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.
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).
Este documento describe cómo se diseñan los clústeres de Expressway para ampliar la resistencia y la capacidad de una instalación de Expressway.
Capacidad. El clúster de Expressway puede aumentar la capacidad de una implementación de Expressway en un factor máximo de cuatro, en comparación con un solo Expressway. Los peers de Expressway en un clúster comparten el uso del ancho de banda, así como el enrutamiento, la zona, FindMe y otras configuraciones.
Resistencia. El clúster de Expressway puede proporcionar redundancia mientras Expressway se encuentra en modo de mantenimiento, o en caso de que se vuelva inaccesible debido a una interrupción de la red o de la alimentación, o a otro motivo. Los terminales pueden registrarse en cualquiera de los pares de un clúster. Si los terminales pierden la conexión con su par inicial, pueden volver a registrarse en otro en el clúster.
Expressway puede formar parte de un clúster de hasta seis Expressway. Al crear un clúster, se nombra a un par como el principal, desde el cual su configuración se replica a los otros pares. Todos los pares de Expressway en el clúster deben tener las mismas capacidades de routing. Si algún Expressway puede rutear una llamada a un destino, se supone que todos los peers de Expressway en ese clúster pueden rutear una llamada a ese destino.
No hay aumento de capacidad después de cuatro peers. Por ejemplo, en un clúster de seis pares, Expressway quinto y sexto no agregan capacidad de llamada adicional al clúster. La resistencia mejora con los pares adicionales, pero no con la capacidad.
Todas las demás claves de licencia deben ser idénticas en cada par.
Nota: Si Expressway-E utiliza un único controlador de interfaz de red (NIC), debe utilizar IP pública. Si Expressway-E utiliza NIC dual, la interfaz interna debe utilizarse para generar el clúster.
Nota: Debe crear un clúster de un peer (primario) primero y reiniciar el primario, antes de agregar otros peers. Puede agregar más peers después de haber establecido un clúster de uno.
Configuración principal: 1
Versión IP del clúster: Elija IPv4 o IPv6 para coincidir con el esquema de direcciones de red.
Opciones del modo de verificación TLS: Permiso (predeterminado) o Aplicación.
Permisivo significa que los pares no validan los certificados de los demás cuando se establecen las conexiones de seguridad de la capa de transporte (TLS) dentro del clúster.
La aplicación es más segura, pero requiere que cada par tenga un certificado válido y que todos los demás pares confíen en la Autoridad de Certificación (CA).
Dirección del par 1: Introduzca la dirección de Expressway (el par principal). Si el modo de verificación de TLS está establecido en Aplicar, debe introducir un nombre de dominio completo (FQDN) que coincida con el asunto Nombre común (CN) o un nombre alternativo de asunto (SAN) en el certificado de este par.
Para agregar un peer adicional, siga los siguientes pasos:
Precaución: Antes de continuar, verifique que sus SAN de certificado contengan los FQDN que se encuentran en los campos de dirección del par N. Debe ver mensajes de estado verdes para la agrupación en clúster y el certificado junto a cada campo de dirección antes de continuar.
Precaución: Se muestra una advertencia si algún certificado no es válido y evita que el clúster funcione correctamente en el modo de verificación TLS forzada.
Nota: Puede realizar este proceso incluso si el par primario actual no está accesible.
Nota: Mientras se lleva a cabo este proceso, ignore cualquier alarma en Expressway que informe de discordancia primaria del clúster o error de replicación del clúster.
Nota: Mientras se realiza este procedimiento, las comunicaciones entre pares se ven temporalmente afectadas, lo que significa que se espera ver alarmas que persisten hasta que se completen los cambios y el clúster acuerde las nuevas direcciones.
Para implementaciones seguras como Mobile and Remote Access (MRA), cada par de Expressway-E debe tener un certificado con una SAN que contenga su FQDN público. El FQDN se asigna en el DNS público a la dirección IP pública de Expressway-E.
Nota: Si simplemente desea agrupar en clúster los pares de Cisco Expressway-E y no necesita la verificación de TLS entre ellos, puede formar el clúster con las direcciones IP privadas de los nodos. No necesita el mapeo de direcciones de clúster.
Las asignaciones de direcciones de clúster son pares FQDN:IP que se comparten alrededor del clúster, un par por cada par. Los pares consultan la Tabla de mapeo antes de consultar DNS y, si encuentran una coincidencia, no consultan DNS.
Si decide aplicar TLS, los pares también deben leer los nombres del campo SAN de los certificados de los demás y comprobar cada nombre en el lado FQDN de la asignación.
Se recomienda encarecidamente que introduzca las asignaciones en el peer primario. Las asignaciones de dirección se replican dinámicamente a través del clúster. Para configurar el Mapping de Direcciones, siga el siguiente procedimiento:
Precaución: No intente utilizar el DNS público para asignar los FQDN públicos de los pares a sus direcciones IP privadas, esta acción puede interrumpir la conectividad externa.
Si desea que los pares de Expressway-E de un clúster verifiquen las identidades de cada uno con certificados, puede permitirles utilizar DNS para resolver los FQDN de peer de clúster en sus direcciones IP públicas. Esta es una forma perfectamente aceptable de formar un clúster si los nodos de Expressway-E tienen:
Si borra todos los campos de dirección de peer de la página de agrupación en clúster y guarda la configuración, Expressway realiza de forma predeterminada un reinicio de fábrica la próxima vez que realice un reinicio. Esto significa que se elimina toda la configuración, excepto la configuración de red básica para la interfaz de red de área local 1 (LAN1), que incluye toda la configuración realizada después de borrar los campos y el siguiente reinicio.
Consejo: Si necesita evitar el restablecimiento de fábrica, restaure los campos de dirección de peer del clúster. Reemplace las direcciones de peer originales en el mismo orden y, a continuación, guarde la configuración para borrar el banner.
El restablecimiento de fábrica se activa automáticamente cuando el par se reinicia para eliminar los datos confidenciales y la configuración del clúster. El reinicio borra toda la configuración excepto la siguiente información básica de red:
Nota: Si utiliza la opción NIC dual, tenga en cuenta que cualquier configuración LAN2 se elimina por completo mediante el reinicio.
Nota: Desde la versión X12.6, el restablecimiento de fábrica elimina del par el certificado del servidor, la clave privada asociada y la configuración del almacén de confianza de la CA. En las versiones anteriores del software de Expressway, estos parámetros se conservan.
El restablecimiento de fábrica puede fallar, esto puede ocurrir si Expressway es un dispositivo de virtualización abierta (OVA) de instalación reciente y no se ha actualizado.
Para corregir esto, siga cualquiera de las siguientes opciones:
Nota: Asegúrese de realizar las copias de seguridad adecuadas antes de una actualización, un cambio de certificado o cuando haya una advertencia de restablecimiento de fábrica.
Si es necesario reiniciar el clúster o cualquier peer, siga los siguientes pasos:
Nota: Es posible que deba esperar unos 5 minutos después de realizar cualquier cambio en el clúster antes de que los peers de Expressway informen del estado correcto.
Las alarmas de los errores de clúster se muestran en el formato: Error de replicación del clúster: (detalles) se requiere la sincronización manual de la configuración, algunos ejemplos de estos son los siguientes:
Si un Expressway subordinado informa de la alarma mencionada, siga el siguiente procedimiento:
Nota: Asegúrese de realizar las copias de seguridad adecuadas antes de una actualización, un cambio de certificado o cuando haya una advertencia de restablecimiento de fábrica.
Si el problema persiste, podría estar relacionado con la clave de cifrado por peer de clúster. Normalmente ocurre cuando los peers se actualizan en el orden incorrecto, los peers subordinados no se sincronizan con el primario. Por lo tanto, si xcommand force no funciona, siga el siguiente procedimiento:
La alarma de replicación se borra después de que el peer primario se haya actualizado y reiniciado. Esto suele ocurrir en los diez minutos posteriores al reinicio, pero puede ser hasta 20 minutos después del reinicio.
Configuración de clustering no válida: El modo H.323 se debe activar: la agrupación en clúster utiliza las comunicaciones H.323 entre pares.
Para borrar esta alarma, asegúrese de que el modo H.323 esté encendido, navegue hasta Configuration > Protocols > H.323.
Falla en la base de datos de Expressway: Póngase en contacto con su representante de soporte técnico de Cisco.
Para resolver este tipo de alarma, siga el siguiente procedimiento:
Un segundo método es posible si la base de datos no se recupera:
Nota: Asegúrese de realizar las copias de seguridad adecuadas antes de una actualización, un cambio de certificado o cuando haya una advertencia de restablecimiento de fábrica.
Precaución: clusterdb_detect_and_purge_data.sh es tan peligroso como suena: utilice esta opción como último recurso.
Nota: La siguiente información se aplica a la versión X14 en adelante.
No se pudo actualizar las alarmas de archivos clave en Expressway en un solo escenario de nodo.
Siga el siguiente procedimiento para resolver este tipo de alarma:
No se pudo actualizar las alarmas de archivos clave se generan en Expressway en un escenario de clúster.
Siga el siguiente procedimiento para resolver este tipo de alarma:
Al igual que cualquier otro registro en Expressway, puede habilitar los registros de diagnóstico con los vaciados de TCP.
En un estado normal, la Sincronización de la Base de Datos en el nodo Maestro se muestra en los registros como el siguiente resultado:
2020-07-21T15:16:50.321-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,321" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:50.330-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,330" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="0"
2020-07-21T15:16:50.433-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,433" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(257)" Detail="This peer is the cluster master, local configuration has already been replicated to the other peers"
2020-07-21T15:16:50.437-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,437" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"
Desde la perspectiva del nodo del par se muestra como el siguiente resultado:
2020-07-21T15:16:46.900-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,899" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:46.908-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,908" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="1"
2020-07-21T15:16:46.947-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,946" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(254)" Detail="This peer is not the cluster master, local configuration is already up to date"
2020-07-21T15:16:46.950-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,950" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"
En el siguiente resultado se muestra una Desconexión de Peer:
2020-08-12T14:57:43.353-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Processed mnesia_down event from accessible node" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="ERROR" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Inconsistent Database" Context="from mnesia system - mnesia down" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Connecting database on mnesia running_partitioned_network event" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Ready to perform node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Running node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.synchronise" Level="WARN" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Failed connecting to node" Node="clusterdb@expc02.apolo.local" Reason="{ badrpc, { EXIT, { aborted, { noproc, { gen_server, call, [ kernel_safe_sup, { start_child, { dets_sup, { dets_sup, start_link, }, permanent, 1000, supervisor, [ dets_sup ] } }, infinity ] } } } } }"
2020-08-12T14:57:43.524-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20006" UUID="0f96695e-d954-4f6f-85c1-2ef1eae6f764" Severity="warning" Detail="Cluster database communication failure: The database is unable to replicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,524"
2020-08-12T14:57:43.771-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20004" UUID="3bca6888-f622-11df-93be-07cc953d7b99" Severity="warning" Detail="Cluster communication failure: The system is unable to communicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,771"
2020-08-12T14:57:53.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:53,871" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI SeqNum=52319 Retransmit=True"
2020-08-12T14:57:54.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:54,871" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ SeqNum=52320 Retransmit=True"
2020-08-12T14:57:56.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:56,871" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ SeqNum=52320 Retransmit=True"
2020-08-12T14:57:57.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:57,871" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI SeqNum=52319 Retransmit=True"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: Event="External Server Communications Failure" Reason="gatekeeper timed out" Service="NeighbourGatekeeper" Detail="name:10.15.13.16:1719" Level="1" UTCTime="2020-08-12 19:57:58,871"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:58,871" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ SeqNum=52320 Timeout=True"
2020-08-12T14:57:59.601-05:00 expc01 UTCTime="2020-08-12 19:57:59,601" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Triggering forced peer update of peers which failed DNS and queueing next run" Queue-Time-ms="300000"
2020-08-12T14:58:01.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:58:01,871" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI SeqNum=52319 Timeout=True"
El cambio a TLS Enforce en el nodo maestro se muestra en el siguiente resultado:
2020-08-12T15:13:24.970-05:00 expc01 UTCTime="2020-08-12 20:13:24,969" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.976-05:00 expc01 UTCTime="2020-08-12 20:13:24,975" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.976-05:00 expc01 httpd[15060]: web: Event="System Configuration Changed" Detail="configuration/cluster/tls_verify - changed from: 'Permissive' to: 'Enforcing'" Src-ip="10.15.13.30" Src-port="53155" User="admin" Level="1" UTCTime="2020-08-12 20:13:24"
2020-08-12T15:13:24.979-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.980-05:00 expc01 UTCTime="2020-08-12 20:13:24,980" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.986-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,986" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.142.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.031-05:00 expc01 UTCTime="2020-08-12 20:13:25,031" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.192-05:00 expc01 management: UTCTime="2020-08-12 20:13:25,192" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.195-05:00 expc01 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,194"
Desde la perspectiva del nodo de par se muestra en el siguiente resultado:
2020-08-12T15:13:24.976-05:00 expc02 UTCTime="2020-08-12 20:13:24,976" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.390.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.979-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.982-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,982" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.041-05:00 expc02 UTCTime="2020-08-12 20:13:25,041" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.042-05:00 expc02 UTCTime="2020-08-12 20:13:25,042" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.046-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,047" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.049-05:00 expc02 UTCTime="2020-08-12 20:13:25,049" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.136-05:00 expc02 management: UTCTime="2020-08-12 20:13:25,136" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.139-05:00 expc02 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,139"
Los siguientes videos podrían ser útiles:
Creación y adición de un par a un clúster de Expressway
Remoción de un Peer de un Clúster de Expressway
Procedimiento de reinicio del clúster de Expressway
Cómo actualizar un clúster de ExpresswayGeneración de CSR para MRA/Expressway agrupadas
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
02-Jul-2021 |
Versión inicial |