Como parte das probas de alta dispoñibilidade dun clúster baseado en Grid Infrastructure (habitualmente un clúster de base de datos RAC), debemos validar que os posibles fallos de infraestrutura se comportan segundo o esperado polo deseño da nosa solución. Entre estes escenarios, os fallos hardware en xeral e os problemas de conectividade de IO e rede en particular, son os que requiren dun especial esforzo debido á necesidade de cooperación entre diferentes grupos, que soen ser os DBAs, os administradores de sistemas e os administradores de rede.

Cando despregamos un clúster estendido, unha das probas que debemos levar a cabo é a de verificar o comportamento no caso de producirse un split brain debido á perda de conectividade entre CPDs. É unha solución habitual empregar unha ou máis conexións entre CPDs a través das que se canalizan tanto as redes de comunicación como as redes SAN, por exemplo, mediante enlaces DWDM. Un corte nesta conexión pode implicar un corte simultáneo de acceso tanto a rede (pública e privada), como a disco. O clúster debe ter capacidade para sobrevivir a esta incidencia, pero como probar este escenario de fallo minimizando o impacto na configuración dun contorno de produción?

Custo de probas

Probar un escenario real de split brain real entre dous sites dunha organización, pode colisionar coa limitación á hora de illar o hardware afectado ós nosos equipos sen afectar a outros sistemas en produción. En caso de que a proba non sexa satisfactoria, será preciso aplicar axustes e repetila. Se as cousas se torcen e topamos cun problema que requira a intervención de soporte Oracle para a resolución dun SR (bug!), a cantidade de probas a facer pode ser inviable de levar a cabo polo seu impacto, complicando moito a validación ou resolución dos problemas, e producindo retrasos importantes nas datas de execución dun proxecto.

Escacha

Para preparar e simplificar a execución de probas de split entre CPDs, podemos empregar a ferramenta escacha, creada ad-hoc por Arumel para salvar os inconvintes de repetición de probas nun escenario no que o comportamento dun clúster ante un split brain non correspondía ó esperado. Ante as implicacións de facer un corte real e a limitación en tempo para poder analizar o comportamento antes de recuperar o corte, preparamos este shell script que simula a nivel de rede e/ou de disco un corte simultáneo entre os dous CPDs.

A ferramenta foi desenvolvida para un contorno no que se fai emprego de redundancia normal ASM para manter unha réplica de datos entre dous CPDs, cada un coa súa propia cabina de almacenamento. A nivel de SO emprégase multipath nativo en RHEL7. Para simular o escenario, a ferramenta pódese parametrizar para:

  • Identificar tódolos discos multipath que forman parte dunha cabina. Con elo escacha será lanzado para poñer tódolos dispositivos de bloque da cabina remota do nodo dende o que se lanza en offline.
  • Identificar as interfaces privadas de interconexión. Escacha empregará regras iptables para bloquear o tráfico con tódolos nodos que se atopen no CPD remoto. A comunicación entre nodos do mesmo CPD seguirá habilitada.

Escacha intégrase con outra ferramenta con scripts moi básicos, denominada arumon, que o que fai é recoller información periódica durante o split brain co obxectivo inicial de ver en que momento se perden funcionalidades como acceso á BD, visibilidade de discos ASM ou corentena de un site (en 12.2). Escacha e arumon están validadas sobre unha versión 12.2 da Grid Infrastructure, polo que versións diferentes poderían requirir adaptacións nalgún comando.

Acceso a escacha e arumon en github

Escacha e arumon están dispoñibles publicamente en github e poden ser descargadas mediante o comando git clone https://github.com/arumel/escacha e git clone https://github.com/arumel/arumon. Escacha é unha ferramenta interna de Arumel que pode resultar útil a terceiros e por elo a queremos facer pública, pero non conta con ningún tipo de soporte nin garantía, polo que o seu uso debe ser feito baixo o propio risco de aquel que queira empregala ou adaptala para o seu contorno. A súa creación ad-hoc fai que na súa actual versión non conte coa versatilidade precisa para a adaptación a calquera contorno sen aplicación de cambios, nin co código mais eficiente posible, pero estes cambios ou melloras poden ser potencialmente simples de levar a cabo para calquera DBA ou administrador de sistemas que o precise. É importante ter en conta que en modo real escacha cortará o acceso a discos e rede como se se tratase dun split real, co correspondente impacto que isto pode ter se se executa en servidores incorrectos, polo que é importante a súa execución con precaución, especialmente se se fai a través dun playbook de Ansible contra un grupo de servidores.

Por último, aínda que o emprego de escacha poda ser útil, é moi recomendable levar a cabo as probas reais de split. Escacha permite reducir o impacto das mesmas permitindo a repetición sen interferir con outros sistemas, polo que debe empregarse como ferramenta de test previo a un corte real que valide os resultados obtidos.

Créditos

Imaxe: Olalla Díaz. “Atrapadas”

Revisión: Alicia Constela