Décision de conception : planification de la reprise après sinistre

Vue d’ensemble

Ce guide aide à planifier l’architecture de reprise après sinistre (DR) et à prendre en compte les considérations relatives aux déploiements sur site et dans le cloud de Citrix Virtual Apps and Desktops. La DR est un sujet important dans son champ d’application en soi. Citrix reconnaît que ce document n’est pas un guide complet d’une stratégie globale de reprise après sinistre. Il ne prend pas en compte tous les aspects de la DR et adopte parfois le point de vue d’un profane sur divers concepts de DR.

Ce guide vise à répondre aux considérations suivantes qui ont un impact significatif sur l’architecture Citrix d’une entreprise et à fournir des conseils architecturaux les concernant :

• Besoins de l’entreprise
• Reprise après sinistre ou haute disponibilité
• Classifications des niveaux de reprise après sinistre
• Options de reprise après sinistre
• Reprise après sinistre dans le cloud
• Considérations relatives à l’exploitation

Besoins de l’entreprise

L’alignement sur la « couche métier » de la méthodologie de conception de Citrix, la collecte des exigences commerciales précises et des contraintes connues pour la restauration des services constituent le point de départ de l’élaboration de tout plan de reprise pour Citrix. Cette étape définit le champ d’application et les exigences qui sous-tendent la stratégie de reprise après sinistre (abordée plus loin) la mieux adaptée pour répondre aux exigences opérationnelles et fonctionnelles dans le cadre des contraintes déterminées par l’entreprise ou le service informatique.

Voici quelques exemples de questions utiles à aborder lors de la planification de la reprise après sinistre. Ces éléments clés sont importants pour identifier les exigences commerciales et les contraintes potentielles. Cette liste est un exemple de questions de base courantes, et les organisations peuvent avoir d’autres questions auxquelles répondre pour répondre à leurs exigences. Ces questions sont abordées plus en détail dans la section Options de reprise après sinistre plus loin dans le document :

• Stratégie de sauvegarde. La sauvegarde peut prendre en charge la reprise après sinistre, mais elle ne remplace pas les sauvegardes qui peuvent en fait être nécessaires pendant la reprise après sinistre, soit dans le cadre du plan, soit pour se protéger contre la corruption des données de réplication. Quelle est la stratégie de sauvegarde utilisée aujourd’hui pour les serveurs ? Y compris :
  • Fréquence de sauvegarde ?
  • Durée de conservation ?
  • Stockage hors site ?
  • Méthodologie de test des sauvegardes ?
• Objectif de temps de restauration (RTO). La plateforme Citrix sera-t-elle immédiatement disponible en cas de sinistre ou mise en ligne dans un délai précis ? (Voir Classifications des niveaux de reprise après sinistre). Le RTO varie en fonction de la classification de criticité des applications ou des services, mais en général, le RTO de Citrix doit correspondre ou être supérieur au RTO le plus bas d’une application hébergée sur Citrix et les dépendances de Citrix (réseau, stockage, calcul, etc.) doivent correspondre ou être supérieures à celles de Citrix ou des RTO en aval pour que les applications puissent être menacées. Il vaut la peine d’inclure les back-ends d’applications auxquels les applications hébergées par Citrix se connectent à la discussion afin d’aligner les attentes.
• Objectif de point de récupération (RPO). Pour le RPO, quel est le degré de perte de données considéré comme tolérable pour l’organisation, lequel peut varier en fonction de la classification des applications en question ? Quel âge peuvent avoir les données récupérées pour le service ? 0 minutes ? Une heure ? Un mois ? Dans le contexte de l’infrastructure Citrix, cette considération ne peut s’appliquer qu’aux modifications de base de données et aux données utilisateur (profils, redirection de dossiers, etc.). Comme pour le RTO, il convient de prendre en compte les backends des applications hébergées par Citrix.
• Portée de la récupération. Cette considération n’inclut pas uniquement l’infrastructure Citrix, mais peut inclure les données utilisateur ou les serveurs d’applications clés avec lesquels les clients d’applications hébergés par Citrix interagissent. Il est important d’identifier s’il y aura une disparité entre le temps nécessaire à la restauration de la plate-forme Citrix et le temps de restauration des applications hébergées sur Citrix. Le delta temporel peut prolonger une panne, car seule une partie de la solution peut l’être.
• Cas d’utilisation. Les plateformes Citrix prennent souvent en charge de nombreux cas d’utilisation, chacun présentant différents niveaux de criticité commerciale. La récupération couvre-t-elle tous les cas d’utilisation de Citrix ? Ou des cas d’utilisation clés dont dépend entièrement le succès opérationnel de l’entreprise. La réponse a un impact important sur la portée de l’infrastructure et les projections de capacité. Il est recommandé de hiérarchiser et de hiérarchiser les cas d’utilisation afin de compartimenter l’activation de la reprise après sinistre s’il s’agit d’une nouvelle fonctionnalité pour l’environnement Citrix.
• Capacités. Existe-t-il des fonctionnalités clés qui n’ont pas besoin d’être incluses dans la reprise après sinistre et qui peuvent réduire les coûts ? Un exemple de cette fonctionnalité serait l’utilisation de bureaux persistants par rapport à des bureaux non persistants ; certains cas d’utilisation du VDI peuvent être servis par des bureaux partagés hébergés ou même des solos d’applications spécifiques. Les entreprises ont parfois indiqué que la redondance des composants (ADC, Controllers, StoreFront, SQL, etc.) n’était pas considérée comme nécessaire en DR. De telles décisions peuvent être considérées comme un risque en cas d’interruption prolongée de la production.
• DR existante. Existe-t-il une stratégie ou un plan de reprise après sinistre existant pour d’autres environnements Citrix et autres services d’infrastructure ? Restait-il dans de nouveaux sous-réseaux routables ou dans une « bulle » miroir des réseaux de production ? La réponse peut aider à donner une visibilité aux approches, aux outils ou à la priorité en cas de reprise après sinistre.
• Capacités technologiques. Cette considération ne peut pas dicter la stratégie de restauration finale pour Citrix. Cependant, il est important de comprendre :
  • Récupération : Quelles technologies de réplication de stockage, technologies de récupération de machines virtuelles (VMware SRM, Veeam, Zerto, Azure Site Recovery (ASR), etc.) sont disponibles au sein de l’organisation ? Certains composants Citrix ainsi que les dépendances Citrix peuvent les utiliser.
  • Citrix : Quelles technologies Citrix sont utilisées pour la gestion des images et l’accès ? Certains éléments ne se prêtent pas bien à certaines stratégies de rétablissement. Les environnements non persistants gérés par MCS ou PVS sont de mauvais candidats pour les technologies de réplication de machines virtuelles en raison de leur intégration étroite avec le stockage et le réseau.
• Degré d’importance des données. Les profils utilisateur ou les données utilisateur sont-ils considérés comme essentiels à la restauration ? Pour le VDI persistant, si ces données ne sont pas disponibles lorsque la reprise après sinistre est invoquée, cela aurait-il un impact significatif sur la productivité ? Ou un profil non persistant ou un VDI peut-il être utilisé comme solution temporaire ? Cette décision peut augmenter les coûts et la complexité des solutions.
• Types de sinistres. Cette décision est assez importante, mais elle peut également être préétablie au moyen d’un plan d’entreprise BC ou RD. Cette exigence dicte souvent l’emplacement de récupération. La stratégie est-elle destinée à permettre la récupération du service au niveau de l’application seulement ? Entre les racks matériels ? Dans une station de métro ? Entre deux zones géographiques ? Deux pays ? Au sein d’une région fournisseur de nuage ou d’une infrastructure complète d’un fournisseur de cloud (multi-région) ? Entre fournisseurs de cloud (multicloud) ?
• Utilisateurs clients. Où se trouvent les utilisateurs qui accèdent aux services en production ? Cette décision peut avoir des implications quant à l’endroit où le service est rétabli, y compris la connectivité réseau d’entreprise qui peut nécessiter des modifications manuelles lors d’un événement de reprise après sinistre. En outre, la réponse dicte les considérations relatives au niveau d’accès.
• Bande passante réseau. Combien de trafic (ICA, applications, services de fichiers) chaque session utilisateur consomme-t-elle en moyenne ? Cette décision s’applique à la fois au cloud et à la récupération sur site.
• Secours (ou restauration). L’organisation dispose-t-elle de plans préexistants pour la remise en service en production une fois que la situation de reprise après sinistre aura été résolue ? Comment l’organisation reprend-elle son état normal ? Comment les nouvelles données qui auraient pu être créées dans DR sont-elles conciliées et combinées avec la production ?

Contraintes

Les contraintes limitent les options de conception DR ou leurs configurations. Ils se présentent sous de nombreuses formes, mais peuvent inclure :

• Stratégie réglementaire ou d’entreprise. Cette décision peut dicter les technologies qui peuvent ou ne peuvent pas être utilisées pour la réplication ou la restauration, la manière dont elles sont utilisées, le RTO, la souveraineté des données ou la distance minimale entre les installations.
• Infrastructure. Existe-t-il une directive sur le type de matériel à utiliser, la bande passante réseau disponible, et ainsi de suite ? Ces considérations peuvent avoir une incidence sur les considérations relatives aux RPO ou même présenter des risques. Par exemple :
  • Les pare-feux ou les canaux réseau sous-dimensionnés en DR peuvent finalement entraîner des pannes, car les dépendances du réseau ne peuvent pas gérer la charge de travail de reprise après sinistre.
  • Dans le cas du calcul, des hôtes hyperviseurs sous-dimensionnés ou l’utilisation d’hyperviseurs totalement différents peuvent avoir un impact sur les options.
  • En ce qui concerne la mise en réseau, si le site de restauration présente une capacité de débit réseau plus limitée que le site de production lors de la maintenance du WAN.
  • Dans les environnements cloud, en particulier lorsqu’ils s’étendent à des milliers de postes, ce risque potentiel peut rapidement devenir un obstacle majeur en raison des limites de service des composants, telles que les pare-feux virtuels, les passerelles VPN et les liaisons montantes entre le cloud et le WAN (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, etc.).
  • En outre, dans les environnements cloud, il convient de tenir dûment compte de la parité des services disponibles dans les régions cloud désignées dans la région DR. Les leçons apprises sur le terrain nous indiquent que même si une région de cloud public peut sembler attrayante au départ du point de vue des coûts d’hébergement, des fonctionnalités importantes telles que les zones de disponibilité, les types d’instances ou des fonctionnalités de stockage particulières, par exemple, ne sont pas disponibles dans toutes les régions cloud. Une bonne règle consiste à évaluer si les fonctionnalités et capacités prévues sont disponibles dans toutes les régions dont le déploiement est prévu.
• Budget. Les solutions de reprise après sinistre ont des coûts qui peuvent entrer en conflit avec les budgets des projets Le plus souvent, plus le RTO est court, plus le coût est élevé.
• Géographie. Si une installation de reprise après sinistre désignée a été identifiée, des considérations telles que la latence entre la production et les installations de reprise après sinistre, en plus des utilisateurs qui se connectent à la DR, doivent être comprises.
• Résidence des données ou classification des données. Cette décision peut limiter les options relatives aux paramètres locaux, aux technologies ou aux méthodes de restauration.
• Récupération cloud. Existe-t-il un mandat pour la restauration de l’infrastructure dans le cloud plutôt que dans une installation sur site ?
• Capacité. Le site de reprise après sinistre dispose-t-il d’une capacité suffisante pour supporter la charge requise pour répondre aux exigences de reprise après sinistre ? En cas de restauration vers le cloud, le volume de charges de travail à restaurer est-il réaliste dans le cadre du RTO s’il n’est pas préprovisionné ou couvert par des droits de capacité garantis ?
• Préparation des applications. Les applications hébergées sur Citrix qui ont des dépendances dorsales disposent-elles d’un plan de reprise après sinistre et comment les RTO s’alignent-ils sur le RTO cible de Citrix ? Citrix peut être conçu pour une récupération rapide, mais si les applications principales n’ont pas de plan de récupération ou avec un RTO étendu, ce risque affecte probablement l’utilité de la plate-forme Citrix dans DR.
• Sécurité du réseau. L’organisation dispose-t-elle de stratégies de sécurité qui peuvent dicter quels segments de trafic nécessitent un chiffrement en transit ? Cette considération varie-t-elle en fonction de la liaison réseau traversée ? La réponse peut nécessiter dans les scénarios de reprise après sinistre l’utilisation de VDA SSL, ICA Proxy, GRE ou IPSec VPN encapsulation du trafic ICA si les flux réseau pour la reprise après sinistre sont différents de la production.

Conceptions fausses sur la conception de la reprise après sinistre (DR)

L’une des idées fausses les plus courantes concernant les conceptions de Citrix DR est qu’un seul plan de contrôle couvrant deux centres de données constitue la DR. Ce n’est pas le cas. Un site Citrix unique ou une ferme PVS couvrant des centres de données, même ceux situés à proximité, inclut une conception de haute disponibilité, mais pas une conception de reprise après sinistre. Certaines entreprises choisissent cette voie pour prendre une décision commerciale, privilégiant la gestion simplifiée par rapport à la capacité de reprise après sinistre. Les groupes de serveurs StoreFront couvrant des centres de données ne sont pris en charge qu’entre des centres de données bien connectés (faible latence). De même, PVS a documenté les maximums de latence à prendre en compte lors du déploiement dans des centres de données, comme indiqué dans le document CTX220651.

Le schéma suivant est un exemple d’architecture Citrix HA multi-centres de données qui n’est toutefois pas une plate-forme de reprise après sinistre pour les raisons mentionnées précédemment. Cette architecture de référence est utilisée par les entreprises qui considèrent deux centres de données physiquement séparés comme un seul centre de données logique en raison de leur proximité l’un de l’autre, de leur faible latence et de leur interconnexion à bande passante élevée. Un plan de reprise après sinistre et un environnement pour Citrix seraient toujours recommandés, car il est peu probable que cette architecture réponde aux besoins de la DR ou de la HA.

Outre la référence conceptuelle HA ci-dessus, les architectures HA basées sur des zones sont disponibles pour les organisations qui souhaitent fournir une redondance intergéographique mais qui n’ont pas besoin que la plate-forme soit entièrement récupérable. Le concept de zones permet diverses fonctionnalités de redondance intra-site qui peuvent résoudre les problèmes liés aux déploiements sur plusieurs sites.

Dans une architecture de site qui utilise la fonctionnalité de préférence de zone, des ressources Citrix identiques sont déployées sur plusieurs zones et agrégées dans un seul groupe de mise à disposition. La préférence de zone (avec la possibilité de revenir à d’autres zones pour une ressource donnée) peut être contrôlée en fonction de l’application, de la zone d’accueil de l’utilisateur ou de l’emplacement de l’utilisateur. Reportez-vous à la section Internes des préférences de zone pour plus d’informations à ce sujet. La fonctionnalité de mise à jour automatique de l’ enregistrement des VDA permet aux VDA de conserver une liste à jour de tous les contrôleurs d’un site, mise en cache localement. Cette fonction permet aux VDA de la zone satellite de basculer l’enregistrement des VDA dans la zone principale au cas où leurs Delivery Controller ou Cloud Connector locaux deviendraient indisponibles dans leur zone locale. Les groupes de serveurs StoreFront sont présents dans chaque zone (ou au moins dans deux zones), comme il est recommandé aux utilisateurs de continuer à accéder aux ressources depuis leur niveau d’accès local en cas d’indisponibilité de la zone principale.

Contrairement à ces options HA prises en charge, le diagramme suivant illustre les architectures de composants non prises en charge ou mal conseillées couvrant des centres de données ou des régions de cloud géographiquement éloignés. Ces diagrammes ne fournissent ni HA ni DR efficaces en raison de la distance et de la latence entre les composants. Des problèmes de stabilité de la plate-forme peuvent également survenir en raison de problèmes de latence lors d’un tel déploiement. De plus, l’étirement des limites administratives entre les sites n’est pas conforme aux principes de RD. Nous avons vu des conceptions conceptuelles similaires par des organisations dans le passé.

Une autre idée fausse courante est la profondeur de considération qu’une solution Citrix DR peut inclure. Citrix Virtual Apps and Desktops est principalement une plate-forme de présentation et de livraison. Le plan de contrôle Citrix dépend d’autres composants (mise en réseau, SQL, Active Directory, DNS, licences d’accès réseau RDS, DHCP, etc.) dont la conception de disponibilité et de récupération répond aux exigences de reprise après sinistre de la plate-forme Citrix. Tout domaine administratif partagé de technologies dont Citrix dépend peut avoir une incidence sur l’efficacité de la solution Citrix DR.

Les considérations relatives à la restauration des services de fichiers (données utilisateur et données commerciales partagées, etc.) et des back-ends d’applications avec lesquels les applications et les bureaux hébergés par Citrix s’interfacent sont tout aussi importantes et ne sont parfois pas pleinement prises en compte par les entreprises. En référençant le point précédent sur l’état de préparation de l’application, une plate-forme Citrix DR peut être conçue pour récupérer dans de courtes périodes. Toutefois, si ces dépendances liées aux cas d’utilisation principaux ne disposent pas d’un plan de restauration avec RTO similaire à Citrix ou s’il n’existe aucun plan de reprise, ce plan peut empêcher Citrix de basculer correctement en DR comme prévu, mais les utilisateurs ne seront pas en mesure d’exécuter leurs tâches car ces dépendances restent indisponibles. Prenons par exemple un hôpital qui héberge son application EMR principale sur Citrix. Un événement de reprise après sinistre se produit et Citrix bascule vers une plate-forme Citrix « toujours active » en cas de reprise après sinistre et les utilisateurs se connectent, mais l’application EMR est restaurée par des moyens plus manuels, ce qui peut prendre des heures, voire des jours. Le personnel clinique serait probablement obligé d’utiliser des processus hors ligne (stylo et papier) pendant cette période. Un tel résultat ne peut être conforme aux attentes générales de l’entreprise en matière de temps de reprise ou d’expérience utilisateur.

La section suivante traitera plus en détail de la DR par rapport à l’HA.

Reprise après sinistre (DR) ou haute disponibilité (HA)

Il est essentiel de comprendre la haute disponibilité par rapport à la reprise après sinistre pour répondre aux besoins de l’organisation et atteindre les objectifs de reprise. HA n’est pas synonyme de DR, mais DR peut utiliser HA. Ce guide interprète l’HA et la DR comme suit :

• La haute disponibilité est considérée comme fournissant une tolérance aux pannes pour un système (service, application, etc.) ou un composant. Un système peut basculer vers un autre système sans perturber le moins possible l’utilisateur. La solution peut être aussi simple qu’une application en cluster ou à charge équilibrée ou une infrastructure active ou en veille « active » ou « toujours active » plus complexe qui reflète les configurations de production et est toujours disponible. Le basculement a tendance à être automatisé dans ces configurations et peut également être qualifié de déploiement « géo-redondant ».
• La reprise après sinistre concerne principalement la restauration du service (en raison d’une défaillance importante au niveau de l’application ou d’une défaillance physique catastrophique du datacenter) vers un autre datacenter (ou plate-forme cloud). La reprise après sinistre a tendance à impliquer des processus de récupération automatisés ou manuels. Les étapes et procédures sont documentées pour orchestrer la récupération. Elle ne concerne pas la redondance ou la tolérance aux pannes des composants et constitue généralement une stratégie à plus large portée qui résiste à de multiples types de défaillances.

Alors que la haute disponibilité a tendance à être intégrée aux spécifications de conception et au déploiement des solutions, la reprise après sinistre concerne principalement la planification de l’orchestration du personnel informatique et des ressources d’infrastructure afin de provoquer le rétablissement du service.

Est-ce que HA peut inclure la DR ? Oui. Pour les services informatiques stratégiques de l’entreprise, ce concept est courant. Prenons par exemple le deuxième exemple de la description HA précédente, associé à la restauration appropriée d’autres composants non liés à Citrix liés à la solution, qui serait considérée comme une solution de reprise après sinistre à haute disponibilité dans laquelle un service (Citrix) bascule vers un centre de données opposé. Cette architecture peut être mise en œuvre en tant qu’actif-passif ou actif-actif dans diverses itérations multisites, telles que active-passive pour tous les utilisateurs, active-active avec les utilisateurs préférant un centre de données plutôt qu’un autre, ou active-active avec des utilisateurs équilibrés entre deux centres de données sans préférence. Il est important de noter que lors de la conception de telles solutions, la capacité de réserve doit être prise en compte, comptabilisée et la charge surveillée en permanence afin de garantir que la capacité reste disponible pour accueillir la reprise après sinistre si nécessaire.

Il est également essentiel que les composants DR soient maintenus à jour pendant la production afin de préserver l’intégrité de la solution. Cette activité est souvent négligée par les entreprises qui conçoivent et déploient une telle solution avec les meilleures intentions, puis commencent à consommer davantage de ressources de plate-forme en production et oublient d’augmenter la capacité disponible pour préserver l’intégrité de la solution après sinistre.

Dans le contexte de Citrix, le fait de répartir les domaines administratifs Citrix (Citrix Site, PVS Farm, etc.) entre deux centres de données tels que deux installations géolocalisées conformément aux directives publiées ne constituerait pas une solution de reprise après sinistre, ni pour certains composants tels que les groupes de serveurs StoreFront. De même, en raison des limites de latence de base de données de PVS conformément aux directives publiées, un tel déploiement n’est pas recommandé. Les contraintes de compatibilité entre les zones géographiques s’étendent également à la conception des sites et des zones Citrix, en raison des délais de latence maximaux entre les contrôleurs satellites et les bases de données, conformément aux directives publiées.

Étant donné que de nombreux composants Citrix partagent des dépendances telles que des bases de données, l’étirement des limites administratives entre les deux centres de données ne permettrait pas de protéger contre plusieurs scénarios de défaillance clés. Si les bases de données étaient corrompues, le domaine défaillant aurait un impact sur les services d’application dans les deux installations. Pour considérer qu’une solution Citrix HA est suffisante pour la reprise après sinistre, nous recommandons que la seconde installation ne partage pas les dépendances clés ou les limites administratives. Par exemple, créez des sites, des batteries de serveurs et des groupes de serveurs distincts pour chaque centre de données de la solution. En permettant à une plate-forme de restauration d’être aussi indépendante que possible, nous réduisons l’impact des défaillances au niveau des composants qui affectent à la fois les environnements de production et de reprise après sinistre. Cette considération va également au-delà de Citrix, et il est également recommandé d’utiliser différents comptes de service, services de fichiers, DNS, NTP, gestion des hyperviseurs, autorités de certification (dépendance FAS) et services d’authentification (AD, RADIUS, etc.) entre les environnements de production et de reprise après sinistre afin de réduire les points de défaillance uniques.

Classifications des niveaux de reprise après sinistre

Les classifications par niveaux pour la reprise après sinistre constituent un aspect important de la stratégie de reprise après sinistre d’une entreprise, car elles permettent de clarifier la criticité des applications ou des services, qui dicte à son tour le RTO (et donc les coûts liés à l’atteinte de ce niveau de reprise). Certaines organisations peuvent également établir un RTO pris en charge (soutenu par des solutions technologiques ou des modèles architecturaux) et leur attribuer des classifications de niveaux. En général, plus le RTO est court, plus le coût de la solution DR est élevé. Être capable de diviser diverses interdépendances en différentes classifications (en fonction de la criticité métier et de la RTO) peut aider à optimiser les cas de reprise après sinistre sensibles aux coûts.

Vous trouverez ci-dessous un ensemble d’exemples de classifications de niveaux DR à utiliser comme référence lors de l’évaluation des services d’infrastructure Citrix, de leurs dépendances et des applications ou cas d’utilisation critiques (associés aux charges de travail VDA) hébergés sur Citrix. Les niveaux DR sont présentés par ordre de priorité de restauration, 0 étant le plus critique. Les organisations sont encouragées à appliquer ou à élaborer une classification par hiérarchisation des DR qui corresponde à leurs propres objectifs de rétablissement et à leurs besoins en matière de classification.

Niveau 0 de reprise après sinistre (exemple)

Niveau 0 - Objectifs de rétablissement

Objectif de temps de récupération : 0

Objectif de point de récupération : 0

Niveau 0 - Classification

Infrastructure informatique de base

• Infrastructure de réseau et de sécurité
• Liens réseau
• Hyperviseurs et dépendances (calcul, stockage)

Services informatiques de base

• Active Directory
• DNS
• DHCP
• Services de fichiers
• Licences RDS
• CA Services (si vous utilisez FAS)
• Serveurs SQL (WEM sur site ou Citrix Virtual Apps and Desktops, PVS, enregistrement de session)
• Services aux utilisateurs finaux critiques (Citrix)

Niveau 0 - Notes

Cette classification concerne principalement les composantes de l’infrastructure de base. Ces composants sont toujours disponibles dans l’emplacement de reprise après sinistre car ils sont des dépendances pour d’autres niveaux, et non dans un segment de réseau isolé. Ils doivent être approvisionnés et entretenus parallèlement à leurs équivalents de production. Si Citrix héberge des applications critiques, elle est probablement considérée comme une plate-forme de niveau 0. Dans de tels scénarios, l’infrastructure Citrix est déployée « à chaud » dans DR.

Reprise après sinistre de niveau 1 (exemple)

Niveau 1 - Objectifs de rétablissement

Objectif de temps de récupération : 15 minutes

Objectif de point de récupération : 1 heure

Niveau 1 - Classification

Applications critiques

• Sites Web et applications Web
• ERP et applications CRM
• Applications sectorielles

Cas d’utilisation de Citrix

• Direction
• Centres d’appels
• Service à la clientèle ou ventes
• Ingénierie et support informatiques

Niveau 1 - Notes

Les applications ou les bureaux virtuels dont dépend l’entreprise pour mener à bien ses activités principales sont généralement contenus dans ce niveau. Ils utiliseraient probablement également une architecture de reprise après sinistre « de secours à chaud » similaire à celle de niveau 0 ou bénéficieraient d’une solution automatisée de réplication et de basculement. En cas de provisionnement dans le cloud, les considérations abordées plus loindoivent être prises en compte car elles peuvent avoir un impact sur les objectifs de RTO.

Reprise après sinistre de niveau 2 (exemple)

Niveau 2 - Objectifs de rétablissement

Objectif de temps de récupération : 4 heures

Objectif du point de rétablissement : 1 jour

Niveau 2 - Classification

Applications non critiques

Cas d’utilisation non critiques de Citrix

Données utilisateur n’ayant aucune incidence sur les fonctionnalités des applications de niveau 1 ou de niveau 0

Niveau 2 - Notes

Applications ou cas d’utilisation qui sont essentiels aux opérations commerciales, mais dont l’indisponibilité à court terme est peu susceptible d’avoir de graves répercussions financières, de réputation ou opérationnelles. Ces applications sont soit restaurées à partir de sauvegardes, soit restaurées avec la plus faible priorité par des outils de restauration automatique.

Reprise après sinistre de niveau 3 (exemple)

Niveau 3 - Objectifs de rétablissement

Objectif de délai de récupération : 5 jours

Objectif du point de rétablissement : 1 semaine

Niveau 3 - Classification

Applications peu utilisées

Niveau 3 - Notes

Les applications dont l’impact des interruptions est négligeable sont indisponibles pendant une semaine au maximum. Ces applications sont probablement récupérées à partir de sauvegardes.

Reprise après sinistre de niveau 4 (exemple)

Niveau 4 - Objectifs de rétablissement

Objectif de délai de récupération : 30 jours

Objectif de point de récupération : 24 heures ou aucun

Niveau 4 - Classification

Environnements hors production

Niveau 4 - Notes

Les applications, les infrastructures et les VDI dont les pannes ont également un impact négligeable sur les opérations commerciales peuvent être restaurées au fil du temps. Selon leur nature, ils peuvent également avoir un RPO étendu ou pas du tout. Ces RPO peuvent être restaurés à partir de sauvegardes ou créés tout neufs en DR et sont considérés comme le dernier niveau à restaurer.

Pourquoi la classification de niveau est-elle importante pour la planification de la reprise après sinistre Citrix ?

La classification par niveau est importante pour Citrix pour les raisons suivantes :

• Quelle est l’importance de l’infrastructure Citrix pour les opérations commerciales ? Si Citrix est considéré comme essentiel, mais que son application hôte est considérée comme nécessaire, l’infrastructure Citrix sera classée comme critique.
• Les cas d’utilisation ou les principales applications métiers hébergés par Citrix. Ont-ils des classifications de niveaux DR différentes ?

Pour répondre à la première question, de nombreux déploiements Citrix en entreprise ont tendance à être classés dans la catégorie « niveau 0 » en raison de la mise à disposition d’applications ou de postes de travail critiques ; dans le niveau « permanent », tel que le réseau, Active Directory, le DNS et l’infrastructure d’hyperviseur. Cette circonstance peut ne pas toujours être le cas cependant pour chaque cas d’utilisation Citrix. Traiter chaque cas d’utilisation Citrix comme de niveau 0 lorsque certains peuvent entrer dans le niveau 1 ou supérieur peut avoir un impact sur le coût global et la complexité du processus de reprise après sinistre.

La deuxième question met l’accent sur la classification par cas d’utilisation de Citrix et souligne son importance particulièrement dans les environnements cloud, ce qui sera discuté plus en détail plus loin. Dans le cloud, il existe des considérations financières importantes entre l’adaptation à des plateformes d’applications ou de bureau « toujours actives », par rapport à des applications ou à des ordinateurs de bureau considérés comme moins critiques pour l’entreprise. De telles considérations peuvent également influencer l’isolement des applications ou des cas d’utilisation (silos) en production afin de tirer parti de la flexibilité du déploiement dans une plate-forme de reprise après sinistre.

Lors de l’élaboration d’une conception de reprise après sinistre pour Citrix, le fait de porter la discussion au-delà du cadre de Citrix lui-même permet de définir les attentes des unités commerciales. Par exemple, un environnement Citrix est considéré comme un service « toujours actif » et est rendu hautement disponible dans un autre centre de données. Pourtant, les back-ends essentiels dont dépendent les applications hébergées de Citrix resteront indisponibles pendant plusieurs heures lorsque la restauration sera invoquée. Cet écart crée une disparité entre les temps de récupération entre les deux plates-formes et peut fournir une expérience utilisateur trompeuse pendant la récupération. Citrix est disponible immédiatement, mais les applications critiques ne fonctionnent pas. La définition des attentes dès le départ offre à toutes les parties prenantes une visibilité appropriée sur l’expérience de rétablissement. Dans certains cas, un client peut souhaiter maintenir Citrix en veille (toujours actif) dans l’installation adverse, tout en contrôlant manuellement le basculement du niveau d’accès afin d’éviter tout malentendu quant à la disponibilité de la plate-forme.

Options de reprise après sinistre

Cette section décrit les stratégies de récupération Citrix les plus courantes, y compris leurs avantages et leurs inconvénients, ainsi que les principales considérations. D’autres fonctionnalités de restauration ou variantes des thèmes suivants sont possibles pour Citrix. Cette section se concentre sur certains des plus courants. De plus, cette section illustre comment les réponses aux questions fondamentales indiquées au début influencent la conception du RD.

En corrélation avec plusieurs des questions de DR précédentes, les sujets de questions suivants ont des implications sur la conception de Citrix DR, comme suit :

• Stratégie de sauvegarde et objectif de temps de récupération (RTO). Si l’infrastructure ou les applications Citrix proposées par Citrix sont considérées comme essentielles à la mission, il est probable que Citrix doive utiliser un modèle « toujours actif » dans lequel une infrastructure Citrix active ou active est présente dans deux centres de données ou plus. Cette architecture entraînerait la création de plusieurs plans de contrôle Citrix indépendants dans chaque centre de données (sites Citrix distincts, batteries PVS le cas échéant, groupes de serveurs StoreFront, etc.). Le fait d’étendre les plans de contrôle de l’infrastructure Citrix ne constitue pas une solution de reprise après sinistre (par exemple, étendre un site à plusieurs centres de données ou utiliser des zones satellites) ; cela va à l’encontre de ce mandat si l’entreprise attend une plate-forme de reprise après sinistre pour Citrix.
• Portée de la récupération. Si Citrix est déployé en mode veille prolongée (toujours active) en cas de reprise après sinistre mais que la restauration des principaux systèmes d’applications métiers prend, par exemple, 8 heures, il n’est pas logique de recourir à un basculement automatique du niveau d’accès. Le basculement manuel du niveau d’accès peut être plus approprié.
• Cas d’utilisation. Si seules les charges de travail critiques ou les applications principales doivent être rapidement restaurées dans Citrix pour maintenir les opérations métier dans un scénario de reprise après sinistre, ce scénario peut probablement réduire les coûts de reprise après sinistre du point de vue de la capacité. Si plusieurs cas d’utilisation ayant des priorités différentes nécessitent une restauration, la classification de l’importance par cas d’utilisation par rapport à l’impact commercial selon la stratégie de hiérarchisation de la reprise évoquée précédemment ne permet pas de réduire les coûts de capacité mais fournira au personnel informatique un ensemble plus ciblé d’ordres prioritaires de restauration.
• Capacités. Si certains composants tels que HDX Insight et Session Recording ne sont pas considérés comme essentiels au fonctionnement de la plate-forme de reprise après sinistre, leur omission dans l’environnement de reprise après sinistre élimine une certaine complexité et réduit les frais de maintenance. De même, si de nombreux cas d’utilisation dans un scénario de reprise après sinistre peuvent subsister sur une option de livraison Citrix plus simple et plus générique en reprise après sinistre, cela peut également réduire la complexité et les coûts. Par exemple, utiliser un bureau partagé hébergé au lieu d’un VDI groupé ou d’un VDI persistant si cela est techniquement faisable (dans le contexte d’une restauration rapide et rentable des services dans un scénario de reprise après sinistre), ou regrouper plusieurs cas d’utilisation en un seul, à condition qu’ils ne nuisent pas aux opérations commerciales.
• DR existante. Si la stratégie de reprise après sinistre existante de l’organisation, par exemple, récupère Citrix et d’autres infrastructures applicatives à l’aide d’outils de réplication et d’orchestration des données, la plupart des composants Citrix peuvent convenir à ce modèle. Si la taille de la plate-forme et le recours à une technologie de gestion d’image unique sont des exigences de la plate-forme de production, ces technologies ne sont souvent pas adaptées ; une approche hybride combinant une plate-forme Citrix de secours et peut-être la réplication des images principales peut être plus appropriée.
• Degré d’importance des données. Si les profils sont considérés comme essentiels pour la restauration en cas de reprise après sinistre, une technologie de réplication appropriée peut être nécessaire. De nombreuses organisations sont moins préoccupées par les profils dans les scénarios de reprise après sinistre et acceptent qu’on les crée à nouveau. Cette considération s’appliquera également aux données utilisateur accessibles dans Citrix (redirection de dossiers, lecteurs mappés) ; RPO et RTO pour ces données peuvent être une décision métier. En outre, si de nombreux VDI persistants sont considérés comme suffisamment importants pour rester intacts en cas de reprise après sinistre (au lieu de demander aux utilisateurs de réinstaller leur logiciel, etc.), la réplication de ces machines virtuelles doit être envisagée, ce qui peut entraîner des coûts supplémentaires liés à la restauration.
• Types de sinistres. La mesure dans laquelle un client veut se protéger contre les défaillances peut dicter divers changements architecturaux. Si le client ne souhaite que la haute disponibilité de l’infrastructure Citrix dans le centre de données ou la région cloud, ce type de sinistre peut simplement exiger que les composants de gestion soient à la fois redondants et fonctionnent sur des infrastructures adverses. À titre d’exemple, un type de paire de serveurs StoreFront utilise des règles d’anti-affinité VMware pour fonctionner sur différents hôtes d’un cluster, ou sur différents clusters entièrement au sein du centre de données, ou peut-être dans le cadre de différents ensembles de disponibilité. Cette situation nécessite rarement la création de plans de contrôle redondants entièrement (plusieurs sites Citrix et groupes de serveurs StoreFront, par exemple). Toutefois, si la reprise après sinistre est destinée à englober plusieurs datacenters quelle que soit la région, les plans de contrôle redondants utilisant des dépendances locales dans chaque centre de données (AD, DNS, SQL, hyperviseur, etc.) sont plus appropriés. Si le client est global et utilise plusieurs centres de données pour assurer la maintenance de Citrix (ou prévoit de le faire) avec les back-ends applicatifs respectifs locaux de ces centres de données, il est plus probable qu’une architecture géo-localisée Active HA-DR soit plus appropriée. Cette architecture offre aux utilisateurs une expérience utilisateur optimale, dans la mesure du possible, en utilisant des infrastructures Citrix géolocalisées qui peuvent, le cas échéant, basculer vers un centre de données de sauvegarde dans un ordre de préférence secondaire.
• Utilisateurs clients. Au-delà du point précédent concernant les considérations relatives à la localisation des utilisateurs, des applications et des données, certains réseaux d’utilisateurs clients peuvent être relativement verrouillés par des dispositifs de sécurité (proxy, pare-feu, etc.) qui peuvent restreindre les communications sortantes vers Internet ou même le WAN. Il est important de déterminer si cet état s’applique aux réseaux clients et garantit que les nouvelles adresses IP pour les services Citrix (telles que les adresses IP StoreFront VIP et VDA, ou Citrix Gateway IP) sont prises en compte dans leurs configurations de sécurité locales afin d’éviter tout retard de restauration supplémentaire dû aux restrictions de sécurité du réseau local lors de l’invocation de DR. Du point de vue de la préparation, en cas de reprise après sinistre, l’accès des clients changera-t-il d’une manière ou d’une autre ? Dans certains scénarios de reprise après sinistre, par exemple, une entreprise peut supposer que le WAN n’est pas disponible et que tous les utilisateurs doivent accéder aux ressources Citrix via Internet. Ces étapes devraient être documentées dans les plans de reprise après sinistre et de préparation, avec des conditions préalables établies pour les utilisateurs finaux (concernant les informations relatives aux clients Citrix pris en charge et les hypothèses relatives à l’accès aux appareils professionnels ou BYOD) afin de supprimer les obstacles au retour au service des utilisateurs, réduisant ainsi la charge de travail du service d’assistance.
• Bande passante réseau. La quantité de bande passante réseau utilisée pour le trafic VDA (ICA, applications, services de fichiers) doit être prise en compte dans le dimensionnement du réseau et les pare-feux des installations de reprise après sinistre. Cette considération est particulièrement importante dans les environnements cloud où il existe des limites sur les passerelles VPN et la capacité du pare-feu virtuel. Il est important de surveiller le trafic de production à partir de VDA pour déterminer une valeur moyenne pour le dimensionnement afin de dimensionner efficacement la mise en réseau. Lorsque des contraintes réseau existent, les entreprises doivent utiliser différentes configurations réseau pour s’adapter à la charge de trafic de reprise après sinistre attendue en cas d’appel.
• Secours (ou restauration). Si les données utilisateur ont changé pendant la reprise après sinistre ou si les images VDA ont été mises à jour pendant la reprise après sinistre, l’organisation doit planifier un retour en arrière afin de propager ces modifications en production si l’environnement de production s’avère récupérable. Pour les données utilisateur, il peut être aussi simple que d’inverser l’ordre de réplication et de restaurer ; de même, pour l’infrastructure Citrix si elle n’utilise pas de technologies de gestion d’image unique. Si vous utilisez MCS ou PVS, les images principales ou les vDisks peuvent être répliqués manuellement vers la production, et les VDA peuvent être mis à jour en conséquence.

La liste suivante décrit diverses options de récupération courantes pour Citrix. Des adaptations de chacune existent sur le terrain (les organisations choisissent parfois de n’implémenter que certaines parties de ces options pour limiter la reprise après sinistre aux cas d’utilisation critiques ou d’utiliser une combinaison d’options pour équilibrer les coûts entre les différents niveaux de cas d’utilisation), mais à des fins de comparaison, nous décrivons les versions de base de chacune d’entre elles. Les options sont organisées en commençant par les plus simples (souvent plus RTO et coût inférieur) à la plus avancée (souvent plus faible RTO mais coût plus élevé). L’option idéale pour une organisation donnée consiste à aligner le temps de récupération pour les applications hébergées ou les cas d’utilisation, en plus des compétences informatiques, du budget et de l’infrastructure disponibles.

En outre, bien que possible, de nombreuses options indiquent que les technologies Citrix intégrées au réseau et au stockage, telles que NetScaler et les technologies de gestion d’image unique, ne sont pas adaptées à des méthodes autres que les modèles de restauration « toujours actifs ». Ce n’est pas qu’il soit techniquement impossible à accomplir, mais le niveau de complexité inhérent à leur réalisation peut rendre la récupération plus risquée et plus sujette à l’erreur humaine.

Option de récupération - Récupération depuis une sauvegarde hors ligne

Dans cette option, les entreprises s’appuient uniquement sur les solutions de sauvegarde traditionnelles pour restaurer la plateforme Citrix et la remettre en service sur un autre site. Il n’existe aucune infrastructure de secours vers laquelle basculer. Plusieurs tâches, souvent manuelles, sont requises dans le plan de restauration pour restaurer les services principaux dont dépend Citrix et restaurer ensuite Citrix lui-même. La durée de la panne de Citrix est déterminée par la vitesse à laquelle les composants peuvent être restaurés sur le site de reprise après sinistre. Ce modèle n’est pas idéal pour les déploiements Citrix avancés. Il convient particulièrement aux infrastructures plus petites et plus simples et aux entreprises capables de résister à une période d’indisponibilité prolongée.

Avantages et inconvénients

Avantages :

• Coûts de maintenance réduits par rapport aux solutions de réplication ou de mise en veille prolongée

Inconvénients :

• Impact élevé sur les temps d’arrêt
• Documentation plus exhaustive et plus détaillée sur le plan de récupération (orchestration de reprise après sinistre)
• Temps de récupération prolongé
• S’appuie sur l’intégrité et l’ancienneté des sauvegardes
• Un degré d’erreur humaine plus élevé si une reconfiguration manuelle est nécessaire (mise en réseau, etc.)
• Ne convient pas aux systèmes MCS ou PVS à clonage rapide groupé
• Ne convient pas à NetScaler VPX en raison de la mise en réseau (et il peut être nécessaire de le reconstruire à l’aide de sauvegardes de répertoires et de fichiers) nsconfigns.conf
• Il faut envisager d’étendre suffisamment le périmètre de conservation des sauvegardes pour faire face aux autres menaces modernes telles que les bombes à temps et les rançongiciels

Cas d’utilisation et hypothèses

Utile pour les organisations informatiques moins matures et les organisations dont le budget d’opérations informatiques est limité et peut permettre des pannes prolongées pour récupérer les services métiers principaux. Suppose que les sauvegardes et le processus de restauration sont testés régulièrement pour s’assurer que les sauvegardes sont correctes et que le processus de restauration est bien compris par ceux qui doivent le faire lors d’un événement réel.

Option de récupération - Restauration via la réplication

Cette option est similaire à l’option précédente mais utilise la réplication plutôt que la sauvegarde pour restaurer l’infrastructure. La réplication peut réduire certains aspects des tâches manuelles dans la séquence de restauration et potentiellement permettre de réduire le RTO (et donc de restaurer le service plus rapidement), mais elle reste tributaire de nombreuses tâches manuelles. Il convient de noter que la réplication ne remplace pas la sauvegarde. Les données corrompues ou compromises sont toujours répliquées vers la reprise après sinistre et ne sont donc pas utiles dans de tels scénarios. Les sauvegardes doivent toujours être considérées comme une solution de secours. À l’instar de l’option précédente, ce modèle n’est pas idéal pour les déploiements Citrix avancés. Il convient particulièrement aux infrastructures plus petites et plus simples ainsi qu’aux entreprises capables de résister à une période d’indisponibilité prolongée.

Avantages et inconvénients

Avantages :

• La réplication est probablement automatisée et s’aligne sur le RTO et les RPO
• Utilise probablement des technologies moins complexes par rapport aux solutions de récupération automatisées

Inconvénients :

• S’appuie sur une intervention administrative
• Documentation plus exhaustive et plus détaillée sur le plan de récupération (orchestration de reprise après sinistre)
• Un degré d’erreur humaine plus élevé si une reconfiguration manuelle est nécessaire (mise en réseau, etc.)
• Ne convient pas au Pooled, au Fast Clone MCS ou au PVS. La récréation des catalogues de machines est prise en compte dans le RTO projeté. Toutefois, en créant des catalogues de machines factices en DR ou en redimensionnant les instances de VDA en DR et en exécutant une action « Mettre à jour le catalogue » en appliquant une image principale répliquée, ce RTO peut être raccourci
• Ne convient pas à NetScaler VPX en raison de la mise en réseau et donc mieux adapté pour utiliser NetScaler en mode veille et en assumer le coût

Cas d’utilisation et hypothèses

Utile pour les organisations informatiques moins matures et les organisations dont les budgets d’exploitation informatique sont limités. Cette solution s’appuie sur les technologies de réplication du stockage du fournisseur du SAN ou du fournisseur de l’hyperviseur (vSphere Replication, Nutanix Replication, etc.) pour répliquer des machines virtuelles vers une autre installation via le WAN.

Option de récupération - Réplication avec récupération automatisée

Dans cette option, la restauration automatique est introduite pour plusieurs composants de la solution afin de restaurer l’infrastructure Citrix et ses dépendances sur le site de reprise après sinistre. Les technologies qui orchestrent la restauration automatique réduisent encore les étapes manuelles et minimisent l’intervention humaine (et les erreurs humaines potentielles), et peuvent encore améliorer le RTO en rationalisant le rétablissement du service. On s’attend à ce qu’une intervention soit toujours nécessaire pour basculer vers l’emplacement DR par le biais de modifications des enregistrements DNS. Il convient de noter que la réplication ne remplace pas la sauvegarde. Les données corrompues ou compromises sont toujours répliquées vers la reprise après sinistre et ne sont donc pas utiles dans de tels scénarios. Les sauvegardes doivent toujours être considérées comme une solution de secours. Bien que ce modèle soit plus mature, il n’est toujours pas adapté à une utilisation avec des configurations Citrix avancées ou aux entreprises qui ne tolèrent pas de longues interruptions de service.

Avantages et inconvénients

Avantages :

• Coûts de maintenance réduits par rapport aux solutions de secours à chaud
• La réplication est probablement automatisée et s’aligne sur RTO et RPO
• Les plans de reprise ont tendance à être automatisés
• Moins d’interventions administratives et d’erreurs humaines

Inconvénients :

• S’appuie sur des technologies plus avancées telles que VMware SRM, Veeam, Zerto, Nutanix Disaster Recovery Orchestration, XenServer Disaster Recovery et Azure Site Recovery (ASR) pour orchestrer la restauration et modifier les paramètres réseau (sauf si les segments du réseau sont étendus)
• Ne convient pas pour Pooled, Fast Clone MCS ou PVS. La récréation des catalogues de machines doit être prise en compte dans le RTO projeté. Toutefois, en créant des catalogues de machines factices en DR ou en redimensionnant les instances de VDA en DR et en exécutant une action « Mettre à jour le catalogue » en appliquant une image principale répliquée, ce RTO peut être raccourci
• Ne convient pas à NetScaler VPX en raison de la mise en réseau et est donc mieux adapté à l’utilisation de NetScaler en mode veille

Cas d’utilisation et hypothèses

Utile pour les entreprises disposant de ressources et d’un budget appropriés pour les installations de reprise après sinistre. Cette solution repose sur la même réplication du stockage que l’option précédente, mais inclut des technologies d’orchestration de reprise après sinistre pour restaurer les machines virtuelles dans un ordre particulier, ajuster les configurations des cartes réseau (si nécessaire), etc.

Option de récupération : veille à chaud (actif-passif) avec basculement manuel

Nous commençons maintenant à examiner les options qui utilisent une infrastructure de secours. Bien que cela soit plus coûteux, les avantages d’un modèle de veille à chaud conçu de manière appropriée réduisent considérablement le nombre d’étapes nécessaires pour orchestrer la restauration sur le site de reprise après sinistre, réduisent le risque d’erreurs technologiques et humaines, et permettent de réduire considérablement le temps de restauration. Ces modèles nécessitent la maintenance d’infrastructures Citrix indépendantes distinctes, ce qui augmente la charge de travail (maintenance et tests continus), mais s’adapte aux déploiements Citrix plus avancés qui utilisent des technologies de gestion d’image unique. Dans cette option, le basculement repose sur l’intervention de l’administrateur pour rediriger le trafic vers un autre emplacement par le biais de modifications du DNS, réduisant ainsi le coût et la complexité du basculement automatique du niveau d’accès. Cette option convient le mieux aux entreprises disposant d’un budget suffisant pour accueillir une infrastructure Citrix de secours, s’appuyant sur des configurations Citrix avancées et nécessitant un faible RTO mais une restauration contrôlée manuellement.

Avantages et inconvénients

Avantages :

• Temps de restauration court car la plateforme est « toujours active »
• Supporte le stockage et les composants dépendant du réseau tels que NetScaler, MCS, PVS
• Documentation sur le plan de reprise d’activité inférieur (orchestration DR)

Inconvénients :

• S’appuie sur une intervention administrative pour basculer l’URL ou demander aux utilisateurs de sauvegarder l’URL (bien que l’orchestration manuelle soit parfois intentionnelle)
• Coûts plus élevés en raison de la mise en veille du matériel « chaud » en DR
• Frais administratifs plus élevés pour synchroniser les configurations et les mises à jour de la plateforme de secours avec la production

Cas d’utilisation et hypothèses

Utile pour les entreprises disposant de ressources et d’un budget appropriés pour les installations de reprise après sinistre. Peut utiliser une plateforme « entièrement évolutive » ou une plateforme « évolutive à la demande » en mode « hot standby ». Ce dernier point peut être intéressant pour la restauration dans le cloud afin de réduire les coûts d’exploitation, avec certaines réserves.

Au moment du basculement, les administrateurs mettent à jour l’entrée **DNS** pour une ou plusieurs URL d’accès afin qu’elles pointent vers une ou plusieurs adresses IP de reprise après sinistre pour Citrix Gateway et StoreFront, ou les utilisateurs sont invités par communication officielle à commencer par une URL de « sauvegarde » ou de « DR ».

Cette option manuelle peut être utile pour les scénarios où les back-ends d’application peuvent nécessiter un temps de récupération plus long, mais créerait de la confusion pour les utilisateurs si Citrix était entièrement disponible et que les applications ne l’étaient pas.

Ce modèle suppose une organisation informatique mature et une infrastructure WAN et informatique suffisantes pour prendre en charge le basculement.

Option de récupération : veille à chaud (actif-passif) avec basculement automatique

À l’instar de l’option de veille à chaud précédente, cette option inclut un basculement automatique, généralement via des technologies DNS qui détectent les défaillances de production et redirigent le trafic vers le site de reprise après sinistre. La nature automatisée met davantage l’accent sur les équipes informatiques pour garantir que les configurations sont correctement maintenues en DR et que les dépendances des applications et des données restent accessibles depuis la DR pendant le fonctionnement normal afin d’éviter tout impact sur les utilisateurs qui pourraient se retrouver sur le site de reprise après sinistre à la suite d’une interruption de service temporaire isolée en cours de production. La gestion et la surveillance des capacités (garantir que la reprise après sinistre peut accueillir le même nombre d’utilisateurs sur Citrix que dans le cadre de la production) deviennent de plus en plus essentielles en raison de la fonctionnalité de basculement automatique. Cette option convient le mieux aux entreprises disposant d’un budget suffisant pour accueillir une infrastructure Citrix de secours, s’appuyant sur des configurations Citrix avancées et nécessitant un RTO proche de zéro.

Avantages et inconvénients

Avantages :

• Temps de restauration court car la plateforme est « toujours active »
• Supporte le stockage et les composants dépendant du réseau tels que NetScaler, MCS, PVS
• Documentation relative au plan de récupération minimal (orchestration de reprise après sinistre)
• Plus facile pour les utilisateurs finaux grâce au basculement des URL
• Prend en charge les scans EPA sur Citrix Gateway avec GSLB

Inconvénients :

• Coûts plus élevés en raison de la mise en veille du matériel « chaud » en phase de reprise après sinistre et des licences NetScaler. La charge financière peut être réduite dans une certaine mesure si la capacité de réserve est utilisée par le développement ou d’autres charges de travail non liées à la production moins critiques, qui peuvent être mises hors tension lors d’un événement de reprise après sinistre afin de donner la priorité à la reprise de la production
• Plus grande complexité du niveau d’accès
• Frais administratifs plus élevés pour synchroniser les configurations et les mises à jour de la plateforme de secours avec la production

Cas d’utilisation et hypothèses

Configuration courante dans les entreprises qui permet un basculement automatique vers le site de reprise après sinistre via NetScaler GSLB (version avancée ou supérieure requise). Ce modèle suppose une organisation informatique mature et une infrastructure WAN et informatique suffisantes pour prendre en charge le basculement. Ce modèle suppose également que les dépendances entre les applications et les données utilisateur correspondent aux dernières versions/mises à jour actives du site et qu’elles sont récupérables sur le site de reprise après sinistre de manière tout aussi automatisée afin de réduire l’impact prolongé du service sur l’utilisateur final et la confusion due à une fonctionnalité partielle de la solution.

Option de récupération — Actif actif avec basculement automatique

Cette option s’appuie sur la première, mais pendant le fonctionnement normal, les sites de production et de reprise après sinistre sont utilisés activement. La capacité peut être gérée et surveillée étroitement, car dans un tel modèle, il est plus facile de passer inaperçue lorsque l’un des sites dépasse un seuil (disons 40 à 45 % d’utilisation) afin de garantir que l’un ou l’autre site peut accueillir l’ensemble des utilisateurs lors d’un événement de reprise après sinistre. Comme les deux environnements sont utilisés activement, la validation de routine de la plupart des composants est intégrée. Toutefois, les composants susceptibles de nécessiter un basculement vers l’emplacement de reprise après sinistre (applications, baies de stockage, etc.) doivent tout de même être soumis à des tests de basculement périodiques de routine. Comme le modèle utilise deux emplacements actifs ou plus, il faut tenir compte des tolérances de performance et des écarts entre les sites, en particulier si les sites s’étendent sur des distances géographiques importantes. Certains écarts de performances peuvent être minimisés dans ce modèle en redirigent les utilisateurs vers un emplacement plutôt qu’un autre (localisation des VDA) pendant le fonctionnement normal et en basculant vers d’autres VDA si leur emplacement local n’est pas disponible. Ce modèle est le plus complexe, le plus robuste et il s’adapte aux déploiements Citrix les plus avancés. Il est idéal pour les entreprises qui ont besoin d’un RTO nul et qui souhaitent un modèle permettant à seulement 50 % des utilisateurs de basculer lors d’un événement de reprise après sinistre, contre 100 %.

Avantages et inconvénients

Avantages :

• Temps de restauration court car la plateforme est « toujours active »
• Supporte le stockage et les composants dépendant du réseau tels que NetScaler, MCS, PVS
• Documentation relative au plan de récupération minimal (orchestration de reprise après sinistre)
• Transparente pour les utilisateurs finaux
• Prend en charge les scans EPA sur Citrix Gateway avec GSLB (les versions du microprogramme NetScaler 13.0+ publiées à partir de 2022 peuvent prendre en charge les scans EPA dans les configurations GSLB active-active, auparavant fonctionnelles uniquement dans les configurations active-passive)

Inconvénients :

• Coûts plus élevés en raison de la mise en veille du matériel « chaud » en phase de reprise après sinistre et des licences NetScaler. La charge financière peut être réduite dans une certaine mesure si la capacité de réserve est utilisée par le développement ou d’autres charges de travail non liées à la production moins critiques, qui peuvent être mises hors tension lors d’un événement de reprise après sinistre afin de donner la priorité à la reprise de la production
• Niveau d’accès le plus complexe
• Frais administratifs plus élevés pour synchroniser les configurations et les mises à jour de la plateforme de secours avec la production
• S’appuie sur les administrateurs pour surveiller et ajuster les ressources et la capacité matérielle de tous les centres de données afin de garantir que l’intégrité de la capacité de reprise après sinistre ne soit pas affectée au fur et à mesure de la croissance de la plate-forme

Cas d’utilisation et hypothèses

Configuration plus avancée mais courante dans les entreprises, qui permet aux URL de niveau d’accès de fonctionner de manière active-active via NetScaler GSLB (NetScaler Advanced ou supérieur est nécessaire). Cette fonctionnalité est utile dans les environnements où les centres de données locaux sont proches les uns des autres, ou dans les situations où les centres de données peuvent être distants, mais avec les moyens d’épingler les utilisateurs aux centres de données préférés (souvent pilotés par des configurations avancées StoreFront et GSLB dans une moindre mesure) pour des scénarios multi-sites.

Ce modèle suppose une organisation informatique mature et une infrastructure WAN et informatique suffisantes pour prendre en charge le basculement. Ce modèle suppose également que les dépendances des données des applications et des utilisateurs sont alignées sur les dernières versions/mises à jour du site et qu’elles peuvent être récupérées au site de reprise après sinistre d’une manière automatisée de manière similaire afin de réduire l’impact prolongé du service pour l’utilisateur final et la confusion due à la fonctionnalité partielle de la solution.

Reprise après sinistre dans le cloud public

La reprise après sinistre impliquant des plates-formes sur site vers le cloud ou du cloud vers le cloud s’accompagne d’un ensemble de défis ou de considérations qui souvent ne se présentent pas dans des scénarios de reprise sur site.

Les principales considérations suivantes peuvent être prises en compte lors de la planification de la conception de la reprise après sinistre afin d’éviter les erreurs susceptibles de rendre le plan de reprise après sinistre appliquant l’infrastructure cloud invalide, prohibitif ou incapable d’atteindre la capacité cible en cas de reprise après sinistre

Prise en compte — Débit réseau

Domaines d’impact

Coût des performances de disponibilité

Détails

Les entreprises peuvent sous-estimer et donc sous-dimensionner les points de jonction de débit de leurs solutions cloud, notamment les pare-feux virtuels, les passerelles VPN et les liaisons montantes WAN (AWS Direct Connect, Azure Express Route, GCP Cloud Interconnect, etc.), ce qui peut avoir un effet délétère significatif sur les performances si la plateforme Citrix doit récupérer dans le cloud et être accessible via le WAN. Tenez également compte des limites de la passerelle VPN si vous l’utilisez avec un fournisseur de cloud. Par exemple, les passerelles de transit AWS ont actuellement une limite maximale de 1,25Gbit/s. Cette limite peut nécessiter l’extension des passerelles ou peut-être l’utilisation de plusieurs VPC si ceux-ci sont essentiels à l’architecture cloud. Les passerelles VPN Azure et GCP peuvent avoir des limites plus élevées. De nombreux pare-feux virtuels ont des limites sous licence quant au débit qu’ils peuvent traiter ou des maximums même à leur limite la plus élevée. Cette contrainte peut nécessiter d’augmenter le nombre de pare-feux et d’équilibrer leur charge d’une manière ou d’une autre.

Recommandations

Lors de l’établissement des calculs de dimensionnement du débit, supposons la pleine charge de capacité DR Capturez les données suivantes par utilisateur simultané :

• Bande passante estimée des sessions ICA
• Bande passante de communication des applications estimée par session si elles franchissent les limites de sécurité
• Bande passante estimée pour les services de fichiers par session s’ils franchissent les limites de sécurité

Pour les mesures précédentes, il peut être utile de recueillir des données sur les modèles de trafic actuels à destination et en provenance des VDA en production. Il est également important de considérer quels autres flux de données non liés à Citrix devraient également utiliser ces chemins réseau. Assurez-vous de faire participer les équipes réseau et de sécurité à la planification de Citrix DR afin de vous assurer que toutes les estimations de bande passante traversant les zones de sécurité et les segments du réseau sont comprises et peuvent être prises en compte.

Considération — Services d’authentification

Domaines d’impact

Disponibilité, performance et sécurité

Détails

Les services d’authentification sont essentiels au fonctionnement des plateformes Citrix. La plupart continuent de s’appuyer sur Microsoft Active Directory Domain Services (AD DS). Si vous utilisez le Citrix Federated Authentication Service (FAS), les autorités de certification Microsoft (CA) ou les autorités de certification tierces prises en charge sont également essentielles au fonctionnement continu de la plateforme. Autrement dit, s’ils sont en panne, Citrix est en panne.

Certaines entreprises continuent de résister à l’idée de placer leur infrastructure de services d’authentification dans des clouds publics, invoquant souvent des problèmes de sécurité. Par conséquent, les performances d’authentification et de courtage sont entravées lors du rétroacheminement vers des contrôleurs de domaine (DC) sur site inscriptibles pendant le fonctionnement normal, et la disponibilité et l’accessibilité des contrôleurs de domaine et des CA dans un scénario de reprise après sinistre peuvent être négligées.

Recommandations

Mettez en œuvre des contrôles compensatoires suffisants pour répondre aux préoccupations de l’équipe de sécurité et placez des contrôleurs de domaine et des CA inscriptibles (si vous utilisez le FAS) à proximité de l’infrastructure Citrix dans le cloud. Si ce n’est pas négociable, assurez-vous que la restauration est planifiée et que l’accessibilité est validée pour ces serveurs en cas de défaillance ou d’inaccessibilité du centre de données de production.

Prise en compte — Licences de systèmes d’exploitation Windows Desktop

Domaines d’impact

Coût

Détails

Il existe des considérations de licence potentiellement complexes pour les instances de système d’exploitation de bureau Microsoft s’exécutant sur différentes plates-formes cloud. Microsoft a révisé ses droits de licence cloud en août 2019, ce qui peut avoir une incidence sur les coûts de VDI dans certains scénarios de déploiement. Les licences Microsoft pour les applications Office 365/Microsoft 365 ont également évolué en ce qui concerne le support sur les clouds publics et les types de systèmes d’exploitation.

Recommandations

L’octroi de licences pour les produits Microsoft est une question en constante évolution. Consultez Microsoft et le fournisseur de cloud (le cas échéant) pour obtenir les informations actuelles sur les déclarations de licence et de prise en charge lors de la détermination de l’architecture du cas d’utilisation. Si le VDI présente un défi financier potentiel dans la solution de reprise après sinistre, envisagez de le compléter par des bureaux partagés hébergés (une augmentation du nombre de CAL RDS peut être nécessaire), si possible, car ils peuvent offrir une plus grande flexibilité à un moindre coût d’exploitation. Les restrictions ou les modifications futures du support peuvent nécessiter une réévaluation complète de la plate-forme utilisée pour la reprise après sinistre.

Prise en considération — Moment de la mise à l’échelle VDA (avant ou pendant la reprise après sinistre)

Domaines d’impact

Disponibilité des coûts

Détails

Les entreprises sont attirées par le cloud car elles sont attirées par le fait de ne payer pour des capacités que lorsqu’elles en ont besoin. Cette solution peut réduire considérablement les coûts de reprise après sinistre en ne payant pas l’infrastructure réservée, qu’elle soit utilisée ou non.

Cependant, à grande échelle, un fournisseur de cloud ne peut pas s’engager à respecter un contrat de niveau de service consistant à activer des centaines ou des milliers de machines virtuelles à la fois. Cette solution devient particulièrement difficile si l’on prévoit que l’encombrement du VDA pour la reprise après sinistre se chiffrera à des centaines ou à des milliers d’instances. Les fournisseurs de cloud ont tendance à maintenir une capacité globale pour différentes tailles d’instances disponibles ; toutefois, ce fournisseur peut varier d’un moment à l’autre. En cas de sinistre affectant une zone géographique, les autres locataires qui demandent également une capacité à la demande peuvent être très contestés.

Dans le cas d’Azure, ne confondez pas les instances réservées avec les capacités réservées (à la demande). Si vous choisissez des instances réservées pour vous protéger contre la disponibilité des ressources dans une région de reprise après sinistre à la demande, il serait prudent de les déployer car Microsoft ne garantit pas la disponibilité de la capacité à la demande. Avec la capacité à la demande, Microsoft met purement et simplement de côté de la capacité (à des tarifs payants à l’utilisation). En fin de compte, il serait prudent de partir du principe que seuls les VDA en cours d’exécution sont garantis.

Questions clés auxquelles il faut répondre et qui peuvent influencer les décisions :

• La capacité de reprise après sinistre de 100% est-elle toujours requise ?
• Quels sont les types de catastrophes planifiés ? S’il s’agit d’une catastrophe régionale, serait-il judicieux d’utiliser une seule région cloud ou une région cloud proche de la zone de production ?
• Est-ce que nous hébergeons uniquement les charges de travail critiques (c’est-à-dire uniquement un sous-ensemble de la production) ?
• Est-il viable de l’étendre au moment de la reprise du sinistre ? Dans l’affirmative, les cas d’utilisation ont-ils été priorisés par les niveaux de reprise après sinistre afin de mieux comprendre les différents RTO de chaque cas d’utilisation afin de prendre en charge une élimination progressive de la capacité ?
• Pouvons-nous faire évoluer les instances du système d’exploitation prenant en charge les cas d’utilisation d’applications ou de bureaux partagés hébergés afin de gagner du temps sur le provisionnement et de mettre ces instances hors tension afin de réduire

Recommandations

Citrix recommande d’abord de contacter votre fournisseur de cloud pour déterminer la viabilité de la mise sous tension de la capacité prévue dans le délai de RTO et si elle peut être satisfaite avec des instances à la demande ou non. Pour se prémunir contre les limitations de disponibilité de capacité pour les VDA dans un scénario de reprise après sinistre, Citrix recommande de Provisioning des VDA dans le plus grand nombre possible de zones de disponibilité.

À grande échelle, il peut s’avérer utile de provisionner diverses régions de cloud et d’ajuster l’architecture en conséquence. Certains fournisseurs de cloud ont suggéré d’utiliser différentes tailles de types d’instance de machines virtuelles pour atténuer davantage l’épuisement des machines virtuelles.

Certaines entreprises peuvent souhaiter diversifier les risques liés aux fournisseurs et adopter un déploiement multicloud dans lequel les cas d’utilisation sont répartis entre deux fournisseurs de cloud différents afin de se prémunir contre la défaillance complète d’une plateforme cloud (DNS, routage, violation, etc.). Ce scénario augmente la complexité et peut ne pas garantir la parité des performances ou des fonctionnalités entre les clouds, mais ces réserves potentiellement mineures peuvent être éclipsées par la valeur perçue de la diversification des plateformes. Dans la mesure du possible, il serait prudent de pré-approvisionner les instances VDA et de les mettre à jour régulièrement (leur maintien en ligne ou hors ligne serait laissé à la discrétion du client et à sa tolérance au risque). Le provisionnement est un processus chronophage et en ressources, et l’extension de la capacité de reprise après sinistre des VDA à la demande peut être accélérée dans une certaine mesure grâce au préprovisionnement.

Si l’organisation a peu d’appétit pour le risque de disponibilité de la capacité, elle peut exiger l’application d’une capacité de calcul réservée ou dédiée et la budgétisation en conséquence pour garantir la disponibilité des ressources. Il est possible de combiner des modèles à la demande et des modèles réservés/dédiés en faisant référence au niveau de reprise après sinistre, dans lequel certains cas d’utilisation peuvent nécessiter la disponibilité immédiate des VDA, tandis que d’autres peuvent bénéficier de la flexibilité nécessaire pour être restaurés sur un RTO plus long de plusieurs jours ou semaines s’ils sont moins essentiels au maintien de l’activité.

Considération — Données de l’application et de l’utilisateur

Domaines d’impact

Performances de disponibilité

Détails

L’emplacement des données utilisateur et des back-ends des applications peut avoir un impact notable sur les performances et parfois sur la disponibilité de l’environnement Citrix DR. Certains scénarios clients utilisent une approche de reprise après sinistre multi-centres de données, dans laquelle tous les back-ends d’applications ou les données utilisateur, telles que les disques personnels et départementaux, ne peuvent pas être restaurés dans le cloud avec Citrix. Cette lacune peut entraîner une latence imprévue qui peut avoir un impact sur les performances ou même la fonctionnalité des applications. Du point de vue du débit, cet écart peut alourdir la bande passante disponible sur le réseau et les dispositifs de sécurité.

Recommandations

Dans la mesure du possible, conservez les données d’application et d’utilisateur locales sur la plate-forme Citrix en reprise après sinistre pour maintenir les performances les plus optimales possible en réduisant la latence et la demande de bande passante sur le réseau étendu. Déterminez ce qui doit réellement être récupérable en DR (les conteneurs de bureau FSLogix peuvent ne pas être critiques, et certains cas d’utilisation peuvent fonctionner correctement avec la création d’un nouveau profil) et assurez-vous que les packages d’applications et les conteneurs sont disponibles sur le site de reprise après sinistre. Il est essentiel de déterminer la solution de réplication la plus appropriée et la plus rentable. Ce sujet est abordé plus loin dans ce guide.

Planification de la reprise après sinistre pour Citrix Cloud

Il existe plusieurs différences notables entre le déploiement sur site ou « traditionnel » de Citrix Virtual Apps and Desktops et le déploiement Citrix DaaS fourni par Citrix Cloud en ce qui concerne la planification de la reprise après sinistre :

• Citrix gère la plupart des composants de contrôle pour le partenaire/client, supprimant les exigences importantes de reprise après sinistre pour le site Citrix et ses composants de sa responsabilité.
• Le déploiement d’un environnement de reprise après sinistre pour les ressources Citrix nécessite simplement que le client déploie des Citrix Cloud Connectors dans l’ « emplacement des ressources » de restauration, et éventuellement StoreFront et NetScaler (pour Citrix Gateway).
• L’architecture de service unique de Citrix Cloud est géographiquement redondante et résiliente de par sa conception.
• La reprise après sinistre au niveau d’accès n’est pas requise si vous utilisez les services Citrix Workspace et NetScaler Gateway.

Au-delà de ces différences fondamentales, bon nombre des considérations de reprise après sinistre des sections précédentes nécessitent toujours une planification partenaire/client, car elles conservent la responsabilité des VDA Citrix, des données utilisateur, des back-end des applications et du niveau d’accès Citrix si NetScaler Gateway Service et le service Citrix Workspace ne sont pas utilisés à partir de Citrix Cloud.

Cette section couvre des sujets clés destinés à aider les entreprises à définir une stratégie de reprise après sinistre appropriée pour Citrix Cloud.

Citrix DaaS simplifie la reprise après sinistre

Voici un schéma conceptuel typique décrivant l’architecture conceptuelle de Citrix DaaS, en plus de la séparation des responsabilités entre les composants gérés par Citrix et les composants gérés par les partenaires/clients. Les « services » WEM, Analytics et NetScaler Gateway ne sont pas illustrés ici, qui sont des composants Citrix Cloud facultatifs liés à Citrix DaaS qui relèveraient de « Managed by Citrix ».

Comme l’illustre le diagramme, une partie importante des composants Control nécessitant des décisions de restauration relèvent du périmètre de gestion de Citrix. En tant que service basé sur le cloud, l’architecture Citrix DaaS est hautement résiliente au sein de la région Citrix Cloud. Il fait partie de la « sauce secrète » de Citrix Cloud et est pris en compte dans les SLA de Citrix Cloud.

Les responsabilités de gestion de la disponibilité des services sont les suivantes :

• Citrix. Plan de contrôle et « services » d’accès en cas d’utilisation (Citrix Workspace, Citrix Gateway Service).
• Client. Les composants de localisation des ressources, notamment les connecteurs cloud, les VDA, les back-ends d’applications, les dépendances de l’infrastructure (AD, DNS, etc.) et le niveau d’accès (StoreFront, NetScaler) si vous n’utilisez pas le niveau d’accès Citrix Cloud.

Les entreprises bénéficient des avantages suivants en matière de reprise après sinistre sur Citrix DaaS :

• Moins de charge administrative grâce à un nombre réduit de composants à gérer et à réduire les configurations indépendantes à répliquer et à maintenir entre les emplacements.
• Réduction des risques d’erreur humaine et des écarts de configuration entre les déploiements Citrix en raison de la configuration centralisée du « Site Citrix » dans le Cloud.
• Rationalisation des opérations grâce à la simplification de la gestion des ressources pour les déploiements de production et de reprise après sinistre grâce à un nombre réduit de sites Citrix et de composants à configurer et à maintenir, à l’absence de niveau d’accès à gérer entre les emplacements (facultatif) et à une logique de reprise après sinistre moins complexe pour les ressources Citrix.
• Réduction des coûts opérationnels grâce à un nombre réduit de composants serveur pour déployer et maintenir et obtenir une vue d’ensemble unique des tendances de l’environnement dans les déploiements grâce à la centralisation de la base de données de surveillance.

Considérations relatives à Citrix DaaS reprise d’activité après sinistre

Bien que de nombreux composants de la planification de la reprise soient retirés du champ de gestion de l’organisation, les organisations restent responsables de la planification et de la gestion de la reprise après sinistre et de la haute disponibilité (en option) pour les composants situés dans l’emplacement des ressources.

La différence la plus importante dans la façon dont nous traitons la disponibilité réside dans la façon dont nous interprétons et configurons les emplacements de ressources. Dans Citrix DaaS lui-même, les emplacements de ressources sont présentés sous forme de zones. Grâce à la préférence de zone, nous pouvons gérer le basculement entre les emplacements de ressources en fonction de la logique que nous spécifions. L’utilisation de la préférence de zone dans un site Citrix Virtual Apps and Desktops déployé de manière traditionnelle serait considérée comme une conception de haute disponibilité, mais pas comme une conception de reprise après sinistre valide. Dans le contexte de Citrix Cloud, cette option est une solution de reprise après sinistre valide.

La plupart des options de reprise après sinistre décrites précédemment s’appliquent à Citrix DaaS. Il existe donc de nombreuses options pour répondre aux objectifs et aux budgets de reprise d’activité de l’entreprise.

Lors de la planification de la reprise après sinistre pour le service Citrix DaaS de Citrix Cloud, plusieurs principes directeurs clés du point de vue de la planification de l’infrastructure doivent être compris :

• Emplacements des ressources. Les emplacements de production et de reprise après sinistre sont configurés en tant que emplacements de ressources indépendants dans Citrix Cloud.
• Connecteurs de cloud. Chaque emplacement de ressource doit avoir au moins deux Cloud Connector déployés. Pour plus de clarté, les Cloud Connectors ne sont pas un composant qui doit être « restauré » manuellement ou automatiquement lors d’un événement de reprise après sinistre. Ils doivent être considérés comme des composants « en veille » et doivent être maintenus en ligne à tout moment sur chaque site.
• Contrôleurs d’accès gérés par le client (facultatif). Les entreprises peuvent choisir de déployer leur propre NetScaler pour les serveurs Citrix Gateway et StoreFront et de ne pas utiliser Citrix Workspace ou Citrix Gateway Service pour plusieurs raisons. Ceux-ci peuvent inclure :
  • Flux d’authentification personnalisés
  • Amélioration des capacités de marque
  • Meilleure flexibilité du routage du trafic HDX
  • Meilleure connaissance des performances du réseau HDX (HDX Insight)
  • Audit des connexions ICA et intégration dans les plates-formes SIEM
  • Possibilité de continuer à fonctionner si la connexion du Cloud Connector à Citrix Cloud est interrompue, à l’aide de la fonction Local Host Cache des Cloud Connector avec StoreFront

  Comme pour les Cloud Connector, il est recommandé de maintenir les composants StoreFront et NetScaler Gateway déployés en « veille à chaud » dans l’emplacement de récupération et de ne pas les récupérer pendant un événement de reprise après sinistre.

Considérations relatives à l’exploitation

La maintenance de la plate-forme de reprise après sinistre est essentielle pour maintenir son intégrité afin d’éviter les problèmes imprévus lorsque la plate-forme est nécessaire. Les directives suivantes sont recommandées concernant l’exploitation et la maintenance de l’environnement DR Citrix :

• La plate-forme Citrix DR n’est pas non-Prod. Les entreprises dotées d’un environnement « en veille prolongée » peuvent être tentées de réduire les coûts et de considérer la reprise après sinistre comme une plate-forme de test. Ce traitement affecte négativement l’intégrité de la solution. En fait, DR serait probablement la dernière plateforme à promouvoir des modifications, afin de garantir que son utilité ne soit pas affectée en cas de panne catastrophique, ce qui n’est pas le cas dans des environnements autres que la production.
• Application de correctifs et maintenance. La maintenance de routine en parallèle avec la production lors de l’utilisation de plateformes Citrix « hot standby » est essentielle au maintien d’une plate-forme de reprise après sinistre fonctionnelle. Il est important de synchroniser la DR avec la production en ce qui concerne le système d’exploitation, les produits Citrix et les correctifs d’applications. Pour atténuer les risques, il est suggéré de prévoir plusieurs jours à une semaine entre la production de correctifs et la reprise après correction des correctifs.
• Essais périodiques. Que la reprise après sinistre implique la réplication de la production vers une installation de restauration ou l’utilisation d’environnements « en veille prolongée », il est important de tester régulièrement (idéalement une ou deux fois par an) le plan de reprise après sinistre afin de s’assurer que les équipes connaissent bien les processus de restauration et que toute faille de la plate-forme ou des flux de travail est identifiée et corrigée. C’est la pratique qui rend parfait. Un plan peut fonctionner sur le papier, mais les tests peuvent révéler que les attentes en matière de RTO et de RPO sont irréalisables, qu’un ordre des opérations doit être ajusté ou qu’un oubli doit être pris en compte. Par exemple, le temps réel nécessaire à la synchronisation et au basculement du stockage peut entraîner une perte de données inattendue, nécessitant un ajustement en fonction des attentes ou de la configuration de réplication.
• Gestion des capacités. True pour les environnements Citrix Active-Passif et Active-Active « toujours sur » Citrix, les changements de capacité ou de cas d’utilisation dans la production doivent également être pris en compte pour la reprise après sinistre. En particulier lorsque des modèles Active-Active sont utilisés, il est facile pour l’utilisation des ressources d’augmenter au-delà d’un seuil d’utilisation des ressources à l’état stable de 50 % dans chaque environnement, uniquement pour qu’un événement de reprise après sinistre se produise et que la plate-forme survivante devient dépassée et fonctionne mal ou échoue en raison de la surcharge. La capacité peut être revue mensuellement ou trimestriellement.

Considérations relatives à la récupération des

Dans cette section, nous aborderons brièvement plusieurs concepts et considérations liés à la gestion des profils utilisateur, des images VDA et des applications (App-V, App Layers, MSIX, etc.) dans des scénarios multi-sites et DR.

Réplication ou sauvegarde

Les deux fonctions de disponibilité et d’intégrité des données sont des facteurs importants lorsqu’il s’agit de récupérer des ensembles de données critiques tels que l’infrastructure de base, les images, les données utilisateur et les applications. Alors que les fonctionnalités de réplication généralement proposées dans les solutions de cloud public fournissent des mécanismes pratiques pour garantir la résilience des données critiques, la réplication ne résout pas le problème de corruption des données ni les scénarios de reprise après sinistre dans lesquels même les données répliquées ont été compromises. La réplication ne remplace pas les sauvegardes et, lorsque cela est financièrement possible, les deux doivent être utilisées. La réplication peut contribuer à la restauration rapide des données, tandis que les sauvegardes peuvent aider à rétablir les données en cas de perte ou de corruption (dans la mesure dictée par la politique de conservation et l’intervalle de sauvegarde). Que ce soit sur site ou dans le cloud, de nombreuses options de sauvegarde sont disponibles.

À ce propos, il est prudent d’examiner attentivement les politiques de conservation des sauvegardes dans le paysage actuel de la cybersécurité, étant donné que les attaques de ransomware utilisent désormais le « bombardement à temps » qui consiste à compromettre des ensembles de données mais semblent normaux alors que le ransomware reste inactif jusqu’à une date précise. En jouant sur le « long terme », les cybercriminels peuvent rendre inutiles les sauvegardes dont la durée de conservation est plus courte lors de la restauration. L’allongement des périodes de conservation peut augmenter les coûts mais peut améliorer la probabilité de récupérer des données critiques.

Que puis-je récupérer ? Classification de la criticité des données

Bien que cet article ait principalement porté sur les options de disponibilité et de restauration de l’infrastructure Citrix, il convient également de tenir compte de la disponibilité de différents ensembles de données afin d’aligner les attentes de l’entreprise sur les coûts. Par exemple, si les profils utilisateur ne sont pas disponibles sur le site de reprise après sinistre, cela constituera-t-il simplement un inconvénient ou un obstacle important aux activités commerciales ? La réponse à cette question aura un impact direct sur la complexité et les coûts des composants de l’infrastructure. Voici une liste de considérations relatives aux données courantes associées à une plate-forme Citrix :

• Profils d’utilisateurs. Inclut les profils ou conteneurs Citrix Profile Management (CPM), les couches utilisateur ou les conteneurs FSLogix. Les entreprises doivent déterminer si elles doivent être restaurées dans le cadre de la reprise après sinistre, ainsi que leurs RTO et RPO. Dans certains cas d’utilisation, la restauration de profils dans DR peut ne pas être rentable si la création de nouveaux profils n’est qu’un inconvénient et que la configuration de nouveaux profils en DR prend 10 à 15 minutes de charge supplémentaire pour les utilisateurs Pour les autres cas d’utilisation, il se peut que cela ne soit pas négociable. Les conteneurs Office ne valent peut-être pas la peine d’être répliqués, car ce sont des caches de données en ligne. Cette différenciation au sein de la discussion sur le profil utilisateur/les données utilisateur peut permettre de réduire les coûts de stockage et de réplication en choisissant de ne pas répliquer ces conteneurs (et plaide en faveur de la séparation des conteneurs de profil FSLogix des conteneurs Office).
• Images/couches. Dans la plupart des cas, il n’y a pas vraiment de décision à prendre quant à la restauration des images (images principales, vDisks PVS, couches App Layering) mais à la manière dont elles doivent être restaurées. Sont-ils répliqués automatiquement ? Ou sont-ils maintenus indépendamment de la production et de la reprise après sinistre ?
• Applications. Nous faisons ici spécifiquement référence aux applications conteneurisées (couches élastiques, MSIX, App-V). Comme pour les images, la décision a tendance à porter davantage sur « comment » nous récupérons que sur « si ».

Options de réplication

Que ce soit dans un cloud public ou sur site, plusieurs technologies de réplication sont disponibles. Cette section couvre de nombreuses options courantes mais n’est pas exhaustive. Notez que dans de nombreux scénarios où la réplication est utilisée, la perte de données est inévitable dans une certaine mesure, sauf si l’emplacement de reprise après sinistre autorise la réplication synchrone. Dans le cas contraire, les options de restauration tiennent généralement compte du RPO, le plus faible étant souvent de 15 minutes (selon la plate-forme, l’outil ou le scénario). Plus l’intervalle de réplication est fréquent, plus le coût est généralement élevé.

Les profils utilisateur (sous toutes leurs formes), les couches utilisateur, les applications et les images peuvent résister à une journée de perte de données pour de nombreuses entreprises, réduisant ainsi le trafic intersite et la consommation de bande passante. Dans certains cas d’utilisation, la perte de données du profil utilisateur peut être sans conséquence pour l’entreprise dans le contexte de la reprise après sinistre et des coûts de réplication. Quelle que soit l’option choisie, le service informatique et l’entreprise doivent être conscients des attentes en termes de perte de données potentielle lors d’un événement de reprise après sinistre imprévu. Les événements de reprise après sinistre planifiés peuvent permettre d’effectuer une réplication complète des données avant le basculement.

Dans les clouds publics, les solutions de services de fichiers natifs telles qu’Azure NetApp Files, Azure Files et AWS FSx sont courantes pour le stockage des données utilisateur et disposent souvent de fonctionnalités de réplication intégrées au sein d’une région ou vers d’autres régions. Si vous planifiez la production et la reprise après sinistre au sein d’une plateforme cloud et que vous répliquez des données vers d’autres régions, soyez attentif, lors de la sélection des régions à utiliser, à la nature de leurs paires de régions, afin de vous assurer que les données peuvent être répliquées dans la région de votre choix. Azure gère iciune liste de paires de régions à réplication croisée. Azure NetApp Files propose également sa propre liste de paires de régions à réplication croisée ici. En cas de déploiement dans des régions qui ne sont pas couplées dans Azure, les données peuvent être restaurées dans une région susceptible de générer plus de latence pour vos VDA.

Dans certains cas, cela peut être surmonté en ne s’appuyant pas sur de telles technologies et en utilisant des fonctionnalités de réplication au niveau de l’application, telles que FSLogix (le cas échéant) Cloud Cache par exemple. AWS FSx, en revanche, ne limite pas la réplication via des paires de régions, offrant ainsi un plus grand choix. Soyez conscient des options de réplication dans le cloud qui ne permettent pas de conserver les connexions SMB. Azure, par exemple, si vous utilisez le stockage géo-redondant (GRS), ne conservera pas les identifiants ou les baux des PME, ce qui peut avoir un impact sur les utilisateurs en fonction du scénario d’échec et nécessiter une déconnexion/une déconnexion pour remonter les partages concernés pour les applications, les couches ou les profils.

Les options tierces, notamment NetApp Cloud Volumes OnTap (CVO), sont également disponibles sur les principaux clouds publics (y compris GCP) et sont populaires auprès des entreprises expérimentées avec NetApp et qui souhaitent bénéficier d’une expérience de gestion et de fonctionnalités similaire dans les clouds.

Comme dans le cas d’Azure GRS, sachez que de nombreuses technologies impliquant la restauration du partage de fichiers entre des centres de données ou des régions de cloud public ne permettent pas de conserver les connexions SMB. Cela peut obliger les utilisateurs à se déconnecter et à se reconnecter en cas de basculement pour remonter les partages de fichiers pour les technologies qui ne réessayent pas automatiquement d’y accéder et peuvent également nécessiter une restauration manuelle du partage/du volume. Cela peut ne pas être perceptible dans un scénario de reprise après sinistre complet dans lequel les utilisateurs se connectent à un VDA complètement différent de celui de production pour retrouver leur productivité.

Sur site, Citrix Professional Services recommande depuis longtemps aux entreprises d’utiliser des plateformes de fichiers natives (c’est-à-dire des services de fichiers réseau IP fournis par des périphériques SAN ou NAS) lorsqu’elles sont disponibles, en raison de leurs ensembles de fonctionnalités robustes et de leur faible surcharge perçue par rapport aux solutions de serveur de fichiers basées sur Windows. Cela est particulièrement important lors de la planification des fonctions de réplication du stockage pour un site de reprise après sinistre.

Si les solutions de gestion des fichiers matériel/matériel ne sont pas disponibles, les solutions Windows constituent une solution de rechange (assurez-vous qu’elles sont adaptées conformément aux directives de Microsoft et dûment sauvegardées). Diverses options sont disponibles, mais elles sont susceptibles d’être plus limitées en termes de performances et d’évolutivité des capacités que les solutions intégrées :

• Serveur de fichiers autonome. Un serveur de fichiers Windows de base pour héberger les données Citrix, y compris les conteneurs de profils et d’applications, les profils utilisateur, la redirection de dossiers Microsoft, etc., à condition que l’environnement ne fonctionne pas 24 heures sur 24, 7 jours sur 7 et puisse résister aux pannes.
  • Avantages : Simple à configurer et à entretenir
  • Inconvénients : aucune haute disponibilité, aucune capacité de réplication, sauf en cas de superposition à une autre technologie telle que DFS-R, Storage Replica ou VMware Site Recovery Manager (SRM), Veeam, robocopy, etc. Les redémarrages (planifiés ou imprévus) interrompront les profils utilisateurs, les données utilisateur (telles que les disques domestiques et la redirection de dossiers Microsoft), les packages d’applications montés, l’accès au vDisk (susceptible de provoquer le crash des cibles PVS)
• Cluster de fichiers Windows. Il s’agit d’une technologie de base dans les environnements Windows qui repose sur le clustering Windows Failover. Conçu pour créer une haute disponibilité pour les partages de fichiers au sein d’un centre de données local.
  • Avantages : solution robuste et mature, idéale pour répondre aux besoins de données Citrix pour différents types de profils et de conteneurs, permet le basculement entre les nœuds sans interrompre les sessions SMB des clients
  • Inconvénients : Il ne s’agit pas d’une solution de reprise après sinistre, mais plutôt d’une solution HA. Cela peut s’avérer plus complexe à configurer et à gérer en fonction de l’architecture de stockage partagé utilisée. Ce n’est pas idéal pour les centres de données répartis sur plusieurs centres de données, sauf si la restauration est effectuée à l’aide d’un outil d’orchestration de restauration au niveau des machines virtuelles tel que VMware SRM, ou à l’aide de DFS-R ou même de Robocopy pour répliquer les modifications entre deux clusters
• Système de fichiers distribué (DFS. La réplication DFS (DFS-R) et l’espace de noms DFS (DFS-N) sont deux des plus anciennes options de réplication et de disponibilité de serveurs de fichiers de Windows, initialement utilisées pour alimenter les fonctions de réplication Active Directory. Ils peuvent être configurés indépendamment les uns des autres, mais ils sont souvent configurés ensemble. Sa prévalence au sein des organisations Microsoft de longue date en fait une solution familière à de nombreux administrateurs. Cependant, son applicabilité prise en charge aux environnements Citrix est limitée.
• Avantages : familiarité avec les administrateurs, facile à configurer, peut couvrir plusieurs centres de données, ne dépend pas de configurations de clusters complexes (mais peut être superposée à celles-ci)
• Inconvénients : DFS présente de nombreuses limites et n’est pas idéal pour la plupart des cas d’utilisation de réplication de données liés à Citrix. LeDFS-N et le DFS-R ne sont pas pris en charge par Microsoft en combinaison l’un avec l’autre pour divers scénarios courants de données et de profils utilisateur, mais ils peuvent être pris en charge dans des scénarios actifs-passifs (réplication unidirectionnelle) avec basculement manuel (un scénario qui obligerait les utilisateurs à se déconnecter et à se reconnecter pour rétablir l’accès au serveur de fichiers), ne conviennent pas à l’hébergement de packages/conteneurs d’applications, sauf si les utilisateurs acceptent de se déconnecter et de se reconnecter
• Réplique de stockage. Storage Replica permet de répliquer des volumes entre des serveurs ou des clusters dans des scénarios impliquant plusieurs centres de données. Il peut être configuré sous trois formes : clusters étendus, cluster à cluster et serveur à serveur. La réplication asynchrone et synchrone est possible.
  • Avantages : prend en charge le basculement automatique lorsqu’il est utilisé avec Storage Spaces Direct pour former un cluster extensible. Peut convenir (sous réserve du test des performances de basculement) aux profils utilisateur, aux données utilisateur, aux conteneurs de profils, aux conteneurs d’applications et aux couches. Si vous n’utilisez pas de clusters extensibles, cela peut convenir uniquement aux conteneurs FSLogix
  • Inconvénients : si vous n’utilisez pas de clusters extensibles, le basculement doit être effectué manuellement et coupera les sessions SMB nécessitant une déconnexion/une connexion pour rétablir l’accès aux profils et aux données des utilisateurs. Ne convient pas à l’hébergement de packages/conteneurs d’applications si vous n’utilisez pas de clusters extensibles
• Serveur de fichiers Scale-Out. Lesserveurs de fichiers Scale-Out sont idéaux pour les cas d’utilisation impliquant des fichiers volumineux tels que des disques de machines virtuelles ou des données d’applications qui ne nécessitent pas particulièrement d’écriture.
  • Avantages : disponibilité continue des PME (réduit les temps d’arrêt en cas de basculement entre les nœuds), idéal pour les disques durs virtuels, les conteneurs d’applications, les couches, les conteneurs de profils, peut couvrir plusieurs centres de données
  • Inconvénients :Non recommandé pour les profils utilisateur (profils d’itinérance, CPM), redirection de dossiers Microsoft par Microsoft

En fonction de l’ensemble de données, il peut ne pas être essentiel de conserver le même chemin d’espace de noms entre les centres de données de production et de reprise après sinistre. Le maintien de chemins indépendants pour les profils utilisateur, les partages de packages d’applications, les couches élastiques ou utilisateur, les conteneurs de profils, etc. peut réduire la complexité. Les implications doivent être évaluées par type d’ensemble de données, notamment en tenant compte de la réplication inverse et du retour en cas de non-fonctionnement dans un scénario actif-actif. Dans les scénarios actif-actif, il serait idéal de rediriger les utilisateurs vers un centre de données régional plutôt qu’un autre, afin d’éviter de monter des applications et des conteneurs de données entre les sites et d’augmenter le temps de latence.

Considérations relatives à la restauration pour l’App Layering

Pour les entreprises qui utilisent App Layering, consultez l’architecture de référence Citrix pour App Layering. Les sauvegardes sont appropriées pour plusieurs composants, notamment l’appliance, les Elastic Layer Shares et les User Layer Shares.

• Les sauvegardes de l’appliance garantissent que toutes les couches sont disponibles même si l’appliance est détruite d’une manière ou d’une autre. Ces sauvegardes garantissent la disponibilité de toutes les couches, même si l’appliance est détruite ou corrompue d’une manière ou d’une autre.
• Les couches élastiques sont montées à partir d’un partage SMB lors de l’ouverture de session. Il est essentiel de s’assurer que le serveur de fichiers et les services utilisés pour Elastic Layers sont hautement disponibles en utilisant un clustering approprié. Il est important d’utiliser des solutions de partage de fichiers matérielles (ou cloud) natives ou des solutions Windows garantissant la disponibilité continue des PME. L’utilisation de plusieurs cibles DFS-R n’est pas suffisante pour ce cas d’utilisation, car en cas de défaillance d’une cible, les fichiers VHD montés ne peuvent pas être remappés vers une autre cible avant une nouvelle ouverture de session. De même, Storage Replica dans plusieurs configurations ne convient pas pour les mêmes raisons que celles évoquées précédemment.
  • Pour la DR, deux modèles peuvent être utilisés pour traiter les couches élastiques
    • Modèle de réplication
    • Modèle de double appliance
• Les couches utilisateur sont plus complexes du point de vue de la reprise après sinistre. Ces disques durs virtuels inscriptibles sont montés par Windows lors de l’ouverture de session et verrouillés par le bureau Windows.
  • Comme pour Elastic Layers, le matériel natif ou les solutions de partage de fichiers dans le cloud sont optimales en raison des limites des méthodes Windows courantes telles que le DFS-R ou la robocopie. Il faut comprendre que les couches utilisateur ont tendance à être plus grandes, les blocs changeant fréquemment, et que les méthodes de réplication qui répliquent au niveau des blocs plutôt que de copier le fichier entier une fois modifié seront préférables, faute de quoi les entreprises risquent de voir des quantités intenables de réplication de la couche utilisateur entre les sites.
  • En raison de la difficulté de réplication de disques volumineux ou des coûts inhérents, les entreprises choisissent le plus souvent de fournir des postes de reprise après sinistre aux utilisateurs sans couche utilisateur répliquée.

Considérations relatives à la restauration des profils

La restauration des profils nécessite une stratégie d’accès et de réplication au stockage adaptée, que les profils soient situés dans des centres de données locaux ou dans le cloud public. Cette section est destinée à s’appuyer sur les considérations antérieures relatives à la restauration abordées précédemment sur la base d’une solution par profil. Pour chaque cas d’utilisation, n’oubliez pas de demander « Le profil doit-il réellement être restauré dans un scénario de reprise après sinistre ? » Si ce n’est pas le cas, les coûts et la complexité peuvent probablement être considérablement réduits.

Recommandations générales :

• Vérifiez si les données du profil doivent être répliquées ou si une partie seulement de celles-ci doivent être répliquées. Par exemple, si vous utilisez des conteneurs de profils FSLogix, vous souhaiterez peut-être le diviser en un conteneur de profil et un conteneur Office (éventuellement sur des partages différents pour un contrôle granulaire de la réplication si vous vous fiez à la réplication du stockage) afin de permettre une réplication flexible des conteneurs de profils, mais pas des conteneurs Office (qui, lors d’un événement de reprise après sinistre, peuvent être créés à la demande).
• Prenez l’exemple en utilisant des plateformes de services de fichiers « natives » (filer) spécialement conçues sur site ou dans le cloud. De nombreuses options Windows sont disponibles, mais elles sont généralement moins robustes (à la fois en termes de fonctionnalités et d’évolutivité), entraînent plus de frais et comportent plus de mises en garde. La redondance locale est fortement recommandée en plus de la redondance intersite afin d’éviter certains des pièges courants des scénarios de basculement susceptibles d’interrompre les connexions des PME.
• Si vous répliquez des disques durs virtuels (qui sont généralement des fichiers volumineux) avec un taux de modification élevé, tels que des couches utilisateur et des conteneurs de profils, envisagez des solutions de réplication capables de se répliquer au niveau des blocs et de ne pas déclencher une copie complète du fichier en cas de modification, sinon les fournisseurs de stockage et le débit du réseau risquent d’être débordés.
• Tenez compte de l’intervalle RPO. Plus elle est courte, plus le coût et la charge des systèmes de stockage et de réseau sont élevés. Une option de réplication asynchrone qui équilibre la tolérance aux pertes de données et l’intervalle de réplication est optimale.
• Concevez la solution de manière à ce que les profils soient locaux pour les VDA de l’un ou l’autre emplacement afin d’améliorer les performances.
• Si vous utilisez le CPM et que vous prévoyez d’utiliser le DFS, reportez-vous à la documentation CPM DR pour connaître les considérations relatives au DFS.
• Sous réserve de tests, envisagez Cloud Cache pour simplifier la réplication et la restauration, car cette fonctionnalité gère la réplication des données de profil au niveau de l’application et permet aux administrateurs de définir une liste préférée de partages cibles de conteneurs (un par fournisseur de stockage de serveurs de fichiers) par centre de données (généralement via des structures GPO /OU). D’autres considérations relatives à Cloud Cache sont fournies par Microsoft et doivent être prises en compte lors de la planification. Cloud Cache présente des inconvénients et certains scénarios peuvent entraîner des pannes. Les entreprises sont donc invitées à examiner les risques potentiels afin de comprendre si les avantages liés à la gestion de la réplication et à la restauration des profils au niveau de l’application l’emportent sur eux.
• Planifiez le retour sur incident, ce qui peut entraîner le renversement de la réplication de la reprise après sinistre à la production.

Considérations relatives à la restauration des packages d’applications

Lorsque nous parlons de packages d’applications, nous faisons référence collectivement à App-V, MSIX, Elastic Layers et à des packages d’applications similaires. Ils sont généralement gourmands en lecture mais pas en écriture et, par rapport aux profils, ils ne sont pas mis à jour aussi fréquemment. Voici quelques recommandations générales pour ce type de données :

• Prenez l’exemple en utilisant des plateformes de services de fichiers « natives » (filer) spécialement conçues sur site ou dans le cloud.
• Envisagez de conserver des partages de fichiers distincts pour les applications (c’est-à-dire de ne pas utiliser le même chemin ou le même espace de noms) et de faire en sorte que les VDA utilisent leur partage de fichiers local. Synchronisez les partages de fichiers manuellement ou via Robocopy.

Considérations relatives à la restauration des images

Les images principales et les vDisks PVS doivent également être pris en compte dans la stratégie de restauration après sinistre. Les images principales, en cas de perte, peuvent nécessiter des efforts considérables pour les reconstruire. L’App Layering entre dans cette catégorie mais a déjà été abordé. Voici quelques recommandations générales à prendre en compte :

• Répliquez les images principales et les vDisks PVS entre des centres de données ou des régions cloud si vous vous fiez à la même image entre la production et la DR. Envisagez la réplication manuelle pour éviter qu’une image corrompue ne soit transmise à DR.
• Sauvegardez les images principales et les vDisks PVS (y compris les fichiers de version et les fichiers manifestes), idéalement sur un site hors site plutôt que sur un site de production.
• Utilisez Azure Compute Gallery (anciennement Shared Image Gallery) si vous utilisez Azure, pour répliquer des images entre les régions, les abonnements et les locataires, en fournissant un référentiel d’images partagé.

Résumé

Nous avons abordé un peu de terrain sur le thème de la reprise après sinistre dans Citrix. Les points suivants résument les principaux messages et points à retenir de ce guide que les architectes et les clients doivent prendre en compte lors de la planification de leur stratégie de récupération Citrix :

• La compréhension des besoins métiers et des capacités technologiques d’un environnement client influence la stratégie de reprise après sinistre requise pour Citrix. La stratégie de reprise choisie doit être alignée sur les objectifs commerciaux.
• La haute disponibilité n’est pas synonyme de reprise après sinistre. Toutefois, la reprise après sinistre peut inclure la haute disponibilité.
• Le partage des limites administratives entre les sites physiques ne constitue pas une solution de reprise après sinistre.
• Le développement d’une classification hiérarchisée de reprise après sinistre pour le portefeuille de technologies d’une entreprise offre visibilité, flexibilité et économies potentielles lors de l’élaboration d’une stratégie de reprise.
• Les exigences RTO pour l’infrastructure Citrix et les applications hébergées sur Citrix constituent le principal facteur d’influence dans la définition de la conception de la reprise après sinistre. Un RTO plus court nécessite souvent un coût de solution plus élevé.
• Les architectures de reprise après sinistre pour Citrix qui n’utilisent pas de plate-forme de reprise après sinistre « chaude » limitent les technologies qu’un client peut utiliser, telles que Citrix MCS, NetScaler et Provisioning.
• Une stratégie de reprise après sinistre pour Citrix doit prendre en compte le temps de restauration et de restauration des données utilisateur et des back-ends des applications. Citrix peut être conçu pour récupérer rapidement, mais les utilisateurs peuvent néanmoins être incapables de travailler si les dépendances entre les applications et les données ne sont pas disponibles dans un délai similaire.
• La reprise après sinistre dans les environnements cloud comporte un ensemble de considérations différentes, absentes des environnements sur site, que les entreprises doivent prendre en compte pour éviter des blocages imprévus ou des impacts opérationnels lorsqu’elles invoquent la reprise après sinistre dans des environnements cloud.
• Il est impératif que les composants de reprise après sinistre soient tenus à jour pour correspondre aux mises à jour et configurations de production afin de préserver l’intégrité de la plate-forme.
• Les plates-formes qui utilisent une configuration actif-active pour Citrix entre différents emplacements doivent être conscientes de la surveillance de la capacité afin de s’assurer qu’en cas de sinistre, des ressources suffisantes sont disponibles pour prendre en charge la charge projetée sur un ou plusieurs emplacements survivants.
• Les entreprises doivent tester régulièrement leur plan de reprise après sinistre pour Citrix afin de valider son fonctionnement et sa capacité à atteindre son objectif principal.
• Citrix DaaS simplifie considérablement de nombreux aspects de l’architecture DR et permet la redondance de l’emplacement des ressources via des configurations de préférence de zone.
• Planifiez et choisissez judicieusement vos options de réplication pour les données utilisateur, les packages d’applications, les couches, les vDisks et les conteneurs de profils afin de vous assurer que leurs limites sont connues et que leurs fonctionnalités correspondent aux exigences de l’entreprise.
• Ne confondez pas réplication et sauvegarde. Ils vont de pair et accordent une plus grande importance à la conservation des sauvegardes en raison de la prévalence des sauvegardes « à temporisation » causées par des rançongiciels.

Sources

Le but de cet article est de vous aider à planifier votre propre implémentation. Pour faciliter cette tâche, nous aimerions vous fournir des diagrammes sources que vous pouvez adapter à vos propres besoins : les diagrammes sources.