Ajout de disque, de mémoire et d'UC
Le modèle d'hébergement Shared Compute prend en charge des allocations de ressources plus fines qui ne sont pas affichées dans l'interface utilisateur pour des raisons de clarté. Pour plus d'informations, voir Modèles d'hébergement.
Pour mettre à l'échelle une instance de saveur hôte Isolated compute, définissez le paramètre hostflavor
correspondant
à la taille de l'unité de calcul isolée que vous visez, par exemple "b3c.4x16.encrypted". Comme cela inclut les sélections d'allocation du CPU et de la RAM, ne sélectionnez pas séparément le CPU et la RAM.
Pour mettre à l'échelle une instance de saveur d'hôte Compute partagé entre la valeur minimale de CPU et 2 CPU, définissez
le CPU sur 0 et mettez à l'échelle l'allocation de RAM à l'aide des commandes suivantes. La valeur de l'unité centrale sera calculée sur la base d'un ratio de 1 unité centrale : 8 Go de RAM, jusqu'à 2 unités centrales. Pour passer à une échelle
supérieure à 2 CPU, réglez les allocations de CPU et de RAM sur votre allocation cible. Dans les deux cas, veillez à inclure le paramètre hostflavor
correspondant.
Pour mettre à l'échelle une instance de saveur hôte Isolated compute, définissez le paramètre host_flavor
correspondant
à la taille de l'unité de calcul isolée que vous visez, par exemple "b3c.4x16.encrypted". Comme cela inclut les sélections d'allocation du CPU et de la RAM, ne sélectionnez pas séparément le CPU et la RAM.
Pour mettre à l'échelle une instance de saveur d'hôte Compute partagé entre la valeur minimale de CPU et 2 CPU, définissez
le CPU sur 0 et mettez à l'échelle l'allocation de RAM à l'aide des commandes suivantes. La valeur de l'unité centrale sera calculée sur la base d'un ratio de 1 unité centrale : 8 Go de RAM, jusqu'à 2 unités centrales. Pour passer à une échelle
supérieure à 2 CPU, réglez les allocations de CPU et de RAM sur votre allocation cible. Dans les deux cas, veillez à inclure le paramètre host_flavor
correspondant.
Pour mettre à l'échelle une instance de saveur hôte Isolated compute, définissez le paramètre host_flavor
correspondant à la taille de l'unité de calcul isolée que vous visez, par exemple "b3c.4x16.encrypted". Comme cela inclut les sélections d'allocation du CPU et de la RAM, ne sélectionnez pas séparément le CPU et la RAM.
Pour mettre à l'échelle une instance de saveur d'hôte Compute partagé entre la valeur minimale de CPU et 2 CPU,
définissez le CPU sur 0 et mettez à l'échelle l'allocation de RAM à l'aide des commandes suivantes. La valeur de l'unité centrale sera calculée sur la base d'un ratio de 1 unité centrale : 8 Go de RAM, jusqu'à 2 unités centrales. Pour passer
à une échelle supérieure à 2 CPU, réglez les allocations de CPU et de RAM sur votre allocation cible. Dans les deux cas, veillez à inclure le paramètre host_flavor
correspondant.
Vous pouvez ajuster manuellement les ressources disponibles pour votre déploiement IBM Cloud® Databases for PostgreSQL en fonction de votre charge de travail et de la taille de vos données.
Remarque : les allocations d'échelle de Terraform se font par membre.
Note : Les allocations de mise à l'échelle de l'API utilisent les valeurs d'allocation totales.
Répartition des ressources
Les déploiements Databases for PostgreSQL comportent deux membres de données dans un cluster, et des ressources sont allouées aux deux membres de manière équitable. Par exemple, le stockage minimum d'un déploiement PostgreSQL est de 10240 Mo, ce qui équivaut à une taille initiale de 5120 Mo par membre. La RAM minimale pour un déploiement PostgreSQL est de 8192 Mo, ce qui équivaut à une allocation initiale de 4096 Mo par membre.
La facturation est basée sur le total des ressources allouées au service.
Utilisation du disque
Le stockage indique la quantité d'espace disque attribuée à votre service. Chaque membre obtient une part égale de l'espace alloué. Vos données sont répliquées sur tous les membres de la base de données PostgreSQL.
L'allocation de disque affecte également les performances du disque, les disques plus volumineux ayant des performances plus élevées. Les performances de référence des opérations d'E/S par seconde (IOPS) du disque sont fixées à 10 IOPS pour chaque Go. Faites évoluer les disques pour augmenter le nombre d'IOPS que votre déploiement peut prendre en charge.
Vous ne pouvez pas réduire la capacité du stockage. Si la taille de votre ensemble de données a diminué, vous pouvez récupérer de l'espace en effectuant une sauvegarde et une restauration dans un nouveau déploiement.
Mémoire RAM
Si vous constatez des problèmes de performance au niveau de vos requêtes et de l'activité de votre base de données liés à un manque de mémoire, vous pouvez mettre à l'échelle la quantité de mémoire RAM allouée à votre service. Si votre instance de base de données est sur un modèle d'hébergement Isolated Compute, sélectionnez la configuration CPU x RAM qui correspond à vos besoins en ressources. Si votre instance de base de données est sur un modèle d'hébergement Shared Compute ou Dedicated Core, sélectionnez l'allocation de RAM que vous souhaitez pour votre base de données.
Dedicated Core est obsolète et sera supprimé en mai 2025.
L'ajout de mémoire à l'allocation totale ajoute de la mémoire aux membres de manière égale. les déploiements de Databases for PostgreSQL ont leur politique d'allocation de mémoire fixée à 50 % du tas et 50 % de la mémoire système, de sorte que l'augmentation de la quantité de RAM augmente à la fois le tas et la mémoire système. La mémoire vive peut être augmentée ou réduite.
Les paramètres work_mem
, maintenance_work_mem
et effective_cache_size
sont réglés automatiquement en fonction de la quantité totale de mémoire du déploiement. Ils sont
également définis lorsque vous mettez à l'échelle la mémoire sur votre déploiement. Lorsque vous effectuez une mise à l'échelle, les valeurs sont ajustées sans entraîner d'indisponibilité pour le déploiement en cours d'exécution.
La quantité de mémoire allouée au pool de mémoire tampon partagé de la base de données n'est pas ajustée automatiquement lorsque vous mettez à l'échelle votre déploiement. Il est recommandé de la fixer à 25 % de la mémoire
totale du déploiement. Vous pouvez ajuster manuellement le pool de mémoire tampon partagé via le paramètre shared_buffer
dans
votre configuration de PostgreSQL. Cette valeur n'est pas réglée automatiquement car la modification du paramètre shared_buffer
nécessite de redémarrer la base de données.
vCPU
Si vous constatez que les charges de travail de votre base de données ont besoin de plus de ressources CPU, vous pouvez augmenter la quantité de CPU allouée à votre service. Si votre instance de base de données est sur un modèle d'hébergement Isolated Compute, sélectionnez la configuration CPU x RAM qui correspond à vos besoins en ressources. Si votre instance de base de données est sur un modèle d'hébergement Shared Compute ou Dedicated Core, sélectionnez l'allocation CPU que vous souhaitez pour votre base de données.
Les anciennes instances dédiées sont obsolètes et seront supprimées en mai 2025. Pour plus d'informations sur les nouveaux modèles d'hébergement, voir l'aperçu des modèles d'hébergement.
Considérations liées à la mise à l'échelle
- L'augmentation d'échelle peut entraîner le redémarrage de votre déploiement. Si votre déploiement doit être déplacé vers un hôte disposant d'une plus grande capacité, le déploiement est redémarré dans le cadre du déplacement.
- Diminuer la mémoire RAM ou l'UC n'entraîne pas de redémarrages.
- La capacité du disque ne peut pas être réduite.
- L'évolution entre les modèles d'hébergement (calcul partagé, calcul isolé et cœurs dédiés) déplace votre déploiement vers de nouveaux hôtes. Vos bases de données sont redémarrées dans le cadre de ce transfert. Lorsque votre déploiement est déplacé vers un nouvel hôte, cela peut également prendre plus de temps que de simplement ajouter des ressources. Pour plus d'informations, voir Informatique partagée et informatique isolée.
- De même, l'augmentation drastique de l'unité centrale, de la mémoire vive ou du disque peut prendre plus de temps que de petites augmentations de ressources pour tenir compte de l'approvisionnement en ressources matérielles sous-jacentes supplémentaires.
- Les opérations de mise à l'échelle sont journalisées dans IBM Cloud® Activity Tracker Event Routing.
- Si vous constatez des tendances constantes dans l'utilisation des ressources ou si vous souhaitez procéder à une mise à l'échelle lorsque certains seuils de ressources sont atteints, activez autoscaling sur votre déploiement.
- Databases for PostgreSQL est conçu pour équilibrer la charge de travail sur un cluster et peut bénéficier d'une mise à l'échelle horizontale. Si vous êtes préoccupé par les performances, consultez la rubrique Ajouter des membres à PostgreSQL.
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. Sélectionnez Configurer pour 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 de passer à Small et Custom, mais pas aux 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 PostgreSQL, membres sont fixés à 2.
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 supprime tout ou partie de la tarification héritée. Pour plus d'informations sur les droits acquis et la date à laquelle ils prennent fin, voir le calendrier de transition des droits acquis.
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électionner votre modèle d'hébergement. Ici, vous pouvez passer à un autre modèle d'hébergement.
Ci-dessous, vous verrez 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.
Le fait de cliquer sur Appliquer les modifications déclenche 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 2
|
+ Memory
| Allocation 8192mb
| Allocation per member 4096mb
| Minimum 4096mb
| Step Size 256mb
| Adjustable true
| Cpu Enforcement Ratio Ceiling 32768mb
| Cpu Enforcement Ratio 8192mb
|
+ CPU
| Allocation 6
| Allocation per member 3
| Minimum 6
| Step Size 2
| Adjustable true
|
+ HostFlavor
| ID multitenant
| Name
| HostingSize
|
+ Disk
| Allocation 10240mb
| Allocation per member 5120mb
| Minimum 10240mb
| Step Size 1024mb
| Adjustable true
Le déploiement comporte deux membres, avec une quantité totale de 4096 Mo de mémoire RAM et 10240 Mo de disque allouée. L'allocation "par membre" est de 4096 Mo de 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 augmenter la mémoire de "l'exemple de déploiement" à 4096 Mo de RAM pour chaque membre de la mémoire
(pour une mémoire totale de 8192 Mo), vous utilisez la commande :
ibmcloud cdb deployment-groups-set example-deployment member --memory 8192
Déterminer le modèle d'hébergement de votre base de données
Utilisez la commande suivante pour vérifier la valeur de l'attribut host_flavor
. Cette valeur sera nulle si la base de données se trouve sur un modèle d'hébergement obsolète (ni partagé, ni isolé).
ibmcloud cdb groups <INSTANCE_NAME_OR_CRN> --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 de calcul partagé, vous pouvez ajuster les options de mémoire, de CPU et de disque à l'aide de la commande suivante. Ceci peut également être utilisé pour déplacer 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 <INSTANCE_NAME_OR_CRN> <GROUP_ID> [--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 le CPU sont ajustés 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. Pour mettre à l'échelle une Cloud Databases instance Isolated Compute, utilisez une commande, telle que la suivante, qui est utilisée pour mettre à l'échelle une instance de 4 CPU par 16 RAM. Cette commande peut également être utilisée pour déplacer 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 <INSTANCE_NAME_OR_CRN> <GROUP_ID> [--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.4x16.encrypted
Le paramètre hostflavor
Le paramètre hostflavor
définit la taille de votre calcul. Pour provisionner une instance Shared Compute, spécifiez multitenant
. Pour provisionner une instance Isolated Compute, entrez la valeur appropriée pour votre
configuration de CPU et de RAM.
Goût de l'hôte | valeur de la saveur de l'hôte |
---|---|
Ordinateur partagé | multitenant |
4 CPU x 16 RAM | b3c.4x16.encrypted |
8 CPU x 32 RAM | b3c.8x32.encrypted |
8 CPU x 64 RAM | m3c.8x64.encrypted |
16 CPU x 64 RAM | b3c.16x64.encrypted |
32 CPU x 128 RAM | b3c.32x128.encrypted |
30 CPU x 240 RAM | m3c.30x240.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 porter la mémoire d'un déploiement à 4096 Mo de RAM pour chaque membre (il y en a 2, soit une mémoire totale de 8192 Mo), utilisez le point d'accès {group_id} De l'API.
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": 8192
}
}'
Déterminer le modèle d'hébergement de votre base de données
Utilisez la commande suivante pour vérifier la valeur de l'attribut host_flavor
. Cette valeur sera nulle si la base de données se trouve sur un modèle d'hébergement obsolète (ni partagé, ni 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": 2},
"memory":
{"allocation_mb": 8192}
}' \
Pour mettre à l'échelle une instance dans une Cloud Databases instance de calcul isolé ou pour mettre à l'échelle une taille de calcul isolé différente, utilisez le paramètre host_flavor
, cette fois-ci défini sur la taille de calcul
isolé souhaitée. Les tailles d'hébergement disponibles et leurs host_flavor
paramètres de valeur sont énuméré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 d'allocation
de CPU et de RAM séparées. Scale avec le Cloud Databases API Scaling endpoint, avec une commande
comme :
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"}}' \
L'allocation de CPU et de RAM n'est pas autorisée lors du provisionnement ou de la mise à l'échelle via Isolated Compute. Spécifiez mulitenant
pour le paramètre host_flavor
afin d'avoir des sélections de CPU et de RAM
indépendantes.
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 des disques est disponible. Si vous avez provisionné une instance isolée ou basculé 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 de disque. Pour ajouter des ressources à votre instance, mettez manuellement à l'échelle votre déploiement.
Le paramètre host flavor
{ : api
Le paramètre host_flavor
définit la taille de votre calcul. Pour provisionner une instance Shared Compute, spécifiez multitenant
. Pour provisionner une instance Isolated Compute, entrez la valeur appropriée pour votre
configuration de CPU et de RAM.
Goût de l'hôte | valeur de la saveur de l'hôte |
---|---|
Ordinateur partagé | multitenant |
4 CPU x 16 RAM | b3c.4x16.encrypted |
8 CPU x 32 RAM | b3c.8x32.encrypted |
8 CPU x 64 RAM | m3c.8x64.encrypted |
16 CPU x 64 RAM | b3c.16x64.encrypted |
32 CPU x 128 RAM | b3c.32x128.encrypted |
30 CPU x 240 RAM | m3c.30x240.encrypted |
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 actuel de l'infrastructure avec l'état souhaité défini dans vos fichiers Terraform. Toute modification des
attributs resource_group_id
, service plan
, version
, key_protect_instance
, key_protect_key
, backup_encryption_key_crn
recrée votre instance. Pour une liste des références
d'arguments actuels avec la spécification Forces new resource
, voir le 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-epostgresql"
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 PostgreSQL database connection string" {
value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}
Passage à des modèles d'hébergement et mise à l'échelle dans Terraform
Sélectionnez le modèle d'hébergement auquel vous souhaitez que votre base de données soit adaptée. Vous pourrez changer ces informations ultérieurement.
Pour faire évoluer votre instance Databases for PostgreSQL vers l'hébergement informatique partagé, définissez le paramètre "host_flavor"
sur multitenant
. Cela fonctionne si vous voulez passer à l'hébergement
informatique partagé, ou si vous voulez conserver l'hébergement et faire évoluer vos ressources. Pour mettre en œuvre votre changement, 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-postgresql"
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 PostgreSQL database connection string" {
value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}
Faites passer votre instance Databases for PostgreSQL en calcul isolé 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 de calcul isolée différente, ainsi que de passer d'une autre saveur d'hôte à la saveur d'hôte de calcul isolée. Les tailles d'hébergement disponibles et leurs host_flavor value
paramètres sont énuméré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-postgresql"
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 PostgreSQL database connection string" {
value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}
Le paramètre host flavor
Le paramètre host_flavor
définit la taille de votre calcul. Pour provisionner une instance Shared Compute, spécifiez multitenant
. Pour provisionner une instance Isolated Compute, entrez la valeur appropriée pour votre
configuration de CPU et de RAM.
Goût de l'hôte | valeur de la saveur de l'hôte |
---|---|
Ordinateur partagé | multitenant |
4 CPU x 16 RAM | b3c.4x16.encrypted |
8 CPU x 32 RAM | b3c.8x32.encrypted |
8 CPU x 64 RAM | m3c.8x64.encrypted |
16 CPU x 64 RAM | b3c.16x64.encrypted |
32 CPU x 128 RAM | b3c.32x128.encrypted |
30 CPU x 240 RAM | m3c.30x240.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 des disques est disponible. Si vous avez provisionné une instance isolée ou basculé 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 de disque. Pour ajouter des ressources à votre instance, mettez manuellement à l'échelle votre déploiement.