Options de continuité d’activité et de reprise d’activité pour FSLogix
Remarque
Tous les diagrammes sont des exemples basés sur Azure Virtual Desktop et s’appliquent à d’autres plateformes de bureau virtuel.
Un plan de continuité d’activité et de reprise d’activité efficace (BCDR) se concentre sur les processus et les ressources nécessaires pour qu’une organisation fonctionne en cas de catastrophe ou d’autres pannes importantes. Les profils utilisateur itinérants ne sont généralement pas décrits comme un composant métier ou stratégique d’une stratégie BCDR . Dans un environnement de bureau virtuel, un utilisateur ne sait pas qu’il dispose d’un profil itinérant. Le profil est itinérant pour fournir aux utilisateurs une expérience cohérente, quelle que soit la machine virtuelle. Les données métier ou stratégiques ne doivent pas être stockées dans le profil d’un utilisateur si possible. L’utilisation de OneDrive, SharePoint ou d’autres solutions est un moyen efficace de protéger les données pendant un événement BCDR , tout en ne s’appuyant pas sur l’itinérance des données avec l’utilisateur dans le cadre de son profil. Ce processus est le mieux décrit dans un objectif de récupération (RTO) et un objectif de point de récupération (RPO) où l’analyse des coûts et des risques peut être pesée sur les objectifs de l’organisation et de l’entreprise.
Option 1 : Aucune récupération de profil
Bien que cette option ne semble pas être une conception BCDR , elle est axée sur la garantie que les données métier et stratégiques ne se trouve pas dans le profil de l’utilisateur. Lors d’un sinistre, les utilisateurs créent des profils dans un nouvel emplacement ou sur un nouveau fournisseur de stockage (les deux peuvent être vrais). Cette option est la plus rentable en termes de coût d’infrastructure, mais a une pénalité en raison de l’effet qu’elle peut avoir sur l’expérience utilisateur.
Figure 1 : Aucune récupération de profil | Conteneurs standard FSLogix (VHDLocations)
Dans le diagramme, il s’agit d’un pool d’hôtes multirégion à l’aide d’Azure Virtual Desktop. Les régions principales et de basculement ont un partage Azure Files dédié à l’aide du stockage redondant interzone (ZRS) qui fournit une haute disponibilité au sein de la région. La région de basculement possède des hôtes de session, qui sont arrêtés ou désalloués. En cas de sinistre, la région de basculement devient la région principale et les utilisateurs se connectent à ces hôtes de session et créent de nouveaux profils sur le partage Azure Files dans cette région.
Option 2 : Cache cloud (principal/basculement)
Une conception de basculement est une stratégie courante pour garantir la disponibilité et la fiabilité de votre infrastructure en cas de sinistre ou de défaillance. Cloud Cache vous permet d’utiliser FSLogix à l’aide de ce type de conception de basculement. Avec Cloud Cache, vous pouvez configurer vos appareils pour utiliser deux (2) fournisseurs de stockage qui stockent vos données de profil dans différents emplacements. Cloud Cache synchronise vos données de profil avec chacun des deux fournisseurs de stockage de façon asynchrone, de sorte que vous disposez toujours de la dernière version de vos données. Certains de vos appareils se trouvent à l’emplacement principal et les autres appareils se trouvent dans l’emplacement de basculement. Cloud Cache hiérarchise le premier fournisseur de stockage (le plus proche de votre appareil) et utilise l’autre fournisseur de stockage comme sauvegarde. Par exemple, si votre appareil principal se trouve dans la région USA Ouest et que votre appareil de basculement se trouve dans la région USA Est, vous pouvez configurer Cloud Cache comme suit :
- L’appareil principal utilise un fournisseur de stockage dans la région USA Ouest comme première option et un fournisseur de stockage dans la région USA Est comme deuxième option.
- L’appareil de basculement utilise un fournisseur de stockage dans la région USA Est comme première option et un fournisseur de stockage dans la région USA Ouest comme deuxième option.
- Si l’appareil principal ou le fournisseur de stockage le plus proche échoue, vous pouvez basculer vers l’appareil de basculement ou le fournisseur de stockage de sauvegarde et poursuivre votre travail sans perdre vos données de profil.
Toutefois, il existe certains inconvénients liés à l’utilisation d’une conception de basculement avec Cloud Cache. Tout d’abord, vous devez payer un supplément pour stocker vos données de profil dans deux (2) emplacements. Ensuite, vous devez lancer manuellement le processus de basculement, ce qui peut nécessiter l’approbation des parties prenantes de l’entreprise. Troisièmement, vous pouvez rencontrer une certaine latence ou incohérence dans vos données de profil en raison de la synchronisation asynchrone avec les deux fournisseurs de stockage.
Conseil
- Avant d’autoriser les utilisateurs à effectuer une restauration automatique vers des profils dans l’emplacement principal, assurez-vous que tous les utilisateurs se sont correctement déconnectés de l’emplacement de basculement pour vous assurer que l’emplacement principal dispose d’un réplica à jour des données de profil de l’utilisateur.
- Cloud Cache est un système gourmand en E/S et peut facilement entraîner des goulots d’étranglement réseau et/ou de stockage à l’emplacement restauré.
Figure 2 : Cache cloud (principal/basculement) | FSLogix Cloud Cache (CCDLocations)
Dans le diagramme, nous disposons d’un pool d’hôtes multirégion utilisant Azure Virtual Desktop. Les régions principales et de basculement font partie de cette configuration. Ils disposent chacun d’un partage Azure Files dédié à l’aide d’un stockage redondant interzone (ZRS), garantissant une haute disponibilité au sein de la région. La région de basculement contient des hôtes de session, qui sont arrêtés ou désalloués. En cas de sinistre, la région de basculement devient la région primaire. Les utilisateurs se connectent à ces hôtes de session et chargent leur profil répliqué à partir de la région de basculement.
Toutefois, il est essentiel de prendre en compte les éléments suivants :
- Les événements BCDR (continuité d’activité et reprise d’activité) sont rarement appropriés. Selon les circonstances, les données de profil utilisateur peuvent ne pas être garanties d’être intactes.
- Les utilisateurs qui se connectent aux hôtes de session dans la région de basculement peuvent subir une perte de données ou, dans des cas pires, une altération du conteneur.
Étant donné cette situation, il est essentiel d’utiliser des plateformes de stockage telles que OneDrive ou SharePoint pour les données critiques. Ces plateformes offrent une redondance et une protection supplémentaires contre la perte de données. N’oubliez pas que la planification de la reprise d’activité est essentielle et que la stratégie de stockage appropriée peut atténuer les risques et garantir la continuité de l’activité.
Option 3 : Cache cloud (actif/actif)
Lors de la discussion de l’infrastructure, il est courant d’utiliser des conceptions actives/actives, qui peuvent également être appliquées à une solution de profil FSLogix. Avec cette option, Le cache cloud est configuré avec deux fournisseurs de stockage mis à jour de manière asynchrone pour refléter toutes les modifications apportées au cache local. Le fournisseur de stockage le plus proche de l’emplacement actif est répertorié en premier, tandis que le fournisseur le plus éloigné est répertorié en deuxième. Dans l’autre emplacement, l’ordre est inversé. Cette option entraîne des coûts supplémentaires pour stocker les données du fournisseur à deux emplacements et nécessite une décision manuelle des parties prenantes de l’entreprise avant de lancer un basculement.
Conseil
- Lorsque la région ayant échoué est opérationnelle, il peut prendre beaucoup de temps pour que les données de profil soient entièrement répliquées.
- Cloud Cache est un système gourmand en E/S et peut facilement entraîner des goulots d’étranglement réseau et/ou de stockage à l’emplacement restauré.
Figure 3 : Cache cloud (actif/actif) | FSLogix Cloud Cache (CCDLocations)
Dans le diagramme, sont deux (2) pools d’hôtes AVD et hôtes de session résidant dans des régions Azure spécifiques. Les utilisateurs affectés à la région USA Ouest accèdent à ces machines virtuelles. Les utilisateurs de la région USA Est accèdent uniquement et sont affectés à ces machines virtuelles. Au cours d’un sinistre, la région survivante doit avoir suffisamment de capacité pour prendre en charge tous les utilisateurs. En outre, les utilisateurs de la région ayant échoué ont besoin d’un accès accordé aux machines virtuelles de la région survivante.
Les événements BCDR ne sont jamais appropriés et en fonction des circonstances de l’événement, les données de profil utilisateur ne sont pas garanties d’être intactes. Les utilisateurs qui se connectent aux hôtes de session dans la région survivante peuvent subir une perte de données ou une altération du conteneur pire. Cette situation renforce la nécessité d’utiliser des plateformes de stockage telles que OneDrive ou SharePoint pour les données utilisateur critiques.