Desafíos y mejores prácticas para servicios que fallan

Question

¿Alguien conoce alguna de las mejores prácticas establecidas para ejecutar servicios de Windows (en mi caso, desarrollada en .NET) para que puedan (automáticamente) conmutar correctamente a otro servidor, para alta disponibilidad ¿Propósitos?

Las principales formas en que veo que esto se hace son iniciar el servidor secundario cuando sea necesario (en cuyo caso debe haber algo supervisando el otro servidor) o tener ambos servicios funcionando juntos (en cuyo caso necesitan sincronice su trabajo para que no intenten hacer las mismas cosas).

¿Hay un patrón o modelo para este tipo de problema? Sé que la situación exacta marcará una gran diferencia, pero parece ser un problema bastante común.

Gracias

John

Answer 1

Esto es lo que funcionó para mí.

Desde el punto de vista de la infraestructura, necesitará tener 2 servidores de Windows agrupados. (2 cajas estándar de Windows Server funcionarán, la pieza de Clustering puede instalarse y configurarse, la mayoría de administradores de sistemas deberían saber cómo hacer esto). A continuación, instale su servicio en ambos nodos del clúster y póngalos APAGADOS y configurados en MANUAL. puesta en marcha. A continuación, agregue un recurso agrupado al Administrador de clúster de Windows para su servicio que administrará el encendido y apagado de su servicio en el nodo que esté activo. Deje que el clúster de Windows administre cuando se está ejecutando su servicio y en qué nodo. Esta es la parte fácil de agrupar su servicio.

Desde el punto de vista del servicio, querrá diseñar su servicio para que pueda ser lo más uniforme posible. Este es un tipo de consejo poco convincente, pero realmente depende de lo que esté haciendo su servicio. En el diseño, solo asuma que en algún punto durante la vida del código se detendrá en el peor momento posible. ¿Cómo sabrá el servicio en el nodo 2 dónde recoger donde quedó el nodo1? Esa es la parte más difícil para la que necesitas diseñar. Dependiendo de lo que esté haciendo su servicio, puede dejar la última tarea completada en una tabla db o en un archivo de datos compartido. También puede hacer que comience desde el principio y verificar si esa tarea se ha completado o no antes de actuar sobre ella.

De nuevo, realmente va a depender de lo que el servicio necesita para lograr. Espero que esto ayude.

Answer 2

que tengan las dos funcionando todo el tiempo es probablemente la solución más simple, pero hay que asegurarse de que usted nunca por encima de 50% de carga, de lo contrario cuando uno falla, el otro estará sobrecargada y quizás también falle.

Para sincronizar, use una base de datos transaccional. Tratar de escribir su propia sincronización generalmente resultará en errores.

Answer 3

Si puede tener ambos servicios funcionando, es mejor. necesita asegurarse de que son apátridas o saben cómo manejar el problema de estado, y Databse se sincronizará entre ellos. En un único punto de falla: enviará el problema a la base de datos, y allí podrá tener un clúster activo activo de 2 nodos y dejar que el fabricante de DB maneje los problemas de sincronización.

Answer 4

Creo que la mejor forma de tratar la conmutación por error es a nivel de red siempre que sea posible. Las IP virtuales que se encuentran frente a entornos de equilibrio de carga o entornos primarios/de conmutación por error son una buena forma de evitar tener que escribir código para escenarios de conmutación por error.

En los casos en que debe manejar la conmutación por error en el código:

1. llamada de conexión de prueba/servicio
2. Si la prueba falla, enviar alertas
3. conmutación por error a lado extremo de servicio "registrado"

Answer 5

Hay dos enfoques básicos.

1. los clientes son conscientes de la diferente dirección de punto final y cambian según sea necesario o según lo indique otro servicio o mecanismo de configuración. (como un ejemplo, stocktrader demo application hace esto.)

2. Los clientes no son conscientes, y utiliza un enfoque de equilibrio de carga de red estándar que también puede proporcionar conmutación por error. F5 es un producto. Hay muchos otros Básicamente es como un NAT para todos los servicios, todas las solicitudes pasan por su NLB y las envía a un servidor, y reenvía la respuesta a la persona que llama. Estos productos monitorean los servicios y solo usan los que están activos. Además, a menudo puede personalizarlo con reglas para que asigne nuevas solicitudes a los servidores en función de las cargas de trabajo del servidor. Windows server has this funcionalidad incorporada hasta cierto punto.

De cualquier modo que lo haga, es mucho más fácil si sus llamadas de servicio son "sin estado".