Prévoir le déploiement d'Azure Files

2025-04-23

Vous pouvez déployer Azure Files de deux façons principales : en montant directement les partages de fichiers Azure serverless ou en mettant en cache des partages de fichiers Azure localement à l’aide d’Azure File Sync. Les considérations relatives au déploiement diffèrent selon l’option que vous choisissez.

Montage direct d’un partage de fichiers Azure : Azure Files fournissant un accès SMB ou NFS, vous pouvez monter des partages de fichiers Azure localement ou dans le cloud à l’aide des clients SMB ou NFS standard qui sont disponibles dans votre système d’exploitation. Étant donné que les partages de fichiers Azure sont serverless, le déploiement pour les scénarios de production ne nécessite pas la gestion d’un serveur de fichiers ni d’un périphérique NAS. Concrètement, cela signifie que vous n'avez aucun correctif logiciel à appliquer ni aucun disque physique à remplacer.
Mise en cache d’un partage de fichiers Azure localement à l’aide d’Azure File Sync : Azure File Sync vous permet de centraliser les partages de fichiers de votre organisation dans Azure Files, tout en conservant la flexibilité, le niveau de performance et la compatibilité d’un serveur de fichiers local. Azure File Sync transforme une instance Windows Server locale (ou cloud) en cache rapide de votre partage de fichiers SMB Azure.

Cet article traite principalement de considérations relatives au déploiement, afin de déployer un partage de fichiers Azure en vue de son montage directement par un client local ou un client cloud. Pour planifier un déploiement d’Azure File Sync, consultez Planification d’un déploiement Azure File Sync.

Protocoles disponibles

Azure Files propose deux protocoles de système de fichiers standard pour le montage de partages de fichiers Azure : SMB (Server Message Block) et NFS (Network File System), ce qui vous permet de choisir le protocole le mieux adapté à votre charge de travail. Les partages de fichiers Azure ne prennent pas en charge le protocoles SMB et NFS à la fois dans un même partage de fichiers. Cependant, vous pouvez créer des partages de fichiers SMB et NFS au sein d’un même compte de stockage.

Avec les partages de fichiers SMB et NFS, Azure Files propose des partages de fichiers d’entreprise qui peuvent être mis à l’échelle pour répondre à vos besoins de stockage et qui permettent l’accès simultané de milliers de clients.

Fonctionnalité	PME	Système de fichiers en réseau (NFS)
Versions des protocoles prises en charge	SMB 3.1.1, SMB 3.0, SMB 2.1	NFS 4.1
Système d’exploitation recommandé	Windows 11, version 21H2+ Windows 10, version 21H1+ Windows Server 2019+ Version 5.3+ du noyau Linux	Version 4.3+ du noyau Linux
Niveaux disponibles	SSD et HDD	SSD uniquement
Redondance	Local (LRS) Zone (ZRS) Géo (GRS) GeoZone (GZRS)	Local (LRS) Zone (ZRS)
Sémantique du système de fichiers	Win32	POSIX
Authentification	Authentification basée sur l’identité (Kerberos), authentification par clé partagée (NTLMv2)	Authentification basée sur l’hôte
Autorisation	Listes de contrôle d’accès de type Win32	Autorisations de style UNIX
Respect de la casse	Non sensible à la casse, casse conservée	Sensible à la casse
Suppression ou modification de fichiers ouverts	Avec verrou uniquement	Oui
Partage de fichiers	Mode de partage Windows	Gestionnaire de verrous réseau de plage d’octets conseillés
Prise en charge des liens physiques	Non prise en charge	Soutenu
Prise en charge des liens symboliques	Non prise en charge	Soutenu
Accessible par Internet (facultatif)	Oui (SMB 3.0+ uniquement)	Non
Prend en charge FileREST	Oui	Sous-ensemble : Opérations sur `FileService` Opérations sur `FileShares` Opérations sur `Directories` Opérations sur `Files`
Verrous de plages d’octets obligatoires	Soutenu	Non prise en charge
Verrous de plages d’octets conseillés	Non prise en charge	Soutenu
Attributs étendus/nommés	Non prise en charge	Non prise en charge
Autres flux de données	Non prise en charge	N/A
Identificateurs d'objet	Non prise en charge	N/A
Points d’analyse	Non prise en charge	N/A
Fichiers partiellement alloués	Non prise en charge	N/A
Compression	Non prise en charge	N/A
Canaux nommés	Non prise en charge	N/A
SMB direct	Non prise en charge	N/A
Bail de répertoire SMB	Non prise en charge	N/A
Cliché instantané de volume	Non prise en charge	N/A
Noms de fichier courts (alias 8.3)	Non prise en charge	N/A
Service de serveur	Non prise en charge	N/A
Transactions de système de fichiers (TxF)	Non prise en charge	N/A

Concepts de gestion

Les partages de fichiers Azure sont déployés dans des comptes de stockage, qui sont des objets de niveau supérieur représentant un pool de stockage partagé. Les comptes de stockage peuvent être utilisés pour déployer plusieurs partages de fichiers, ainsi que d’autres ressources de stockage en fonction du type de compte de stockage. Toutes les ressources de stockage qui sont déployées dans un compte de stockage partagent les limites qui s’appliquent à ce compte de stockage. Pour voir les limites actuelles d’un compte de stockage, consultez Objectifs de scalabilité et de performances d’Azure Files.

Il existe deux principaux types de comptes de stockage utilisés pour les déploiements Azure Files :

Comptes de stockage provisionnés : les comptes de stockage provisionnés se distinguent à l’aide du type de FileStorage compte de stockage. Les comptes de stockage provisionnés vous permettent de déployer des partages de fichiers provisionnés sur du matériel SSD ou HDD. Les comptes de stockage provisionnés ne peuvent être utilisés que pour stocker des partages de fichiers Azure. Les partages de fichiers NFS ne peuvent être déployés que dans des comptes de stockage approvisionnés dans le niveau multimédia SSD. Nous vous recommandons d’utiliser les comptes de stockage provisionnés pour tous les nouveaux déploiements d’Azure Files.
Comptes de stockage à la demande : les comptes de stockage à la demande se distinguent grâce au type de StorageV2 compte de stockage. Les comptes de stockage à la demande vous permettent de déployer des partages de fichiers sur du matériel à base de HDD selon le principe du paiement à l’usage. En plus de stocker les partages de fichiers Azure, les comptes de stockage GPv2 peuvent stocker d’autres ressources de stockage, telles que des conteneurs d’objets blob, des files d’attente ou des tables.

Identité

Pour accéder à un partage de fichiers Azure, l’utilisateur du partage de fichiers doit être authentifié et autorisé à accéder au partage. Cette opération s’effectue en fonction de l’identité de l’utilisateur accédant au partage de fichiers. Azure Files prend en charge les méthodes d’authentification suivantes :

Active Directory Domain Services en local (AD DS ou AD DS en local) : Les comptes de stockage Azure peuvent être joints à un domaine sur une instance Active Directory Domain Services appartenant à un client, exactement comme un serveur de fichiers Windows Server ou un appareil NAS. Votre contrôleur de domaine peut être déployé localement, dans une machine virtuelle Azure, ou même en tant que machine virtuelle dans un autre fournisseur de cloud. Azure Files ne dépend pas de l’emplacement où votre contrôleur de domaine est hébergé. Dès lors qu’un compte de stockage est joint à un domaine, l’utilisateur final peut monter un partage de fichiers avec le compte d’utilisateur dont il s’est servi pour se connecter à son PC. L’authentification basée sur Active Directory utilise le protocole d’authentification Kerberos.
Microsoft Entra Domain Services : Microsoft Entra Domain Services fournit un contrôleur de domaine managé par Microsoft qui peut être utilisé pour les ressources Azure. La jonction de domaine de votre compte de stockage à Microsoft Entra Domain Services offre des avantages similaires à la jonction de domaine à une instance AD DS détenue par le client. Cette option de déploiement est particulièrement utile pour les scénarios lift-and-shift d’application qui nécessitent des autorisations basées sur AD. Étant donné que Microsoft Entra Domain Services fournit une authentification basée sur AD, cette option utilise également le protocole d’authentification Kerberos.
Microsoft Entra Kerberos pour les identités hybrides : Microsoft Entra Kerberos vous permet d’utiliser Microsoft Entra ID pour authentifier des identités utilisateur hybrides, qui sont des identités AD locales synchronisées avec le cloud. Cette configuration utilise Microsoft Entra ID pour émettre des tickets Kerberos visant à accéder au partage de fichiers avec le protocole SMB. Cela signifie que vos utilisateurs finaux peuvent accéder à des partages de fichiers Azure par Internet sans avoir besoin d’une connectivité réseau aux contrôleurs de domaine des machines virtuelles jointes à Microsoft Entra de façon classique ou hybride.
Authentification Active Directory sur SMB pour les clients Linux : Azure Files prend en charge l’authentification basée sur l’identité sur SMB pour les clients Linux à l’aide du protocole d’authentification Kerberos via AD DS ou Microsoft Entra Domain Services.
Clé de compte de stockage Azure : bien qu’il ne soit pas recommandé pour des raisons de sécurité, vous pouvez également monter des partages de fichiers Azure à l’aide d’une clé de compte de stockage Azure au lieu d’utiliser une identité. Pour monter un partage de fichiers à l’aide de la clé de compte de stockage, le nom du compte de stockage est utilisé comme nom d’utilisateur et la clé de compte de stockage est utilisée comme mot de passe. L’utilisation de la clé de compte de stockage pour monter le partage de fichiers Azure est effectivement une opération d’administrateur, car le partage de fichiers monté dispose d’autorisations complètes pour tous les fichiers et dossiers sur le partage, même s’ils ont des listes de contrôle d’accès. Lors de l’utilisation de la clé de compte de stockage pour le montage sur SMB, le protocole d’authentification NTLMv2 est utilisé. Dans presque tous les cas, nous vous recommandons d’utiliser l’authentification basée sur l’identité au lieu de la clé de compte de stockage pour accéder aux partages de fichiers Azure SMB. Toutefois, si vous devez utiliser la clé de compte de stockage, nous vous recommandons d’utiliser des points de terminaison privés ou des points de terminaison de service, comme décrit dans la section Mise en réseau .

Pour les clients qui migrent à partir de serveurs de fichiers locaux ou créent des partages de fichiers dans Azure Files destinés à se comporter comme des serveurs de fichiers Windows ou des appliances NAS, il est recommandé de joindre votre compte de stockage à AD DS appartenant au client . Pour en savoir plus sur la jonction de domaine de votre compte de stockage à un environnement AD DS appartenant au client, consultez Vue d’ensemble - Authentification Active Directory Domain Services locale sur SMB pour les partages de fichiers Azure.

Mise en réseau

Le montage direct de votre partage de fichiers Azure requiert souvent une certaine réflexion en termes de configuration réseau, car :

Le port que les partages de fichiers SMB utilisent pour la communication, le port 445, est souvent bloqué par nombre d’organisations et de fournisseurs de services Internet (ISP) pour le trafic sortant (Internet).
Les partages de fichiers NFS s’appuient sur l’authentification au niveau du réseau et sont dès lors uniquement accessibles via des réseaux restreints. L’utilisation d’un partage de fichiers NFS nécessite systématiquement un certain niveau de configuration réseau.

Pour configurer la mise en réseau, Azure Files fournit un point de terminaison public accessible sur Internet et une intégration à des fonctionnalités de mise en réseau Azure telles que les points de terminaison de service, qui permettent de restreindre le point de terminaison public aux réseaux virtuels spécifiés et aux points de terminaison privés, ce qui donne à votre compte de stockage une adresse IP privée à partir d’un espace d’adressage IP de réseau virtuel. Bien qu’il n’y ait aucuns frais supplémentaires pour l’utilisation de points de terminaison publics ou de service, des taux de traitement des données standard s’appliquent pour les points de terminaison privés.

Cela signifie que vous devez prendre en compte les configurations réseau suivantes :

Si le protocole requis est SMB et que tous les accès via SMB proviennent de clients Azure, aucune configuration réseau spéciale n’est nécessaire.
Si le protocole requis est SMB et que l’accès provient de clients locaux, une connexion VPN ou ExpressRoute locale à votre réseau Azure est nécessaire, avec Azure Files exposé sur votre réseau interne à l’aide de points de terminaison privés.
Si le protocole requis est NFS, vous pouvez utiliser des points de terminaison de service ou des points de terminaison privés pour restreindre le réseau aux réseaux virtuels spécifiés. Si vous avez besoin d’une adresse IP statique et/ou si votre charge de travail nécessite une haute disponibilité, utilisez un point de terminaison privé. Avec les points de terminaison de service, un événement rare tel qu’une panne zonale peut entraîner la modification de l’adresse IP sous-jacente du compte de stockage. Les données sont toujours disponibles sur le partage de fichiers, mais le client aura besoin d’un nouveau montage du partage.

Pour en savoir plus sur la configuration de la mise en réseau pour Azure Files, consultez Considérations relatives à la mise en réseau Azure Files.

En plus de se connecter directement au partage de fichiers à l’aide du point de terminaison public ou d’une connexion VPN/ExpressRoute avec un point de terminaison privé, SMB fournit une stratégie d’accès client supplémentaire : SMB sur QUIC. SMB sur QUIC offre un « VPN SMB » sans configuration pour l’accès SMB via le protocole de transport QUIC. Si Azure Files ne prend pas directement en charge SMB sur QUIC, vous pouvez créer un cache léger de vos partages de fichiers Azure sur une machine virtuelle Windows Server 2022 Azure Edition à l’aide d’Azure File Sync. Pour en savoir plus sur cette option, consultez SMB sur QUIC avec Azure File Sync.

Chiffrement

Azure Files prend en charge deux types de chiffrement différents :

Chiffrement en transit, qui concerne le chiffrement utilisé lors du montage/de l’accès au partage de fichiers Azure
Chiffrement au repos, qui concerne la façon dont les données sont chiffrées lorsqu’elles sont stockées sur le disque

Chiffrement en transit

Par défaut, le chiffrement en transit est activé pour tous les comptes de stockage Azure. Cela signifie que lorsque vous montez un partage de fichiers sur SMB ou que vous y accédez via le protocole FileREST (par exemple via le portail Azure, PowerShell/CLI ou les kits sdk Azure), Azure Files autorise uniquement la connexion si elle est établie avec SMB 3.x avec chiffrement ou HTTPS. Les clients qui ne prennent pas en charge le protocole SMB 3.x, ou qui prennent en charge le protocole SMB 3.x mais pas le chiffrement SMB, ne peuvent pas monter le partage de fichiers Azure si le chiffrement en transit est activé. Pour plus d’informations sur les systèmes d’exploitation prenant en charge SMB 3.x avec chiffrement, consultez notre documentation pour Windows, macOS et Linux. Toutes les versions actuelles de PowerShell, de CLI et des SDK prennent en charge le protocole HTTPS.

Vous pouvez désactiver le chiffrement en transit pour un compte de stockage Azure. Lorsque le chiffrement est désactivé, Azure Files autorise également SMB 2.1 et SMB 3.x sans chiffrement, et les appels d’API FileREST non chiffrés via HTTP. La principale raison justifiant de désactiver le chiffrement en transit est la nécessité de prendre en charge une application héritée devant être exécutée sur un système d’exploitation plus ancien, tel que Windows Server 2008 R2 ou une distribution Linux plus ancienne. Azure Files n’autorise que les connexions SMB 2.1 dans la même région Azure que le partage de fichiers Azure. Ainsi, un client SMB 2.1 situé en dehors de la région Azure dans laquelle se trouve le partage de fichiers Azure, par exemple, localement ou dans une autre région Azure, ne peut pas accéder au partage de fichiers.

Nous recommandons vivement de vérifier que le chiffrement des données en transit est activé.

Pour plus d’informations sur le chiffrement en transit, consultez exiger un transfert sécurisé dans le stockage Azure et le chiffrement en transit pour les partages de fichiers Azure NFS.

Chiffrement au repos

Toutes les données stockées dans Azure Files sont chiffrées au repos avec Azure Storage Service Encryption (SSE). Cette fonctionnalité fonctionne de la même façon que BitLocker sur Windows : les données sont chiffrées sous le niveau du système de fichiers. Comme les données sont chiffrées sous le système de fichiers du partage de fichiers Azure, car codées sur le disque, il n’est pas nécessaire d’avoir accès à la clé sous-jacente sur le client pour lire ou écrire sur le partage de fichiers Azure. Le chiffrement au repos s’applique aux protocoles SMB et NFS.

Par défaut, les données stockées dans Azure Files sont chiffrées avec des clés managées par Microsoft. Microsoft détient ainsi les clés permettant de chiffrer et de déchiffrer les données et se charge de les renouveler régulièrement. Vous pouvez également choisir de gérer vos propres clés, ce qui vous permet de contrôler le processus de renouvellement. Si vous choisissez de chiffrer vos partages de fichiers avec des clés gérées par le client, Azure Files est autorisé à accéder à vos clés pour traiter les demandes de lecture et d’écriture de vos clients. Vous pouvez révoquer cette autorisation à tout moment grâce aux clés gérées par le client, mais ce qui signifie que votre partage de fichiers Azure ne sera plus accessible via SMB ou l’API FileREST.

Azure Files utilise le même schéma de chiffrement que les autres services de stockage Azure, comme le Stockage Blob Azure. Pour plus d’informations sur Azure Storage Service Encryption (SSE), consultez Chiffrement du stockage Azure pour les données au repos.

Protection de données

Azure Files adopte une approche multicouche pour garantir que vos données sont sauvegardées, récupérables et protégées contre les menaces de sécurité. Consultez Azure Files vue d’ensemble de la protection des données.

Suppression réversible

La suppression réversible est un paramètre au niveau du compte de stockage qui vous permet de récupérer votre partage de fichiers lorsqu’il est supprimé accidentellement. Lors de la suppression d’un partage de fichiers, celui-ci passe par un état transitoire de suppression réversible au lieu d’être supprimé définitivement. Vous pouvez configurer la durée pendant laquelle les partages supprimés de manière réversible sont récupérables avant leur suppression définitive, et annuler la suppression du partage à tout moment lors de cette période de rétention.

La suppression réversible est activée par défaut pour les nouveaux comptes de stockage. Si vous avez un flux de travail dans lequel la suppression du partage est courante et attendue, vous pouvez décider de configurer une période de rétention brève ou de ne pas activer du tout la suppression réversible.

Pour plus d’informations sur la suppression réversible, consultez Prévenir les suppressions de données accidentelles.

Sauvegarde

Vous pouvez sauvegarder votre partage de fichiers Azure via des captures instantanées de partage, qui sont des copies en lecture seule de votre partage à un instant dans le passé. Les captures instantanées sont incrémentielles, ce qui signifie qu’elles ne contiennent que les données modifiées depuis la capture instantanée précédente. Vous pouvez avoir jusqu’à 200 captures instantanées par partage de fichiers et les conserver pendant jusqu’à 10 ans. Vous pouvez prendre manuellement des captures instantanées dans le portail Azure, via PowerShell ou l’interface de ligne de commande (CLI), ou utiliser la Sauvegarde Azure.

La Sauvegarde Azure pour les partages de fichiers Azure gère la planification et la rétention des instantanés. Ses fonctionnalités grand-père-père-fils vous permettent de prendre des captures instantanées quotidiennes, hebdomadaires, mensuelles et annuelles, dont les périodes de rétention diffèrent. Le service Sauvegarde Azure orchestre également l’activation de la suppression réversible, et pose un verrou de suppression sur un compte de stockage dès qu’un partage de fichiers dans celui-ci est configuré pour la sauvegarde. Enfin, le service Sauvegarde Azure offre certaines fonctionnalités de surveillance et d’alerte clés, qui permettent aux clients d’avoir une vue consolidée de leur parc de sauvegarde.

Sauvegarde Azure vous permet d’effectuer des restaurations au niveau élément et au niveau partage dans le portail Azure. Il vous suffit de choisir le point de restauration (une capture instantanée particulière), le fichier ou répertoire particulier le cas échéant, puis l’emplacement (d’origine ou de remplacement) sur lequel vous souhaitez effectuer la restauration. Le service de sauvegarde gère la copie des données de captures instantanées et affiche la progression de la restauration dans le portail.

Protéger Azure Files avec Microsoft Defender pour Stockage

Microsoft Defender pour le stockage est une couche de sécurité intelligente native Azure qui détecte les menaces potentielles sur vos comptes de stockage. Il offre une sécurité complète en analysant les données de télémétrie du plan de données et du plan de contrôle générées par Azure Files. Il utilise des fonctionnalités avancées de détection des menaces optimisées par Microsoft Threat Intelligence pour fournir des alertes de sécurité contextuelles, y compris des étapes pour atténuer les menaces détectées et empêcher les attaques futures.

Defender pour le stockage analyse en continu le flux de données de télémétrie généré par Azure Files. Quand des activités potentiellement malveillantes sont détectées, des alertes de sécurité sont générées. Ces alertes sont affichées dans Microsoft Defender pour le cloud avec les détails de l’activité suspecte, les étapes d’investigation, les actions correctives et les recommandations de sécurité.

Defender pour le stockage détecte les programmes malveillants connus, tels que les rançongiciels, les virus, les logiciels espions et autres programmes malveillants chargés sur un compte de stockage en fonction du hachage de fichier complet (pris en charge uniquement pour l’API REST). Cela permet d’empêcher les programmes malveillants d’entrer dans l’organisation et de se propager à davantage d’utilisateurs et de ressources. Consultez Compréhension des différences entre l’analyse des programmes malveillants et l’analyse de la réputation de hachage.

Defender pour le stockage n’accède pas aux données de compte de stockage et n’impacte pas ses performances. Vous pouvez activer Microsoft Defender pour le stockage au niveau de l’abonnement (recommandé) ou de la ressource.

Niveaux de stockage

Azure Files offre deux niveaux de supports de stockage, SSD et HDD, qui vous permettent de personnaliser vos partages de fichiers en fonction des exigences de performances et de budget de votre scénario :

SSD (premium) : les partages de fichiers SSD offrent systématiquement des performances élevées et une faible latence (de l’ordre de quelques millisecondes pour la plupart des opérations d’E/S) pour les charges de travail gourmandes en E/S. Les partages de fichiers SSD conviennent à un vaste éventail de charges de travail, notamment les bases de données, l’hébergement de sites web et les environnements de développement. Les partages de fichiers SSD peuvent être utilisés avec les protocoles SMB (Server Message Block) et NFS (Network File System). Les partages de fichiers SSD sont disponibles dans le modèle de facturation provisionné v1. Les partages de fichiers SSD offrent un SLA dont la disponibilité est supérieure à celle des partages de fichiers HDD (voir « Niveau Premium d’Azure Files »).
HDD (standard) : les partages de fichiers HDD fournissent une option de stockage économique pour les partages de fichiers à usage général. Les partages de fichiers HDD sont disponibles avec les modèles de facturation provisionné v2 et paiement à l’utilisation, même si nous recommandons le modèle provisionné v2 pour les déploiements de nouveaux partages de fichiers. Pour en savoir plus sur le contrat SLA, consultez la page Contrats de niveau de service Azure (voir « Comptes de stockage »).

Au moment de sélectionner un niveau de support de stockage pour votre charge de travail, tenez compte de vos exigences en matière de performances et d’utilisation. Si votre charge de travail nécessite une latence à un chiffre ou si vous utilisez un support de stockage SSD local, les partages de fichiers SSD sont probablement les mieux adaptés. Si une faible latence n’est pas une préoccupation majeure, par exemple si vous avez des partages d’équipe montés localement à partir d’Azure ou mis en mémoire cache localement à l’aide d’Azure File Sync, les partages de fichiers HDD peuvent être plus indiqués du point de vue des coûts.

Après avoir créé un partage de fichiers dans un compte de stockage, il est impossible de le déplacer directement vers un autre niveau de stockage. Par exemple, pour déplacer un partage de fichiers HDD vers le niveau multimédia SSD, vous devez créer un partage de fichiers SSD et copier les données de votre partage d’origine vers le nouveau partage de fichiers. Voir migrer des fichiers d’un partage de fichiers vers un autre

Vous trouverez plus d’informations sur les niveaux multimédias SSD et HDD dans Understanding Azure Files billing and Understanding Azure Files performance.

Redondance

Pour protéger les données de vos partages de fichiers Azure contre la perte de données ou la corruption, Azure Files stocke plusieurs copies de chaque fichier lors de leur écriture. Vous pouvez sélectionner différents degrés de redondance, selon vos besoins. Azure Files prend actuellement en charge les options de redondance des données suivantes :

Stockage localement redondant (LRS) : avec redondance locale, chaque fichier est stocké trois fois dans un cluster de stockage Azure. Cela protège de la perte de données due à des défaillances matérielles, telles qu’un lecteur de disque défectueux. Toutefois, si un sinistre tel qu’un incendie ou une inondation se produit dans le centre de données, tous les réplicas d'un compte de stockage utilisant un LRS peuvent être perdus ou irrécupérables.
Stockage redondant interzone (ZRS) : avec redondance de zone, trois copies de chaque fichier sont stockées. Cependant; ces copies sont physiquement isolées dans trois clusters de stockage distincts dans différentes zones de disponibilité Azure. Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. Une écriture sur le stockage n’est pas acceptée tant qu’elle n’est pas écrite sur les clusters de stockage dans les trois zones de disponibilité.
Stockage géoredondant (GRS) : avec la géoredondance, vous disposez de deux régions, d’une région primaire et d’une région secondaire. Les fichiers sont stockés trois fois au sein d’un cluster de stockage Azure dans la région primaire. Les écritures sont répliquées de façon asynchrone dans une région secondaire définie par Microsoft. La géoredondance fournit six copies de vos données réparties entre deux régions Azure. Si une catastrophe majeure se produit, par exemple la perte permanente d’une région Azure en raison d’une catastrophe naturelle ou d’un autre événement similaire, Microsoft effectue un basculement. Dans ce cas, la région secondaire devient la région primaire, servant toutes les opérations. Étant donné que la réplication entre les régions primaires et secondaires est asynchrone, si une catastrophe majeure se produit, les données qui ne sont pas encore répliquées dans la région secondaire sont perdues. Vous pouvez également effectuer le basculement manuel d’un compte de stockage géoredondant.
Stockage géoredondant interzone (GZRS) : avec la redondance geoZone, les fichiers sont stockés trois fois sur trois clusters de stockage distincts dans la région primaire. Toutes les écritures sont ensuite répliquées de façon asynchrone dans une région secondaire définie par Microsoft. Le processus de basculement pour la redondance GeoZone fonctionne de la même façon que la géoredondance.

Les partages de fichiers HDD prennent en charge les quatre types de redondance. Les partages de fichiers SSD prennent uniquement en charge LRS et ZRS.

Les comptes de stockage avec paiement à l’utilisation fournissent deux autres options de redondance qu’Azure Files ne prend pas en charge : le stockage géoredondant accessible en lecture (RA-GRS) et le stockage géoredondant zonal accessible en lecture (RA-GZRS). Vous pouvez approvisionner des partages de fichiers Azure dans des comptes de stockage dont ces options sont définies, mais Azure Files ne prend pas en charge la lecture depuis la région secondaire. Les partages de fichiers Azure déployés dans des comptes de stockage RA-GRS ou RA-GZRS sont facturés en tant que geo ou GeoZone, respectivement.

Pour plus d’informations sur la redondance, consultez Redondance de données Azure Files.

Disponibilité des partages de fichiers SSD redondants interzone

Les partages de fichiers SSD redondants interzone sont disponibles pour un sous-ensemble de régions Azure.

Reprise d’activité après sinistre et basculement

En cas de panne de service régionale non planifiée, vous devez disposer d’un plan de récupération d’urgence pour vos partages de fichiers Azure. Pour comprendre les concepts et les processus impliqués dans le plan de reprise après sinistre et le basculement des comptes de stockage, voir Plan de reprise après sinistre et basculement pour Azure Files.

Migration

Dans de nombreux cas, vous n’établirez pas de nouveau partage de fichiers net pour votre organisation, mais migrerez plutôt un partage de fichiers existant, depuis un serveur de fichiers local ou un appareil NAS, vers Azure Files. Le choix de la stratégie et de l’outil de migration appropriés pour votre scénario est important pour la réussite de votre migration.

L’article vue d’ensemble de la migration aborde brièvement les bases et contient un tableau qui vous amène à des guides de migration susceptibles de couvrir votre scénario.