Hay un pequeño centro de datos cerca de una empresa de fabricación en una pequeña ciudad bastante lejos de Moscú. Lo necesitan todo el día. Dio la casualidad de que solo hay una entrada de la red eléctrica, pero no hay un grupo electrógeno diesel. Debido a que la empresa no es TI, sino de producción, una vez no diseñaron correctamente. Porque una vez que todo funcionó.
El rayo de poder comenzó a jugar bromas. Cada semana, la luz se cortaba durante varias horas, y en forma de lotería: podían ser por una hora, o podrían ser más. No hay patrones
El administrador sugirió comprar un diésel, pero el negocio dijo que este no era un negocio de administración. Su trabajo es proporcionar tiempo de inactividad por no más de una hora. Simplemente agregaron una gran cantidad de dinero al equipo, por lo que no puede irse a la nube, y no hay centros de datos comerciales para transportar el equipo allí.
Y que hacer
Es con esta tarea que el cliente vino a nosotros. No hay mucho presupuesto, debe buscar una solución válida.
El caso normal (excepto la aparición de la segunda entrada, la transferencia del equipo o la aparición de un generador diesel) es desplegar la segunda instancia de la misma instancia exacta en la nube y cambiar a ella si algo cae repentinamente. Se llama recuperación de desastres. Algunos están construyendo un segundo centro de datos para sí mismos, hace frío y espera a que caiga el principal, o funciona en modo activo-activo, tomando el 50% de la carga.
Pero no hay dinero para un segundo centro de datos completo.
Se les ocurrió esto:
Hay un servidor físico pesado con una base de datos en el centro de datos del cliente. Y hay aplicaciones que funcionan con esta base de datos, que son un conjunto de máquinas virtuales en ESXi.
Para replicar la base de datos, instalaron el software Carbonite Availability (anteriormente conocido como Double-Take Availability) en la nube, que funciona en el nivel del sistema operativo. Y para la replicación de las máquinas virtuales que instalaron Zerto, este software funciona a nivel de hipervisor. Ambas soluciones funcionan aproximadamente de la misma manera: primero replican todo el volumen de datos del servidor a la nube, y luego interceptan todos los registros en discos en el sitio principal y los duplican en discos a la nube. El retraso en este caso es específicamente de 10 segundos, es decir, siempre tenemos una copia nueva de los datos hace 10 segundos.
Las máquinas virtuales no están incluidas. Usando el botón del panel de control de Zerto, podemos iniciar todas las máquinas virtuales a la vez. Esto sucede dentro de unos 28 minutos (las máquinas comienzan en paralelo), SLA durante 1 hora con nosotros inactivo. El lanzamiento se realiza llamando al administrador de turno. El cliente decide cuándo es necesario.
Las máquinas virtuales recogen la base y comienzan a trabajar.
Cuando se enciende la alimentación en las instalaciones, el cliente mismo comprende su infraestructura. Se ocupa de averías, luego habilita manualmente la replicación inversa. Se devuelve la cantidad de cambios en la base de datos acumulados durante el funcionamiento de las aplicaciones. Replicado - interruptor. En este ejemplo específico, el tráfico se acumula durante aproximadamente 5 minutos de recarga por cada hora de máquinas virtuales. Cuanto mayor sea el tiempo de funcionamiento de la instancia de emergencia, menor será el tráfico compartido, porque los registros a menudo van a las mismas tablas de la base de datos, y solo enviamos la diferencia.
Después de volver a la nube, las máquinas virtuales se apagan. El cliente no paga por los recursos que están apagados. Cuantificamos por reloj.
El pago es solo por la cantidad de datos almacenados, el canal y la licencia de software para la replicación (Zerto y Carbonite). Trabajamos según el principio de "Recuperación ante desastres como servicio", le damos SLA para eso. Y financieramente responsable de este SLA.
El cliente replica todo, una máquina virtual con los mismos parámetros que su física, todas las unidades de disco están duplicadas.
Esto es lo que hace Zerto:
Tiene replicación sin agente, tiene modo asíncrono, las máquinas virtuales en la plataforma DR están apagadas, replicación de diario, optimización de WAN, replicación de hipervisor cruzado, licencia para máquinas virtuales protegidas.
Carbonite es un agente de replicación, por lo que no importa qué hipervisor, hay un modo de operación asincrónico, hay soporte para instantáneas, compresión de los datos transmitidos, licencias para máquinas virtuales protegidas.
La instalación aplicó ambas soluciones a la vez. Por lo tanto, fue necesario debido a una serie de características. Por lo general, ofrecen una cosa.
También puede resolver un problema similar con la solución doméstica Veeam Cloud Connect (generalmente la usamos si ya tiene una copia de seguridad Veeam).
Resumen
Todos entendemos que el problema podría resolverse de manera diferente bombeando la instalación del lado del servidor de un generador diesel. Sin embargo, el negocio redujo los requisitos para la organización de la reserva. Brindamos un servicio y funcionó. Resultó ser un buen ejemplo de cómo puede implementar una plataforma DR de forma correcta y económica.
Referencias