¡Hola a tod@s!!

En un post anterior comenté genéricamente los pasos a seguir para realizar una parada y arranque controlados de un entorno vSphere. Aprovechando ese hilo, quería añadir en este otro unos pocos pasos adicionales para los que tengáis el entorno plenamente virtualizado con escritorios View/Horizon View.

Vamos pues a ver un guión que bien puede servir para la mayoría de entornos vSphere & View sin mayores complicaciones.

Proceso de apagado

0.- Puede parecer un punto innecesario, pero cuando soy yo el encargado de apagar un entorno que no administro diariamente y que me resulta parcialmente desconocido, tomo capturas de las máquinas que están puesta en marcha y dando servicio en el entorno, de esta manera evitamos luego dudar si todas o no estaban en marcha. Puede que haya máquinas obsoletas inventariadas apagadas, otras máquinas apagadas intencionadamente, etc. Lo dicho no cuesta nada y tendremos para al final una radiografía del entorno antes de manipular nada.

1.- En este caso empezaremos por el apagado de las máquinas desktop View. Para asegurar que todo está bajo control, mi recomendación sería acceder al panel de administrador del Connection Server (Broker) y deshabilitar cada uno de pools de escritorios que tengamos creados. De esta forma conseguiremos que una vez iniciado el proceso de apagado de los escritorios, el mismo Connection Server se ponga a darles Play otra vez y vuelta a empezar. Este tipo de comportamiento se da si tenemos configurada la opción Ensure desktops are always powered on en la configuración del Pool. Modificamos a Take no power action si hemos preferido no deshabilitar el Pool entero. Aceptamos los cambios y a por el siguiente paso.

pool.png

2.- Vamos a ir apagando ordenadamente todas la máquinas virtuales del entorno, dejando para las últimas el propio vCenter, (al que he dado por sentado que estamos conectados desde nuestra estación de trabajo, bien sea mediante el vSphere Client tradicional, el Web Client o directamente por sesión de escritorio remoto) y uno de los controladores de dominio, a poder ser el que haga de servidor DNS principal en nuestra red. Así evitaremos cualquier «paranoia» de resolución de nombres internos de la red a medida que vayamos apagando equipos/servicios.

** Un pequeño detalle que no querría pasar por alto es, que si tenéis instalado un equipo que realiza las tareas de copia de seguridad como bien puede ser Veeam Backup, Backup Exec System Recovery, otros, os aseguréis que en el momento del apagado del mismo no se está llevando a cabo ninguna tarea de backup/replica. Pues de ser así, interrumpirlo abruptamente, tal vez nos deje ahí como regalo un snapshot que en el futuro pase inadvertido y ni el propio sistema ni nosotros administradores lo consolidemos y nos de quebraderos de cabeza pasados unos días/semanas.

3.- Ahora accedemos a el/los host/hosts que llevan la ejecución del vCenter Server y del DC (dando por sentado también que ambos con máquinas virtuales, en caso de ser equipos físicos omitir este punto) y apagamos ordenadamente también estas dos últimas máquinas.

4.- Llegó el momento de apagar los hosts. Conectados a estos mediante el vSphere Client o directamente en consola pulsando F12 y usando las credenciales adecuadas, recordad, usuario root y la contraseña correspondiente ordenamos un Shutdown Host.

5.- Con los pasos anteriores realizados, ya hemos asegurado que ningún equipo del entorno vSphere está accediendo al almacenamiento SAN/NAS siempre y cuando solo los hosts y máquinas virtuales sean los que acceden a la red y equipos de almacenamiento. ¡OJO!! A tener en cuenta este punto en un entorno donde hayan equipos físicos aparte de los hosts que acceden a volúmenes lógicos de la cabina por FC/iSCSI/NFS/CIFS.

De no ser nuestro caso, llegó el momento de apagar mediante el portal de administración las unidades NAS que podamos tener, si se da el caso. Pongamos como ejemplo las típicas unidades QNAP, iOmega, Synology, etc. Desde su panel de administración daremos la orden de apagado ordenado.

Pasamos a realizar el apagado de las cabina de discos SAN. Aquí en función de cada marca/modelo pueden aplicar multitud de combinaciones para realizar el correcto apagado del equipo. Mejor cada uno informarse con el fabricante del equipo en cuestión cual es el procedimiento correcto. No quisiera con este escrito hacer incurrir en problemas a alguien por aplicar pasos inadecuados. 

Las hay que mediante el propio entorno de administración se puede ordenar el apagado ordenado. En otras solo de forma parcial, haciendo shutdown de las controladoras, pero que luego hay que cortar corriente mediante interruptores físicos de la cabina o de cada una de las fuentes de alimentación. En otros casos mediante botones/pulsadores físicos en la cabina (bien por la parte delantera o trasera) se inicia la secuencia de apagado ordenada, haciendo primero un destage (bajada a discos de los datos pendientes de ser escritos almacenados todavía en caché) y luego apagado del sistema operativo interno y para finalizar cortar el suministro eléctrico a las fuentes de alimentación. Pueden haber otros métodos.

6.- Nos queda todavía la electrónica de red propia del almacenamiento. Puede ser esta 2 o más switch ethernet para comunicación iSCSI y/o 2 o más switch FC que interconecten los hosts con las unidades de almacenamiento. En alguno de ellos se puede realizar un shutdown ordenado, en otros simplemente tiramos del cable eléctrico o si disponemos de regletas de enchufes PDU en rack, cortamos corriente a nivel de interruptor general.

Poco más por el momento. Creo que no me dejó nada de vital importancia. Apagaríamos el SAI o los SAI para estar seguros de tener aislados los equipos del CPD de cualquier evento eléctrico indeseado y a esperar la orden de arranque que detallo a continuación con mayor brevedad y en estricto orden inverso.

Puesta en marcha

0.- Rearme de los equipos SAI y regletas eléctricas para asegurar que vuelva a llegar tensión a las fuentes de los equipos.

1.- Puesta en marcha de los equipos de electrónica de red de almacenamiento. Este punto no suele requerir proceso de interacción posterior. Suelen ser equipos de puesta en marcha desatendida que no requieren mayor atención.

2.- Puesta en marcha de la cabina de discos. Aplíquese en cada caso el procedimiento propio facilitado por el fabricante. Suele bastar con conectar las fuentes de alimentación y a lo sumo usar un botón de arranque del equipo para iniciar la carga del sistema operativo interno del equipo. Vale la pena esperar unos minutos a que este proceso termine. Suele llevar un rato, tal vez hasta 10 minutos en algunos casos, hasta que se hace el chequeo de los discos, bandejas, etc., y se llega al estado Ready en el que ya acepta conexiones a los datos que alberga.

3.- Arranque de los hosts y aguardar unos minutos también. Podemos ir viendo el proceso de carga del sistema operativo ESXi en consola por KVM o por iLO/DRAC/etc. No debe haber mayor problema si nuestro querido Murphy no anda por la zona. De tener configurado el arranque automático en los hosts de las máquinas virtuales activado, poco más habría que hacer, pues con el arranque del hosts estas irán poniéndose en play una tras otra en el orden e intervalo establecido.

De no ser así, nos conectaremos a los hosts mediante vSphere Cliente y nos aseguraremos de arrancar primero los controladores de dominio, luego el vCenter Server y el resto de máquinas. En unos pocos minutos todos debería haber vuelto a la normalidad.

4.- Ahora nos toca realizar las acciones inversas que hemos visto en el punto 1 del apartado del proceso de apagado referentes a los escritorios View. Habilitamos los Pool/s que antes hemos modificado o bien accedemos a las propiedades de cada uno de ellos para volver a modificar las propiedades del Pool en lo referente a si los escritorios deben estar siempre puestos en marcha, etc.
Recomendaría no habilitar todos los Pools a la vez o modificar esa propiedad si disponemos de decenas de ellos o incluso cientos. En el arranque del conjunto se va a llevar a cabo una altísima demanda de acceso a disco en la cabina de discos y puede que todo el entorno se pueda resentir debido al Boot Storm. Puede afectar por igual a la red, etc. Como bien dice un buen cliente y mejor amigo:
– Pooocooooo a poooooooco.


5.- Nos quedaría revisar que todos los servicios están Up&Ready y celebrarlo con otra cerveza bien fría..!


A ver si os puede servir de ayuda.

Saludos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Post Relacionados: