Hochverfügbarkeits-Cluster mit SSM vor Ort 8.x in Betrieb

Download-Optionen

  • PDF     (7.9 MB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (9.9 MB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (4.1 MB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:24. Juni 2021
Dokument-ID:217212

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

    Einleitung

    In diesem Dokument wird beschrieben, wie die Smart Software Manager (SSM)-Vor-Ort-Kontensynchronisierung und die Produktinstanzregistrierung auf dem als Hochverfügbarkeits-Cluster bereitgestellten SSM-Vor-Ort-Server bei Failover- und Fallback-Szenarien durchgeführt werden.

    Voraussetzungen

    Anforderungen

    Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

    • SSM vor Ort
    • HA

    Verwendete Komponenten

    Die Informationen in diesem Dokument basieren auf standortbasiertem SSM 8 und höher.

    Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

    Hintergrundinformationen

    Dies sind die Referenzdokumente, die Informationen über HA bereitstellen.

    SSM-Synchronisierung vor Ort während Failover und Fallback

    Die hohe Verfügbarkeit zwischen zwei lokalen SSM-Servern muss mithilfe dieses Handbuchs konfiguriert werden:

    HA-Cluster bereitstellen: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    Verwenden Sie in dieser Demonstration Folgendes:

    .5 - IP-Adresse des primären Servers

    .10 - IP-Adresse des sekundären Servers

    .12 - Virtuelle IP-Adresse

    Hohe Verfügbarkeit

    1. Bei erfolgreicher Konfiguration von HA wird der primäre Server (.5) als aktiver, der sekundäre Server (.10) als Standby- und der VIP-Server (.12) als sd im Bild angezeigt.

    2. Die Synchronisierung von SSM On-Prem mit Cisco Software Central wurde erfolgreich vom primären/aktiven Server aus abgeschlossen, wie im Image gezeigt.

    3. Cluster-HA-Status zeigt an, dass die Datenbank des primären Servers (Replication Master) auf der linken Seite auf die Datenbank des sekundären Servers (Replication Slave) auf der rechten Seite repliziert wird, wie im Image dargestellt.

    Failover

    1. HA-Cluster auf dem primären Server wird angehalten, wie im Bild gezeigt.

    2. Primär|Sekundär wie im Bild dargestellt.

    3. Bei der lokalen SSM-GUI mit VIP angemeldet, und die primäre GUI ist ausgefallen.

    4. Der sekundäre Server (.10) wird als aktiver Server angezeigt.

    5. Heartbeat wird getrennt.

    6. Primärer Server (.5) in den Standby-Status versetzt.

    7. Die Synchronisierung des lokalen SSM-Kontos mit Cisco Software Central kann in der grafischen Benutzeroberfläche des sekundären/aktiven Servers erfolgreich durchgeführt werden (siehe Abbildung).

    8. Starten des HA-Clusters auf dem primären Server, wie im Bild dargestellt

    9. Der HA-Clusterstatus zeigt an, dass die primäre Datenbank aus der sekundären Datenbank repliziert wird.

    10. Primär|Sekundär wie im Bild dargestellt.

    11. Die GUI zeigt den Heartbeat als verbunden, den sekundären im aktiven Zustand und den primären im Standby-Zustand an, wie im Bild gezeigt.

    12. Erstellen Sie ein neues TEST-Konto und aktivieren Sie es im aktiven Standby-Modus. (.10)-Server.

    13. Derzeit ist kein Zugriff auf die primäre GUI (.5) möglich.

    Fallback

    1. Ha_cluster wird in Sekundär beendet, wie im Bild gezeigt.

    2. Hier sehen Sie den aktuellen Status der Datenbank des primären Servers und der Datenbank des sekundären Servers.

    3. Bei der lokalen SSM-GUI unter Verwendung von VIP angemeldet und die sekundäre GUI ausgefallen.

    4. Der primäre Server (.5) wird als aktiver Server angezeigt.

    5. Heartbeat wird getrennt.

    6. Sekundärer Server (.5) in den Standby-Status versetzt.

    7. Das neu erstellte TEST-Konto kann im synchronisierten Zustand angezeigt werden, wenn die Replikation von der sekundären zu der primären Datenbank erfolgt ist, wie im Bild gezeigt.

    8. GUI ist zu diesem Zeitpunkt über die VIP-Adresse (.12) und nicht über die sekundäre IP-Adresse zugänglich.

    9. Hochverfügbarkeits-Cluster auf dem sekundären Server wird gestartet, wie im Bild dargestellt.

    10. Der HA-Status des Clusters zeigt an, dass die Datenbank des primären Servers (Replication Master) auf der linken Seite auf die Datenbank des sekundären Servers (Replication Slave) auf der rechten Seite repliziert wird, wie im Abbild dargestellt.

    11. Die GUI zeigt den Heartbeat an, der zwischen dem aktiven primären Server und dem sekundären Standby-Server verbunden ist.

    12. Das TEST-Konto wird erfolgreich mit Cisco Software Central synchronisiert.

    Registrierung von Produktinstanzen bei VIP-Service am Standort von SSM während Failover und Fallback

    Die hohe Verfügbarkeit zwischen zwei lokalen SSM-Servern muss mithilfe dieses Handbuchs konfiguriert werden:

    Bereitstellen des HA-Clusters: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    Verwenden Sie in dieser Demonstration Folgendes:

    .11 - IP-Adresse des primären Servers

    .9 - IP-Adresse des sekundären Servers

    .14 - Virtuelle IP-Adresse

    Hohe Verfügbarkeit

    1. Erfolgreiche Konfiguration von HA, bei der der primäre Server (.11) als aktiver Server, der sekundäre Server (.9) als Standby- und VIP-Server (.14) angezeigt wird.

    2. Cluster-HA-Status zeigt an, dass die Datenbank des primären Servers (Replication Master) auf der linken Seite wie im Abbild dargestellt auf die Datenbank des sekundären Servers (Replication Slave) auf der rechten Seite repliziert wird.

    3. Wenn SSM On-Prem als HA-Cluster bereitgestellt wird, melden Sie sich beim SSM On-Prem Administration Workspace an, navigieren Sie zu Sicherheit > Zertifikate, und verwenden Sie die virtuelle IP-Adresse auf dem gemeinsamen Hostnamen.

    4. Dieser Wert muss mit dem Wert übereinstimmen, den Sie für die Produkt-Ziel-URL verwenden möchten. Bei Bereitstellung eines Dual-Stack-Netzwerks (sowohl IPv4 als auch IPv6) muss dieser Wert ein FQDN und keine IP-Adresse sein.

    5. Nachdem Sie den gemeinsamen Hostnamen aktualisiert haben, stellen Sie sicher, dass Ihre Zertifikate mit dem neuen gemeinsamen Namen neu generiert werden, indem Sie Ihre lokalen Konten mit Cisco Smart Software Manager synchronisieren.

    6. Sie müssen synchronisieren, bevor Sie versuchen, die Produkte mit dem neuen Common Name in der Ziel-URL-Konfiguration neu zu registrieren.

    7. Wird die Synchronisierung nicht durchgeführt, können sich die Produkte nicht für den neuen gemeinsamen Hostnamen registrieren lassen.

    8. Zwei Produktinstanzen (annanr-39) und (cucmpub) werden an die VIP-Adresse von SSM On-Prem registriert (siehe Registerkarte "Produktinstanzen").

    9. Die von diesen Produktinstanzen verwendete/angeforderte Lizenz wird auf der Registerkarte License (Lizenz) angezeigt.

    Failover

    1. HA-Cluster auf dem primären Server wird angehalten, wie im Bild gezeigt.

    2. Bei der lokalen SSM-GUI unter Verwendung von VIP (.14) angemeldet und die primäre GUI ausgefallen.

    3. Der sekundäre Server (.9) wird als aktiver Server angezeigt.

    4. Heartbeat wird getrennt.

    5. Der primäre Server (.11) wird in den Standby-Status versetzt.

    6. Registrieren von Produktinstanzen unter Verwendung von SSM On-Prem VIP in der Produktregistrierungs-URL bei den Transport Gateway-Einstellungen, wie im Bild gezeigt.

    7. Name der Produktinstanz: pi37 wurde erfolgreich bei SSM On-Prem unter Verwendung einer VIP-Adresse wie im Bild dargestellt registriert.

    8. Registrieren anderer Produktinstanzen unter Verwendung von SSM On-Prem VIP in der Produktregistrierungs-URL bei den Transport Gateway-Einstellungen.

    9. Die Produktregistrierung wurde mit SSM On-Prem erfolgreich abgeschlossen. Hierzu wurde die VIP-Adresse verwendet, wie im Bild gezeigt.

    10. Name der Produktinstanz: cucm-pub-30 wurde erfolgreich bei SSM On-Prem unter Verwendung einer VIP-Adresse registriert, wie im Bild gezeigt.

    11. Zwei neue Produktinstanzen (pi37) und (cucm-pub-30) werden an die VIP-Adresse von SSM On-Prem registriert (siehe Registerkarte Produktinstanzen).

    12. Die von diesen Produktinstanzen verwendete/angeforderte Lizenz wird auf der Registerkarte License (Lizenz) angezeigt.

    13. Hochverfügbarkeits-Cluster auf dem primären Server wird gestartet.

    14. Der HA-Clusterstatus zeigt an, dass die primäre Datenbank aus der sekundären Datenbank repliziert wird.

    15. Primär|Sekundär wie im Bild dargestellt.

    16. Die GUI zeigt den Heartbeat als verbunden, den sekundären im aktiven Zustand und den primären im Standby-Zustand an, wie im Bild gezeigt.

    Fallback

    1. Ha_cluster wird in sekundärem Cluster angehalten.

    2. Der aktuelle Status der Datenbank des primären Servers und der Datenbank des sekundären Servers kann angezeigt werden.

    3. Über VIP (.14) bei der lokalen SSM-GUI angemeldet und die sekundäre GUI ausgefallen.

    4. Der primäre Server (.11) wird als aktiver Server angezeigt.

    5. Heartbeat wird getrennt.

    6. Sekundärer Server (.9) in den Standby-Status versetzt.

    7. Die GUI ist zu diesem Zeitpunkt über die VIP-Adresse (.14) und nicht über die sekundäre IP-Adresse zugänglich.

    8. Starten des HA-Clusters auf dem sekundären Server

    9. Cluster-HA-Status zeigt an, dass die Datenbank des primären Servers (Replication Master) auf der linken Seite wie erwartet auf die Datenbank des sekundären Servers (Replication Slave) auf der rechten Seite repliziert wird.

    10. Die GUI zeigt den Heartbeat an, der zwischen dem aktiven primären Server und dem sekundären Standby-Server verbunden ist.

    11. Alle vier Produktinstanzen wurden unter der VIP-Adresse von SSM On-Prem registriert (siehe Registerkarte "Produktinstanzen").

    12. Die von diesen Produktinstanzen verwendete/angeforderte Lizenz wird auf der Registerkarte License (Lizenz) angezeigt.

    Hochverfügbarkeits-Cluster herunterstufen

    1. Ein interner Cisco Smart Manager-Cluster kann direkt auf einen Einzelknoten heruntergestuft werden.
    2. Verwenden Sie den Befehl <ha_teardown>, um über die Konsole eine Verbindung mit dem primären/aktiven SSM vor Ort herzustellen.
    3. Nach der Überprüfung des Betriebs des SSM vor Ort muss der sekundäre/Standby-Server verworfen werden und kann nicht wiederverwendet werden.
    4. Statt eines Clusters haben Sie jetzt ein eigenständiges System.
    5. Der Abriss wurde wie im Bild dargestellt eingeleitet.

    6. Auslösen des Abbruchs auf dem sekundären Server, wie im Bild gezeigt.

    7. HA-Cluster wurde zerstört. SSMS befindet sich jetzt im Standalone-Modus.

    8. GUI zugegriffen mit der Verwendung der sekundären Server-IP-Adresse nicht mehr schneien die Hochverfügbarkeit Widget.

    9. Auslösen des Abbruchs auf dem primären Server, wie im Bild gezeigt.

    10. HA wurde erfolgreich deaktiviert.

    11. Die GUI, auf die mit der IP-Adresse des primären Servers zugegriffen wird, schneidet das Widget für hohe Verfügbarkeit nicht mehr.

    Nächste Schritte?!

    1. Melden Sie sich beim lokalen SSM-Arbeitsbereich für die primäre Administration an, navigieren Sie zu Security > Certificates, und verwenden Sie die des primären Servers (IP-Adresse/Hostname/FQDN) auf dem gemeinsamen Hostnamen.

    2. Nachdem Sie den gemeinsamen Hostnamen aktualisiert haben, stellen Sie sicher, dass Ihre Zertifikate mit dem neuen gemeinsamen Namen neu generiert werden, indem Sie Ihre lokalen Konten mit Cisco SSM synchronisieren.

    3. Sie müssen eine Synchronisierung durchführen, bevor Sie versuchen, die Produkte mit dem neuen Common Name in der Ziel-URL-Konfiguration neu zu registrieren.

    4. Wird die Synchronisierung nicht durchgeführt, können sich die Produkte nicht für den neuen gemeinsamen Hostnamen registrieren lassen.

    Zugehörige Informationen

    TAC Authored

    Beiträge von Cisco Ingenieuren

    • Annangarachari R
      Cisco TAC-Techniker

    War dieses Dokument hilfreich?

    FeedbackFeedback

    Cisco kontaktieren

    Dieses Dokument gilt für folgende Produkte.