Analizar el uso de DRBD o un sistema de archivos en clúster para ayudar con el tiempo de actividad cuando se produce un tiempo de inactividad en un entorno de pequeñas empresas.
Actualmente usamos una caja de servidor para un servidor de archivos que usa Linux y samba, luego ejecutamos el servidor web y la base de datos en una máquina virtual. Estaba pensando en agregar un segundo servidor y colocar los archivos y la máquina virtual en el sistema de archivos distribuido. El sistema operativo base es más estático y se puede administrar fácilmente de forma más manual (copie los archivos de configuración en el momento del cambio, copie el sistema operativo base si es necesario desde copias de seguridad completas, etc.)
La pregunta es sobre el escenario de conmutación por error si se realiza manualmente. Si el servidor 1 falla y la conmutación por error se realiza manualmente, la conmutación por error se completa simplemente configurando la IP estática del servidor 2 en el servidor 1 (nuevamente el servidor 1 está inactivo y necesitaría reparación), iniciando Samba e iniciando ¿La VM que tendría las mismas IP estáticas que tenía cuando se ejecutaba en el servidor 1 e iniciaba los servicios de respaldo?
Parece un proceso rápido y sencillo, casi demasiado sencillo. ¿Me estoy perdiendo de algo? Esto también podría automatizarse fácilmente a través de un script o algo que alguien con poca competencia pueda ejecutar en caso de falla.
El tiempo de inactividad si tenemos una falla de hardware fácilmente podría ser de días sin el soporte de TI de guardia y las piezas necesarias sin un segundo servidor, pero con el segundo servidor, el tiempo de inactividad sería como máximo una cuestión de horas (si no uno es la oficina lo suficientemente competente para realizar tales operaciones, minutos si alguien lo fuera)
Respuesta1
El proceso de conmutación por error que estás describiendo es tan simple como correcto. El uso de DRBD es el paso clave para crear redundancia, ya que elimina un único punto de falla como un almacenamiento compartido.
La conmutación por error actual que menciona se puede automatizar fácilmente medianteMarcapasos/Corosyncpara que no haya necesidad de intervención manual. Preferiría esto a los scripts escritos por mí mismo, ya que también se encarga de proteger los nodos no funcionales, para que no te encuentres con un escenario de cerebro dividido (que podría arruinar todos tus datos).
Tenga en cuenta que la HA "real" requiere una separación completa (o al menos máxima archivable) de los sistemas (habitación separada (o al menos bastidor), diferentes USV, conmutación redundante, etc.). Un único punto de falla generalmente arruina todo su esfuerzo por optimizar la disponibilidad.