Esaminare le risorse attuali e il modello di hosting

Nella scheda Risorse, si trovano sia il modello di hosting che le caselle di allocazione delle risorse. Questi riquadri riflettono le risorse e il modello di hosting attuali. Selezionare Configura per regolare le impostazioni di ciascuna piastrella.

Ridimensionamento nell'IU

Nella scheda Risorse dell'interfaccia utente, selezionare Configura nel riquadro Allocazione risorse. Si apre un pannello in cui è possibile regolare le risorse.

Se il database è sul modello di hosting Isolated Compute, viene visualizzata la tabella "Host sizes", in cui è possibile selezionare la configurazione di vCPU e RAM per membro per il database.

Se si utilizza il modello di hosting Shared Compute, si vede la configurazione Small, che fornisce 0.5 vCPU e 4 GB di RAM per membro, l'opzione Small Custom o la configurazione Custom. Small Custom indica che il database è stato scalato con la CLI, l'API o Terraform, che fornisce una scalatura delle risorse più fine, insieme a un'opzione per l'allocazione automatica di vCPU proporzionata al valore della RAM. Nell'interfaccia utente è possibile scalare a Small e Custom, ma non è possibile scalare ai valori a grana fine forniti da CLI, API o Terraform. Con Custom, trascinate il cursore o regolate il valore nella casella di immissione per selezionare i valori di vCPU e RAM del vostro database per membro.

Il cursore "Disco (GB/membro)" rappresenta la selezione del disco per membro. Trascinare il cursore o regolare il numero nella casella di immissione per modificare il numero di GB del disco. Si noti che il disco è legato alle IOPS: 1 GB = 10 IOPS.

Membri è il numero di membri del database. Per MongoDB, membri sono impostati a 3.

Esaminate il costo totale stimato nella calcolatrice in basso. Si noti che se si dispone di costi precedenti, noti anche come struttura di prezzi legacy, il ridimensionamento dell'istanza del database rimuove alcuni o tutti i prezzi legacy. Per ulteriori informazioni sul grandfathering e sulla sua scadenza, consultare la timeline di transizione del modello Hosting.

Al termine, fare clic su Applica modifiche per attivare l'operazione di ridimensionamento.

Passare da un modello di hosting all'altro nell'interfaccia utente

Nella scheda Risorse dell'interfaccia utente, selezionare Configura sul riquadro del modello di hosting. Si apre un pannello in cui è possibile regolare la selezione del modello di hosting.

La prima opzione disponibile è Seleziona il modello di hosting. Qui è possibile passare a un modello di hosting diverso.

Di seguito sono riportate le opzioni per regolare anche le risorse del nuovo modello di hosting selezionato. Seguire le istruzioni della sezione precedente, "Ridimensionamento nell'interfaccia utente" per regolare le risorse.

Facendo clic su Applica modifiche si attiva questa operazione di scala.

Esaminare le risorse attuali e il modello di hosting

IBM Cloud Plug-in database cloud CLI supporta la visualizzazione e il ridimensionamento delle risorse nella tua distribuzione. Utilizza il comando cdb deployment-groups per visualizzare informazioni sulla risorsa corrente per il tuo servizio, inclusi i gruppi di risorse che sono regolabili. Per ridimensionare uno qualsiasi dei gruppi di risorse disponibili, utilizza il comando cdb deployment-groups-set.

Ad esempio, con il seguente comando è possibile visualizzare i gruppi di risorse per un'installazione client denominata "example-deployment". Si noti che questo comando rivelerà anche se il database è un'istanza Shared Compute o Isolated Compute attraverso l'attributo hostflavor. Se hostflavor è nullo, si tratta di un modello di hosting vecchio stile.

ibmcloud cdb deployment-groups <INSTANCE_NAME_OR_CRN>

Questo comando produce l'output:

Group   member
Count   3
|
+   Memory
|   Allocation                      6144mb
|   Allocation per member           2048mb
|   Minimum                         6144mb
|   Step Size                       256mb
|   Adjustable                      true
|   Cpu Enforcement Ratio Ceiling   49152mb
|   Cpu Enforcement Ratio           8192mb

|
+   CPU
|   Allocation              0
|   Allocation per member   0
|   Minimum                 6
|   Step Size               2
|   Adjustable              true
|                           
+   HostFlavor    
|   ID            multitenant
|   Name          
|   HostingSize   
|
+   Disk
|   Allocation              30720mb
|   Allocation per member   10240mb
|   Minimum                 30720mb
|   Step Size               2048mb
|   Adjustable              true

La distribuzione ha tre membri, con 6144 MB di RAM e 30720 MB di disco assegnati in totale. L'assegnazione "per membro" è di 2048 MB di RAM e 10240 MB di disco. Il valore minimo è l'allocazione totale più bassa che è possibile impostare. La dimensione della fase è la quantità più piccola di cui è possibile regolare l'assegnazione totale.

Risorse e ridimensionamento nella CLI

Il comando cdb deployment-groups-set consente di impostare l'allocazione totale della RAM o del disco in MB. Ad esempio, per scalare la memoria di "example-deployment" a 4096 MB di RAM per ogni membro della memoria (per una memoria totale di 12288 MB), si usa il comando:

ibmcloud cdb deployment-groups-set <INSTANCE_NAME_OR_CRN> member --memory 12288

Determinare il modello di hosting del database

Utilizzate il seguente comando per verificare il valore dell'attributo hostflavor. Questo valore sarà nullo se il database si trova su un modello di hosting deprecato (non Shared o Isolated Compute).

ibmcloud cdb groups <deployment_id> --json

Passaggio a e tra i modelli di hosting nella CLI

Se il database è un'istanza Shared Compute, è possibile regolare le opzioni di memoria, CPU e disco con il seguente comando. Se il database non è su Shared Compute, questo comando consente di spostare un database da un modello di hosting diverso al modello di hosting Shared Compute.

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

Ad esempio, per scalare verso un'istanza di Shared Compute o per scalare l'istanza di Shared Compute, utilizzare la seguente procedura:

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

Se il database è un'istanza Isolated Compute, la memoria e la CPU vengono regolate insieme selezionando la dimensione Isolated Compute (vedere tutte le dimensioni nella Tabella 1). Il disco viene scalato separatamente. Se il database non è su Isolated Compute, questo comando sposta anche un database da un modello di hosting diverso al modello di hosting Isolated Compute.

Si noti che, poiché la selezione del sapore dell'host include le dimensioni della CPU e della RAM b3c.4x16.encrypted è 4 CPU e 16 RAM), questa richiesta non accetta sia una selezione di dimensioni isolate sia selezioni separate di allocazione di CPU e RAM.

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

Ad esempio, per scalare a un'istanza di Compute isolato o per scalare l'istanza di Compute isolato, utilizzare la seguente procedura:

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

L'autoscaling di CPU e RAM non è supportato su Cloud Databases Isolated Compute. È disponibile l'autoscaling dei dischi. Se si è eseguito il provisioning di un'istanza isolata o si è passati da una distribuzione con autoscaling, monitorare le risorse usando IBM Cloud® Monitoring integrazione, che fornisce le metriche per l'utilizzo della memoria, dello spazio su disco e dell'I/O su disco. Per aggiungere risorse all'istanza, scalare manualmente l'installazione.

Esaminare le risorse attuali e il modello di hosting

L'endpoint Foundation mostrato nel pannello Overview del servizio fornisce l'URL di base per accedere a questa distribuzione tramite l'API. Utilizzalo con l'endpoint /groups se hai bisogno di gestire o automatizzare la scalabilità in modo programmatico.

Per visualizzare le risorse correnti e scalabili di un'installazione client, utilizzare l'endpoint {id}. Si noti che questo comando rivelerà anche se il database è un'istanza Shared Compute o Isolated Compute attraverso l'attributo host_flavor. Se host_flavor è nullo, si tratta di un modello di hosting vecchio stile.

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

Scalare con l'API

Per scalare la memoria di un'installazione client a 4096 MB di RAM per ogni membro di memoria (per una memoria totale di 12288 MB), usare il seguente comando:

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 '{"memory": {"allocation_mb": 12288}}' \

Per ulteriori informazioni, consultare il riferimento all'API.

Determinare il modello di hosting del database

Utilizzate il seguente comando per verificare il valore dell'attributo host_flavor. Questo valore sarà nullo se il database si trova su un modello di hosting deprecato (non Shared o Isolated Compute).

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

Passaggio da e verso i modelli di hosting nell'API

Per scalare qualsiasi Cloud Databases istanza di Shared Compute, usare il seguente comando, impostando host_flavor su multitenant. Se il database non è su Shared Compute, questo comando consente di spostare un database da un modello di hosting diverso al modello di hosting 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}
    }' \

Per scalare qualsiasi istanza in un'istanza di Cloud Databases Computo isolato o per scalare a una diversa dimensione di Computo isolato, usare il parametro host_flavor, questa volta impostato sulla dimensione di Computo isolato desiderata. Le dimensioni disponibili per l'hosting e i relativi parametri host_flavor sono elencati nella Tabella 1. Ad esempio, {"host_flavor": "b3c.4x16.encrypted"}. Si noti che, poiché la selezione del sapore dell'host include le dimensioni della CPU e della RAM (b3c.4x16.encrypted è 4 CPU e 16 RAM), questa richiesta non accetta sia una selezione di dimensioni isolate che selezioni separate di allocazione di CPU e RAM. Scalare con l'endpoint dell'API Cloud Databases Con un comando del tipo:

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'allocazione di CPU e RAM non è consentita durante il provisioning o lo scaling tramite Isolated Compute. Specificare mulitenant per il parametro host_flavor per avere selezioni indipendenti di CPU e RAM.

L'autoscaling di CPU e RAM non è supportato su Cloud Databases Isolated Compute. È disponibile l'autoscaling dei dischi. Se si è eseguita la fornitura di un'istanza isolata o si è passati da un'implementazione con autoscaling, è possibile tenere sotto controllo le risorse utilizzando IBM Cloud® Monitoring integrazione, che fornisce metriche per l'utilizzo della memoria, dello spazio su disco e dell'I/O su disco. Per aggiungere risorse all'istanza, scalare manualmente l'installazione.

Esaminare le risorse attuali e il modello di hosting

Verificate l'allocazione delle risorse al vostro database controllando gli script di terraform per cpu { allocation_count = }, memory {allocation_mb = } e disk { allocation_mb = }. Controllare l'impostazione host_flavor per determinare se il database è un modello di hosting di tipo Shared Compute o Isolated Compute. Se host_flavor non esiste, il database è su un modello di hosting vecchio stile.

Scalare con Terraform

Prima di eseguire uno script Terraform su un'istanza esistente, utilizzare il comando terraform plan per confrontare lo stato attuale dell'infrastruttura con lo stato desiderato definito nei file Terraform. Qualsiasi modifica agli attributi resource_group_id, service plan, version, key_protect_instance, key_protect_key, backup_encryption_key_crn ricrea l'istanza. Per un elenco dei riferimenti agli argomenti correnti con la specifica Forces new resource, vedere il registro Terraform di Ibm_database.

Scalare l'istanza regolando lo script Terraform per la risorsa che interessa. Nell'esempio seguente, vengono specificate le allocazioni cpu, memory e disk. Se è stato selezionato un tipo di host (Isolated Compute o Shared Compute Multitenant), mantenere la selezione del tipo di host nello script.

Per implementare la modifica, eseguire 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-mongodb"
  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 MongoDB database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}

Passaggio e scalabilità dei modelli di hosting in Terraform

Selezionare il modello di hosting su cui si vuole scalare il database. Puoi modificarlo in un secondo momento.

Per scalare l'istanza Databases for MongoDB al tipo di hosting Shared Compute, impostare il parametro "host_flavor" su multitenant. Questo funziona se si vuole scalare verso il modello di hosting Shared Compute o se si vuole mantenere il modello host e scalare le risorse. Per implementare la modifica, eseguire terraform apply.

Vedi il seguente esempio:

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-mongodb"
  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 MongoDB database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}

Scalare l'istanza Databases for MongoDB a calcolo isolato con lo stesso "host_flavor" parametro, impostato sulla dimensione isolata desiderata. Questo comando funziona per scalare l'istanza del database a una dimensione diversa di Isolated Compute, nonché per passare da un altro host flavor all'host flavor di Isolated Compute. Le dimensioni di hosting disponibili e i relativi parametri host_flavor value sono elencati nella Tabella 1. Ad esempio, {"host_flavor": "b3c.4x16.encrypted"}. Si noti che, poiché la selezione del sapore dell'host include le dimensioni della CPU e della RAM (b3c.4x16.encrypted è 4 CPU e 16 RAM), questa richiesta non accetta sia una selezione di dimensioni isolate che selezioni separate di allocazione di CPU e RAM.

Per implementare la modifica, eseguire 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-mongodb"
  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 MongoDB database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}