Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Proper Order for Starting Nodes in a Cluster

Begin by starting all SSR nodes, one at a time in the following order:

  1. SBR/management nodes (sm):
    On each SBR/management node, one at a time, execute sbrd start ssr. Then, check the status of that node by executing sbrd status, and ensure the SSR process is running without error. There should be no indication of starting, connecting, or disconnected. Repeat this process until each SBR/management node is started and running without error.
  2. Management nodes (m):
    On each management node, one at a time, execute sbrd start ssr. Then, check the status of that node by executing sbrd status, and ensure the SSR process is running without error. There should be no indication of starting, connecting, or disconnected. Repeat this process until each management node is started and running without error.
  3. Data nodes (d):
    On each data node, one at a time, execute sbrd start ssr. Then, check the status of that node by executing sbrd status, and ensure the SSR process is running without error. There should be no indication of starting, connecting, or disconnected. Repeat this process until each data node is started and running without error.
  4. If this is the first time starting the cluster, or if the schema has changed, you need to execute CreateDB.sh on every management node before proceeding to the next step of starting the RADIUS process on all SBR nodes.

    By definition, the schema has changed if DestroyDB.sh has been executed on any management node including: SBR/management nodes (sm) or management nodes (m).

    If you have executed DestroyDB.sh on any management node, we recommend you run ./sbrd clean before starting the SSR process on the node with the ./sbrd start ssr command.

    Note: Except when migrating from a temporary cluster, all SSR processes must be up on all SSR nodes [sm, m, d] and all SBR processes must be down on all SBR nodes [s, sm] in order to execute CreateDB.sh. This is also the case when executing DestroyDB.sh. See Table 37 for a definition of SSR nodes compared to SBR nodes.

    Table 37: Node Type Definitions

    SSR Nodes

    SBR Nodes

    SBR/management (sm)*

    SBR/management (sm)

    Management nodes (m)

    SBR node (s)

    Data nodes (d)

    * These are also referred to as management nodes.

    If this is not the first time starting the cluster, and you are sure the schema has not changed, proceed to next Step.

  5. Start all SBR nodes, one at a time, by executing sbrd start radius in the following order:
    1. SBR nodes (s):
      On each SBR node, one at a time, execute sbrd start radius. Then, check the status of that node by executing sbrd status, and ensure the RADIUS process is running without error. There should be no indication of starting, connecting, or disconnected. Repeat this process until each SBR node is started and running without error.
    2. SBR/management nodes (sm):
      On each SBR/management node, one at a time, execute sbrd start radius. Then, check the status of that node by executing sbrd status, and ensure the RADIUS process is running without error. There should be no indication of starting, connecting, or disconnected. Repeat this process until each SBR node is started and running without error.

Note: When CCM is enabled, you must start the primary SBR Carrier server first, wherever it is. In most cases, one of the sm nodes is the primary. So, in the case of CCM, the order in which SBR nodes are started is ultimately determined by which s or sm node is the primary. Start the SBR nodes beginning with the primary first, and then follow the order listed previously.

Modified: 2017-10-26