Gestione della capacità con il bilanciamento del carico

Last reviewed 2018-01-18 UTC

La maggior parte dei bilanciatori del carico utilizza un approccio di hashing basato su round robin o su flusso per distribuire il traffico. I bilanciatori del carico che utilizzano questo approccio possono avere difficoltà ad adattarsi quando i picchi di domanda del traffico superano la capacità di pubblicazione disponibile. Questo tutorial mostra come Cloud Load Balancing ottimizza la capacità delle applicazioni a livello globale, con una migliore esperienza utente e costi inferiori rispetto alla maggior parte delle implementazioni di bilanciamento del carico.

Questo articolo fa parte di una serie di best practice per i prodotti Cloud Load Balancing. Questo tutorial è accompagnato da Ottimizzazioni della capacità delle applicazioni con il bilanciamento del carico globale, un articolo concettuale che spiega in modo più dettagliato i meccanismi di base dell'overflow del bilanciamento del carico globale. Per approfondire la latenza, consulta Ottimizzazione della latenza delle applicazioni con Cloud Load Balancing.

Questo tutorial presuppone che tu abbia una certa esperienza con Compute Engine. Dovresti anche conoscere le nozioni di base del bilanciatore del carico delle applicazioni esterno.

Obiettivi

In questo tutorial, configurerai un semplice server web che esegue un'applicazione che richiede molta CPU e che calcola gli insiemi di Mandelbrot. Inizia misurando la capacità della rete utilizzando strumenti di test di carico (siege e httperf). Poi esegui la scalabilità della rete su più istanze VM in un'unica regione e misura il tempo di risposta sotto carico. Infine, esegui la scalabilità della rete in più regioni utilizzando il bilanciamento del carico globale, poi misura il tempo di risposta del server sotto carico e confrontalo con il bilanciamento del carico a livello di singola regione. L'esecuzione di questa sequenza di test ti consente di vedere gli effetti positivi della gestione del carico tra regioni di Cloud Load Balancing.

La velocità di comunicazione di rete di una tipica architettura di server a tre livelli è solitamente limitata dalla velocità del server di applicazioni o dalla capacità del database anziché dal carico della CPU sul server web. Dopo aver completato il tutorial, puoi utilizzare gli stessi strumenti di test di carico e le stesse impostazioni di capacità per ottimizzare il comportamento del bilanciamento del carico in un'applicazione reale.

Imparerai a:

  • Scopri come utilizzare gli strumenti di test di carico (siege e httperf).
  • Determina la capacità di pubblicazione di una singola istanza VM.
  • Misura gli effetti del sovraccarico con il bilanciamento del carico a livello di singola regione.
  • Misura gli effetti dell'overflow in un'altra regione con il bilanciamento del carico globale.

Costi

Questo tutorial utilizza i componenti fatturabili di Google Cloud, tra cui:

  • Compute Engine
  • Bilanciamento del carico e regole di inoltro

Utilizza il Calcolatore prezzi per generare una stima dei costi in base all'utilizzo previsto.

Prima di iniziare

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. Enable the Compute Engine API.

    Enable the API

Configurazione dell'ambiente

In questa sezione configuri le impostazioni del progetto, la rete VPC e le regole di firewall di base necessarie per completare il tutorial.

Avvia un'istanza Cloud Shell

Apri Cloud Shell dalla console Google Cloud. Se non diversamente indicato, esegui il resto del tutorial da Cloud Shell.

Configura le impostazioni del progetto

Per semplificare l'esecuzione dei comandi gcloud, puoi impostare le proprietà in modo da non dover fornire opzioni per queste proprietà con ogni comando.

  1. Imposta il progetto predefinito utilizzando l'ID progetto per [PROJECT_ID]:

    gcloud config set project [PROJECT_ID]

  2. Imposta la zona Compute Engine predefinita utilizzando la zona che preferisci per [ZONE] e poi impostala come variabile di ambiente per utilizzarla in un secondo momento:

    gcloud config set compute/zone [ZONE]
export ZONE=[ZONE]

Crea e configura la rete VPC

  1. Crea una rete VPC per i test:

    gcloud compute networks create lb-testing --subnet-mode auto

  2. Definisci una regola firewall per consentire il traffico interno:

    gcloud compute firewall-rules create lb-testing-internal \
    --network lb-testing --allow all --source-ranges 10.128.0.0/11

  3. Definisci una regola firewall per consentire al traffico SSH di comunicare con la rete VPC:

    gcloud compute firewall-rules create lb-testing-ssh \
    --network lb-testing --allow tcp:22 --source-ranges 0.0.0.0/0

Determinazione della capacità di pubblicazione di una singola istanza VM

Per esaminare le caratteristiche di prestazioni di un tipo di istanza VM, procedi come segue:

  1. Configura un'istanza VM che gestisce il carico di lavoro di esempio (l'istanza del server web).

  2. Crea una seconda istanza VM nella stessa zona (l'istanza di test di carico).

Con la seconda istanza VM, misurerai le prestazioni utilizzando semplici strumenti di misurazione delle prestazioni e dei test di carico. Utilizzerai queste misurazioni più avanti nel tutorial per definire l'impostazione corretta della capacità di bilanciamento del carico per il gruppo di istanze.

La prima istanza VM utilizza uno script Python per creare un'attività che richiede molta CPU calcolando e mostrando un'immagine di un insieme di Mandelbrot su ogni richiesta al percorso radice (/). Il risultato non viene memorizzato nella cache. Durante il tutorial, ottieni lo script Python dal repository GitHub utilizzato per questa soluzione.

Configurazione di due server per testare la risposta del server web

Configurazione delle istanze VM

  1. Configura l'istanza VM webserver come istanza VM a 4 core installando e avviando il server Mandelbrot:

    gcloud compute instances create webserver --machine-type n1-highcpu-4 \
    --network=lb-testing --image-family=debian-12 \
    --image-project=debian-cloud --tags=http-server \
    --metadata startup-script='#! /bin/bash
apt-get -y update
apt-get install -y git python-numpy python-matplotlib
    git clone \
https://github.com/GoogleCloudPlatform/lb-app-capacity-tutorial-python.git
    cd lb-app-capacity-tutorial-python
python webserver.py'

  2. Crea una regola firewall per consentire l'accesso esterno all'istanza webserver dalla tua macchina:

    gcloud compute firewall-rules create lb-testing-http \
    --network lb-testing --allow tcp:80 --source-ranges 0.0.0.0/0 \
    --target-tags http-server

  3. Ottieni l'indirizzo IP dell'istanza webserver:

    gcloud compute instances describe webserver \
    --format "value(networkInterfaces[0].accessConfigs[0].natIP)"

  4. In un browser web, vai all'indirizzo IP restituito dal comando precedente. Viene visualizzato un insieme di Mandelbrot calcolato:

    Screenshot del browser che mostra l'insieme di Mandelbrot visualizzato

  5. Crea l'istanza di test di carico:

    gcloud compute instances create loadtest --machine-type n1-standard-1 \
    --network=lb-testing --image-family=debian-12 \
    --image-project=debian-cloud

Test delle istanze VM

Il passaggio successivo consiste nell'eseguire richieste per valutare le caratteristiche di prestazioni dell'istanza VM per i test di carico.

  1. Utilizza il comando ssh per connetterti all'istanza VM per i test di carico:

    gcloud compute ssh loadtest

  2. Nell'istanza di test di carico, installa siege e httperf come strumenti di test di carico:

    sudo apt-get install -y siege httperf

    Lo strumento siege consente di simulare le richieste di un numero specificato di utenti, inviando richieste successive solo dopo che gli utenti hanno ricevuto una risposta. In questo modo, puoi ottenere informazioni sulla capacità e sui tempi di risposta previsti per le applicazioni in un ambiente reale.

    Lo strumento httperf consente di inviare un numero specifico di richieste al secondo indipendentemente dal fatto che vengano ricevute risposte o errori. In questo modo puoi ottenere informazioni su come le applicazioni rispondono a un carico specifico.

  3. Misura il tempo di una semplice richiesta al server web:

    curl -w "%{time_total}\n" -o /dev/#objectives_2 -s webserver

    Riceverai una risposta come 0,395260. Ciò significa che il server ha impiegato 395 millesimi di secondo (ms) per rispondere alla tua richiesta.

  4. Utilizza il seguente comando per eseguire 20 richieste da 4 utenti in parallelo:

    siege -c 4 -r 20 webserver

    Viene visualizzato un output simile al seguente:

    ** SIEGE 4.0.2
** Preparing 4 concurrent users for battle.
The server is now under siege...
Transactions:                    80 hits
Availability:                 100.00 %
Elapsed time:                  14.45 secs
Data transferred:               1.81 MB
Response time:                  0.52 secs
Transaction rate:               5.05 trans/sec
Throughput:                     0.12 MB/sec
Concurrency:                    3.92
Successful transactions:         80
Failed transactions:               0
**Longest transaction:            0.70
Shortest transaction:           0.37
**

    L'output è spiegato in modo completo nel manuale di Siege, ma in questo esempio puoi vedere che i tempi di risposta variavano tra 0,37 s e 0,7 s. In media, sono state risposte a 5,05 richieste al secondo. Questi dati aiutano a stimare la capacità di pubblicazione del sistema.

  5. Esegui i seguenti comandi per convalidare i risultati utilizzando lo strumento di test di carico httperf:

    httperf --server webserver --num-conns 500 --rate 4

    Questo comando esegue 500 richieste alla frequenza di 4 richieste al secondo, ovvero meno delle 5,05 transazioni al secondo completate da siege.

    Viene visualizzato un output simile al seguente:

    httperf --client=0/1 --server=webserver --port=80 --uri=/ --rate=4
--send-buffer=4096 --recv-buffer=16384 --num-conns=500 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to
FD_SETSIZE
Maximum connect burst length: 1

Total: connections 500 requests 500 replies 500 test-duration 125.333 s

Connection rate: 4.0 conn/s (251.4 ms/conn, <=2 concurrent connections)
**Connection time [ms]: min 369.6 avg 384.5 max 487.8 median 377.5 stddev 18.0
Connection time [ms]: connect 0.3**
Connection length [replies/conn]: 1.000

Request rate: 4.0 req/s (251.4 ms/req)
Request size [B]: 62.0

Reply rate [replies/s]: min 3.8 avg 4.0 max 4.0 stddev 0.1 (5 samples)
Reply time [ms]: response 383.8 transfer 0.4
Reply size [B]: header 117.0 content 24051.0 footer 0.0 (total 24168.0)
Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0

CPU time [s]: user 4.94 system 20.19 (user 19.6% system 80.3% total 99.9%)
Net I/O: 94.1 KB/s (0.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

    L'output è spiegato nel file README di httperf. Nota la riga che inizia con Connection time [ms], che mostra che le connessioni hanno richiesto in totale tra 369,6 e 487,8 ms e non hanno generato errori.

  6. Ripeti il test 3 volte impostando l'opzione rate su 5, 7 e 10 richieste al secondo.

    I blocchi seguenti mostrano i comandi httperf e il relativo output (vengono mostrate solo le righe pertinenti con le informazioni sui tempi di connessione).

    Comando per 5 richieste al secondo:

    httperf --server webserver --num-conns 500 --rate 5 2>&1| grep 'Errors\|ion time'

    Risultati per 5 richieste al secondo:

    Connection time [ms]: min 371.2 avg 381.1 max 447.7 median 378.5 stddev 7.2
Connection time [ms]: connect 0.2
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

    Comando per 7 richieste al secondo:

    httperf --server webserver --num-conns 500 --rate 7 2>&1| grep 'Errors\|ion time'

    Risultati per 7 richieste al secondo:

    Connection time [ms]: min 373.4 avg 11075.5 max 60100.6 median 8481.5 stddev
10284.2
Connection time [ms]: connect 654.9
Errors: total 4 client-timo 0 socket-timo 0 connrefused 0 connreset 4
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

    Comando per 10 richieste al secondo:

    httperf --server webserver --num-conns 500 --rate 10 2>&1| grep 'Errors\|ion time'

    Risultati per 10 richieste al secondo:

    Connection time [ms]: min 374.3 avg 18335.6 max 65533.9 median 10052.5 stddev
16654.5
Connection time [ms]: connect 181.3
Errors: total 32 client-timo 0 socket-timo 0 connrefused 0 connreset 32
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

  7. Esci dall'istanza webserver:

    exit

Da queste misurazioni puoi dedurre che il sistema ha una capacità di circa 5 richieste al secondo (RPS). A 5 richieste al secondo, l'istanza VM reagisce con una latenza paragonabile a 4 connessioni. Con 7 e 10 connessioni al secondo, il tempo di risposta medio aumenta drasticamente fino a oltre 10 secondi con più errori di connessione. In altre parole, qualsiasi valore superiore a 5 richieste al secondo causa rallentamenti significativi.

In un sistema più complesso, la capacità del server viene determinata in modo simile, ma dipende molto dalla capacità di tutti i suoi componenti. Puoi utilizzare gli strumenti siege e httperf insieme al monitoraggio del carico della CPU e dell'I/O di tutti i componenti (ad esempio il server frontend, il server delle applicazioni e il server di database) per identificare i colli di bottiglia. Ciò può aiutarti a attivare la scalabilità ottimale per ogni componente.

Misurare gli effetti del sovraccarico con un bilanciatore del carico a una sola regione

In questa sezione esamini gli effetti del sovraccarico sui bilanciatori del carico a singola regione, come i bilanciatori del carico tipici utilizzati on-premise o il bilanciatore del carico di rete passthrough esterno di Google Cloud. Puoi osservare questo effetto anche con un bilanciatore del carico HTTP(S) quando viene utilizzato per un deployment regionale (anziché globale).

Configurazione del bilanciatore del carico in un deployment regionale a zona singola

Creazione del bilanciatore del carico HTTP(S) a singola regione

I passaggi seguenti descrivono come creare un bilanciatore del carico HTTP(S) per una singola regione con una dimensione fissa di 3 istanze VM.

  1. Crea un modello di istanza per le istanze VM del server web utilizzando lo script di generazione di Mandelbrot in Python che hai utilizzato in precedenza. Esegui i seguenti comandi in Cloud Shell:

    gcloud compute instance-templates create webservers \
    --machine-type n1-highcpu-4 \
    --image-family=debian-12 --image-project=debian-cloud \
    --tags=http-server \
    --network=lb-testing \
    --metadata startup-script='#! /bin/bash
apt-get -y update
apt-get install -y git python-numpy python-matplotlib
git clone \
    https://github.com/GoogleCloudPlatform/lb-app-capacity-tutorial-python.git
cd lb-app-capacity-tutorial-python
python webserver.py'

  2. Crea un gruppo di istanze gestite con 3 istanze basate sul modello del passaggio precedente:

    gcloud compute instance-groups managed create webserver-region1 \
    --size=3 --template=webservers

  3. Crea il controllo di integrità, il servizio di backend, la mappa URL, il proxy di destinazione e regola di forwarding globale necessari per generare il bilanciamento del carico HTTP:

    gcloud compute health-checks create http basic-check \
    --request-path="/health-check" --check-interval=60s

gcloud compute backend-services create web-service \
    --health-checks basic-check --global
gcloud compute backend-services add-backend web-service \
    --global --instance-group=webserver-region1 \
    --instance-group-zone $ZONE

gcloud compute url-maps create web-map --default-service web-service

gcloud compute target-http-proxies create web-proxy --url-map web-map

gcloud compute forwarding-rules create web-rule --global \
    --target-http-proxy web-proxy --ports 80

  4. Ottieni l'indirizzo IP della regola di forwarding:

    gcloud compute forwarding-rules describe --global web-rule --format "value(IPAddress)"

    L'output è l'indirizzo IP pubblico del bilanciatore del carico che hai creato.

  5. In un browser, vai all'indirizzo IP restituito dal comando precedente. Dopo qualche minuto, viene visualizzata la stessa immagine di Mandelbrot che hai visto prima. Tuttavia, questa volta l'immagine viene pubblicata da una delle istanze VM nel gruppo appena creato.

  6. Accedi alla macchina loadtest:

    gcloud compute ssh loadtest

  7. Nella riga di comando della macchina loadtest, testa la risposta del server con diversi numeri di richieste al secondo (RPS). Assicurati di utilizzare valori RPS almeno nell'intervallo da 5 a 20.

    Ad esempio, il seguente comando genera 10 RPS. Sostituisci [IP_address] con l'indirizzo IP del bilanciatore del carico di un passaggio precedente di questa procedura.

    httperf --server [IP_address] --num-conns 500 --rate 10 2>&1| grep 'Errors\|ion time'

    La latenza di risposta aumenta notevolmente con l'aumento del numero di RPS oltre 12 o 13 RPS. Ecco una visualizzazione dei risultati tipici:

    Grafico che mostra l&#39;aumento brusco del tempo di risposta con l&#39;aumento delle richieste al minuto

  8. Uscire dall'istanza VM loadtest:

    exit

Questo rendimento è tipico di un sistema con bilanciamento del carico a livello di regione. Man mano che il carico supera la capacità di pubblicazione, la latenza media e massima delle richieste aumenta notevolmente. Con 10 RPS, la latenza media delle richieste è vicina a 500 ms, ma con 20 RPS la latenza è di 5000 ms. La latenza è aumentata di dieci volte e l'esperienza utente peggiora rapidamente, causando abbandoni degli utenti o timeout dell'applicazione o entrambi.

Nella sezione successiva, aggiungerai una seconda regione alla topologia di bilanciamento del carico e confronterai l'impatto del failover tra regioni sulla latenza dell'utente finale.

Misurare gli effetti dell'overflow in un'altra regione

Se utilizzi un'applicazione globale con un bilanciatore del carico delle applicazioni esterno e hai i backend di cui è stato eseguito il deployment in più regioni, quando si verifica un sovraccarico della capacità in una singola regione, il traffico viene indirizzato automaticamente a un'altra regione. Puoi convalidare questa operazione aggiungendo un secondo gruppo di istanze VM in un'altra regione alla configurazione creata nella sezione precedente.

Configurazione del bilanciatore del carico in un deployment multi-regione

Creazione di server in più regioni

Nei passaggi che seguono, aggiungerai un altro gruppo di backend in un'altra regione e assegnerai una capacità di 10 RPS per regione. Puoi quindi vedere come reagisce il bilanciamento del carico quando viene superato questo limite.

  1. In Cloud Shell, scegli una zona in una regione diversa da quella predefinita e impostala come variabile di ambiente:

    export ZONE2=[zone]

  2. Crea un nuovo gruppo di istanze nella seconda regione con 3 istanze VM:

    gcloud compute instance-groups managed create webserver-region2 \
    --size=3 --template=webservers --zone $ZONE2

  3. Aggiungi il gruppo di istanze al servizio di backend esistente con una capacità massima di 10 RPS:

    gcloud compute backend-services add-backend web-service \
    --global --instance-group=webserver-region2 \
    --instance-group-zone $ZONE2 --max-rate 10

  4. Modifica max-rate in 10 RPS per il servizio di backend esistente:

    gcloud compute backend-services update-backend web-service \
    --global --instance-group=webserver-region1 \
    --instance-group-zone $ZONE --max-rate 10

  5. Dopo l'avvio di tutte le istanze, accedi all'istanza VM loadtest:

    gcloud compute ssh loadtest

  6. Esegui 500 richieste a 10 RPS. Sostituisci [IP_address] con l'indirizzo IP del bilanciatore del carico:

    httperf --server [IP_address] --num-conns 500 --rate 10 2>&1| grep 'ion time'

    Vedrai risultati come i seguenti:

    Connection time [ms]: min 405.9 avg 584.7 max 1390.4 median 531.5 stddev
181.3
Connection time [ms]: connect 1.1

    I risultati sono simili a quelli prodotti dal bilanciatore del carico a livello di regione.

  7. Poiché lo strumento di test esegue immediatamente un carico completo e non aumenta lentamente il carico come un'implementazione reale, devi ripetere il test un paio di volte affinché il meccanismo di overflow abbia effetto. Esegui 500 richieste 5 volte a 20 RPS. Sostituisci [IP_address] con l'indirizzo IP del bilanciatore del carico.

    for a in \`seq 1 5\`; do httperf --server [IP_address] \
    --num-conns 500 --rate 20 2>&1| grep 'ion time' ; done

    Vedrai risultati come i seguenti:

    Connection time [ms]: min 426.7 avg 6396.8 max 13615.1 median 7351.5 stddev
3226.8
Connection time [ms]: connect 0.9
Connection time [ms]: min 417.2 avg 3782.9 max 7979.5 median 3623.5 stddev
2479.8
Connection time [ms]: connect 0.9
Connection time [ms]: min 411.6 avg 860.0 max 3971.2 median 705.5 stddev 492.9
Connection time [ms]: connect 0.7
Connection time [ms]: min 407.3 avg 700.8 max 1927.8 median 667.5 stddev 232.1
Connection time [ms]: connect 0.7
Connection time [ms]: min 410.8 avg 701.8 max 1612.3 median 669.5 stddev 209.0
Connection time [ms]: connect 0.8

Una volta stabilizzato il sistema, il tempo di risposta medio è di 400 ms a 10 RPS e aumenta solo a 700 ms a 20 RPS. Si tratta di un enorme miglioramento rispetto al ritardo di 5000 msofferto da un bilanciatore del carico regionale e si traduce in un'esperienza utente molto migliore.

Il seguente grafico mostra il tempo di risposta misurato in base alle RPS utilizzando il bilanciamento del carico globale:

Grafico che mostra che il tempo di risposta rimane invariato con l&#39;aumento delle richieste al minuto

Confronto dei risultati del bilanciamento del carico a livello di regione e globale

Dopo aver stabilito la capacità di un singolo nodo, puoi confrontare la latenza osservata dagli utenti finali in un deployment basato su regione con la latenza in un'architettura di bilanciamento del carico globale. Sebbene il numero di richieste in una singola regione sia inferiore alla capacità di pubblicazione totale in quella regione, entrambi i sistemi hanno una latenza dell'utente finale simile, perché gli utenti vengono sempre reindirizzati alla regione più vicina.

Quando il carico di una regione supera la capacità di pubblicazione per quella regione, la latenza dell'utente finale è molto diversa tra le soluzioni:

  • Le soluzioni di bilanciamento del carico a livello di regione diventano sovraccaricate quando il traffico supera la capacità, perché non può fluire altrove che verso le istanze VM di backend sovraccaricate. Sono inclusi i bilanciatori del carico on-premise tradizionali, i bilanciatori del carico di rete passthrough esterni su Google Cloud e i bilanciatori del carico delle applicazioni esterni in una configurazione di una singola regione (ad esempio, utilizzando la rete livello Standard). Le latenze medie e massime delle richieste aumentano di più di un ordine di grandezza, con conseguente esperienza utente scadente che potrebbe a sua volta portare a un tasso di abbandono significativo degli utenti.

  • I bilanciatori del carico delle applicazioni esterni globali con backend in più regioni consentono di far confluire il traffico nella regione più vicina con capacità di servizio disponibile. Ciò comporta un aumento misurabile, ma relativamente basso, della latenza dell'utente finale e offre un'esperienza utente molto migliore. Se la tua applicazione non è in grado di eseguire lo scaling out in una regione abbastanza rapidamente, il bilanciatore del carico delle applicazioni esterno globale è l'opzione consigliata. Anche in caso di guasto di un'intera regione dei server delle applicazioni utente, il traffico viene reindirizzato rapidamente ad altre regioni e aiuta a evitare un'interruzione completa del servizio.

Esegui la pulizia

Elimina il progetto

Il modo più semplice per eliminare la fatturazione è eliminare il progetto che hai creato per il tutorial.

Per eliminare il progetto:

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

Le seguenti pagine forniscono ulteriori informazioni e informazioni di base sulle opzioni di bilanciamento del carico di Google: