Alta disponibilidad del servidor para una pequeña empresa

Después de tener un poco de miedo con un servidor que no surgiría una mañana, los superiores decidieron que la empresa necesita una alta disponibilidad / configuración de conmutación por error.

Tenemos 5 servidores principales (4x Linux, 1x OpenBSD), todos los cuales deben ejecutarse para que la empresa funcione. Tres de los servidores son bastante estándar (Archivos / Web / Base de datos), el cuarto maneja la mayoría de los enrutamientos de red y proxies web, mientras que el quinto admite nuestro sistema telefónico y tiene hardware no estándar.

Mi jefe ha declarado que el tiempo de respuesta para una falla del servidor debe ser inferior a 30 minutos.

Mi experiencia en este campo es inexistente (solo soy un programador que fue 'promovido'), así que supongo que mi pregunta realmente se reduce a:

• ¿Es esto algo que incluso debería ser intentado por alguien con habilidades promedio de administrador de servidor? Si es así, ¿qué debo leer y con quién debo hablar?

Gracias.

Creo que debería comenzar reuniendo números para describir el costo asociado con el cumplimiento del "requisito" establecido para ver si incluso cae dentro del presupuesto. Si no se siente cómodo con todos los métodos "normales" que se utilizarían para cumplir con el requisito (agrupación de conmutación por error, hipervisores con capacidad de "migración en caliente", etc.), probablemente haría bien en encontrar un consultor que pueda ayudar.

Habrá algún costo asociado con el estudio de factibilidad, pero va a costar mucho menos descubrir que una buena solución no se ajustará al requisito establecido (lo que significa que las expectativas deben ser establecidas de manera más realista por la administración, o ellos necesita gastar más dinero del que costará hacer algo a medias que termina por no cumplir con el requisito y gastar una tonelada de dinero en el proceso.

Parece que tu jefe acaba de sacar ese número del aire. Quizás haya hecho un análisis y sepa cuál es el costo por hora asociado con el tiempo de inactividad de varios sistemas, pero lo dudo. Suena como un número de pastel en el cielo que no está vinculado a la realidad. Me sorprendería si todos sus sistemas necesitan ese tipo de disponibilidad. Es posible que, durante el estudio de la empresa, descubra que solo un subconjunto de funcionalidades necesita tener tal grado de tiempo de actividad y tolerancia a fallas (y, por lo tanto, tal solución finalmente costaría menos). Estoy seguro de que los teléfonos y la aplicación de línea de negocio están ahí, pero es posible que tenga cierta tolerancia al tiempo de inactividad en algunos de los otros sistemas.

Mi instinto dice que probablemente encontrará una victoria en el uso de tecnologías de virtualización para crear un sistema de conmutación por error basado en la migración de máquinas virtuales entre hardware redundante. Si se ajustará a su presupuesto o no dependerá de su negocio, ya que definitivamente necesitará algún tipo de SAN para que funcione de manera efectiva.

Sin embargo, no descarte el clúster de conmutación por error "tradicional". Definitivamente, también hay "victorias" si sus aplicaciones se adaptan bien a dicha configuración.

Me pregunto si su jefe ha pensado en escenarios de fallas catastróficas (quemaduras en edificios, inundaciones, tornados, robos, etc.). Si eso ya no está planeado, esta sería una oportunidad de oro para trabajar en alguna planificación general de continuidad del negocio y contingencia de recuperación de desastres.

Obtenga ayuda de alguien que pueda entrar y estudiar su negocio y hacer recomendaciones. No te arrepentirás.

"Este camino lleva a mucho dolor y dolor ..."

Entonces, ¿cuál es el plan de continuidad de su negocio? Su plan de recuperación de desastres?

¿Lo has discutido? Escrito? PROBADO

Debe tener una conversación adecuada con los "superiores" y realmente llegar al fondo de los requisitos de alta disponibilidad porque es diferente para los diferentes servicios.

Entonces, ¿cuál fue realmente el "punto de dolor" que sintieron esa mañana?

¿Era que?

• ¿Los teléfonos dejaron de funcionar? Problema bastante importante (y visible). Y sí, esto necesitará una "solución", pero espero que esto esté bajo un acuerdo de soporte.
• Sitio web fallido? OK: bastante visible pero no inesperado, y a menos que tenga una presencia web ENORME, entonces no es tan importante. Está bien tener este servidor inactivo durante unas horas.
• ¿Servidor de base de datos inactivo? Miedo ... ¡Espero que tengas buenas copias de seguridad! No pierda los datos, de lo contrario, el negocio fallará. Pero, siempre y cuando los datos estén seguros, es un servidor que es importante y debe tener un plan de recuperación.
• Archivo e impresión (y aplicaciones internas, etc.). Esto es PITA para la mayoría de las personas, ya que se sentarán y no harán nada durante una mañana mientras lo arregla.

¿Asumo que ha comprado hardware de alta calidad para sus sistemas principales? Bien, porque ahorrar dinero en hardware es una economía falsa ya que estos servidores vienen con todo "dual" en la caja.

También supondré que sabe CÓMO reconstruir un servidor, cambiar ventiladores, fuentes de alimentación, instalar un servidor, configurar redes de doble ruta en conmutadores redundantes Has hecho esto suficientes veces para entender qué funciona y qué no funciona, qué es normal y qué es erróneo. Si no es así, obtenga ayuda y capacitación (o al menos practique y experimente).

Quizás gran parte del problema era MIEDO. No tenían idea de que tal problema podría ocurrir (y cuán importantes eran los servidores para su negocio) y realmente no sabía lo que estaba haciendo (?) ¿Un problema de confianza?

Debe hacer todo lo anterior correctamente ANTES de seguir la ruta HA muy costosa. ¿Puede el negocio permitirse este costoso equipo (y la mayor parte, por definición, solo se usará en una falla y a menudo nunca se usará)

Evan acertó en algunos buenos puntos, pero aquí hay quizás algunas formas rentables específicas para obtener un tiempo de recuperación inferior a 1 hora ante fallas.

Las pequeñas empresas probablemente significan hardware pequeño, por lo que puede que no sea un gran costo hacer algunas cosas simples que realmente agregan una cantidad significativa de resistencia frente a los problemas. La idea principal es tener hardware extra listo para funcionar.

Primero, póngase cómodo con la idea de una IP virtual. Esa es la dirección IP con la que los usuarios hablarán, pero pueden residir en cualquier servidor al que se la des. Esta es la dirección IP que son usuarios, y las aplicaciones querrán hablar con ellas. Y será lo más útil para finalmente cualquier solución que elija. Tener un VIP significa que no debería tener que reconfigurar ninguna de las aplicaciones al fallar. Además, tenga en cuenta que tener hardware redundante también tiene el impacto de aumentar la sobrecarga administrativa, haciendo dos actualizaciones de configuración en lugar de 1.

Si comenzamos con su servidor proxy de enrutamiento / web, probablemente sea el más fácil, ya que no habrá ningún estado real que deba almacenarse en la caja. Así que solo obtenga un duplicado del mismo cuadro y configúrelo igual. Mantendría a ambos conectados en el segmento LAN, y suponiendo que su Internet esté en otra interfaz, cambie los cables si falla. Desde una perspectiva de enrutamiento, configura todos sus clientes lan para que apunten a la dirección .1 (el VIP) para su ruta predeterminada y el servidor proxy le da al servidor A la dirección .2 y al servidor B la dirección .3. De esta manera, ambos se pueden administrar para actualizaciones de configuración (se aplica a ambos). Y todo lo que tiene que hacer para la conmutación por error es eliminar la asignación de IP .1 de .2 y moverla a .3, y mover la conexión a Internet a la otra interfaz. No es muy complicado, fácil de hacer y entender, y cuesta el hardware extra de una segunda caja. Si puede obtener redundancia en el lado de Internet, podría agregar algo de complejidad y obtener una conmutación por error automática usando algo como VRRP.

Sin detalles, es difícil de decir, pero su servidor web puede ser igual de simple. Agregue un segundo servidor con configuración idéntica, cree un vIP entre los dos y mueva el VIP a la copia de seguridad en caso de falla. Por lo general, no me importa si el estado de la sesión se pierde en una conmutación por error (es un problema crítico causar una conmutación por error). Entonces, si los usuarios tienen que iniciar sesión nuevamente, no es gran cosa. Nuevamente, vrrp probablemente se puede usar para la conmutación por error automática.

Pasando a su DB, esto es significativamente más complejo. La mayoría de las bases de datos tienen algún tipo de modelo primario / secundario, donde hace una copia de seguridad de la base de datos original en la secundaria y luego copia todos los registros de transacciones o los cambios de la base de datos en la secundaria. Nuevamente, puede combinar esto con VIP para las aplicaciones / usuarios que realmente acceden a la base de datos. Sin embargo, la conmutación por error es más complicada. Dependiendo de la falla del primario, es posible que deba poner en funcionamiento las unidades para copiar y sobrar los registros de transacciones. Luego traiga el secundario activo. Si puede tolerar algunos datos perdidos, puede activar el secundario activo de inmediato. Después de la conmutación por error, el servidor B es ahora su principal y su trabajo consistiría en restaurar el servidor A y convertirlo en la nueva copia de seguridad para que esté listo para fallar cuando el servidor b eventualmente tenga problemas.

Los servidores de archivos son siempre la parte más difícil, ya que a diferencia de los DB, es mucho más difícil obtener una función integrada del sistema de archivos. Sin embargo, se puede lograr cierto nivel de resistencia al tener un segundo servidor, y simplemente escribir un script que escanee el sistema de archivos en busca de cambios, y copie los archivos nuevos a su segundo nivel. Básicamente puede ejecutar rsync en un cron. Creo que puedo hacer esto. Nuevamente, usa un VIP que le da a los usuarios, que se mueve si realiza una conmutación por error. En su secuencia de comandos, le recomiendo que verifique para asegurarse de que el sistema sea el propietario del VIP antes de transferir archivos. Realmente realmente no quieres que el rsync se ejecute en la dirección incorrecta y sobrescriba los cambios que están haciendo los usuarios. Esto podría perder algunos archivos si es un error,

No tengo idea de qué podría hacer con su sistema telefónico ... realmente depende del proveedor y de cómo esté configurado. El proveedor puede tener alguna solución estándar para la resistencia.

Algunas palabras finales de advertencia. Asegúrese de probar a fondo cualquier configuración que vaya a utilizar. Asegúrate de saber cómo fallar sin perder esa información crítica. Prueba prueba prueba para asegurarte de que funcionará cuando lo necesites. Asegúrese de tener procesos implementados para que los cambios de configuración, actualizaciones de software, etc. se apliquen correctamente tanto a las copias de seguridad primarias como a las copias de seguridad. La buena noticia es que probablemente pueda realizar una conmutación por error controlada cuando desee bajar un servidor para actualizar, etc. No es una configuración activo-activo, por lo que no tiene idea de si el secundario funcionará cuando lo necesite.

Trabajo en telecomunicaciones y nuestro equipo es muy redundante, incluida en la mayoría de los casos la redundancia geográfica. Nuestro punto de falla número 1 es que la redundancia no se prueba después de los cambios, y los usuarios que realizan cambios que no saben cómo funciona el modelo de redundancia. Sin embargo, tenemos el problema adicional de que todos nuestros equipos deben admitir la conmutación por error automática en no más de varios segundos. Puede tolerar la intervención manual en sus failovers si solo necesita estar en funcionamiento dentro de 30 a 60 minutos. Solo necesitas estar preparado. Buena suerte.

Todos los demás puntos son geniales, así que solo un par de comentarios.

Es imposible garantizar 30 minutos, especialmente para todo. Puede decir que es un objetivo, pero no hay forma de que pueda ser una garantía, porque siempre existe el factor X. Podría tener 2 líneas ISP y un camión se estrella contra el edificio y las saca a ambas porque no creía que tenerlas enrutadas desde los extremos opuestos del edificio fuera un ejemplo.

Como comienzo para el costeo, duplique todo. Tienes 5 servidores, por lo que debes duplicar eso. No es necesario que todo esté en hardware, puedes virtualizar, pero ya ves lo que quiero decir. Además de eso, todo debe ser consciente de HA, lo que también aumentará el costo, puede descubrir que tendrá que reemplazar su enrutador por uno nuevo y, por supuesto, necesita 2 de ellos. No olvide duplicar las fuentes de alimentación y obtener el generador, ya que no puede garantizar que la compañía de energía volverá a funcionar en 30 minutos.

Estos ejemplos piensan que es más o menos una configuración de espera activa, que es lo que sospecho que está pensando su jefe.

Lo que encuentro mejor para la pequeña empresa es diseñar un plan para recuperar y clasificar todo.

Averigua qué servicios son

crítico (paradas comerciales)

importante (el negocio se ralentiza)

rutina (las empresas pueden prescindir de ella por un tiempo).

Por ejemplo, sus teléfonos del centro de llamadas son críticos, por lo que tal vez valga la pena comprar un segundo servidor y un segundo ISP y su apagón promedio sea de aproximadamente 15 minutos, por lo que obtendremos un UPS que durará 60 minutos (no olvidar las estaciones de trabajo tampoco). Ahora digamos que el ERP solo es importante, lo que significa que puede funcionar sin él por un tiempo. Tal vez las personas de su centro de llamadas lo usen, pero si está inactivo, pueden volver a usar lápiz y papel o un bloc de notas y luego actualizar el ERP después. El procedimiento para hacerlo si está inactivo puede ser más barato que intentar que sea un servicio crítico. Y los de rutina podrían ser algo así como impresoras, está bien, pero podemos esperar un par de días si todos se caen.

Eso también te da la orden de arreglar las cosas si la mierda realmente golpea al fan algún día :)

¿Es posible? Por supuesto. ¿Es asequible? Probablemente no para una "pequeña empresa", especialmente si tiene un jefe que le da números arbitrarios para trabajar, y está exigiendo una alta disponibilidad de un departamento de TI que consiste en un programador suplente (lo ha visto muchas veces en otros lugares y nunca bonito para sus niveles de estrés, si su situación fuera como la de ellos).

La conmutación por error es posible, pero generalmente requiere hardware redundante, SAN para compartir datos entre servidores, etc., en otras palabras, buena suerte para obtener fondos si no contratan a un administrador dedicado para que se encargue de ello.

El hardware de su sistema de llamadas que mencionó es hardware especializado, y aludió a ser un centro de llamadas. Debería hablar con el proveedor sobre las opciones para hacer que sea redundante. Hacer el tonto con eso podría anular el apoyo en primer lugar.

En otros sistemas, es probable que obtenga cierta redundancia al invertir en soluciones de tipo VMWare (o Hyper-V o XenServer, pero primero miraría VMware y XenServer). Luego, puede buscar obtener una SAN, un par de servidores robustos con conmutadores de red rápidos, y usar LiveMotion para migrar servidores virtualizados entre servidores de hardware si hay una falla, así como equilibrar parte de la carga entre servidores a medida que surjan las necesidades.

Mencionó que está ejecutando Linux en esos sistemas. Con el dinero para obtener múltiples servidores, podría buscar configurar DRBD con un programa heartbeat y STONITH para replicar datos entre servidores y hacerse cargo cuando uno no esté disponible; estaría buscando configurar un sistema donde literalmente haya duplicado cada servidor, así como duplicar su consumo de energía y disipación de calor en la sala de servidores (si tiene una sala de servidores). Eso se puede hacer por el costo del hardware y su cordura. Además, tendría que probarlo, tendría tiempo de inactividad mientras lo configuraba, y aún tiene la posibilidad de que no funcione a veces, ya que todavía existe la posibilidad de que surjan problemas que deben solucionarse (división cerebro, por ejemplo).

El último es un plan para lograr que un par de sistemas actúen como sistemas de pizarra en blanco y tengan un plan de copia de seguridad realmente bueno que le permita restaurar los datos en uno de los sistemas "en blanco" si un servidor muere. Tener hardware en el sitio le dará algunas opciones si / cuando un servidor muere; pero aún tendrá algún tiempo de inactividad mientras restaura los datos, y necesita instrucciones sobre cómo instalar correctamente sus aplicaciones en el nuevo servidor. Dependiendo de qué tan rápido trabaje y qué tan grandes sean los datos, puede tener un tiempo de inactividad que dura desde unas pocas horas hasta uno o dos días. Usted no tiene un trabajo, conocido buena copia de seguridad para sus servidores, con un plan de recuperación en su lugar, ¿no?

¿Deberías intentarlo? Mi primera reacción es que si te rascas la cabeza ante alguna de las sugerencias o sientes un nudo en el estómago al tratar de pensar esto, entonces no deberías. Necesitaría una compañía de consultoría para que revise el problema y calcule los costos e implemente, o necesita contratar a un administrador de sistemas dedicado para que lo haga por su empresa.

El hecho de que te estén diciendo que lo hagas y estás diciendo que eres "solo un programador que fue" promovido "y que tienes un PHB que te dice que des redundancia con un tiempo máximo de falla de 30 minutos es que eres amable de arriba de un arroyo.