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

Question

Vamos a decir que tengo un servicio de Windows independiente que se ejecuta en una máquina servidor de ventanas. Cómo asegurarse de que es altamente disponible?

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

2). Cómo hacer que sea altamente disponible como primario / secundario, por ejemplo., Las soluciones de clustering disponibles actualmente 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 los servicios de Windows, por favor intente obedecer a esta regla:)

Answer 1

Para mantener el servicio al menos correr se puede organizar para el Administrador de servicios de Windows para reiniciar automáticamente el servicio si se bloquea (véase la ficha Recuperación de las propiedades del servicio.) Más detalles están disponibles aquí, incluyendo una secuencia de comandos por lotes para establecer estos propiedades - reiniciar un servicio de windows si se bloquea

La alta disponibilidad es más que mantener el servicio desde el exterior - el servicio en sí tiene que ser construido con alta availabiity en cuenta (es decir, el uso buena prácticas de programación en todo, estructuras de datos apropiadas, pares aquire de recursos y de liberación), y el toda prueba de estrés para asegurar que permanecerá bajo cargas esperadas.

Para los comandos idempotente, tolerando fallos intermitentes (tales como recursos bloqueados) se puede lograr mediante la re-invocar el comando de un cierto número de veces. Esto permite que el servicio para proteger al cliente de la falta (hasta un punto). El cliente también debe codificarse para anticipar el fracaso. El cliente puede manejar fallo en el servicio de varias maneras - el registro, indicando al usuario, volver a intentar X veces, registrando un error fatal y salida son posibles todos los manipuladores - cuál es el adecuado para usted depende de sus necesidades. Si el servicio tiene "estado de conversación", cuando el servicio falla duro (es decir, el proceso se reinicia), el cliente debe conocer y manejar THS situación, ya que por lo general significa el estado actual de la conversación se ha perdido.

Una sola máquina va a ser vulnerable a fallos de hardware, por lo que si usted va a utilizar una sola máquina, y luego asegurarse de que tiene componentes redundantes. Discos duros son particularmente propensos a fallo, por lo que tienen por lo menos unidades duplicadas, o una matriz RAID. Fuentes de alimentación son el siguiente punto débil, por lo que la fuente de alimentación redundante También vale la pena, ya que es un SAI.

En cuanto a la agrupación, Windows es compatible con la agrupación de servicios, y gestiona servicios utilizando un nombre de red, en lugar de nombres de equipo individual. Esto permite que el cliente se conecte a cualquier máquina que ejecuta el servicio y no un nombre codificado. Pero a menos que tome medidas adicionales, esto es la conmutación por error de recursos - que dirigen las peticiones de una instancia del servicio a otro. Estado converstaion normalmente se pierde. Si sus servicios están escribiendo a una base de datos, a continuación, que debe también ser agrupados para también garantizar y asegurar reliabiity cambios están a disposición de todo el clúster, y no sólo el nodo local.

Esto es realmente sólo la punta del iceberg, pero espero que le da ideas para empezar a trabajar en la investigación adicional.

Microsoft Clustering Service (MSCS)

Answer 2

Si usted analiza los problemas que están tratando de resolver, creo que probablemente va a llegar a algunas respuestas usted mismo. Como Justin menciona en el comentario, no hay una respuesta. Depende completamente de lo que hace su servicio y cómo los clientes utilizan. También no se especifica ningún detalle acerca de la interactividad cliente-servidor. HTTP? TCP? UDP? Otro?

Aquí hay algunas cosas en que pensar para empezar.

1) ¿Qué hacer si el servicio o el servidor deja de funcionar?

• ¿Qué hay de ejecutar más de una instancia de su servicio en servidores separados?

2) Ok, pero ahora ¿cómo los clientes saben acerca de los múltiples servicios?

• Puede codificar la lista en cada cliente (no recomendado)
• Se puede utilizar DNS round-robin a las solicitudes de rebote a través de todos ellos.
• Se puede utilizar un dispositivo de balanceo de carga.
• Usted puede tener un servicio independiente que sabe acerca de todos los otros servicios y se puede dirigir a los clientes a los servicios disponibles.

3) Entonces, ¿qué si un servicio deja de funcionar?

• ¿Las aplicaciones cliente sabe qué hacer si el servicio que están conectados a deja de funcionar? Si no es así, entonces tienen que actualizarse para manejar esa situación.

Esto debería empezar con la idea básica de cómo empezar a trabajar con alta disponibilidad. Si usted proporciona detalles específicos acerca de su arquitectura, es probable que obtener 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ñalar un / registro / TCP / lo que sea que usted está vivo

base de datos

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

Sin embargo, si usted tiene un cliente que se conecta a este servicio a través NamedPipes / TCP / etc, el cliente tendría que comprobar la dirección de la máquina con el servicio que se ejecuta en una base de datos, o si tiene algo más elaborado como un conmutador inteligente al tráfico de redirección .