¿Host de reserva caliente vs host de reserva fría?

Tenemos varios hosts donde tenemos un host de repuesto dinámico idéntico, que está parcheado y actualizado, por lo que está muy cerca de tener el mismo software y configuración. En caso de falla, el cable de red se cambia y el servidor DHCP se actualiza con la nueva dirección MAC. Este es el mejor caso, ya que generalmente hay un poco más que necesita modificación.

Siento que es una pérdida de electricidad tener un host de repuesto caliente y una pérdida de tiempo para mantenerlo, y dado que se necesitan modificaciones de configuración en caso de conmutación por error, me gustaría preguntar lo siguiente:

¿Los hosts de repuesto en caliente son de la vieja escuela y ahora hay mejores formas?

En lugar de tener un host de repuesto en caliente, ¿tendría sentido convertirlo en un repuesto en frío? Tome los discos duros y colóquelos en el host primario y cambie el RAID de 1 a 1 + 1. En caso de falla, todo lo que tendría que hacer es cambiar los cables de red, actualizar el servidor DHCP, tomar los discos duros e insertarlos en el repuesto en frío y encenderlos. El beneficio, según lo veo, es que los discos 2x2 siempre están sincronizados, por lo que solo se necesita un host para mantener y no se necesitan cambios de configuración cuando se produce una falla.

¿Es eso una buena idea?

Sobrique explica cómo la intervención manual hace que su solución propuesta sea óptima , y ewwhite habla sobre la probabilidad de falla de varios componentes . Ambos de la OMI hacen muy buenos puntos y deben ser fuertemente considerados.

Sin embargo, hay un tema que nadie parece haber comentado hasta ahora, que me sorprende un poco. Usted propone:

haga que [el host de repuesto dinámico actual] sea un repuesto frío, tome los discos duros y colóquelos en el host primario y cambie el RAID de 1 a 1 + 1.

Esto no lo protege contra todo lo que hace el sistema operativo en el disco.

Realmente solo lo protege contra la falla del disco, que al pasar de los espejos (RAID 1) a los espejos de los espejos (RAID 1 + 1) reduce en gran medida el impacto de comenzar. Puede obtener el mismo resultado al aumentar el número de discos en cada conjunto de espejos (pasar de RAID 1 de 2 discos a RAID 1 de 4 discos, por ejemplo), junto con una mejora muy probable en el rendimiento de lectura durante las operaciones normales.

Bueno, veamos algunas formas en que esto podría fallar .

• Digamos que está instalando actualizaciones del sistema, y ​​algo hace que el proceso falle a mitad de camino; tal vez haya una falla de energía y UPS , o tal vez tenga un accidente extraño y se encuentre con un error de kernel paralizante (Linux es bastante confiable en estos días, pero aún existe el riesgo).
• Tal vez una actualización introduce un problema que no detectó durante la prueba (prueba las actualizaciones del sistema, ¿verdad?) Que requiere una conmutación por error al sistema secundario mientras repara el primario
• Tal vez un error en el código del sistema de archivos provoca escrituras falsas e inválidas en el disco.
• Tal vez un administrador gordo (o incluso malicioso) lo haga rm -rf ../*o rm -rf /*no rm -rf ./*.
• Tal vez un error en su propio software hace que corrompa masivamente el contenido de la base de datos.
• Tal vez un virus logra colarse.

Tal vez, tal vez, tal vez ... (y estoy seguro de que hay muchas más formas en que su enfoque propuesto podría fallar). Sin embargo, al final esto se reduce a su "ventaja" de los dos conjuntos están siempre sincronizados. A veces no quieres que estén perfectamente sincronizados.

Dependiendo de lo que haya sucedido exactamente, es cuando desea tener un modo de espera en caliente o frío listo para encenderlo o realizar copias de seguridad adecuadas. De cualquier manera, los espejos RAID de espejos (o espejos RAID) no lo ayudan si el modo de falla involucra mucho más que la falla del dispositivo de almacenamiento de hardware (bloqueo del disco). Algo así como el raidzN de ZFS probablemente pueda mejorar un poco en algunos aspectos, pero no mejorar en otros.

Para mí, esto haría que su enfoque propuesto sea un fracaso desde el principio si la intención es algún tipo de conmutación por error ante desastres.

Sí, es un poco vieja escuela. El hardware moderno no solo falla tan a menudo. Concéntrese en hacer que sus aplicaciones estén más disponibles (no siempre es posible) o en los elementos necesarios para que sus hosts individuales sean más resistentes ...

Para los anfitriones:

• Compre un mejor hardware.
• Asegúrese de tener contratos de soporte.
• REGISTRE los contratos de soporte de sus servidores (¡los repuestos se almacenan localmente según los datos de registro!)
• Utilice fuentes de alimentación redundantes, (¿hardware?) RAID, ventiladores redundantes.
• Si el servidor no es capaz de acomodar las funciones redundantes anteriores, tenga a mano un chasis o componentes de repuesto para poder repararse a sí mismo en caso de falla.

En orden de disminución de la frecuencia de fallas, veo: discos, RAM, fuentes de alimentación, ventiladores con mayor frecuencia ... A veces, la placa del sistema o la CPU. Pero esos dos últimos son donde debería entrar en vigencia su contrato de soporte.

Es bastante ineficiente, sobre todo debido a la dependencia de la intervención manual para realizar el cambio.

He trabajado en lugares que ejecutan un sitio de DR en caliente, literalmente, servidores idénticos a los principales, listos para funcionar al instante. Sin embargo, la conmutación DR es un proceso automatizado: no estamos hablando de cableado, un poco de violín y un interruptor, sino un proceso cuando presionamos el botón voltea todo de un sitio a otro.

Este enfoque es asquerosamente costoso, pero esa es una decisión comercial: riesgo aceptable frente al dinero necesario para cumplir el objetivo. Como regla, hay una curva exponencial en el objetivo del tiempo de recuperación: cuanto más se acerca a cero, más cuesta.

Pero de eso se trata tu pregunta, de verdad. ¿Cuál es su objetivo de tiempo de recuperación y cuál es la forma más efectiva de lograrlo? Esperar a que se inicie un servidor llevará unos minutos. ¿Cuánto tiempo le toma a alguien hacer el ajuste y las 'tareas de recuperación' cuando sale a las 4am?

¿Y por cuánto tiempo es una interrupción aceptable?

Sugeriría que si está haciendo una 'recuperación en caliente', desea pensar en la agrupación. Puede ser bastante económico en la agrupación en clúster con un buen uso de VMWare: 'pasar por alto' a una VM, incluso desde un dispositivo físico, significa que no está ejecutando hardware redundante. (Bueno, N + 1 en lugar de 2N).

Si su RTO es lo suficientemente largo, apague la caja. Puede encontrar que el RTO es suficiente para que una reconstrucción en frío desde la copia de seguridad esté bien.

El hecho de que sea de la vieja escuela no necesariamente hace que el uso de un repuesto dinámico sea una mala idea.

Su principal preocupación debe ser la justificación, cuáles son los riesgos que corre y cómo los mitiga el funcionamiento de un repuesto dinámico. Porque, en mi opinión, su repuesto dinámico solo soluciona fallas de hardware, lo cual, aunque no es infrecuente, no es el único riesgo operativo que corre, ni el más probable. La segunda preocupación es si las estrategias alternativas brindan más reducción de riesgos o ahorros significativos.

Ejecutar un repuesto dinámico con múltiples pasos de conmutación por error manuales llevará mucho tiempo y es probable que salga mal, pero también me parece que la conmutación por error automática con las suites de clúster HA se convierten en grandes f * cks de clúster.

Otra cosa es que el modo de espera frío o caliente en la misma ubicación no proporciona continuidad comercial en caso de desastre local.

El concepto de tener un repuesto caliente o incluso frío depende de cómo se construyan las aplicaciones en primer lugar.

Lo que quiero decir es que si la aplicación se ha creado de tal manera que la carga de datos y servicios se distribuya entre varias máquinas, entonces el concepto de cualquier máquina que derribe el sistema debería desaparecer. En esa situación, no necesita un repuesto caliente. En cambio, necesita suficiente capacidad en exceso para manejar cuando una máquina / componente individual muere.

Por ejemplo, una aplicación web estándar generalmente requiere un servidor web y un servidor de base de datos. Para los servidores web, solo balance de carga 2 o más. Si uno muere, no hay problema. La base de datos suele ser más difícil, ya que tiene que ser diseñada para ser multimaestro con todos los datos sincronizados en las máquinas participantes. Entonces, en lugar de un único servidor de base de datos, terminas con 2 (o más) que atienden tus necesidades de datos. Grandes proveedores de servicios como Google, Amazon, Facebook, etc., han tomado esta ruta. Hay más costo inicial en el tiempo de desarrollo, pero paga dividendos si necesita escalar.

Ahora, si su aplicación no está estructurada de tal manera o es simplemente prohibitiva ajustar la aplicación, entonces sí es probable que desee un repuesto dinámico.