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.

Scala nell'interfaccia utente

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 PostgreSQL, membri sono impostati su 2.

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 su quando termina, consultare la linea temporale di transizione del Gradfathering.

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, vengono visualizzate 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 Il plug-in CLI per i database cloud supporta la visualizzazione e il ridimensionamento delle risorse sulla distribuzione. Usate il comando cdb deployment-groups per vedere le informazioni correnti sulle risorse per il vostro servizio, compresi i gruppi di risorse regolabili. Per scalare uno qualsiasi dei gruppi di risorse disponibili, usare 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 example-deployment

Questo produce l'output:

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

L'installazione ha due membri, con 4096 MB di RAM e 10240 MB di disco allocati in totale. L'allocazione "per membro" è di 4096 MB di RAM e 5120 MB di disco. Il valore minimo è il valore più basso che può essere impostato per l'allocazione totale. La dimensione del passo è la quantità minima di cui è possibile regolare l'allocazione 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 8192 MB), si usa il comando:

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

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).

ibmcloud cdb groups <INSTANCE_NAME_OR_CRN> --json

Passaggio da e verso i modelli di hosting nella CLI

Se il database è un'istanza Computer condiviso, è possibile regolare le opzioni di memoria, CPU e disco con il seguente comando. Questo può essere utilizzato anche per spostare un database da un modello di hosting diverso al modello di hosting Shared Compute.

ibmcloud cdb deployment-groups-set <INSTANCE_NAME_OR_CRN> <GROUP_ID> [--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. Per scalare un'istanza di Cloud Databases Isolated Compute, utilizzare un comando, come il seguente, usato per scalare a un'istanza di 4 CPU per 16 RAM. Questo comando può essere usato anche per spostare 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 <INSTANCE_NAME_OR_CRN> <GROUP_ID> [--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.4x16.encrypted

Esaminare le risorse attuali e il modello di hosting

L' endpoint di Foundation, visualizzato nel pannello Panoramica del servizio, fornisce l' URL di base per accedere a questa installazione client attraverso l'API. Usarlo con l'endpoint /groups se è necessario gestire o automatizzare il ridimensionamento 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 -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups'

Scalare con l'API

Per scalare la memoria di un'installazione client a 4096 MB di RAM per ogni membro (ce ne sono 2, quindi una memoria totale di 8192 MB), usare l'endpoint API /deployments/{id}/groups/{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": 8192
      }
    }'

Determinare il modello di hosting del database

Utilizzare 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": 2},
      "memory":
        {"allocation_mb": 8192}
    }' \

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 di hosting disponibili 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 il Cloud Databases API Scaling endpoint, con un comando come:

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 avete effettuato il provisioning di un'istanza isolata o siete passati da un'implementazione con autoscaling, tenete d'occhio le vostre risorse usando l'integrazione di IBM Cloud® Monitoring, che fornisce metriche per la memoria, lo spazio su disco e l'utilizzo 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, usare 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-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}"
}

In alternativa, è possibile utilizzare moduli Terraform IBM(TIM) precostituiti, open-source e pronti per l'impresa, che supportano la funzione di autoscaling Databases for PostgreSQL che supportano la funzione di autoscaling.

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 PostgreSQL al tipo di hosting Shared compute, impostare il parametro "host_flavor" su multitenant. Questo funziona se si vuole scalare verso l'hosting di calcolo condiviso o se si vuole mantenere l'hosting 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-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}"
}

Scalare l'istanza Databases for PostgreSQL a calcolo isolato con lo stesso parametro "host_flavor", 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-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}"
}