PDF de programación - VMware SRM 1.1 - Capítulo 5: Configuración del sitio de Recuperación

Capítulo 5: Configuración del sitio de
Recuperación



http://www.JmGVirtualconsulting.com http://www.josemariagonzalez.es






Estamos muy cerca de ser capaces de ejecutar nuestra primera prueba básica de plan de
contingencias. Estoy seguro de que está deseando de presionar el botón que pone a
prueba la tolerancia a fallos (failover). Y quiero llegar a esa fase lo más rápidamente
posible, para que pueda tener una idea clara de los componentes que conforman la lista
de SRM. Me gustaría darle primero una idea general, antes de perderte con los detalles.

Hasta el momento, toda nuestra atención ha estado en la configuración del vCenter del
sitio de protección. Ahora vamos a cambiar el rumbo, para ver la configuración del
vCetner de sitio de recuperación. La pieza fundamental es la creación de un plan de
recuperación. Es probable que usted tenga múltiples planes de recuperación sobre la base
de la posibilidad de diferentes desastres. Si usted pierde la totalidad de un sitio, el plan de
recuperación sería muy diferente de un plan de recuperación invocado solo por la pérdida
de una cabina de almacenamiento o por la pérdida de un conjunto de aplicaciones.


Creación de un plan de recuperación completo de sitio
básico
Nuestro primer plan va a incluir cada máquina virtual en el ámbito de nuestro grupo de
protección, con poca o ninguna modificación. Una vez más, volveremos a crear un plan
personalizado de recuperación en el próximo capítulo. Este es mi intento de llegar a la
parte de prueba del producto tan pronto como sea posible, sin abrumarle demasiado con
las personalizaciones de las máquinas virtuales. El plan de recuperación contiene muchas
opciones y configuraciones:


• El grupo de protección que abarca el plan
• La demora entre el encendido de una máquina virtual antes de otra basado en el
servicio “Heartbeat” de las Herramientas VMware o un valor fijo en segundos
• Control de la configuración de la red durante las pruebas de los planes
• Suspender MV (maquinas virtuales) "locales" en el sitio de recuperación que no
son criticas para el negocio, para liberar así más recursos para MV



1. Inicie sesión con el cliente Vi en el vCenter del sitio de recuperación
2. Haga clic en el icono Site Recovery
3. En la pestaña Summary, en el panel de Recovery Setup, haga clic en el enlace
Create situado junto a la opción de Recovery Plans


4. En el cuadro de diálogo Create Recovery Plan – Recovery Plan Information
escriba un nombre descriptivo y significativo y una descripción para el plan, como
por ejemplo Complete Loss of Site Plan – Simple Test



http://www.JmGVirtualconsulting.com http://www.josemariagonzalez.es




5. En el cuadro de diálogo Create Recovery Plan – Protection Group,
seleccione el grupo de protección, el cual está cubierto por el Plan de
Recuperación



http://www.JmGVirtualconsulting.com http://www.josemariagonzalez.es



6. Haga clic en Next, y en el cuadro de diálogo Create Recovery Plan –
Response Times, seleccione un valor en tiempo que piense es apropiado
para encender las maquinas virtuales de recuperación



Nota:
Estos dos valores de tiempo se unen. Por lo tanto, SRM esperara hasta que oiga la
señal hearbeat desde las herramientas VMware (VMware Tools) y después añade
30 segundos de espera. El segundo valor 300 es el tiempo total que esperará por
una respuesta de una máquina virtual antes de arrancar la próxima máquina
virtual. Si SRM no recibe un hearbeat de las herramientas VMware, marcara esa
máquina virtual como un problema en el plan, y pasara a la siguiente máquina
virtual

7. Siguiente, en el cuadro de diálogo Create Recovery Plan – Configure Test
Networks, establezca las opciones para manejar la creación de redes
cuando se ejecute una prueba.



http://www.JmGVirtualconsulting.com http://www.josemariagonzalez.es






Nota:
La opción llamada "auto" crea un switch "interno" (anteriormente conocido como
vmnet ESX en 2.xx) llamado "burbuja". Esto asegura que no tendremos conflictos
de IP o NetBIOS entre las máquinas virtuales del sitio protegido y el sitio de
recuperación. Usted puede sobre-escribir esta configuración y mapear un vSwitch
de su propia elección, pero tenga cuidado con la posibilidad de crear conflictos con
las máquinas virtuales en producción.


Nota importante sobre Auto:
A simple vista, la función de auto suena como una buena idea. Evitara que ocurran
conflictos basados en IP o nombre NetBIOS. Sin embargo, puede hacer parar la
comunicación de dos máquinas virtuales en la prueba. He aquí un ejemplo.
Digamos que tiene cuatro servidores ESX en un clúster DRS. Cuando las máquinas
virtuales son encendidas, no tienen “control” sobre donde se ejecutarán esas
maquinas virtuales. Estas “auto”máticamente se conectaran a un switch interno, lo
que significa, que mientras las máquinas virtuales conectadas e ese vSwitch
interno serán capaces de comunicarse entre sí , estas no podrá hablar con
cualquier otra máquina virtual en cualquier otro servidor ESX del clúster. Las
consecuencias de esto son claras. A pesar de nuestra capacidad para priorizar el
encendido de las máquinas virtuales para resolver cualquier dependencia de
servicio, esos servicios de red fallaran con el cumplimiento de las dependencias y,
por lo tanto, las MV no se iniciaran correctamente.

Actualmente no hay arreglo para este problema, excepto si se usa una estructura
VLAN para aislar las máquinas virtuales de la red general. El problema puede
arreglarse en futuras versiones con un concepto llamado "Cross-Host Network
Fencing". Esto permitirá la comunicación cruzada entre vSwitches de un servidor
ESX a otro. El concepto de network fencing apareció primero hace algún tiempo en
el producto de VMware Lab Manager, donde nos enfrentamos a un desafío similar a
sus entornos de prueba - múltiples copias de máquinas virtuales corriendo en la



http://www.JmGVirtualconsulting.com http://www.josemariagonzalez.es



misma red física. En esencia, network fencing es un despliegue muy sofisticado y
automatizado de Network Address Translation (NAT) con DHCP. Esto permite que
todas las máquinas virtuales puedan preservar la configuración IP original, y que
aún se comuniquen unos con otros. Incluso con esta opción, aún habría algunas
cuestiones por resolver, por ejemplo, algunos protocolos como DCOM no funcionan
con network fencing.

Otra alternativa al "Cross-Host Network Fencing" podría ser la aplicación de pVLAN
o VLANs privadas. Desafortunadamente, las pVLANs están fuera del alcance de este
libro. Si desea obtener más información, en este link puede encontrar más
información sobre cómo funcionan:

Private VLANS - A look at Cisco's implementation of Private Virtual LANs (PVLANs)
http://www.cramsession.com/articles/get-article.asp?aid=12

Por el momento, la función "auto" en el asistente del plan de Recuperación, es la
mejor opción a considerar como un "valor de seguridad", el cual le permite probar
un plan sin temor de generar un conflicto en el IP o nombre NetBIOS en las
máquinas virtuales.

Nota:
En ocasiones, he podido ver que el campo "DataCenter" está en blanco. Esto
parece ser un error de diseño el cual ya ha sido arreglado en la versión 1.0,1 de
SRM.

8. Por último, usted puede suspender la MV en el sitio de recuperación para liberar
recursos de CPU y memoria en el cuadro de diálogo Create Recovery Plan –
Suspend Local Virtual Machines. En mi caso, las MV bajo Test & Dev se
suspenderán



9. Haga clic en Finish



http://www.JmGVirtualconsulting.com http://www.josemariagonzalez.es




Nota:
Al igual que con los grupos de protección, los planes de recuperación puede ser
mucho más sofisticado que el plan que acabo de crear. Volveré con los planes de
recuperación en el capítulo 8.


Pruebas de configuración de almacenamiento en el sitio
de recuperación
Ahora sí que estoy seguro que estará deseando de presionar el botón verde que dice "SRM
Test".



Pero antes de hacerlo, si desea que sus pruebas funcionen correctamente, vale la pena
confirmar que los servidores ESX, en el sitio de recuperación, pueden acceder a la cabina
de almacenamiento del sitio de recuperación. Anteriormente, cuando estuvimos
configurando el sitio de producción, nos centramos en asegurarnos que los servidores ESX
del sitio producción tenían acceso a los volúmenes VMFS. Las mismas consideraciones
también deben ser tomadas en cuenta para el sitio de recuperación .

Podría ser una buena práctica asegurarse de que los servidores ESX, en el sitio de
recuperación, tienen visibilidad de la cabina, especialmente si usted está utilizando una
cabina iSCSI, donde una post-configuración de los servidores ESX es necesaria para
permitir el acceso d