Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez déployer Azure Files de deux manières principales : en montant directement les partages de fichiers Azure serverless ou en les mettant en cache sur site via Azure File Sync. Les considérations de déploiement varient selon 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. Vous pouvez choisir d’utiliser les partages de fichiers Azure Classic ou Microsoft.FileShares (version préliminaire) comme modèle de gestion.
Mettre en cache des partages de fichiers Azure en local avec 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é, les performances 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.
Concepts de gestion
Dans Azure, une ressource est un élément gérable que vous créez et configurez dans vos abonnements Et groupes de ressources Azure. Les ressources sont proposées par les fournisseurs de ressources, qui sont des services de gestion qui fournissent des types de ressources spécifiques. Bien que vous puissiez utiliser de nombreuses ressources pour déployer une charge de travail dans Azure, Azure Files se concentre sur deux ressources clés :
Comptes de stockage, proposés par le
Microsoft.Storagefournisseur de ressources. Les comptes de stockage sont des ressources de niveau supérieur qui représentent un pool partagé de stockage, d’E/S par seconde et de débit dans lequel vous pouvez déployer des partages de fichiers classiques ou 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. Les partages de fichiers classiques prennent en charge les protocoles de partage de fichiers SMB et NFS.Partages de fichiers (préversion), proposés par le
Microsoft.FileSharesfournisseur de ressources. Les partages de fichiers sont une nouvelle ressource de niveau supérieur qui simplifie le déploiement d’Azure Files en éliminant le compte de stockage. Contrairement aux partages de fichiers classiques, qui doivent être déployés dans un compte de stockage, les partages de fichiers sont déployés directement dans le groupe de ressources, comme les comptes de stockage eux-mêmes, ou d’autres ressources Azure que vous connaissez peut-être comme des machines virtuelles, des disques ou des réseaux virtuels. Les partages de fichiers prennent en charge le protocole de partage de fichiers NFS : si vous avez besoin de SMB, choisissez des partages de fichiers classiques pour votre déploiement.
Cette vidéo fournit une vue d’ensemble complète des différences entre le compte de stockage et les modèles de gestion des partages de fichiers :
Partages de fichiers classiques (Microsoft.Storage)
Les partages de fichiers classiques ou les partages de fichiers déployés dans des comptes de stockage constituent la méthode traditionnelle pour déployer des partages de fichiers pour Azure Files. Ils prennent en charge toutes les fonctionnalités clés prises en charge par Azure Files, notamment les niveaux de média SMB et NFS, SSD et HDD, tous les types de redondance et dans chaque région. Bien que les partages de fichiers classiques prennent en charge l’ensemble des fonctionnalités d’Azure Files, ils présentent des limitations clés importantes :
Planification de la capacité : les partages de fichiers classiques et les objets enfants d'autres services de stockage tels que les conteneurs blob, qui résident dans le même compte de stockage, partagent un pool commun de stockage, d'IOPS et de débit. Cela signifie que le placement de plusieurs partages de fichiers classiques dans un compte de stockage nécessite une planification pour éviter les goulots d’étranglement de capacité. Lors de la planification de la capacité des partages de fichiers classiques, vous devez prendre en compte les besoins actuels et futurs de chaque partage de fichiers classique placé dans un compte de stockage, car la croissance d'un partage de fichiers classique peut évincer d'autres partages de fichiers.
Paramètres partagés : de nombreux paramètres importants, tels que les règles de réseau et de sécurité, sont appliqués au niveau du compte de stockage. Par conséquent, le placement de partages de fichiers classiques dans le même compte de stockage nécessite une considération minutieuse. Vous devez considérer le compte de stockage comme une limite d’approbation et placer uniquement des partages de fichiers classiques dans le même compte de stockage si vous êtes ok avec eux ayant les mêmes paramètres de sécurité.
Complexité de la mise à l’échelle : les déploiements à grande échelle d’Azure Files peuvent nécessiter la gestion de nombreux abonnements Azure en raison des contraintes sur les comptes de stockage du fournisseur de ressources
Microsoft.Storage. Pour plus d’informations, consultez les limites du compte de stockage.
Il existe deux types principaux de comptes de stockage utilisés pour les déploiements de partage de fichiers classiques :
-
Comptes de stockage provisionnés : les comptes de stockage provisionnés sont distingués à l’aide du type de compte de stockage
FileStorage. Les comptes de stockage provisionnés vous permettent de déployer des partages de fichiers classiques 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 classiques et ne peuvent pas être utilisés pour stocker d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente et des tables. Nous vous recommandons d’utiliser des comptes de stockage provisionnés pour tous les nouveaux déploiements de partage de fichiers classiques. -
Comptes de stockage avec paiement à l’utilisation : les comptes de stockage à la carte se distinguent par le type de compte de stockage
StorageV2. Les comptes de stockage avec paiement à l’utilisation vous permettent de déployer des partages de fichiers de paiement à l’utilisation sur du matériel HDD. Les comptes de stockage avec paiement à l’utilisation peuvent être utilisés pour stocker des partages de fichiers classiques et d’autres ressources de stockage telles que des conteneurs d’objets blob, des files d’attente ou des tables.
Pour plus d’informations, consultez Créer un partage de fichiers classique.
Partages de fichiers (Microsoft.FileShares)
Les partages de fichiers (aperçu) sont une nouvelle ressource Azure de niveau supérieur fournie par le fournisseur de ressources Microsoft.FileShares. Les partages de fichiers offrent les avantages suivants par rapport aux partages de fichiers classiques :
Gestion simplifiée : les partages de fichiers sont créés directement en tant que ressources de niveau supérieur dans le portail ou via des API de gestion. Cela supprime la nécessité de gérer un compte de stockage et simplifie l’expérience de déploiement.
Capacité et performances indépendantes : chaque partage de fichiers possède son propre stockage dédié, ses IOPS et son débit. Cela évite d’avoir à planifier la capacité sur vos comptes de stockage des ressources limitées et permet aux partages de fichiers de croître librement à mesure que les requêtes de charge de travail augmentent.
Configuration granulaire : les paramètres de mise en réseau et de sécurité sont appliqués au niveau du partage de fichiers, ce qui vous permet de contrôler précisément les limites d’accès et l’isolation. Cela facilite l’application de stratégies de sécurité pour des applications, des équipes ou des environnements spécifiques.
Facturation prévisible et flexible : les partages de fichiers utilisent le modèle de facturation v2 approvisionné, ce qui vous permet d’approvisionner indépendamment le stockage, les IOPS et le débit par partage. Étant donné que la facturation dans Azure est effectuée par ressource Azure de niveau supérieur, l’utilisation de partages de fichiers vous permet de suivre facilement les coûts de chaque partage individuel pour l’attribution des coûts au projet, à l’équipe ou au client qui utilise le partage de fichiers.
Amélioration de la mise à l’échelle et des performances : les partages de fichiers prennent en charge des limites plus élevées et des temps de déploiement inférieurs aux partages de fichiers classiques. Pour plus d’informations, voir Objectifs de performance et d’extensibilité d’Azure Files.
Disponibilité régionale
Actuellement, la création d’un partage de fichiers avec Microsoft.FileShares (préversion) est disponible dans les régions suivantes :
- Australia East
- Australie Centre
- Australia Southeast
- Asie de l’Est
- East US
- Allemagne Nord
- Sud de la Corée
- Asie du Sud-Est
- Europe Nord
- Afrique du Sud Ouest
- South India
- Émirats arabes unis Centre
Actuellement, la prise en charge du point de terminaison privé pour le partage de fichiers avec Microsoft.FileShares (préversion) est disponible dans un sous-ensemble limité de régions :
- Toutes les régions de cloud public Azure.
Comparaison des fournisseurs de ressources : Microsoft.Storage et Microsoft.FileShares
| Fonctionnalité | Partages de fichiers classiques  |
Partages de fichiers (Microsoft.FileShares)  |
|---|---|---|
| Garantie de support | Disponibilité générale | Aperçu public |
| Ressource de niveau supérieur pour le service | Compte de stockage  |
Partages de fichiers |
| Protocole SMB |
|
|
| Protocole NFS |
|
|
| Prise en charge Azure File Sync |
|
|
| Exiger un compte de stockage |
|
|
| Paiement à l’utilisation du modèle de facturation |
|
|
| Modèle de facturation v1 provisionné |
|
|
| Modèle de facturation v2 provisionné |
|
|
| Prise en charge HDD |
|
|
| Prise en charge SSD |
|
|
| LRS |
|
|
| ZRS |
|
|
| GRS (Gymnastique Rythmique et Sportive) |
|
|
| GZRS |
|
|
| Facturation au niveau du partage, mise en réseau et configurations de sécurité |
|
|
| Configurations de réseau virtuel unique pour un partage de fichiers |
|
|
| Configuration de réseau virtuel unique pour plusieurs partages de fichiers |
|
|
| Pilote CSI AKS |
|
|
| API REST du plan de données |
|
|
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é |
|
Version 4.3+ du noyau Linux |
| Niveaux disponibles | SSD et HDD | SSD uniquement |
| Redondance |
|
|
| 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 | Oui (Microsoft.Storage uniquement) |
| 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 |
| Transactions de système de fichiers (TxF) | Non prise en charge | N/A |
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 via le chiffrement côté service stockage Azure (SSE). SSE 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.
Étant donné que les données sont chiffrées sous le système de fichiers du partage de fichiers Azure, car elles sont encodées sur disque, vous n’avez pas besoin d’accéder à la clé sous-jacente sur le client pour lire ou écrire dans 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. Avec les clés gérées par Microsoft, Microsoft contient les clés pour chiffrer et déchiffrer les données. Microsoft est responsable de la rotation de ces clés 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. Avec les clés gérées par le client, vous pouvez révoquer cette autorisation à tout moment. Mais sans cette autorisation, votre partage de fichiers Azure n’est plus accessible via SMB ou l’API FileREST.
Azure Files utilise le même schéma de chiffrement que les autres services stockage Azure, tels que Stockage Blob Azure. Pour en savoir plus sur Azure Storage SSE, consultez Chiffrement Stockage Microsoft 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 multimédias de stockage : disque SSD (SSD) et disque dur (HDD). Ces niveaux vous permettent d’adapter vos partages aux exigences de performances et de prix de votre scénario :
SSD (Premium) : les partages de fichiers SSD fournissent des hautes performances et une faible latence cohérentes, en millisecondes à un chiffre 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 large éventail de charges de travail, telles que les bases de données, l’hébergement de sites web et les environnements de développement.
Vous pouvez utiliser des partages de fichiers SSD avec les protocoles SMB et NFS. Les partages de fichiers SSD sont disponibles dans les modèles de facturation v2 approvisionnés et v1 approvisionnés . Les partages de fichiers SSD offrent un SLA de disponibilité plus élevé que les partages de fichiers HDD.
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és v2 et paiement à l'utilisation, bien que nous recommandions le modèle provisionné v2 pour les nouveaux déploiements de partages de fichiers. Pour plus d’informations sur le SLA, consultez la page Azure SLA pour les services en ligne.
Lorsque vous sélectionnez un niveau multimédia 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 support de stockage SSD local, les partages de fichiers SSD sont probablement les mieux adaptés. Si la faible latence n’est pas autant problématique, les partages de fichiers HDD peuvent être mieux adaptés du point de vue des coûts. Par exemple, une faible latence peut être moins préoccupante avec les partages d’équipe montés sur site à partir d’Azure ou mis en cache sur site via Azure File Sync.
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 multimédia. Par exemple, pour déplacer un partage de fichiers HDD vers le niveau multimédia SSD, vous devez créer un nouveau partage de fichiers SSD et copier les données de votre partage d'origine vers le nouveau partage de fichiers.
Vous trouverez plus d’informations sur les niveaux de support SSD et HDD dans Comprendre les modèles de facturation Azure Files et Comprendre et optimiser les performances du partage de fichiers Azure.
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. Selon vos besoins, vous pouvez sélectionner des degrés de redondance. Azure Files prend actuellement en charge les options suivantes pour la redondance des données :
Stockage localement redondant (LRS) : avec redondance locale, chaque fichier est stocké trois fois dans un cluster de stockage Azure. Cette approche permet de protéger contre la perte de données en raison d’erreurs matérielles, telles qu’un lecteur de disque incorrect. Toutefois, si une catastrophe telle que l’incendie ou l’inondation se produit dans le centre de données, tous les réplicas d’un compte de stockage qui utilise LRS peuvent être perdus ou irrécupérables.
Stockage redondant interzone (ZRS) : avec redondance de zone, trois copies de chaque fichier sont stockées. Toutefois, ces copies sont physiquement isolées dans trois clusters de stockage distincts dans les zones de disponibilité Azure. Les zones de disponibilité sont des emplacements physiques uniques dans une région Azure. Chaque zone 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 redondance géographique, vous disposez d’une région primaire et d’une région secondaire. Les fichiers sont stockés trois fois dans 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 les deux régions Azure. Si une catastrophe majeure se produit, telle que 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, le secondaire devient le principal et sert 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 géographique, 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 de zone géographique fonctionne de la même façon que pour 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 d’accès en lecture (RA-GRS) et le stockage géoredondant avec accès en lecture (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 à partir de 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 géoredondants ou géozone redondants, 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.