blogsulting

Hace apenas seis o siete años, cuando participé en mi primer proyecto de DR (BCP, BRS, DRP, BC… y demás), en una importante entidad bancaria con sede central en Sabadell (de la que no daré más detalles), la tecnología existente hoy nos hubiera ahorrado mucho tiempo de diseño, nos hubiera facilitado enormemente el trabajo y sobre todo hubiera supuesto un abaratamiento de costes importantísimo. Por desgracia, entonces no disponíamos de dos de los pilares fundamentales en los que yo me baso para plantear hoy en día proyectos de este tipo:

• NetApp MetroCluster

• VMware SRM

Sin ánimo de ponerle puertas al campo, ya que hay muchas otras soluciones, la verdad es que con estas dos podríamos cubrir la mayoría de escenarios. Bien es cierto que concretamente uno de los objetivos que nos proponíamos por aquel entonces quedaría excluido: proteger el host. Aunque en mi caso, y supongo que en el de la mayoría, ese tipo de proyectos no se me presentan cada día.

Antes de entrar en materia, y sin profundizar demasiado en la teoría, voy a intentar dar un par de conceptos para que a nadie se le escape nada. Siempre que hablamos de recuperar el negocio, como en la mayoría de los proyectos, hay una serie de fases que se deben tener en cuenta: Análisis, Diseño, Implementación, Pruebas, Documentación, Formación y Mantenimiento. Comentaré sólo las más destacables, porque entiendo que el contenido de las otras es fácilmente deducible:

• Análisis: Dentro de esta fase conviene estudiar el tipo de amenazas ante las que el DRP nos cubrirá las espaldas, desde las catástrofes naturales, hasta la intrusión o los fallos humanos. Asimismo aparecen dos conceptos clave que conviene definir para que nuestro plan sea útil: El estado del sistema al que queremos volver y la cantidad de datos que nos podemos permitir perder (Recovery Point Objective o RPO) y el tiempo necesario del que podemos disponer para llevar a cabo la recuperación (Recovery Time Objective o RTO).
• Diseño: Como en todo proyecto, hay que definir exactamente las infraestructuras que serán necesarias para recuperarse (ubicación secundaria, servidores de contingencia, redes,etc), la estructura del equipo de crisis y todos los mecanismos de TI necesarios (replicación, líneas de comunicación, aplicaciones, etc) y dimensionarlas de acuerdo con el entorno del cliente.
• Implementación: Como se dice en inglés, ésta es self-explanatory.
• Pruebas: Esta fase también es importante, sobre todo para definir un juego de pruebas suficientemente adecuado al entorno implementado y a las eventualidades que se deseen cubrir, y que se realicen las pruebas con cierta frecuencia, para estar seguros del funcionamiento de nuestro plan. Para esto, VMware vCenter SRM aporta una funcionalidad incomparable… el botón de test.
• Documentación y formación: Está bastante claro ¿no?
• Mantenimiento: Esto también es importantísimo, ya que en función del nivel de automatización de nuestro sistema de recuperación, será más o menos complejo conseguir tener actualizados los procedimientos.

Ahora que todos tenemos claro que el nivel de dificultad que puede alcanzar un proyecto de este tipo, en caso de que los entornos que queramos proteger tengan cierta complejidad, puede ser entre faraónico y galáctico, ya podemos entrar a comentar cómo nos pueden ayudar los dos productos que he mencionado antes.

Siempre que hablemos de entornos basados en arquitecturas x86, o más concretamente que podamos virtualizar con VMware, la mejor de las alternativas que conozco es VMware vCenter SRM. Este producto, que se instala como un complemento de la plataforma de gestión vCenter, permite definir un plan de contingencia que cubra a las máquinas virtuales que nos interese en tiempo récord. Un esquema característico de las soluciones basadas en VMware vCenter SRM, es el siguiente:

Escenario típico de VMware con vCenter SRM

En él encontramos dos CPDs, que en el mejor de los escenarios estarán en edificios separados, y comunicados entre sí por una buena línea de comunicaciones. En cada uno de los CPDs tendremos varios hosts de VMware ESX, una cabina de almacenamiento y un servidor VMware vCenter con vCenter SRM. Las máquinas virtuales que se quieran proteger han de estar ubicadas en uno o varios volúmenes de la cabina del CPD principal, que se replicarán hacia la cabina del otro CPD, mediante los mecanismos propios de cada fabricante. Para garantizar la integración, los fabricantes de almacenamiento (Dell, EMC, HP, IBM, NetApp, etc) han desarrollado unas APIs de integración con SRM, llamadas Storage Replication Adapter, que se instalan durante el proceso de configuración de SRM. La más sencilla de las alternativas, es aquella en la que las dos cabinas son de un mismo fabricante, aunque hoy en día podríamos incluso hacer montajes heterogéneos, bien con virtualizadores o gateways de almacenamiento (NetApp V-Series, HP SVSP, IBM SVC, FalconStor NSS, etc) , bien con software (DataCore, EMC RecoveryPoint, etc) .

A la hora de dimensionar una solución con SRM, conviene contemplar algunos detalles, como por ejemplo su licenciamiento basado en CPU protegida, que obliga a tenerlo en cuenta en el diseño del clústering HA y DRS, para que las máquinas virtuales en el plan de DR queden circunscritas a los hosts cuyas CPUs están licenciadas, ya que su movimiento a otro de los hosts las excluiría del DRP. Entre las características más interesantes, conviene destacar su nivel de integración con los mecanismos de replicación de los principales fabricantes, hasta el punto de controlar en qué estado se encuentran los volúmenes de origen y destino en cada una de las cabinas, y poder parar la replicación o incluso configurarla en sentido inverso, para facilitar el failback, después de un failover.

El otro de los productos recomendados, NetApp MetroCluster, ofrece una aproximación desde el punto de vista del almacenamiento, que permite trabajar conceptualmente con una única cabina, separada en dos sites. El concepto es tan sencillo de entender como coger una cabina de discos, partirla en dos y llevarse un trozo a cada CPD. Evidentemente, a nivel técnico entraña algo más de complejidad, aunque su implementación tampoco es extremadamente difícil. Económicamente, tiene un cierto impacto sobre el TCO, ya que se ha de duplicar el almacenamiento y utilizar SyncMirror, para que en caso de perder una mitad de la cabina, podamos continuar disponiendo de controladoras y discos. De cualquier modo, siempre es más económico que comprarse dos cabinas y replicarlas, y la funcionalidad que ofrece es mucho mayor, ya que en caso de desastre la cabina continúa funcionando, haciendo imperceptible la caída de la otra parte para el usuario.