El tratamiento del APD en vSphere 5.x

Como ya dicho en los últimos posts, una de las mejorias que hizo VMware fue en el tratamiento de APD (all paths down). Pueden preguntarse porque hablo bastante de eso, y en resumen es que genera tantos problemas, y su solución es tan difícil, que realmente es muy gratificante ver la importancia que VMware dio a ese problema. Esto afecta directamente la estabilidad del producto.

El APD ocurre cuando un dispositivo es removido del ESX de un modo inesperado, sea por alguna tarea administrativa, sea por un problema de hardware. Es lo mismo que tener un disco en un servidor Linux/Windows y sacarlo sin más ni menos, esperando que nada pase – dependiendo del contenido del disco, de que estaba siendo accedido, de que aplicaciones dependen de el, el resultado puede ser catastrofico. Generalmente, cuando un ESX está accediendo un dispositivo externo, poseé más de un camino hacia el, por lo cual perder un camino o algunos no debería generar problemas, pero perder todos los caminos sí es un grande inconveniente – por la naturaleza de multiples caminos, de recuperación, de alta disponibilidad, es que el ESX entra en el estado de APD.

El gran problema con el APD está en los resultados directos sobre el hostd – el agente que se comunica con el gerenciamiento del ESX, y es responsable por contestar las llamadas en los puertos 902 y 443 del mismo, o sea, es la puerta de entrada al control del ESX. El hostd tiene threads que, en caso de un APD, iran esperar indefinidamente para que el I/O sea restablecido, y el hostd solo puede tener un número finito de threads. Como consecuencia principal, el ESX entra en el modo “disconnected” del vCenter (a veces tampoco es posible accederlo directamente por client). No se pueden gerenciar VMs, apagarlas, prenderlas, moverlas, nada. Y para salir del estado de APD, dependiendo de la versión del ESX y el estado de la conectividad, es imposible. Un reboot del host generalmente es necesario, llevando juntamente todas las VMs prendidas en el.

Para corregir eso, un nuevo estado de device fue introducido en el vSphere 5.0: el PDL (permanent device loss). Este estado es configurado en un device cuando se sabe que el mismo no mas va a volver. Para eso, el ESX depende que el storage envie los “sense codes” correctamente, avisando que el device no más está presente, evitando que el ESX siga intentando conectar o siga esperando el mismo. La KB http://kb.vmware.com/kb/2004684 de VMware especifica exactamente cuales son estos codes.

En el vSphere 5.1, lo que se quiere ahora es poder detectar estados de PDL mas transientes, no tan explicitos, y evitar que el hostd se quede esperando indefinidamente I/O’s, y también evitar que el problema ocurra en storages que tienen solo un path por target (por ejemplo, el Equallogic) ya que, en caso de pérdida de comunicación con un device, el camino también se fue. Ya en el vSphere 5.0 U1, fue introducida una mejoria de detección de PDL, que se integra con el HA para apagar una VM en un ESX que tenga una LUN en este estado para prenderla en otro que no lo tenga, si posible.

Algunas nuevas configuraciones fueron introducidas para evitar que el hostd entre en un estado irrecuperable:

  • Misc.APDHandlingEnable: esta seteadoen 1 por default, que quiere decir que utilize el nuevo tratamiento de APD/PDL de vSphere 5.1. Si tiene el valor de 0, el comportamiento es el mismo de las versiones 5.0 y anteriores.
  • Misc.APDTimeout: con default en 140, son los segundos que el ESX espera hasta marcar la LUN en APD como APD Timeout. Todos los IOs enviados a esta LUN fallan con el status NO_CONNECT, como si no hubieran cables conectados, pero solamente a esta LUN. SI alguno de los paths a la LUN vuelve, la misma automaticamente sale de APD y los IOs vuelven a ser enviados normalmente.
  • LUNs con path único (single path single target): LUNs de arrays como, por ejemplo, el Equallogic, tiene un solo path, ya que a cada LUN el storage presenta un nuevo target al ESX (el multipathing lo hace en el lado del storage, y no lo maneja el ESX). En estos casos, el ESX va intentar loguear de nuevo al initiator iSCSI – dependiendo de la señal recibida de vuelta, el estado del path puede configurarse como PDL.

Configurando APD en vSphere 5.1. Thanks to Duncan Epping for the image (www.yellow-bricks.com)

Estaré posteando más informaciones así que tenga en manos más problemas prácticos y sus resoluciones. También está bueno ver que VMware está activamente trabajando para solucionar problemas graves como estos.

Abrazo!

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s