Funzionamento del cluster SSM locale ad alta disponibilità 8.X

Opzioni per il download

  • PDF     (7.7 MB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (8.0 MB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (4.1 MB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:24 giugno 2021
ID documento:217212

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    Introduzione

    In questo documento viene descritto il funzionamento della sincronizzazione dell'account locale e della registrazione dell'istanza del prodotto di Smart Software Manager (SSM) sul server locale SSM distribuito come cluster ad alta disponibilità (HA) al momento degli scenari di failover e fallback.

    Prerequisiti

    Requisiti

    Cisco raccomanda la conoscenza dei seguenti argomenti:

    • SSM locale
    • HA

    Componenti usati

    Le informazioni di questo documento si basano su SSM On-Prem 8 e versioni successive.

    Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

    Premesse

    Si tratta dei documenti di riferimento che forniscono informazioni sull’HA.

    Sincronizzazione dell'account locale SSM durante il failover e il fallback

    La disponibilità elevata tra due server locali SSM deve essere configurata con l'aiuto di questa guida:

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

    In questa dimostrazione, utilizzare:

    0.5 - Indirizzo IP del server principale

    .10 - Indirizzo IP del server secondario

    .12 - Indirizzo IP virtuale

    Alta disponibilità

    1. Una corretta configurazione di HA consente di visualizzare il server primario (.5) come attivo, il server secondario (.10) come standby e l'sd VIP (.12) come illustrato nell'immagine.

    2. La sincronizzazione di SSM on-Prem con Cisco Software Central è stata completata dal server primario/attivo come mostrato nell'immagine.

    3. Lo stato HA del cluster indica che il database del server primario (replica master) a sinistra esegue la replica nel database del server secondario (replica slave) a destra come previsto, come mostrato nell'immagine.

    Failover

    1. Arresto del cluster HA sul server primario come mostrato nell'immagine.

    2. Primario|Secondario come mostrato nell'immagine.

    3. Ha eseguito l'accesso all'interfaccia utente locale di SSM usando VIP e l'interfaccia utente principale è inattiva.

    4. Il server secondario (.10) viene visualizzato come server attivo.

    5. Heartbeat disconnesso.

    6. Il server primario (.5) è stato spostato nello stato Standby.

    7. La sincronizzazione dell'account locale SSM con Cisco Software Central può essere verificata correttamente dall'interfaccia utente del server secondario/attivo, come mostrato nell'immagine.

    8. Avvio del cluster HA sul server primario come mostrato nell'immagine.

    9. Lo stato del cluster HA indica che il database primario è replicato dal database secondario.

    10. Primario|Secondario come mostrato nell'immagine.

    11. La GUI mostra l'heartbeat come connesso, secondario nello stato attivo e primario nello stato di standby, come mostrato nell'immagine.

    12. Creare un nuovo account TEST e attivarlo in standby attivo. (.10).

    13. In questa fase non sarà possibile accedere all'interfaccia utente principale (.5).

    Fallback

    1. Arresto di Ha_cluster in Secondario come mostrato nell'immagine.

    2. Lo stato corrente del database del server primario e del database del server secondario è indicato qui.

    3. Ha eseguito l'accesso all'interfaccia utente locale di SSM usando VIP e l'interfaccia utente secondaria è inattiva.

    4. Il server principale (.5) viene visualizzato come server attivo.

    5. Heartbeat disconnesso.

    6. Il server secondario (.5) è stato spostato in stato Standby.

    7. L'account TEST appena creato può essere visualizzato in stato sincronizzato quando la replica è avvenuta dal database secondario a quello primario, come mostrato nell'immagine.

    8. In questa fase, l'interfaccia utente grafica sarà accessibile dall'indirizzo VIP (.12) e non dall'indirizzo IP secondario.

    9. Avvio del cluster HA sul server secondario come mostrato nell'immagine.

    10. Lo stato HA del cluster indica che il database del server primario (replica master) a sinistra sta eseguendo la replica nel database del server secondario (replica slave) a destra come previsto, come mostrato nell'immagine.

    11. La GUI mostra l'heartbeat connesso tra il server primario attivo e il server secondario in standby.

    12. L'account TEST viene sincronizzato correttamente con Cisco Software Central.

    Registrazione dell'istanza del prodotto con SSM On-Prem VIP durante il failover e il fallback

    È consigliabile configurare l'alta disponibilità tra due server locali SSM utilizzando questa guida:

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

    In questa dimostrazione, utilizzare:

    .11 - Indirizzo IP del server principale

    0.9 - Indirizzo IP del server secondario

    .14 - Indirizzo IP virtuale

    Alta disponibilità

    1. Configurazione riuscita di HA che mostra il server primario (.11) come attivo, il server secondario (.9) come standby e VIP (.14).

    2. Lo stato HA del cluster indica che il database del server primario (replica master) a sinistra esegue la replica nel database del server secondario (replica slave) a destra come previsto, come mostrato nell'immagine.

    3. Quando SSM On-Prem viene distribuito come cluster HA, accedere all'area di lavoro di amministrazione locale di SSM, passare a Protezione > Certificati e utilizzare l'indirizzo IP virtuale nel nome comune dell'host.

    4. Questo valore deve corrispondere al valore che si intende utilizzare per l'URL di destinazione del prodotto. Se si distribuisce uno stack doppio (sia IPv4 che IPv6), questo valore deve essere un FQDN e non un indirizzo IP.

    5. Dopo aver aggiornato il nome comune dell'host, assicurarsi che i certificati vengano rigenerati con il nuovo nome comune sincronizzando gli account locali con Cisco Smart Software Manager.

    6. È necessario eseguire la sincronizzazione prima di tentare di registrare nuovamente i prodotti con il nuovo nome comune nella configurazione dell'URL di destinazione.

    7. La mancata sincronizzazione può impedire la registrazione dei prodotti con il nuovo nome comune dell'host.

    8. Due istanze di prodotto, (annanr-39) e (cucmpub) sono registrate nell'indirizzo VIP di SSM On-Prem come mostrato nella scheda Istanze di prodotto.

    9. Le licenze utilizzate/richieste da queste istanze del prodotto vengono visualizzate nella scheda Licenza.

    Failover

    1. Arresto del cluster HA sul server primario come mostrato nell'immagine.

    2. Ha eseguito l'accesso all'interfaccia utente locale di SSM utilizzando VIP (.14) e l'interfaccia utente principale è inattiva.

    3. Il server secondario (.9) viene visualizzato come server attivo.

    4. Heartbeat disconnesso.

    5. Il server principale (.11) viene impostato sullo stato Standby.

    6. Registrazione delle istanze del prodotto con l'utilizzo di SSM On-Prem VIP nell'URL di registrazione del prodotto nell'impostazione Transport Gateway, come mostrato nell'immagine.

    7. Nome istanza prodotto: pi37 è stato registrato con SSM in locale con l'utilizzo di un indirizzo VIP come mostrato nell'immagine.

    8. Registrazione di altre istanze del prodotto con l'utilizzo di SSM On-Prem VIP nell'URL di registrazione del prodotto nell'impostazione Transport Gateway.

    9. La registrazione del prodotto è stata completata con SSM in locale utilizzando un indirizzo VIP come mostrato nell'immagine.

    10. Nome istanza prodotto: cucm-pub-30 è stato registrato con SSM On-Prem con l'utilizzo di un indirizzo VIP, come mostrato nell'immagine.

    11. Due nuove istanze del prodotto, (pi37) e (cucm-pub-30) sono registrate nell'indirizzo VIP del servizio locale SSM come mostrato nella scheda Istanze del prodotto.

    12. Le licenze utilizzate/richieste da queste istanze del prodotto vengono visualizzate nella scheda Licenza.

    13. Avvio del cluster HA nel server primario.

    14. Lo stato del cluster HA indica che il database primario è replicato dal database secondario.

    15. Primario|Secondario come mostrato nell'immagine.

    16. La GUI mostra l'heartbeat come connesso, secondario nello stato attivo e primario nello stato di standby, come mostrato nell'immagine.

    Fallback

    1. Arresto di Ha_cluster nel database secondario.

    2. È possibile visualizzare lo stato corrente del database del server primario e del database del server secondario inattivo.

    3. Ha eseguito l'accesso all'interfaccia utente locale di SSM utilizzando VIP (.14) e l'interfaccia utente secondaria è inattiva.

    4. Il server primario (.11) viene visualizzato come server attivo.

    5. Heartbeat disconnesso.

    6. Il server secondario (.9) è stato spostato in stato Standby.

    7. In questa fase, l'interfaccia utente grafica sarà accessibile dall'indirizzo VIP (.14) e non dall'indirizzo IP secondario.

    8. Avvio del cluster HA sul server secondario.

    9. Lo stato HA del cluster indica che il database del server primario (replica master) a sinistra esegue la replica nel database del server secondario (replica slave) a destra come previsto.

    10. La GUI mostra l'heartbeat connesso tra il server primario attivo e il server secondario in standby.

    11. Tutte e quattro le istanze del prodotto sono state registrate nell'indirizzo VIP locale di SSM come mostrato nella scheda Istanze del prodotto.

    12. Le licenze utilizzate/richieste da queste istanze del prodotto vengono visualizzate nella scheda Licenza.

    Effettuare il downgrade di un cluster ad alta disponibilità

    1. È possibile effettuare il downgrade diretto di un cluster Cisco Smart Manager locale a un singolo nodo standalone.
    2. Utilizzare la console locale per connettersi al server principale/attivo SSM locale con il comando <ha_teardown>.
    3. Dopo aver verificato il funzionamento di SSM locale, il server secondario/standby deve essere scartato e non può essere riutilizzato.
    4. Si disporrà ora di un sistema autonomo anziché di un cluster.
    5. La disinstallazione è stata avviata come mostrato nell'immagine.

    6. Attivazione della disinstallazione sul server secondario come mostrato nell'immagine.

    7. Cluster HA eliminato. SSMS è ora in modalità autonoma.

    8. La GUI a cui si accede utilizzando l'indirizzo IP del server secondario non blocca più il widget Alta disponibilità.

    9. Attivazione della disinstallazione sul server principale come mostrato nell'immagine.

    10. HA è stato disabilitato.

    11. L'accesso tramite GUI tramite l'indirizzo IP del server principale non provoca più l'effetto neve del widget Alta disponibilità.

    E adesso?!

    1. Accedere all'area di lavoro Amministrazione primaria locale di SSM, passare a Sicurezza > Certificati e utilizzare il nome comune host del server primario (indirizzo IP/nome host/FQDN).

    2. Dopo aver aggiornato il nome comune dell'host, assicurarsi che i certificati vengano rigenerati con il nuovo nome comune sincronizzando gli account locali con Cisco SSM.

    3. È necessario eseguire la sincronizzazione prima di tentare di registrare nuovamente i prodotti con il nuovo nome comune nella configurazione dell'URL di destinazione.

    4. La mancata sincronizzazione può impedire la registrazione dei prodotti con il nuovo nome comune dell'host.

    Informazioni correlate

    TAC Authored

    Contributo dei tecnici Cisco

    • Annangarachari R
      Cisco TAC Engineer

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci

    Questo documento si applica a questi prodotti