publicar net mvc deploy asp c# asp.net sql-server iis deployment

c# - mvc - ¿Es posible implementar una aplicación ASP.NET de empresa y cambios de esquema de SQL con cero tiempo de inactividad?



iis mvc (9)

Tenemos una gran aplicación web ASP.NET que debe implementarse en LIVE con cero o casi cero tiempo de inactividad. Permítanme señalar que he leído las siguientes preguntas / respuestas, pero desafortunadamente no soluciona nuestros problemas ya que nuestra arquitectura es un poco más complicada.

Digamos que actualmente tenemos dos servidores IIS que responden a las solicitudes y que ambos están conectados al mismo servidor MSSQL. La solución parece ser pan comido, pero no es debido a los cambios de esquema principales que debemos aplicar de vez en cuando. Debido a su gran tamaño, una simple copia de seguridad de la base de datos toma alrededor de 8 minutos, lo que se ha vuelto inaceptable, pero es una necesidad antes de cada nueva implementación por razones de seguridad.

Me gustaría pedirle ayuda para reducir el tiempo de implementación tanto como sea posible. Si tiene ideas geniales para una arquitectura diferente o tal vez ha utilizado herramientas que pueden ayudarnos aquí, no sea tímido y comparta la información.

Actualmente, la mejor idea que se nos ocurrió es comprar otro servidor SQL que se configuraría como una réplica de la base de datos original. Desde el equilibrador de carga, enrutaríamos todo el tráfico nuevo a uno de los dos servidores web IIS. Cuando el segundo servidor web está libre de sesiones en ejecución, podemos implementar el nuevo código. Ahora viene la parte difícil. En este punto, nos desconectaríamos con el sitio web, eliminaríamos la replicación entre los dos servidores SQL, de modo que tengamos una instantánea de la base de datos directamente en un estado esperanzadamente consistente (nos ahorra 7.5 de los 8 minutos). Finalmente, actualizaríamos el esquema de la base de datos en el servidor SQL principal y enrutaríamos todo el tráfico a través del servidor web actualizado mientras estamos actualizando el segundo servidor web a la nueva versión.

Por favor también comparta sus pensamientos con respecto a esta solución. ¿Podemos de alguna manera lograr eliminar la necesidad de desconectarnos con el sitio web? ¿Cómo se implementan las empresas de bluechip con aplicaciones web mammuth?

¡Toda idea o sugerencia es más que bienvenida! Comprar un nuevo hardware o software realmente no es un problema, simplemente nos perdemos la idea de romper. ¡Gracias de antemano por tu ayuda!

Edición 1 (2010.01.12):
Otro requisito es eliminar la intervención manual, de modo que, de hecho, estamos buscando una forma que se pueda aplicar de forma automática.

Permítame recordarle la lista de requisitos:
1. Copia de seguridad de la base de datos
2a. Despliegue de sitio web
2b. Actualización del esquema de base de datos
3. Cambiar a sitio web actualizado
4 (opcional): forma fácil de volver al sitio web anterior si algo va muy mal.

Ambiente:

  1. Sitio web actual en vivo (s)
  2. Base de datos en vivo actual
  3. Nueva versión de sitio web (s)
  4. Nueva versión de base de datos

Enfoque:

  1. Configure un feed (p. Ej., Replicación, un procedimiento almacenado, etc.) para que el servidor de la base de datos en vivo actual envíe actualizaciones de datos a la nueva versión de la base de datos.
  2. Cambie su enrutador para que las nuevas solicitudes apunten a la nueva versión del sitio web hasta que los sitios antiguos ya no estén sirviendo las solicitudes.
  3. Eliminar el sitio antiguo y la base de datos.

En este enfoque, no hay tiempo de inactividad debido a que tanto el sitio antiguo como el nuevo sitio (y sus respectivas bases de datos) tienen permiso para atender solicitudes en paralelo. El único problema es que los clientes que tienen una solicitud van al nuevo servidor y una solicitud posterior va al servidor anterior. En ese escenario, no verán los nuevos datos que podrían haberse creado en el nuevo sitio. Una solución para eso es configurar su enrutador para usar temporalmente las sesiones adhesivas y asegurarse de que todas las nuevas sesiones vayan al nuevo servidor web.

Como dice que no tiene problemas para comprar un nuevo servidor, sugiero que la mejor manera sería conseguir que un nuevo servidor implemente su aplicación allí primero. Siga los pasos a continuación:
1. Agregue cualquier certificado si es necesario a este nuevo servidor y pruebe su aplicación con la nueva configuración.
2. Cierre su antiguo servidor y asigne su IP al nuevo servidor, el tiempo de inactividad sería el mismo que el servidor tarda en cerrar y usted asigna la nueva IP al nuevo servidor.
3. Si ve que la nueva Implementación no está funcionando, siempre puede volver atrás siguiendo el paso 2 nuevamente.
Con respecto a la copia de seguridad de su base de datos, tendría que establecer un programa de copia de seguridad.

En primer lugar, es probable que no conozca el concepto de " restauración en un punto en el tiempo ". En resumen, si realiza una copia de seguridad adecuada de sus registros de transacciones, no importa cuánto demoren sus copias de seguridad, siempre tendrá la capacidad de restaurarlas en cualquier momento . Simplemente restaura su última copia de seguridad y vuelve a aplicar los registros de transacciones desde entonces, y puede obtener una restauración hasta el punto de implementación.

Lo que tiendo a recomendar sería volver a instalar el sitio web en una definición de sitio web diferente con un encabezado de host "muerto" configurado: este es su sitio de almacenamiento provisional. Haga un script que ejecute sus cambios de base de datos todos a la vez (en una transacción) y luego voltea los encabezados de host entre el sitio activo y el sitio de ensayo.

En primer lugar, haga cambios pequeños y regulares. He trabajado como desarrollador independiente en varios Bancos de Inversión principales en varios sistemas de operaciones en vivo 24/7 y el mejor y más suave modelo de implementación que he visto fue implementaciones regulares (mensuales) con un retroceso bien definido estrategia cada vez.

De esta manera, todos los cambios se reducen al mínimo, los errores se solucionan de manera oportuna, el desarrollo no presenta cambios y, como sucede con tanta frecuencia, TODOS están motivados para lograr que el proceso de implementación sea tan automático y sin contratiempos como sea posible.

Pero, inevitablemente, se producen grandes cambios en el esquema que hacen que una reversión sea muy difícil (aunque aún es importante saber, y probar, cómo se realizará la reversión en caso de que sea necesario).

Para estos grandes cambios de esquema, trabajamos un modelo de "cerrar la brecha". Es decir, implementaríamos una capa de transformación de base de datos que se ejecutaría casi en tiempo real, actualizando una copia en vivo de los nuevos datos de esquema de estilo en una segunda base de datos, en función de los datos en vivo en el sistema implementado actualmente.

Copiaríamos esto un par de veces al día a un sistema UAT y lo utilizaríamos como base para las pruebas (por lo tanto, los evaluadores siempre tienen un conjunto de datos realistas para probar, y la capa de transformación se está probando como parte de eso).

Por lo tanto, el cambio en la base de datos se está ejecutando continuamente en vivo, y la implementación del nuevo sistema es simplemente un caso de:

  1. Congelar a todos fuera
  2. Apagar la capa de transformación
  3. Activando la nueva capa de aplicación
  4. Cambio de usuarios a la nueva capa de aplicación
  5. Descongelar todo

Sin embargo, aquí es donde la reversión se convierte en un problema. Si el nuevo sistema se ha ejecutado durante una hora, no es fácil volver al sistema anterior. Una capa de transformación inversa sería lo ideal, pero no creo que alguna vez hayamos tenido a alguien que comprenda la idea de dedicarle tiempo.

Al final, lo desplegaríamos durante el período más tranquilo posible y lograríamos que todos estuvieran de acuerdo en que la reversión nos llevaría al punto de cambio y todo lo que faltara se tendría que volver a ingresar manualmente. Eso sí, eso motiva a las personas a probar cosas correctamente :)

Finalmente, cómo hacer la capa de transformación, en algunos de los casos más simples, usamos los activadores en la propia base de datos. Solo una vez creo que injertamos código en una versión anterior que hizo ''actualizaciones dobles'', la actualización original al sistema actual y otra actualización al nuevo esquema de estilo. La intención era lanzar el nuevo sistema en la próxima versión, pero las pruebas revelaron la necesidad de ajustes en la base de datos y la "capa de transformación" estaba en producción en ese momento, por lo que el proceso se complicó.

El modelo que utilizamos con mayor frecuencia para la capa de transformación fue simplemente otro proceso del servidor en ejecución, observando la base de datos y actualizando la nueva base de datos en función de los cambios. Esto funcionó bien ya que el código se está ejecutando fuera de la producción, se puede cambiar a voluntad sin afectar el sistema de producción (bueno, si se ejecuta en una réplica de la base de datos de producción, puede hacerlo, pero de lo contrario debe tener cuidado de no vincular la producción). base de datos con algunas consultas suicidas - ¡simplemente ponga a los mejores individuos más conscientes en esta parte del código!)

De todos modos, perdón por el largo viaje, espero que haya dejado de lado la idea, hago la implementación de la base de datos continuamente como una implementación ''en vivo'' en una segunda base de datos, entonces todo lo que tiene que hacer para implementar el nuevo sistema es implementar la aplicación Capa y canaliza todo para ello.

Recomendaría utilizar Analysis Services en lugar del motor de base de datos para sus necesidades de informes. Luego, podría procesar sus cubos ... mover su base de datos ... cambiar una cadena de conexión, volver a procesar sus cubos y, por lo tanto, tener cero tiempo de inactividad.

Muerto en serio ... No hay un producto mejor en el mundo que Analysis Services para este tipo de cosas.

Una posibilidad sería utilizar el control de versiones en su base de datos.

Así que tiene una configuración global que define la versión actual de todos los procedimientos almacenados para usar.

When you come to do a release you do the following: 1. Change database schema, ensuring no stored procedures of the previous version are broken. 2. Release the next version of stored procedures 3. Change the global setting, which switches the application to use the next set of stored procedures/new schema.

La parte difícil es asegurarse de que no rompa nada cuando cambia el esquema de la base de datos.

Si necesita realizar cambios fundamentales, deberá usar tablas ''temporales'', que se usan para una versión, antes de pasar al esquema que desea en la próxima versión, o puede modificar los procedimientos almacenados de las versiones anteriores para mas flexible.

Eso debería significar casi cero tiempos de inactividad, si puede hacerlo bien.