Instalar VMware SRM integrado con SRA de NetApp

Estimados lectores, en este nuevo artículo veremos el procedimiento para instalar VMware SRM integrado con SRA de NetApp. VMware Site Recovery Manager es una herramienta que nos puede ayudar en la administración y gestión de nuestro CPD de contingencia para disponer de él en caso de un desastre. En las siguientes líneas veremos el proceso de instalación de la herramienta y también la instalación del adaptador de NetApp SRA el cual nos servirá para integrar la replicación de nuestros sistemas de almacenamiento con SRM.

Antes de entrar en el procedimiento deberemos tener en cuenta los siguientes aspectos de diseño:

1. VMware SRM requiere 2 Sites con una instancia de vCenter cada uno de ellos – 2 servidores vCenter. Generalmente dispondremos de un Datacenter de Producción formado por un clúster HA de N nodos ESXi y un Datacenter de Contingencia con M nodos ESXi (digo M porque pueden ser menos o bien N nodos quizás con capacidades de computación menores ya que se entiende que éstos solamente van a dar servicio en caso de desastre).
2. SRM necesita una base de datos para operar, SQL Express embebida o bien un SQL Server Remoto, Oracle o DB2. Cada instancia de SRM tiene su propia base de datos y técnicamente es posible tener un Site con su BD en SQL Server y el otro con la BD en Oracle, por ejemplo.
3. Realizaremos la instalación de SRM en cada uno de los Sites a ser posible sobre una máquina virtual dedicada.
4. El licenciamiento de SRM va en conjuntos que se utilizan para licenciar cada máquina virtual a proteger hacia el CPD de Contingencia. Si las especificaciones del diseño requieren un comportamiento de «ida y vuelta», es decir, proteger la VM hacia Contingencia y poder volver a Producción entonces se computan 2 licencias. Para poner un ejemplo, si queremos proteger 30 VMs de forma automatizada y queremos que éstas puedan ser devueltas a Producción también de forma automatizada entonces necesitaremos 60 licencias. Respecto este punto comentar que la hipotética «vuelta» al CPD de Producción, si existe (por ejemplo si se han quemado los equipos, inundado el CPD o casos peores), se puede resolver de forma manual o con scripts.

Con la infraestructura virtual de Producción y la de Contingencia ambas con un nivel de software compatible podemos lanzar la instalación de VMware Site Recovery Manager como sigue:

Lanzamos el asistente de instalación que como veremos es bastante sencillo.

Información de registro y patentes. Seguimos…

Como es habitual aceptaremos el acuerdo de licencia, de lo contrario no podremos realizar la instalación.

Podemos consultar, si no lo hemos hecho antes, el enlace propuesto para verificar que «vamos bien» antes de continuar. El escenario de este artículo está basado en 2 infraestructuras virtuales vSphere 5.5, una de Producción con 3 nodos ESXi y otra de Contingencia con 2 nodos ESXi, cada una de ellas con un servidor vCenter y su correspondiente Datacenter y Clúster HA. Cada infraestructura independiente tiene una cabina NetApp como almacenamiento, estas 2 cabinas tienen configurado SnapMirror y los volúmenes de Producción (Datastores NFS) se replican hacia el CPD de Contingencia.

Describiendo un poco más el escenario para este cometido disponemos de una máquina virtual en cada CPD destinada a VMware Site Recovery Manager. Como podemos observar no se requiere demasiado espacio en disco.

Es necesario introducir los datos de acceso a vCenter para realizar el registro de SRM. En cada Site, PROD y CONT, realizaremos el registro en el correspondiente vCenter (SRM-PROD <–> vCenter-PROD y SRM-CONT <–> vCenter-CONT).

Aceptamos la instalación del certificado (aparece la alerta si el certificado de vCenter es auto-firmado).

En este apartado configuraremos un nombre de Site que lo identifique bien además de introducir los datos de red solicitados (IP local y puertos de servicio). Como es una VM dedicada para SRM no hay problema en aceptar los puertos predeterminados.

En la mayoría de los casos aceptaremos la instalación del plug-in predeterminada.

Seleccionamos generar un certificado auto-firmado a bien cargamos uno que tengamos creado para esta autenticación.

Rellenamos la información que tendrá el certificado.

En este apartado tenemos dos opciones: usar una base de datos embebida o bien usar una base de datos personalizada. Veamos en primer lugar la opción predeterminada y posteriormente veremos un ejemplo con una base de datos ubicada en un SQL Server remoto.

Especificaremos un nombre para el DSN y las credenciales para la conexión a éste. Las opciones de conexión así como los puertos pueden quedar configurados de forma predeterminada.

Podemos usar una cuenta de servicios Local System o bien especificar un usuario, por ejemplo, del dominio de Active Directory. Aunque en los ejemplos estemos usando el Administrador como siempre es recomendable tener un usuario específico con los permisos mínimos necesarios y configurando algunas restricciones (prohibir acceso remoto, acceso a carpetas compartidas, inicios de sesión, …).

Todo listo, podemos lanzar la instalación.

Si todo ha ido bien observaremos la ventana de finalización. En el caso de que optemos por ubicar la base de datos de SRM un servidor remoto como Microsoft SQL Server podemos proceder de la siguiente forma:

En el servidor SQL creamos una nueva base de datos.

Configuramos las opciones indicadas y damos un nombre identificativo a la nueva base de datos. En este ejemplo con srmprod estamos indicando que será para el servidor SRM del CPD de Producción y srmcont para el de Contingencia.

Una vez creada vamos a configurar un nuevo Login.

Para hacer más «entendible» la solución creamos un Login con un nombre de usuario que coincida con el nombre de la base de datos. Esto no es un requisito pero puede ayudarnos a identificar mejor todo el conjunto.

Indicamos que para la nueva base de datos y para la msdb este usuario sea db_owner.

Para que SRM funcione correctamente sobre SQL Server es necesario crear un Esquema cuyo nombre coincida con el nombre de usuario que hemos definido en el Login.

En este caso el usuario forma parte de un Dominio de Active Directory por lo que usamos el nombre NetBios para identificarlo. Es importante que el nombre de esquema coincida exactamente con el nombre de usuario así que deberemos indicar DOMINIO\srmprod ya que si no el proceso de instalación posterior no podrá generar las tablas necesarias.

Ahora editaremos las propiedades del usuario para cambiar su esquema predeterminado.

Como no puede ser de otra manera indicaremos que su Esquema Default sea el que hemos creado anteriormente. Una vez finalizada la creación de la base de datos generamos el ODBC de 64 bits para la conexión con la misma. Antes de ello instalaremos el Microsoft SQL Server 2008 R2 Native Client.

Seguiremos el asistente de creación de un nuevo origen de datos.

Introduciremos un nombre identificativo y el servidor SQL Server donde se aloja la base de datos.

Configuramos la autenticación integrada de Windows.

Indicaremos que la base de datos predeterminada sea la que hemos creado anteriormente.

Podemos dejar las opciones predeterminadas y finalizamos.

Vuelta al punto donde configuramos la base de datos en la instalación de VMware SRM seleccionaremos el DSN indicando las credenciales de acceso y finalizaríamos la instalación del producto de la misma forma.

Hasta aquí hemos visto cómo instalar VMware Site Recovery Manager en nuestros servidores dedicados de los CPDs de Producción y Contingencia. Ahora nos falta realizar la instalación del adaptador NetApp SRA para que SRM se encargue de las peticiones de replicación de los Datastores que configuremos en nuestros Recovery Plans basados en Arrays.

La instalación del adaptador la realizaremos sobre los servidores SRM dedicados (en ambos).

Como siempre aceptamos los acuerdos para continuar.

Ventana de información sobre la compañía.

Seleccionamos una instalación completa de SRA.

Y lanzamos la instalación del producto.

Como vemos la instalación de NetApp SRA no tiene opciones de configuración, sencillamente nos va a proporcionar el interfaz de nuestros Array Managers correspondientes a las cabinas de Producción y Contingencia.

^{This Post by David Solé Pérez is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License}