Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Recuperación de desastres (DR) para servidores virtualizados

Los servidores virtuales, gracias al mayor nivel de movilidad y a la relativa autonomía respecto al haDRware que presentan, contribuyen en gran medida a reducir los costos y la complejidad de implantación de un programa de recuperación ante desastres (DR), lo que permite a las empresas extender el plan de DR a un mayor número de servidores y aplicaciones.

Aunque la protección de los datos de los servidores virtuales resulta más sencilla y menos costosa, un estudio reciente demuestra que la mayor parte de las empresas no realizan todas las copias de seguridad de sus servidores virtuales.

La implantación de los servidores virtuales en los centros de datos está conociendo una progresión imparable.

Las ventajas derivadas de la reducción de costos que permite la consolidación, de una administración más sencilla y del ahorro de consumo que aportan constituyen algunas de las razones fundamentales que explican la proliferación de infraestructuras virtualizadas. La parte negativa de esta tendencia es que la sencillez de implantación de los servidores virtualizados conlleva el riesgo de asignar aplicaciones de vital importancia a los nuevos servidores sin adoptar las medidas necesarias de protección de datos y recuperación ante desastres.  

Además, las estrategias de protección de datos y de recuperación ante desastres en entornos virtuales plantean diversos retos, sin olvidar que los procesos configurados originalmente para la infraestructura física pueden no funcionar (o funcionar de modo diferente) con los servidores virtualizados. Según revela el Informe de investigación sobre recuperación ante desastres Symantec, elaborado por Symantec Corp., los planes corporativos de recuperación ante desastres dejan fuera de su ámbito de aplicación al 35% de los servidores virtuales. 

Por otra parte, sólo el 37% de las empresas encuestadas realizaban copias de seguridad de todos sus sistemas virtuales. El motivo principal de tales deficiencias en la política de protección de datos y recuperación ante desastres de los servidores virtuales es la falta de medios. Los departamentos de tecnología de la información, sobrecargados ya al máximo, no tienen tiempo para implantar planes viables de recuperación ante desastres para gran parte de sus sistemas virtualizados. Por añadidura, las herramientas de protección para servidores físicos y para servidores virtuales difieren en muchos casos, lo que hace que se multipliquen los costos laborales, los de formación y los asociados al software. A pesar de los desafíos que pone de manifiesto el estudio de Symantec, el sistema de protección de los datos de los servidores virtuales resulta más sencillo y más económico que el de los servidores físicos.

Estrategias de recuperación de datos para máquinas virtuales

La razón por la que la protección de los servidores virtuales resulta más sencilla que la de los servidores físicos reside en la estructura de la arquitectura del hipervisor de la máquina virtual. Un hipervisor es una plataforma de virtualización en la que un conjunto de sistemas virtualizados (denominados "sistemas operativos huéspedes") se ejecutan a través de un único equipo físico, conocido como el host. Las máquinas virtuales ejecutan sus propios sistemas operativos, pero comparten los recursos subyacentes del equipo físico: desde la CPU a la memoria, pasando por los dispositivos de E/S y el sistema de almacenamiento. Mientras que los servidores físicos son inseparables del equipo físico, los servidores virtuales se almacenan como archivos o imágenes de la máquina virtual en el host. Dado que la imagen de la máquina virtual contiene todos los datos de dicha máquina, ésta puede desplazarse de un equipo físico a otro con solo copiar el archivo de la imagen, relativamente autónomo respecto al hardware, e instalarlo en diferentes hosts. El valor añadido de la movilidad, inherente a los servidores virtuales, es el responsable directo de que la implantación de los servidores virtuales en un sitio de recuperación ante desastres resulte más sencilla que la de los servidores físicos.

En comparación, los sistemas de recuperación ante desastres de los servidores físicos, cuya configuración prevé una migración de los servidores principales a servidores secundarios en caso de que se produzca un fallo, representan una empresa de mucha mayor envergadura que genera, asimismo, costos más elevados.  Los servidores principales y secundarios requieren el mismo haDRware, o, al menos, equipos muy similares, y, para ejecutar cualquier tipo de migración automática por fallo, es necesario dotar a estos equipos físicos de una cierta configuración clusterizada. Las soluciones clásicas de software de clúster, como Microsoft Cluster Server, determinan una relación relativamente estática en la que los nodos del servidor clusterizado se preasignan y se clasifican como nodos principales o secundarios.

Jason Nadeau, responsable de producto del Veritas Cluster Server (VCS) de Symantec, nos explica: “Con los paquetes de software de clústers tradicionales que se han estado empleando en los sistemas de alta disponibilidad (HA) y recuperación ante desastres para servidores físicos, los nodos presentan fuertes lazos de conexión entre ellos, lo que limita la escalabilidad y multiplica la inversión en capital y los gastos operativos y explotación.”

Por el contrario, en un entorno de servidores virtualizados, el host principal, gracias a las máquinas virtuales de producción y al host secundario de recuperación ante desastres, puede presentar características muy distintas. Mark Browker, analista del grupo Enterprise Strategy Group (ESG), con sede en Milford (Massachusetts), afirma: “Los sistemas de recuperación ante desastres para servidores virtuales ya no requieren una analogía de hardware. “En efecto, podemos tener diez servidores físicos para ejecutar máquinas virtuales en nuestro centro de datos principal, y cuatro servidores físicos muy distintos en el centro de datos secundario.” Pero podemos ir aún más allá, instalando las máquinas virtuales en cualquiera de los hosts de recuperación ante desastres, o ejecutando diversas funciones de una máquina virtual de producción a través de distintos hosts del sitio de recuperación ante desastres.

La flexibilidad que aporta la movilidad inherente de los servidores virtuales es asombrosa, y ofrece nuevas posibilidades para explotar los recursos de los servidores. En un entorno de servidores virtuales, los servidores físicos (hosts de máquinas virtuales) designados como servidores de recuperación ante desastres, pueden utilizarse para dar soporte a aplicaciones corrientes durante el flujo normal de las operaciones. Así, los servidores de recuperación ante desastres, en lugar de estar inactivos el 99% del tiempo, pueden emplearse para alojar aquellas aplicaciones que, en caso de desastre, dejan de ser necesarias.

Peter Allen, director de operaciones de TI de Nixon Peabody LLP, un bufete de abogados internacional con sede en Rochester (Nueva York, EE. UU.) y 18 oficinas en todo el mundo, indica: "Nuestros hosts VMware ESX nos brindan la oportunidad de aprovechar los servidores de recuperación ante desastres de nuestro centro de datos secundario para ejecutar tareas de desarrollo y de prueba en el transcurso normal de las operaciones." Allen dispone de 17 hosts ESX que albergan más de 100 servidores virtuales del centro de datos principal, en Rochester, y de un centro de datos secundario situado en Ohio.

Las ventajas que ofrecen los servidores virtualizados en los sistemas de protección de datos y de recuperación ante desastres se están convirtiendo en una razón de peso que impulsa a un número cada vez mayor de responsables de tecnología de la información a apostar por una infraestructura de servidores virtualizados. Bowker añade: “El factor de la recuperación ante desastres está ganando terreno a la consolidación como elemento clave a la hora de decidir la implantación de servidores virtuales. Hay quien se está decantando por instalar una única máquina virtual en un host para dar soporte a aplicaciones de vital importancia y que consumen un gran número de recursos, tales como Exchange, con el objetivo de beneficiarse de las ventajas que proporciona este sistema de recuperación ante desastres y de garantizar, a la par, una provisión de recursos suficiente; los aspectos positivos de la protección de datos compensan, con mucho, la ligera sobrecarga de virtualización que se produce."

Hipervisores y DR

El de VMware, con una cuota de mercado de, aproximadamente, el 70%, según los datos del estudio de ESG, constituye actualmente el hipervisor más utilizado, seguido de Microsot Virtual Server (23%), y de los distintos derivados de XenServer (en torno al 4%). Sin embargo, con el lanzamiento de Hyper-V (el sucesor de Microsoft Virtual Server), como componente del paquete Windows Server 2008, es muy probable que se produzcan cambios en estos porcentajes. Bowker, de ESG, apunta: “Gracias a la competitividad de su precio y al hecho de que Hyper-V forma parte del sistema operativo, se prevé que en 18 meses habrá más máquinas virtuales alojadas en Hyper-V que en ESX, de VMware."

Aunque los distintos hipervisores se basan en los mismos principios arquitectónicos, se diferencian en las prestaciones de implantación y gestión que ofrecen. Estas diferencias repercuten en los sistemas de protección de datos y de recuperación ante desastres, en tanto en cuanto determinan estrategias de implementación de las soluciones de DR también distintas.

ESX Server de VMware

En este ámbito, ESX Server es líder en prestaciones, rendimiento y escalabilidad, y presenta opciones y características arquitectónicas muy positivas cara a la protección de datos y a la recuperación ante desastres. En primer lugar, ESX Server no se ejecuta sobre un sistema operativo de otro fabricante, como Windows o Linux, e incluye, además, un núcleo muy fino optimizado para la tarea específica del hipervisor, que elimina el problema de la sobrecarga que presentan los sistema operativos multifunción.

Está integrado en el paquete Virtual Machine File System (VMFS), un sistema de archivos clusterizado específicamente diseñado para la virtualización. El almacenamiento compartido constituye un requisito clave de los hipervisores para poder compartir datos a través de máquinas virtuales, así como para poder realizar migraciones “en caliente”. Noemi Greyzdorf, responsable de investigación de software de almacenamiento de IDC, con sede en Framingham (Massachusetts, EE. UU.), nos los explica: “VMFS está especialmente concebido para las migraciones en caliente, y permite que varias máquinas virtuales que comparten un único número de unidad lógica (LUN) puedan, incluso, migrar o conmutarse en caso de fallo a máquinas virtuales individuales.”

La decisión de VMware de patentar un sistema de archivos propio y de ofrecer tareas de gestión de almacenamiento hace más difícil la realización, mediante las herramientas existentes de protección de datos, de copias de seguridad y replicaciones de archivos en formato VMDK (virtual machine disk, disco de máquina virtual) almacenados en un sistema de archivos diferente a los dispositivos convencionales. Para superar este escollo, VMware lanzó un paquete de herramientas y aplicaciones que permiten compatibilizar sus propios protocolos y mecanismos con las aplicaciones de protección de datos estándares.

Con los archivos en formato de disco virtual alojados en un sistema de archivos diferente, los usuarios de se ven obligados a ejecutar agentes de backup en cada máquina virtual, o bien a actualizar a Consolidated Backup (VCB) de VMware, si quieren contar con una solución de copias de seguridad más efectiva, dotada de mayor escalabilidad, que interfiera menos en el rendimiento del servidor. El sistema de backup consolidado obtiene un snapshot (sinopsis) de la máquina virtual y la envía a un servidor proxy central, donde se realiza la copia de seguridad de los datos por medio de aplicaciones de backup normales.

Como parte de este proceso, VCB desactiva el sistema de archivos de la máquina virtual para garantizar que al obtener el snapshot se recoja el estado completo de dicha máquina. Actualmente, VCB se queda corto cuando tiene que realizar copias de seguridad de aplicaciones como Exchange ejecutadas a través de máquinas virtuales. Aunque la última versión de VCB incorpora un módulo de consulta (requester) VSS para obtener snapshots que se adapten a las características de la aplicación, no ha solucionado la cuestión de la restauración, dado que la única manera de restaurar una aplicación a un nivel aceptable es restaurar toda la máquina virtual.

Site Recovery Manager (SRM) de VMware permite a las empresas automatizar el proceso de migración por fallo de su infraestructura de servidores virtuales. Si no se dispone de una herramienta como SRM, el proceso de migración por fallo tiene que realizarse manualmente o a través de scripts personalizados. La integración del software de replicación constituye un aspecto fundamental de la automatización del proceso de migración por fallo, y, en este caso, mediante plug-ins Site Recovery Adapter (SRA), el software de replicación de otros fabricantes puede combinarse con el sistema SRM.

Los principales proveedores de matrices y software de replicación han desarrollado, o están en ello, adaptadores SRA que VMware suministra de forma directa. SRM, que salió al mercado a finales de 2007, es una herramienta todavía en estado incipiente, que presenta deficiencias a las que, a buen seguro, se pondrá solución en futuras revisiones de la versión. Allen, de Nixon Peabody, afirma: “En la actualidad, no estamos utilizando SRM para trasladar máquinas virtuales al sitio de recuperación ante desastres, porque no es compatible con NFS, y sólo funciona con números de unidad lógica de canal de fibra.” No disponer de una herramienta como SRM para Hyper-V o XenServer no es tanto un problema grave como un inconveniente. Bowker, de ESG, desarrolla esta idea: “No hay nada del Site Recovery Manager de VMware que no pueda realizarse a través de scripts; de hecho, SRM, lo que hace, es proporcionarnos una interfaz gráfica de usuario para definir el proceso de recuperación y generarnos el script.”

VMware fue el primer proveedor de hipervisores que perfeccionó el sistema de migración en caliente de máquinas virtuales gracias a VMotion, que traslada la máquina virtual en uso, en su totalidad, y de forma instantánea, de un servidor a otro, sin provocar tiempos de inactividad en las aplicaciones. El estado completo de la máquina virtual se encapsula en un paquete de archivos alojados en un sistema de almacenamiento compartido, y el sistema de archivos clusterizado VMFS de VMware permite que los servidores de origen y destino de VMware ESX accedan a los archivos de la máquina virtual simultáneamente. La memoria activa y el estado de ejecución exacto de una máquina virtual pueden transferirse, a continuación, rápidamente, a través de una red de alta velocidad.

Si bien VMotion se emplea, fundamentalmente, por motivos operativos, los usuarios están explorando las ventajas de su aplicación a los planes de recuperación ante desastres, asociadas a la distribución de la carga de trabajo entre varios servidores ESX. Jim Yarber es responsable sénior de operaciones de red de HeritageBank of the South, un banco de ámbito regional situado en Albany (Georgia, EE. UU.) que ofrece sus servicios en la zona suroccidental de Georgia y en la región central y septentrional de Florida. Vmotion constituye una parte fundamental de su plan de recuperación ante desastres. “En caso de que tenga que realizarse una migración por fallo, las máquinas virtuales se transfieren a tres servidores ESX del sitio de recuperación ante desastres" —afirma. “Para hacer frente a la creciente carga de trabajo, utilizamos, además, VMotion, que nos permite llevar a cabo una migración transparente de los servidores virtuales a otros servidores ESX."

Yarber también aprovecha las ventajas de VMware HA, que permite controlar la disponibilidad de los servidores virtuales, además de transferir y reiniciar automáticamente los servidores virtuales en otros servidores ESX en caso de fallo. “VMware HA nos ofrece alta disponibilidad sin tener que invertir en los costosos equipos auxiliares y en el software complementario que requieren las soluciones clusterizadas de HA convencionales” —sostiene.

Hyper-V de Microsoft

Con Hyper-V, así como con su predecesor, Virtual Server, los discos virtuales se almacenan como archivos VHD en el sistema de archivos de Windows, y no se diferencian de otros tipos de archivos. En consecuencia, las herramientas y los sistemas de protección de datos de Windows preexistentes pueden utilizarse, sin necesidad de cambio alguno, para realizar las copias de seguridad y la restauración de los archivos VHD. Bob Roudebush, director de soluciones de ingeniería de la empresa Double-Take Software, declara: “En Double-Take podemos replicar los cambios a nivel de los archivos Hyper-V tal y como lo hacemos con los archivos de Exchange DB.”

A diferencia de ESX Server, de VMware, Hyper-V se vale del sistema de archivos NTFS, y no de un sistema de archivos clusterizado, lo que dificulta el proceso de migración en caliente. El paquete Quick Migration, de Microsoft, basado en un sistema de clusterización convencional, realiza una migración simultánea de todas las máquinas virtuales que posean el mismo número de unidad lógica. Dado que el sistema HA de Hyper-V depende aún de un software de clústers, los usuarios de Hyper-V pueden decantarse por un servidor de clústers de nueva generación, como la última versión de VCS, que puede albergar hasta 256 nodos heterogéneos y resulta muy ligero. “A diferencia del sistema HA de VMware, que proporciona una solución de recuperación ante desastres para contenedores de máquinas virtuales, sin tener en cuenta las características de las aplicaciones del servidor virtual, la prioridad de VCS es ofrecer alta disponibilidad adaptada a estas aplicaciones” —apunta Nadeau, de Symantec.

Aunque con Hyper-V Microsoft ha dado un colosal paso adelante respecto a su estadio anterior, representado por Virtual Server, especialmente, en lo que respecta a la gestión, la fiabilidad y la escalabilidad, Hyper-V todavía no se sitúa al mismo nivel que ESX Server, de VMware. Por otra parte, su sistema de recuperación ante desastres está más suboDRinado a herramientas de otros fabricantes y scripts personalizados que el de ESX Server.

XenServer y Virtual Iron

Si bien existe un amplio número de proveedores (Citrix Systems Inc., Novell Inc., Oracle Corp., Red Hat Inc., Sun Microsystems Inc. y otros distribuidores Linux) que ofrecen hipervisores de tecnología Xen, de código abierto, los productos que han cosechado la mayor aceptación han sido Citrix XenServer y Virtual Iron Software Inc.

Al igual que Hyper-V, Xen se ejecuta sobre sistemas operativos Unix; fundamentalmente, sobre Linux. Sin embargo, a diferencia de Hyper-V, los archivos de la máquina virtual se graban en discos vírgenes, lo que dificulta el control y el backup de los cambios que se produzcan en los archivos por parte de las herramientas de protección de datos. “Necesitamos incorporar un controlador de filtrado de volúmenes a nivel de bloques para replicar los archivos de imágenes virtuales Xen” —afirma Roudebush.

El hipervisor Xen contempla la migración en caliente de máquinas virtuales en uso, pero no se realiza a través de un sistema de archivos virtuales como VMFS. Por el contrario, se basa en la actividad de unidades NFS para crear directorios compartidos mientras se transfieren las máquinas virtuales de un host a otro. Para migrar servidores virtuales de forma individual, XenServer asigna un número de unidad lógica a cada imagen de disco virtual y se vale de las funciones de los sistemas de almacenamiento para realizar copias de seguridad, snapshots y clones de estos volúmenes.

Entre los diversos hipervisores Xen que han salido al mercado, Virtual Iron ofrece las herramientas de gestión con mayores prestaciones, en un intento de situarse al nivel de VMware. Chris Barclay, responsable de gestión de productos de Virtual Iron, desarrolla esta idea: "Entramos en escena para cubrir las necesidades de aquellos clientes que no pueden costoarse el producto de VMware. Por un precio tres veces inferior, proporcionamos herramientas de gestión muy similares a las suyas.”

Opciones de backup para servidores virtuales

En función del hipervisor que se emplee, de la infraestructura tecnológica instalada y de los objetivos de tiempo de recuperación (RTO) y objetivo del punto de recuperación (RPO) previstos, las empresas pueden implantar distintos métodos de recuperación ante desastres para servidores virtuales.

Sistemas de backup y de recuperación convencionales: Las pequeñas y medianas empresas con un reducido número de servidores suelen optar por realizar copias de seguridad de las máquinas virtuales y restaurarlas en el sitio de recuperación ante desastres en caso de que se produzca una situación de este tipo. Como la restauración puede llevarse a cabo en la práctica totalidad de los equipos que ejecuten el software del hipervisor, los requisitos de hardware para restaurar los servidores físicos no representan un problema. La capacidad de restaurar múltiples máquinas virtuales en un único host permite minimizar, aún más, los requisitos de hardware a efectos de la restauración en el sitio secundario, y contribuye a reducir de forma significativa el costo total del plan de recuperación ante desastres.

La forma más sencilla, en este contexto, para realizar las copias de seguridad de los servidores consiste en instalar agentes de backup en las máquinas virtuales, pero esto hace que aumente la sobrecarga, y puede provocar que el rendimiento del servidor se vea afectado por la ejecución de los backups. Las empresas que utilizan VMware tienen la opción de implantar Consolidated Backup de VMware, que elimina la carga de la copia de seguridad de las máquinas virtuales. Además de realizar la copia de seguridad de cada máquina virtual, pueden ejecutarse backups a nivel de los hipervisores, gracias a lo cual desaparece la necesidad de instalar agentes en cada máquina, aunque esta posibilidad también entraña inconvenientes, dado que sólo permite llevar a cabo la restauración a nivel de la máquina virtual.

Los proveedores de software de backup, como CommVault, han ampliado sus paquetes de backup para adaptarlos a las necesidades en materia de copias de seguridad de los servidores virtuales. La inmensa mayoría de los productos de los proveedores de software de backup incorporan VCB, y algunos han añadido prestaciones complementarias. Peter Kovaleski, administrador de redes Unix que trabaja para la universidad de Tulsa (Oklahoma, EE. UU.) Oral Roberts University, afirma: “Utilizamos VCB de VMware y Galaxy de CommVault para realizar el backup de unos 70 servidores ESX de VMware.  El agente de restauración de CommVault nos permite volver a restaurar archivos directamente en hosts ESX, lo que elimina la tarea manual de copiar los archivos del servidor proxy en la máquina virtual.”

Replicación síncrona o asíncrona

La obtención de snapshots y réplicas a partir de los sistemas de almacenamiento representa, en la gran esfera empresarial, el método predominante de transferencia de imágenes y datos de máquinas virtuales de un sitio primario a uno secundario. Desde el punto de vista del sistema de almacenamiento y de la técnica de replicación, los requisitos de protección de servidores físicos y virtuales son muy similares.

En primer lugar, los snapshots están programados para registrar cualquier cambio que se produzca a partir del momento de la obtención de la última "fotografía". La frecuencia de los snapshots varía en función del objetivo de tiempo de recuperación (RPO) aceptable. La desactivación de los servidores virtuales es una condición esencial del proceso de toma de los snapshots, para garantizar que registren el estado completo de la máquina virtual en el momento que en que se realizan. A continuación, las snapshots se duplican en el sitio secundario, a través de un proceso de replicación síncrono o asíncrono.

Entre los distintos tipos de hipervisores que se comercializan, los de Microsoft son los que ofrecen menos problemas de integración con el sistema de almacenamiento, ya que utilizan los sistemas NTFS y VSS, protocolos ampliamente compatibles con las soluciones de los proveedores de tecnologías de almacenamiento. Del mismo modo, gracias a su cuota de mercado, que asciende al 70%, VMware disfruta de una vasta compatibilidad de integración, especialmente, en el caso de Site Recovery Manager, con el que pueden trabajar las soluciones de la mayor parte de los proveedores de tecnologías de almacenamiento.

La técnica de obtención de snapshots y réplicas de los sistemas de almacenamiento es la preferida por los usuarios corporativos, porque, a menudo, cuentan ya con servicios de snapshots y réplicas asociados a sus sistemas de almacenamiento, y se muestran reticentes a adoptar soluciones alternativas cuya eficacia no está tan demostrada, como la protección continua de datos (CDP). Allen, de Nixon Peabody, nos explica: “Decidimos recurrir a NetApp y a SnapManager, de NetApp, para nuestra infraestructura virtual porque nos permitía automatizar las tareas que antes había que realizar mediante scripts: desde la desactivación de las máquinas virtuales y la obtención de snapshots hasta su replicación en el sitio secundario."

CDP

Los productos de protección continua de datos (CDP), como Double-Take for Virtual Systems, CDP Virtual Appliance, de FalconStor Software Inc., diseñado para la infraestructura de VMware y para Network Storage Server (que permite una migración automática por fallo, adaptada a las aplicaciones, en clústers situados en distintos puntos geográficos tanto de servidores físicos como de servidores virtuales Hyper-V), y DR-Scout de InMage Systems Inc. constituyen soluciones viables de recuperación ante desastres alternativas a las técnicas de snapshot y replicación a partir de los sistemas de almacenamiento por varios motivos. Por un lado, resultan menos costosas, en especial, para aquellos clientes que no disponen de sistemas de almacenamiento análogos en el centro de datos principal y en el secundario. Por otro, registran y replican los cambios en el momento en que se producen, y añaden una escasa sobrecarga a las máquinas virtuales. Por último, los productos CDP no sólo proporcionan migración por fallo de la última réplica, sino que también permiten a los usuarios recuperar los datos de puntos anteriores en el tiempo.

Yarber, de HeritageBank, apunta: “Elegimos utilizar DR-Scout sobre un sistema de replicación en matrices por el escaso ancho de banda que consumía. Tengo una conexión Ethernet de 100 Mb entre nuestros dos centros de datos, y DR-Scout apenas la toca.”

Sin duda, los servidores virtualizados están generando una auténtica revolución en el seno de las estrategias de recuperación ante desastres. Éstas siempre han presentado el inconveniente de su elevado costo, por lo que muchos de los planes de DR sólo abarcan las aplicaciones de vital importancia. Los servidores virtuales, gracias al mayor nivel de movilidad y a la relativa autonomía respecto al haDRware que presentan, contribuyen en gran medida a reducir estos costos y la complejidad de implantación del programa de recuperación ante desastres, lo que permite a las empresas extender el plan de DR a un mayor número de servidores y aplicaciones.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close