Citrix Virtual Apps and Desktops: Planificación de recuperación ante desastres

Información general

Esta guía ayuda con la planificación de la arquitectura de continuidad del negocio (BC) y recuperación ante desastres (DR) y consideraciones para implementaciones locales y en la nube de Citrix Virtual Apps and Desktops. La DR es un tema importante en su amplitud de alcance en sí misma. Citrix reconoce que este documento no es una guía completa de la estrategia general de recuperación ante desastres. No tiene en cuenta todos los aspectos de la DR y, a veces, toma una perspectiva de términos más laicos en varios conceptos de DR.

Esta guía tiene por objeto abordar las siguientes consideraciones que tienen un impacto significativo en la arquitectura Citrix de una organización y proporcionar orientación arquitectónica relacionada con ellas:

  • Requisitos del negocio
  • Recuperación ante desastres frente a Alta disponibilidad
  • Clasificaciones de niveles de recuperación ante desastres
  • Opciones de recuperación ante desastres
  • Recuperación ante desastres en la nube
  • Consideraciones sobre la operación

Requisitos del negocio

Alineación con la “capa empresarial” de la metodología de diseño de Citrix, recopilando requisitos empresariales claros y restricciones conocidas para la recuperación del servicio. Documentar estos elementos es el punto de partida en el desarrollo de cualquier plan de recuperación para Citrix. Este paso ayuda a obtener claridad sobre el alcance y proporcionar orientación sobre la estrategia de recuperación ante desastres más adecuada para satisfacer los requisitos empresariales y funcionales, y las limitaciones.

Las preguntas útiles a haber respondido incluyen, pero no se limitan a, las siguientes. Estas preguntas se analizan con más detalle en la Opciones de recuperación ante desastres sección en términos de cómo afectan a un diseño de Citrix DR:

  • Estrategia de reserva y objetivo de tiempo de recuperación (RTO). ¿Qué estrategia de backup se utiliza hoy en día para los servidores? ¿Frecuencia de respaldo? ¿Período de retención? ¿Almacenamiento fuera del sitio? ¿Probado? ¿La plataforma Citrix debe estar disponible inmediatamente en caso de un desastre o ponerse en línea dentro de un período de tiempo específico? (Consulte Clasificaciones de niveles de recuperación ante desastres). Vale la pena incluir los back-ends de aplicaciones a los que se conectan las aplicaciones alojadas en Citrix en la discusión para alinear las expectativas.
  • Objetivo de punto de recuperación (RPO). Para RPO, ¿qué grado de pérdida de datos se considera tolerable para DR, que puede variar en función del componente de infraestructura o de la clasificación de datos? ¿Qué edad pueden tener los datos recuperados para el servicio? ¿0 minutos? ¿Una hora? ¿Un mes? En el contexto de la infraestructura de Citrix, esta consideración solo puede aplicarse a los cambios en la base de datos y a los datos de usuario (perfiles, redirección de carpetas, etc.). Al igual que con RTO, vale la pena considerar los back-end de la aplicación para las aplicaciones alojadas en Citrix en la discusión.
  • Alcance de la recuperación. Esta consideración no incluye solo la infraestructura de Citrix, sino que puede incluir datos de usuario o servidores de aplicaciones clave con los que interactúan los clientes de aplicaciones alojados en Citrix. Es importante identificar si va a haber una disparidad entre el tiempo para recuperar la plataforma Citrix y el tiempo para recuperar aplicaciones alojadas en Citrix. El tiempo delta puede prolongar una interrupción ya que solo parte de la solución está en línea.
  • Casos de uso. Las plataformas Citrix suelen atender numerosos casos de uso, cada uno con diferentes niveles de criticidad empresarial. ¿Cubre la recuperación todos los casos de uso de Citrix? O casos de uso clave de los que el éxito operativo de la empresa depende completamente. La respuesta tiene un gran impacto en el alcance de la infraestructura y las proyecciones de capacidad. Se recomienda segmentar y priorizar los casos de uso para compartimentar la habilitación de DR si se trata de una nueva capacidad neta para el entorno Citrix.
  • Prestaciones. ¿Hay alguna funcionalidad clave que no pueda incluirse en la recuperación ante desastres que pueda reducir los costes? Un ejemplo de esta capacidad sería el uso de escritorios persistentes frente a no persistentes; algunos casos de uso de VDI que pueden ser servidos por escritorios compartidos alojados, o incluso solos de aplicaciones específicas. Los clientes a veces han indicado redundancia de componentes (ADC, Controllers, StoreFront, SQL, etc.) no se consideran necesarias en DR. Tales decisiones pueden considerarse un riesgo si se produce una interrupción prolongada de la producción.
  • DR existente. ¿Existe una estrategia o plan de recuperación ante desastres existente para otros entornos Citrix y otros servicios de infraestructura? ¿Se recupera en nuevas subredes redirigibles o en una “burbuja” que refleja las redes de producción? La respuesta puede ayudar a dar visibilidad a los enfoques actuales de recuperación ante desastres, herramientas o prioridad.
  • Prestaciones tecnológicas. Esta consideración no puede dictar la estrategia final de recuperación de Citrix, sin embargo, es importante comprender:
    • Recuperación: ¿Qué tecnologías de replicación de almacenamiento, tecnologías de recuperación de VM (VMware SRM, Veeam, Zerto, Azure Site Recovery (ASR), etc.) están disponibles dentro de la organización? Algunos componentes de Citrix junto con las dependencias de Citrix pueden utilizarlos.
    • Citrix: ¿Qué tecnologías Citrix se utilizan para la administración y el acceso de imágenes? Algunos componentes no pueden prestarse bien a ciertas estrategias de recuperación. Los entornos no persistentes administrados por MCS o PVS son candidatos pobres para tecnologías de replicación de VM debido a su estrecha integración con el almacenamiento y las redes.
  • Criticidad de los datos. ¿Los perfiles de usuario o los datos de usuario se consideran críticos para la recuperación? ¿VDI persistentes? Si estos datos no están disponibles cuando se invoca DR, ¿esto causaría impactos significativos en la productividad? ¿O se puede usar un perfil no persistente o VDI como solución temporal? Esta decisión puede aumentar los costes y la complejidad de las soluciones.
  • Tipos de desastres. Esta decisión es bastante significativa, pero también puede preestablecerse a través de un plan corporativo de BC o DR. Este requisito suele dictar la ubicación de recuperación. ¿Está pensada la estrategia para dar cabida a la recuperación del servicio únicamente a nivel de aplicación? ¿Entre bastidores de hardware? ¿Dentro de un metro? ¿Entre dos geografías? ¿Dos países? ¿Dentro de una región de proveedor de nube o una infraestructura completa de un proveedor de nube (varias regiones)?
  • Usuarios cliente. ¿Dónde se encuentran los usuarios que acceden a los servicios en producción? Esta decisión puede tener implicaciones en cuanto a dónde se restaura el servicio, incluida la conectividad de red corporativa que puede requerir modificaciones manuales durante un evento de recuperación ante desastres. Además, la respuesta dicta consideraciones sobre el nivel de acceso.
  • Ancho de banda de red. ¿Cuánto tráfico (ICA, aplicaciones, servicios de archivos) consume cada sesión de usuario en promedio? Esta decisión se aplica tanto a la recuperación en la nube como en las instalaciones.
  • Fallback (o failback). ¿Tiene la organización planes preexistentes para volver al servicio en producción una vez que se haya resuelto la situación de DR? ¿Cómo se recupera la organización a un estado normal? ¿Cómo se concilian y consolidan los nuevos datos que se pueden haber creado en DR con la producción?

Las restricciones limitan las opciones de diseño de BC/DR o sus configuraciones. Vienen en muchas formas, pero pueden incluir:

  • Directiva regulativa o corporativa. Esta decisión puede dictar qué tecnologías pueden o no se pueden usar para replicación o recuperación, cómo se usan, RTO o distancia mínima entre instalaciones.
  • Infraestructura. ¿Existe una directiva sobre el tipo de hardware que se va a utilizar, el ancho de banda de red disponible, etc.? Estas consideraciones pueden afectar a las consideraciones de RPO o incluso pueden presentar riesgos. Por ejemplo, los firewall de tamaño inferior o las tuberías de red en DR pueden provocar interrupciones, ya que las dependencias de red no pueden manejar la carga de trabajo de DR. O bien, en el caso de la computación, los hosts de hipervisores de tamaño insuficiente o el uso de diferentes hipervisores pueden afectar por completo a las opciones. Con respecto a la red, si el sitio de recuperación tiene una capacidad de rendimiento de red más limitada que la producción al realizar el mantenimiento de la WAN. En entornos de nube, especialmente al escalar a miles de puestos, este riesgo potencial puede convertirse rápidamente en un cuello de botella significativo debido a limitaciones de servicios de componentes como firewalls virtuales, puertas de enlace VPN y enlaces ascendentes de nube a WAN (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, etc. en).
  • Presupuesto. Las soluciones de recuperación ante desastres vienen con costes que pueden entrar en conflicto con los presupuestos de los proyectos. La mayoría de las veces, cuanto más corto sea el RTO, mayor será el coste.
  • Geografía. Si se ha identificado una instalación de recuperación ante desastres designada, deben entenderse consideraciones como la latencia desde la producción hasta las instalaciones de DR, además de los usuarios que se conectan a la DR.
  • Residencia de datos o clasificación de datos. Esta decisión puede limitar las opciones en términos de configuraciones regionales y tecnologías o métodos de recuperación.
  • Recuperación en la nube. ¿Existe un mandato para que la infraestructura se recupere en la nube frente a una instalación local?
  • Preparación de la aplicación. ¿Las aplicaciones alojadas en Citrix que tienen dependencias de back-end tienen un plan BC/DR y cómo se alinean los RTO al RTO de destino de Citrix? Citrix se puede diseñar para una recuperación rápida, pero si las aplicaciones principales no tienen un plan de recuperación o uno con un RTO extendido, este riesgo probablemente afecte a la utilidad de la plataforma Citrix en DR.
  • Seguridad de la red. ¿Tiene la organización directivas de seguridad que pueden dictar qué segmentos de tráfico requieren cifrado en tránsito? ¿Esta consideración varía dependiendo del enlace de red que se atraviesa? La respuesta puede requerir en escenarios de recuperación ante desastres el uso de SSL VDA, ICA Proxy, GRE o encapsulación VPN IPSec del tráfico ICA si los flujos de red para DR son diferentes de los de producción.

Conceptos erróneos sobre el diseño de recuperación ante desastres

Uno de los conceptos erróneos más comunes para los diseños de Citrix DR, a los que se hace referencia en este artículo, es la noción de que un único plano de control que abarca dos centros de datos constituye DR. No lo hace. Un único Citrix Site o PVS Farm que abarque centros de datos, incluso los cercanos, constituye un diseño de alta disponibilidad, pero no un diseño de recuperación ante desastres. Algunos clientes eligen esta ruta como una decisión empresarial que valora la administración simplificada sobre la capacidad de recuperación ante desastres. La expansión de grupos de servidores de StoreFront se admite solo entre centros de datos bien conectados (baja latencia). Del mismo modo, ha documentado los máximos de latencia a tener en cuenta al implementar en centros de datos como se describe en CTX220651.

El siguiente diagrama es un ejemplo de una arquitectura de Citrix de alta disponibilidad de centros de datos múltiples que, sin embargo, no es una plataforma de recuperación ante desastres debido a la justificación mencionada anteriormente. Esta arquitectura de referencia la utilizan los clientes que tratan dos instalaciones de centros de datos físicamente separadas como un único centro de datos lógico debido a su proximidad entre sí y a la baja latencia y la interconectividad de alto ancho de banda. Aún se recomendaría un plan de recuperación ante desastres y un entorno para Citrix, ya que es poco probable que esta arquitectura satisfaga las necesidades de DR o HA.

Recuperación ante desastres

Además de la referencia conceptual de alta disponibilidad anterior, las arquitecturas HA que aplican zonas están disponibles para los clientes que quieren proporcionar redundancia geográfica cruzada, pero no requieren que la plataforma sea totalmente recuperable. El concepto de zonas de la arquitectura IMA heredada (XenApp 6.5 y versiones posteriores) se rediseñó para FMA y se reintrodujo en XenDesktop 7.7 con mejoras importantes en 7.11, lo que permite varias capacidades de redundancia dentro del sitio que pueden resolver los desafíos de las implementaciones en varias ubicaciones.

En una arquitectura de sitio que utiliza la función preferencia de zona (7.11 y versiones posteriores), se implementan recursos de Citrix idénticos en varias zonas y se agregan en un único grupo de entrega. La preferencia de zona (con la capacidad de devolver a otras zonas para un recurso determinado) se puede controlar en función de la aplicación, la zona de inicio del usuario o la ubicación del usuario. Consulte Zone preference internals para obtener más información sobre este tema. La función de Registro de VDA actualización automática (introducida en XenDesktop 7.6) permite a los VDA mantener una lista actualizada almacenada en caché localmente de todos los controladores de un sitio. Esta función permite que los VDA dentro de la zona satélite conmuten por error el registro a los VDA a la zona principal en caso de que sus Delivery Controllers o Cloud Connectors locales no estén disponibles en su zona local. Los grupos de servidores StoreFront están presentes en cada ubicación de zona, como se recomienda para que los usuarios continúen accediendo a los recursos desde su nivel de acceso local en caso de que la zona principal no esté disponible.

Recuperación ante desastres

A diferencia de estas opciones de alta disponibilidad admitidas, el siguiente diagrama ilustra arquitecturas de componentes no admitidas o mal aconsejadas que abarcan centros de datos geográficamente distantes o regiones de nube. Estos diagramas no proporcionan alta disponibilidad ni DR efectivos debido a la distancia y latencia entre los componentes. También pueden producirse problemas de estabilidad de la plataforma debido a problemas de latencia en dicha implementación. Además, la extensión de los límites administrativos entre sitios no se ajusta a los principales de DR. Hemos visto diseños conceptuales similares por parte de los clientes en el pasado.

Recuperación ante desastres

Otro concepto erróneo común es la profundidad de la consideración que puede incluir una solución Citrix DR. Citrix Virtual Apps and Desktops en su núcleo es principalmente una plataforma de presentación y entrega. El plano de control de Citrix depende de otros componentes (redes, SQL, Active Directory, DNS, CAL de RDS, DHCP, etc.) cuya disponibilidad y diseño de recuperación propio cumplen los requisitos de recuperación ante desastres de la plataforma Citrix. Cualquier dominio administrativo compartido de tecnologías del que dependa Citrix puede afectar la eficacia de la solución Citrix DR.

Las consideraciones de recuperación de los servicios de archivos (datos de usuario y de negocios en recursos compartidos, etc.) y back-end de aplicaciones con las que interactúan las aplicaciones y los escritorios alojados en Citrix, tienen una importancia similar y, en ocasiones, no están plenamente contabilizadas por los clientes. Al hacer referencia al punto anterior sobre la preparación de las aplicaciones, se puede diseñar una plataforma Citrix DR para recuperarse en períodos cortos de tiempo. Sin embargo, si estas dependencias principales de casos de uso no poseen un plan de recuperación con RTO similar a Citrix o ningún plan de recuperación en absoluto, este plan puede afectar a la conmutación por error de Citrix correctamente en DR como se esperaba, pero los usuarios no pueden realizar sus funciones de trabajo porque estas dependencias permanecen no disponibles. Por ejemplo, un hospital que hospeda su aplicación EMR principal en Citrix. Se produce un evento de DR y Citrix conmuta por error a una plataforma Citrix “siempre encendida” en DR y los usuarios se están conectando, pero la aplicación EMR se recupera a través de medios más manuales que pueden tardar horas o días en completarse. El personal clínico probablemente se vería obligado a utilizar procesos fuera de línea (lápiz y papel) durante este tiempo. Tal resultado no puede ser congruente con la expectativa general de la empresa en cuanto al tiempo de recuperación o a la experiencia del usuario.

La siguiente sección discutirá DR vs. HA con más detalle.

Recuperación ante desastres (DR) frente a Alta disponibilidad (HA)

Comprender HA vs. La DR es fundamental para adaptarse a las necesidades de la organización y cumplir los objetivos de recuperación. HA no es sinónimo de DR, pero DR puede usar HA. Esta guía interpreta HA y DR de la siguiente manera:

  • Se considera que ha proporcionado tolerancia a fallas para un servicio. Un servicio puede conmutar por error a otro sistema con una interrupción mínima para un usuario. La solución puede ser tan simple como una aplicación en clúster o balanceada de carga para una infraestructura “caliente” o “siempre activa” más compleja, activa o en espera, que refleja las configuraciones de producción y siempre está disponible. La conmutación por error tiende a automatizarse en estas configuraciones y también se puede denominar implementación “georredundante”.
  • La recuperación ante desastres se refiere principalmente a la recuperación del servicio (debido a fallas significativas a nivel de aplicación o a fallas físicas catastróficas del centro de datos) a un centro de datos alternativo (o plataforma en la nube). La recuperación ante desastres tiende a implicar procesos de recuperación automatizados o manuales. Los pasos y procedimientos se documentan para orquestar la recuperación. No se refiere a la redundancia o la tolerancia a fallas del servicio y generalmente es una estrategia de alcance más amplio que soporta múltiples tipos de fallas.

Mientras que HA tiende a integrarse en las especificaciones de diseño y la implementación de soluciones, DR se ocupa en gran medida de la planificación de la orquestación de recursos de personal e infraestructura para invocar la recuperación del servicio.

¿Puede HA incluir DR? Sí. En el caso de los servicios de TI de misión crítica para empresas, este concepto es común. Tomemos, por ejemplo, el segundo ejemplo de la descripción de HA anterior, junto con la recuperación adecuada de otros componentes no Citrix relacionados con la solución, se consideraría una solución de DR de alta disponibilidad en la que un servicio (Citrix) conmuta por error a un centro de datos contrario. Esa arquitectura particular se puede implementar como Active-Pasivo o Active-Activo en varias iteraciones de varios sitios, como Active-Pasivo para todos los usuarios, Active-Activo con usuarios que prefieren un centro de datos sobre otro, o Active-Activo, con los usuarios equilibrados de carga entre dos centros de datos sin preferencia. Es importante tener en cuenta que, al diseñar tales soluciones, se debe tener en cuenta la capacidad de reserva, contabilizarse y supervisar la carga de forma continua para garantizar que la capacidad permanezca disponible para acomodar la recuperación ante desastres, si es necesario.

También es esencial que los componentes de recuperación ante desastres se mantengan actualizados con la producción para mantener la integridad de la solución. Esta actividad suele ser ignorada por los clientes que diseñan e implementan una solución de este tipo con la mejor de las intenciones, luego comienzan a consumir más recursos de plataforma en producción y olvidan aumentar la capacidad disponible para conservar la integridad de DR de la solución.

En el contexto de Citrix, la extensión de dominios administrativos de Citrix (Citrix Site, PVS Farm, etc.) entre dos centros de datos, como dos instalaciones geolocalizadas como por ejemplo, no guía publicada constituiría DR ni para algunos componentes como Grupos de servidores StoreFront. Del mismo modo, debido a las limitaciones de latencia de la base de datos de PVS por guía publicada, tal implementación también sería probablemente insoportable. Las restricciones de compatibilidad entre geográficos también se extienden a veces al diseño de Citrix Site y Zone, debido a los máximos de latencia entre los controladores de satélite y las bases de datos per guía publicada.

Dado que muchos componentes de Citrix comparten dependencias, como bases de datos, ampliar los límites administrativos entre los dos centros de datos no protegería contra varios escenarios de falla clave. Si las bases de datos se dañan, el dominio de error afectaría a los servicios de aplicaciones en ambas instalaciones. Para considerar que una solución Citrix de alta disponibilidad es suficiente para DR, recomendamos que la segunda instalación no comparta dependencias clave ni límites administrativos. Por ejemplo, cree sitios, comunidades y grupos de servidores independientes para cada centro de datos de la solución. Al permitir que una plataforma de recuperación sea lo más independiente posible, redujimos los impactos de las fallas a nivel de componente que afectan tanto a los entornos de producción como de recuperación ante desastres. Esta consideración también va más allá de Citrix, y el uso de diferentes cuentas de servicio, servicios de archivos, DNS, NTP, administración de hipervisores, servicios de autenticación (AD, RADIUS, etc.) entre entornos de producción y de recuperación ante desastres también se recomienda para reducir los puntos únicos de falla.

Clasificaciones de niveles de recuperación ante desastres

Las clasificaciones de niveles para DR son un aspecto importante de una estrategia de DR de las organizaciones, ya que proporcionan claridad sobre la importancia de la aplicación o del servicio, lo que a su vez dicta el RTO (y, por lo tanto, los costes de lograr ese nivel de recuperación). Generalmente, cuanto más corto sea el RTO, mayor será el coste de la solución de DR. Ser capaz de desglosar varias interdependencias en diferentes clasificaciones (basadas en la criticidad del negocio y RTO) puede ayudar a optimizar los casos de DR sensibles a los costes.

A continuación se muestra un conjunto de clasificaciones de nivel de DR de ejemplo que sirven de referencia al evaluar los servicios de infraestructura Citrix, sus dependencias y aplicaciones críticas o casos de uso (y asociados a los VDA) alojados en Citrix. Los niveles de recuperación ante desastres se describen en orden o prioridad de recuperación, siendo 0 el más crítico. Se recomienda a las organizaciones que apliquen o desarrollen una clasificación por niveles de DR alineada con sus propios objetivos de recuperación y necesidades de clasificación.

Nivel 0 de recuperación ante desastres

Nivel 0: Objetivos de recuperación (ejemplos)

Objetivo de tiempo de recuperación: 0

Objetivo de punto de recuperación: 0

Nivel 0: Ejemplos de clasificación

Infraestructura de TI principal

  • Infraestructura de redes y seguridad
  • Enlaces de red
  • Hipervisores y dependencias (computación, almacenamiento)

Servicios de TI principales

  • Active Directory
  • DNS
  • DHCP
  • Servicios de archivos
  • Licencias RDS
  • Servicios críticos para usuarios finales (Citrix)

Nivel 0: Notas

Esta clasificación se aplica en gran medida a los componentes básicos de la infraestructura. Estos componentes siempre están disponibles en la ubicación de DR, ya que son dependencias para otros niveles y no en un segmento de red aislado. Deben ser aprovisionadas y mantenidas junto con sus equivalentes de producción. Si Citrix aloja aplicaciones críticas, es probable que se considere una plataforma de nivel 0. En tales escenarios, la infraestructura de Citrix se implementa “en caliente” en DR.

Nivel 1 de recuperación ante desastres

Nivel 1: Objetivos de recuperación (ejemplos)

Objetivo de tiempo de recuperación: 4 horas

Objetivo de punto de recuperación: 15 minutos

Nivel 1: Ejemplos de clasificación

Aplicaciones críticas

  • Sitios web y aplicaciones web
  • Aplicaciones ERP y CRM
  • Aplicaciones de línea de negocio

Casos de uso de Citrix

  • Administración
  • Servicio al Cliente o Ventas
  • Ingeniería y soporte de TI

Nivel 1: Notas

Las aplicaciones o escritorios virtuales de los que depende el negocio para llevar a cabo actividades empresariales principales normalmente se encuentran en este nivel. Es probable que también empleen una arquitectura de recuperación ante desastres de “espera en caliente” similar a la de Nivel 0 o se beneficiarán de una solución automatizada de conmutación por error y replicación. Si se lleva a cabo un aprovisionamiento en la nube, es necesario tener en cuenta consideraciones debatidas más adelante, ya que pueden afectar a los objetivos de RTO.

Nivel 2 de recuperación ante desastres

Nivel 2: Objetivos de recuperación (ejemplos)

Objetivo de tiempo de recuperación: 48 horas

Objetivo de punto de recuperación: 1 hora

Nivel 2: Ejemplos de clasificación

Aplicaciones no críticas Casos de uso no críticos de Citrix Datos de usuario que no afectan a la funcionalidad de las aplicaciones de nivel 1 o nivel 0.

Nivel 2: Notas

Aplicaciones o casos de uso que son clave para las operaciones del negocio, pero cuya indisponibilidad a corto plazo es poco probable que cause graves impactos financieros, de reputación u operativos. Estas aplicaciones se recuperan de copias de seguridad o se recuperan con la menor prioridad mediante herramientas de recuperación automatizadas.

Nivel 3 de recuperación ante desastres

Nivel 3: Objetivos de recuperación (ejemplos)

Objetivo de tiempo de recuperación: 5 días

Objetivo de punto de recuperación: 8 horas

Nivel 3: Ejemplos de clasificación

Aplicaciones usadas con poca frecuencia

Nivel 3: Notas

Las aplicaciones con un impacto insignificante de interrupción no están disponibles hasta una semana. Es probable que estas aplicaciones se recuperen a partir de copias de seguridad.

Nivel 4 de recuperación ante desastres

Nivel 4: Objetivos de recuperación (ejemplos)

Objetivo de tiempo de recuperación: 30 días

Objetivo de punto de recuperación: 24 horas o ninguno

Nivel 4: Ejemplos de clasificación

Entornos que no son de producción

Nivel 4: Notas

Aplicaciones, infraestructura y VDIs cuyas interrupciones también tienen un impacto insignificante en las operaciones del negocio y pueden restaurarse durante un tiempo prolongado. Pueden tener un RPO extendido también, o no en absoluto dependiendo de su naturaleza. Estos RPO se pueden recuperar de copias de seguridad o crear nuevos en DR y se consideran el último nivel que se recuperará.

¿Por qué es importante la clasificación de niveles para la planificación de Citrix DR?

La clasificación de niveles es importante para Citrix por las siguientes razones:

  • ¿Qué importancia tiene la infraestructura de Citrix para las operaciones empresariales? Es importante tener en cuenta que si Citrix se considera importante pero una aplicación que aloja se considera crítica, la infraestructura de Citrix se clasificaría como crítica.
  • Los casos de uso o las aplicaciones empresariales principales que aloja Citrix; ¿tienen clasificaciones de nivel de DR diferentes?

Para la primera pregunta, muchas implementaciones empresariales de Citrix tienden a clasificarse como Nivel 0 debido a la entrega de aplicaciones o escritorios críticos; la capa “siempre activa” como la infraestructura de red, Active Directory, DNS e hipervisor. Sin embargo, esta circunstancia puede no ser siempre el caso en cada caso de uso de Citrix. Tratar cada caso de uso de Citrix como Nivel 0 cuando algunos pueden entrar en el nivel 1 o superior puede afectar el coste general y la complejidad del proceso de recuperación ante desastres.

La segunda pregunta hace hincapié en la clasificación por caso de uso de Citrix y otorga su importancia más significativa en entornos de nube, que es debatidos más adelante con más detalle. En la nube, hay importantes consideraciones de coste entre acomodar plataformas de aplicaciones o de escritorio “siempre disponibles”, frente a aplicaciones o escritorios considerados menos críticos para el negocio. Estas consideraciones también pueden influir en el aislamiento de aplicaciones o casos de uso (silos) en producción para aprovechar la flexibilidad de implementación en una plataforma de recuperación ante desastres.

Al establecer un diseño de recuperación ante desastres para Citrix, llevar la discusión fuera del alcance de Citrix en sí es útil para establecer expectativas para las unidades de negocio. Por ejemplo, un entorno Citrix se considera un servicio “siempre activo” y está altamente disponible en un centro de datos alternativo; sin embargo, los back-ends críticos de las aplicaciones de los que dependen las aplicaciones alojadas de Citrix permanecerán indisponibles durante varias horas a medida que se invoca la recuperación. Esta brecha crea una disparidad en el tiempo de recuperación entre las dos plataformas y puede proporcionar una experiencia de usuario engañosa durante la recuperación. Citrix está disponible inmediatamente, pero las aplicaciones clave no funcionan. Establecer las expectativas desde el principio proporciona una visibilidad adecuada a todas las partes interesadas sobre el aspecto que puede tener la experiencia de recuperación. En algunas situaciones, un cliente puede querer mantener Citrix en modo de espera (siempre activo) en la instalación opuesta, pero controlar manualmente la conmutación por error del nivel de acceso, para evitar malentendidos sobre la disponibilidad de la plataforma.

Opciones de recuperación ante desastres

En esta sección, se describen las estrategias comunes de recuperación de Citrix, incluidas sus ventajas y desventajas, y consideraciones clave. Otras capacidades de recuperación o variaciones de los siguientes temas para Citrix son posibles, esta sección se centra en algunos de los más comunes. Además, esta sección ilustra cómo las respuestas a las preguntas principales indicadas en el principio influyen en el diseño de DR.

Si se correlacionan demasiado varias de las preguntas anteriores sobre la recuperación ante desastres, los siguientes temas de preguntas tienen implicaciones en el diseño de Citrix DR de la siguiente manera:

  • Estrategia de reserva y objetivo de tiempo de recuperación (RTO). Si la infraestructura o las aplicaciones de Citrix servidas desde Citrix se consideran esenciales para la misión, es probable que Citrix deba emplear un modelo “siempre activado” en el que la infraestructura de Citrix activa o en espera activa esté presente en dos o más centros de datos. Esta arquitectura daría como resultado la creación de varios planos de control independientes de Citrix en cada centro de datos (sitios Citrix independientes, comunidades de PVS, si corresponde, grupos de servidores StoreFront, etc.). Expansión de los planos de control de la infraestructura de Citrix no constituye una recuperación ante desastres (por ejemplo, abarcando un sitio a través de centros de datos o mediante zonas satelitales); hacerlo si el negocio está anticipando una plataforma de recuperación ante desastres para Citrix, que contradiga ese mandato.
  • Alcance de la recuperación. Si Citrix se implementa en una capacidad de espera en caliente (siempre activa) en DR, pero los back-end principales de las aplicaciones empresariales tardan, por ejemplo, 8 horas en recuperarse, no tiene sentido emplear una conmutación por error de nivel de acceso automatizado. La conmutación por error manual del nivel de acceso puede ser más apropiada.
  • Casos de uso. Si solo se deben recuperar rápidamente cargas de trabajo críticas o aplicaciones principales en Citrix para mantener las operaciones del negocio en un caso de recuperación ante desastres, es probable que este caso pueda reducir los costes de DR desde una perspectiva de capacidad. Si es necesario recuperar varios casos de uso con prioridades diferentes, la clasificación de importancia por caso de uso contrastada con el impacto empresarial según la estrategia de organización en niveles de recuperación discutido anteriormente no puede reducir los costes de capacidad, sino que proporcionará al personal de TI un conjunto más centrado de órdenes de prioridad de recuperación.
  • Prestaciones. Si ciertos componentes, como HDX Insight, Grabaciones de sesiones, no se consideran críticos para el funcionamiento de la plataforma de DR, su omisión en el entorno de DR elimina cierta complejidad y sobrecarga de mantenimiento. Del mismo modo, si muchos casos de uso en un caso de recuperación ante desastres pueden subsistir con una opción de entrega Citrix más simple y genérica en DR, esto también puede reducir la complejidad y los costes. Por ejemplo, usar un escritorio compartido hospedado en lugar de VDI agrupado si es técnicamente factible, o agregar más casos de uso en uno, siempre que no sean perjudiciales para las operaciones empresariales. Recuperación ante desastres
  • DR existente. Si la estrategia de recuperación ante desastres existente de la organización, por ejemplo, recupera Citrix y otra infraestructura de aplicaciones mediante herramientas de replicación y orquestación de datos, la mayoría de los componentes de Citrix pueden ser adecuados para este modelo. Si el tamaño de la plataforma y la dependencia de la tecnología de administración de imagen única es un requisito de plataforma de producción, a menudo dichas tecnologías no pueden ser adecuadas; un enfoque híbrido de una plataforma Citrix en espera en caliente y tal vez la replicación de imágenes maestras puede ser más apropiado.
  • Criticidad de los datos. Si los perfiles se consideran críticos para la recuperación ante desastres, puede ser necesaria la tecnología de replicación adecuada. Muchas organizaciones están menos preocupadas por los perfiles en casos de recuperación ante desastres y aceptan que se creen nuevos. Esta consideración también se aplicará a los datos de usuario a los que se accede en Citrix (redirección de carpetas, unidades asignadas); RPO y RTO para estos datos pueden ser una decisión empresarial. Además, si se considera que muchos VDIs persistentes son lo suficientemente importantes como para conservar intactos en DR (en lugar de requerir a los usuarios que reinstalen su software, etc.), estas máquinas virtuales deben considerarse para la replicación, lo que puede incurrir en costes adicionales para soportar la recuperación.
  • Tipos de desastres. La medida en que un cliente quiere protegerse contra fallas puede dictar varios cambios arquitectónicos. Si el cliente solo quiere alta disponibilidad de la infraestructura Citrix dentro del centro de datos o la región de la nube, este tipo de desastre solo puede requerir garantizar que los componentes de administración sean redundantes y funcionen en infraestructuras opuestas. Por ejemplo, un tipo de par de servidores StoreFront utiliza reglas antiafinidad de VMware para operar en diferentes hosts de un clúster, o en diferentes clústeres completamente dentro del centro de datos, o tal vez como parte de diferentes conjuntos de disponibilidad. Esta situación rara vez requiere crear planos de control redundantes por completo (por ejemplo, varios sitios de Citrix y grupos de servidores StoreFront). Sin embargo, si la recuperación ante desastres está pensada para abarcar varios centros de datos independientemente de la región, entonces los planos de control redundantes que utilicen dependencias locales en cada centro de datos (AD, DNS, SQL, hipervisor, etc.) es más apropiado. Si el cliente es global y emplea varios centros de datos para dar servicio a Citrix (o planea hacerlo) con los back-ends de aplicaciones correspondientes locales a estos centros de datos, es más probable que una arquitectura de HA-DR activo-localizada sea más adecuada. Esta arquitectura proporciona a los usuarios la experiencia de usuario óptima cuando sea posible, mediante el uso de infraestructuras geolocalizadas de Citrix que, de ser necesario, pueden ser conmutadas por error a un centro de datos de backup en un orden de preferencia secundario.
  • Usuarios cliente. Más allá de la relación anterior sobre las consideraciones de usuario, aplicación y localización de datos, algunas redes de usuarios cliente pueden estar relativamente bloqueadas con dispositivos de seguridad (proxy, firewall, etc.) que pueden restringir la comunicación saliente a Internet o incluso a la WAN. Es importante considerar si este estado se aplica a las redes cliente y asegurarse de que las nuevas IP para los servicios Citrix (como la IP virtual de StoreFront y las IP de VDA, o la IP de Citrix Gateway) se tengan en cuenta en sus configuraciones de seguridad locales para garantizar que no se produzcan más retrasos en la recuperación debido a la seguridad de LAN local restricciones al invocar DR. Desde una perspectiva de preparación, en caso de recuperación ante desastres, ¿el acceso del cliente cambiará de alguna manera? En algunos escenarios de recuperación ante desastres para un cliente puede suponer que la WAN no está disponible y que todos los usuarios deben acceder a los recursos de Citrix a través de Internet. Tales pasos requerirían documentación en el BC y planes de preparación, con requisitos previos establecidos para los usuarios finales (en relación con los detalles del cliente Citrix admitido, supuestos sobre el acceso a dispositivos corporativos o BYOD) para eliminar las barreras para que los usuarios regresen al servicio, reduciendo aún más la carga sobre el servicio de soporte técnico.
  • Ancho de banda de red. La cantidad de ancho de banda de red utilizado con respecto al tráfico VDA (ICA, aplicaciones, servicios de archivos) se debe tener en cuenta en el tamaño de la red de instalaciones de DR y los firewalls. Esta consideración es especialmente importante en entornos de nube donde existen límites en las puertas de enlace VPN y la capacidad de firewall virtual. La supervisión del tráfico de producción de los agentes VDA para determinar un valor promedio para el dimensionamiento es importante para dimensionar eficazmente las redes. Cuando existan restricciones de red, las organizaciones deben utilizar diferentes configuraciones de red para acomodar la carga de tráfico de DR prevista si se invocan y cuando se invocan. La tecnología de optimización de WAN de Citrix SD-WAN puede ayudar a reducir las demandas de tráfico.
  • Fallback (o failback). Si los datos de usuario que han cambiado en DR, o si las imágenes de VDA mientras se encuentran en DR, la organización debe planificar la conmutación por recuperación para propagar estos cambios de nuevo a producción, si el entorno de producción resulta recuperable. Para los datos de usuario, puede ser tan sencillo como revertir el orden de replicación y recuperar; de manera similar, para la infraestructura de Citrix si no se utilizan tecnologías de administración de imágenes únicas. Si utiliza MCS o PVS, las imágenes maestras o los discos virtuales se pueden replicar manualmente en producción y los VDA actualizarse en consecuencia.

En la lista siguiente se describen varias opciones de recuperación comunes para Citrix. Las adaptaciones de cada uno existen en el campo, sin embargo, por el bien de la comparación, estamos esbozando versiones básicas de cada uno. Las opciones se organizan a partir de la más simple (a menudo mayor RTO y menor coste) a través de la más avanzada (a menudo menor RTO pero mayor coste). La opción ideal para una organización determinada es alinearse con el tiempo de recuperación para aplicaciones alojadas o casos de uso, además de las habilidades de TI, el presupuesto y la infraestructura disponibles. Además, aunque es posible lograr, muchas opciones indican que las tecnologías Citrix integradas con redes y almacenamiento, como ADC y tecnologías de administración de imagen única, no son adecuadas para métodos distintos de los modelos de recuperación “siempre activos”. No es que sea técnicamente imposible de lograr, pero el nivel de complejidad que implica alcanzarlos puede hacer que la recuperación sea más arriesgada y más propensa al error humano.

Opción de recuperación: recuperación de copias de seguridad sin conexión

Recuperación ante desastres

Pros y contras

Pros:

  • Menor coste de mantenimiento en comparación con las soluciones de replicación o en espera en caliente

Contras:

  • Alto impacto en el tiempo de inactividad
  • Documentación más grande y detallada del plan de recuperación (orquestación de DR)
  • Tiempo de recuperación ampliado
  • Se basa en la integridad y la antigüedad de los backups
  • Mayor grado de error humano si es necesaria la reconfiguración manual (redes, etc.)
  • No apto para MCS o PVS
  • No es adecuado para Citrix VPX ADC debido a la red (y se debe reconstruir aplicando copias de seguridad de nsconfig directorio y ns.conf archivos)

Caso de uso y suposiciones

Útil para organizaciones de TI menos maduras y organizaciones con presupuestos limitados de operaciones de TI y puede permitir interrupciones prolongadas para recuperar los servicios principales del negocio. Supone que las copias de seguridad se prueban regularmente para la integridad de la restauración y se siguen procesos de recuperación claramente documentados.

Opción de Recuperación: Recuperación mediante Replicación

Recuperación ante desastres

Pros y contras

Pros:

  • Es probable que la replicación sea automatizada y se alinea con RTO y RPO
  • Probablemente utiliza tecnologías menos complejas en comparación con soluciones de recuperación automatizadas

Contras:

  • Se basa en la intervención administrativa
  • Documentación más grande y detallada del plan de recuperación (orquestación de DR)
  • Mayor grado de error humano si es necesaria la reconfiguración manual (redes, etc.)
  • No apto para MCS o PVS. La recreación de catálogos de máquinas se tiene en cuenta en el RTO proyectado. Sin embargo, al crear catálogos de máquinas ficticios en DR o escalar las instancias de VDA en DR y realizar una acción “Actualizar catálogo” aplicando una imagen maestra replicada, este RTO se puede acortar
  • No apto para Citrix VPX ADC debido a la red y, por lo tanto, es más adecuado para emplear ADC en espera en caliente

Caso de uso y suposiciones

Útil para organizaciones de TI menos maduras y organizaciones con presupuestos limitados de operaciones de TI. Esta solución se basa en tecnologías de replicación de almacenamiento de información del proveedor de SAN o del proveedor de hipervisores (vSphere Replication, etc.) para replicar máquinas virtuales en otra instalación a través de la WAN.

Opción de Recuperación: Replicación con Recuperación Automatizada

Recuperación ante desastres

Pros y contras

Pros:

  • Menor coste de mantenimiento en comparación con las soluciones de espera en marcha
  • Es probable que la replicación sea automatizada y se alinea con RTO y RPO
  • Los planes de recuperación tienden a ser automatizados
  • Menos intervención administrativa y error humano

Contras:

  • Se basa en tecnologías más avanzadas, como VMware SRM, Veeam, Zerto, ASR, para organizar la recuperación y modificar los parámetros de red
  • No apto para MCS o PVS. La recreación de catálogos de máquinas se debe tener en cuenta en el RTO proyectado. Sin embargo, al crear catálogos de máquinas ficticios en DR o escalar las instancias de VDA en DR y realizar una acción “Actualizar catálogo” aplicando una imagen maestra replicada, este RTO se puede acortar
  • No apto para Citrix VPX ADC debido a la red y, por lo tanto, es más adecuado para emplear ADC en espera en caliente

Caso de uso y suposiciones

Útil para organizaciones empresariales con recursos adecuados y presupuesto para instalaciones de recuperación ante desastres. Esta solución se basa en la misma replicación de almacenamiento de información que la opción anterior, pero incluye tecnologías de orquestación de DR para recuperar máquinas virtuales en orden particular, ajustar configuraciones de NIC (si es necesario), etc.

Opción de recuperación: espera activa (activo-pasiva) con conmutación por error manual

Recuperación ante desastres

Pros y contras

Pros:

  • Tiempo de recuperación corto ya que la plataforma está “siempre encendida”
  • Admite componentes de almacenamiento y dependientes de la red, como VPX, MCS, PVS
  • Documentación del plan de recuperación inferior (orquestación de DR)

Contras:

  • Se basa en la intervención administrativa para conmutar la URL o dirigir a los usuarios a la URL de copia de seguridad
  • Mayor coste debido a tener hardware “activo” en recuperación ante desastres sentado en modo de espera
  • Mayor sobrecarga administrativa para mantener las configuraciones y actualizaciones de la plataforma en espera sincronizadas con la producción

Caso de uso y suposiciones

Útil para organizaciones empresariales con recursos adecuados y presupuesto para instalaciones de recuperación ante desastres. Puede utilizar una plataforma de espera en caliente “totalmente escalada” o una plataforma de “escala a demanda”. Este último puede ser atractivo para la recuperación en la nube para reducir los costes operativos, con advertencias.

En el momento de la conmutación por error, los administradores actualizan la entrada **DNS** de una o varias direcciones URL de acceso para apuntar a una o más direcciones IP de DR para Citrix Gateway y StoreFront, o bien, mediante comunicación formal, se aconseja a los usuarios que comiencen a utilizar una dirección URL de “copia de seguridad” o “DR”.

Esta opción manual puede ser útil para escenarios en los que los back-end de aplicaciones pueden requerir más tiempo de recuperación, pero agregaría confusión a los usuarios si Citrix estuviera completamente disponible y las aplicaciones no lo estuvieran.

Este modelo supone una organización de TI madura y hay suficiente infraestructura WAN y computación disponibles para admitir la conmutación por error.

Opción de recuperación: espera activa (activo-pasiva) con conmutación por error automatizada

Recuperación ante desastres

Pros y contras

Pros:

  • Tiempo de recuperación corto ya que la plataforma está “siempre encendida”
  • Admite componentes de almacenamiento y dependientes de la red, como VPX, MCS, PVS
  • Documentación del plan de recuperación mínimo (orquestación de DR)
  • Más fácil para los usuarios finales como la conmutación por error de URL
  • Admite análisis EPA en Citrix Gateway

Contras:

  • Mayor coste debido a tener hardware “activo” en recuperación ante desastres en espera y licencias de Citrix ADC
  • Mayor complejidad del nivel de acceso
  • Mayor sobrecarga administrativa para mantener las configuraciones y actualizaciones de la plataforma en espera sincronizadas con la producción

Caso de uso y suposiciones

Una configuración común con los clientes empresariales y permite la conmutación por error automatizada al sitio de recuperación ante desastres mediante Citrix ADC GSLB (ADC Advanced o superior necesario). Este modelo supone una organización de TI madura y suficiente infraestructura WAN y computación para admitir la conmutación por error. Este modelo también asume que las dependencias de datos de usuarios y aplicaciones están en consonancia con las versiones y actualizaciones más recientes del sitio activo y se pueden recuperar en la instalación de recuperación ante desastres de manera similar automatizada para reducir el impacto prolongado del servicio para el usuario final y la confusión debido a la funcionalidad parcial de la solución.

Opción de recuperación: activa-activa con conmutación por error automatizada

Recuperación ante desastres

Pros y contras

Pros:

  • Tiempo de recuperación corto ya que la plataforma está “siempre encendida”
  • Admite componentes de almacenamiento y dependientes de la red, como VPX, MCS, PVS
  • Documentación del plan de recuperación mínimo (orquestación de DR)
  • Sin problemas para los usuarios finales

Contras:

  • Mayor coste debido a tener hardware “activo” en recuperación ante desastres en espera y licencias de Citrix ADC
  • La mayor complejidad del nivel de acceso
  • Mayor sobrecarga administrativa para mantener las configuraciones y actualizaciones de la plataforma en espera sincronizadas con la producción
  • Actualmente, GSLB activo/activo no admite exploraciones EPA en Citrix Gateway, se sugiere la configuración GSLB de GSLB para la URL de Citrix Gateway
  • Confía en los administradores para supervisar y ajustar la capacidad de recursos y hardware en todos los centros de datos para garantizar que a medida que crece la plataforma, la integridad de la capacidad de recuperación ante desastres no se vea afectada

Caso de uso y suposiciones

Una configuración más avanzada pero común con clientes empresariales y permite que las direcciones URL de nivel de acceso funcionen de manera activa-activa a través de Citrix ADC GSLB (ADC Advanced o superior necesario). Esta funcionalidad es útil en entornos con proximidad a centros de datos locales o en situaciones en las que los centros de datos pueden ser remotos pero con los medios para anclar a los usuarios a centros de datos preferidos (a menudo impulsados por configuraciones avanzadas de StoreFront y GSLB en menor medida) para escenarios de varios sitios.

Este modelo supone una organización de TI madura y suficiente infraestructura WAN y computación para admitir la conmutación por error. Este modelo también asume que las dependencias de datos de usuarios y aplicaciones están en consonancia con las versiones y actualizaciones más recientes del sitio y se pueden recuperar en la instalación de DR de una manera similar automatizada para reducir el impacto prolongado del servicio para el usuario final y la confusión debido a la funcionalidad parcial de la solución.

Recuperación ante desastres en la nube pública

La recuperación ante desastres que implica plataformas en la nube o nube a nube viene con su propio conjunto de desafíos o consideraciones que a menudo no se presentan en casos de recuperación local.

Las siguientes consideraciones clave se pueden abordar durante la planificación del diseño de DR para evitar errores que pueden hacer que el plan de recuperación ante desastres aplicando la infraestructura en la nube sea inválido, prohibitivo de costes o incapaz de cumplir la capacidad objetivo en caso de DR.

Consideración: rendimiento de la red

Áreas de impacto

Disponibilidad Rendimiento Coste

Detalles

Los clientes pueden subestimar y, por lo tanto, subdimensionar los puntos de coyuntura de rendimiento en su solución en la nube, incluido el firewall virtual, la puerta de enlace VPN y el enlace ascendente WAN (AWS Direct Connect, Azure Express Route, GCP Cloud Interconnect, etc.) si la plataforma Citrix quiere recuperarse en la nube y ser accesible a través de la WAN. Las puertas de enlace VPN de Azure y las puertas de enlace de AWS Transit tienen actualmente límites máximos de 1,25 Gbps. Este límite puede requerir escalar las puertas de enlace horizontales o quizás utilizar varias VPC (si hay AWS) si son esenciales para la arquitectura de la nube. Muchos firewalls virtuales tienen límites de licencia sobre el rendimiento que pueden procesar o máximos incluso en su límite máximo. Esta restricción puede requerir escalar el número de firewall y balancearlos de alguna manera.

Recomendaciones

Al establecer cálculos de tamaño de rendimiento, asuma la carga completa de la capacidad de recuperación ante desastres. Capture los siguientes datos por usuario simultáneo:

  • Ancho de banda estimado de sesión ICA
  • Ancho de banda estimado de comunicación de aplicaciones por sesión si atraviesan límites de seguridad
  • Ancho de banda estimado para servicios de archivos por sesión si atraviesan límites de seguridad

Para las métricas anteriores, puede ser útil recopilar datos sobre los patrones de tráfico actuales hacia y desde agentes VDA en producción. También es importante considerar qué otros flujos de datos no relacionados con Citrix también se prevé que utilicen estas rutas de red. Asegúrese de involucrar a los equipos de seguridad y red en la planificación de Citrix DR para asegurarse de que todas las estimaciones de ancho de banda que atraviesan zonas de seguridad y segmentos de red se entienden y se pueden acomodar. Cuando el ancho de banda es de primera calidad, Citrix SD-WAN WAN Optimization puede ayudar a reducir el espacio de la sesión en el cable o a agregar ancho de banda a través de varias conexiones de red.

Consideración: Licencias de SO de escritorio Windows

Áreas de impacto

Coste

Detalles

Existen consideraciones de licencia potencialmente complejas para las instancias de SO de escritorio de Microsoft que se ejecutan en diferentes plataformas de nube. Microsoft revisó sus derechos de licencia en la nube en agosto de 2019, lo que puede afectar a las implicaciones de costes de VDI en algunos escenarios de implementación.

Recomendaciones

Consulte las instrucciones más recientes de Microsoft para determinar la arquitectura de casos de uso. Si existe un potencial desafío de costes para VDI en la solución de DR, considere la posibilidad de complementar con escritorios compartidos alojados (se puede requerir un aumento de CAL de RDS), si es factible, ya que pueden proporcionar mayor flexibilidad a un menor coste de operación.

Consideración: sincronización de la escala de salida de VDA (antes o durante la recuperación ante desastres)

Áreas de impacto

Disponibilidad Coste

Detalles

Los clientes se sienten atraídos a la nube por el atractivo de pagar por la capacidad solo cuando es necesaria. Esta solución puede reducir drásticamente los costes de DR al no pagar por la infraestructura reservada, ya sea que se utilice o no.

Sin embargo, a grandes escalas, un proveedor de nube no puede comprometerse a un acuerdo de nivel de servicio de encendido de cientos o miles de máquinas virtuales a la vez. Esta solución se vuelve particularmente difícil si se prevé que la huella de VDA para DR se ejecutará en cientos o miles de instancias. Los proveedores de nube tienden a mantener la capacidad masiva para varios tamaños de instancias disponibles; sin embargo, este proveedor puede variar de momento a momento. Si se produce un desastre que afecta a una zona geográfica, puede haber disputas de otros arrendatarios que también soliciten capacidad a demanda.

Preguntas clave que deben ser respondidas que pueden influir en las decisiones:

  • ¿Se requiere siempre una capacidad de recuperación ante desastres 100%?
  • ¿Debemos alojar solo cargas de trabajo críticas (es decir, subconjunto de producción)?
  • ¿Es viable escalar hacia fuera en el momento de la recuperación ante desastres? En caso afirmativo, ¿los niveles de DR han dado prioridad a los casos de uso para comprender mejor los diferentes RTO de cada caso de uso a fin de admitir una escala gradual de la capacidad?
  • ¿Podemos ampliar las instancias del sistema operativo compatibles con casos de uso de aplicaciones o escritorios compartidos alojados para ahorrar tiempo de Provisioning y apagar estas instancias para ahorrar costes operativos?

Recomendaciones

Citrix recomienda en primer lugar interactuar con su proveedor de nube para determinar la viabilidad de encender la capacidad prevista dentro del plazo de tiempo de RTO y si se puede cumplir con instancias a demanda o no. Para protegerse contra las limitaciones de disponibilidad de capacidad de los agentes VDA en un caso de recuperación ante desastres, Citrix recomienda Provisioning agentes VDA en tantas zonas de disponibilidad como sea posible. A grandes escalas, puede valerse la pena aprovisionar en varias regiones de la nube y ajustar la arquitectura en consecuencia. Algunos proveedores de nube han sugerido emplear diferentes tamaños de tipos de instancias de VM para mitigar aún más el agotamiento de VM. Siempre que sea posible, sería prudente aprovisionar previamente las instancias de VDA y mantenerlas fuera de línea y actualizarlas periódicamente. El Provisioning es un proceso que requiere mucho tiempo y recursos, y el escalamiento horizontal de la capacidad de DR de VDA a demanda puede acelerarse hasta cierto punto mediante el aprovisionamiento previo. Si la organización tiene poco apetito por el riesgo de disponibilidad de capacidad, puede requerir la aplicación de la capacidad informática reservada o dedicada y la presupuestación en consecuencia para garantizar la disponibilidad de los recursos. Es posible combinar modelos a demanda y reservados\ dedicados haciendo referencia al nivel de recuperación ante desastres en el que ciertos casos de uso pueden requerir que los VDA estén inmediatamente disponibles, mientras que otros pueden tener la flexibilidad de recuperarse a lo largo de un RTO más largo de varios días o semanas si son menos críticos para mantener el negocios.

Consideración — Datos de aplicación y usuario

Áreas de impacto

Coste Disponibilidad Rendimiento

Detalles

La ubicación de los datos de usuario y los back-end de aplicaciones puede tener un impacto notable en el rendimiento y, a veces, en la disponibilidad del entorno Citrix DR. Algunos escenarios de clientes utilizan un enfoque de recuperación ante desastres de múltiples centros de datos en el que no todos los back-end de aplicaciones o los datos de usuario, como las unidades domésticas y departamentales, no se pueden recuperar en la nube junto con Citrix. Esta brecha puede dar lugar a una latencia imprevista que puede afectar el rendimiento o incluso la funcionalidad de las aplicaciones. Desde una perspectiva de rendimiento, esta brecha puede aumentar la tensión al ancho de banda disponible del dispositivo de seguridad y la red.

Recomendaciones

Siempre que sea posible, mantenga los datos de aplicaciones y usuarios locales en la plataforma Citrix en DR para mantener el mejor rendimiento posible al reducir las demandas de latencia y ancho de banda en toda la WAN.

Planificación de la recuperación ante desastres para Citrix Cloud

Existen varias diferencias notables entre la implementación local o “tradicional” de Citrix Virtual Apps and Desktops (CVAD), frente al servicio Citrix Virtual Apps and Desktops Service (CVADS) proporcionado por Citrix Cloud con respecto a la planificación de la recuperación ante desastres:

  • Citrix administra la mayoría de los componentes de control para el socio o cliente, eliminando de su responsabilidad los requisitos de recuperación ante desastres significativos para el sitio de Citrix y sus componentes.
  • La implementación de un entorno de recuperación ante desastres para los recursos de Citrix simplemente requiere que un cliente implemente Citrix Cloud Connectors en la “Ubicación de recursos” de recuperación y, opcionalmente, los ADC StoreFront y Citrix para Citrix Gateway.
  • La arquitectura de servicio exclusiva de Citrix Cloud es geográficamente redundante y resistente por diseño.
  • No se requiere la recuperación ante desastres de nivel de acceso si se utilizan los servicios Citrix Workspace y Citrix Gateway.

Más allá de estas diferencias principales, muchas de las consideraciones de recuperación ante desastres de secciones anteriores todavía requieren planificación de socios y clientes, ya que conservan la responsabilidad de los VDA de Citrix, los datos de usuario, los back-end de aplicaciones y el nivel de acceso de Citrix si Citrix Gateway Service y Citrix Workspace Service no se utilizan desde Citrix Cloud.

Esta sección cubre temas clave para ayudar a los clientes a definir una estrategia de recuperación ante desastres adecuada para Citrix Cloud.

CVADS simplifica la recuperación ante desastres

A continuación se muestra un diagrama conceptual típico que describe la arquitectura conceptual de CVADS, además de la separación de la responsabilidad de los componentes gestionados por Citrix y los componentes administrados por socios o clientes. No se ilustran aquí los “Servicios” de WEM, Analytics y Citrix Gateway, que son componentes electivos de Citrix Cloud relacionados con CVADS, que se clasificarían en “Administrado por Citrix”.

Recuperación ante desastres

Como se ilustra en el diagrama, una parte importante de los componentes de Control que requieren decisiones de recuperación entran dentro del ámbito de administración de Citrix. Al ser un servicio basado en la nube, la arquitectura CVADS es altamente resistente dentro de Región de Citrix Cloud. Forma parte de la “Salsa Secreta” de Citrix Cloud y se considera dentro SLAs de Citrix Cloud.

Las responsabilidades de administración de disponibilidad de servicios son las siguientes:

  • Citrix. Plane de control y acceda a “servicios” si está en uso (Workspace, Citrix Gateway Service).
  • Cliente. Componentes de ubicación de recursos, incluidos Cloud Connectors, agentes VDA, back-end de aplicaciones, dependencias de infraestructura (AD, DNS, etc.) y nivel de acceso (StoreFront, Citrix ADC) si no se utiliza el nivel de acceso de Citrix Cloud.

Los clientes obtienen las siguientes ventajas con respecto a la recuperación ante desastres en CVADS:

  • Menor carga administrativa debido a menos componentes que administrar y menos configuraciones independientes para replicar y mantener entre ubicaciones.
  • Reducción de las posibilidades de error humano y discrepancias de configuración entre las implementaciones de Citrix debido a la configuración centralizada del “sitio Citrix” en la nube.
  • Operaciones optimizadas gracias a la simplificación de la administración de recursos para implementaciones de producción y recuperación ante desastres debido a que hay menos componentes y sitios Citrix que deben configurarse y mantenerse, no hay nivel de acceso para administrar entre ubicaciones (opcional) y lógica de recuperación ante desastres menos compleja para los recursos de Citrix.
  • Reducción de los costes operativos con menos componentes de servidor para implementar y mantener, y obtener una vista única de las tendencias del entorno en todas las implementaciones mediante la centralización de la base de datos de supervisión.

Consideraciones sobre recuperación ante desastres de CVADS

Aunque muchos componentes para la planificación de la recuperación se eliminan del ámbito de administración del cliente, los clientes siguen siendo responsables de la planificación y administración de DR y alta disponibilidad (opcional) para los componentes ubicados en la ubicación de recursos.

La diferencia más significativa en cómo abordamos la disponibilidad se reduce a cómo interpretamos y configuramos ubicaciones de recursos. Dentro de CVADS mismo, las ubicaciones de recursos se presentan como Zonas. Con Preferencia de zona podemos administrar la conmutación por error entre ubicaciones de recursos en función de la lógica que especificamos. El uso de la preferencia de zona dentro de un sitio CVAD implementado tradicionalmente se consideraría un diseño de alta disponibilidad, pero no un diseño de DR válido. En el contexto de Citrix Cloud, esta opción es una solución de recuperación ante desastres válida.

La mayoría de las Opciones de recuperación ante desastres discutidas anteriormente se aplican a CVADS, por lo que existen numerosas opciones para ajustarse a los objetivos y presupuestos de recuperación de la organización.

Al planificar la recuperación ante desastres para el servicio CVADS de Citrix Cloud, es necesario comprender varios principios rectores clave desde la perspectiva de la planificación de la infraestructura:

  • Ubicaciones de recursos. Las ubicaciones de producción y recuperación ante desastres se configuran como ubicaciones de recursos independientes en Citrix Cloud.
  • Conectores en la nube. Cada ubicación de recursos debe tener un mínimo de dos Cloud Connectors implementados. Para mayor claridad, Cloud Connectors no es un componente que debe “recuperarse” manual o automáticamente durante un evento de DR. Deben considerarse componentes de “espera en caliente” y mantenerse en línea dentro de cada ubicación.
  • Controladores de acceso administrados por el cliente (opcional). Los clientes pueden optar por implementar sus propios ADC de Citrix para servidores Citrix Gateway y StoreFront y no consumir Citrix Workspace o Citrix Gateway Service por varias razones. Estos pueden incluir:
    • Flujos de autenticación personalizados
    • Aumento de las capacidades de marca
    • Mayor flexibilidad de redirección de tráfico HDX
    • Auditoría de conexiones ICA e integración en plataformas SIEM
    • Capacidad para continuar funcionando si la conexión del Cloud Connector a Citrix Cloud está cortada, mediante la función de caché de host local de Cloud Connectors con StoreFront

    Al igual que con Cloud Connectors, se recomienda mantener los componentes de StoreFront y Citrix Gateway implementados como “en espera activa” en la ubicación de recuperación y no recuperarlos durante un evento de recuperación ante desastres.

Consideraciones sobre la operación

Mantener la plataforma DR es esencial para mantener su integridad a fin de evitar problemas imprevistos cuando se requiere la plataforma. Se recomiendan las siguientes pautas con respecto al funcionamiento y mantenimiento del entorno Citrix de DR:

  • Citrix DR Platform no es Prod. Los clientes con un entorno de “espera en caliente” pueden sentirse tentados a cortar esquinas y tratar la recuperación ante desastres como una plataforma de prueba. Este tratamiento afecta negativamente a la integridad de la solución. De hecho, es probable que la recuperación ante desastres sea la última plataforma en la que promover cambios, para garantizar que su utilidad no se vea afectada en caso de que el mantenimiento fuera catastróficamente erróneo de una manera que no se exhibe en entornos que no son de producción.
  • Parches y mantenimiento. El mantenimiento rutinario en el paso de bloqueo con la producción cuando se utilizan plataformas Citrix “en espera en caliente” es esencial para mantener una plataforma de recuperación ante desastres funcional. Es importante mantener la recuperación ante desastres sincronizada con la producción con respecto al sistema operativo, el producto Citrix y los parches de aplicaciones. Para mitigar el riesgo, se sugiere permitir entre varios días y una semana entre la producción de parches y la recuperación ante desastres.
  • Pruebas periódicas. Independientemente de si la recuperación ante desastres implica la replicación de la producción en una instalación de recuperación o el uso de entornos de “espera en caliente”, es importante probar periódicamente (dos veces al año o más es ideal) el plan de DR para garantizar que los equipos estén familiarizados con los procesos de recuperación y cualquier defecto en la plataforma o los flujos de trabajo identificados y remediados.
  • Gestión de la capacidad. True para entornos Citrix activo-pasivo y Active-activo “siempre activado”, también se deben tener en cuenta los cambios de capacidad o casos de uso en producción para la recuperación ante desastres. Especialmente cuando se utilizan modelos activo-activo, es fácil que la utilización de recursos aumente más allá de digamos, un umbral de utilización de recursos en estado estacionario del 50% en cada entorno, solo para que ocurra un evento de recuperación ante desastres y la plataforma sobreviviente se vea abrumada y tenga un rendimiento deficiente o falla debido a la sobrecarga. La capacidad se puede revisar mensualmente o trimestralmente.

Resumen

Hemos cubierto un poco de terreno sobre el tema de la recuperación ante desastres en Citrix. En los siguientes puntos se resumen los mensajes principales y las conclusiones de esta guía que los arquitectos y los clientes deben tener en cuenta al planificar su estrategia de recuperación de Citrix:

  • La comprensión de los requisitos empresariales y las capacidades tecnológicas de un entorno de cliente influye en la estrategia de recuperación ante desastres requerida para Citrix. La estrategia de recuperación elegida puede alinearse con los objetivos del negocio.
  • La alta disponibilidad no es sinónimo de recuperación ante desastres. Sin embargo, la recuperación ante desastres puede incluir alta disponibilidad.
  • Compartir límites administrativos entre ubicaciones físicas no constituye una solución de recuperación ante desastres.
  • El desarrollo de una clasificación de organización en niveles de recuperación ante desastres para la cartera de tecnología de una organización proporciona visibilidad, flexibilidad y posibles ahorros de costes al desarrollar una estrategia de recuperación.
  • Los requisitos de RTO para la infraestructura de Citrix o las aplicaciones alojadas en Citrix son el factor más importante que influye en el diseño de la recuperación ante desastres. Un RTO más corto a menudo requiere un coste de soluciones más alto.
  • Las arquitecturas de recuperación ante desastres para Citrix que no utilizan una plataforma de recuperación ante desastres “activa” presentan limitaciones en las tecnologías que un cliente puede utilizar, como Citrix MCS, ADC y Provisioning.
  • La estrategia de recuperación ante desastres para Citrix también debe tener en cuenta el tiempo de recuperación y recuperación de los datos de usuario y back-end de aplicaciones. Citrix puede diseñarse para recuperarse rápidamente, sin embargo, los usuarios no pueden trabajar si las dependencias de aplicaciones y datos no están disponibles en un período de tiempo similar.
  • La recuperación ante desastres en entornos de nube posee sus propias consideraciones que no están presentes en entornos locales que las organizaciones deben revisar para evitar cuellos de botella imprevistos o impactos operativos al invocar la recuperación ante desastres en entornos de nube.
  • Es imprescindible que los componentes de recuperación ante desastres se mantengan actualizados para que se adapten a las actualizaciones y configuraciones de producción a fin de mantener la integridad de la plataforma.
  • Las plataformas que utilizan una configuración activo-activa para Citrix entre ubicaciones deben tener en cuenta la supervisión de la capacidad para garantizar que, en caso de desastre, haya suficientes recursos disponibles para soportar la carga proyectada en una o más ubicaciones supervivientes.
  • Los clientes deben probar periódicamente su plan de recuperación ante desastres para Citrix para validar su funcionamiento y su capacidad para cumplir su propósito principal.
  • Citrix Virtual Apps and Desktops Service simplifica significativamente muchos aspectos de la arquitectura de DR y permite la redundancia de ubicación de recursos mediante la configuración de preferencias de zona.

Fuentes

El objetivo de este artículo es ayudarle a planificar su propia implementación. Para facilitar esta tarea, nos gustaría proporcionarle diagramas de origen que puede adaptar a sus propias necesidades: diagramas de origen.

Citrix Virtual Apps and Desktops: Planificación de recuperación ante desastres

En este artículo