Sesiones a prueba de balas para IIS Web Farm

Question

Buenas tardes, todas.

Actualmente estamos dando el salto de un servidor web a dos y con el fin de proporcionar conmutación por error sin problemas a nuestros usuarios, tenemos que hacer algo con respecto a la sesión.

Actualmente, estamos investigando tres métodos diferentes.

1. Hacer uso de un servidor de estado
uso
2. Hacer del servidor SQL
3. Chuck todo en campos ocultos

Yo, personalmente, les gustaría ver la opción número uno para en su lugar a medida que no tiene una base de datos dedicada para la opción número dos y la opción número tres parece un truco desordenado.

El problema que enfrento actualmente es que mi gerente no está satisfecho con el único punto de falla proporcionado por un servidor de estado (nuestro servidor SQL está replicado, por lo que no hay problemas).

¿Se puede hacer algo para replicar el servidor de estado o algo así?

Answer 1

Después de investigar un poco más, hemos decidido ir con la opción StateServer. Todavía estamos buscando ver cómo superar el punto único de falla en el StateServer y hemos descubierto otras dos vías de investigación.

Nuestra primera opción es utilizar un programa de terceros para manejar las sesiones. El que estamos viendo ahora se llama nCache: creo que hay otro llamado ScaleOut que también podemos ver.

Opción número dos es el uso de Paritioning estado de sesión y actualmente estamos investigando esta opción, así: http://msdn.microsoft.com/en-gb/magazine/cc163730.aspx

Answer 2

Que yo sepa, no hay forma de hacer una copia de seguridad o replicar su servicio StateServer. Otro problema al usar StateServer en una granja de servidores web es que si su clúster permite que el mismo navegador llegue a diferentes máquinas en diferentes solicitudes, podrían tener diferentes datos de sesión en cada solicitud. (Editar: Martin señaló a continuación que puede solucionar esto compartiendo una única instancia de StateServer entre múltiples servidores web). Para sus propósitos, la opción 2 o 3 sería más tolerante a fallas, y agregaré otra idea: para pequeños fragmentos de datos intente usar cookies para el almacenamiento de la sesión.

Answer 3

También asegúrese de no estar utilizando SQL Server para almacenar el estado de sesión que acaba de salir de la base de datos. Si es así, también puede llamar a la base de datos cada vez.

Answer 4

Creo que se está mudando a otra arquitectura: más de un Front End IIS.

¿Vas a utilizar NLB?

• Si es así, su mejor opción es utilizar un servidor de estado, se jugará como un servidor de aplicaciones en concepto.

Aquí en mi empresa estamos migrando la aplicación .NET a dos IIS con Equilibrio de carga de red, y las aplicaciones suelen tener administración de sesión en el proceso.

Hemos investigado que no había otra alternativa:

• usando la afinidad del cliente en la configuración de NLB, lo que permite la devolución de datos para volver a la IIS donde se generó el proceso, el precio era perder toda la NLB ...

Después de asesoría de Microsoft, la mejor opción era el servidor de estado :)

Espero que ayude!

¡Atentamente!

Answer 5

Puede ser doloroso, pero he decidido desactivar la sesión y enfrentar las consecuencias. Hasta ahora no ha surgido nada insuperable.