{"id":8573,"date":"2017-11-13T19:45:22","date_gmt":"2017-11-13T18:45:22","guid":{"rendered":"http:\/\/arumel.com\/?p=8573"},"modified":"2018-01-04T19:02:43","modified_gmt":"2018-01-04T18:02:43","slug":"escacha-simulador-de-split-brain-grid-infrastructure-cluster-extendido","status":"publish","type":"post","link":"https:\/\/arumel.com\/ca\/escacha-simulador-de-split-brain-grid-infrastructure-cluster-extendido\/","title":{"rendered":"Escacha – Simulador de split brain para Grid Infrastructure en un cl\u00faster extendido"},"content":{"rendered":"

Como parte de las pruebas de alta disponibilidad de un cl\u00faster basado en Grid Infrastructure (habitualmente un cl\u00faster de base de datos RAC), debemos validar que los posibles fallos de infraestructura se comportan seg\u00fan lo esperado por el dise\u00f1o de nuestra soluci\u00f3n. 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\u00f3n entre diferentes equipos, que suelen ser los DBAs, los administradores de sistemas y los administradores de red.<\/p>\n

Cuando desplegamos un cl\u00faster 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\u00e9rdida de conectividad entre CPDs. Una soluci\u00f3n habitual en estas configuraciones es la de emplear una o m\u00e1s conexiones entre CPDs a trav\u00e9s de las que se canalizan tanto las redes de comunicaci\u00f3n como las redes SAN, por ejemplo, mediante enlaces DWDM. Un corte en esta conexi\u00f3n puede por lo tanto implicar un corte simult\u00e1neo de acceso tanto a la red (p\u00fablica y privada), como al disco. El cl\u00faster debe tener capacidad para sobrevivir a esta incidencia, pero \u00bfc\u00f3mo probar este escenario de fallo minimizando el impacto en la configuraci\u00f3n de un entorno de producci\u00f3n?<\/p>\n

Coste de pruebas<\/span><\/h1>\n

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

Escacha<\/span><\/h1>\n

Para preparar y simplificar la ejecuci\u00f3n de pruebas de split entre CPDs, podemos emplear la herramienta escacha<\/strong>, creada ad-hoc por Arumel para salvar los inconvenientes de la repetici\u00f3n de pruebas en un escenario en el que el comportamiento de un cl\u00faster ante un split brain no correspond\u00eda al esperado. Ante las implicaciones de hacer un corte real y la limitaci\u00f3n 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\u00e1neo entre los dos CPDs.<\/p>\n

La herramienta fue desarrollada para un entorno en el que se hace uso de redundancia normal ASM para mantener una r\u00e9plica 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:<\/p>\n