Llegamos a ustedes gracias a:



Reportajes y análisis

Recuperación de desastres

¿Cómo sobrevivir a una interrupción?

[31/03/2017] Asíncrono vs síncrono. Recuperación oscura de desastres vs. arquitectura activa. Activo/activo vs. activo/pasivo. Ninguna configuración es objetivamente mejor o peor que otra. Lo mejor para usted depende principalmente de su nivel de tolerancia respecto a lo que sucede cuando el servidor cae.

Los expertos en seguridad dicen que la manera en que las compañías individuales eligen guardar sus datos en previsión de una interrupción, depende de cuánto tiempo puedan sobrevivir antes de que las "luces" se vuelvan a encender. ¿Qué nivel de disponibilidad necesita su empresa? ¿La cara de su compañía es un sitio de comercio electrónico, donde incluso unos pocos minutos sin conexión puede costarle una suma astronómica? ¿El costo de un sistema activo-activo superará la pérdida potencial del negocio tras una interrupción?

"No se trata de que uno sea más eficiente que el otro. Se trata de qué necesidades está tratando de resolver. Por ejemplo, comprar un Ferrari para hacer las compras de la casa va a funcionar, ¿pero es realmente adecuado para el propósito?", señala Don Foster, director senior de marketing de soluciones y alianzas técnicas en Commvault.

En una arquitectura activa/activa, normalmente un grupo de servidores externos se sincroniza con el servidor in situ. Esto permite que no haya tiempo de inactividad en caso de un desastre, en el que un servidor se encuentre desconectado. Se puede configurar para activar automáticamente la conmutación por error. En esta configuración, se necesita menos hardware porque todos los sistemas están siendo utilizados, en comparación a solo la mitad del hardware en un escenario de recuperación oscura de desastres. Si tuviera 48 núcleos de recuperación oscura de desastres, tendría 96 núcleos en total y utilizaría solo 48. En el modo activo/activo, se reduce a 32 x 2 para 64 núcleos, y los 64 están activos.

En un escenario oscuro de recuperación de desastres, la capacidad es un sistema totalmente redundante -todo el hardware y software listo para funcionar- pero está completamente inactivo. Esa capacidad no se utiliza para nada hasta que falla el primer sitio, pero se reproduce en determinados períodos.

Erin Swike, arquitecto senior de cloud solution en Bluelock, explica que "la recuperación de desastres activa/activa es el unicornio del mundode DR (recuperación de desastres, por sus siglas en inglés). La idea de ser capaz de dormir por la noche sabiendo que, en caso de que su sitio de producción falle, el sitio de DR comenzará automáticamente a presentar las aplicaciones a los usuarios sin un solo paquete perdido, es el nirvana de cualquier CIO o ingeniero de sistemas.

"Para la mayoría, sigue siendo cosa de cuentos de hadas y leyendas. Olvídese del factor obvio de proximidad al centro de datos y latencia de la red; uno de los factores más importantes es si sus aplicaciones están escritas para soportar este tipo de escenario. A menos que una aplicación haya sido escrita con esto en mente desde el principio, las probabilidades apuntan a que no pueda soportarlo", señala.

Los costos de software son más altos en modo activo/activo, pues cualquier sistema que se esté ejecutando en modo activo, debe tener un software con licencia. Cuando el sistema está en modo oscuro de recuperación de desastres, el segundo sistema no requiere licencias pagadas para los núcleos de base de datos, por ejemplo, ya que solo un set está activo a la vez. El hecho de que los dos sistemas se mantengan sincronizados no afecta en absoluto los costos.

En la replicación sincrónica, es necesario tener conexiones de red confiables entre los dos servidores. También hay trabajo adicional al tener que administrar otro sitio constantemente.

Lo negativo de la replicación asíncrona implica perder algunos datos entre el tiempo de inactividad y el momento en que se actualizó por última vez. Sin embargo, se puede configurar para la conmutación por error automática.

Anand Hariharan, vicepresidente de producto en Webscale Networks, comenta que esto es esencialmente el concepto de los servidores de backup fríos/tibios/calientes. Los pros y contras se dividen en dos grupos: acuerdo de nivel de servicio y costo. El Objetivo de Punto de Recuperación (RPO, por sus siglas en inglés) y el Objetivo de Tiempo de Recuperación (RTO, por sus siglas en inglés) definen el SLA que un proveedor proporcionará para informar al usuario de la longitud aceptable de tiempo en que los datos podrían perderse en caso de una interrupción, y qué tan rápido repararán los servicios.

"Naturalmente, con un backup en caliente, o una arquitectura activa/activa, no hay tiempo de inactividad y existe una réplica perfecta de datos, por lo que desde una perspectiva de SLA es un camino muy favorable, pues asegura que los datos críticos no se pierdan y que las aplicaciones fundamentales sigan funcionando sin ninguna interrupción", anota Hariharan." Aquí, el inconveniente es, sin duda, el costo. Esencialmente, el mantenimiento de dos sistemas que siempre funcionan cuesta el doble, ya sea que estos costos estén relacionados con la ejecución de réplicas de arquitecturas en un centro de datos privado, el pago de un proveedor de hosting gestionado para realizar la misma tarea en un sitio externo, o el costo de ejecutar el doble de instancias en la nube. En algunos de estos escenarios, y dependiendo del tamaño del despliegue, es probable que también se considere la planilla, donde el personal técnico adicional que se necesita para administrar el doble de sistemas también causará un fuerte aumento en los costos".

Costos

Dada una tasa media (y creciente) de 7.900 dólares por minuto (Ponemon Institute), el tiempo de inactividad crea un enorme costo potencial para las empresas, tanto en el negocio inmediato como en la reputación a largo plazo.

Otros costos incluyen los servidores en una coubicación. Poseen la atracción superficial de ahorrar dinero mediante la distribución de costos de infraestructura sobre muchos usuarios, pero una mirada más cercana revela que esos ahorros no se actualizan, según el Libro Blanco de ScaleArc. La compañía de coubicación todavía cobra por los recursos no utilizados, incluyendo aquellos oscuros que algún día podrían ser activados para uso completo. Sin embargo, las empresas no pueden reducir la cantidad de recursos dedicados al sitio secundario, pues toda la información del servidor primario debe estar respaldada en el secundario.

El informe de ScaleArc también señala que, al igual que la coubicación, las soluciones de la nube pública parecen atractivas debido a sus economías de escala asumidas. No obstante, las organizaciones con problemas de seguridad (por ejemplo, bancos y agencias gubernamentales) todavía se alejan de la nube debido a preocupaciones de privacidad. Además, los sistemas de la nube pueden introducir latencia que repercute en el rendimiento de la aplicación más allá de los niveles aceptables. Y nuevamente, la economía de la nube no siempre es lo que parece. Bajo pleno funcionamiento, los gastos de la nube suelen ser más altos que cuando las empresas poseen y administran su propia infraestructura.

ScaleArc cree que los costos de mantenimiento para una arquitectura activa/activa son más bajos porque las tareas se pueden hacer durante las horas de trabajo, en lugar de requerir un equipo en medio de la noche. También requieren menos miembros del personal, ya que las organizaciones pueden mantener la aplicación en ejecución durante el mantenimiento, por lo que los desarrolladores y otros especialistas en aplicaciones no necesitan estar involucrados.

"Solo por un 20% de aumento en los costos, las organizaciones disfrutarán un 33% más en capacidad del sistema, junto con los beneficios económicos adicionales de la reducción del tiempo de inactividad, menores costos operativos, mejor utilización de activos, y probablemente mayores ingresos totales", escribe ScaleArc.

Es posible que los clientes no entiendan las arquitecturas de computadoras, pero quieren que sus aplicaciones y datos estén disponibles, todo el tiempo. Cualquier proveedor que no proporcione el 100% de tiempo de actividad corre el riesgo de perder clientes e ingresos.

Al Sargent, director senior de OneLogin, señala que, desde el punto de vista financiero, los ingresos brutos eclipsan lo que las empresas gastan en presupuestos de TI. Un estudio muestra que las empresas gastan entre 3 y 7% de los ingresos en TI. "El cambio a las arquitecturas activas/activas podría aumentar el presupuesto de TI una fracción del porcentaje, pero evitará interrupciones que podrían reducir los ingresos en muchos puntos porcentuales", anota.

Algunas de estas desventajas de costos son amortiguadas con una solución SaaS basada en la nube, donde un entorno de administración común puede mantenerse en ambos sitios de manera automática. La nube permite tiempos de ampliación rápidos, por lo que puede implementar una infraestructura de conmutación por error reducida (menor ocupación de espacio) que restaura las aplicaciones casi al instante durante un incidente de desastre, lo que permite un mejor SLA, afirmó Hariharan.

Foster añade que ambos escenarios son válidos para una estrategia de recuperación de desastres de la empresa. Muchas aplicaciones, e incluso la infraestructura (las matrices de almacenamiento en el espacio empresarial han creado redes activas/activas a través de namespaces únicos que pueden cruzar los centros de datos también), han desarrollado esta tecnología para facilitar a las empresas la posibilidad de proporcionar planes de continuidad y recuperación de negocio en caso de una interrupción de la infraestructura.

"El problema es el costo del mantenimiento y funcionamiento de estas infraestructuras. Si una aplicación o servicio tiene requisitos para ser verdaderamente un sistema al estilo de 'tono de marcación' (siempre encendido), entonces una empresa gastará el dinero necesario para asegurar los cinco nueves de disponibilidad", indica.

La mayoría de aplicaciones fundamentales con estas necesidades poseen tales tipos de mecanismos de conmutación por error incorporados, para que los sistemas secundarios o terciarios puedan reanudarse si uno falla, añadió Foster. La agrupación también ha existido durante mucho tiempo para los servidores, y como esa tecnología se ha desplazado hacia abajo, hasta los servicios de infraestructura, la facilidad con la que se puede proporcionar la disponibilidad ha mejorado considerablemente -solo a un precio.

Sin embargo, señala que el costo no es el único inconveniente. "Las soluciones de recuperación activo-activo no consideran el error del usuario. Son la basura entrante y saliente, y en caso de este tipo de interrupción, es necesario tener algún punto de seguimiento en la consistencia temporal de los datos para recuperarse. La interrupción de GitLab hace unas semanas es un claro ejemplo", anota Foster.

"Podría haber cualquier cantidad de aplicaciones fundamentales que merecen la protección de la redundancia activa/activa, el truco está en determinar aquellas por las que realmente vale la pena el gasto", anota Steven Hill, analista senior de almacenamiento en 451 Research. "Es importante recordar que un buen plan DR/BC requiere una amplia evaluación de las prioridades clave empresariales de una compañía; el personal, los datos y aplicaciones necesarios para asistirlos; y el costo de las opciones alternativas disponibles para reemplazarlos -todos considerados- en un análisis costo/beneficio frente al riesgo de pérdida y probabilidad de una interrupción crítica de negocio".

Pros y contras
Don Foster de Commvault ofrece las ventajas y desventajas de una arquitectura activa/activa.

Pros:
* Recuperación rápida o instantánea -a menudo sin ningún tiempo de inactividad.
* Duplica el entorno de producción para asegurar la portabilidad del servicio, independientemente de la interrupción de la infraestructura.
* Generalmente, es proporcionado como parte de la oferta de la aplicación (Oracle RAC, DAG para Exchange, etc.).
* Fácil de manejar una vez configurado.

Contras:
Caro -se debe duplicar la infraestructura y siempre tenerla en funcionamiento. Este escenario se vuelve muy caro en la nube.
* No se recupera en caso de corrupción de datos (evento no relacionado a infraestructura).
* Requiere más soluciones para verdaderamente "proteger un servicio o aplicación de una interrupción de cualquier tipo.
* No proporciona copias de datos versionadas.
* Difícil de configurar y mantener para un servicio o aplicación compleja.

La recuperación de desastres oscura es más rentable, suele estar enfocada en interrupciones de datos, y puede ser perfectamente complementaria a los servicios de recuperación activos incorporados, señala Foster. La infraestructura estaría altamente disponible con copias de datos rastreadas con referencias en tiempo real y point-in-time versioned para resolver cualquier problema que pudiera surgir sobre interrupciones.

Justin Barney, CEO de ScaleArc, cree que una evaluación de los costos de una arquitectura activa-activa debe tener en cuenta las posibles pérdidas de tiempo de inactividad. "Las operaciones activas/activas cuestan algo así como una prima -alrededor del 20% en costos de hardware y software. Pero esos costos adicionales no incluyen compensaciones de fuentes tales como pérdidas de ingresos prevenidas debido al tiempo de inactividad evitado. En general, la perspectiva de que las operaciones activas/activas solo se justifican para las organizaciones que no pueden permitirse el tiempo de inactividad es verdadera", anota.

Barney comentó que debido a que la demanda de disponibilidad continua domina casi todas las industrias, sin duda las operaciones activas/activas ofrecen la mejor combinación de ventajas.

Existen nuevos datos que muestran que los sistemas y procesos de backup de las empresas se han basado en la mayoría para garantizar que la continuidad del negocio/recuperación de desastres en realidad podría estar perjudicando, y no ayudando cuando se trata de prevenir grandes interrupciones, según Barney. "Hoy en día, esto es importante porque los sistemas de recuperación de desastres ya no están satisfaciendo las necesidades de las organizaciones que deben lograr la 'disponibilidad continua'.

"Las empresas de hoy no pueden darse el lujo de fallar y luego recuperarse del fracaso, cuando estar desconectados no es una opción -y por lo tanto, el modelo 'DR oscuro' falla", añade.

Foster no está de acuerdo con esa declaración. "Si sigue operando los backups, la recuperación y DR como si fuera el 2005, entonces la declaración sí puede ser correcta; pero la realidad es que los clientes están modernizando la forma en que desempeñan un DR y backup, a medida que sus infraestructuras y arquitecturas maduran y cambian. Cuando no lo hacen, las interrupciones pueden ocurrir debido a la moda no integrada en la que se toman las decisiones de protección y DR".

Además, el flujo de trabajo normal del servidor primario debe ser redirigido al servidor secundario, que se convierte, al menos de manera temporal, en el nuevo servidor primario. Esta redirección puede requerir cantidades significativas de configuración manual, con dos equipos de TI (uno en cada ubicación) trabajando horas extras para habilitar y solucionar el problema de la transición. Reconfiguración similar se aplica a DNS, redes, topología de replicación y otros elementos de infraestructura. Los requisitos de las pruebas son enormes, y el personal de TI adicional debe ubicarse en la instalación secundaria, mientras que el equipo de TI original trata de conseguir que la instalación principal vuelva a estar en línea.

"Por supuesto, a medida que vemos que las grandes tendencias como 'el software está comiéndose el mundo' y 'cada empresa se está convirtiendo en una compañía de software', hay cada vez menos organizaciones para las que el tiempo de inactividad es aceptable. A menudo, DR significa por lo menos varios minutos -sino, es más- de tiempo de inactividad; y claro, debido a que usted está volviendo un sistema inactivo repentinamente activo, puede no iniciar las operaciones fluidamente. Pero sí, las arquitecturas activas/activas son las más adecuadas para las organizaciones que no pueden tolerar el tiempo de inactividad", afirma Barney.

Joseph George, vicepresidente de gestión de productos en Sungard AS, dijo que no encasillaría el debate entre las dos arquitecturas puramente en términos de eficiencia, ya que a menudo el mayor factor decisivo para el nivel de resistencia que escoge un negocio, se basa en lo que las empresas pueden pagar. "Claramente, si el costo no fuese un factor, todas las empresas tendrían sistemas [de alta disponibilidad]. Pero normalmente solo pueden permitirse (y necesitar) ese nivel para los sistemas y aplicaciones más esenciales", añade.

"Es importante que las empresas 'nivelen' sus aplicaciones para ayudar a manejar el equilibrio económico entre el riesgo y la inversión para mitigar. Las aplicaciones de nivelación, así como mapean sus interdependencias, permiten una secuencia óptima del orden de recuperación y buscan el programa de disponibilidad más rentable para el nivel de tiempo de inactividad de la aplicación, y la pérdida de datos que la organización puede permitirse en función del impacto empresarial.

DR tibio está bien

Swike dijo que la mayoría de las empresas realmente no necesitan DR activa/activa. DR tibia satisface sus necesidades. Con un ancho de banda apropiado entre los sitios, un RPO de segundos y RTO técnico de minutos a horas es muy factible. "Sin embargo, la tecnología es solamente parte de la historia: tiene que haber disciplina y tiempo invertido al proceso de DR. La replicación de servidores es un gran paso, pero si no lo prueba regularmente, ¿cómo sabe que va a funcionar?".

Para muchos, DR es el número 11 en su lista de las top 10 prioridades, señala. "Eso, de ninguna manera, significa que no se preocupan por DR. Es solo que los problemas y proyectos de producción del día a día siempre tienden a encabezar de la lista".

Mike Weber, vicepresidente de la división de laboratorios en Coalfire, señaló que, fundamentalmente, la clave para una estrategia de backup sólida depende de las necesidades del negocio y, sobre todo, del sistema. Existen muchos niveles de modelos que tratan los datos críticos con un RTO muy corto medido en minutos, que requieren copias de seguridad de streaming y/o replicación a un sistema redundante (pero no de alta disponibilidad), a través de los datos no críticos que pueden absorber el impacto de la recuperación medido en días.

"Cada uno de estos, y varios niveles de por medio, requiere diferentes estrategias para satisfacer tanto la continuidad del negocio como los objetivos de recuperación de desastres. Hay docenas de maneras de lograrlo", anota Weber.

También comentó que, muchas veces, Coalfire descubre que los sitios de recuperación de desastres o de backup no tienen las mismas protecciones y controles de seguridad que los sitios de producción. Las pruebas de penetración han encontrado que cuando existen sistemas usados varias veces en capacidades de respaldo o redundancia, las limitaciones de presupuesto a menudo resultan en la falta de los mismos controles de seguridad de red que protegen el entorno de producción.