Perdóneme si no puedo ser totalmente claro aquí. No es intencional, soy un desarrollador de nivel senior en una empresa muy pequeña y tengo que actuar como gerente en este momento.
De todos modos, la historia es que tenemos 2 servidores Dell más antiguos con SQL Server 2008 Standard en un "clúster". Lo pongo entre comillas porque todavía no tengo 100% claro lo que significa. Tenemos 2 servidores Blade nuevos y queremos trasladar las bases de datos existentes al nuevo hardware.
Bien, aquí está el problema. Necesitamos hacer esto con poco o ningún tiempo de inactividad. Me dicen que podemos desalojar el nodo pasivo y luego instalar uno de los nuevos servidores. Pero también me dicen que este es un paso peligroso porque algo podría salir mal y provocar que el clúster falle y luego nos quedaríamos sin nada porque el servidor activo no podría volver a funcionar.
¿Alguien tiene alguna idea sobre cómo manejar esto? Me dicen que la única manera de garantizar el éxito es tener al menos un día de inactividad en el que abramos un nuevo clúster en el nuevo hardware y luego migremos las bases de datos una por una.
[Editar] Dado que todavía está relacionado con esta pregunta, me gustaría agregar otra pregunta. ¿Es posible para nosotros eliminar una máquina del clúster? ¿Luego crear un nuevo clúster con el nodo eliminado como máquina activa y luego incorporar un nuevo servidor? ¿Preservar eficazmente el clúster antiguo mientras las nuevas máquinas se intercambian dentro y fuera en caso de que algo salga mal?
Respuesta1
poco o ningún tiempo de inactividad
Si bien es de poca ayuda ahora que debería ejecutar una empresa si necesita alta disponibilidad, la característica más obvia que usaría en esta situación es la capacidad de tener hasta 16 nodos en un clúster, por lo que en su caso simplemente habría agregado 2 nodos más luego eliminaron los que ya no deseaba. Consideraría actualizar la versión mientras actualizas el hardware.
... Pero también me dicen que este es un paso peligroso porque algo podría salir mal y provocar que el clúster falle y luego nos quedaríamos sin nada porque el servidor activo no podría volver a funcionar.
Todo es posible. Si bien nunca he visto un clúster de conmutación por error de un servidor 208 sql 2008 simplemente caer muerto, en teoría es posible. Tenga en cuenta que el nodo activo no está "inactivo" durante la actualización del nodo, por lo que no hay nada que eliminar. El clúster simplemente se ejecuta en 1 nodo sin posibilidad de conmutación por error. El peor de los casos razonables es que el nodo antiguo esté de alguna manera muerto y el reemplazo no se agregue, en cuyo caso estaría ejecutando sin capacidad de conmutación por error hasta que se resuelva el problema que está causando que el servidor no se agregue.
Me dicen que la única manera de garantizar el éxito es tener al menos un día de inactividad en el que abramos un nuevo clúster en el nuevo hardware y luego migremos las bases de datos una por una.
Probablemente esa sea la única manera de garantizar el éxito de la persona que realiza el trabajo. Haría la inocente pregunta de "si se necesita un día de inactividad para mover un clúster, ¿por qué debería agruparme en primer lugar? Podría comprar 2 máquinas y dejar 1 apagada y lista para funcionar para ese tipo de disponibilidad". En resumen, necesita encontrar a alguien que realmente trabaje con clústeres antes y comprenda la tecnología involucrada. Suponiendo que no haya problemas únicos (por ejemplo, su empresa escribió algunoscasisoftware compatible con el clúster que se ejecuta en el clúster) Creo que a la mayoría de los administradores profesionales de Microsoft les daría vergüenza decir que se necesitaría un día de inactividad para reemplazar/agregar hardware a un clúster existente y en funcionamiento.
Respuesta2
En primer lugar, la estrategia recomendada al final de su pregunta es la forma en que yo también recomendaría hacerlo, pero dado que esa no es una opción, así es como lo manejaría. Parece confundido acerca de un clúster, básicamente ambos servidores tienen SQL instalado y servicios de clúster, con un comando a través de los servicios de clúster puede "pasar" SQL de un servidor a otro. Si estuviera en su lugar, lo haría como sugirió: trasladar todos los servicios a un nodo, eliminar el segundo nodo del clúster, agregar uno de sus nuevos servidores como nodo del clúster, trasladar todos los servicios al nuevo nodo del clúster. agregue el segundo nodo nuevo, elimine el segundo nodo antiguo del clúster.
**Tenga en cuenta que si no está familiarizado con los servicios de clúster y/o las instalaciones de SQL en clúster e intenta esto en su sistema activo, esto podría terminar muy, muy mal para usted. Mucho peor que el día de inactividad planificado. Contrataría a un consultor con experiencia en clústeres o, si esa no fuera una opción, configuraría un entorno de prueba que pudiera probar el proceso por dentro y por fuera.
Aquíes un enlace a los pasos para agregar un nodo a su clúster.
Respuesta3
No es necesario romper el clúster anterior en absoluto a menos que desee utilizar el hardware nuevamente. Yo recomendaría lo siguiente:
- Cree un nuevo clúster con los nuevos blades.
- Instale SQL en el nuevo clúster, mantenga las mismas letras de unidad, rutas, puerto y nombre de instancia (si corresponde)
- Después de la instalación, restaure/reemplace las bases de datos maestra y msdb del antiguo servidor SQL al nuevo para obtener los inicios de sesión y los trabajos, o bien escriba los trabajos en el antiguo y use sp_help_revlogins.
- Registre o refleje la base de datos del servidor antiguo al nuevo para actualizar los datos.
Esto hará que su nueva instancia esté en el mismo estado que la anterior, junto con una nueva instalación del sistema operativo y SQL. Para realizar la transición al nuevo clúster, puede hacer lo siguiente, asumiendo que el nombre de su instancia anterior es INSTA y la nueva es INSTB:
- Desconecte la antigua instancia de SQL
- Recuperar las bases de datos en el nuevo servidor.
- Eliminar el registro DNS de INSTA del DNS de Active Directory
- Cree un nuevo registro DNS CNAME (alias) en Active Directory DNS que apunte a INSTB
Una vez hecho esto, las aplicaciones deberían conectarse con el nombre anterior de la instancia de SQL, pero eso las llevará al nuevo servidor. Es posible que necesite ejecutar "ipconfig /flushdns" en todos los servidores de aplicaciones para que el cambio de DNS funcione más rápido; asegúrese de hacer ping al nombre anterior para ver cuándo apunta hacia atrás. Usamos este método para la transición porque nos permite mantener el clúster antiguo en caso de que necesitemos revertirlo. No podrá recuperar la antigua instancia de SQL hasta que cambie el parámetro Nombre de red del servidor SQL a otra cosa, pero una vez hecho esto, simplemente deberá apuntar el alias DNS al anterior si desea revertirlo.
Respuesta4
Sin conocer los detalles del hardware para saber si esto funcionaría, mi sugerencia sería crear una imagen del antiguo nodo pasivo en el nuevo servidor. Usar algo como Acronis que permitiría colocar la imagen en un nuevo hardware debería permitirle básicamente mover el nodo pasivo al nuevo hardware. Una vez allí, puede encenderlo y verificar que esté funcionando correctamente (tanto como pueda) y luego intentar realizar la conmutación por error al nuevo hardware. Aunque hay muchas cosas que podrían salir mal, como dijo Jim B, hay muchas posibilidades de que falle correctamente al nuevo hardware o no funcione y simplemente tenga que volver al hardware antiguo. Si funciona, puedes repetir el proceso en el otro nodo. Si no es así, puede volver a encender el antiguo nodo pasivo (que no tendría que destruir) e intentar algo más.