Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

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 34 for a definition of SSR nodes compared to SBR nodes.

    Table 34: 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.