Escribo esto porque acabo de llegar a mi cueva después de un ajetreado día de trabajo, mejor dicho, una ajetreada que me despegó del mundo unas 5 horas consecutivas. Inicié a las 05:00 PM a 10:00 PM aproximadamente. Me refiero a una migración de bases de datos de un servidor a otro, los servidores son IAAS en Azure con Windows Server 2012 R2, eran 14 bases de datos de SQL SERVER 2014, algunas BDs con 4GB otros con 35 MB, En total era migrar unos 15GB, además de migrar los web services WCF y REST relacionados. ¿Por qué la migración? Porque en el servidor origen (llamémosle servidor A) se presentó una anomalía para acceder al escritorio remoto del mismo, creemos que un ataque de consumo o alguna falla por parte de alguien que tiene acceso oficial al servidor, que en este caso somos 3, malogró alguna configuración. Dicha anomalía sucedió el domingo en la tarde noche, cuando nadie trabaja, por lo tanto todo el lunes nos dimos cuenta y no se podía ingresar al server para revisar los backups generados ni cualquier otro archivo de revisión de rutina, por suerte esta anomalía no afecto el funcionamiento del motor de base de datos, tampoco a los servicios web. El día había iniciado, los clientes del servidor A iniciaron operaciones de lo más normal así que un reinicio para verificar si esa era la solución, podría ser fatal, así que en la noche esperé que todos los clientes salgan para el reinicio. Lamentablemente persistía el problema.
Decisión. Como jefe de producción y encargado de la continuidad de negocio de nuestros clientes, tenía dos caminos, o mecharme con los de Microsoft Perú, o migrar a otro servidor IAAS, bueno, creo que el título del post lo dice todo, porque no podía esperar más en obtener los backups del sábado, domingo, lunes y martes estancados en un servidor inaccesibles. Ahora, iniciar un trámite de acuerdo con Microsoft nos quita un recurso importante: tiempo, ya que anteriormente sucedió algo similar que hizo que el negocio de nuestros clientes se detuvieran por cerca de cuatro horas. Inaceptable. Menos mal entendieron que dependía de responsabilidad de nuestro proveedor MS, pero no cualquier cliente puede entender eso, pero menos mal que nuestro cliente tenía planes de contingencia en caso fallara el sistema. Obviamente llegamos a un acuerdo para que este perjuicio sea un descuento en su mensualidad por el servicio. Bueno, saquen Uds. sus conclusiones respecto a Azure, si bien es cierto no es seguido (el primer inconveniente sucedió hace un año) pero deja que desear, en fin. La decisión ya está tomada, a ejecutarla.
A las 05:00 PM arrancó todo, tenía que esperar hasta las 08:00 PM para que salgan todos de los servicios, eso quiere decir que: Primero debe coordinarse el corte de servicio con el cliente, esto es vital, hasta los bancos lo notifican, claro ellos hacen mantenimiento por las madrugadas. En fin, hasta las 08:00 PM tenía tiempo para preparar la automatización de la migración, esto es obvio, si no queremos tener fallas, dejemos que el SO lo haga por nosotros. Primero comencé con asegurarme que el servidor destino (llamémosle servidor B) esté operativo a la perfección, para ello le instalé los web services de A a B, esto se logra fácilmente a través de una carpeta compartida entre servidores Azure conectados a una VPN que permitan copiar los contenidos de los web services de IIS. Segundo, configurar la seguridad del BD destino, usuarios, roles, permisos, accesos, denegaciones y configuraciones extra, para ello ya tenía preparado el script sql necesario. Tercero, hacer una prueba de acceso con una BD de prueba cambiando las configuraciones del lado del cliente a una aplicación aislada, y asegurarte que todo lo anterior esté configurado correctamente. Cuarto, antes que llegue la hora tope creé el script que saque los backups completos hacia una carpeta del servidor A que sea de escritura y sea leída desde otro servidor (para mi fortuna todo servidor de nuestro negocio tiene una carpeta FTP, lamentablemente la carpeta compartida entre servidores por la VPN no tenía permisos de escritura). Como me alcanzaba el tiempo, también alisté el script que restaure esas backups en el servidor B. Entonces, para nuestros 60 o 70 clientes con el ejecutable que apuntaba al servidor A ¿Cómo podríamos cambiarlos para que lean al servidor B?, pues tendríamos que cambiar la parte del servidor de su actualizador automático para que descarguen la misma versión del ejecutable de presentación pero con los archivos configs que apunten al servidor B (Sí, eso olvidé mencionar, la arquitectura es cliente/servidor de escritorio conectado a servicios WCF y REST) además cambiar paralizar el server A para que nadie se comunique con él. ¿Cómo podría detener los servicios de A si no hay acceso a su escritorio remoto?, fácil hay solución, si tuvieras respuesta favor de comentármelo, pero para este apaga fuego sólo decidimos a cambiar las contraseñas a todos los login de la BD a las 08:00 PM. Ejecuté el script de backups a la carpeta FTP y con FileZilla descargué directamente los BAK a una carpeta del server B, realmente lo hizo en media hora esos 15GB aprox. asumo que por lo que están en VPN (velocidad de 32MB/s aprox), ejecuté el script de restauración en el server B, además de otro script que le asigne los usuarios, permisos, roles, etc a las BDs restauradas (claro, porque hasta ese momento tenías las ids de los usuarios incluidos en la migración aún son del server A), con eso ya era suficiente para que la presentación pudiera acceder al nuevo server. Luego, configuré el Firewall para que todas las IPs que accedían al puerto SQL de A sean idénticas en B. Finalmente, se cambió el DNS para que el IP pública fija que apuntaba al servidor A apunte ahora al B. Después de tanto trajín y pruebas, todo estuvo correcto a las 9:47 PM y para el usuario mañana todo será trasparente.
Obvio que cada ambiente de sistema es un mundo, pero no escapa de cosas que son estándares, como por ejemplo hacer este trabajo fuera de horario de oficina del usuario, pruebas de continuidad, notificaciones previas al usuario, etc. Si tuvieras recomendaciones favor de enviarme a mi correo o comentario. Bueno, en honor a la verdad este post pudo ser más extenso, pero tengo controlar mi tiempo que le dedico a los post, pero si tuvieran la necesidad de que comparta algún detalle de esta travesía no dudes en escribirme, tal vez quieres que te pase algún bat, script powershell, o T-SQL, en fin, estamos para compartir. Ahora sí a dormir.
No hay comentarios.:
Publicar un comentario