Servicios de Windows: escenarios de alta disponibilidad y enfoque de diseño

Question

Digamos que tengo un servicio de Windows independiente que se ejecuta en una máquina con servidor de Windows. ¿Cómo asegurarse de que esté altamente disponible?

1). ¿Cuáles son todas las pautas de nivel de diseño que puede proponer?

2). Cómo hacer que sea altamente disponible como primario/secundario, por ejemplo, las soluciones de clúster actualmente disponibles en el mercado

3). Cómo hacer frente a las preocupaciones transversales en caso de que alguno de conmutación por error escenarios

Si cualquier otro que se pueda imaginar favor añadir aquí ..

Nota: La pregunta está relacionada solamente con las ventanas y ventanas servicios, intente obedecer esta regla :)

Answer 1

Para mantener el servicio funcionando al menos, puede hacer que el Administrador de servicios de Windows reinicie el servicio automáticamente si falla (consulte la pestaña Recuperación en las propiedades del servicio). Hay más detalles disponibles, incluido un script por lotes para establecer estas propiedades - Restart a windows service if it crashes

La alta disponibilidad es más que solo mantener el servicio desde el exterior - el servicio mismo necesita construirse con alta disponibilidad en mente (es decir, usar buenas prácticas de programación, estructuras de datos apropiadas, pares de recursos y lanzamiento), y todo el stress-tested para asegurarse de que permanecerá bajo las cargas esperadas.

Para comandos idempotentes, tolerar fallas intermitentes (como recursos bloqueados) puede lograrse al volver a invocar el comando un cierto número de veces. Esto permite que el servicio proteja al cliente de la falla (hasta cierto punto). El cliente también debe estar codificado para anticipar el error. El cliente puede manejar las fallas del servicio de varias maneras: el registro, la solicitud del usuario, la repetición de X veces, la grabación de un error fatal y la salida son todos los posibles manejadores; cuál es el adecuado para usted depende de sus requisitos. Si el servicio tiene "estado de conversación", cuando el servicio falla (es decir, el proceso se reinicia), el cliente debe conocer y manejar esta situación, ya que generalmente significa que se ha perdido el estado actual de la conversación.

Una sola máquina va a ser vulnerable a fallas de hardware, por lo que si va a utilizar una sola máquina, asegúrese de que tenga componentes redundantes. Las unidades de disco duro son particularmente propensas a fallas, por lo tanto, al menos deben tener unidades duplicadas o una matriz de discos RAID. Las PSU son el siguiente punto débil, por lo que una fuente de alimentación redundante también vale la pena, al igual que un UPS.

En cuanto a la agrupación en clústeres, Windows admite clústeres de servicios y administra los servicios utilizando un nombre de red, en lugar de nombres de equipo individuales. Esto permite que su cliente se conecte a cualquier máquina que ejecute el servicio y no a un nombre codificado. Pero a menos que tome medidas adicionales, esta es la Conmutación por falla de recursos: dirigir las solicitudes de una instancia del servicio a otra. El estado convergente generalmente se pierde. Si sus servicios están escribiendo en una base de datos, entonces también se debe agrupar para garantizar la confiabilidad y garantizar que los cambios estén disponibles para todo el clúster, y no solo para el nodo local.

Esto es solo la punta del iceberg, pero espero que te dé ideas para comenzar a investigar más.

Microsoft Clustering Service (MSCS)

Answer 2

Si analiza los problemas que está tratando de resolver, creo que usted mismo probablemente obtendrá algunas respuestas. Como Justin mencionó en el comentario, no hay una sola respuesta. Depende completamente de lo que hace su servicio y cómo lo usan los clientes. Tampoco especifica ningún detalle sobre la interactividad cliente-servidor. HTTP? TCP? UDP? ¿Otro?

Aquí hay algunas cosas en las que pensar para comenzar.

1) ¿Qué hace si el servicio o servidor se cae?

• ¿Qué tal si ejecutamos más de una instancia de su servicio en servidores separados?

2) Bien, pero ahora, ¿cómo saben los clientes sobre los múltiples servicios?

• que puede codificar la lista en cada cliente (no se recomienda)
• Puede utilizar la rotación en DNS para rebotar solicitudes a través de todos ellos.
• Puede usar un dispositivo de equilibrio de carga.
• Puede tener un servicio separado que conozca todos los demás servicios y pueda dirigir a los clientes a los servicios disponibles.

3) Entonces, ¿qué pasa si un servicio se cae?

• ¿Las aplicaciones del cliente saben qué hacer si el servicio al que están conectadas se cae? Si no, entonces necesitan ser actualizados para manejar esa situación.

Esto debería comenzar con la idea básica de cómo comenzar con alta disponibilidad. Si proporciona detalles específicos sobre su arquitectura, probablemente obtendrá una respuesta mucho mejor.

Answer 3

Si el servicio no expone ninguna interfaz para conectividad de cliente que podía:

• Broadcast o exponer un mensaje de “estoy vivo” o señal de una base de datos/registro/TCP/lo que sea que usted está viva

• Tener un segundo servicio (monitor) que comprueba si estos “estoy vivo” señales y tratar de reiniciar el servicio en caso de que se ha reducido

Pero si tiene un cliente que se conecta a este servicio a través de namedpipes/tcp/etc, el cliente debería verificar la dirección de la máquina con el servicio ejecutándose en una base de datos, o tener algo más elegante como un interruptor inteligente para redirigir el tráfico.