¿Cómo está programada la empresa para sobrevivir a interrupciones?

¿Cómo está programada la empresa para sobrevivir a interrupciones?

CIO

Asincrónico Vs. sincrónico. Recuperación de oscuros desastres vs. arquitectura activa. Activo/activo vs. activo/pasivo. Objetivamente, no hay configuración mejor que otra. La mejor para ti depende de tu nivel de tolerancia cuando el servidor se caiga.

Los expertos en seguridad dicen como las compañías individuales elijen salvar su data anticipando una interrupción depende de que tanto pueden sobrevivir antes de que las “luces” se vuelvan a encender. ¿Qué nivel de disponibilidad necesita tu compañía? ¿Es la cara de tu compañía una web de comercio electrónico donde hasta unos minutos fuera de línea puede costar una cantidad astronómica de dinero? ¿Sera el costo de un sistema activo-activo mayor que la perdida por la interrupción?

“No se trata de que una es más eficiente que la otra. Es mas ¿Cuál es la necesidad que tratas de solventar? Por ejemplo, comprar un Ferrari para hacer las compras de la semana hace el trabajo, pero ¿En verdad encaja con el propósito?” dice Don Foster, director senior de soluciones y mercado para Commvault.

En una arquitectura activa/activa, típicamente, un racimo de servidores fuera de linea esta sincronizado con servidores en linea. Esto permite que no haya puntos muertos en el caso de un desastre donde un servidor quede fuera de línea. Puede estar configurado para una conmutación por error.

En esta configuración se necesita menos hardware porque todo el sistema en ambos sitios está siendo utilizado vs. Solo la mitad del hardware en una recuperación de un desastre oscuro.  Si tienes 48 núcleos de recuperación de desastre oscuro, tendrías 96 núcleos y usarías solo 48. En modo activo/activo, bajas la escala de 32 x 2, para 64 núcleos y todos activos

En un escenario de recuperación de desastre oscuro, la capacidad es un sistema redundante entero – todo el hardware y software listo – pero completamente ocioso. Esa capacidad no se usa para nada hasta que el primer sistema falla, pero se puede replicar en ciertos periodos.

Erin Swike, arquitecto senior de soluciones de nubes para Bluelock, explica que “la recuperación de un desastre activo/activo es el unicornio del mundo de recuperación de desastres (RD). La idea de poder dormir de noche sabiendo que, si la producción de tu sistema falla, tu sitio RD empezará a enviar aplicaciones a tus usuarios sin tener momentos de oscuridad, es el nirvana de cualquier CIO o ingeniero en sistemas.

“Para la mayoría, se mantiene como algo de cuentos de hadas y legendas. Olvídense sobre el factor obvio de la proximidad de la data y el estado latiente de la red; uno de los factores más importantes es si tus aplicaciones estas escritas para soportar este tipo de escenarios. Al menos que esta aplicación haya sido escrita con esto en mente desde el principio, la probabilidad está en que no lo puede soportar,” dice esta.

El costo en software es mayor en modo activo/activo porque cualquier sistema que esté funcionando en modo activo debe contar con la licencia del software. Cuando el sistema está en modo de recuperación de desastre oscuro, el segundo sistema no requiere licencias pagas para funcionar porque solo un grupo de estos están activos a la vez. El hecho de que ambos sistemas estén sincronizados, no afecta el costo para nada.

En replicación sincrónica, es necesario que haya una conexión de red confiable entre los 2 servidores. También hay trabajo extra cuando se tratan de mantener 2 redes activas.

Don Foster, Commvault

El aspecto negativo de la replicación sincrónica es la data que se pierde entre el momento que esta el sistema caído y la última vez que fue actualizado. Sin embargo, puede ser configurado para una conmutación por error automática.

Anand Hariharan, vicepresidente de productos en Webscale Networks dice que este es esencialmente el concepto de frio/tibio/caliente en los servidores de respaldo. Los pros y los contras caen en 2 grupos: acuerdo de nivel del server (SLA) y costo. Cuando el objetivo es la recuperación (RPO) y cuando el objetivo de la recuperación es el tiempo (RTO) aunque esta información – el periodo de tiempo aceptable para la recuperación – es deducible.

“Naturalmente con un respaldo, o una arquitectura activa/activa, no se pierde tiempo fuera de línea y por esto se tiene data de réplica perfecta, así que desde la perspectiva de SLA, este es un camino muy favorable para tomar ya que asegura que no se pierda data crítica y aplicaciones indispensables sigan funcionando sin interrupciones,” dijo Hariharan.

“La desventaja aquí es por supuesto el costo. Manejar dos sistemas que están siempre activos es el doble de costo, puede que este gasto sea por tener la réplica en un centro de data privado, pagarle a un proveedor de mantenimiento de servidor para que haga el mismo trabajo en dos lugares, o el costo de que la nube funcione el doble. En alguno de estos escenarios, y dependiendo del tamaño del despliegue, también hay probablemente una cuenta de cabezas que vale la pena considerar, donde requiera el staff adicional manejar el doble del sistema ocasionará también incremento en costos.

Ver más: Bitcoin: Desenfrenado e irregular crecimiento durante 2017

Costos

Dando un estimado (e incremento) de $7,900 por minute (Ponemon Institute), el tiempo en el sistema deja de funcionar crea una gran pérdida para las compañías, tanto a corto plazo (negocios inmediatos) como a largo plazo (la reputación de tu empresa)

Otros costos incluyen los servidores en el lugar de colocación. Ellos tienen la atracción superficial de ahorrar dinero distribuyendo el gasto de infraestructura en varios usuarios, pero una mirada más cercana nos dice que esos ahorros no están actualizados, de acuerdo con ScaleArc White Paper. Las compañías de colocación también cobran por cualquier servicio no utilizado. incluso oscuros que en algún momento pueden ser usados. Sin embargo, las compañías no pueden reducir la cantidad de recursos utilizados para los servidores secundarios ya que estos cargan con el respaldo del servidor principal.

The ScaleArc reportó que al igual que en las colocaciones, ver como soluciones a las nubes de almacenamiento publicas debido a la gran economía que estas representan. Sin embargo, organizaciones con preocupaciones de seguridad (bancos y organizaciones de gobierno, por ejemplo) aun no la usan por preocupaciones de privacidad. También cabe destacar que las nubes sufren de inestabilidad lo que impacta en la actuación de las aplicaciones mucho más de lo aceptable. Y advertimos, las nubes no son tan económicas como parecen. Cuando están 100% operativas, los gastos en nubes pueden ser mayores a que si uno mismo posee una infraestructura.

ScaleArc cree que el costo de mantenimiento por una arquitectura activa/activa son más bajos porque las actividades pueden ser desarrolladas durante jornada de trabajo, en vez de necesitar a un equipo en el medio de la noche. También requieren menos miembros del staff porque las organizaciones pueden mantener la aplicación activa durante el mantenimiento, así que desarrolladores y otros especialistas en aplicaciones no necesitan involucrarse.

Por tan solo un 20% de incremento en costos, organizaciones disfrutaran de 33 % más capacidad de sistema, junto con beneficios (económicos y adicionales) de reducción de tiempo fuera de servicio, valor más bajo de operación, mejor uso de las características, y un leve aumento de ingresos.

Los clientes puede que no entiendan la arquitectura de las computadoras, pero ellos quieren sus aplicaciones y data funcionando todo el tiempo. Cualquier vendedor que falle en proveer 100% de disponibilidad, se arriesga a perder clientes y ganancias.

Al Sargent, director senior de OneLogin, dice desde un punto de vista de finanzas, solo una parte minúscula del presupuesto se gasta en TI. Un estudio muestra que las compañías gastan entre 5 y 7 por ciento de sus ingresos en TI.

“Si se cambian a arquitecturas activo/activo puede que el presupuesto para TI crezca una fracción, pero prevendría interrupciones que erosionaría aún más el porcentaje en el presupuesto,” agregó.

Algunas de estas desventajas de costo son minimizadas usando como solución las nubes, donde un ambiente común de manejo puede ser automáticamente mantenido en los 2 sitios. La nube permite recuperaciones de rápida escala, así que puedes desplegar una conmutación por error reducida en la infraestructura (una huella más pequeña) que puede restaurar aplicaciones casi de inmediato durante un incidente desastroso, permitiendo mejor SLA, dice Hariharan.

Foster dice que ambos escenarios son válidos para una estrategia de recuperación de desastre de una empresa. Muchas aplicaciones y hasta estructuras (compañías de almacenamiento han creado cuadriculas activo/activo a través de nombres que pueden cruzar centros de data) han desarrollado esta tecnología para hacerlos más fácil para compañías para proveer planes de comunidades de negocios y recuperación en caso de una interrupción infraestructura. 

“EL problema es el costo de mantener y manejar estas infraestructuras. Si una aplicación o servicio tiene requisitos para funcionar óptimamente, entonces el negocio gastará los dólares requeridos para asegurar los cinco nueve de disponibilidad y hasta un poco más”, manifestó.

Las aplicaciones más críticas con estas necesidades tienen este tipo de conmutación por error instalada para que ese sistema secundario o terciario puede continuar si una tiene alguna falla, añade Foster. El conjunto de racimos ha estado alrededor por un largo tiempo, y como esa tecnología ha bajado de peldaño en los servicios de infraestructura, la facilidad con la que la disponibilidad puede ser dada es grandiosamente mejorada – solo que a un costo.

A pesar de que este dijo que el costo no es la única desventaja. “soluciones de recuperación activo-activo no cuentan como errores del usuario. Son del tipo basura entra t basura sale, y en un evento de este tipo de un corte, necesitan tener algo que sea punto de rastreo en la consistencia del tiempo de la data para recuperarla también. El corte de The GitLab de hace unas semanas es un gran ejemplo de esto,” externó Foster.

“Podría haber cualquier número de aplicaciones que valgan la pena proteger de redundancia activo/activo, el truco es determinar aquellas que ameritan el gasto,” dice Steven Hill, analista senior de almacenamiento para 451 Research. “Es importante recordar que un buen plan de recuperación de desastres hace llamado a una gran evaluación de las prioridades claves de una compañía; el personal, data y las aplicaciones necesarias para sostenerla; y el costo de opciones alternativas disponibles para reemplazarlas – todas tomando en cuenta el costo/análisis beneficioso contra el riesgo de pierda y probabilidad de una interrupción crítica del negocio.

La recuperación de desastres oscuros es más efectiva hablando de costo, es típicamente data interrumpida de su foco, y puede ser muy complementaria para los servicios de recuperaciones ya existentes. La infraestructura estaría altamente disponible con copia de data rastreada a tiempo real y versionada en referencias para resolver cualquier problema de corte que pueda surgir.

El CEO de ScaleArc Justin Barney cree que una evolución de costo para una arquitectura activo/activo debe tener en cuenta las pérdidas potenciales de los tiempos fuera de linea. “Operaciones activo/activo cuestan un poco como algo exclusivo – como 20% en hardware y software. Pero esos costos adicionales no incluyen pérdida de ingresos evitadas por haber evitado una corte. Sobre todo, la perspectiva que las operaciones activo/activo están garantizadas solo para organizaciones que no pueden costear cortes,” dijo este.

De acuerdo con Barney con demanda por disponibilidad continúa dominando casi todas las industrias, operaciones activo/activo claramente proveen la mejor combinación de ventajas.

 

Leave a comment

Send a Comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *