Partager via

Stockage hautes performances dans Azure DocumentDB

Azure DocumentDB utilise des disques Premium SSD v2 pour offrir des performances significativement plus élevées pour les charges de travail intensives en E/S en découplant la capacité de stockage des paramètres d’IOPS et de bande passante.

Avec le stockage SSD Premium v2 sur Azure DocumentDB, les paramètres d’E/S par seconde et de bande passante configurables maximales sont disponibles par défaut, quelle que soit la capacité de stockage configurée pour le cluster. L’IOPS et la capacité de bande passante du niveau de calcul déterminent les IOPS et la bande passante réalisables dans la couche de stockage sans avoir à augmenter la capacité de stockage.

Seule la capacité de stockage requise doit être sélectionnée, tandis que les E/S par seconde réalisables les plus élevées et la bande passante sont configurées automatiquement par Azure DocumentDB sans coût supplémentaire. Aucune intervention supplémentaire de l’utilisateur n’est nécessaire pour garantir que le cluster est configuré pour des performances optimales. Le résultat est une amélioration des performances 12x sans coût supplémentaire.

Auparavant, un saut de 5 000 IOPS à 20 000 IOPS exigeait une augmentation de la taille du disque de 1 To à 20 To, même en l’absence de besoins de stockage plus élevés. Avec ssd Premium v2, 20 000 IOPS peuvent être obtenues sur le même disque de 1 To tant que le niveau de calcul du cluster a la capacité d’envoyer (push) et de maintenir 20 000 IOPS. De plus, les disques SSD Premium v2 peuvent prendre en charge jusqu’à 80 000 IOPS , soit une augmentation de 4 fois par rapport au disque SSD Premium.

Instructions

Les performances maximum pour votre cluster DocumentDB Azure dépendent désormais uniquement du niveau compute et non de la taille de stockage. Commencez par choisir uniquement la taille de stockage souhaitée pour le cluster, puis sélectionnez un niveau de calcul qui fournit les E/S par seconde requises et le débit (MBits/s) pour votre charge de travail. Les IOPS et les limites de bande passante les plus réalisables et durables par niveau de calcul sont tabulées ci-dessous.

IOPS et limites de débit

Avec les disques SSD Premium v2, le cluster est automatiquement configuré avec les valeurs supérieures limitées indiquées ci-dessous, sans coût supplémentaire.

Niveau de calcul Nombre maximal d’IOPS Bande passante maximale (Mbits/s)
M30 (2 cœurs) 3 750 85
M40 (4 cœurs) 6 400 145
M50 (8 cœurs) 12 800 290
M60 (16 cœurs) 25 600 600
M80 (32 cœurs) 51 200 865
M200 (64 cœurs) 80 000 1,200

Prerequisites

  • Un abonnement Azure

    • Si vous n'avez pas d'abonnement Azure, créez un compte free

  • Un cluster DocumentDB Azure existant

    • Si vous n’avez pas de cluster, créez un cluster

Créer un cluster avec un stockage hautes performances

Configurez un cluster à l’aide du stockage SSD Premium v2 (hautes performances) dans le cadre de l’étape de création du cluster.

  1. Connectez-vous au portail Azure (https://portal.azure.com).

  2. Dans le menu du portail Azure ou dans la page Home, sélectionnez Créer une ressource.

  3. Dans la page New, recherchez et sélectionnez Azure DocumentDB.

    Screenshot de la fonctionnalité de recherche du portail Azure pour localiser Azure DocumentDB.

  4. Dans la page Créer un cluster Azure DocumentDB et dans la section Paramètres de base, sélectionnez l’option Configurer dans la section Niveau de cluster.

    Capture d'écran des options disponibles pour configurer un cluster Azure DocumentDB.

  5. Dans la page Configurer , choisissez le niveau de cluster et la taille de stockage en fonction des besoins. Sélectionnez le type de stockage en tant que SSD Premium v2 pour activer le stockage hautes performances, puis sélectionnez Enregistrer pour appliquer les modifications.

    Screenshot de l’option de configuration spécifique aux disques SSD Premium v2 dans Azure DocumentDB.

  6. Renseignez les détails restants, puis sélectionnez Vérifier + créer.

  7. Passez en revue les paramètres que vous fournissez, puis sélectionnez Créer. La création du cluster ne prend que quelques minutes. Attendez que le déploiement des ressources soit terminé.

  8. Enfin, sélectionnez Go to resource pour accéder au cluster DocumentDB Azure dans le portail.

Capture d’écran de l’étape d’achèvement du déploiement avec une option permettant d’accéder au nouveau cluster Azure DocumentDB.

  1. Ouvrez un nouveau terminal.

  2. Connectez-vous à Azure CLI.

  3. Créez un fichier Bicep pour définir votre définition de rôle. Nommez le fichier main.bicep.

  4. Ajoutez ce modèle au contenu du fichier. Remplacez les espaces réservés <cluster-name>, <location>, <username> et <password> par les valeurs appropriées.

    resource cluster 'Microsoft.DocumentDB/mongoClusters@2025-09-01' = {
  name: '<cluster-name>'
  location: '<location>'
  properties: {
    administrator: {
      userName: '<username>'
      password: '<password>'
    }
    serverVersion: '8.0'
    storage: {
      sizeGb: 32
      type: 'PremiumSSDv2'
    }
    compute: {
      tier: 'M30'
    }
    sharding: {
      shardCount: 1
    }
    highAvailability: {
      targetMode: 'Disabled'
    }
  }
}

  5. Déployez le modèle Bicep à l’aide de az deployment group create. Spécifiez le nom du modèle Bicep et remplacez l’espace réservé <resource-group> par le nom de votre groupe de ressources Azure cible.

    az deployment group create \
    --resource-group "<resource-group>" \
    --template-file main.bicep

  6. Attendez que le déploiement se termine. Passez en revue la sortie du déploiement.

  1. Ouvrez un nouveau terminal.

  2. Connectez-vous à Azure CLI.

  3. Vérifiez votre abonnement Azure cible.

    az account show

  4. Définissez votre cluster dans un nouveau fichier Terraform. Nommez le cluster de fichiers .tf.

  5. Ajoutez cette configuration de ressource au contenu du fichier. Remplacez les <cluster-name>, <resource-group> et <location> par les valeurs appropriées.

    variable "admin_username" {
  type        = string
  description = "Administrator username for the cluster."
  sensitive   = true
}

variable "admin_password" {
  type        = string
  description = "Administrator password for the cluster."
  sensitive   = true
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "existing" {
  name = "<resource-group>"
}

resource "azurerm_mongo_cluster" "cluster" {
  name                   = "<cluster-name>"
  resource_group_name    = data.azurerm_resource_group.existing.name
  location               = "<location>"
  administrator_username = var.admin_username
  administrator_password = var.admin_password
  shard_count            = "1"
  compute_tier           = "M30"
  high_availability_mode = "Disabled"
  storage_size_in_gb     = "32"
  storage_type           = "PremiumSSDv2"
  version                = "8.0"
}

    Conseil / Astuce

    Pour plus d’informations sur les options à l’aide de la azurerm_mongo_cluster ressource, consultez azurerm la documentation du fournisseur dans Terraform Registry.

  6. Initialisez le déploiement Terraform.

    terraform init --upgrade

  7. Créez un plan d’exécution et enregistrez-le dans un fichier nommé cluster.tfplan. Fournissez des valeurs lorsque vous êtes invité pour les variables admin_username et admin_password.

    ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --out "cluster.tfplan"

    Note

    Cette commande définit temporairement la variable d’environnement ARM_SUBSCRIPTION_ID . Ce paramètre est requis pour le fournisseur azurerm à partir de la version 4.0. Pour plus d'informations, consultez l'identifiant d'abonnement dans azurerm.

  8. Appliquez le plan d’exécution pour déployer le cluster sur Azure.

    ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "cluster.tfplan"

  9. Attendez que le déploiement se termine. Passez en revue la sortie du déploiement.

  1. Ouvrez un nouveau terminal.

  2. Connectez-vous à Azure CLI.

  3. Créez un fichier JSON nommé cluster.json.

  4. Ajoutez ce document au contenu du fichier. Remplacez les <location>, <username> et <password> par les valeurs appropriées.

    {
  "location": "<location>",
  "properties": {
    "administrator": {
      "userName": "<username>",
      "password": "<password>"
    },
    "serverVersion": "8.0",
    "storage": {
      "sizeGb": 32,
      "type": "PremiumSSDv2"
    },
    "compute": {
      "tier": "M30"
    },
    "sharding": {
      "shardCount": 1
    },
    "highAvailability": {
      "targetMode": "Disabled"
    }
  }
}

  5. Utilisez la commande az rest Azure CLI pour créer un cluster avec la configuration spécifiée dans le fichier JSON. Spécifiez le nom du fichier JSON en tant qu'body de la requête et remplacez les espaces réservés suivants :

    Descriptif
    <subscription-id> Identificateur unique de votre abonnement Azure cible
    <resource-group> Nom de votre groupe de ressources Azure cible
    <cluster-name> Nom unique de votre nouveau cluster DocumentDB Azure 
    az rest \
    --method "GET" \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01" \
    --body @cluster.json

    Conseil / Astuce

    Utilisez az account show pour obtenir l’identificateur unique de votre abonnement Azure cible.

  6. Attendez que le déploiement se termine. Passez en revue la sortie du déploiement.

Limitations actuelles du stockage hautes performances (stockage SSD Premium v2)

  • Les clés gérées par le client (CMK) ne sont pas prises en charge avec le stockage SSD Premium v2.

  • Les paramètres de capacité de stockage sur les disques SSD Premium v2 peuvent être ajustés jusqu’à quatre fois au cours d’une période de 24 heures. Pour les clusters nouvellement créés, un maximum de trois ajustements de capacité de stockage peuvent être effectués au cours des 24 premières heures. 

  • La réplication de SSD Premium vers SSD Premium v2 est prise en charge uniquement pour les scénarios de migration. La réplication continue n’est pas prise en charge, car le SSD Premium ne peut pas correspondre aux performances du ssd Premium v2 et peut entraîner une latence plus élevée.

  • La migration en ligne de SSD Premium vers SSD Premium v2 n’est actuellement pas prise en charge. Pour effectuer une mise à niveau de SSD Premium vers SSD Premium V2, vous pouvez effectuer une restauration à un point dans le temps sur un nouveau serveur à l’aide de SSD Premium v2. Vous pouvez également créer une réplique en lecture à partir d’un serveur SSD Premium vers un serveur SSD Premium v2 et le promouvoir après la réplication.

  • Si vous effectuez une opération nécessitant une hydratation de disque, l’erreur suivante peut se produire. Cette erreur se produit parce que les disques SSD Premium v2 ne prennent pas en charge l’opération pendant que le disque est toujours en cours d’hydratage.

    • Message d’erreur : Impossible d’effectuer l’opération, car le disque est toujours hydraté. Recommencez l’opération un peu plus tard.
    • Les opérations qui peuvent déclencher ce comportement sont les suivantes :
      • Exécution de la mise à l’échelle du calcul, mise à l’échelle du stockage, activation de la haute disponibilité (HA) en succession rapide.
      • Cela inclut également les basculements déclenchés par le service pour garantir une haute disponibilité.
      • Utilisation de PITR (restauration dans le temps) pour créer un cluster et activer immédiatement la Haute Disponibilité alors que le disque est encore en cours d'hydratation.
    • En guise de meilleure pratique, lors de l’utilisation de disques SSD Premium v2, espacez ces opérations ou effectuez-les de manière séquentielle, ce qui garantit que l’hydratation du disque se termine entre les actions.

Contenu connexe

  • Last updated on