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

Vue d’ensemble

Ce guide facilite la planification de l’architecture de continuité d’activité (BC) et de reprise après sinistre (DR), ainsi que les considérations relatives aux déploiements sur site et dans le cloud des 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 de la stratégie globale de reprise après sinistre. Il ne prend pas en compte tous les aspects de la reprise après sinistre et adopte parfois une perspective plus profane sur divers concepts de reprise après sinistre.

Le présent guide vise à aborder les considérations suivantes qui ont une incidence importante sur l’architecture Citrix d’une organisation et à fournir des conseils architecturaux à leur sujet :

• Besoins de l’entreprise
• Reprise après sinistre contre 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

Alignement sur la « couche métier » de la méthodologie de conception Citrix, collecte des exigences métiers claires et des contraintes connues pour la restauration du service. La documentation de ces éléments constitue le point de départ du développement d’un plan de récupération pour Citrix. Cette étape aide à clarifier la portée et à fournir une orientation sur la stratégie de reprise après sinistre la plus appropriée pour répondre aux exigences opérationnelles et fonctionnelles, ainsi qu’aux contraintes.

Voici quelques exemples de questions utiles à discuter. Ces questions sont abordées plus en détail dans la sectionOptions de reprise après sinistreen termes de leur incidence sur une conception de reprise après sinistre Citrix :

• Stratégie de sauvegarde et objectif de temps de récupération (RTO).Quelle est la stratégie de sauvegarde utilisée aujourd’hui pour les serveurs ? Fréquence de sauvegarde ? Durée de conservation ? Stockage hors site ? Testé ? La plate-forme Citrix doit-elle être 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). Cela vaut la peine d’inclure les back-ends d’applications auxquels les applications hébergées par Citrix se connectent dans la discussion pour aligner les attentes.
• 对象if de point de récupération (RPO).Pour le RPO, quel degré de perte de données est considéré comme tolérable pour la reprise après sinistre, qui peut varier en fonction du composant d’infrastructure ou de la classification des données ? 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 avec RTO, il vaut la peine de considérer les back-ends de l’application pour les applications hébergées Citrix dans la discussion.
• Portée de la récupération.Cette considération n’inclut pas seulement l’infrastructure Citrix, mais peut inclure des données utilisateur ou des serveurs d’applications clés avec lesquels les clients d’applications hébergés Citrix s’interfacent. 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 est en ligne.
• Cas d’utilisation.Les plates-formes Citrix prennent souvent en charge de nombreux cas d’utilisation, chacun avec différents niveaux de criticité métier. 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 segmenter 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 capacité nette 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, ce qui peut réduire les coûts ? Un exemple de cette fonctionnalité serait l’utilisation de postes de travail persistants ou non persistants ; certains cas d’utilisation VDI qui peuvent être servis par des bureaux partagés hébergés, ou même des solos d’application spécifiques. Les clients ont parfois indiqué que la redondance des composants (ADC, Controller, StoreFront, SQL, etc.) ne sont pas considérées comme nécessaires dans 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 récupération finale pour Citrix, mais 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 ? Certaines composantes ne peuvent pas se prêter bien à certaines stratégies de rétablissement. Les environnements non persistants gérés par MCS ou PVS font des candidats médiocres pour les technologies de réplication de machines virtuelles en raison de leur intégration étroite avec le stockage et la mise en réseau.
• Degré d’importance des données.Les profils d’utilisateurs ou les données des utilisateurs sont-ils considérés comme essentiels à la récupération ? Des VDI persistants ? Si ces données ne sont pas disponibles lorsque la RD est invoquée, cela aurait-il des répercussions importantes 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 cloud ou de l’ensemble de l’infrastructure d’un fournisseur de cloud (multi-région) ?
• 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 ont pu être créées en reprise après sinistre sont-elles conciliées et consolidées avec la production ?

Les contraintes limitent les options de conception BC/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 quelles technologies peuvent ou ne peuvent pas être utilisées pour la réplication ou la récupération, comment elles sont utilisées, RTO ou la distance minimale entre les installations.
• Infrastructure.Existe-t-il一个指令苏尔勒德物资类型à 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, des pare-feu ou des canaux réseau sous-dimensionnés en reprise après sinistre peuvent entraîner des pannes car les dépendances réseau ne peuvent pas gérer la charge de travail de reprise après sinistre. Ou, dans le cas du calcul, les hôtes d’hyperviseurs sous-dimensionnés ou l’utilisation de différents hyperviseurs peuvent avoir un impact sur les options. En ce qui concerne la mise en réseau, si le site de récupération a une capacité de débit réseau plus limitée que la production lors de la maintenance du réseau étendu. Dans les environnements cloud, en particulier lorsque vous évoluez vers des milliers de sièges, ce risque potentiel peut rapidement devenir un goulot d’étranglement important en raison des limitations du service des composants, telles que les pare-feu virtuels, les passerelles VPN et les liaisons montantes Cloud-to-WAN (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, etc. sur).
• 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 en termes de paramètres régionaux et de technologies ou de méthodes de récupération.
• Récupération cloud.Existe-t-il un mandat pour la récupération de l’infrastructure dans le cloud plutôt que dans une installation sur site ?
• Préparation des applications.Les applications hébergées sur Citrix qui ont des dépendances back-end ont-elles un plan BC/DR 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 reprise après sinistre Citrix est l’idée qu’un plan de contrôle unique couvrant deux centres de données constitue la DR. Ce n’est pas le cas. Un seul site Citrix ou une batterie PVS couvrant des datacenters, même situés à proximité, constitue une conception haute disponibilité, mais pas une conception de reprise après sinistre. Certains clients choisissent ce chemin comme une décision d’entreprise qui valorise la gestion simplifiée par rapport à la capacité de reprise après sinistre. La répartition des groupes de serveurs StoreFront estprise en chargeuniquement 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 documentCTX220651.

勒之前按照联合国为例d 'architectureHA Citrix multi-datacenter qui n’est cependant pas une plate-forme de reprise après sinistre en raison de la justification mentionnée précédemment. Cette architecture de référence est utilisée par les clients qui traitent deux installations physiquement distinctes de datacenter comme un centre de données logique unique en raison de leur proximité les unes avec les autres et de leur faible latence et de leur interconnectivité à large bande passante. 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.

En plus de la référence conceptuelle HA ci-dessus, les architectures HA basées sur les zones sont disponibles pour les clients 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 issu de l’architecture IMA héritée (XenApp 6.5 et versions antérieures) a été repensé pour FMA et réintroduit dans XenDesktop 7.7 avec des améliorations majeures de la version 7.11 permet de créer diverses fonctionnalités de redondance intra-site qui peuvent résoudre des problèmes pour les déploiements multi-emplacements.

Dans une architecture de site qui utilise la fonctionnalité depréférence de zone(7.11 et versions ultérieures), des ressources Citrix identiques sont déployées dans plusieurs zones et agrégées dans un seul groupe de mise à disposition. Les préférences de zone (avec possibilité de revenir à d’autres zones pour une ressource donnée) peuvent être contrôlées en fonction de l’application, de la zone d’accueil de l’utilisateur ou de l’emplacement de l’utilisateur. Reportez-vous à la sectionInternes des préférences de zonepour plus d’informations à ce sujet. La fonction de mise à jour automatique de l’enregistrement des VDA(introduite dans XenDesktop 7.6) permet aux VDA de maintenir une liste mise à jour en cache locale de tous les Controller d’un site. 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 emplacement de zone, comme il est recommandé aux utilisateurs de continuer à accéder aux ressources à partir de 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 se produire en raison de problèmes de latence dans 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 de la part de clients 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考虑de恢复倒Les检修es de fichiers (données utilisateur et données métiers sur les partages, etc.) et les back-end d’applications avec lesquels les applications hébergées et les bureaux hébergés par Citrix s’interfacent. 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 de cas d’utilisation principaux ne possèdent pas de plan de récupération avec RTO similaire à Citrix ou aucun plan de récupération du tout, ce plan peut affecter Citrix basculer correctement en reprise après sinistre comme prévu, mais les utilisateurs ne sont pas en mesure d’exécuter leurs fonctions 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 sur une plate-forme Citrix « toujours sur » en reprise après sinistre et les utilisateurs se connectent, mais l’application EMR est récupérée via plus de moyens manuels, ce qui peut prendre des heures ou 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 pas être conforme aux attentes générales de l’entreprise en ce qui concerne le temps de récupération ou l’expérience utilisateur.

La section suivante traitera de la DR c. HA plus en détail.

Reprise après sinistre (DR) et Haute disponibilité (HA)

Comprendre HA vs. La RD est essentielle pour s’aligner sur les besoins organisationnels et atteindre les objectifs de rétablissement. HA n’est pas synonyme de DR, mais DR peut utiliser HA. Ce guide interprète l’HA et la DR comme suit :

• HA est considéré comme fournissant une tolérance aux pannes pour un service. Un service peut basculer vers un autre système avec une interruption minimale pour un utilisateur. La solution peut être aussi simple qu’une application en cluster ou à charge équilibrée vers une infrastructure active ou de secours plus complexe ou « à chaud » ou « toujours active » 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 du service et constitue généralement une stratégie de portée plus large qui résiste à plusieurs types de défaillances.

Alors que la haute disponibilité tend à ê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 et des ressources de l’infrastructure pour invoquer la récupération 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 ci-dessus, couplé à une récupération appropriée d’autres composants non Citrix liés à la solution, serait considéré comme une solution de reprise après sinistre hautement disponible dans laquelle un service (Citrix) bascule vers un centre de données opposé. Cette architecture particulière peut être implémentée en tant qu’actif-passif ou Active-Active dans diverses itérations multi-sites telles que Active-Passif pour tous les utilisateurs, Active-Active avec les utilisateurs préférant un centre de données à un autre, ou Active-Actif avec un équilibrage de charge 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 secours doit être prise en compte, prise en compte et surveillée de façon continue de la charge afin de s’assurer que la capacité reste disponible pour répondre aux besoins de DR, si nécessaire.

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

Dans le contexte de Citrix, le fait de répartir les domaines administratifs Citrix (site Citrix, batterie PVS, etc.) entre deux centres de données tels que deux installations géo-localisées selon lesdirectives publiéesne constituerait pas une reprise après sinistre et pour certains composants tels que les groupes de serveurs StoreFront. De même, en raison des limites de latence de la base de données PVS par rapportaux directives publiées, un tel déploiement ne serait probablement pas pris en charge. Les contraintes de prise en charge entre les géos s’étendent parfois à la conception du site et de la zone Citrix, en raison des latences maximales entre les contrôleurs de satellite et les bases de données, conformémentaux 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 une solution HA Citrix comme suffisante pour la reprise après sinistre, nous recommandons que la deuxième 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 récupération d’être aussi indépendante que possible, nous réduisons l’impact des défaillances au niveau des composants d’affecter à la fois les environnements de production et de reprise après sinistre. Cette prise en compte s’étend également au-delà de Citrix et l’utilisation de différents comptes de service, services de fichiers, DNS, NTP, gestion d’hyperviseur, services d’authentification (AD, RADIUS, etc.) entre les environnements de production et de reprise après sinistre est également recommandée pour réduire les points de défaillance uniques.

Classifications des niveaux de reprise après sinistre

La classification des niveaux pour la reprise après sinistre est un aspect important d’une stratégie de reprise après sinistre de l’organisation, car elle permet de clarifier l’application ou la criticité du service qui, à son tour, dicte le RTO (et donc les coûts pour atteindre ce niveau de récupération). 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 niveau DR à utiliser comme référence lors de l’évaluation des services d’infrastructure Citrix, de leurs dépendances et des applications critiques ou des cas d’utilisation (et associés aux VDA) hébergés sur Citrix. Les niveaux de reprise après sinistre sont définis par ordre ou priorité de récupération, 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

Niveau 0 - Objectifs de rétablissement (exemples)

对象if de temps de récupération : 0

对象if de point de récupération : 0

Tier 0 - Exemples de 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
• 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, il est probablement considéré 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

Niveau 1 - Objectifs de rétablissement (exemples)

对象if de temps de récupération : 4 heures

对象if de point de récupération : 15 minutes

Tier 1 - Exemples de classification

Applications critiques

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

Cas d’utilisation de Citrix

• Direction
• Service à la clientèle ou ventes
• Ingénierie informatique et support

Niveau 1 - Notes

Les applications ou postes de travail virtuels sur lesquels l’entreprise dépend pour exercer ses activités principales seraient généralement contenues 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. Si le provisionnement dans le cloud, les considérationsabordé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

Niveau 2 - Objectifs de rétablissement (exemples)

对象if de temps de récupération : 48 heures

对象if de point de récupération : 1 heure

Tier 2 - Exemples de classification

Applications non critiques Cas d’utilisation Citrix non critiques Données utilisateur qui n’ont pas d’impact sur les fonctionnalités des applications Tier 1 ou Tier 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 récupérées à partir de sauvegardes ou restaurées avec la priorité la plus basse par des outils de restauration automatisés.

Reprise après sinistre de niveau 3

Niveau 3 - Objectifs de rétablissement (exemples)

目的de delai de恢复:5天时间

对象if de point de récupération : 8 heures

Tier 3 - Exemples de classification

Applications peu utilisées

Niveau 3 - Notes

Les applications ayant un impact négligeable de panne ne sont pas disponibles jusqu’à une semaine. Ces applications sont probablement récupérées à partir de sauvegardes.

Reprise après sinistre de niveau 4

Niveau 4 - Objectifs de rétablissement (exemples)

对象if de délai de récupération : 30 jours

对象if de point de récupération : 24 heures ou aucun

Tier 4 - Exemples de classification

Environnements hors production

Niveau 4 - Notes

Applications, infrastructure et VDI dont les pannes ont également un impact négligeable sur les opérations de l’entreprise et peuvent être restaurées sur une longue période. Ils peuvent également avoir un RPO étendu, ou pas du tout selon leur nature. Ces RPO peuvent être récupérés à partir de sauvegardes ou construits tout neuf en reprise après sinistre et sont considérés comme le dernier niveau à récupérer.

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 ? Il est important de considérer que si Citrix est jugée importante mais qu’une application qu’il héberge est considérée comme critique, l’infrastructure Citrix deviendrait considérée comme critique.
• Les cas d’utilisation ou les applications métier de base que Citrix héberge ; dispose-t-il de différentes classifications de niveaux de reprise après sinistre ?

Pour la première question, de nombreux déploiements Citrix d’entreprise ont tendance à être classés comme niveau 0 en raison de la fourniture d’applications ou de postes de travail critiques ; le niveau « toujours actif » comme réseau, Active Directory, DNS et 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 Citrix et accorde une importance toute particulière à son importance dans les environnements cloud, dontnous parlerons plus en détail plus loin. Dans le cloud, il existe des considérations de coûts importantes entre la prise en charge de plates-formes d’applications ou de bureau « toujours en service », et les applications ou 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’établissement d’une conception de reprise après sinistre pour Citrix, il est utile d’amener la discussion au-delà de la portée de Citrix lui-même pour 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, mais les backends d’application critiques dont dépendent les applications hébergées par Citrix resteront indisponibles pendant plusieurs heures lorsque la récupération est appelé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 clés ne sont pas fonctionnelles. Établir des attentes dès le départ donne à tous les intervenants une visibilité appropriée sur ce que peut ressembler l’expérience de rétablissement. Dans certains cas, un client peut vouloir garder Citrix en veille à chaud (toujours activé) dans l’installation adverse, mais contrôler manuellement le basculement du niveau d’accès, afin d’éviter les malentendus sur la disponibilité de la plate-forme.

Options de reprise après sinistre

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

Corrélant trop plusieurs des questions de reprise après sinistre précédentes, les rubriques suivantes ont des implications de conception de Citrix DR comme suit :

• Stratégie de sauvegarde et objectif de temps de récupération (RTO).Si l’infrastructure Citrix ou les applications desservies par Citrix sont considérées comme critiques pour la mission, il est probable que Citrix doit utiliser un modèle « toujours activé » où l’infrastructure Citrix Active-Active est présente dans deux datacenters 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 reprise après sinistre (p. ex. couvrant un site à travers des centres de données ou en utilisant des zones satellites) ; si l’entreprise prévoit une plate-forme de reprise après sinistre pour Citrix, qui contrevient à ce mandat.
• Portée de la récupération.Si Citrix est déployé en mode veille à chaud (toujours en fonction) en reprise après sinistre, mais que les back-end de l’application métier principale prennent, par exemple, 8 heures pour la récupération, il n’est pas logique d’utiliser un basculement automatisé de 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 de priorités différentes nécessitent une restauration, la classification de l’importance par cas d’utilisation par opposition à l’impact métier selon la stratégie de hiérarchisation de la restaurationdiscutée précédemmentne peut pas réduire les coûts de capacité mais fournira au personnel informatique un ensemble plus ciblé d’ordres de priorité de restauration.
• Capacités.如果某些运输、composants HDX洞察力et l说nregistrement de session ne sont pas considérés comme essentiels au fonctionnement de la plate-forme DR, leur omission dans l’environnement de reprise après sinistre élimine une certaine complexité et une surcharge 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, l’utilisation d’un bureau partagé hébergé au lieu de VDI groupé si cela est techniquement possible, ou l’agrégation d’autres cas d’utilisation en un seul, à condition qu’ils ne nuisent pas aux opérations de l’entreprise.
• DR existante.如果选择策略de重奏然后这个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 la dépendance à la technologie de gestion d’image unique sont une exigence de plate-forme de production, ces technologies ne peuvent souvent pas convenir ; une approche hybride d’une plate-forme Citrix de secours à chaud et peut-être la réplication des images maîtresses peuvent être plus appropriées.
• Degré d’importance des données.Si les的资料是壶批评倒拉restauration en 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’ils soient créés de nouveaux. 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. De plus, si de nombreux VDI persistants sont jugés suffisamment importants pour conserver intacts en reprise après sinistre (plutôt que de demander aux utilisateurs de réinstaller leur logiciel, etc.), ces machines virtuelles doivent être envisagées pour la réplication, ce qui peut entraîner des coûts supplémentaires pour prendre en charge la récupération.
• 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 lorsque cela est possible, en utilisant des infrastructures Citrix géo-localisé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-dela du点ci-dessus concernant les考虑ations relatives à la localisation des utilisateurs, des applications et des données, certains réseaux d’utilisateurs clients peuvent être relativement verrouillés avec des périphériques de sécurité (proxy, pare-feu, etc.) qui peuvent restreindre la communication sortante vers Internet ou même le WAN. Il est important de déterminer si cet état s’applique aux réseaux clients et de s’assurer que les nouvelles adresses IP pour les services Citrix (telles que les adresses IP VIP et VDA StoreFront, ou Citrix Gateway IP) sont prises en compte dans leurs configurations de sécurité locales afin de garantir que d’autres retards de récupération ne se produisent pas en raison de la sécurité du LAN local restrictions lors de l’appel 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 pour un client peut supposer que le WAN n’est pas disponible et que tous les utilisateurs doivent accéder aux ressources Citrix via Internet. Ces étapes nécessiteraient de la documentation dans les plans de préparation de la C.-B. et de préparation, avec des pré-requis établis pour les utilisateurs finaux (concernant les détails du client Citrix pris en charge, les hypothèses sur l’accès des entreprises ou des appareils BYOD) afin d’éliminer les obstacles pour les utilisateurs retournant au service, ce qui réduirait davantage le fardeau du service de soutien.
• Bande passante réseau.La quantité de bande passante réseau utilisée en ce qui concerne le trafic VDA (ICA, applications, services de fichiers) doit être prise en compte dans le dimensionnement du réseau de l’installation DR et les pare-feu. 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 organisations doivent utiliser différentes configurations réseau pour prendre en charge la charge de trafic de reprise après sinistre prévue si et quand elles sont invoquées. La technologie d’optimisation WAN de Citrix SD-WAN peut aider à réduire la demande de trafic.
• Secours (ou restauration).Si les données utilisateur qui ont été modifiées en reprise après sinistre ou si des images VDA pendant la reprise après sinistre, l’organisation doit planifier le retour arrière pour propager ces modifications à la production, l’environnement de production est-il 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 en production et les VDA mis à jour en conséquence.

以下这个liste decrit de recup多样化的选择ération courantes pour Citrix. Les adaptations de chacun existent sur le terrain, mais pour des raisons de comparaison, nous présentons des versions de base de chacune. 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. De plus, bien que possible à réaliser, de nombreuses options indiquent que les technologies Citrix intégrées au réseau et au stockage telles que les technologies ADC et de gestion d’image unique ne conviennent pas aux méthodes autres que les modèles de restauration « toujours en service ». 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

Avantages et inconvénients

Avantages :

• Coûts de maintenance réduits par rapport aux solutions de réplication ou de secours

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
• 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 à Citrix VPX ADC en raison de la mise en réseau (et peut avoir besoin d’être reconstruit à l’aide de sauvegardes densconfigrépertoire et dens.conffichiers)

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 l’intégrité de la restauration des sauvegardes est régulièrement testée et suit des processus de restauration clairement documentés.

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

Avantages et inconvénients

Avantages :

• La réplication est probablement automatisée et s’aligne sur RTO et 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)
• Degré d’erreur humaine plus élevé si une reconfiguration manuelle est nécessaire (mise en réseau, etc.)
• Ne convient pas pour Pooled, Fast Clone MCS ou 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 reprise après sinistre ou en mettant à l’échelle des instances VDA en reprise après sinistre 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 pour Citrix VPX ADC en raison de la mise en réseau et donc mieux adapté pour utiliser un serveur de secours ADC

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 de stockage du fournisseur SAN ou du fournisseur d’hyperviseur (vSphere Replication, etc.) pour répliquer les machines virtuelles vers une autre installation via le WAN.

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

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, ASR pour orchestrer la récupération et modifier les paramètres réseau
• 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 reprise après sinistre ou en mettant à l’échelle des instances VDA en reprise après sinistre 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 pour Citrix VPX ADC en raison de la mise en réseau et donc mieux adapté pour utiliser un serveur de secours ADC

Cas d’utilisation et hypothèses

Utile pour les organisations d’entreprise avec des ressources et un budget appropriés pour les installations de reprise après sinistre. Cette solution repose sur la même réplication de 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 de carte réseau (si nécessaire), etc.

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

Avantages et inconvénients

Avantages :

• Temps de récupération court car la plate-forme est « toujours active »
• Prend en charge le stockage et les composants dépendants du réseau tels que VPX, 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 diriger les utilisateurs vers l’URL de sauvegarde
• Coûts plus élevés en raison de la présence de matériel « chaud » en reprise après sinistre en veille
• 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 organisations d’entreprise avec des ressources et un budget appropriés pour les installations de reprise après sinistre. Peut utiliser une plate-forme de veille à chaud « entièrement évolutive » ou une plate-forme « évolutive à la demande ». Ce dernier point peut être intéressant pour la restauration dans le cloud afin de réduire les coûts d’exploitation, aveccertaines réserves.

Au moment du basculement, les administrateurs mettent à jour l’entrée**DNS** pour une ou plusieurs URL d’accès pour pointer vers une ou plusieurs adresses IP DR pour Citrix Gateway et StoreFront, ou les utilisateurs sont invités par une communication formelle à commencer à utiliser une URL « sauvegarde » ou « 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 suffisamment d’infrastructure WAN et de calcul sont disponibles pour prendre en charge le basculement sur incident.

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

Avantages et inconvénients

Avantages :

• Temps de récupération court car la plate-forme est « toujours active »
• Prend en charge le stockage et les composants dépendants du réseau tels que VPX, MCS, PVS
• 文档相对非盟计划恢复minimal (orchestration de reprise après sinistre)
• Plus facile pour les utilisateurs finaux grâce au basculement des URL
• Prise en charge des analyses EPA sur Citrix Gateway

Inconvénients :

• Coût plus élevé en raison du fait que le matériel « chaud » en reprise après sinistre est en veille et licences Citrix ADC
• 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

配置公社用d 'entrepris les客户e et permet un basculement automatique vers le site de reprise après sinistre via Citrix ADC GSLB (ADC Advanced ou supérieur nécessaire). Ce modèle suppose une organisation informatique mature et suffisamment de WAN et une infrastructure de calcul suffisante pour prendre en charge le basculement sur incident. 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 actives du site et qu’elles peuvent être récupérées sur le 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.

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

Avantages et inconvénients

Avantages :

• Temps de récupération court car la plate-forme est « toujours active »
• Prend en charge le stockage et les composants dépendants du réseau tels que VPX, MCS, PVS
• 文档相对非盟计划恢复minimal (orchestration de reprise après sinistre)
• Transparente pour les utilisateurs finaux

Inconvénients :

• Coût plus élevé en raison du fait que le matériel « chaud » en reprise après sinistre est en veille et licences Citrix ADC
• 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
• Le GSLB actif/actif ne prend pas actuellement en charge les scans EPA sur Citrix Gateway, configuration GSLB actif/passif pour Citrix Gateway URL suggérée
• S’appuie sur les administrateurs pour surveiller et ajuster la capacité des ressources et du matériel dans tous les centres de données afin de garantir que l’intégrité de la capacité de reprise après sinistre n’est pas affectée à mesure

Cas d’utilisation et hypothèses

Une configuration plus avancée mais commune avec les clients d’entreprise et permet aux URL de niveau d’accès de fonctionner de manière active via Citrix ADC GSLB (ADC Advanced ou supérieur 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 suffisamment de WAN et une infrastructure de calcul suffisante pour prendre en charge le basculement sur incident. 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 considérations clés suivantes peuvent être prises en compte lors de la planification de la conception de la reprise après sinistre afin d’éviter les erreurs qui peuvent rendre le plan de reprise après sinistre appliquant l’infrastructure cloud invalide, coûteux ou incapable d’atteindre la capacité cible en cas de DR

Prise en compte — Débit réseau

Domaines d’impact

Coût des performances de disponibilité

Détails

Les clients peuvent sous-estimer et donc sous-dimensionner les points de jonction de débit dans leur solution cloud, y compris le pare-feu virtuel, la passerelle VPN et la liaison ascendante WAN (AWS Direct Connect, Azure Express Route, GCP Cloud Interconnect, etc.) si la plate-forme Citrix doit être restaurée dans le Cloud et être accessible via WAN. Les passerelles VPN Azure et les passerelles AWS Transit ont actuellement des limites maximales de 1,25 Gbit/s. Cette limite peut nécessiter la mise à l’échelle des passerelles ou peut-être l’utilisation de plusieurs VPC (s’il existe un AWS) s’ils sont essentiels à l’architecture du cloud. De nombreux pare-feu virtuels ont des limites sous licence sur le débit qu’ils peuvent traiter ou des maximums, même à leur limite la plus élevée. Cette contrainte peut nécessiter la mise à l’échelle du nombre de pare-feu et l’équilibrage de la 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
• 邦德passante de沟通des应用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 ci-dessus, il peut être utile de collecter des données sur les schémas de trafic actuels vers 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. Veillez à associer les équipes réseau et sécurité à la planification de Citrix DR pour vous assurer que toutes les estimations de bande passante traversant les zones de sécurité et les segments réseau sont comprises et peuvent être prises en compte. Lorsque la bande passante est à un niveau supérieur, Citrix SD-WAN WAN Optimization peut vous aider à réduire l’encombrement de session sur le fil ou à agréger la bande passante sur plusieurs connexions réseau.

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修改ses所有权de执照云en août 2019, ce qui peut avoir une incidence sur les coûts de VDI dans certains scénarios de déploiement.

Recommandations

Reportez-vous aux instructions Microsoft les plus récentes pour déterminer l’architecture de cas d’utilisation. Si la solution de reprise après sinistre présente un défi potentiel en termes de coûts, envisagez d’ajouter des postes de travail partagés hébergés (une augmentation des LAC RDS peut être nécessaire), dans la mesure du possible, car ils peuvent offrir une plus grande flexibilité à un coût d’exploitation moins élevé.

奖赏在考虑——时刻de la协定l 'echelle VDA (avant ou pendant la reprise après sinistre)

Domaines d’impact

Disponibilité des coûts

Détails

Les clients sont attirés par le cloud car ils paient pour la capacité seulement quand elle est nécessaire. 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 à un contrat SLA de mise sous tension sur des centaines ou des milliers de machines virtuelles à la fois. Cette solution devient particulièrement difficile si l’empreinte VDA pour la reprise après sinistre devrait s’exécuter dans des centaines ou des milliers d’instances. Les fournisseurs de cloud ont tendance à maintenir la capacité en bloc pour différentes tailles d’instance en main ; cependant, ce fournisseur peut varier d’un moment à l’autre. Si une catastrophe affectant une zone géographique se produit, d’autres locataires peuvent également demander une capacité à la demande.

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 ?
• Devons-nous héberger uniquement des 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做上杜雷斯实例系统e 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. Dans la mesure du possible, il serait prudent de pré-provisionner les instances de VDA, de les garder hors ligne et de les mettre à jour régulièrement. Le Provisioning est un processus exigeant en ressources et en temps, et la mise à l’échelle de la capacité de reprise après sinistre VDA à la demande peut être accélérée dans une certaine mesure par le 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 réservés \ dédiés en référençant le niveau de récupération après sinistre dans lequel certains cas d’utilisation peuvent nécessiter la disponibilité immédiate des VDA, tandis que d’autres peuvent avoir la flexibilité d’être récupérés sur un RTO plus long de plusieurs jours ou semaines s’ils sont moins critiques pour maintenir le entreprise.

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-end des applications peut avoir un impact notable sur les performances et parfois sur la disponibilité de l’environnement de reprise après sinistre Citrix. Certains scénarios clients utilisent une approche de reprise après sinistre multidatacenter, où tous les back-end d’applications ou les données utilisateur telles que les disques domestiques et départementaux ne peuvent pas être récupéré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, cette lacune peut augmenter la pression sur la bande passante disponible du réseau et des appliances 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.

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 (CVAD) et Citrix DaaS fourni par Citrix Cloud concernant 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 requiert simplement qu’un client déploie Citrix Cloud Connector dans la restauration « Emplacement des ressources », et éventuellement StoreFront et Citrix ADC 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 Citrix 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 Citrix Gateway Service et le service Citrix Workspace ne sont pas utilisés à partir de Citrix Cloud.

Cette section traite des rubriques clés pour aider les clients à définir une stratégie de reprise après sinistre appropriée pour Citrix Cloud.

Citrix DaaS simplifie la reprise après sinistre

Vous trouverez ci-dessous un schéma conceptuel typique décrivant l’architecture conceptuelle de Citrix DaaS, en plus de la séparation des responsabilités pour les composants gérés par Citrix et les composants gérés par les partenaires/clients. Les « services » WEM, Analytics et Citrix 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 larégion Citrix Cloud. Il fait partie de la « sauce secrète » de Citrix Cloud et est pris en compte dans lesSLA de Citrix Cloud.

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

• Citrix.Contrôlez le plan et accédez aux « services » s’ils sont utilisés (Workspace, Citrix Gateway Service).
• Client.Composants d’emplacement des ressources, y compris Cloud Connector, VDA, back-end des applications, dépendances d’infrastructure (AD, DNS, etc.) et niveau d’accès (StoreFront, Citrix ADC) si vous n’utilisez pas le niveau d’accès Citrix Cloud.

Les clients 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 destinés à la planification de la restauration soient retirés du périmètre de gestion du client, les clients 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.

拉加重要的差异在这样堂t 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 dezones. 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 CVAD déployé traditionnellement serait considérée comme une conception haute disponibilité, mais pas 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 desoptions de reprise après sinistredé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é, Cloud Connector ne constitue pas un composant qui doit être « récupéré » manuellement ou automatiquement lors d’un événement de reprise après sinistre. Ils doivent être considérés comme des composants « de secours à chaud » et conservés en ligne dans chaque emplacement.
• Contrôleurs d’accès gérés par le client (facultatif).Les clients peuvent choisir de déployer leurs propres ADC Citrix pour les serveurs Citrix Gateway et StoreFront et 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
  • 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 Citrix 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 clients disposant d’un environnement de « veille à chaud » peuvent être tentés de couper les coins et de traiter la reprise après sinistre comme une plate-forme de test. Ce traitement affecte négativement l’intégrité de la solution. En fait, la DR serait probablement la dernière plate-forme à promouvoir des modifications, afin de s’assurer que son utilité n’est pas affectée dans les cas où la maintenance a mal tourné d’une manière qui n’a pas été exposée dans des environnements non prod.
• Application de correctifs et maintenance.La maintenance de routine en phase de verrouillage avec production lors de l’utilisation de plates-formes Citrix « de secours à chaud » est essentielle pour maintenir une plate-forme de reprise après sinistre fonctionnelle. Il est important de maintenir la reprise après sinistre synchronisée avec la production en ce qui concerne le système d’exploitation, les produits Citrix et les correctifs d’application. 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.Peu importe si la reprise après sinistre implique la réplication de la production vers une installation de récupération ou l’utilisation d’environnements « de secours à chaud », il est important de tester périodiquement (deux fois par an ou plus, c’est idéal) le plan de reprise après sinistre pour s’assurer que les équipes connaissent bien les processus de récupération et que les défauts de la plate-forme ou des workflows sont identifiées et corrigées.
• 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.

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 peut s’aligner sur les objectifs de l’entreprise.
• 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 frontières administratives entre emplacements 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 technologique d’une entreprise offre visibilité, flexibilité et économies potentielles lors de l’élaboration d’une stratégie de restauration.
• Les exigences RTO pour l’infrastructure Citrix ou les applications hébergées sur Citrix constituent le facteur d’influence le plus important sur lequel la conception de reprise après sinistre est nécessaire. Un RTO plus court nécessite souvent un coût de solutions plus élevé.
• Les architectures de reprise après sinistre pour Citrix qui n’utilisent pas de plate-forme de reprise après sinistre « chaude » présentent des limitations dans les technologies qu’un client peut utiliser, telles que Citrix MCS, ADC et Provisioning.
• La stratégie de reprise après sinistre pour Citrix doit également tenir compte du temps de récupération et de récupération des données utilisateur et des back-end des applications. Citrix peut être conçu pour une restauration rapide, mais les utilisateurs peuvent néanmoins être incapables de travailler si les dépendances des applications et des données ne sont pas disponibles dans un délai similaire.
• La reprise après sinistre dans les environnements cloud présente ses propres considérations qui ne sont pas présentes dans les environnements locaux que les organisations doivent examiner pour éviter les goulets d’étranglement imprévus ou les impacts opérationnels lorsqu’elles invoquent la reprise après sinistre dans les 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 clients doivent tester périodiquement leur plan de reprise après sinistre pour Citrix afin de valider son fonctionnement et sa capacité à servir son objectif principal.
• Citrix DaaS simplifie considérablement de nombreux aspects de l’architecture de reprise après sinistre et permet la redondance de l’emplacement des ressources via la configuration des préférences de zone.

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 : lesdiagrammes sources.