BACKGROUND IMAGE: iSTOCK/GETTY IMAGES

Este contenido es parte de Guía Esencial: Guía esencial para que (por fin) elabore su plan de DR y BC
Gestionar Aprenda a aplicar las mejores prácticas y optimizar sus operaciones.

¿Pueden los clusters de conmutación por error ofrecer BC/DR instantánea? No tan rápido

Aunque algunos fabricantes afirman que la conmutación por error ofrece continuidad del negocio y recuperación de desastres instantáneas, el proceso de BC/DR sigue siendo un desafío.

En junio, el Centro Nacional de Huracanes de Estados Unidos anunció que la temporada 2015 de huracanes del Atlántico prometía ser una tranquila. Esa era una buena noticia, pero la no tan buena es que una combinación de proyecciones erradas y temporadas de tormentas relativamente tranquilas en 2013 y 2014 parecen haber calmado un montón de gente hacia tomar una actitud de laxitud cuando se trata de la preparación para desastres. Estoy viendo más actitudes tipo Alfred E. Neuman (ya saben, ese chico de la revista Mad que decía “¿Qué? ¿Yo, preocupado?") de lo que puedo recordar, y eso es un poco aterrador.

Para el registro, las estimaciones de la Administración Nacional Oceánica y Atmosférica (NOAA) son solo eso: estimaciones, con base en los registros anteriores del comportamiento del clima. Algunos afirman que el cambio climático está tomando su cuota en los modelos más antiguos, cambiando el nivel de energía de partículas atrapadas en la atmósfera superior. Esto puede limitar la relevancia de los eventos cíclicos –tales como El Niño, cambiando la presión atmosférica y la velocidad del viento, y así sucesivamente– en la determinación de la probabilidad de tormentas. No es que la ciencia de la predicción de tormentas haya sido siempre exacta: Por ejemplo, NOAA predijo una temporada de huracanes activa en 2013 que generó prácticamente ningún tiempo severo. Y, algunas de las peores tormentas, incluyendo el huracán Andrew en 1992, ocurrieron en épocas en que la NOAA predijo una baja actividad. Sin embargo, muchas de las empresas que visito se están retirando de hacer cualquier tipo de planes de recuperación de desastres (DR) en absoluto.

Algunas empresas y gente de TI me han dicho que las mejoras tecnológicas están negando la necesidad de una planificación DR. En muchos departamentos de mainframe, el personal se está diciendo a sí mismo que ejecutar el Motor de Virtualización de IBM (TS7700) les permitirá saltar a un punto reciente RUN (Descarga de Retroceso de Cinta) para recuperar ambientes automáticamente después de un corte de luz. En otras palabras, ellos creen que es tan simple como rebobinar un proceso a un punto justo antes de producirse una interrupción y reiniciarlo desde allí. Por supuesto, leer el Redbook del producto proporciona un punto de vista muy diferente. Usted debe tener en cuenta muchos factores, además de los puntos RUN para un reinicio, y se requiere de planificación y pruebas cuidadosas para asegurarse de que tiene todo lo necesario para restaurar las operaciones. Es probable que la sobreventa de representantes agresivos de proveedores, combinada con una audición selectiva de los consumidores, cause a la gente mucho dolor, si y cuando necesiten restaurar el negocio.

El verdadero significado de la continuidad del negocio

Por supuesto, la continuidad del negocio en realidad significa algo más que fallas sobre el procesamiento de cargas de trabajo entre un par de servidores en clúster.

En el mundo x86, parece estarse desarrollando el mismo problema. Algunos discursos de marketing de hipervisor garantizan a los usuarios que "DR está muerto" y que la arquitectura HA (es decir, grupos de conmutación por error) ha eliminado la necesidad de este tipo de procesos. VMware, de hecho, ha comenzado a referirse a su configuración de clúster de conmutación por error como una función integrada de "continuidad de negocio".

Por supuesto, la continuidad del negocio en realidad significa algo más que fallas sobre el procesamiento de cargas de trabajo entre un par de servidores en clúster. De acuerdo con las normas ISO que llevan el título de "continuidad del negocio," la actividad tiene como objetivo recuperar no solo la infraestructura de tecnología y datos, sino también los procesos de negocio, el personal y las instalaciones de los lugares de trabajo, como consecuencia de un evento de interrupción no planificada. Compadezco al tonto que cree que la agrupación de servidores de conmutación por error significa lo mismo que la continuidad del negocio en el sentido de la norma ISO, especialmente si el cumplimiento de la norma ISO se utiliza para satisfacer los requisitos de cumplimiento legal o regulatorio.

Permítanme ir al punto más directamente. La pérdida catastrófica de datos que se requiere para la preservación bajo, digamos, el Acta de Responsabilidad y Portabilidad de Seguros de Salud (HIPAA) muy bien podría crear una calamidad doble para una empresa médica. En primer lugar, por supuesto, los costos operativos serían enormes conforme la pérdida de datos podría poner en peligro el cuidado de la salud de los pacientes. Además, también podría haber ramificaciones legales adicionales si la empresa ha afirmado conformidad con el estándar ISO 22301 sobre  continuidad de negocios, y la "conformidad" se basaba en realidad en un proveedor de hipervisor que marcaba su modelo de servidor de conmutación por error como "continuidad de negocios instantánea”.

Por qué es importante la planificación de recuperación de desastres

Mire, sé que nadie quiere hacer la planificación de recuperación de desastres. Además, los grandes desastres de humo y escombros, como los huracanes, han representado tradicionalmente solo alrededor del 5% del tiempo de inactividad en TI. La parte del león de las interrupciones resulta de una combinación de tiempo de inactividad planificado, fallos de software, fallos de hardware, errores del usuario, malware y virus. Por lo tanto, algún tipo de conmutación por error (con la replicación de datos continua) puede ayudar a las empresas a continuar las operaciones con éxito contra el telón de fondo del 95% de los problemas que pueden resultar en tiempo de inactividad.

Pero esa no es continuidad del negocio o recuperación de desastres; es prevención de desastres. Una capacidad importante también, pero no es lo mismo. Los planificadores de DR y BC tienen que considerar las interrupciones insuperables o inevitables que eliminan el proceso de negocio. Usted necesita considerar cómo se reanudarán las operaciones fuera del perímetro de sus instalaciones en caso de que el acceso de usuario a los sistemas y datos se corte, independientemente de la causa.

En primer lugar, usted necesita construir una infraestructura de datos que sea verdaderamente disponible, y cuya disponibilidad pueda ser probada y validada ad hoc. La replicación de datos y la oración no son suficientes. Es necesario verificar los espejos y las réplicas, para asegurar que los datos correctos se están replicando de forma continua y que la réplica se está almacenando en una ubicación fuera del sitio a distancia suficiente para evitar ser afectados por cualquier desastre que pueda poner en peligro el original.

Eso es algo que muchas empresas no hacen. Duplicar datos entre el almacenamiento de conexión directa detrás de un par de servidores en clúster, o incluso entre un par de servidores locales y un clúster remoto que está fuera de la sede, no es suficiente. Es necesario analizar y descubrir todos los datos, tanto los datos de aplicaciones y los archivos de soporte (incluyendo el software del hipervisor, los drivers, etc.) que serán necesarios para volver a crear las instancias de las cargas de trabajo en un host alternativo. Luego hay que determinar dónde se encuentran físicamente ubicados los clústers de recuperación de destino, y es necesario comprender el impacto que la latencia inducida por la distancia y las variaciones de la red pueden tener sobre la actualidad y la validez de la copia de datos que está haciendo. Esto último requiere romper el proceso de espejo y comprobar la consistencia de los conjuntos de datos locales y remotos (copiados) de forma  bastante frecuente.

Mantenga la cabeza en las nubes

Si su destino de respaldo es una "nube", necesita saber donde está localizado físicamente ese servicio. Una nube puede estar ofreciendo los acuerdos de nivel de servicio (SLA) más altos para la recuperación de desastres, pero la distancia tendrá mucho que ver con la capacidad del proveedor para cumplirlos.

Por un lado, si se accede a la DRaaS a través de una red de área metropolitana como SONET o MPLS, pregúntese si es suficiente distancia para evitar ser destruidos por el mismo desastre que le golpea, ya sea un corte de energía en toda la ciudad o un huracán con un radio de daños de 100 kilómetros o más. Sus datos no estarán seguros si el proveedor de DRaaS está en el edificio de enfrente.

Por otro lado, si el servicio en la nube está muy distante y se accede a través de una red de área amplia (WAN), puede o no ser adecuado para la replicación de datos transaccionales que son sensibles a "deltas" o diferencias introducidas por la latencia. Esto va para los escenarios de conmutación por error simples, así como para modelos de conmutación por error más complejos que involucran sistemas interdependientes.

En todos los casos, se requieren pruebas. Así que su estrategia debería valerse tanto de pruebas  programadas como de pruebas ad hoc. Muchos de los llamados servicios DRaaS son realmente "DR en el último momento”, proveedores de servicios de hosting que están ofreciendo DR como una opción de menú adicional sin entender realmente lo que conlleva. Hay muchos proveedores de software ahora mismo que están desarrollando menús de front-end “a prueba de baba" para el software de respaldo o espejo, los cuales se pueden presentar a los usuarios a través de una interfaz de nube. Solo hacer al complejo software de protección de datos disponible a través de una interfaz web, no significa que el vendedor sabe nada en absoluto acerca de la disciplina real de la planificación de DR/BC o que puede hacer un buen trabajo al entregar una capacidad de continuidad válida.

En pocas palabras, la planificación de DR/BC planificación sigue siendo una tarea difícil que las empresas deben realizar si quieren sobrevivir a los eventos de interrupción que pueden representar solo el 5% de las interrupciones, pero el 100% de los desastres financieros. Usted no debe engañarse a sí mismo acerca de probabilidades o frecuencias de los eventos de desastre. Prepárese para el 5% y también será capaz de hacer frente al otro 95%.

Sobre el autor: Jon William Toigo es un veterano de TI de 30 años, director general y director administrativo de Toigo Partners International, y presidente del Instituto de Gestión de Datos.

Próximos pasos

Tómese un tiempo para revisar también:

Mejores prácticas de prevención de pérdida de datos para mejorar BC y DR

¿Qué le ofrece a DR el software de respaldo de código abierto?

Con un plan de pruebas de DR, falle en planear y planee fallar

Este artículo se actualizó por última vez en diciembre 2015

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close