Esaminare le risorse attuali e il modello di hosting

Nella scheda Risorse si trovano i riquadri Modello di hosting e Allocazione delle risorse. Questi riquadri riflettono le risorse e il modello di hosting attuali. Selezionando Configura è possibile 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 Elasticsearch, i membri sono impostati a 3.

Esaminate il costo totale stimato nella calcolatrice in basso. Si noti che se si dispone di costi pregressi, noti anche come struttura di prezzi legacy, il ridimensionamento dell'istanza del database eliminerà alcuni o tutti i prezzi legacy. Per ulteriori informazioni sul grandfathering e sulla sua scadenza, consultare la timeline di transizione dei modelli di 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.

Fare clic su Applica modifiche per attivare 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 example-deployment

Questo produce l'output:

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

L'implementazione ha tre membri, con 3072 MB di RAM e 15360 MB di disco assegnati in totale. L'assegnazione "per membro" è di 1024 MB di RAM e 5120 MB di disco. Il valore minimo è il più basso che può essere impostato per l'assegnazione totale. La dimensione della fase è la quantità più piccola in base alla quale è 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 example-deployment member --memory 12288

Determinare il modello di hosting del database nella CLI

Utilizzare il seguente comando per esaminare il valore dell'attributo hostflavor. Questo valore sarà null se il database si trova su un modello di host obsoleto (non Shared o Isolate Compute).

ibmcloud cdb groups <deployment_id> --json

Passaggio a e tra i modelli di hosting nella CLI

Se il tuo database è un'istanza Shared Compute, puoi 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 tuo database è un'istanza Isolate Compute, la memoria e la CPU vengono regolate insieme selezionando la dimensione Isolate Compute (vedi tutte le dimensioni nella Tabella 1). Il disco viene ridimensionato 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

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. 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 -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups'

Ridimensionamento con l'API

Per scalare la memoria di una distribuzione a 4096 MB di RAM per ogni membro (ce ne sono 3, quindi una memoria totale di 12288 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": 12288
      }
    }'

Determinare il modello di hosting del database nell'API

Utilizzare il seguente comando per esaminare il valore dell'attributo host_flavor. Questo valore sarà null se il database si trova su un modello di host obsoleto (non Shared o Isolate 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 ridimensionare qualsiasi istanza in un'istanza Cloud Databases Isolate Compute o per scalare a una dimensione Isolate Compute differente, utilizza il parametro host_flavor, questa volta impostato sulla dimensione Isolate Compute desiderata. Le dimensioni host disponibili e i relativi parametri di valore host_flavor vengono 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. Ridimensiona con l'endpoint di scalabilità API Cloud Databases, 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"}}' \

Il ridimensionamento automatico della CPU e della RAM non è supportato su Cloud Databases Compute isolato. Il ridimensionamento automatico del disco è disponibile. Se hai eseguito il provisioning di un'istanza isolata o hai eseguito il passaggio da una distribuzione con il ridimensionamento automatico, tieni d'occhio le tue risorse utilizzando l'integrazione IBM Cloud® Monitoring, che fornisce le metriche per l'utilizzo di memoria, spazio su disco e I/O del disco. Per aggiungere risorse alla tua istanza, ridimensiona manualmente la tua distribuzione.

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.

Ridimensionamento con Terraform

Prima di eseguire uno script Terraform su un'istanza esistente, utilizza il comando terraform plan per confrontare lo stato dell'infrastruttura corrente con quello desiderato definito nei tuoi file Terraform. Qualsiasi modifica agli attributi resource_group_id, service plan, version, key_protect_instance, key_protect_key, backup_encryption_key_crn ricrea la tua istanza. Per un elenco dei riferimenti dell'argomento corrente con la specifica Forces new resource, vedi ibm_database Terraform Registry.

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-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}"
}

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 Elasticsearch 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-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}"
}

Scalare l'istanza Databases for Elasticsearch a Computazione isolata 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 host disponibili e i relativi parametri host_flavor value sono riportati 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-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}"
}