Partager via

Considérations importantes pour Azure Data Lake Storage

  • Article

En savoir plus sur les considérations clés de stockage pour vos lacs de données Azure.

Gestion du cycle de vie

Le Stockage Azure propose différents niveaux d’accès et vous permet de stocker vos objets blob de la manière la plus économique possible. Les niveaux d’accès disponibles incluent les suivants :

  • Chaud : optimisé pour le stockage des données souvent sollicitées.
  • Froid : optimisé pour le stockage des données peu sollicitées. Les données sont stockées pendant au moins 30 jours.
  • Niveau en ligne : optimisé pour le stockage des données rarement consultées ou modifiées. Les données sont stockées pendant au moins 90 jours. Le niveau d’accès froid possède des coûts de stockage plus faibles et des coûts d’accès plus élevés que le niveau sporadique.
  • Archive : optimisé pour le stockage des données rarement sollicitées. Les données sont stockées pendant au moins 180 jours avec des exigences flexibles en termes de latence, sur la base d’un nombre d’heures.

Important

Il n’existe aucune fiabilité, sécurité, excellence opérationnelle ou compromis d’efficacité des performances entre les différents niveaux d’accès en ligne, ce qui laisse le choix d’un niveau en ligne pour être une décision financière, par objet blob, en fonction de la taille des données d’accès aux charges de travail, des interactions opérationnelles et du temps avant la suppression de l’objet blob. Sélectionnez le niveau approprié, par objet blob, en fonction d’un calcul des facteurs précédents. Pour plus d’informations, consultez Planifier et gérer les coûts de Stockage Blob Azure.

Tenez compte des informations suivantes lors de l’utilisation des niveaux d’accès :

  • Seuls les niveaux d’accès chaud et froid peuvent être définis au niveau du compte. Le niveau d’accès archive n’est pas disponible au niveau du compte.

  • Les niveaux chaud, froid et archive peuvent tous être définis au niveau de l’objet blob durant ou après le chargement.

  • Les données des niveaux d’accès sporadique et froid offrent une disponibilité légèrement inférieure, mais présentent toujours des caractéristiques de durabilité élevée, de latence d’extraction et de débit similaires à celles des données de niveau chaud. Pour les données du niveau froid, une disponibilité légèrement inférieure et des coûts d’accès supérieurs peuvent être des compromis acceptables pour des coûts de stockage globaux inférieurs, par rapport au niveau chaud.

  • Stockage archive stocke des données hors connexion et offre les coûts de stockage les plus faibles. Toutefois, il dispose également des coûts d’accès et de réalimentation des données les plus élevés.

Pour plus d’informations, consultez Niveaux d’accès pour les données d’objets blob.

Attention

Pour l’analyse à l’échelle du cloud, nous vous recommandons d’implémenter la gestion du cycle de vie à l’aide d’un microservice personnalisé et d’évaluer soigneusement l’impact du déplacement des données détectables par l’utilisateur vers le stockage froid.

Vous ne devriez déplacer des sections de votre lac de données vers le niveau cool que pour des charges de travail bien assimilées.

Connectivité des lacs de données

Chacun de vos lacs de données doit utiliser des points de terminaison privés injectés dans le réseau virtuel de votre zone d’atterrissage des données. Pour fournir un accès entre les zones d’atterrissage, connectez les zones d’atterrissage des données via l’appairage de réseaux virtuels. Cette connexion fournit une solution optimale du point de vue des coûts et du contrôle d’accès.

Pour plus d’informations, consultez Points de terminaison privés et zone d’atterrissage de la gestion des données dans la zone d’atterrissage des données.

Important

Il est possible d’accéder aux données d’une zone d’atterrissage de données à partir d’une autre zone d’atterrissage de données via l’homologation de réseaux virtuels entre les zones. Pour ce faire, utilisez les points de terminaison privés associés à chaque compte de lac de données. Nous vous recommandons de désactiver tout accès public à vos lacs et à l’aide de points de terminaison privés. L'équipe chargée de l'exploitation de la plateforme doit contrôler la connectivité du réseau dans toutes les zones d'atterrissage des données.

Suppression réversible pour les conteneurs

La suppression réversible des conteneurs protège vos données contre des suppressions accidentelles ou malveillantes. Si vous activez la suppression réversible du conteneur pour votre compte de stockage, les conteneurs supprimés et leur contenu sont conservés dans Stockage Azure pendant la durée de votre choix. Pendant la période de rétention des données, vous pouvez restaurer des conteneurs précédemment supprimés. La restauration d’un conteneur a également pour effet de restaurer tous les objets blob qui figuraient dans celui-ci au moment de sa suppression.

Activez les fonctionnalités de protection des données suivantes pour assurer la protection des données blob de bout en bout :

Avertissement

La suppression d’un compte de stockage est irréversible. La suppression réversible d’un conteneur n’a pas pour effet de protéger contre la suppression d’un compte de stockage, mais uniquement contre la suppression de conteneurs dans un compte. Pour empêcher toute suppression d’un compte de stockage, configurez un verrou sur la ressource du compte de stockage. Pour plus d’informations sur le verrouillage des ressources Azure Resource Manager, consultez Verrouiller les ressources pour empêcher les modifications inattendues.

Monitoring

Dans une zone d’atterrissage des données, toute la supervision doit être envoyée à votre abonnement de gestion à l’échelle de l’entreprise à des fins d’analyse.

Pour en savoir plus sur les données de surveillance utilisées par stockage Azure, consultez Supervision de ressources Azure avec Azure Monitor. Pour obtenir davantage d’informations sur les journaux et les métriques créés par le Stockage Azure, consultez Supervision du service Stockage Blob Azure.

Les entrées de journal sont créées uniquement si des demandes sont effectuées sur le point de terminaison de service. Les types de demandes authentifiées suivants sont enregistrés :

  • Demandes ayant réussi
  • Demandes ayant échoué, y compris les erreurs de délai d’expiration, limitation, réseau, autorisation et autres erreurs
  • Demandes utilisant une signature d’accès partagé (SAS) ou OAuth, y compris les demandes ayant réussi et ayant échoué
  • Demandes de données d’analyse, comme les données de journal classique dans le conteneur $logs et données de métriques de classe dans les tables $metric

Les demandes effectuées par le service de stockage lui-même, telles que la création ou la suppression d’un journal, ne sont pas consignées. Les types de demandes anonymes suivants sont enregistrés :

  • Demandes ayant réussi
  • Erreurs de serveur
  • Erreurs de délai d’expiration pour le client et le serveur
  • Échec des requêtes HTTP GET avec le code d’erreur 304 (Not Modified)

Aucune autre demande anonyme ayant échoué n'est enregistrée.

Important

Définissez votre stratégie d’analyse par défaut pour auditer le stockage et envoyer les journaux à l’abonnement de gestion à l’échelle de votre entreprise.

Étapes suivantes