Planification d’un déploiement Azure Files

Le service Azure Files peut être déployé de deux façons : en procédant à un montage direct des 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 de déploiement diffèrent en fonction de l’option choisie.

  • 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. Dans la mesure où les partages de fichiers Azure sont serverless, vous n'avez aucun serveur de fichiers ou appareil NAS à gérer lors des déploiements liés à des scénarios de production. 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. Vous ne pouvez pas utiliser à la fois le protocole SMB et le protocole NFS dans un même partage de fichiers Azure. Cependant, vous pouvez créer des partages de fichiers SMB et NFS au sein d’un même compte de stockage. NFS 4.1 n’est pris en charge que par le nouveau type de compte de stockage FileStorage (partages de fichiers Premium uniquement).

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é SMB 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 10, version 21H1+
  • Windows Server 2019+
  • Noyau Linux version 5.3+
Noyau Linux version 4.3+
Niveaux disponibles Premium, transaction optimisée, niveaux d’accès chaud et froid Premium
Modèle de facturation Capacité allouée
Points de terminaison de zone Azure DNS (préversion) Prise en charge Prise en charge
Redondance LRS, ZRS, GRS, GZRS LRS, 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 Respect de la casse
Suppression ou modification de fichiers ouverts Avec verrou uniquement Oui
Partage de fichiers Mode de partage Windows Gestionnaire conseil de verrouillage réseau de plage d’octets
Prise en charge des liens physiques Non prise en charge Pris en charge
Prise en charge des liens symboliques Non prise en charge Pris en charge
Accessible par Internet (facultatif) Oui (SMB 3.0+ uniquement) Non
Prend en charge FileREST Oui Sous-ensemble :
Verrous de plages d’octets obligatoires Prise en charge Non pris en charge
Verrous de plages d’octets conseillés Non pris en charge Prise en charge
Attributs étendus/nommés Non pris en charge Non pris en charge
Autres flux de données Non pris en charge N/A
Identificateurs d'objet Non pris en charge N/A
Points d’analyse Non pris en charge N/A
Fichiers partiellement alloués Non pris en charge N/A
Compression Non pris en charge N/A
Canaux nommés Non pris en charge N/A
SMB Direct Non pris en charge N/A
Bail de répertoire SMB Non pris en charge N/A
Cliché instantané des volumes Non pris en charge N/A
Noms de fichier courts (alias 8.3) Non pris en charge N/A
Service de serveur Non pris en charge N/A
Transactions de système de fichiers (TxF) Non pris 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é. Ce pool de stockage peut être utilisé pour déployer plusieurs partages de fichiers ainsi que d’autres ressources de stockage, telles que des conteneurs d’objets blob, des files d’attente ou des tables. 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 que vous allez utiliser pour les déploiements d’Azure Files :

  • Comptes de stockage version 2 (GPv2) universels : Les comptes de stockage GPv2 vous permettent de déployer des partages de fichiers Azure sur du matériel Standard/sur disque dur (HDD). 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.
  • Comptes de stockage FileStorage : Les comptes de stockage FileStorage vous permettent de déployer des partages de fichiers Azure sur du matériel Premium/sur disque SSD. Les comptes FileStorage peuvent uniquement être utilisés pour stocker des partages de fichiers Azure. Aucune autre ressource de stockage (conteneurs d’objets blob, files d’attente, tables, etc.) ne peut être déployée dans un compte FileStorage. Seuls les comptes FileStorage peuvent déployer des partages de fichiers SMB et NFS.

Il existe plusieurs autres types de comptes de stockage que vous pouvez rencontrer dans le portail Azure, PowerShell ou l’interface CLI. Deux types de comptes de stockage, BlockBlobStorage et BlobStorage, ne peuvent pas contenir de partages de fichiers Azure. Les deux autres types de comptes de stockage que vous pouvez voir sont les comptes version 1 (GPv1) universels et les comptes classiques, qui peuvent tous deux contenir des partages de fichiers Azure. Bien que les comptes de stockage GPv1 et classiques puissent contenir des partages de fichiers Azure, la plupart des nouvelles fonctionnalités d’Azure Files sont disponibles uniquement dans les comptes de stockage GPv2 et FileStorage. Nous vous recommandons donc d’utiliser uniquement les comptes de stockage GPv2 et FileStorage pour les nouveaux déploiements ainsi que pour mettre à niveau les comptes de stockage GPv1 et classiques s’ils existent déjà dans votre environnement.

Lorsque vous déployez des partages de fichiers Azure dans des comptes de stockage, tenez compte des recommandations suivantes :

  • Déployez uniquement des partages de fichiers Azure dans des comptes de stockage ayant d’autres partages de fichiers Azure. Bien que les comptes de stockage GPv2 vous permettent de disposer de comptes de stockage mixte, les ressources de stockage (telles que les partages de fichiers Azure et les conteneurs d’objets BLOB) partageant les limites du compte de stockage, la combinaison des ressources peut compliquer la résolution des problèmes de performances par la suite.

  • Faites attention aux limites d’IOPS d’un compte de stockage lors du déploiement des partages de fichiers Azure. Dans l'idéal, une correspondance 1:1 doit être respectée entre les partages de fichiers et les comptes de stockage. Mais cela n'est pas toujours possible en raison des différentes limites et restrictions imposées par votre organisation et Azure. S’il n’est pas possible d’avoir un seul partage de fichiers déployé dans un compte de stockage, tenez compte des partages qui seront très actifs et des partages qui le seront moins, afin de garantir que les partages de fichiers les plus sollicités ne soient pas mis ensemble dans le même compte de stockage.

  • Déployez uniquement des comptes GPv2 et FileStorage, et mettez à niveau les comptes de stockage GPv1 et Classic lorsque vous les trouvez dans votre environnement.

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 s’intègre avec quatre fournisseurs d’identité principaux :

  • 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.
  • Azure Active Directory Domain Services (Azure AD DS) . Azure AD DS fournit un contrôleur de domaine géré par Microsoft et pouvant être utilisé pour les ressources Azure. Joindre le domaine de votre compte de stockage à Azure AD DS offre des avantages similaires à le joindre à 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é qu’Azure AD DS fournit une authentification basée sur Active Directory, cette option utilise également le protocole d’authentification Kerberos.
  • Azure Active Directory (Azure AD) Kerberos pour les identités hybrides : Azure AD Kerberos vous permet d’utiliser Azure AD pour authentifier des identités d’utilisateur hybrides, qui sont des identités AD locales synchronisées avec le cloud. Cette configuration utilise Azure AD pour émettre des tickets Kerberos pour accéder au partage de fichiers avec le protocole SMB. Cela signifie que vos utilisateurs finaux peuvent accéder à des partages de fichiers Azure via internet sans avoir besoin d’une ligne de vue sur des contrôleurs de domaine à partir de machines virtuelles jointes à Azure AD Hybride et à Azure AD.
  • Clé du compte de Stockage Azure : Les partages de fichiers Azure peuvent également être montés à l’aide d’une clé de compte de stockage Azure. Pour monter un partage de fichiers de cette façon, le nom du compte de stockage est utilisé comme nom d’utilisateur, et la clé du compte de stockage comme mot de passe. L’utilisation de la clé de compte de stockage pour monter le partage de fichiers Azure relève en fait une opération d’administrateur, car le partage de fichiers monté disposera d’autorisations complètes sur tous les fichiers et dossiers du 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é.

Pour les clients qui migrent à partir de serveurs de fichiers locaux ou qui créent dans Azure Files des partages de fichiers destinés à se comporter comme des serveurs de fichiers Windows ou des appliances NAS, le fait de joindre le domaine de votre compte de stockage à l’instance AD DS appartenant au client représente l’option recommandée. 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.

Si vous envisagez d’utiliser la clé de compte de stockage pour accéder à vos partages de fichiers Azure, nous vous recommandons d’utiliser des points de terminaison privés ou de service, comme décrit à la section Mise en réseau.

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.

Du point de vue pratique, cela signifie que vous devez envisager 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és 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.

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 : le chiffrement en transit, qui se rapporte au chiffrement utilisé lors du montage/de l’accès au partage de fichiers Azure, et le chiffrement au repos, qui a trait à la façon dont les données sont chiffrées lorsqu’elles sont stockées sur le disque.

Chiffrement en transit

Important

Cette section traite en détail du chiffrement en transit pour les partages SMB. Pour plus d’informations sur le chiffrement en transit avec les partages NFS, consultez Sécurité et réseau.

Par défaut, le chiffrement en transit est activé pour tous les comptes de stockage Azure. Cela signifie que, quand vous montez un partage de fichiers sur SMB ou y accédez en utilisant le protocole FileREST (par exemple, via le portail Azure, PowerShell/CLI ou des kits SDK Azure), Azure Files autorise la connexion uniquement si elle est établie à l’aide des protocoles 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 détaillée 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 les protocoles SMB 2.1 et SMB 3.x sans chiffrement, ainsi que les appels d’API FileREST non chiffrés via le protocole 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 au sein de 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 fortement de vérifier que le chiffrement des données en transit est activé.

Pour plus d’informations sur le chiffrement en transit, voir Exiger un transfert sécurisé dans Stockage Azure.

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, mais dans ce cas 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é.

Suppression réversible

La suppression réversible pour les partages de fichiers SMB est un paramètre de niveau de compte de stockage qui vous permet de récupérer votre partage de fichiers en cas de suppression accidentelle. 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 données supprimées de manière réversible sont récupérables avant leur suppression définitive, et annuler la suppression du partage à tout moment lors de la période de rétention.

Nous vous recommandons d’activer la suppression réversible pour la plupart des partages de fichiers SMB. Si vous avez un flux de travail dans lequel la suppression de partage est courante et attendue, vous pouvez décider de configurer une période de rétention brève ou de ne pas activer la suppression réversible. La suppression réversible ne fonctionne pas pour les partages NFS, même si elle est activée pour le compte de stockage.

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 soit prendre manuellement ces captures instantanées dans le portail Azure, via PowerShell ou l’interface de ligne de commande (CLI), soit d’utiliser Sauvegarde Azure. Les captures instantanées sont stockées dans votre partage de fichiers, ce qui signifie que, si vous supprimez votre partage de fichiers, vos captures instantanées sont également supprimées. Pour protéger vos sauvegardes de captures instantanées contre des suppressions accidentelles, assurez-vous que la suppression réversible est activée pour votre partage.

La Sauvegarde Azure pour les partages de fichiers Azure gère la planification et la rétention des captures instantanées. 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.

Pour plus d’informations sur la sauvegarde, consultez À propos de la sauvegarde des partages de fichiers Azure.

Protéger Azure Files avec Microsoft defender pour Stockage

Microsoft Defender for Stockage fournit une couche supplémentaire d’intelligence de sécurité qui génère des alertes lorsqu’il détecte une activité anormale sur votre compte de stockage, par exemple des tentatives d’accès inhabituelles. Il exécute également une analyse de réputation du hachage de programme malveillant et déclenche une alerte concernant les programmes malveillants connus. Vous pouvez configurer Microsoft Defender pour Stockage au niveau de l’abonnement ou du compte de stockage via Microsoft Defender pour le Cloud.

Pour plus d’informations, consultez Présentation d’Azure Defender pour le Stockage.

Niveaux de stockage

Azure Files offre quatre niveaux de stockage, premium, optimisé pour les transactions, chaud et froid, pour vous permettre de personnaliser vos partages en fonction des performances et du budget demandés par votre scénario :

  • Premium : Les partages de fichiers Premium reposent sur des disques SSD et offrent toujours un niveau de performance élevé et une faible latence (à un chiffre en millisecondes pour la plupart des opérations d’E/S) pour les charges de travail les plus gourmandes en E/S. Les partages de fichiers Premium sont adaptés à un vaste éventail de charges de travail, comme les bases de données, l’hébergement de site web et les environnements de développement. Les partages de fichiers Premium peuvent être utilisés avec les protocoles SMB (Server Message Block) et NFS (Network File System).
  • Optimisé pour les transactions : Les partages de fichiers optimisés pour les transactions permettent d’avoir des charges de travail lourdes en transactions qui n’ont pas besoin de la latence offerte par les partages de fichiers premium. Les partages de fichiers optimisés pour les transactions sont proposés sur le matériel de stockage standard reposant sur des lecteurs de disque dur (HDD). Le niveau Optimisé pour les transactions était auparavant appelé « Standard », mais cela fait référence au type de support de stockage plutôt qu’au niveau lui-même (les niveaux chaud et froid sont également des niveaux « standard », car ils se trouvent sur du matériel de stockage standard).
  • Hot : Les partages de fichiers chauds offrent un stockage optimisé pour les scénarios de partage de fichiers à usage général, tels que les partages d’équipe. Les partages de fichiers chauds sont proposés sur le matériel de stockage standard reposant sur des HDD.
  • Froid : Les partages de fichiers froids offrent un stockage abordable optimisé pour les scénarios de stockage d’archive en ligne. Les partages de fichiers froids sont proposés sur le matériel de stockage standard reposant sur des HDD.

Les partages de fichiers Premium sont déployés dans le type de compte de stockage FileStorage et sont disponibles uniquement dans un modèle de facturation provisionnée. Pour plus d’informations sur le modèle de facturation avec approvisionnement pour les partages de fichiers Premium, consultez Comprendre l’approvisionnement des partages de fichiers Premium. Les partages de fichiers standard, notamment les partages de fichiers optimisés pour les transactions, chauds et froids, sont déployés dans le type de compte de stockage à usage générale version 2 (GPv2) et sont disponibles via une facturation avec paiement à l’utilisation.

Au moment de sélectionner un niveau de stockage pour votre charge de travail, tenez compte de vos besoins en matière de performances et d’utilisation. Si votre charge de travail nécessite une latence à un chiffre ou si vous utilisez un média de stockage SSD local, le niveau Premium est probablement le mieux adapté. Si une faible latence ne constitue pas un problème, 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, le stockage standard est peut être plus indiqué du point de vue du coût.

Une fois que vous avez créé un partage de fichiers dans un compte de stockage, vous ne pouvez plus le déplacer dans des niveaux réservés à différents types de compte de stockage. Par exemple, pour déplacer un partage de fichiers optimisé pour les transactions vers le niveau Premium, vous devez créer un nouveau partage de fichiers dans un compte de stockage FileStorage et copier les données de votre partage d’origine vers un nouveau partage de fichiers dans le compte FileStorage. Nous vous recommandons d’utiliser AzCopy pour copier des données entre différents partages de fichiers Azure, mais vous pouvez aussi utiliser des outils comme robocopy sur Windows ou rsync pour macOS et Linux.

Pour plus d’informations, consultez la présentation de la facturation Azure Files.

Limitations

Les partages de fichiers standard d’une capacité de 100 Tio présentent certaines limitations.

  • Actuellement, seuls les comptes de stockage localement redondant (LRS) et de stockage redondant interzone (ZRS) sont pris en charge.
  • Après avoir activé les partages de fichiers volumineux, vous ne pouvez plus convertir de comptes de stockage en comptes de stockage géoredondant (GRS) ou de stockage géoredondant interzone (GZRS).
  • Après avoir activé les partages de fichiers volumineux, vous ne pouvez plus les désactiver.

Redondance

Pour protéger les données de vos partages de fichiers Azure contre la perte ou l’altération des données, tous les partages de fichiers Azure stockent plusieurs copies de chaque fichier au fur et à mesure de leur écriture. En fonction des exigences de votre charge de travail, vous pouvez sélectionner des degrés de redondance supplémentaires. Azure Files prend actuellement en charge les options de redondance des données suivantes :

  • Stockage localement redondant (LRS) : avec LRS, chaque fichier est stocké trois fois au sein d’un cluster de stockage Azure. Cela le 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 à l’intérieur du centre de données, tous les réplicas d’un compte de stockage utilisant un stockage localement redondant risquent d’être perdus ou irrécupérables.
  • Stockage redondant dans une zone (ZRS) : avec ZRS, trois copies de chaque fichier stocké, mais 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 dans les clusters de stockage dans les trois zones de disponibilité.
  • Stockage géoredondant (GRS) : avec GRS, vous avez deux régions, une région primaire et 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. Le stockage GRS fournit six copies de vos données réparties entre deux régions Azure. En cas de sinistre majeur, tel que la perte permanente d’une région Azure en raison d’une catastrophe naturelle ou d’un autre événement similaire, Microsoft effectuera un basculement afin que la région secondaire en vigueur devienne la région primaire, assurant toutes les opérations. Étant donné que la réplication entre les régions primaire et secondaire est asynchrone, en cas de sinistre majeur, les données qui ne sont pas encore répliquées dans la région secondaire seront perdues. Vous pouvez également effectuer le basculement manuel d’un compte de stockage géoredondant.
  • Stockage géo-redondant dans une zone (GZRS) : vous pouvez considérer GZRS comme s’il s’agissait de ZRS, mais avec la géo-redondance. Avec GZRS, 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 GZRS fonctionne de la même façon que GRS.

Les partages de fichiers Azure standard jusqu’à 5 Tio prennent en charge les quatre types de redondance. Les partages de fichiers standard supérieurs à 5-Tio prennent uniquement en charge LRS et ZRS. Les partages de fichiers Premium Azure prennent uniquement en charge LRS et ZRS.

Les comptes de stockage v2 universels (GPv2) fournissent deux options de redondance supplémentaires qui ne sont pas prises en charge par Azure Files : le stockage géographiquement redondant avec accès en lecture, souvent appelé RA-GRS, et le stockage géographiquement redondant interzone avec accès en lecture, souvent appelé RA-GZRS. Vous pouvez approvisionner des partages de fichiers Azure dans des comptes de stockage avec ces options définies, mais Azure Files ne prend pas en charge la lecture de la région secondaire. Les partages de fichiers Azure déployés dans des comptes de stockage géographiquement redondant ou géographiquement redondant interzone avec accès en lecture sont facturés en tant que stockage géoredondant ou géoredondant interzone, respectivement.

Disponibilité ZRS Standard

ZRS pour les comptes de stockage v2 standard à usage général est disponible pour un sous-ensemble de régions Azure :

  • (Afrique) Afrique du Sud Nord
  • (Asie-Pacifique) Australie Est
  • (Asie-Pacifique) Inde Centre
  • (Asie-Pacifique) Asie Est
  • (Asie-Pacifique) Japon Est
  • (Asie-Pacifique) Corée Centre
  • (Asie-Pacifique) Asie Sud-Est
  • (Europe) France Centre
  • (Europe) Allemagne Centre-Ouest
  • (Europe) Europe Nord
  • (Europe) Norvège Est
  • (Europe) Suède Centre
  • (Europe) Suisse Nord
  • (Europe) Royaume-Uni Sud
  • (Europe) Europe Ouest
  • (Moyen-Orient) Qatar Central
  • (Moyen-Orient) Émirats arabes unis Nord
  • (Amérique du Nord) Canada Centre
  • (Amérique du Nord) USA Centre
  • (Amérique du Nord) USA Est
  • (Amérique du Nord) USA Est 2
  • (Amérique du Nord) USA Centre Sud
  • (Amérique du Nord) US Gov Virginie
  • (Amérique du Nord) USA Ouest 2
  • (Amérique du Nord) USA Ouest 3
  • (Amérique du Sud) Brésil Sud

Disponibilité ZRS Premium

ZRS pour les partages de fichiers Premium est disponible pour un sous-ensemble de régions Azure :

  • (Asie-Pacifique) Australie Est
  • (Asie-Pacifique) Japon Est
  • (Asie-Pacifique) Asie Sud-Est
  • (Asie-Pacifique) Corée Centre
  • (Europe) France Centre
  • (Europe) Europe Nord
  • (Europe) Europe Ouest
  • (Europe) Royaume-Uni Sud
  • (Moyen-Orient) Qatar Central
  • (Amérique du Nord) USA Est
  • (Amérique du Nord) USA Est 2
  • (Amérique du Nord) USA Ouest 2
  • (Amérique du Nord) USA Centre Sud
  • (Amérique du Sud) Brésil Sud

Disponibilité GZRS Standard

GZRS est disponible pour un sous-ensemble de régions Azure :

  • (Afrique) Afrique du Sud Nord
  • (Asie-Pacifique) Australie Est
  • (Asie-Pacifique) Asie Est
  • (Asie-Pacifique) Japon Est
  • (Asie-Pacifique) Corée Centre
  • (Asie-Pacifique) Asie Sud-Est
  • (Asie-Pacifique) Inde Centre
  • (Europe) France Centre
  • (Europe) Allemagne Centre-Ouest
  • (Europe) Europe Nord
  • (Europe) Norvège Est
  • (Europe) Suède Centre
  • (Europe) Suisse Nord
  • (Europe) Royaume-Uni Sud
  • (Europe) Europe Ouest
  • (Amérique du Nord) Canada Centre
  • (Amérique du Nord) USA Centre
  • (Amérique du Nord) USA Est
  • (Amérique du Nord) USA Est 2
  • (Amérique du Nord) USA Centre Sud
  • (Amérique du Nord) USA Ouest 2
  • (Amérique du Nord) USA Ouest 3
  • (Amérique du Nord) US Gov Virginie
  • (Amérique du Sud) Brésil Sud

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.

Étapes suivantes