Xylos brands

Créer des serveurs de fichiers à haute disponibilité dans Azure : trouver l’équilibre entre possibilités et limitations…

Les serveurs de fichiers traditionnels nécessitent beaucoup de maintenance... Et quand il s’agit de mettre à niveau ou à jour l’infrastructure existante, vous êtes généralement confronté à une tâche à la fois difficile, coûteuse et inefficace. C’est la raison pour laquelle nous créons des conceptions techniques qui vous soulageront complètement de ce fardeau. Mais comment concevoir un tel serveur de fichiers dans Azure ? Illustrons le processus à l’aide d’une de nos études de cas de client.

Notre scénario client

Un client nous a récemment demandé si nous étions en mesure de fournir une solution pour migrer vers le cloud des serveurs de fichiers locaux dispersés sur plusieurs sites en Belgique.

La solution devait répondre au « cahier des charges » suivant :

  • haute disponibilité,
  • centralisation,
  • évolutivité,
  • facilité d’entretien,
  • facilité de restauration.

Par ailleurs, nous avons dû tenir compte des exigences suivantes :

  • quantité de données : 8 To (11 millions de fichiers), répartis sur dix sites en Belgique ;
  • les autorisations NTFS ont dû être transférées ;
  • les fichiers doivent être conservés pendant au moins dix ans.

Au terme d’une analyse approfondie et d’une preuve de concept réussie, nous avons élaboré le projet technique suivant :

Les points ci-dessous examinent plus avant certains des choix que nous avons opérés.

Notre solution Azure

Azure Files

À première vue, Azure Files semblait être la solution la plus appropriée, mais il y avait un obstacle de taille : pour utiliser les listes de contrôle d’accès (ACL), nous devions configurer Azure Active Directory Domain Services. Comme ce n’était pas une option, nous avons dû trouver un autre moyen d’atteindre nos objectifs.

Windows Server avec la puissance d’Azure

Et pourquoi pas une configuration de serveurs Windows ?

Premier pas incontournable : nous avons d’abord créé deux serveurs de fichiers dans Azure. À cet effet, il est préférable d’utiliser un modèle ARM. Vous pouvez ainsi réorganiser automatiquement les serveurs de fichiers et le document contient des informations spécifiques sur la conception, de sorte que tout le monde puisse examiner ces informations lorsque cela s’avère nécessaire.

Voici notre modèle ARM

Nous avions besoin d’une machine virtuelle (VM) pour atteindre nos objectifs généraux. Après avoir examiné les options, nous avons décidé que « Standard_D4s_v3 » était le meilleur choix pour notre solution. Si nous devions avoir une solution plus ou moins puissante, nous pourrions facilement l'adapter.

Nous avons également placé les serveurs dans deux zones de disponibilité différentes pour obtenir la redondance souhaitée. Même en cas de défaillance d’un datacenter entier pour l'une ou l’autre raison, nous pouvons toujours compter sur une machine virtuelle dans un autre datacenter.

Enfin, nous avons utilisé deux disques de 4 To pour stocker toutes les données.

Pourquoi deux disques de 4 To ?

De cette façon, nous avons pu contourner une limitation importante d’Azure : « Prise en charge de disque de grande capacité – Vous pouvez désormais sauvegarder des VM avec des disques d’une capacité maximale de 4 To (4 095 Go), tant gérés que non gérés. »

Et une seule implémentation plus tard...

Chez le client, un des problèmes était que l’espace disque de ses serveurs de fichiers était presque plein. Pour y remédier, nous voulions nous assurer que l’ensemble des données de nos clients puisse croître à l’infini dans un avenir proche.

Pour ce faire, nous avons utilisé les Windows Storage Spaces. Les disques de ces serveurs de fichiers sont configurés comme un disque virtuel à volume agrégé par bande et à allocation granulaire (avec Simple Storage Layout). Autrement dit, des disques supplémentaires peuvent être connectés à la VM à tout moment et les disques virtuels peuvent être étendus si nécessaire, sans indisponibilité. De cette façon, chaque espace de stockage pourrait croître dynamiquement. De plus, il y avait un autre avantage : nous n’avions pas à fournir trop d’espace de stockage (en d'autres termes, nous ne devions pas gaspiller trop d’argent), mais seulement celui dont nous avions besoin dans un avenir proche.

 

Grâce aux Windows Storage Spaces, nous avons pu cocher la case « évolutivité » sur la liste des exigences de notre client.

Passer à la haute disponibilité

Pour maintenir les serveurs de fichiers synchronisés, nous avons utilisé Azure File Sync.

Comment savoir sur quel serveur les collaborateurs travaillent ? Que se passe-t-il si deux collaborateurs travaillent sur le même fichier sur des serveurs différents ?

Nous avons résolu ce problème avec le DFS (système de fichiers distribué). Nous avons créé des espaces de nom pour chaque site. À cet effet, il est toutefois possible d'utiliser toute topologie de données souhaitée.

Le secret ? Définir la priorité pour un espace de nom. Par exemple, si vous donnez la priorité à l’espace de nom du serveur de fichiers 1, tout le trafic sera acheminé vers ce serveur, à moins que la connexion ne soit indisponible. Vous créez ainsi une configuration active-passive. Si le serveur de fichiers 1 n’est pas disponible pour une raison quelconque (patchs, centre de données Azure indisponible...), l’espace de nom DFS redirige tout le trafic vers le serveur de fichiers 2 jusqu’à ce que la connexion soit rétablie.

La configuration d’Azure

Nous avions donc deux serveurs de fichiers avec DFS. La différence avec un serveur de fichiers sur site réside dans le fait que nous pouvons conserver les fichiers sur les deux serveurs synchronisés avec Azure File Sync.

Pour utiliser Azure File Sync, vous avez besoin d’un compte de stockage. Étant donné que, dans ce cas de figure, les fichiers du compte de stockage devaient être dupliqués sur les deux serveurs, et n’étaient utilisés que passivement pour synchroniser les serveurs, la performance standard avec un stockage localement redondant s'est révélée suffisante.

Nous avons créé un partage de fichiers pour chaque site. C’était à nouveau un choix que nous nous devions de soupeser minutieusement. En gardant à l’esprit une autre limitation d’Azure (la taille maximale d’un partage de fichiers dans Azure est de 5 Tio), nous avons calculé que si chaque site contient environ 10 Tio/10 sites = 1 Tio, chaque site pourrait encore s’élargir de 4 Tio avant que nous ne devions prendre des mesures. Un autre avantage réside dans le maintien d’une certaine simplicité en ne faisant pas d’abstraction supplémentaire par couche (par exemple, en faisant un partage de fichiers pour chaque disque).

Ensuite, nous avons dû installer les Azure File Sync Agents sur les deux serveurs, un jeu d’enfant avec Powershell CmdLets comme interface d’installation, raison pour laquelle je n’approfondirai pas la question. Vous trouverez un complément d’information ici.

Le résultat

Des groupes de synchronisation

Les points de terminaison

Prochaine étape : migrer toutes les données. Il est essentiel que vous exécutiez ces étapes correctement. Afin que le déploiement s’effectue le plus rapidement possible avec 10 To, vous devez transférer toutes les données sur un seul serveur, afin qu’AFS puisse ensuite synchroniser tous les fichiers sur le second serveur. Si vous essayez de transférer les mêmes données sur les deux serveurs simultanément, cela ne peut que mal tourner.

Nous avons utilisé Robocopy, la solution de copie fiable et éprouvée, pour migrer toutes les données. Robocopy dispose de switches puissants qui en font la solution parfaite pour notre projet.

  • /mir switch : reflète l’arborescence des répertoires. Très pratique pour les deltas et les migrations incrémentielles.
  • /mt:[n] switch: crée des copies multi-threaded avec « N » threads, où N doit être un nombre entier compris entre 1 et 128. Cela a rendu le processus beaucoup plus rapide.
  • /copy:<copyflags> avec les flags D=Data, A=Attributes, T=Time stamps, S=NTFS Access Control List (ACL), O=Owner information et U=Auditing information. Toutes ces valeurs devaient également être copiées.

Parallèlement, il existe encore un certain nombre de switches intéressants, mais nous n'avions besoin que de ces trois-là pour réaliser nos objectifs. Vous trouverez plus d’informations ici.

Azure fournit également de beaux diagrammes visuels qui font l'objet d'améliorations constantes. Vous savez ainsi ce qu’il se passe exactement en un coup d’œil.

Opter ou non pour le tiering dans le cloud ?

Fonction facultative, mais puissante, le tiering dans le cloud d’Azure File Sync met des fichiers souvent utilisés en cache sur le serveur en mode local, alors que tous les autres fichiers sont " hiérarchisés " vers Azure Files en fonction de paramètres stratégiques. Dans ce cadre, le filtre système Azure File Sync (StorageSync.sys) remplace le fichier au niveau local par un pointeur ou un reparse point. Ce dernier est une URL qui renvoie vers le fichier dans Azure Files.

Bien que nous eussions parfaitement pu utiliser cette fonction, nous nous sommes heurtés ici à une autre limitation d’Azure, raison pour laquelle nous avons dû oublier cette fonction pour le moment. Vous pouvez en savoir plus à ce sujet dans la section suivante : backup et stockage.

Quid des backups et de la conservation des fichiers ? 

Des dispositions législatives et de conformité imposaient au client de conserver tous les fichiers pendant au moins dix ans. Nous avons pu respecter cette obligation de plusieurs façons. En voici quelques-unes.

Serveur de backup MABS

Si DPM/MABS offre une granularité totale pour la sauvegarde et la conservation, il n’en reste pas moins qu’en pratique, MABS ne pourrait pas gérer la quantité de données de ce projet. Si vous vouliez ainsi sauvegarder une machine virtuelle avec un ensemble de données supérieur à 3 millions de fichiers, la sauvegarde échouerait systématiquement. De plus, DPM/MABS nécessite une maintenance supplémentaire que nous voulions éviter autant que possible.

Azure Files Backup (aperçu)

Nous avons pu sauvegarder tous les fichiers en sauvegardant les partages de fichiers Azure (nos points de terminaison Azure File Sync). Cela nous permet de restaurer facilement un ou plusieurs fichiers à partir d’un jour donné. Dans l’aperçu, toutefois, vous ne pouvez créer une sauvegarde planifiée qu’une fois par jour. De plus, vous ne pouvez conserver des sauvegardes que pendant 180 jours, alors que notre client doit garder les données pendant au moins dix ans. Cependant, nous avons utilisé cette solution parce qu’il s’agit d’une méthode très simple pour restaurer les données à court terme.

Azure Virtual Machine Backup

Comme nous l’avons mentionné précédemment, Azure Virtual Machine Backup ne prend en charge que les machines virtuelles avec des disques d’une taille maximale de 4 To. Nous nous sommes déjà chargés de ce point au début du projet et nous pouvons donc poursuivre sur notre lancée sans aucun problème.

Azure VM Backup offre toutes les fonctions dont nous avons besoin. Nous pouvons conserver les sauvegardes pendant au moins dix ans, effectuer un backup tous les jours et restaurer facilement nos machines virtuelles et nos données sans maintenance supplémentaire. Il n’y a qu’un seul point d’attention : si nous avions utilisé le tiering dans le cloud auparavant, de nombreux fichiers n’auraient pas été sauvegardés. Ils ne seraient enregistrés que dans Azure Files et la VM elle-même n’aurait que des pointeurs. Comme nous l’avons déjà souligné, nous avons donc dû abandonner la fonction de tiering dans le cloud.

Cependant, Azure Virtual Machine Backup nous a permis de concevoir une bonne solution de sauvegarde qui répond à tous nos besoins.

Conclusion

Nous avons déployé un environnement de serveur de fichiers complet avec AFS et DFS pour créer un environnement à haute disponibilité. L’infrastructure est fiable, performante, facile à entretenir et à restaurer, surveillée et flexible. Grâce aux fonctions pratiques d’Azure, chaque projet se transforme en succès.

Voulez-vous en savoir plus sur nos solutions Azure ? N’hésitez pas à consulter notre site web !

Partager cet article de blog
Tags: Azure

Laissez une réponse

Votre adresse email ne sera pas publiée. Les champs requis sont indiqués.