Examiner les ressources actuelles et le modèle d'hébergement

Dans l'onglet Ressources, vous trouverez les tuiles Modèle d'hébergement et Allocations de ressources. Ces tuiles reflètent vos ressources et votre modèle d'hébergement actuels. En sélectionnant Configurer, vous pouvez ajuster les paramètres de chaque tuile.

Mise à l'échelle à l'aide de l'interface utilisateur

Dans l'onglet Ressources de l'interface utilisateur, sélectionnez Configurer sur la tuile Allocations de ressources. Un panneau s'ouvre alors, dans lequel vous pouvez ajuster vos ressources.

Si votre base de données est sur le modèle d'hébergement Isolated Compute, vous voyez alors un tableau "Host sizes", où vous pouvez sélectionner la configuration vCPU et RAM par membre pour votre base de données.

Si vous êtes sur le modèle d'hébergement Shared Compute, vous voyez la configuration Small, qui fournit 0.5 vCPU et 4 Go de RAM par membre ; l'option Small Custom ; ou la configuration Custom. Small Custom indique que votre base de données a été dimensionnée à l'aide du CLI, de l'API ou de Terraform, qui permet une mise à l'échelle plus fine des ressources, ainsi qu'une option d'allocation automatique de vCPU au prorata de la valeur de la RAM. Dans l'interface utilisateur, il est possible d'adapter les valeurs Small et Custom, mais il n'est pas possible d'adapter les valeurs fines fournies par l'interface CLI, l'API ou Terraform. Avec Personnalisé, faites glisser le curseur ou ajustez la valeur dans la boîte de saisie pour sélectionner les valeurs de vCPU et de RAM par membre de votre base de données.

Le curseur "Disque (GB/membre)" correspond à votre choix de disque par membre. Faites glisser le curseur ou ajustez le nombre dans la boîte de saisie pour modifier le nombre de Go de disque. Notez que le disque est lié à l'IOPS à 1 Go = 10 IOPS.

Membres est le nombre de membres de votre base de données. Pour Elasticsearch, le nombre de membres est fixé à 3.

Vérifiez le coût total estimé à l'aide de la calculatrice située au bas de la page. Notez que si vous avez des coûts acquis, également connus sous le nom de structure tarifaire héritée, la mise à l'échelle de votre instance de base de données supprimera une partie ou la totalité de votre tarification héritée. Pour plus d'informations sur les droits acquis et leur échéance, voir le calendrier de transition des modèles d'hébergement.

Une fois que vous avez terminé, cliquez sur "Appliquer les modifications" pour déclencher l'opération de mise à l'échelle.

Passer d'un modèle d'hébergement à l'autre dans l'interface utilisateur

Dans l'onglet Ressources de l'interface utilisateur, sélectionnez Configurer sur la tuile Modèle d'hébergement. Cela ouvre un panneau où vous pouvez ajuster votre sélection de modèle d'hébergement.

La première option disponible est "Sélectionnez votre modèle d'hébergement". Ici, vous pouvez passer à un autre modèle d'hébergement.

Ci-dessous, vous voyez les options permettant d'ajuster également les ressources du nouveau modèle d'hébergement que vous avez sélectionné. Suivez les instructions de la section précédente, "Mise à l'échelle dans l'interface utilisateur", pour ajuster vos ressources.

Cliquez sur Appliquer les modifications pour déclencher cette opération de mise à l'échelle.

Examiner les ressources actuelles et le modèle d'hébergement

Le plug-in d'interface de ligne de commande Cloud Databases IBM Cloud prend en charge l'affichage et la mise à l'échelle des ressources sur votre déploiement. Utilisez la commande cdb deployment-groups pour afficher les informations de ressource en cours pour votre service, y compris les groupes de ressources qui peuvent être ajustés. Pour mettre à l'échelle l'un des groupes de ressources disponibles, utilisez la commande cdb deployment-groups-set.

Par exemple, la commande suivante permet d'afficher les groupes de ressources d'un déploiement nommé "exemple-déploiement". Notez que cette commande indiquera également si votre base de données est une instance Shared Compute ou Isolated Compute grâce à l'attribut hostflavor Si le hostflavor est nul, c'est qu'il s'agit d'un ancien modèle d'hébergement.

ibmcloud cdb deployment-groups example-deployment

Le résultat de cette commande est le suivant :

Group   member
Count   3
|
+   Memory
|   Allocation              3072mb
|   Allocation per member   1024mb
|   Minimum                 3072mb
|   Step Size               384mb
|   Adjustable              true
|   Cpu Enforcement Ratio Ceiling   49152mb
|   Cpu Enforcement Ratio           8192mb
|
+   CPU
|   Allocation              0
|   Allocation per member   0
|   Minimum                 9
|   Step Size               3
|   Adjustable              true
|
+   HostFlavor
|   ID            multitenant
|   Name
|   HostingSize
|
+   Disk
|   Allocation              15360mb
|   Allocation per member   5120mb
|   Minimum                 15360mb
|   Step Size               3072mb
|   Adjustable              true

Le déploiement comporte trois membres, avec une quantité totale de 3072 Mo de mémoire RAM et 15360 Mo de disque allouée. L'allocation par membre est 1024 Mo de mémoire RAM et 5120 Mo de disque. La valeur minimale est la valeur la plus basse qui peut être définie pour l'allocation totale. La taille d'étape est la plus petite quantité qui peut être utilisée pour ajuster l'allocation totale.

Ressources et mise à l'échelle dans l'interface de ligne de commande

La commande cdb deployment-groups-set permet de définir l'allocation totale de la RAM ou du disque en Mo. Par exemple, pour mettre à l'échelle la mémoire de "example-deployment" à 4096 Mo de mémoire RAM pour chaque membre de mémoire (pour une quantité totale de mémoire de 12288 Mo), utilisez la commande suivante :

ibmcloud cdb deployment-groups-set example-deployment member --memory 12288

Déterminer le modèle d'hébergement de votre base de données dans le CLI

Utilisez la commande suivante pour vérifier la valeur de l'attribut hostflavor. Cette valeur est nulle si la base de données se trouve sur un modèle d'hébergement obsolète (pas de calcul partagé ou isolé).

ibmcloud cdb groups <deployment_id> --json

Passer d'un modèle d'hébergement à l'autre dans l'interface de programmation

Si votre base de données est une instance Shared Compute, vous pouvez ajuster les options de mémoire, d'UC et de disque à l'aide de la commande suivante. Si votre base de données n'est pas sur Shared Compute, cette commande déplacera également une base de données d'un modèle d'hébergement différent vers le modèle d'hébergement Shared Compute.

ibmcloud cdb deployment-groups-set <deploymentid> <groupid> [--memory <val>] [--cpu <val>] [--disk <val>] [--hostflavor multitenant]

Par exemple, utilisez la procédure suivante pour mettre à l'échelle une instance de Shared Compute ou pour mettre à l'échelle votre instance de Shared Compute :

ibmcloud cdb deployment-groups-set crn:abc ... xyz:: member  --memory 24576 --cpu 6  --hostflavor multitenant

Si votre base de données est une instance de calcul isolé, la mémoire et l'UC sont ajustées ensemble en sélectionnant la taille de calcul isolé (voir toutes les tailles dans le tableau 1). Le disque est mis à l'échelle séparément. Si votre base de données n'est pas sur Isolated Compute, cette commande déplacera également une base de données d'un modèle d'hébergement différent vers le modèle d'hébergement Isolated Compute.

Notez que puisque la sélection de la saveur de l'hôte inclut les tailles de CPU et de RAM b3c.4x16.encrypted est 4 CPU et 16 RAM), cette requête n'accepte pas à la fois une sélection de taille isolée et des sélections séparées d'allocation de CPU et de RAM.

ibmcloud cdb deployment-groups-set <deploymentid> <groupid> [--disk <val>] [--hostflavor <hostflavor>]

Par exemple, utilisez la procédure suivante pour mettre à l'échelle une instance d'ordinateur isolé ou pour mettre à l'échelle votre instance d'ordinateur isolé :

ibmcloud cdb deployment-groups-set crn:abc ... xyz:: member  --hostflavor b3c.8x32.encrypted

Examiner les ressources actuelles et le modèle d'hébergement

Le noeud final de base qui s'affiche sur le panneau Aperçu de votre service fournit l'URL de base permettant d'accéder à ce déploiement via l'API. Utilisez-le avec le noeud final /groups si vous devez gérer ou automatiser la mise à l'échelle à l'aide d'un programme.

Pour afficher les ressources actuelles et évolutives sur un déploiement, utilisez le noeud final /deployments/{id}/groups. Notez que cette commande indiquera également si votre base de données est une instance Shared Compute ou Isolated Compute grâce à l'attribut host_flavor Si le host_flavor est nul, c'est qu'il s'agit d'un ancien modèle d'hébergement.

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups'

Mise à l'échelle à l'aide de l'API

Pour augmenter la mémoire d'un déploiement à 4096 Mo de RAM pour chaque membre (il y en a 3, soit une mémoire totale de 12288 Mo), utilisez le point de terminaison de l'API /déploiements/{id}/groupes/{group_id}.

curl -X PATCH 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"memory": {
        "allocation_mb": 12288
      }
    }'

Déterminer le modèle d'hébergement de votre base de données dans l'API

Utilisez la commande suivante pour vérifier la valeur de l'attribut host_flavor. Cette valeur est nulle si la base de données se trouve sur un modèle d'hébergement obsolète (pas de calcul partagé ou isolé).

curl -X GET https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups -H 'Authorization: Bearer <>' \

Passer d'un modèle d'hébergement à l'autre dans l'API

Pour mettre à l'échelle une instance Cloud Databases Shared Compute, utilisez la commande suivante, en définissant host_flavor sur multitenant. Si votre base de données n'est pas sur Shared Compute, cette commande déplacera également une base de données d'un modèle d'hébergement différent vers le modèle d'hébergement Shared Compute.

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member
-H 'Authorization: Bearer <>'
-H 'Content-Type: application/json'
-d '{"host_flavor":
        {"id": "multitenant"},
      "cpu":
        {"allocation_count": 3},
      "memory":
        {"allocation_mb": 12288}
    }' \

Pour mettre à l'échelle une instance dans une instance Cloud Databases de calcul isolé ou pour mettre à l'échelle une autre taille de calcul isolé, utilisez le paramètre host_flavor, cette fois défini sur la taille de calcul isolé souhaitée. Les tailles d'hébergement disponibles et leurs paramètres de valeur host_flavor sont répertoriés dans le Tableau 1. Par exemple, {"host_flavor": "b3c.4x16.encrypted"}. Notez que puisque la sélection de la saveur de l'hôte inclut les tailles de CPU et de RAM (b3c.4x16.encrypted est 4 CPU et 16 RAM), cette requête n'accepte pas à la fois une sélection de taille isolée et des sélections séparées d'allocation de CPU et de RAM. Procédez à une mise à l'échelle avec le noeud final de mise à l'échelle d'API Cloud Databases, à l'aide d'une commande telle que la suivante:

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member
-H 'Authorization: Bearer <>'
-H 'Content-Type: application/json'
-d '{"host_flavor": {"id": "b3c.4x16.encrypted"}}' \

La mise à l'échelle automatique du CPU et de la RAM n'est pas prise en charge sur Cloud Databases Isolated Compute. La mise à l'échelle automatique du disque est disponible. Si vous avez provisionné une instance isolée ou si vous êtes passé d'un déploiement avec autoscaling, gardez un œil sur vos ressources en utilisant l'intégration IBM Cloud® Monitoring, qui fournit des mesures pour la mémoire, l'espace disque et l'utilisation des E/S disque. Pour ajouter des ressources à votre instance, mettez à l'échelle manuellement votre déploiement.

Examiner les ressources actuelles et le modèle d'hébergement

Examinez les ressources allouées à votre base de données en vérifiant les scripts terraform pour cpu { allocation_count = }, memory {allocation_mb = } et disk { allocation_mb = }. Examinez le paramètre host_flavor pour déterminer si votre base de données est un modèle d'hébergement de type Calcul partagé ou Calcul isolé. Si host_flavor n'existe pas, votre base de données se trouve sur un ancien modèle d'hébergement.

Mise à l'échelle avec Terraform

Avant d'exécuter un script Terraform sur une instance existante, utilisez la commande terraform plan pour comparer l'état de l'infrastructure en cours à l'état souhaité défini dans vos fichiers Terraform. Toute modification apportée aux attributs resource_group_id, service plan, version, key_protect_instance, key_protect_key, backup_encryption_key_crn recrée votre instance. Pour obtenir la liste des références d'argument en cours avec la spécification Forces new resource, voir ibm_database Terraform Registry.

Faites évoluer votre instance en ajustant votre script Terraform pour la ressource qui vous intéresse. Dans l'exemple suivant, les allocations cpu, memory et disk sont spécifiées. Notez que si vous avez sélectionné une variante d'hôte (Isolated Compute ou Shared Compute Multitenant), conservez la sélection de la variante d'hôte dans votre script.

Pour mettre en œuvre votre changement, exécutez terraform apply.

data "ibm_resource_group" "group" {
  name = "<your_group>"
}
resource "ibm_database" "<your_database>" {
  name              = "<your_database_name>"
  plan              = "standard"
  location          = "eu-gb"
  service           = "databases-for-elasticsearch"
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["tag1", "tag2"]
  adminpassword     = "password12"
  group {
    group_id = "member"
    cpu {
      allocation_count = 6
    }
    memory {
      allocation_mb = 24576
    }
    disk {
      allocation_mb = 256000
    }
  }
  users {
    name     = "user123"
    password = "password12"
  }
  allowlist {
    address     = "172.168.1.1/32"
    description = "desc"
  }
}
output "ICD Elasticsearch database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}

Vous pouvez également utiliser des modules Terraform IBM(TIM) préconstruits, open-source et prêts à l'emploi pour les entreprises, qui prennent en charge la fonction de mise à l'échelle automatique Databases for Elasticsearch qui prennent en charge la fonction de mise à l'échelle automatique.

Passage à des modèles d'hébergement et mise à l'échelle dans Terraform

Sélectionnez le modèle d'hébergement auquel votre base de données doit être adaptée. Vous pourrez changer ces informations ultérieurement.

Pour mettre à l'échelle votre instance Databases for Elasticsearch vers la saveur d'hébergement Shared Compute, définissez le paramètre "host_flavor" sur multitenant. Cela fonctionne si vous voulez évoluer vers la saveur d'hébergement Shared Compute, ou si vous voulez garder la saveur de l'hôte et faire évoluer vos ressources. Pour implémenter votre modification, exécutez terraform apply. Voir l'exemple suivant :

data "ibm_resource_group" "group" {
  name = "<your_group>"
}
resource "ibm_database" "<your_database>" {
  name              = "<your_database_name>"
  plan              = "standard"
  location          = "eu-gb"
  service           = "databases-for-elasticsearch"
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["tag1", "tag2"]
  adminpassword     = "password12"
  group {
    group_id = "member"
    host_flavor {
      id = "multitenant"
    },
    cpu {
      allocation_count = 6
    }
    memory {
      allocation_mb = 24576
    }
    disk {
      allocation_mb = 256000
    }
  }
  users {
    name     = "user123"
    password = "password12"
  }
  allowlist {
    address     = "172.168.1.1/32"
    description = "desc"
  }
}
output "ICD Elasticsearch database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}

Mettez à l'échelle votre instance Databases for Elasticsearch vers Isolated Compute avec le même paramètre "host_flavor", défini à la taille isolée souhaitée. Cette commande permet de mettre à l'échelle votre instance de base de données vers une taille différente d'Isolated Compute, ainsi que de passer d'une autre saveur d'hôte à la saveur d'hôte d'Isolated Compute. Les tailles d'hébergement disponibles et leurs paramètres host_flavor value sont répertoriés dans le Tableau 1. Par exemple, {"host_flavor": "b3c.4x16.encrypted"}. Notez que puisque la sélection de la saveur de l'hôte inclut les tailles de CPU et de RAM (b3c.4x16.encrypted est 4 CPU et 16 RAM), cette requête n'accepte pas à la fois une sélection de taille isolée et des sélections séparées d'allocation de CPU et de RAM.

Pour mettre en œuvre votre changement, exécutez terraform apply.

data "ibm_resource_group" "group" {
  name = "<your_group>"
}
resource "ibm_database" "<your_database>" {
  name              = "<your_database_name>"
  plan              = "standard"
  location          = "eu-gb"
  service           = "databases-for-elasticsearch"
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["tag1", "tag2"]
  adminpassword     = "password12"
  group {
    group_id = "member"
    host_flavor {
      id = "b3c.8x32.encrypted"
    }
    disk {
      allocation_mb = 256000
    }
  }
  users {
    name     = "user123"
    password = "password12"
  }
  allowlist {
    address     = "172.168.1.1/32"
    description = "desc"
  }
}
output "ICD Elasticsearch database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}