Disponibilité et durabilité : systèmes de fichiers mono-AZ et multi-AZ

Amazon FSx pour Windows File Server propose deux types de déploiement de systèmes de fichiers : mono-AZ et multi-AZ. Les sections suivantes fournissent des informations qui vous aideront à choisir le type de déploiement adapté à vos charges de travail. Pour plus d'informations sur la disponibilité du service SLA (Service Level Agreement), consultez Amazon FSx Service Level Agreement.

Les systèmes de fichiers mono-AZ sont composés d'une seule instance de serveur de fichiers Windows et d'un ensemble de volumes de stockage au sein d'une seule zone de disponibilité (AZ). Avec les systèmes de fichiers mono-AZ, les données sont automatiquement répliquées afin de les protéger contre la défaillance d'un seul composant dans la plupart des cas. Amazon surveille FSx en permanence les défaillances matérielles et se rétablit automatiquement en cas de panne en remplaçant le composant d'infrastructure défaillant. Les systèmes de fichiers mono-AZ sont hors ligne, généralement pendant moins de 20 minutes, pendant ces événements de reprise en cas de panne et pendant la maintenance planifiée du système de fichiers pendant la période de maintenance que vous configurez pour votre système de fichiers. Avec les systèmes de fichiers mono-AZ, une défaillance du système de fichiers peut être irréparable dans de rares cas, par exemple en raison de défaillances de plusieurs composants ou d'une défaillance involontaire du serveur de fichiers unique qui laisse le système de fichiers dans un état incohérent. Dans ce cas, vous pouvez récupérer votre système de fichiers à partir de la sauvegarde la plus récente.

Les systèmes de fichiers multi-AZ sont composés d'un cluster à haute disponibilité de serveurs de fichiers Windows répartis sur deux AZs (un AZ préféré et un AZ de secours), tirant parti de la technologie Windows Server Failover Clustering (WSFC) et d'un ensemble de volumes de stockage sur chacun des deux. AZs Les données sont répliquées de manière synchrone au sein de chaque AZ et entre les deux. AZs Par rapport au déploiement mono-AZ, les déploiements multi-AZ offrent une durabilité accrue en répliquant davantage les donnéesAZs, une disponibilité accrue lors de la maintenance planifiée du système et des interruptions de service imprévues en basculant automatiquement vers l'AZ de secours. Cela vous permet de continuer à accéder à vos données et de les protéger contre les défaillances d'instance et les perturbations de l'AZ.

Choix du type de déploiement d'un système de fichiers mono-AZ ou multi-AZ

Nous recommandons d'utiliser des systèmes de fichiers multi-AZ pour la plupart des charges de travail de production étant donné le modèle de haute disponibilité et de durabilité qu'ils offrent. Le déploiement mono-AZ est conçu comme une solution rentable pour les charges de travail de test et de développement, certaines charges de travail de production dont la réplication est intégrée à la couche applicative et ne nécessitent pas de redondance supplémentaire au niveau du stockage, et les charges de travail de production qui ont assoupli les exigences en matière de disponibilité et d'objectif de point de restauration (). RPO Les charges de travail dont la disponibilité et les RPO besoins sont limités peuvent tolérer une perte de disponibilité temporaire pouvant aller jusqu'à 20 minutes en cas de maintenance planifiée du système de fichiers ou d'interruption de service imprévue et, dans de rares cas, de perte de mises à jour des données depuis la dernière sauvegarde.

Nous vous recommandons également de revoir le modèle de disponibilité de votre système de fichiers et de vous assurer que votre charge de travail résiste au comportement de restauration attendu pour le type de déploiement que vous choisissez lors d'événements tels que la maintenance du système de fichiers, les modifications de capacité de débit et les interruptions de service imprévues.

Support des fonctionnalités par type de déploiement

Le tableau suivant récapitule les fonctionnalités prises en charge par FSx les types de déploiement de systèmes de fichiers Windows File Server :

Type de déploiement	SSDrangement	HDDrangement	DFSespaces de noms	DFSréplication	DNSNoms personnalisés	Actions CA
Mono-AZ 1	✓		✓	✓	✓
Mono-AZ 2	✓	✓	✓		✓	✓*
Multi-AZ	✓	✓	✓		✓	✓*

Note

* Bien que vous puissiez créer des partages disponibles en continu (CA) sur des systèmes de fichiers mono-AZ 2, vous devez utiliser des partages CA sur des systèmes de fichiers multi-AZ pour les déploiements SQL Server HA.

Processus de basculement FSx pour Windows File Server

Les systèmes de fichiers multi-AZ basculent automatiquement du serveur de fichiers préféré vers le serveur de fichiers de secours si l'une des conditions suivantes se produit :

• Une panne de zone de disponibilité se produit.

• Le serveur de fichiers préféré devient indisponible.

• Le serveur de fichiers préféré fait l'objet d'une maintenance planifiée.

En cas de basculement d'un serveur de fichiers à un autre, le nouveau serveur de fichiers actif commence automatiquement à traiter toutes les demandes de lecture et d'écriture du système de fichiers. Lorsque les ressources du sous-réseau préféré sont disponibles, Amazon revient FSx automatiquement au serveur de fichiers préféré dans le sous-réseau préféré. Un basculement s'effectue généralement en moins de 30 secondes entre la détection de la panne sur le serveur de fichiers actif et le passage du serveur de fichiers de secours à l'état actif. Le retour à la configuration multi-AZ d'origine s'effectue également en moins de 30 secondes et ne se produit qu'une fois que le serveur de fichiers du sous-réseau préféré est complètement restauré.

Pendant la brève période pendant laquelle votre système de fichiers bascule puis retombe en panne, les E/S peuvent être interrompues et les CloudWatch métriques Amazon peuvent être temporairement indisponibles.

Pour les systèmes de fichiers multi-AZ, si le trafic est permanent pendant le basculement et le retour en arrière, toutes les modifications de données effectuées pendant cette période devront être synchronisées entre les serveurs de fichiers. Ce processus peut prendre plusieurs heures pour les charges de travail exigeantes en écriture ou en IOPS écriture. Nous vous recommandons de tester l'impact des basculements sur votre application lorsque votre système de fichiers est moins chargé.

Expérience de basculement sur les clients Windows

En cas de basculement d'un serveur de fichiers à un autre, le nouveau serveur de fichiers actif commence automatiquement à traiter toutes les demandes de lecture et d'écriture du système de fichiers. Une fois que les ressources du sous-réseau préféré sont disponibles, Amazon revient FSx automatiquement au serveur de fichiers préféré dans le sous-réseau préféré. Comme le DNS nom du système de fichiers reste le même, les basculements sont transparents pour les applications Windows, qui reprennent les opérations du système de fichiers sans intervention manuelle. Un basculement s'effectue généralement en moins de 30 secondes entre la détection de la panne sur le serveur de fichiers actif et le passage du serveur de fichiers de secours à l'état actif. Le retour à la configuration multi-AZ d'origine s'effectue également en moins de 30 secondes et ne se produit qu'après la restauration complète du serveur de fichiers du sous-réseau préféré.

Expérience de basculement sur les clients Linux

Les clients Linux ne prennent pas en charge le DNS basculement automatique. Par conséquent, ils ne se connectent pas automatiquement au serveur de fichiers de secours lors d'un basculement. Ils reprendront automatiquement les opérations du système de fichiers une fois que le système de fichiers multi-AZ aura échoué sur le serveur de fichiers du sous-réseau préféré.

Test du basculement sur un système de fichiers

Vous pouvez tester le basculement de votre système de fichiers multi-AZ en modifiant sa capacité de débit. Lorsque vous modifiez la capacité de débit de votre système de fichiers, Amazon FSx désactive le serveur de fichiers du système de fichiers. Les systèmes de fichiers multi-AZ basculent automatiquement vers le serveur secondaire tandis qu'Amazon FSx remplace d'abord le serveur de fichiers du serveur préféré. Ensuite, le système de fichiers revient automatiquement sur le nouveau serveur principal et Amazon FSx remplace le serveur de fichiers secondaire.

Vous pouvez suivre la progression de la demande de mise à jour de la capacité de débit dans la FSx console Amazon, leCLI, et leAPI. Une fois la mise à jour terminée avec succès, votre système de fichiers est redirigé vers le serveur secondaire, puis de nouveau vers le serveur principal. Pour plus d'informations sur la modification de la capacité de débit de votre système de fichiers et le suivi de la progression de la demande, consultezGestion de la capacité de débit sur FSx les systèmes de fichiers Windows File Server.

Utilisation des ressources d'un système de fichiers mono-AZ ou multi-AZ

Sous-réseaux

Lorsque vous créez unVPC, il couvre toutes les zones de disponibilité (AZs) de la région. Les zones de disponibilité sont des emplacements distincts conçus pour être isolés des défaillances dans d'autres zones de disponibilité. Après avoir créé unVPC, vous pouvez ajouter un ou plusieurs sous-réseaux dans chaque zone de disponibilité. La valeur par défaut VPC possède un sous-réseau dans chaque zone de disponibilité. Chaque sous-réseau doit résider entièrement dans une zone de disponibilité et ne peut pas s'étendre sur plusieurs zones. Lorsque vous créez un système de FSx fichiers Amazon mono-AZ, vous spécifiez un sous-réseau unique pour le système de fichiers. Le sous-réseau que vous choisissez définit la zone de disponibilité dans laquelle le système de fichiers est créé.

Lorsque vous créez un système de fichiers multi-AZ, vous spécifiez deux sous-réseaux, l'un pour le serveur de fichiers préféré et l'autre pour le serveur de fichiers de secours. Les deux sous-réseaux que vous choisissez doivent se trouver dans des zones de disponibilité différentes au sein de la même AWS région.

Pour les AWS applications intégrées, nous vous recommandons de lancer vos clients dans la même zone de disponibilité que votre serveur de fichiers préféré afin de minimiser le temps de latence.

Interfaces réseau élastiques pour systèmes de fichiers

Lorsque vous créez un système de FSx fichiers Amazon, Amazon FSx fournit une ou plusieurs interfaces réseau élastiques dans l'Amazon Virtual Private Cloud (VPC) que vous associez à votre système de fichiers. L'interface réseau permet à votre client de communiquer avec le système de fichiers FSx for Windows File Server. L'interface réseau est considérée comme relevant du champ d'application des services d'AmazonFSx, même si elle fait partie de celle de votre compteVPC. Les systèmes de fichiers multi-AZ disposent de deux interfaces réseau élastiques, une pour chaque serveur de fichiers. Les systèmes de fichiers mono-AZ disposent d'une interface Elastic Network.

Avertissement

Vous ne devez ni modifier ni supprimer les interfaces réseau élastiques associées à votre système de fichiers. La modification ou la suppression de l'interface réseau peut entraîner une perte permanente de connexion entre votre système de fichiers VPC et votre système de fichiers.

Le tableau suivant récapitule les ressources relatives au sous-réseau, à l'interface Elastic Network et aux adresses IP FSx pour les types de déploiement de systèmes de fichiers Windows File Server :

Type de déploiement du système de fichiers	Nombre de sous-réseaux	Nombre d'interfaces réseau élastiques	Nombre d'adresses IP
Mono-AZ 2	1	1	2
Mono-AZ 1	1	1	1
Multi-AZ	2	2	4

Une fois qu'un système de fichiers est créé, ses adresses IP ne changent pas tant que le système de fichiers n'est pas supprimé.

Important

Amazon FSx ne prend pas en charge l'accès aux systèmes de fichiers depuis l'Internet public ou l'exposition de systèmes de fichiers à celui-ci. Si une adresse IP élastique, qui est une adresse IP publique accessible depuis Internet, est attachée à l'interface Elastic Network d'un système de fichiers, Amazon la détache FSx automatiquement.