Decisión de diseño: planificación de recuperación ante desastres

Introducción

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 ámbito 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, adopta una perspectiva de términos más simples sobre 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 ámbito 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.

Los siguientes son algunos ejemplos de preguntas útiles para discutir. Estas preguntas se analizan con más detalle en la sección Opciones de recuperación ante desastres en términos de cómo afectan al diseño de DR de Citrix:

• Estrategia de reserva y objetivo de tiempo de recuperación (RTO). ¿Qué estrategia de reserva se utiliza hoy en día para los servidores? ¿Frecuencia de reserva? ¿Periodo 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 backends de aplicaciones a los que se conecten las aplicaciones alojadas en Citrix en el debate para alinear las expectativas.
• Objetivo de punto de recuperación (RPO). Para RPO, ¿qué grado de pérdida de datos se considera tolerable para la DR, que puede variar según el componente de la infraestructura o la clasificación de los datos? ¿Qué antigü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 dar servicio a 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 depende totalmente el éxito operativo de la empresa. La respuesta tiene un gran impacto en el ámbito 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 capacidad clave que no necesite incluirse en DR y 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 una ubicación de metro? ¿Entre dos geografías? ¿Dos países? ¿Dentro de una región de proveedor de nube o de la infraestructura completa de un proveedor de nube (multirregión)?
• 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). ¿La organización tiene planes preexistentes sobre cómo 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 canalizaciones 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 DR conllevan costes que pueden entrar en conflicto con los presupuestos del proyecto. 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 requisito para que la infraestructura se recupere en la nube en lugar de en una instalación local?
• Preparación de la aplicación. ¿Las aplicaciones alojadas en Citrix que tienen dependencias de back-end tienen un plan de BC/DR y cómo se alinean los RTO con el 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 DR de Citrix es la noción de que un solo 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 los grupos de servidores de StoreFront solo se admite entre centros de datos bien conectados (baja latencia). Del mismo modo, PVS ha documentado los máximos de latencia que se deben tener en cuenta al implementar en varios centros de datos, tal como se describe en el 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.

Además de la referencia conceptual de HA anterior, las arquitecturas de alta disponibilidad basadas en zonas están disponibles para los clientes que desean proporcionar redundancia entre regiones geográficas, 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 de preferencia de zona (7.11 y posteriores), se implementan recursos de Citrix idénticos en varias zonas y se agregan en un solo 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 Componentes internos de preferencias de zona para obtener más información sobre este tema. La función de actualización automática del registro de VDA (introducida en XenDesktop 7.6) permite a los VDA mantener una lista actualizada en caché local 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.

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 realizados por clientes en el pasado.

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 ocupa de la redundancia ni de la tolerancia a fallas del servicio y, en general, es una estrategia de ámbito más amplio que soporta múltiples tipos de fallas.

Si bien la alta disponibilidad tiende a integrarse en las especificaciones de diseño y la implementación de soluciones, la DR se preocupa en gran medida de la planificación de la organización de los recursos de personal e infraestructura para invocar la recuperación del servicio.

¿Puede la 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 ampliación de los dominios administrativos de Citrix (sitio de Citrix, comunidad de PVS, etc.) entre dos centros de datos, como dos instalaciones geolocalizadas según la guía publicada, no supondría una recuperación ante desastres y para algunos componentes, como los grupos de servidores de StoreFront. Del mismo modo, debido a las limitaciones de latencia de la base de datos de PVS según la guía publicada, es probable que dicha implementación no sea compatible. Las restricciones de compatibilidad entre geografías también se extienden a veces al diseño de sitios y zonas de Citrix, debido a los máximos de latencia entre los controladores de satélite y las bases de datos según la 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 niveles de recuperación ante desastres de muestra que sirven de referencia al evaluar los servicios de infraestructura de Citrix, sus dependencias y las aplicaciones o casos de uso críticos (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 red y seguridad
• Enlaces de red
• Hipervisores y dependencias (cómputos, almacenamiento)

Servicios básicos de TI

• Active Directory
• DNS
• DHCP
• Servicios de archivos
• Licencias RDS
• Servicios críticos para el usuario final (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
• ERP y aplicaciones CRM
• Aplicaciones de línea de negocios

Casos prácticos de Citrix

• Administración
• Servicio de atención 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 realiza el aprovisionamiento en la nube, las consideraciones analizadas más adelantedeben tenerse en cuenta, ya que pueden afectar 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 comerciales, pero cuya falta de disponibilidad a corto plazo es poco probable que cause graves impactos financieros, operacionales o de reputación. Estas aplicaciones se recuperan de las copias de seguridad o se recuperan con la prioridad más baja 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 utilizadas 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 ajenos

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 los entornos de nube, que se analizará 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 ámbito de Citrix en sí es útil para establecer expectativas para las unidades de negocio. Por ejemplo, se considera que un entorno de Citrix es un servicio “siempre activo” y tiene una alta disponibilidad en un centro de datos alternativo; sin embargo, los back-ends de aplicaciones críticas de los que dependen las aplicaciones alojadas de Citrix permanecerán no disponibles durante varias horas a medida que se invoque 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. Son posibles otras capacidades de recuperación o variaciones de los siguientes temas para Citrix; 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 de diferentes prioridades, la clasificación de importancia por caso de uso en comparación con el impacto en el negocio según la estrategia de organización en niveles de recuperación discutida anteriormente no puede reducir los costes de capacidad, pero proporcionará al personal de TI un conjunto más centrado de órdenes de prioridad de recuperación.
• Prestaciones. Si ciertos componentes, como HDX Insight o Grabación de sesiones, no se consideran críticos para el funcionamiento de la plataforma de recuperación ante desastres, su omisión en el entorno de DR elimina parte de la complejidad y la 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.
• 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 NetScaler 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

Pros y contras

Pros:

• Menor coste de mantenimiento en comparación con soluciones de replicación o de reserva activa

Contras:

• Alto impacto de inactividad
• Documentación más grande y detallada del plan de recuperación (orquestación de DR)
• Tiempo de recuperación extendido
• 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 es adecuado para MCS o PVS de clonación rápida agrupados
• No es adecuado para Citrix VPX ADC debido a la conexión en red (y es posible que deba reconstruirse mediante copias de seguridad del directorio nsconfig y los archivos ns.conf)

Caso de uso y suposiciones

Útil para organizaciones de TI menos maduras y organizaciones con presupuestos de operaciones de TI limitados y puede permitir interrupciones prolongadas para recuperar los servicios empresariales principales. Asume que las copias de seguridad se prueban regularmente para comprobar la integridad de las restauraciones y siguen

Opción de recuperación: recuperación mediante replicación

Pros y contras

Pros:

• Es probable que la replicación sea automatizada y se alinea con RTO y RPO
• Es probable que utilice tecnologías menos complejas en comparación con las 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 es adecuado para MCS o PVS de clonación rápida agrupados. 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

Pros y contras

Pros:

• Menor coste de mantenimiento en comparación con las soluciones de reserva
• Es probable que la replicación sea automatizada y se alinea con RTO y RPO
• Los planes de recuperación tienden a automatizarse
• Menor 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 es adecuado para MCS o PVS de clonación rápida agrupados. 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

Pros y contras

Pros:

• Tiempo de recuperación corto, ya que la plataforma está “siempre activa”
• 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 por error la URL o dirigir a los usuarios a la URL
• Coste más alto debido a que el hardware “activo” en DR está en 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”. Esto ú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 NetScaler 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

Pros y contras

Pros:

• Tiempo de recuperación corto, ya que la plataforma está “siempre activa”
• 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 NetScaler Gateway

Contras:

• Mayor coste debido a tener hardware “activo” en recuperación ante desastres en espera y licencias de NetScaler 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 NetScaler 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

Pros y contras

Pros:

• Tiempo de recuperación corto, ya que la plataforma está “siempre activa”
• 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)
• Perfecta para los usuarios finales

Contras:

• Mayor coste debido a tener hardware “activo” en recuperación ante desastres en espera y licencias de NetScaler 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
• El GSLB activo/activo no admite actualmente los análisis EPA en NetScaler Gateway, se sugiere la configuración de GSLB activo/pasivo para la URL de NetScaler Gateway
• Depende de los administradores para supervisar y ajustar la capacidad de recursos y hardware en todos los centros de datos para garantizar que, a medida que la plataforma crezca, la integridad de la capacidad de DR no

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 NetScaler 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

Coste de rendimiento de disponibilidad

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 los cálculos de dimensionamiento del rendimiento, suponga la carga total de capacidad de DR Capture los siguientes datos por usuario simultáneo:

• Ancho de banda estimado de sesión ICA
• Ancho de banda de comunicación de aplicaciones estimado por sesión si atraviesan los 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 de nube en agosto de 2019, lo que puede afectar las implicaciones de los 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 de costes

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%?
• ¿Necesitamos alojar solo cargas de trabajo críticas (es decir, solo un subconjunto de la 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 de SO que admiten casos de uso de aplicaciones o escritorios compartidos alojados para ahorrar tiempo de aprovisionamiento y apagar estas instancias para conservar los 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, mantenerlas fuera de línea y actualizarlas con regularidad. 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

Rendimiento de disponibilidad de costes

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 a Citrix DaaS proporcionado por Citrix Cloud con respecto a la planificación de DR:

• 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 NetScaler Gateway.
• La arquitectura de servicios única 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 NetScaler 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 NetScaler 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.

Citrix DaaS simplifica la recuperación ante desastres

A continuación se muestra un diagrama conceptual típico que describe la arquitectura conceptual de Citrix DaaS, además de la separación de responsabilidades para los componentes administrados por Citrix y los componentes administrados por partners y clientes. Aquí no se ilustran los “Servicios” de WEM, Analytics y NetScaler Gateway, que son componentes opcionales de Citrix Cloud relacionados con Citrix DaaS que se incluirían en “Administrados por Citrix”.

Como se ilustra en el diagrama, una parte importante de los componentes de Control que requieren decisiones de recuperación caen dentro del ámbito de administración de Citrix. Al ser un servicio basado en la nube, la arquitectura de Citrix DaaS es muy resistente dentro de la región de Citrix Cloud. Forma parte de la “salsa secreta” de Citrix Cloud y se considera dentro de los SLA 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, NetScaler 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, NetScaler) 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 Citrix DaaS:

• 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 la recuperación ante desastres de Citrix DaaS

Si bien 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 de la alta disponibilidad (opcional) de los componentes ubicados dentro de 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 Citrix DaaS, las ubicaciones de recursos se presentan como zonas. Con la preferencia de zona podemos gestionar la conmutación por error entre ubicaciones de recursos en función de la lógica que especifiquemos. 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 analizadas anteriormente se aplican a Citrix DaaS, por lo que hay 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 Citrix DaaS de Citrix Cloud, se deben entender 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 NetScaler Gateway y StoreFront y no consumir Citrix Workspace o NetScaler 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 de seguir funcionando si se interrumpe la conexión de Cloud Connector a Citrix Cloud, 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 NetScaler 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 bastante 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 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 DaaS simplifica significativamente muchos aspectos de la arquitectura de DR y permite la redundancia de ubicación de recursos a través de 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 fuente que puede adaptar a sus propias necesidades: diagramas fuente.