Remarque
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.
Stockage de conteneurs Azure activé par Azure Arc est un système de stockage interne conçu pour les clusters Kubernetes connectés à Arc. Cette extension Arc peut être déployée pour écrire des fichiers dans une revendication de volume persistant (PVC) ReadWriteMany où ils peuvent être stockés localement ou transférés vers des destinations de stockage Azure Blob dans le cloud.
Important
Azure Container Storage activé par Azure Arc est actuellement en préversion. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.
Azure Container Storage offre une gamme de fonctionnalités permettant de prendre en charge différentes charges de travail, telles que les modèles d’apprentissage IA et ML, Les opérations Azure IoT et d’autres services Arc. Avec les options de haute disponibilité et de tolérance de panne disponibles, cette extension Arc est prête pour les charges de travail de production.
Pour télécharger des diagrammes d’architecture en haute résolution, visitez Jumpstart Gems.
Que fait Azure Container Storage ?
Azure Container Storage sert de système de stockage persistant natif pour les clusters Kubernetes connectés à Arc. Son rôle principal est de fournir un système de fichiers flexible, fiable et tolérant aux pannes qui permet aux données d’être conservées en toute sécurité à la périphérie, d’être hiérarchisé vers Azure ou d’être mises en miroir à partir du cloud et disponibles localement.
Les principales fonctionnalités des clusters connectés à Arc exécutant cette extension sont les suivantes :
- Tolérance aux défaillances de nœud : Lorsqu’il est configuré en tant que trois clusters de nœuds ou plus, Azure Container Storage réplique les données entre les nœuds pour garantir une haute disponibilité et une tolérance aux défaillances de nœud unique.
- Stockage local sur votre cluster : Avec un volume partagé local à la périphérie, l'utilisateur peut stocker des données dans son déploiement de périphérie avec un modèle d’accès ReadWriteMany.
- Synchronisation des données vers Azure : Azure Container Storage est configuré avec un objectif de stockage, de sorte que les données écrites dans les volumes sont automatiquement transférées dans Azure Blob (blob de blocs, Azure Data Lake Storage Gen2 ou OneLake) dans le cloud.
- Miroir de données à partir d’Azure (préversion) : Le stockage conteneur Azure est configuré avec une cible de stockage. Par conséquent, les données écrites dans cette destination de stockage sont automatiquement mises en miroir en tant que copie en lecture seule vers le volume local de votre cluster.
- Connexion simple : Les clients peuvent facilement se connecter à un volume configuré à l’aide d’un pilote CSI pour commencer à effectuer des revendications de volume persistant sur leur stockage.
- Observable: Prend en charge les journaux d’activité et les métriques de surveillance Kubernetes standard et prend en charge l’observabilité de l’agent Azure Monitor.
Quelles sont les offres Azure Container Storage disponibles ?
Volumes partagés locaux : Fournit un stockage hautement disponible et capable de basculement, local pour votre cluster Kubernetes. Ce type de stockage partagé reste indépendant de l’infrastructure cloud, ce qui le rend idéal pour l’espace de travail, le stockage temporaire et les données persistantes localement non adaptées aux destinations cloud.
Ingestion cloud de sous-volumes : facilite l’ingestion illimitée de données de la périphérie vers des objets blobs, notamment Azure Data Lake Storage Gen2 et OneLake. Les fichiers écrits dans ce type de stockage sont transférés de manière transparente vers le stockage Blob, puis supprimés du cache local une fois leur téléchargement confirmé, garantissant la disponibilité de l’espace pour de nouvelles données. Les stratégies configurables permettent une flexibilité dans les comportements de chargement et de vidage. De plus, cette option de stockage prend en charge l’intégrité des données dans les environnements déconnectés, ce qui permet le stockage local et la synchronisation lors de la reconnexion au réseau.
Mise en miroir cloud des sous-volumes (préversion) : met en miroir les données du cloud vers la périphérie. À l’aide du stockage d’objets blob cloud comme origine des données, les sous-volumes miroirs permettent la distribution de contenu du cloud vers les applications Kubernetes situées en périphérie. La copie cloud de vos données est toujours la version faisant autorité. Votre copie locale est donc une image miroir des données de ce conteneur d’objets blob. Un sous-volume miroir fournit à votre application un réplica de système de fichiers ReadOnly pour la consultation à la périphérie. Le sous-volume Miroir est ReadOnly et les données ne peuvent pas être modifiées ou supprimées par des charges de travail consommant les données en périphérie. Si vous souhaitez modifier les données, vous devez modifier la version cloud faisant autorité.
Architecture détaillée
Pour télécharger des diagrammes d’architecture en haute résolution, visitez Jumpstart Gems.