Actualización del sitio web de producción IIS y la base de datos SQL Server sin parar

Question

Hay un servidor de prueba que utiliza la base de datos de prueba. Probamos el sitio web en el servidor de prueba. Si está bien, actualizamos el sitio web y el esquema de la base de datos desde el servidor de prueba al servidor de producción. Pero este método es muy doloroso y arriesgado.

Primero, tenemos que redirigir a los usuarios a una página de mantenimiento, por lo que el sitio web se detiene por un tiempo.

Segundo, si algo sale mal cuando se actualiza, tenemos que volver al sitio web antiguo, porque no podemos poner el sitio web en un modo de mantenimiento durante mucho tiempo.

Así que busco una solución sólida para actualizar un sitio web de IIS y una base de datos de SQL Server sin pérdida de datos y utilizando el modo de mantenimiento. ¿Hay alguna forma de hacer esto? Cómo los sitios web grandes hacen esto sin pérdida de datos y de pausa.

Hemos pensado utilizar un sitio web de candidatos de liberación. Hemos planeado usar este sitio web de RC para temporal. Primero, actualizamos el sitio RC, luego cambiamos los enlaces entre RC y sitio web de producción. Pero esta vez la base de datos es problema. Debido a que podemos cambiar el esquema de la base de datos, y el anterior no puede funcionar con una nueva base de datos. Por lo tanto, si usamos un sitio de TEMP con TEMP DB, habrá pérdida de datos. Además, el sitio web actualizado no funcionará con la base de datos antigua si el sitio TEMP utiliza la base de datos de producción antigua. Así que necesito una solución sólida y práctica para este problema.

Answer 1

Esto es órdenes de magnitud más complicada de lo que imaginas. Esto específicamente es no sobre HA ni sobre integración contigua. Ninguno de ellos proporcionará lo que necesita, son solo piezas del rompecabezas mucho más complejo.

Simplemente no es posible escribir cambios de código de una manera que sea transparente / ajeno a los cambios de esquema a medida que ocurren . En el mejor de los casos, puede escribir el código de una manera que admita el esquema en v. N y en v. N + 1, que en sí mismo es un gran desafío. Pero es imposible escribir el código de una manera que admita el esquema a medida que transica de v. N a v. N + 1. El cambio de esquema inducido por un despliegue debe ser atómico para el código que opera en el esquema. Dado que el cambio de esquema en sí no puede ser atómico, sigue que la actualización tiene dos avenidas posibles:

• Tome el código fuera de línea durante el cambio de esquema. Esto es lo que estás haciendo ahora y es el enfoque más seguro. Por supuesto, implica la disponibilidad de servicios en el tiempo de inactividad y ejecuta los riesgos que ya experimentó (Rollback de actualización fallida, actualización prolongada, etc.). Una variante de este enfoque es redirigir el servicio a una copia de solo lectura de los datos y ofrecer una experiencia de servicio degradada (no hay cambios posibles durante el tiempo de inactividad), lo que puede o no ser aceptable, dependiendo de los aspectos del negocio.

• Actualización de espera. Esto implica que usted toma una instantánea de los datos de servicio (varias soluciones de HA pueden proporcionar una instantánea de espera fuera de la caja, por ejemplo, el envío de registros). Actualice la instantánea, luego aplique todas las transacciones que se produzcan en los datos de servicio real en la instantánea actualizada. Esto siempre es complicado, porque requiere una tecnología para detectar, capturar y aplicar los cambios (por ejemplo, el seguimiento de cambios, la replicación, la solución personalizada, etc.) y requiere transformar cada cambio al nuevo, actualizado, esquema . Una vez que el esquema actualizado esté actualizado con los cambios del servicio principal, el servicio puede ser redirigido al esquema actualizado. Esta redirección también es mucho más compleja de lo que suena. Para elegir el momento en que se elimine el esquema anterior y deje de aceptar nuevos cambios, mientras se asegura de que los cambios se aplicaron a los nuevos cambios de esquema actualizado, es un desafío en sí mismo. Otro desafío es resolver el conflicto del Código comprendiendo las versiones previas a la actualización y el esquema posterior a la mejora. Desarrollo de código que maneja ambos es, como dije, es problemático y propenso a errores, por lo que una solución es, nuevamente, tomar el servicio fuera de línea por un período corto y reemplazar el código. Otra solución es tener un STANDBY Service , código de ejecución que maneja el esquema DB de post-actualización y está conectado a la DB de la actualización posterior a la actualización y redirige las solicitudes en vivo a su reserva, actualizado, servicio. < / p>

  Y ni siquiera tocó el tema espinoso de la interacción de servicio, cuando se debe actualizar un servicio particular de una solución desplegada mucho mayor. Esto es cuando Service API Protocol Atrás compatibilidad Juega El papel principal para permitir que el servicio post-actualización se desempeñe junto con sus servicios de pares.

  En última instancia, simplemente no hay ninguna bala de plata. He presenciado la máquina única de implementaciones de DB grandes que tomaron semanas para desplegar la versión N + 1, con la replicación transcripcional que alimenta contactamente el esquema de DB de la actualización posterior a los cambios de la DB de actualización previa. Y presencié las implementaciones de miles de máquinas que implementan la versión N + 1 en etapas, como un baile complicado de habilitar el código y los cambios de datos a lo largo de varios días para alcanzar la funcionalidad completa de la actualización posterior a la actualización. Este problema es simplemente claro duro .

Answer 2

Esto es lo que Azure es fantástico.La plataforma Azure Cloud permite la etapa de servidores y servidores de producción.Puede configurarlo de modo que una vez que confirque sus cambios en Git o TFS, se presiona automáticamente con un servidor de estadificación o producción automáticamente.También puede configurar para empujar manualmente los cambios.La mayoría de las bibliotecas ORM como el marco de entidades tienen soporte de migración.

Hay mucha más información en este tema como: Azure Actualización perfecta Cuando el esquema de la base de datos cambia ¿Estadio o instancia de producción?

Answer 3

Usted describe una solución de alta disponibilidad (ha).Las soluciones de HA son caras y se pueden exagerar rápidamente.Necesitaría redundancia para su aplicación y servidores DB, lo que significa configurar un clúster DB.Todo esto aumenta la cantidad de tiempo que gastaría implementar cambios, pero la compensación es que su aplicación siempre está disponible.

Lo principal con la implementación es tener un proceso repetible.Así que mi mejor recomendación es ser guión o automatizar lo más posible.