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 los pasos para solucionar los problemas de actualización de la infraestructura centrada en aplicaciones (ACI) y las prácticas recomendadas que deben seguirse antes y durante el proceso de actualización.
Una actualización de ACI implica la actualización del software y los switches de Application Policy Infrastructure Controller (APIC) (hoja y columna). Una actualización del switch suele ser muy sencilla, sin embargo, una actualización de APIC podría implicar algunos problemas de clúster. Estas son algunas comprobaciones previas que Cisco recomienda preparar antes de iniciar una actualización.
Antes de iniciar la actualización de ACI, asegúrese de realizar algunas comprobaciones previas para evitar comportamientos inesperados.
Muchos fallos en el fabric ACI indican que hay políticas inválidas o conflictivas, o incluso interfaces desconectadas, etc. Entienda el disparador y borre el antes de iniciar la actualización. Tenga en cuenta los fallos, como encap already been used
or Routed port is in L2 mode
podría provocar una interrupción inesperada. Cuando actualiza el switch, descarga todas las políticas desde APIC desde cero. A consecuencia de ello, las políticas inesperadas podrían hacerse cargo de las políticas esperadas, lo que podría provocar una interrupción.
Nota: Si activa el cifrado para la copia de seguridad, asegúrese de guardar la clave de cifrado. De lo contrario, todas las contraseñas de la cuenta de usuario, incluida la contraseña admin, no se importarán correctamente.
date
para verificar la hora actual del sistema. Ahora ingrese el comando grep "ipmi" /var/log/dme/log/svc_ifc_ae.bin.log | tail -5
y verifique la última vez que el proceso AE consultó el IPMI. Compare el tiempo con el tiempo del sistema para verificar si la última consulta estuvo dentro de la ventana de 10 segundos del tiempo del sistema. Nota: No reinicie dos o más APIC al mismo tiempo para evitar cualquier problema de clúster.
acidiag avread | grep id= | cut -d ' ' -f 9,10,20,26,46
desde cualquier CLI APIC para verificar el estado de estado de APIC. Si la puntuación de estado no es 255 para ningún APIC, no inicie la actualización. Comience siempre a resolver problemas de APIC1 si la actualización se atasca o falla. Si la actualización de APIC1 aún no ha finalizado, no haga nada en APIC2 y APIC3. El proceso de actualización de APIC es incremental y, por lo tanto, APIC2 se actualizará sólo después de que APIC1 complete la actualización y notifique al APIC2 sobre ello, etc. Por lo tanto, la violación de esto podría poner el clúster en un estado dañado con una base de datos dañada y podría ser necesario que reconstruyera el clúster.
En esta situación, verá que APIC1 se actualiza correctamente, pero APIC2 sigue estancado en un 75%. Este problema ocurre si la información de la versión de actualización APIC1 no se propaga a APIC2 o posterior. Tenga en cuenta que svc_ifc_appliance_director
está a cargo de la sincronización de la versión entre los APIC.
Paso 1: Asegúrese de que APIC1 pueda hacer ping al resto de los APIC con su dirección IP de punto final del túnel (TEP), ya que esto determinará si necesita resolver problemas desde el switch de hoja o continuar desde el APIC. Si APIC1 no puede hacer ping con APIC2, es posible que desee llamar al Technical Assistance Center (TAC) para resolver problemas del switch. Si APIC1 puede hacer ping con APIC2, continúe con el segundo paso.
Paso 2: Dado que los APIC pueden hacer ping entre sí, la información de la versión APIC1 se debería haber replicado al par, pero de alguna manera no fue aceptada por el par. La información de la versión se identifica mediante una marca de tiempo de la versión. Puede confirmar el sello de fecha y hora de la versión de APIC1 desde la CLI y la CLI de APIC2, que espera un 75%.
En APIC1
apic1# acidiag avread | grep id=1 | cut -d ' ' -f20-21
version=2.0(2f) lm(t):1(2018-07-25T18:01:04.907+11:00)
En APIC2
apic2# acidiag avread | grep id=1 | cut -d ' ' -f20-21
version=2.0(1m) lm(t):1(2018-07-25T18:20:04.907+11:00)
Como puede ver, la marca de tiempo de la versión de APIC2 (18:20:04) que ejecuta la versión 2.0(1m) en este ejemplo es mayor que la marca de tiempo de la versión de APIC1(18:01:04) que ejecuta la versión 2.0(2f). Por lo tanto, el proceso de instalación de APIC2 considera que la actualización de APIC1 aún no se ha completado y espera un 75%. La actualización de APIC2 se iniciará cuando la marca de tiempo de la versión de APIC1 supere la marca de hora de la versión de APIC2. Sin embargo, esto podría ser mucho esperar en función de la diferencia de tiempo. Para recuperar el fabric de este estado, puede abrir un caso del TAC para obtener ayuda para resolver problemas y solucionar el problema de APIC1.