Como parte de las pruebas de alta disponibilidad de un clúster basado en Grid Infrastructure (habitualmente un clúster de base de datos RAC), debemos validar que los posibles fallos de infraestructura se comportan según lo esperado por el diseño de nuestra solución. Entre estos escenarios, los fallos hardware en general y los problemas de conectividad de IO y red en particular, son los que requieren de un especial esfuerzo debido a la necesidad de cooperación entre diferentes equipos, que suelen ser los DBAs, los administradores de sistemas y los administradores de red.

Cuando desplegamos un clúster extendido, una de las pruebas que debemos llevar a cabo es la de verificar el comportamiento en el caso de producirse un split brain debido a la pérdida de conectividad entre CPDs. Una solución habitual en estas configuraciones es la de emplear una o más conexiones entre CPDs a través de las que se canalizan tanto las redes de comunicación como las redes SAN, por ejemplo, mediante enlaces DWDM. Un corte en esta conexión puede por lo tanto implicar un corte simultáneo de acceso tanto a la red (pública y privada), como al disco. El clúster debe tener capacidad para sobrevivir a esta incidencia, pero ¿cómo probar este escenario de fallo minimizando el impacto en la configuración de un entorno de producción?

Coste de pruebas

Probar un escenario real de split brain real entre dos sites de una organización, puede colisionar con limitaciones a la hora de aislar el hardware afectado exclusivamente a nuestros equipos sin afectar a otros sistemas de producción. En caso de que la prueba no sea satisfactoria, será preciso aplicar ajustes y repetirla. Si las cosas se tuercen y nos encontramos con un problema que requiera la intervención de soporte Oracle para la resolución de un SR (bug!), la cantidad de pruebas a realizar puede ser inviable por su impacto, complicando mucho la validación o resolución de los problemas, y pudiendo producir retrasos importantes en las fechas de ejecución de un proyecto.

Escacha

Para preparar y simplificar la ejecución de pruebas de split entre CPDs, podemos emplear la herramienta escacha, creada ad-hoc por Arumel para salvar los inconvenientes de la repetición de pruebas en un escenario en el que el comportamiento de un clúster ante un split brain no correspondía al esperado. Ante las implicaciones de hacer un corte real y la limitación en tiempo para poder analizar el comportamiento antes de recuperar el corte, desarrollamos este shell script que simula a nivel de red y/o de disco un corte simultáneo entre los dos CPDs.

La herramienta fue desarrollada para un entorno en el que se hace uso de redundancia normal ASM para mantener una réplica de datos entre dos CPDs, cada uno con su propia cabina de almacenamiento. A nivel de SO se emplea multipath nativo en RHEL7 sobre almacenamiento iSCSI. Para simular el escenario, la herramienta puede parametrizarse para:

  • Identificar todos los discos multipath que forman parte de una cabina. Escacha será lanzado para poner todos los dispositivos de bloque de la cabina remota del nodo desde lo que se lanza en offline sin necesidad de identificar previamente dichos dispositivos.
  • Identificar las interfaces privadas de interconexión. Escacha creará reglas iptables para bloquear el tráfico con todos los nodos que se encuentren en el CPD remoto. La comunicación entre nodos del mismo CPD seguirá habilitada.

Escacha se integra con otra herramienta con scripts muy básicos, que hemos denominado arumon, que lo que hace es recoger información periódica durante el split brain con el objetivo inicial de ver en que momento se pierden funcionalidades como acceso a la BD, visibilidad de discos ASM o cuarentena de un site (en 12.2). Es una implantación para automatizar y ampliar la recogida de información que desde soporte se solicitaba para analizar la incidencia. Escacha y arumon están probadas sobre una versión 12.2 de la Grid Infrastructure, por lo que versiones diferentes podrían requerir adaptaciones en algún comando.

Acceso la escacha y arumon en github

Escacha y arumon están disponibles públicamente en github y pueden ser descargadas mediante los comandos git clone https://github.com/arumel/escacha y git clone https://github.com/arumel/arumon. Como hemos comentado, escacha es una herramienta interna de Arumel que puede resultar útil a terceros y por este motivo queremos hacerla pública, pero no cuenta con ningún tipo de soporte ni garantía, por lo que su uso debe ser hecho bajo el propio riesgo de aquel que quiera emplearla o adaptarla para su entorno. Su creación ad-hoc hace que en su actual versión no cuente con la versatilidad para adaptarse a cualquier entorno sin antes aplicar cambios al código, ni con el código más eficiente posible, pero estos cambios o mejoras pueden ser potencialmente simples de llevar a cabo para cualquier DBA o administrador de sistemas que lo necesite. Es muy importante tener en cuenta que en modo real escacha cortará el acceso a discos y red como si se tratara de un split real, con el correspondiente impacto que esto puede tener si se ejecuta en servidores incorrectos, por lo que debe ser ejecutado con precaución, especialmente si se hace a través de un playbook de Ansible contra un grupo de servidores.

Por último, aunque el uso de escacha pueda ser útil para validar un entorno, es muy recomendable llevar a cabo las pruebas reales de split. Escacha permite reducir el impacto de dichas pruebas permitiendo la repetición sin interferencia en otros sistemas, por lo que se recomienda emplear como herramienta de test previo a un corte real que valide los resultados obtenidos.

Créditos

Imaxe: Olalla Núñez. “Atrapadas”

Revisión: Alicia Constela

A %d blogueros les gusta esto: