Trabajo en clúster de alta disponibilidad en las instalaciones de SSM 8.X

Opciones de descarga

  • PDF     (7.7 MB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (8.0 MB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (4.1 MB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:24 de junio de 2021
ID del documento:217212

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

    Introducción

    Este documento describe cómo funciona la sincronización Smart Software Manager (SSM) On-Prem Account y el registro de la instancia del producto en el servidor SSM On-Prem implementado como un clúster de alta disponibilidad (HA), en el momento de los escenarios de recuperación ante fallos y recuperación.

    Prerequisites

    Requirements

    Cisco recomienda que tenga conocimiento sobre estos temas:

    • SSM in situ
    • HA

    Componentes Utilizados

    La información en este documento se basa en SSM On-Prem 8 y superiores.

    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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

    Antecedentes

    Estos son los documentos de referencia que proporcionan información sobre HA.

    Sincronización de cuenta en las instalaciones de SSM durante conmutación por fallas y reserva

    Se debe configurar HA entre dos servidores en las instalaciones de SSM con la ayuda de esta guía:

    Implementar el clúster HA: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    En esta demostración, utilice:

    .5 - Dirección IP del servidor principal

    .10 - Dirección IP del servidor secundario

    .12 - Dirección IP virtual

    Alta disponibilidad

    1. La configuración correcta de HA muestra el servidor primario (.5) como activo, servidor secundario (.10) como en espera y VIP (.12) sd que se muestra en la imagen.

    2. La sincronización de SSM en las instalaciones con Cisco Software Central se ha completado correctamente desde el servidor primario/activo, como se muestra en la imagen.

    3. El estado HA del clúster muestra que la base de datos del servidor primario (Replication Master) a la izquierda se replica a la base de datos del servidor secundario (Replication Slave) a la derecha, como se espera en la imagen.

    Failover

    1. Detención del clúster HA en el servidor primario como se muestra en la imagen.

    2. Primario|Secundario como se muestra en la imagen.

    3. Se ha conectado a la GUI en las instalaciones de SSM con el uso de VIP y la GUI principal está inactiva.

    4. El servidor secundario (.10) se muestra como servidor activo.

    5. El latido se desconecta.

    6. El servidor principal (.5) se ha movido al estado En espera.

    7. La sincronización de la cuenta en las instalaciones de SSM con Cisco Software Central se puede ver correctamente desde la GUI del servidor secundario/activo, como se muestra en la imagen.

    8. Iniciando el clúster HA en el servidor primario como se muestra en la imagen.

    9. El estado del clúster de HA muestra que la base de datos principal se replica desde la base de datos secundaria.

    10. Primario|Secundario como se muestra en la imagen.

    11. La GUI muestra el latido como conectado, Secundario en estado Activo y Primario en estado En espera como se muestra en la imagen.

    12. Cree una nueva cuenta TEST y actívela en Active standby. (.10).

    13. En esta etapa no se podrá acceder a la GUI principal (.5).

    Reserva

    1. Detener Ha_cluster en Secundario como se muestra en la imagen.

    2. El estado actual de la base de datos del servidor primario y de la base de datos del servidor secundario se puede ver aquí.

    3. Se ha conectado a la GUI en las instalaciones de SSM con el uso de VIP y la GUI secundaria está inactiva.

    4. El servidor principal (.5) se muestra como servidor activo.

    5. El latido se desconecta.

    6. El servidor secundario (.5) pasó al estado En espera.

    7. La cuenta TEST creada recientemente se puede ver en estado sincronizado como la replicación ocurrió desde la base de datos secundaria a la principal, como se muestra en la imagen.

    8. Se podrá acceder a la GUI desde la dirección VIP (.12) en esta etapa y no desde la dirección IP secundaria.

    9. Inicio del clúster HA en el servidor secundario como se muestra en la imagen.

    10. El estado HA del clúster muestra que la base de datos del servidor primario (Replication Master) a la izquierda se está replicando a la base de datos del servidor secundario (Replication Slave) a la derecha como se esperaba, como se muestra en la imagen.

    11. La GUI muestra Heartbeat conectado entre el servidor primario activo y el servidor secundario en espera.

    12. La cuenta TEST se sincroniza correctamente con Cisco Software Central.

    Registro de instancia de producto con SSM On-Prem VIP durante la conmutación por fallas y la reserva

    Se debe configurar la alta disponibilidad entre dos servidores en las instalaciones de SSM mediante esta guía:

    Implementación del clúster HA: https://www.cisco.com/web/software/286285517/152313/Smart_Software_Manager_On-Prem_8-202006_Installation_Guide.pdf

    En esta demostración, utilice:

    .11 - Dirección IP del servidor principal

    .9 - Dirección IP del servidor secundario

    .14 - Dirección IP virtual

    Alta disponibilidad

    1. Configuración correcta de HA que muestra el servidor primario (.11) como activo, servidor secundario (.9) como en espera y VIP (.14).

    2. El estado HA del clúster muestra que la base de datos del servidor primario (Replication Master) a la izquierda se replica a la base de datos del servidor secundario (Replication Slave) a la derecha, como se espera en la imagen.

    3. Cuando SSM On-Prem se implementa como un clúster HA, inicie sesión en SSM On-Prem Administration Workspace, navegue hasta Security > Certificates y utilice la dirección IP virtual en Host Common Name.

    4. Este valor debe coincidir con el valor que planea utilizar para la URL de destino del producto. Si implementa una pila doble (tanto IPv4 como IPv6), este valor debe ser un FQDN y no una dirección IP.

    5. Después de actualizar el nombre común del host, asegúrese de que los certificados se regeneran con el nuevo nombre común sincronizando las cuentas locales con Cisco Smart Software Manager.

    6. Debe sincronizar antes de intentar volver a registrar los productos con el nuevo nombre común en la configuración de URL de destino.

    7. Si no se sincroniza, los productos no se pueden registrar con el nuevo nombre común de host.

    8. Dos instancias del producto (annanr-39) y (cucmpub) se registran en la dirección VIP de SSM On-Prem, como se ve en la pestaña Instancias del producto.

    9. La licencia consumida/solicitada por estas instancias del producto se refleja en la pestaña Licencia.

    Failover

    1. Detención del clúster HA en el servidor primario como se muestra en la imagen.

    2. Inició sesión en la GUI de SSM in situ con el uso de VIP (.14) y la GUI principal está inactiva.

    3. El servidor secundario (.9) se muestra como servidor activo.

    4. El latido se desconecta.

    5. El servidor primario (.11) se mueve al estado En espera.

    6. Registro de instancias de productos con el uso de SSM On-Prem VIP en la URL de registro de productos en la configuración Transport Gateway, como se muestra en la imagen.

    7. Nombre de la instancia del producto: pi37 se ha registrado correctamente con SSM On-Prem con el uso de una dirección VIP como se muestra en la imagen.

    8. Registro de otras instancias de productos con el uso de SSM On-Prem VIP en la URL de registro de productos en el parámetro Transport Gateway.

    9. Registro del producto completado correctamente con SSM On-Prem usando una dirección VIP como se muestra en la imagen.

    10. Nombre de la instancia del producto: cucm-pub-30 se ha registrado correctamente con SSM On-Prem con el uso de una dirección VIP como se muestra en la imagen.

    11. Se registran dos nuevas instancias de productos (pi37) y (cucm-pub-30) en la dirección VIP de SSM On-Prem como se ve en la pestaña Instancias de producto.

    12. La licencia consumida/solicitada por estas instancias del producto se refleja en la pestaña Licencia.

    13. Inicio del clúster HA en el servidor primario.

    14. El estado del clúster de HA muestra que la base de datos principal se replica desde la base de datos secundaria.

    15. Primario|Secundario como se muestra en la imagen.

    16. La GUI muestra el latido como conectado, Secundario en estado Activo y Primario en estado En espera como se muestra en la imagen.

    Reserva

    1. Deteniendo Ha_cluster en secundario.

    2. Se puede ver el estado actual de la base de datos del servidor primario y de la base de datos del servidor secundario.

    3. Inició sesión en la GUI en las instalaciones de SSM con VIP (.14) y la GUI secundaria está inactiva.

    4. El servidor principal (.11) se muestra como servidor activo.

    5. El latido se desconecta.

    6. El servidor secundario (.9) pasó al estado En espera.

    7. Se podrá acceder a la GUI desde la dirección VIP (.14) en esta etapa y no desde la dirección IP secundaria.

    8. Inicio del clúster HA en el servidor secundario.

    9. El estado HA del clúster muestra que la base de datos del servidor primario (Replication Master) a la izquierda se replica a la base de datos del servidor secundario (Replication Slave) a la derecha como se esperaba.

    10. La GUI muestra Heartbeat conectado entre el servidor primario activo y el servidor secundario en espera.

    11. Las cuatro instancias de producto registradas en la dirección VIP de SSM On-Prem como se ve en la pestaña Instancias de producto.

    12. La licencia consumida/solicitada por estas instancias del producto se refleja en la pestaña Licencia.

    Reducir un clúster de alta disponibilidad

    1. Un clúster in situ de Cisco Smart Manager se puede degradar directamente a un solo nodo independiente.
    2. Utilice la consola en las instalaciones para conectarse al SSM principal/activo en las instalaciones con el comando <ha_teardown>.
    3. Después de verificar la operación de SSM On-Prem, el servidor secundario/en espera se debe descartar y no se puede reutilizar.
    4. Ahora tendrá un sistema independiente en lugar de un clúster.
    5. La eliminación se ha iniciado como se muestra en la imagen.

    6. Desencadenando la desactivación en el servidor secundario como se muestra en la imagen.

    7. El clúster de HA ha sido destruido. SSMS está ahora en modo autónomo.

    8. La GUI a la que se accede con el uso de la dirección IP del servidor secundario ya no nieva el widget de alta disponibilidad.

    9. Desencadenando la desactivación en el servidor primario como se muestra en la imagen.

    10. HA se ha inhabilitado correctamente.

    11. La GUI a la que se accede con el uso de la dirección IP del servidor principal ya no nieva el widget de alta disponibilidad.

    ¡¿Qué sigue?!

    1. Inicie sesión en SSM On-Prem Primary Administration Workspace, navegue hasta Security > Certificates y utilice el servidor primario (dirección IP/nombre de host/FQDN) en Host Common Name.

    2. Después de actualizar el nombre común de host, asegúrese de que los certificados se regeneran con el nuevo nombre común sincronizando las cuentas locales con Cisco SSM.

    3. Debe sincronizar antes de intentar volver a registrar los productos con el nuevo nombre común en la configuración de URL de destino.

    4. Si no se sincroniza, los productos no se pueden registrar con el nuevo nombre común de host.

    Información Relacionada

    TAC Authored

    Con la colaboración de ingenieros de Cisco

    • Annangarachari R
      Cisco TAC Engineer

    ¿Resultó útil este documento?

    FeedbackComentarios

    Contacte a Cisco

    Este documento se aplica a estos productos