Si vous comptez utiliser Amazon FSx for OpenZFS, mieux vaut connaître les types de déploiement et leur fonctionnement en coulisses. Trois types de déploiement sont actuellement pris en charge : Single-AZ (non-HA), Single-AZ (HA) et Multi-AZ (HA).
Lors de la configuration de votre nouveau système de fichiers, deux méthodes de création s'offrent à vous : Quick Create et Standard Create. Quick Create propose une procédure simplifiée, tandis que Standard Create offre des options de configuration bien plus complètes.
En réalité, Standard Create n'est pas seulement recommandée — elle est même obligatoire pour deux des trois types de déploiement. C'est donc le choix à privilégier dans la plupart des cas, car elle vous donne dès le départ un meilleur contrôle sur la configuration de votre système de fichiers.
Type de déploiement Single-AZ (non-HA)
Avec Single-AZ (non-HA), vous devez impérativement passer par la procédure Standard Create, car ce type de déploiement n'est pas disponible via Quick Create (voir figure 1). Vous obtenez un seul système de fichiers ; en cas de panne, celui-ci est censé se rétablir automatiquement en remplaçant le composant d'infrastructure défaillant. Une interruption de service surviendra toutefois pendant la panne, accompagnée d'une perte de données. Dans de rares cas, le système de fichiers peut s'avérer irrécupérable, et vous perdrez alors toutes les données qui n'auront pas été sauvegardées.
Veillez à bien rattacher le bon security group et à créer la règle adéquate pour autoriser le trafic (avec Quick Create, le security group par défaut du VPC est rattaché automatiquement). Ce point vaut pour tous les types de déploiement.
Figure 1 — interface de création FSx pour Quick Create.
Type de déploiement Single-AZ (HA)
Avec Single-AZ (HA), vous pouvez choisir indifféremment Quick Create ou Standard Create, mais mieux vaut opter pour Standard Create afin de pouvoir sélectionner le sous-réseau et le security group de votre choix.
Ce type de déploiement crée 2 systèmes de fichiers au sein du même sous-réseau, ainsi qu'une adresse IP de point de terminaison (Endpoint IP, sur laquelle nous reviendrons plus en détail dans la partie Multi-AZ). Cette Endpoint IP sert à FSx pour gérer les bascules dans ce type de déploiement. Le FSx dispose d'un nom DNS qui pointe vers l'Endpoint IP, et celle-ci est rattachée à l'ENI du système de fichiers actuellement actif en tant qu'adresse IP secondaire. Lors d'une bascule, l'Endpoint IP est détachée de l'ENI du système actif et rattachée à l'ENI du système de secours. Le DNS pointe alors toujours vers la même IP, mais celle-ci est désormais associée à l'ENI de secours, jusqu'au rétablissement complet du système principal.
Ces deux types de déploiement permettent de monter votre système de fichiers sur vos instances EC2 avec une configuration minimale. Une étape supplémentaire est en revanche requise avec le type Multi-AZ.
Type de déploiement Multi-AZ
Avec le type de déploiement Multi-AZ, il est essentiel de toujours privilégier Standard Create plutôt que Quick Create, car cette dernière ne permet pas de choisir les sous-réseaux ni d'associer des tables de routage. L'association de tables de routage au système de fichiers FSx n'est en effet disponible que pour les configurations Multi-AZ.
Une configuration Multi-AZ créée via Quick Create n'utilisera que la table de routage par défaut, alors que vos sous-réseaux utilisent probablement leurs propres tables de routage. Pourquoi est-ce important ? Tout simplement parce qu'avec cette configuration, vous n'aurez pas de connectivité réseau immédiate et votre connexion expirera. C'est précisément ce qui est arrivé à l'un de mes clients qui avait tenté Quick Create, et c'est ce qui nous a poussés à approfondir le sujet pour en comprendre le fonctionnement.
On pourrait s'attendre à ce que les ressources d'un même VPC se connectent automatiquement à votre système de fichiers FSx via la route local — après tout, c'est ainsi que l'on accède à d'autres services AWS comme RDS, ElastiCache et les instances EC2 de votre VPC, et même aux systèmes de fichiers FSx Single-AZ. Pourtant, voici la subtilité inattendue : cette hypothèse ne tient pas dans ce cas précis. La route local seule ne suffit pas à établir la connectivité avec votre système de fichiers FSx dans ces conditions.
Comment activer la connectivité dans ce scénario ? Réponse rapide : vous devez associer au système de fichiers FSx les tables de routage des sous-réseaux dans lesquels résident vos instances EC2. Pour cela, cliquez sur manage à côté de route tables et associez ou dissociez les tables de routage (voir figure 2).
Figure 2 — modification de l'association des tables de routage FSx.
Une fois la connectivité activée, vous remarquerez l'apparition d'une entrée d'ENI dans votre table de routage (voir figure 3). C'est cette route ENI qui permet à votre instance d'atteindre le système de fichiers FSx. L'entrée se compose d'une Endpoint IP et de l'ENI du système de fichiers actuellement actif.
Figure 3 — entrée ENI dans vos tables de routage associées.
Cette configuration vise à permettre la procédure de bascule. Comme pour Single-AZ (HA), nous utilisons une Endpoint IP, mais celle-ci ne peut pas être déplacée entre des ENI situées dans des AZ différentes. De plus, l'Endpoint IP est créée au sein d'un sous-réseau existant en Single-AZ (HA), ce qui n'est pas le cas en déploiement Multi-AZ.
Configuration Multi-AZ
Lorsque vous configurez FSx en mode Multi-AZ, deux systèmes de fichiers distincts sont créés dans deux sous-réseaux situés dans des AZ différentes, à des fins de redondance. Chaque système de fichiers possède sa propre Elastic Network Interface (ENI). Pendant la configuration, FSx a besoin d'une adresse IP particulière (une IP flottante) qui servira aux bascules. Il s'agit d'une adresse unique (/32).
Vous pouvez spécifier vous-même la plage d'adresses IP via le paramètre EndpointIpAddressRange, ou laisser FSx choisir automatiquement une plage CIDR /28 inutilisée dans votre VPC.
Un détail important concernant cette IP flottante : bien qu'elle se situe dans la plage IP de votre VPC, elle est volontairement placée en dehors de toute plage de sous-réseau existante. Du point de vue réseau d'Amazon EC2, cette adresse IP n'est donc liée à aucune ressource réseau ni à aucun sous-réseau spécifique.
Vos systèmes de fichiers et leurs ENI restent dans vos sous-réseaux, mais l'Endpoint IP, l'IP flottante, ne se trouve dans aucun CIDR de sous-réseau de votre VPC. L'entrée dans la table de routage est nécessaire pour acheminer le trafic destiné à l'IP flottante vers la bonne ENI du système de fichiers actuellement actif. Sans cette route, le trafic est rejeté, l'IP flottante ne faisant partie d'aucun sous-réseau (voir figure 4).
Cette configuration s'explique par le fait que FSx n'effectue pas de bascule basée sur le DNS, en raison des limitations de bascule du client NFS. Les résolutions DNS ne sont effectuées qu'une seule fois, au moment du montage. FSx doit donc s'appuyer sur un mécanisme de bascule différent de celui généralement employé par d'autres services AWS Multi-AZ comme RDS, sans quoi les clients NFS devraient remonter le système de fichiers après chaque bascule.
En résumé, pour permettre une bascule transparente entre les systèmes de fichiers Multi-AZ principal et de secours, il vous faut l'entrée ENI dans les tables de routage des sous-réseaux où sont déployés vos clients. Lors d'une bascule, FSx mettra à jour l'ensemble des tables de routage client associées au FSx, de sorte que l'IP flottante (destination) reste inchangée, mais que la cible devienne celle du système de fichiers de secours pendant la bascule.
Figure 4 — configuration FSx.
Synthèse
Cet article a abordé la mise en œuvre d'Amazon FSx for OpenZFS, les options de création, le fonctionnement réseau et les raisons pour lesquelles les implémentations diffèrent selon les types de déploiement.
Des questions sur la mise en œuvre de FSx for OpenZFS dans votre organisation ?
Si vous vous demandez encore comment tirer parti d'une configuration OpenZFS Multi-AZ — ou de toute autre solution d'infrastructure GCP ou AWS — au sein de votre organisation, nous sommes là pour vous aider.
Chez DoiT International, notre équipe est composée exclusivement d'ingénieurs seniors. Nous sommes spécialisés dans le conseil cloud avancé, la conception d'architecture et les services de débogage. Que vous fassiez vos premiers pas avec les bases de données distribuées, que vous optimisiez un système existant ou que vous résolviez des problèmes complexes, nous vous proposons des conseils d'experts adaptés à vos besoins.
Contactez-nous dès aujourd'hui et exploitez tout le potentiel de votre infrastructure cloud.