PDF de programación - VMware SRM 1.1 - Capítulo 3: Instalando VMware SRM

Capítulo 3: Instalando VMware SRM



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







La arquitectura de VMware SRM
Antes de comenzar el proceso de creación y configuración de SRM por primera vez, es
importante comprender la estructura del producto y sus requisitos básicos.



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




Uno de los principales desafíos de esta arquitectura es que, es muy poco probable que el
servidor SRM resida solo en una red. Y sin embargo, la cabina de almacenamiento, muy
posiblemente será “parcheada” a una red diferente. En otras palabras, hay cuatro vías
diferentes de comunicación hacia y desde el servidor de SRM:


• A/Desde la base de datos backend del SRM (SQL u Oracle)
• A/Desde la cabina de almacenamiento a través del Site Recovery Adapter (SRA)
escrito por su proveedor de almacenamiento
• A/Desde el servidor de vCenter y el servidor de licencias
• A/Desde el servidor de vCenter en el sitio de recuperación, el que a su vez se
comunica con el servidor SRM del sitio de recuperación. El vCenter actúa como un
servidor "proxy" para sus respectivos servidores SRM

Nota:
Por supuesto es posible tener todos los roles en un único Servidor Windows (base
de datos, SRM, vCenter, servidor de licencias). En el diagrama anterior, los roles
han sido representados, por claridad, de forma independiente y mostrando los
números de puerto utilizados.


Le adjunto una lista de los números de puerto y los caminos de comunicación utilizados en
el diagrama:


1. El servidor SRM se comunica con el servidor de base de datos de Microsoft SQL
u Oracle.

2. SRM se comunica con el servidor de licencias por el puerto TCP 22000 y 20001.

2/4 SRM se comunica con los dos vCenters, en el sitio protegido y en el sitio de
recuperación por el puerto TCP 443. El vCenter actúa como un servidor “proxy”
entre los dos servidores SRM.

El servidor SRM “escucha” en el puerto TCP 8095 basado en SOAP.

Los usuarios del cliente Vi, se descargan el plug-in de SRM por un puerto HTTP
personalizado, puerto 8096.

Si decide utilizar la API, la comunicación iría por el puerto TCP 9007 y 9008 (SOAP
y HTTP personalizado respectivamente).

3. El SRM, a través del SRA (Site Recovery Adapter), se comunica por una serie de
puertos de almacenamiento "dictados" por el vendedor. Por favor, consulte la
documentación específica del proveedor.


Durante la configuración del SRM "Array Manager", el SRM utiliza un software especial
escrito por su proveedor de almacenamiento ( Storage Array Adapter) para descubrir las
LUNs/Volúmenes que se están replicando. Esta comunicación será a través de la red, vía
enlaces UTP de la cabina de almacenamiento de fibra, o directamente a un objeto iSCSI.
En un entorno de producción, tendrá que configurar el enrutamiento o la comunicación
intra-VLAN para permitir que el adaptador de SRM pueda comunicarse con su “Array
Manager”.

Otro desafío de red es asegurarse de que los servidores de seguridad permiten la
comunicación de un vCenter al otro y de un servidor SRM al. Finalmente, el último desafío



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



es conseguir que las dos cabinas de almacenamiento se comuniquen entre ellas con el fin
de replicar y crear instantáneas.

Componentes de replicación del almacenamiento

SRM asume que usted tiene dos o más ubicaciones geográficamente dispersas. La primera
es su "sitio protegido". Usted puede conocer este como el “sitio donde corren todas las
funciones críticas de su negocio. Si pierde este sitio, su negocio no puede funcionar, por lo
que se realiza el cambio a un "sitio de recuperación", el cual puede ser usado en el caso
de fallos en el sitio principal. Usted puede conocer mejor este sitio como el “sitito
secundario” o como el sitio DR/BC. Hay ya muchas empresas que alquilan “espacio en
rack” por tarifas comerciales, para proveer un sitio de recuperación a otras empresas.

En mi caso, voy a comenzar con el uso de nombres muy claros para el sitio primario y el
secundario. Voy a asumir que tenemos un lugar dedicado para la recuperación - quizás
hemos contratado “espacio en rack” para esto - y la tolerancia a fallos es unidireccional.
Es decir, el sitio principal siempre “falla” hacia el sitio secundario. Hay otra configuración
diferente, la cual llamamos bidireccional. En este caso, la ubicación secundaria DR es el
sitio principal y, el sitio principal DR, es la ubicación del sitio secundario. Este enfoque
bidireccional se utiliza mucho en grandes empresa donde la ubicación del sitio Londres DR
podría ser las oficinas en Edimburgo y, la ubicación de las oficinas de Edimburgo DR, sería
Londres. Voy a tratar la configuración bidireccional DR de SRM en el Capítulo 8. Otra
forma de describir la diferencia entre una configuración unidireccional y bidireccional, es
utilizando los términos más convencionales como “activo/standy” o “activo/activo”. Voy a
seguir con los términos unidireccional y bidireccional porque son también los términos que
encontrará en la documentación oficial de VMware.

En alguno de estos dos sitios hay servidores ESX con máquinas virtuales que necesitan
protección. Las máquinas virtuales del "sitio protegido", se han replicado con una cierta
frecuencia determinada, la cual será un equilibrio entre su ancho de banda y su tolerancia
a la pérdida de datos. Cuanto mayor sea el ancho de banda entre el sitio protegido y el
sitio de recuperación, mayor será la frecuencia con la que podremos replicar los dos sitios.

Las grandes empresas pueden y, muchas veces tienen, una mezcla de tecnologías y ciclos
de replicación para facilitar el desplazamiento de los datos fuera del espacio protegido.
Quizás tienen un canal de fibra de alta velocidad entre el SitioA y SitioB, pero luego usan
una red más lenta entre SitioB y SitioC. En esta configuración, la replicación entre SitioA
y SitioB podría ser sincrónica y sin latencia. Así, cuando un disco “escribe” en el SitioA,
este dato ya se ha escrito en un disco del SitioB. Esa frecuencia de replicación ofrece una
probabilidad muy baja de pérdida de datos. La replicación de SitioB a SitioC tendrá una
mayor latencia, pero este tipo es con frecuencia seleccionado como el mejor método para
replicar los datos a una distancia considerable y fuera de la zona protegida de una forma
económica. Actualmente, SRM está limitado a crear solo una relación de sitios “uno-a-
uno”. En la actualidad, no es posible crear una relación de replicación “spoke-and-hub”. Es
de esperar que en el futuro, este tipo de configuración sea posible.

Componentes VMware

Dejando las consideraciones de almacenamiento a un lado, hay una serie de componentes
VMware que necesitan ser configurados. Es posible que ya tenga algunos de estos
componentes configurados, si usted ha estado utilizando VMware Vi3 durante algún
tiempo. Tanto en el sitio de protección, como en el sitio de recuperación usted necesita:


• ESX 3.0.x, 3.5 o 3i Update 1
• vCenter 2.5 Update 1



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



• Una base de datos para el servidor de SRM en el sitio de protección y otra en el
sitio recuperación. VMware soporta SQL 2000 Standard (SQL Express funciona
también) o superior y Oracle 9i Release 2 Standard o superior
• SRM en el sitio de protección y otro SRM en el sitio de recuperación (SRM está
disponible para Windows XP SP2 Professional, Windows 2003 R2, Windows 2003
Server SP1, Windows 2000 Server SP4 con Update Rollup 1, solo en la versión de
32bits)
• Adaptador SRM de su proveedor de almacenamiento instalados en ambos
servidores SRM.
• SRM Vi plug-in
• Enmascaramiento LUN – Los servidores ESX en el sitio protegido ven las LUNs
“reales” pero los servidores ESX en el sitio de recuperación sólo ven las "replicas"
o instantáneas. Esto permite, que en las pruebas, no se interrumpan las
operaciones normales y tampoco se interrumpe el ciclo normal de la replicación
entre los dos sitios
• La resolución de nombres DNS. Al igual que con Vi3, se recomienda probar todos
los métodos de resolución de nombres - nombre de host, corto, largo FQDN, e
inverso.


Una pregunta muy común, es si es posible replicar la base de datos en vCenter en el sitio
protegido al sitio de recuperación. La respuesta es NO, si usted tiene intención de usar
SRM. SRM asume que las dos bases de datos de vCenter se están ejecutando de forma
independiente la una de la otra. De hecho, una de las tareas de gestión necesarias
durante la configuración de los dos SRM es la "vinculación" del SRM en el sitio de
protección con el SRM del sitio de recuperación. Después, se mapean los objetos del
vCenter (carpetas, resource pools, redes) en el sitio protegido con el sitio de
recuperación. Actualmente, la estructura de la base de datos de vCenter no permite el uso
de la replicación de SQL u Oracle para duplicar esta en el sitio de recuperación.

A efectos de brevedad, voy a asumir que usted sabe cómo configurar ESX y vCenter para
que pueda centrarse más espec