Fonctionnement du cluster haute disponibilité SSM sur site 8.X

Options de téléchargement

  • PDF     (7.7 MB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (8.0 MB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (4.1 MB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:24 juin 2021
ID du document:217212

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit comment la synchronisation des comptes sur site Smart Software Manager (SSM) et l'enregistrement d'instance de produit fonctionnent sur le serveur sur site SSM déployé en tant que cluster haute disponibilité (HA) au moment des scénarios de basculement et de secours.

    Conditions préalables

    Conditions requises

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • SSM sur site
    • HA

    Components Used

    Les informations de ce document sont basées sur SSM On-Prem 8 et versions ultérieures.

    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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

    Informations générales

    Il s'agit des documents de référence qui fournissent de l'information sur la haute disponibilité.

    Synchronisation de compte sur site SSM lors du basculement et de la reprise

    La haute disponibilité entre deux serveurs SSM On-Prem doit être configurée à l'aide de ce guide :

    Déployer le cluster HA : https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    Dans cette démonstration, utilisez :

    .5 - Adresse IP du serveur principal

    .10 - Adresse IP du serveur secondaire

    .12 - Adresse IP virtuelle

    Haute disponibilité

    1. La configuration réussie de HA montre le serveur principal (.5) comme serveur actif et secondaire (.10) comme sd de veille et VIP (.12) illustré dans l'image.

    2. La synchronisation de SSM On-Prem avec Cisco Software Central s'est terminée correctement à partir du serveur principal/actif, comme l'illustre l'image.

    3. L'état HA du cluster montre que la base de données du serveur principal (Replication Master) sur la gauche se réplique vers la base de données du serveur secondaire (Replication Slave) sur la droite comme prévu dans l'image.

    Basculement

    1. Arrêt du cluster HA sur le serveur principal, comme illustré dans l'image.

    2. Principal|Secondaire comme illustré dans l'image.

    3. Connecté à l'interface utilisateur graphique SSM On-Prem à l'aide du protocole VIP et l'interface utilisateur graphique principale est désactivée.

    4. Le serveur secondaire (.10) est affiché en tant que serveur actif.

    5. La pulsation est déconnectée.

    6. Le serveur principal (.5) est passé à l'état Veille.

    7. La synchronisation du compte SSM On-Prem avec Cisco Software Central peut être vue correctement à partir de l'interface utilisateur graphique du serveur secondaire/actif, comme l'illustre l'image.

    8. Démarrage du cluster HA sur le serveur principal, comme illustré dans l'image.

    9. L'état du cluster HA indique que la base de données principale est répliquée à partir de la base de données secondaire.

    10. Principal|Secondaire comme illustré dans l'image.

    11. L'interface utilisateur graphique affiche la pulsation en tant que connexion, l'état Secondaire en état Actif et l'état Principal en veille comme illustré dans l'image.

    12. Créez un compte TEST et activez-le en veille active. (.10).

    13. L'interface graphique principale (.5) ne sera pas accessible à ce stade.

    Basculement

    1. Arrêt de Ha_cluster dans Secondaire comme illustré dans l'image.

    2. L'état actuel de la base de données du serveur principal et de la base de données du serveur secondaire est visible ici.

    3. Connecté à l'interface utilisateur graphique SSM On-Prem à l'aide du protocole VIP et l'interface utilisateur graphique secondaire est désactivée.

    4. Le serveur principal (.5) est affiché en tant que serveur actif.

    5. La pulsation est déconnectée.

    6. Le serveur secondaire (.5) est passé à l'état Veille.

    7. Le compte TEST nouvellement créé peut être vu à l'état synchronisé, car la réplication s'est produite de la base de données secondaire vers la base de données principale comme l'illustre l'image.

    8. L'interface utilisateur graphique sera accessible à partir de l'adresse VIP (.12) à ce stade et non de l'adresse IP secondaire.

    9. Démarrage du cluster HA sur le serveur secondaire, comme illustré dans l'image.

    10. L'état HA du cluster indique que la base de données du serveur principal (maître de réplication) sur la gauche se réplique vers la base de données du serveur secondaire (esclave de réplication) sur la droite comme prévu dans l'image.

    11. L'interface utilisateur graphique affiche Heartbeat connecté entre le serveur principal actif et le serveur secondaire de secours.

    12. Le compte TEST se synchronise correctement avec Cisco Software Central.

    Inscription d'instance de produit avec VIP SSM sur site pendant le basculement et la restauration

    La haute disponibilité entre deux serveurs SSM On-Prem doit être configurée à l'aide de ce guide :

    Déploiement du cluster HA : https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    Dans cette démonstration, utilisez :

    .11 - Adresse IP du serveur principal

    .9 - Adresse IP du serveur secondaire

    .14 - Adresse IP virtuelle

    Haute disponibilité

    1. Configuration de la haute disponibilité qui affiche le serveur principal (.11) comme serveur actif, secondaire (.9) comme serveur de secours et VIP (.14).

    2. L'état HA du cluster indique que la base de données du serveur principal (maître de réplication) à gauche se réplique vers la base de données du serveur secondaire (esclave de réplication) à droite comme prévu dans l'image.

    3. Lorsque SSM On-Prem est déployé en tant que cluster HA, connectez-vous à SSM On-Prem Administration Workspace, accédez à Security > Certificates et utilisez l'adresse IP virtuelle sur le nom commun de l'hôte.

    4. Cette valeur doit correspondre à la valeur que vous prévoyez d'utiliser pour l'URL de destination du produit. Si vous déployez une double pile (IPv4 et IPv6), cette valeur doit être un nom de domaine complet (FQDN) et non une adresse IP.

    5. Après avoir mis à jour le nom commun de l'hôte, assurez-vous que vos certificats sont régénérés avec le nouveau nom commun en synchronisant vos comptes locaux avec Cisco Smart Software Manager.

    6. Vous devez effectuer une synchronisation avant de tenter de réenregistrer les produits avec le nouveau nom commun dans la configuration de l'URL de destination.

    7. La non-synchronisation peut entraîner l'échec de l'enregistrement des produits avec le nouveau nom commun d'hôte.

    8. Deux instances de produit (annanr-39) et (cucmpub) sont enregistrées à l'adresse VIP de SSM On-Prem, comme indiqué dans l'onglet Product Instances.

    9. La licence consommée/demandée par ces instances de produit est reflétée dans l'onglet Licence.

    Basculement

    1. Arrêt du cluster HA sur le serveur principal, comme illustré dans l'image.

    2. Connecté à l'interface utilisateur graphique SSM On-Prem à l'aide du protocole VIP (.14) et l'interface utilisateur graphique principale est désactivée.

    3. Le serveur secondaire (.9) est affiché en tant que serveur actif.

    4. La pulsation est déconnectée.

    5. Le serveur principal (.11) est déplacé à l'état Veille.

    6. Inscription des instances de produit à l'aide du programme VIP SSM On-Prem dans l'URL d'enregistrement de produit au niveau du paramètre de la passerelle de transport, comme illustré dans l'image.

    7. Nom de l'instance de produit : pi37 a été enregistré avec succès avec SSM On-Prem avec l'utilisation d'une adresse VIP comme l'illustre l'image.

    8. Inscription d'autres instances de produit à l'aide de SSM On-Prem VIP dans l'URL d'enregistrement de produit au niveau du paramètre de la passerelle de transport.

    9. L'enregistrement du produit s'est terminé avec SSM On-Prem à l'aide d'une adresse VIP, comme indiqué sur l'image.

    10. Nom de l'instance de produit : cucm-pub-30 a été enregistré avec succès auprès de SSM On-Prem avec l'utilisation d'une adresse VIP comme l'illustre l'image.

    11. Deux nouvelles instances de produit (pi37) et (cucm-pub-30) sont enregistrées à l'adresse VIP de SSM On-Prem, comme indiqué dans l'onglet Product Instances.

    12. La licence consommée/demandée par ces instances de produit est reflétée dans l'onglet Licence.

    13. Démarrage du cluster HA sur le serveur principal.

    14. L'état du cluster HA indique que la base de données principale est répliquée à partir de la base de données secondaire.

    15. Principal|Secondaire comme illustré dans l'image.

    16. L'interface utilisateur graphique affiche la pulsation en tant que connexion, l'état Secondaire en état Actif et l'état Principal en veille comme illustré dans l'image.

    Basculement

    1. Arrêt de Ha_cluster dans secondaire.

    2. L'état actuel de la base de données du serveur principal et de la base de données du serveur secondaire désactivée est visible.

    3. Connecté à l'interface utilisateur graphique SSM On-Prem à l'aide de VIP (.14) et l'interface utilisateur secondaire est désactivée.

    4. Le serveur principal (.11) est affiché en tant que serveur actif.

    5. La pulsation est déconnectée.

    6. Le serveur secondaire (.9) est passé à l'état Veille.

    7. L'interface utilisateur graphique sera accessible à partir de l'adresse VIP (.14) à ce stade et non de l'adresse IP secondaire.

    8. Démarrage du cluster HA sur le serveur secondaire.

    9. L'état HA du cluster indique que la base de données du serveur principal (maître de réplication) à gauche se réplique vers la base de données du serveur secondaire (esclave de réplication) à droite comme prévu.

    10. L'interface utilisateur graphique affiche Heartbeat connecté entre le serveur principal actif et le serveur secondaire de secours.

    11. Les quatre instances de produit enregistrées à l'adresse VIP de SSM On-Prem, comme indiqué dans l'onglet Instances de produit.

    12. La licence consommée/demandée par ces instances de produit est reflétée dans l'onglet Licence.

    Rétrograder un cluster haute disponibilité

    1. Un cluster Cisco Smart Manager On-Prem peut être directement rétrogradé vers un seul noeud autonome.
    2. Utilisez la console On-Prem pour vous connecter au module SSM principal/actif On-Prem à l'aide de la commande <ha_teardown>.
    3. Après avoir vérifié le fonctionnement de SSM On-Prem, le serveur secondaire/veille doit être abandonné et ne peut pas être réutilisé.
    4. Vous disposerez désormais d'un système autonome au lieu d'un cluster.
    5. Le démontage a été initié comme le montre l'image.

    6. Déclenchement de la désactivation sur le serveur secondaire comme illustré dans l'image.

    7. Le cluster HA a été détruit. SSMS est maintenant en mode autonome.

    8. L'interface utilisateur graphique accessible à l'aide de l'adresse IP du serveur secondaire ne neige plus le widget Haute disponibilité.

    9. Déclenchement de la désactivation sur le serveur principal comme illustré dans l'image.

    10. La HA a été désactivée.

    11. L'interface utilisateur graphique accessible à l'aide de l'adresse IP du serveur principal n'enlève plus le widget Haute disponibilité.

    Et ensuite ? !

    1. Connectez-vous à SSM On-Prem Primary Administration Workspace, accédez à Security > Certificates et utilisez le serveur principal (adresse IP/nom d'hôte/nom de domaine complet) sur le nom commun de l'hôte.

    2. Après avoir mis à jour le nom commun de l'hôte, assurez-vous que vos certificats sont régénérés avec le nouveau nom commun en synchronisant vos comptes locaux avec Cisco SSM.

    3. Vous devez effectuer une synchronisation avant de tenter de réenregistrer les produits avec le nouveau nom commun dans la configuration de l'URL de destination.

    4. La non-synchronisation peut entraîner l'échec de l'enregistrement des produits avec le nouveau nom commun d'hôte.

    Informations connexes

    TAC Authored

    Contribution d’experts de Cisco

    • Annangarachari R
      Cisco TAC Engineer

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits