La próxima versión de Veeam Availability Suite v9 incluirá, entre muchas características nuevas e increíbles, más mejoras para entornos Enterprise. En estos entornos, suelen surgir dos características principales, que requieren soluciones adecuadas: escalabilidad y administración de múltiples oficinas remotas/sucursales (ROBO).
Una de las grandes capacidades avanzadas de nuestro software es la interacción con el sistema operativo (guest) de las máquinas virtuales protegidas para realizar un respaldo y una restauración adecuados. Al ser una solución sin agentes, nuestros trabajos de respaldo implementan un proceso de tiempo de ejecución temporal en cada máquina virtual para la que se activa el “Procesamiento de imágenes con reconocimiento de aplicaciones”. Este proceso es responsable de la organización de procesamiento de VSS y de ejecutar tareas específicas dentro del proceso de Backup específicos para las aplicaciones, como el truncamiento de registros (logs) y el indexado de los archivos del sistema operativo guest.
Antes de la v9, todas las interacciones con archivos guest eran realizadas por el servidor de backup. Para cada VM protegida, la consola central implementa el proceso de interacción directamente en la VM (ya sea directamente en el sistema operativo guest por medio de la red o utilizando VIX API por medio de una conexión a un host para guests en redes desconectadas). Este proceso siempre ha funcionado a la perfección, pero a medida que crecían los entornos protegidos, en tamaño y complejidad, aparecieron dos límites aparentes.
El primero de ellos tiene relación directa con la escalabilidad. El procesamiento a nivel de Sistema Operativo guest se administra con el servidor de backup, pero, con el tiempo, la cantidad de VM´s protegidas en un entorno de cliente típico ha crecido de forma tan significativa que los recursos del servidor de backup comenzaron a verse afectados por “ cuellos de botella”, lo que limita la cantidad de accesos o interacciones simultaneas a nivel del Sistema Operativo “guest” antes de que los trabajos comiencen a experimentar tiempos de espera.
El segundo límite está relacionado, en cierta forma, con el primero. Por lo general, los entornos Enterprise también cuentan con varias oficinas remotas, con entornos virtuales implementados de forma local para servir a los usuarios de aquellas sucursales. Dado que en esos escenarios el servidor VBR suele implementarse en las oficinas centrales, todas las interacciones a nivel de Sistema Operativo “ guest “ deben realizarse por medio del enlace WAN, que suele ser lento.
Entonces, incluso si se desplegara un Proxy o Repositorio remotos o un repositorio en la sucursal para mantener el tráfico local de respaldos y restauración, el tráfico relacionado con el Sistema operativo “ guest” aún necesitaría hacer uso del enlace WAN, lo que supondría problemas de escalabilidad en estos entornos.
Para mejorar el rendimiento, la v9 incluirá un “ Guest Interaction Proxy “. Los clientes pueden asignar este rol virtual a cualquier Windows Server administrado (incluidos los proxies y los repositorios de respaldo existentes). El proxy de backup remoto en una sucursal suele ser el candidato ideal, ya que es el más cercano a las máquinas virtuales que protege:
Con el Proxy de interacción guest instalado, el servidor de backup solo enviará comandos de control a través del enlace WAN. El Proxy de interacción guest “local” se encargara de todos los procesos a nivel de interacción con el Sistema Operaivo “ guest “ en todas y cada una de las VM´s protegidas.. Como resultado, se minimizará el tráfico que tiene que enviarse por medio de ese enlace lento y de esta forma se reducirá la carga del servidor VBR. Además, como un solo servidor de backup podrá controlar múltiples proxies de interacción guest, la escalabilidad mejorará en gran medida. Por ejemplo, piense en un usuario de Enterprise con 500 sitios remotos. Ahora, este negocio puede designar el proxy de backup de cada sitio para que actúe como el proxy de interacción guest, todo controlado desde el servidor de respaldo central. Y, desde luego, también pueden utilizarse múltiples proxies de interacción guest en un único centro de datos grande para mejorar el rendimiento y la escalabilidad en todo lo relacioando con actividades a nivel de Sistema Operativo “ guest”.
Otro beneficio oculto de esta funcionalidad, que quizás no sea evidente a primera vista, es obtener acceso al sistema operativo guest cuando el procesamiento sin conexión de red por medio de VIX no sea posible; por ejemplo, cuando no puede proporcionarse la cuenta con privilegios de acceso a nivel de Sistema Operativo “guest”, debido a razones de seguridad. Básicamente, ahora puede designar un equipo Windows con una NIC tanto en redes de producción como de respaldo y aprovecharlo como un proxy de interacción guest para “enviar” comunicaciones de la red de respaldos a la red de producción.
Pero los respaldos siempre son solo parte de la historia. Una vez que los datos estén almacenados de forma segura en un repositorio, quizás sea necesaria una restauración. Y, si observamos nuevamente este caso desde el escenario de la oficina remota, actualmente, las restauraciones a nivel de archivo deben estar dirigidas por un servidor de respaldos central, con archivos de respaldo montados directamente en este:
Entonces, incluso si el repositorio de respaldos fuera “local” en relación con el entorno virtual remoto, durante las restauraciones a nivel de archivo local, los datos deberán atravesar este enlace WAN dos veces: primero se envían al servidor de respaldos y, luego, regresan a la máquina virtual en el sitio remoto. Una solución alternativa popular es utilizar el asistente de restauración a nivel de archivo (FLR) para múltiples sistemas operativos con la aplicación de ayuda de FLR ejecutada en el sitio remoto; sin embargo, este método tiene sus propias desventajas.
Con la v9, esto ya no es necesario gracias a la nueva configuración Mount Server para cada repositorio de respaldos. Básicamente, ahora cualquier Windows Server administrado con Veeam puede designarse como un punto de montaje de FLR para respaldos de Veeam. Y, desde luego, ¡no hay una mejor opción para una oficina remota que un repositorio existente basado en Windows sea su propio host de montaje!
Actualmente, gracias a este nuevo rol virtual, el servidor de VBR central solo enviará comandos de control por medio del enlace WAN, mientras que el backup remoto se montará con el servidor de montaje “local” designado para restaurar los archivos requeridos directamente en la máquina virtual remota, y todas las trasferencias de datos permanecerán dentro del sitio remoto.
En relación con las operaciones “remotas”, otra novedad o mejora muy importante que se incluirá en la v9 es una consola independiente. Sí, nos referimos a la muy esperada consola Veeam Backup & Replication que los administradores de Veeam podrán instalar por separado del servidor de respaldos, como en sus propias estaciones de trabajo, y que permitirá administrar el servidor de respaldos de forma remota por medio de la red. Dígale adiós a las sesiones de RDP o a aquellas con múltiples usuarios luchando entre ellos para conectarse al mismo servidor de respaldos, ya que ahora cada operador podrá tener su propia consola. Es importante destacar que la consola también asume el rol de un servidor de montaje para escenarios de recuperación avanzados en los que deben montarse respaldos locales (como para Veeam Explorer); una capacidad que será muy útil en escenarios ROBO.
Pero, ¡eso no es todo! Como ya pudo observar en la v8, estamos completamente comprometidos y decididos a proporcionar el mejor soporte de cinta del mercado para clientes de cualquier tamaño; la v9 traerá muchas mejoras adicionales en las funcionalidades de cinta que nuestros clientes de Enterprise han estado esperando con interés. Solo explicaré las más importantes, ¡pero puedo asegurarle que hay muchas otras!
La primera, y, en mi opinión, la más importante, es la capacidad de crear un conjunto de medios que se desprende de una única librería de cintas física y que es capaz de abarcar datos a través de múltiples librerías de cintas. Este “conjunto global de medios” se convertirá en el principal objetivo cuando se trate de trabajos de cintas y mejorará el rendimiento y la experiencia general de administración.
Un trabajo de cinta en el “conjunto global de medios” puede utilizar múltiples librerías de cintas o unidades independientes dependiendo del orden de failover (conmutación por error) de la librería configurada y cambiar a una de las librerías disponibles si ocurre un evento de failover. Por ejemplo, imagine que a una librería se le acaban los Media Pool asignados, o que tiene todas las unidades de cinta ocupadas. Gracias a los conjuntos globales de medios, un trabajo de cinta puede cambiar a otra librería que aún tenga media pools o unidades de cinta disponibles.
¿Qué otras características se incluirán en el rendimiento operativo de cinta? En la v9, ¡estará disponible el procesamiento paralelo entre múltiples unidades de cinta, tan solicitado por los clientes! Lo que antes requería configurar múltiples media pools y trabajos de respaldos de cinta, con una complejidad incrementada, ¡ahora está disponible de inmediato!
Esto será una opción simple, pero poderosa, que le permitirá ejecutar simultáneamente trabajos de cinta orientados al mismo conjunto de medios o expandir el archivado de los archivos de respaldo fuente entre múltiples unidades.
A continuación, hablemos acerca de la rotación de medios de cinta. Estoy seguro de que muchos de ustedes estarán felices al escuchar que habrá un nuevo tipo de conjunto de medios disponible en la v9: el conjunto de medios GFS dedicado a respaldos completos. De manera similar, aunque es posible lograr casi el mismo resultado con múltiples conjuntos de medios en la v8, la v9 va más allá al quitar por completo la complejidad asociada a la administración.
Si está familiarizado con nuestro mecanismo de rotación (Grandfather – Father – Son: GFS) de trabajos de copia de respaldo en la v8, el concepto sigue siendo el mismo, por lo cual debería ser sencillo de entender. Cuando los respaldos completos se orientan al conjunto de medios GFS en los tipos de configuración de trabajos de respaldo a cinta, las cintas correspondientes se mantienen según un esquema de retención específico, que comprende semanas, meses, trimestres e incluso años, en la medida que su política de retención de datos lo requiera.
Con un conjunto de medios GFS, se necesitan menos cintas para obtener una política de retención más prolongada. Por ejemplo, el esquema de rotación GFS está configurado para mantener 4 años de respaldos completos en solo 19 cintas: 4 semanales, 12 mensuales y 3 anuales. Todavía están disponibles los conjuntos de medios simples para retención de respaldos completos a corto plazo y respaldos incrementales; por lo tanto, usted es quien decide, en última instancia, qué conjunto de medios se adapta mejor a su escenario de retención de datos deseado.
Como puede ver , hay una gran variedad de mejoras significativas de las funcionalidades específicas de clase Enterprise en la v9. Y eso sin tener en cuenta que acabamos de empezar a lanzar los anuncios de las nuevas funcionalidades y características de la V9 , pero todavía no hemos revelado ni anunciado la mejor y más interesante de estas funcionalidades.. Espero que nuestros esfuerzos hayan demostrado claramente que prestamos atención a las necesidades específicas de nuestros clientes, y que estamos decididos a proporcionarle un producto que esté 100 % preparado para asumir los retos Enterprise y que permite escalar de forma sencilla para mantener en todo momento la disponibilidad de su negocio en constante crecimiento.
