Prérequis du système de fichiers Azure Managed Lustre
Cet article explique les prérequis que vous devez configurer avant de créer un système de fichiers Azure Managed Lustre.
- Conditions préalables réseau
- Conditions préalables à l’intégration d’objets blob (facultatif)
Configuration réseau requise
Les systèmes de fichiers Azure Managed Lustre existent dans un sous-réseau de réseau virtuel. Le sous-réseau contient le service MGS (service de gestion Lustre), et gère toutes les interactions des clients avec le cluster Lustre virtuel.
Vous ne pouvez pas déplacer un système de fichiers d’un réseau ou d’un sous-réseau vers un autre après avoir créé le système de fichiers.
Azure Managed Lustre accepte uniquement les adresses IPv4. IPv6 n’est pas pris en charge.
Exigences relatives à la taille du réseau
La taille du sous-réseau dont vous avez besoin dépend de la taille du système de fichiers que vous créez. Le tableau suivant fournit une estimation approximative de la taille de sous-réseau minimale pour les systèmes de fichiers Azure Managed Lustre de différentes tailles.
| Capacité de stockage | Valeur de préfixe CIDR recommandée |
|---|---|
| De 4 Tio à 16 Tio | /27 ou plus |
| De 20 Tio à 40 Tio | /26 ou plus |
| De 44 Tio à 92 Tio | /25 ou plus |
| De 96 Tio à 196 Tio | /24 ou plus |
| De 200 Tio à 400 Tio | /23 ou plus |
Autres considérations relatives à la taille du réseau
Lorsque vous planifiez votre réseau virtuel et votre sous-réseau, prenez en compte les exigences des autres services que vous souhaitez localiser dans le sous-réseau Ou le réseau virtuel Azure Managed Lustre.
Si vous utilisez un cluster Azure Kubernetes Service (AKS) avec votre système de fichiers Azure Managed Lustre, vous pouvez localiser le cluster AKS dans le même sous-réseau que le système de fichiers. Dans ce cas, vous devez fournir suffisamment d’adresses IP pour les nœuds et les pods AKS en plus de l’espace d’adressage pour le système de fichiers Lustre. Si vous utilisez plusieurs clusters AKS au sein du réseau virtuel, vérifiez que celui-ci dispose d’une capacité suffisante pour toutes les ressources de tous les clusters. Pour en savoir plus sur les stratégies réseau relatives à Azure Managed Lustre et AKS, consultez Accès au sous-réseau AKS.
Si vous envisagez d’utiliser une autre ressource pour héberger vos machines virtuelles de calcul dans le même réseau virtuel, vérifiez les conditions requises pour ce processus avant de créer le réseau virtuel et le sous-réseau pour votre système Azure Managed Lustre. Lors de la planification de plusieurs clusters au sein du même sous-réseau, il est nécessaire d’utiliser un espace d’adressage suffisamment grand pour répondre aux exigences totales de tous les clusters.
Accès au sous-réseau et autorisations
Par défaut, aucun changement spécifique n’est nécessaire pour activer Azure Managed Lustre. Si votre environnement inclut des stratégies de réseau ou de sécurité restreintes, vous devez prendre en compte les conseils d’aide suivants :
| Type d’accès | Paramètres réseau obligatoires |
|---|---|
| Accès DNS | Utilisez le serveur DNS Azure par défaut. |
| Accès entre les hôtes | Autorisez l’accès entrant et sortant entre les hôtes au sein du sous-réseau Azure Managed Lustre. Par exemple, l’accès au port TCP 22 (SSH) est nécessaire pour le déploiement du cluster. |
| Accès à Azure Cloud Services | Configurez votre groupe de sécurité réseau pour autoriser le système de fichiers Azure Managed Lustre à accéder à Azure Cloud Services depuis le sous-réseau du système de fichiers. Ajoutez une règle de sécurité pour le trafic sortant avec les propriétés suivantes : - Port : N’importe laquelle - Protocole : N’importe laquelle - Source : Réseau virtuel - Destination : Étiquette de service « AzureCloud » - Action : Autoriser Remarque : La configuration d’Azure Cloud Services permet également d’effectuer la configuration nécessaire au service de File d’attente Azure. Pour plus d’informations, consultez Étiquettes de service du réseau virtuel. |
| Accès au port réseau Lustre | Votre groupe de sécurité réseau doit autoriser l’accès entrant et sortant sur le port 988 et les ports 1019-1023. Aucun autre service ne peut réserver ou utiliser ces ports sur vos clients Lustre. Les règles par défaut 65000 AllowVnetInBound et 65000 AllowVnetOutBound répondent à cette exigence. |
Pour obtenir des conseils d’aide détaillés sur la configuration d’un groupe de sécurité réseau pour les systèmes de fichiers Azure Managed Lustre, consultez Créer et configurer un groupe de sécurité réseau.
Limitations connues
Les limitations connues suivantes s’appliquent aux paramètres de réseau virtuel pour les systèmes de fichiers Azure Managed Lustre :
- Les ressources Azure Managed Lustre et Azure NetApp Files ne peuvent pas partager un sous-réseau. Si vous utilisez le service Azure NetApp Files, vous devez créer votre système de fichiers Azure Managed Lustre dans un sous-réseau distinct. Le déploiement échoue si vous essayez de créer un système de fichiers Azure Managed Lustre dans un sous-réseau qui contient actuellement ou a déjà contenu des ressources Azure NetApp Files.
- Si vous utilisez le
ypbinddémon sur vos clients pour conserver les informations de liaison NIS (Network Information Services), vous devez vous assurer queypbindle port 988 n’est pas réservé. Vous pouvez ajuster manuellement les ports réservés parypbind, ou vérifier que l’infrastructure de démarrage de votre système lance le montage de votre client Lustre avant de démarrerypbind.
Remarque
Une fois que vous avez créé votre système de fichiers Azure Managed Lustre, plusieurs nouvelles interfaces réseau apparaissent dans le groupe de ressources du système de fichiers. Leurs noms commencent par amlfs- et finissent par -snic. Ne changez aucun paramètre sur ces interfaces. Plus précisément, gardez la valeur par défaut, activé, pour le paramètre Performances réseau accélérées. La désactivation des performances réseau accélérées sur ces interfaces réseau dégrade les performances de votre système de fichiers.
Conditions préalables à l’intégration d’objets blob (facultatif)
Si vous prévoyez d’intégrer votre système de fichiers Azure Managed Lustre au service Stockage Blob Azure, respectez les prérequis suivants avant de créer votre système de fichiers.
Pour en savoir plus sur l’intégration d’objets blob, consultez Utiliser le service Stockage Blob Azure avec un système de fichiers Azure Managed Lustre.
Azure Managed Lustre fonctionne avec des comptes de stockage qui ont un espace de noms hiérarchique activé et des comptes de stockage avec un espace de noms non hiérarchique ou plat. Les différences mineures suivantes s’appliquent :
- Pour un compte de stockage avec un espace de noms hiérarchique activé, Azure Managed Lustre lit les attributs POSIX à partir de l’en-tête d’objet blob.
- Pour un compte de stockage qui n’a pas d’espace de noms hiérarchique activé, Azure Managed Lustre lit les attributs POSIX à partir des métadonnées d’objet blob. Un fichier distinct et vide portant le même nom que le contenu de votre conteneur d’objets blob est créé pour contenir les métadonnées. Ce fichier est un frère du répertoire de données réel dans le système de fichiers Azure Managed Lustre.
Pour intégrer le service Stockage Blob Azure à votre système de fichiers Azure Managed Lustre, vous devez créer ou configurer les ressources suivantes avant de créer le système de fichiers :
Compte de stockage
Vous devez créer un compte de stockage ou en utiliser un existant. Le compte de stockage doit avoir les paramètres suivants :
- Type de compte - Type de compte de stockage compatible. Pour en savoir plus, consultez Les types de comptes de stockage pris en charge.
- Rôles d’accès - Attributions de rôles qui permettent au système Azure Managed Lustre de modifier les données. Pour en savoir plus, consultez Rôles d’accès obligatoires.
- Clés d’accès - Le paramètre d’accès via des clés de compte de stockage doit avoir la valeur Activé pour le compte de stockage.
Types de compte de stockage pris en charge
Les types de comptes de stockage suivants peuvent être utilisés avec les systèmes de fichiers Azure Managed Lustre :
| Type de compte de stockage | Redondance |
|---|---|
| Standard | Stockage localement redondant (LRS), stockage géoredondant (GRS) Stockage redondant interzone (ZRS), stockage géoredondant avec accès en lecture (RAGRS), stockage géoredondant interzone (GZRS), stockage géoredondant avec accès en lecture (RA-GZRS) |
| Premium - Objets blob de blocs | LRS, ZRS |
Pour plus d’informations sur les types de comptes de stockage, consultez Types de comptes de stockage.
Rôles d’accès pour l’intégration d’objets blob
Azure Managed Lustre a besoin d’une autorisation pour accéder à votre compte de stockage. Utilisez le contrôle RBAC Azure (contrôle d’accès en fonction du rôle Azure) pour accorder au système de fichiers l’accès à votre instance du service Stockage Blob.
Tout propriétaire du compte de stockage doit ajouter ces rôles avant de créer le système de fichiers :
Important
Vous devez ajouter ces rôles avant de créer votre système de fichiers Azure Managed Lustre. Si le système de fichiers ne peut pas accéder à votre conteneur d’objets blob, la création du système de fichiers échoue. La validation effectuée avant la création du système de fichiers ne peut pas détecter les problèmes d’autorisation d’accès au conteneur. La propagation des paramètres de rôle dans l’environnement Azure peut prendre jusqu’à cinq minutes.
Pour ajouter les rôles du principal de service Fournisseur de ressources HPC Cache, suivez ces étapes :
- Accédez à votre compte de stockage, puis sélectionnez Contrôle d’accès (IAM) dans le volet de navigation de gauche.
- Sélectionnez Ajouter>Ajouter une attribution de rôle pour ouvrir la page Ajouter une attribution de rôle.
- Attribuez le rôle.
- Ajoutez Fournisseur de ressources HPC Cache à ce rôle.
Conseil
Si vous ne trouvez pas le fournisseur de ressources HPC Cache, recherchez storagecache à la place. Fournisseur de ressources storagecache était le nom de principal du service avant la version en disponibilité générale du produit.
- Répétez les étapes 3 et 4 pour ajouter chaque rôle.
Pour connaître les étapes détaillées, consultez Attribuer des rôles Azure à l’aide du portail Azure.
Conteneurs d’objets blob
Vous devez disposer de deux conteneurs d’objets blob distincts dans le même compte de stockage, qui sont utilisés aux fins suivantes :
- Conteneur de données : Conteneur d’objets blob dans le compte de stockage, qui contient les fichiers à utiliser dans le système de fichiers Azure Managed Lustre.
- Conteneur de journalisation : Deuxième conteneur pour les journaux d’importation/d’exportation dans le compte de stockage. Vous devez stocker les journaux dans un conteneur distinct de celui du conteneur de données.
Remarque
Vous pourrez ajouter des fichiers au système de fichiers plus tard à partir de clients. Toutefois, les fichiers ajoutés au conteneur d’objets blob d’origine après la création du système de fichiers ne sont pas importés dans le système de fichiers Azure Managed Lustre, sauf si vous créez un travail d’importation.
Points de terminaison privés (facultatif)
Si vous utilisez un point de terminaison privé avec votre configuration d’objet blob, afin de vous assurer qu’Azure Managed Lustre peut résoudre le nom de la sa, vous devez activer le paramètre de point de terminaison privé Intégrer à la zone DNS privée lors de la création d’un nouveau point de terminaison.
- Intégrer à DNS privé zone : doit être défini sur Oui.
