SSM On-Prem 8.X High Availability Cluster Working

Available Languages

Download Options

  • PDF     (7.7 MB)
    View with Adobe Reader on a variety of devices
  • ePub     (8.0 MB)
    View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
  • Mobi (Kindle)     (4.1 MB)
    View on Kindle device or Kindle app on multiple devices
Updated:June 24, 2021
Document ID:217212

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

    Introduction

    This document describes how the Smart Software Manager (SSM) On-Prem Account synchronization and Product Instance registration works on the SSM On-Prem server deployed as a High Availability (HA) Cluster, at the time of Failover and Fallback scenarios.

    Prerequisites

    Requirements

    Cisco recommends that you have knowledge of these topics:

    • SSM On-Prem
    • HA

    Components Used

    The information in this document is based on SSM On-Prem 8 and above.

    The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

    Background Information

    These are the reference documents that provide information on HA.

    SSM On-Prem Account Synchronization during Failover and Fallback

    HA between two SSM On-Prem servers should be configured with the help of this guide:

    Deploy the HA cluster: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    In this demonstration, use:

    .5 - Primary Server's IP Address

    .10 - Secondary Server's IP Address

    .12 - Virtual IP Address

    High Availability

    1. Successful configuration of HA shows Primary server (.5) as Active, Secondary server (.10) as Standby and VIP (.12) sd shown in the image.

    2. Synchronization of SSM On-Prem with Cisco Software Central has been completed successfully from the Primary/Active server as shown in the image.

    3. Cluster HA status show that the primary server's database (Replication Master) on the left replicates to the secondary server's database (Replication Slave) on the right as expected as shown in the image.

    Failover

    1. Stopping HA cluster on Primary Server as shown in the image.

    2. Primary|Secondary as shown in the image.

    3. Logged into the SSM On-Prem GUI with the use of VIP and the Primary GUI is down.

    4. The secondary server (.10) is shown as an Active server.

    5. Heartbeat is disconnected.

    6. Primary server (.5) moved to Standby state.

    7. Synchronization of SSM On-Prem Account with Cisco Software Central can be seen successfully from the Secondary/Active server GUI as shown in the image.

    8. Starting the HA cluster on the Primary server as shown in the image.

    9. HA Cluster status shows that the Primary database is replicated from the Secondary database.

    10. Primary|Secondary as shown in the image.

    11. GUI shows heartbeat as connected, Secondary in Active state and Primary in Standby state as shown in the image.

    12. Create a new TEST account and activate it on Active standby. (.10) server.

    13. Primary (.5) GUI will not be accessible at this stage.

    Fallback

    1. Stopping Ha_cluster in Secondary as shown in the image.

    2. The current status of the Primary server's database and Secondary server's database can be seen here.

    3. Logged into the SSM On-Prem GUI with the use of VIP and the Secondary GUI is down.

    4. The Primary server (.5) is shown as an Active server.

    5. Heartbeat is disconnected.

    6. Secondary server (.5) moved to Standby state.

    7. The newly created TEST Account can be seen in synced state as the replication happened from Secondary to Primary database as shown in the image.

    8. GUI will be accessible from the VIP address (.12) at this stage and not the secondary IP address.

    9. Starting HA Cluster on the Secondary server as shown in the image.

    10. The cluster HA status shows that the Primary server's database (Replication Master) on the left is replicating to the secondary server's database (Replication Slave) on the right as expected as shown in the image.

    11. The GUI shows Heartbeat connected between Active Primary server and Standby Secondary server.

    12. The TEST account synchronizes successfully with Cisco Software Central.

    Product Instance Registration with SSM On-Prem VIP during Failover and Fallback

    High Availability between two SSM On-Prem servers should be configured using this guide:

    Deploying the HA cluster: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    In this demonstration, use:

    .11 - Primary Server's IP Address

    .9 - Secondary Server's IP Address

    .14 - Virtual IP Address

    High Availability

    1. Successful configuration of HA that shows Primary server (.11) as Active, Secondary server (.9) as Standby and VIP (.14).

    2. Cluster HA status shows that the primary server's database (Replication Master) on the left replicates to the secondary server's database (Replication Slave) on the right as expected as shown in the image.

    3. When SSM On-Prem is deployed as a HA Cluster, login to SSM On-Prem Administration Workspace, navigate to the Security > Certificates and use the Virtual IP Address on the Host Common Name.

    4. This value must match the value you plan to use for the product destination URL. If deploying dual-stack (both IPv4 and IPv6) this value must be an FQDN and not an IP address.

    5. After you have updated the Host Common Name, ensure that your certificates are regenerated with the new Common Name by synchronizing your Local Accounts with Cisco Smart Software Manager.

    6. You must synchronize before attempting to re-register the products with the new Common Name in the destination URL configuration.

    7. Not synchronizing can result in the products failing to register with the new Host Common Name.

    8. Two product instances, (annanr-39) and (cucmpub) are registered to SSM On-Prem’s VIP address as seen on the Product Instances tab.

    9. License consumed/requested by these product instances are reflecting on the License tab.

    Failover

    1. Stopping HA cluster on Primary Server as shown in the image.

    2. Logged into the SSM On-Prem GUI with the use of VIP (.14) and the Primary GUI is down.

    3. Secondary server (.9) is shown as an Active server.

    4. Heartbeat is disconnected.

    5. The Primary server (.11) is moved to the Standby state.

    6. Registering product instances with the use of SSM On-Prem VIP in product registration URL at Transport Gateway setting as shown in the image.

    7. Product Instance Name: pi37 has been successfully registered with SSM On-Prem with the use of a VIP address as shown in the image.

    8. Registering other product instances with the use of SSM On-Prem VIP in product registration URL at Transport Gateway setting.

    9. Product registration successfully completed with SSM On-Prem using a VIP address as shown in the image.

    10. Product Instance Name: cucm-pub-30 has been successfully registered with SSM On-Prem with the use of a VIP address as shown in the image.

    11. Two new product instances, (pi37) and (cucm-pub-30) are registered to SSM On-Prem’s VIP address as seen on the Product Instances tab.

    12. License consumed/requested by these product instances are reflecting on the License tab.

    13. Starting the HA cluster on the Primary server.

    14. HA Cluster status shows that the Primary database is replicated from the Secondary database.

    15. Primary|Secondary as shown in the image.

    16. GUI shows heartbeat as connected, Secondary in Active state and Primary in Standby state as shown in the image.

    Fallback

    1. Stopping Ha_cluster in secondary.

    2. Current status of the Primary server's database and the Secondary server's database down can be seen.

    3. Logged into the SSM On-Prem GUI using VIP (.14) and the Secondary GUI is down.

    4. Primary server (.11) is shown as an Active server.

    5. Heartbeat is disconnected.

    6. Secondary server (.9) moved to Standby state.

    7. GUI will be accessible from the VIP address (.14) at this stage and not the Secondary IP address.

    8. Starting HA Cluster on the Secondary server.

    9. Cluster HA status shows that the primary server's database (Replication Master) on the left replicates to the secondary server's database (Replication Slave) on the right as expected.

    10. The GUI shows Heartbeat connected between Active Primary server and Standby Secondary server.

    11. All four product instances registered to SSM On-Prem’s VIP address as seen on the Product Instances tab.

    12. License consumed/requested by these product instances are reflecting on the License tab.

    Downgrade a High Availability Cluster

    1. A Cisco Smart Manager On-Prem cluster can be directly downgraded to a single node standalone.
    2. Use the On-Prem Console to connect to the Primary/Active SSM On-Prem with the use of the <ha_teardown> command.
    3. After you verify the SSM On-Prem’s operation, the Secondary/Standby server must be discarded and cannot be reused.
    4. You will now have a standalone system instead of a cluster.
    5. The teardown has been initiated as shown in the image.

    6. Triggering teardown on the Secondary server as shown in the image.

    7. HA cluster has been destroyed. SSMS is now in a stand-alone mode.

    8. GUI accessed with the use of the Secondary server IP address does not snow the High availability widget anymore.

    9. Triggering teardown on the Primary server as shown in the image.

    10. HA has been disabled successfully.

    11. GUI accessed with the use of the Primary server IP address does not snow the High availability widget anymore.

    What Next?!

    1. Log in to SSM On-Prem Primary Administration Workspace, navigate to the Security > Certificates and use the Primary server's (IP address/Hostname/FQDN) on the Host Common Name.

    2. After you have updated the Host Common Name, ensure that your certificates are regenerated with the new Common Name by synchronizing your Local Accounts with Cisco SSM.

    3. You must synchronize before you attempt to re-register the products with the new Common Name in the destination URL configuration.

    4. Not synchronizing can result in the products failing to register with the new Host Common Name.

    Related Information

    TAC Authored

    Contributed by Cisco Engineers

    • Annangarachari R
      Cisco TAC Engineer

    Was this Document Helpful?

    FeedbackFeedback

    Contact Cisco

    This Document Applies to These Products