Comment déployer Azure Files
Vous pouvez déployer Azure Files de deux façons : en montant directement 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. É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. 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é |
|
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 prise en charge | Non prise 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 classiques 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 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é 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é. 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.
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.
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. Bien que les données soient alors toujours disponibles sur le partage de fichiers, le client nécessitera un remontage 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
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 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 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, 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é. 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 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.
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, le niveau des partages de fichiers SSD convient probablement le mieux. 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, vous ne pouvez pas le déplacer directement vers un autre niveau de support. Par exemple, pour déplacer un partage de fichiers HDD vers le niveau de support SSD, vous devez créer un partage de fichiers SSD 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.
Redondance
Pour protéger les données de vos partages de fichiers Azure contre la perte ou l’altération des données, Azure Files stocke plusieurs copies de chaque fichier au fur et à mesure 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 LRS, chaque fichier est stocké trois fois au sein d’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 un ZRS, 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éo-redondant (GRS) : Avec un 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 événement similaire, Microsoft effectuera un basculement. Dans ce cas, la région secondaire devient la région primaire, servant toutes les opérations. La réplication entre les régions primaire et secondaire étant 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 interzone (GZRS) : Vous pouvez considérer le GZRS comme un ZRS, mais avec une 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 le LRS et le ZRS. Les partages de fichiers Premium Azure prennent uniquement en charge LRS et ZRS.
Les comptes de stockage version 2 (GPv2) à usage général fournissent deux autres options de redondance qu’Azure Files ne prend pas en charge : la lecture d’un stockage géo-redondant accessible (RA-GRS) et la lecture d’un stockage géo-redondant interzone accessible (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 respectivement comme des GRS ou des GZRS.
Pour plus d’informations sur la redondance, consultez Redondance de données Azure Files.
Disponibilité ZRS Standard
Un ZRS pour les comptes de stockage v2 standard à usage général est disponible pour un sous-ensemble de régions Azure.
Disponibilité ZRS Premium
Un ZRS pour les partages de fichiers Premium est disponible pour un sous-ensemble de régions Azure.
Disponibilité GZRS Standard
Un GZRS est disponible 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 la récupération d’urgence et le basculement de compte de stockage, consultez Récupération d’urgence 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.