Preguntas sobre puntos únicos de falla para operaciones pequeñas

1. Si no puede permitirse el lujo o no necesita un clúster o un servidor de reserva esperando para conectarse en caso de falla, parece que podría dividir los servicios proporcionados por un servidor robusto en dos servidores menos robustos. Por lo tanto, si el Servidor A deja de funcionar, los clientes pueden perder el acceso al correo electrónico, por ejemplo, y si el Servidor B deja de funcionar, pueden perder el acceso al sistema ERP .

   Si bien al principio esto parece ser más confiable, ¿no aumenta simplemente la posibilidad de falla del hardware? Por lo tanto, cualquier falla no tendrá un impacto tan grande en la productividad, pero ahora se está preparando para el doble de fallas.

   Cuando digo "menos fornido", lo que realmente quiero decir es menor especificación de componentes, no menor calidad. Entonces, una especificación de máquina para visualización frente a dos servidores especificados por menos carga cada uno.

2. Muchas veces se recomienda una SAN para que pueda usar clustering o migración para mantener los servicios en funcionamiento. Pero, ¿qué pasa con la propia SAN? Si tuviera que invertir dinero en un lugar donde ocurrirá una falla, no será en el hardware básico del servidor, tendrá algo que ver con el almacenamiento. Si no tiene algún tipo de SAN redundante, esos servidores redundantes no me darían una gran sensación de confianza. Personalmente, para una operación pequeña, tendría más sentido para mí invertir en servidores con componentes redundantes y unidades locales. Puedo ver un beneficio en operaciones más grandes donde el precio y la flexibilidad de una SAN es rentable. Pero para las tiendas más pequeñas no veo el argumento, al menos no para la tolerancia a fallas.

Todo esto se reduce a la gestión de riesgos. Hacer un análisis adecuado de costo / riesgo de sus sistemas de TI lo ayudará a determinar dónde gastar el dinero y con qué riesgos puede o tiene que vivir. Hay un costo asociado con todo ... esto incluye HA y tiempo de inactividad.

Trabajo en un lugar pequeño, así que entiendo esta lucha y el geek de TI en mí no quiere puntos únicos de falla en ninguna parte, pero el costo de hacerlo en todos los niveles no es una opción realista. Pero aquí hay algunas cosas que he podido hacer sin tener un gran presupuesto. Sin embargo, esto no siempre significa eliminar el único punto de falla.

Network Edge : Tenemos 2 conexiones a Internet, una T1 y Comcast Business. Planeamos mover nuestro firewall a un par de computadoras viejas que ejecutan pfSense usando CARP para HA.

Red : obtener un par de conmutadores administrados para el núcleo de la red y usar la vinculación para dividir los servidores críticos entre los dos conmutadores evita que una falla del conmutador elimine todo el armario de datos.

Servidores : todos los servidores tienen RAID y fuentes de alimentación redundantes.

Servidor de respaldo : Tengo un sistema más antiguo que no es tan poderoso como el servidor de archivos principal pero tiene algunas unidades sata grandes en raid5 que toma instantáneas por hora del servidor de archivos principal. Tengo una configuración de scripts para que esto cambie los roles para ser el servidor de archivos principal en caso de que se caiga.

Servidor de respaldo externo : similar al respaldo en el sitio, hacemos respaldos nocturnos a un servidor a través de un túnel vpn a la casa de uno de los propietarios.

Máquinas virtuales : tengo un par de servidores físicos que ejecutan una serie de servicios dentro de las máquinas virtuales con Xen. Estos se ejecutan desde un recurso compartido NFS en el servidor de archivos principal y puedo hacer una migración en vivo entre los servidores físicos si surge la necesidad.

Creo que esta es una pregunta con muchas respuestas, pero estaría de acuerdo en que en muchas tiendas más pequeñas la solución de varios servidores funciona y, como usted dice, al menos algo continúa si hay una falla. Pero depende de lo que falla.

Es muy difícil cubrir todas las bases, pero pueden ser útiles las fuentes de alimentación redundantes, la alimentación de buena calidad y las buenas copias de seguridad.

Hemos utilizado Backup Exec System Recovery para algunos sistemas críticos. No tanto para el respaldo diario sino como una herramienta de recuperación. Podemos restaurar a hardware diferente, si está disponible, y también utilizamos el software para convertir la imagen de copia de seguridad en una máquina virtual. Si el servidor falla y necesitamos esperar reparaciones de hardware, podemos iniciar una VM en un servidor o estación de trabajo diferente y seguir adelante. No es perfecto, pero puede estar funcionando rápidamente.

Con respecto a las SAN: casi todo lo que use será redundante. Incluso si se trata de una sola carcasa, en el interior habrá dos fuentes de alimentación, dos conectores y dos 'cabezales', cada uno con enlaces a todos los discos. Incluso algo tan simple como un MD3000 vendido por Dell tiene todas estas características. Las SAN están diseñadas para ser el núcleo de sus cajas, por lo que están diseñadas para sobrevivir a casi cualquier falla aleatoria de hardware.

Dicho esto, tienes un punto de que la redundancia no siempre es la mejor opción. ESPECIALMENTE si aumenta la complejidad. (y lo hará) Una mejor pregunta es ... "¿Cuánto aceptará la empresa el tiempo de inactividad"? Si la pérdida de su servidor de correo durante un día o dos no es un gran problema, entonces probablemente no debería molestarse con dos de ellos. Pero si una interrupción del servidor web comienza a perder dinero real cada minuto, entonces tal vez debería pasar el tiempo haciendo un grupo adecuado para ello.

Cuantos más servidores tenga, más posibilidades hay de que algo se rompa, esa es una forma de verlo. Otra es que si uno se rompe, estás al 100%, también como estás diciendo.

La falla de hardware más común es HD, como dijiste anteriormente. Independientemente de cuánto desee dividir las operaciones, debe RAIDing su almacenamiento.

Yo votaría por un par de servidores (RAID por supuesto) en lugar de uno masivo, tanto por la estabilidad de las operaciones como por el rendimiento. Menos software chocando con cada pedido de recursos, menos desorden, más discos para leer / escribir, y así sucesivamente.

Yo personalmente optaría por varios servidores. No creo que la falla del equipo sea más probable en este escenario. Sí, tiene más equipos que podrían fallar, pero las probabilidades de que falle una unidad determinada deberían ser constantes.

Lo que me brinda tener múltiples servidores en una configuración no redundante / no HA es la capacidad de descargar parte del trabajo a otro servidor en caso de falla. Entonces, digamos que mi servidor de impresión se cae. Si puedo asignar algunas impresoras al servidor de archivos mientras estoy arreglando el servidor de impresión, el impacto en las operaciones se reduce. Y ahí es donde realmente importa. A menudo tendemos a hablar de redundancia de hardware, pero el hardware es solo una herramienta para la continuidad de las operaciones.

Trabajo en una pequeña tienda (departamento de TI de un solo hombre) y no cambiaría mis servidores múltiples por uno solo bajo ninguna circunstancia. Si alguno de los servidores se cae, tengo la opción de agregar los servicios que ahora faltan a otra máquina o incluso simplemente configurarlos en una PC de repuesto. Podemos vivir con una interrupción de una o dos horas para la mayoría de las cosas, pero no podemos vivir con una interrupción completa de todos los sistemas. Si bien puedo reemplazar cualquiera de nuestros servidores con una PC, al menos temporalmente, no tengo ni puedo conseguir nada que sea lo suficientemente potente como para reemplazar todos los servidores a la vez.

Su publicación original plantea la hipótesis de que no puede permitirse un clúster, pero considera soluciones con dos servidores (sin incluir copias de seguridad). Eso implicaría que lo más probable es que tenga tres servidores disponibles, suficiente para iniciar un clúster.

Existen soluciones intermedias que pueden evitar SPoF y seguir siendo apropiadas en pequeñas y medianas empresas: replicación de nodo a nodo sin almacenamiento SAN.

Esto es compatible, por ejemplo, con Proxmox (pero creo que también es compatible con XCP-ng / XenServer y probablemente con ESXi).

Consideremos una configuración de 3 nodos. Todo con RAID, PSU redundante, red redundante.

• Los nodos A y B tienen una CPU robusta y mucha RAM.
• El nodo C es más modesto en CPU / RAM pero tiene mucho almacenamiento y se utiliza para proporcionar quórum al watchdog de alta disponibilidad y copias de seguridad del host.

Entonces dos opciones:

1. Todas las máquinas virtuales normalmente se ejecutan en el nodo A y se replican en el nodo B (lo que requiere una CPU decente)
2. Las máquinas virtuales se dividen entre el nodo A y B, y se replican mutuamente algunas del nodo A al nodo B y del nodo B al nodo A.

Este tipo de configuración puede tolerar una falla de red, una falla de nodo total y mayor (cualquiera de las tres), con un tiempo de inactividad de aproximadamente 1 minuto (aproximadamente el tiempo necesario para que una VM arranque). La desventaja es la pérdida de datos desde la última replicación (que dependiendo de su configuración y rendimiento del hardware puede ser tan baja como 1 minuto y tan alta como unas pocas horas).

Con la segunda opción (VM normalmente dividida entre los nodos A y B), debe priorizar qué VM puede volver a conectarse. Dado que, como su carga de VM generalmente se divide entre dos servidores, hacer que todos se ejecuten en un solo nodo puede agotar la RAM del nodo o congestionar la CPU.

"Si bien al principio esto parece ser más confiable, ¿no aumenta simplemente la posibilidad de falla del hardware?"

• Desde el punto de vista del hardware, no veo cómo aumenta prácticamente las posibilidades de falla. Aquí hay muchas variables, y nunca he estudiado la probabilidad, pero para simplificar en exceso: Digamos que Dell hace 1 servidor defectuoso por cada 100,000 que hacen. Sus posibilidades han cambiado de 1 en 100,000 a 2 en 100,000 (o 1 en 50,000). Entonces, sí, el doble de posibilidades, pero aún así debido a la escala, las posibilidades prácticamente no son tan diferentes.
• Creo que la perspectiva es clave aquí. "Te estás preparando para el doble de fallas". Tal vez desde su perspectiva, pero en los dos escenarios que dio, el correo electrónico se ejecuta en un servidor y ERP se ejecuta en un servidor. Entonces, desde la perspectiva del correo electrónico o erp (que es lo que le importa a la empresa), es realmente lo mismo. A menos que se sientan solos, o les guste su espacio ;-)
• Creo que también deberías mirarlo desde el punto de vista de las personas. Creo que la falla debido a errores de la gente es probablemente más probable, y de esta manera alguien probablemente solo arruinaría un servidor a la vez. También facilita la identificación de problemas con cosas como la carga. Si tanto el correo electrónico como un sitio web se ejecutan en un servidor, tiempo adicional para averiguar dónde está el problema.

Nunca es así de simple, los servidores grandes y robustos pueden estar mejor o peor. Pueden tener piezas de mayor calidad, pero tal vez generan más calor y no se enfrían adecuadamente. Un servidor robusto tiene más RAM, más CPU, etc., por lo que al final tal vez tenga la misma cantidad de CPU en ambos escenarios, por lo que tal vez un servidor no sea la unidad correcta para pensar.

Debido a la complejidad de las posibilidades, creo que lo que sea más rentable gana. Si tiene que pagar licencias, 1 servidor grande puede ser más barato que algunos servidores más pequeños, dependiendo de la estructura de licencias.

Mi enfoque predeterminado es evitar cualquier infraestructura centralizada. Por ejemplo, esto significa que no hay SAN , ni Load Balancer . También puede llamar a este enfoque centralizado "monolítico".

Como arquitecto de software, estoy trabajando con la infraestructura del cliente. Eso podría significar usar su propio centro de datos privado o usar algo como AWS. Por lo tanto, generalmente no tengo control sobre si usan una SAN o no. Pero mi software generalmente abarca varios clientes, por lo que lo construyo como si se ejecutara en máquinas individuales de forma aislada en una red.

El ejemplo de correo electrónico

El correo electrónico es extraño, porque es un sistema heredado (que funciona). Si el correo electrónico se inventara hoy, probablemente usaría las API RESTFul en servidores web, y los datos estarían en una base de datos que podría replicarse usando herramientas normales (Replicación transaccional, Copias de seguridad incrementales).

La solución de arquitectura de software es que una aplicación web se conectaría a uno de una lista de nodos disponibles (al azar), y si no está disponible, intentará conectarse a otro nodo (al azar). Un cliente puede ser expulsado de un servidor si está demasiado ocupado. Aquí, no es necesario un equilibrador de carga para conectarse a una granja de servidores web; y, no hay necesidad de una SAN para alta disponibilidad. También es posible fragmentar la base de datos por departamento o geografía.

Mercancía significa ...

Por lo tanto, en lugar de tener 1 o 2 servidores caros y una SAN con medidas de redundancia interna, puede usar varias máquinas de bajo costo y bajo consumo.

• Simplicidad : la redundancia proviene únicamente de la cantidad de dispositivos. Puede verificar fácilmente su redundancia por la cantidad de máquinas. Y usted estima más correctamente que tienen una mayor probabilidad de fracaso y se prepara para eso.

• Porcentaje de redundancia : si tiene 2 servidores, si uno falla, le queda 1 (50%). Si tiene 10 servidores básicos y uno falla, le quedan 9 (90%)

• Inventario : un dispositivo básico está disponible en cualquier tienda cercana a un precio excelente.

• Compatibilidad : con canales de fibra y todo tipo de estándares para formatos de volumen de disco, dispositivos básicos y arquitectura de software significa que no está bloqueado en un solo modelo o marca de dispositivo.

• Rendimiento : con 2 dispositivos en SAN, deben estar en la misma habitación. Con el enfoque de máquina de productos básicos, si tiene 5 oficinas, puede tener 2 en cada oficina, con redundancia VPN WAN entre oficinas. Esto significa que el software y las comunicaciones están en la LAN a <1 ms de tiempo de acceso.

• Seguridad : basándose en el alto nivel de redundancia, puede reconstruir fácilmente los nodos como un proceso regular de productos básicos. ¿Desea reconstruir un clúster monolítico de 2 servidores? Saca el manual. Al reconstruir las máquinas a menudo (con automatización), mantiene actualizado el software y evita que cualquier hacker o virus se establezca en su red.

Nota: aún necesitaría tener redundancia de conmutador múltiple y enrutador de puerta de enlace