Gestione della capacità con il bilanciamento del carico

Last reviewed 2018-01-18 UTC

La maggior parte dei bilanciatori del carico utilizza un approccio "round robin" o di hashing basato sul flusso per distribuire il traffico. I bilanciatori del carico che utilizzano questo approccio possono avere difficoltà adattarsi quando la domanda di traffico aumenta al di là della capacità di gestione disponibile. Questo il tutorial mostra come Cloud Load Balancing ottimizza la capacità globale dell'applicazione, con un conseguente miglioramento dell'esperienza e costi inferiori rispetto alla maggior parte delle implementazioni di bilanciamento del carico.

Questo articolo fa parte di una serie di best practice per Cloud Load Balancing prodotti di big data e machine learning. Questo tutorial è accompagnato dalla Ottimizzazioni della capacità dell'applicazione con il bilanciamento del carico globale, un articolo concettuale che spiega i meccanismi sottostanti del carico globale dell'overflow del bilanciamento del bilanciamento del carico in modo più dettagliato. 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 Concetti fondamentali sul bilanciatore del carico delle applicazioni esterno.

Obiettivi

In questo tutorial hai configurato un semplice server web che esegue un uso intensivo della CPU che calcola i set di Mandelbrot. Inizia misurando la capacità della rete utilizzando strumenti di test di carico (siege e httperf). Scala poi la 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, quindi misura il tempo di risposta del server sotto carico e confrontalo con il bilanciamento del carico a livello di singola regione. Esecuzione di questa operazione di test consente di vedere gli effetti positivi del carico tra regioni per la gestione 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).
  • Determinare la capacità di gestione 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 forwarding

Utilizza la 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 configurerai le impostazioni del progetto, la rete VPC e le regole firewall necessarie per completare il tutorial.

avvia un'istanza di Cloud Shell

Apri Cloud Shell dal Console Google Cloud. Se non diversamente indicato, esegui il resto del tutorial dall'interno di Cloud o una conchiglia.

Configura le impostazioni del progetto

Per semplificare l'esecuzione dei comandi gcloud, puoi impostare le proprietà in modo da non è necessario fornire opzioni per queste proprietà con ciascun 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 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 servizio di una singola istanza VM

Per esaminare le caratteristiche prestazionali di un tipo di istanza VM, eseguirai seguenti:

  1. Configura un'istanza VM che gestisce il carico di lavoro di esempio (il 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 un caricamento semplice di test e misurazione del rendimento. 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à ad alta intensità di CPU calcolare e mostrare l'immagine di un set di Mandelbrot su ogni richiesta alla principale (/). Il risultato non viene memorizzato nella cache. Durante il tutorial, imparerai a utilizzare Python dello script 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 richieste da un numero specifico di utenti, facendo richieste di follow-on 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 tu abbia ricevuto 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 del tipo 0,395260. Ciò significa che il server ha impiegato 395 millisecondi (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

    Verrà 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 dettagliatamente nel manuale d'assedio, ma in questo esempio puoi vedere che i tempi di risposta variavano tra 0,37 s e 0,7 sec. In media, le risposte sono state 5,05 al secondo. Questi dati aiutano a stimare la capacità di pubblicazione del sistema.

  5. Esegui questi comandi per convalidare i risultati utilizzando httperf di test di carico:

    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.

    Verrà 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 README httperf . Nota la riga che inizia con Connection time [ms], che mostra che le connessioni hanno richiesto tra 369,6 e 487,8 ms in totale e non hanno generato errori.

  6. Ripeti il test 3 volte, impostando l'opzione rate su 5, 7 e 10 come utilizzo della CPU, utilizzo della rete, richieste per 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 si può dedurre che il sistema ha una capacità 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.

Misurazione degli effetti di sovraccarico con un bilanciatore del carico a regione singola

In questa sezione esamini gli effetti del sovraccarico sui bilanciatori del carico a livello di 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 regione singola

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 il metodo Script di generazione Python di Mandelbrot 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. Creare il controllo di integrità, il servizio di backend, la mappa URL, il proxy di destinazione e regola di forwarding globale necessaria per generare 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 fornita da una delle istanze VM nell'infrastruttura gruppo.

  6. Accedi al computer 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 i 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

Queste prestazioni sono normali per 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 500 ms, ma con 20 RPS la latenza è di 5000 ms. La latenza è aumentata di dieci volte e l'esperienza utente si deteriora rapidamente, portando all'abbandono 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.

Misurazione degli effetti dell'overflow in un'altra regione

Se utilizzi un'applicazione globale con un bilanciatore del carico delle applicazioni esterno e hai backend di cui è stato eseguito il deployment in più regioni, quando il sovraccarico della capacità si verifica in un regione, il traffico passa automaticamente a un'altra regione. Per confermare, procedi nel seguente modo: aggiungendo alla configurazione un secondo gruppo di istanze VM in un'altra regione creato nella sezione precedente.

Configurazione del bilanciatore del carico in un deployment multi-regione

Creazione di server in più regioni

Nei passaggi seguenti, aggiungerai un altro gruppo di backend in un'altra regione e assegnare 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. Lo strumento di test esegue immediatamente un carico completo e non aumentare lentamente il carico come nel caso di un'implementazione reale, ripeti il test un paio di volte affinché il meccanismo di overflow effetto. Esegui 500 richieste 5 volte a 20 RPS. Sostituisci [IP_address] con 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 che il sistema si è stabilizzato, 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 per RPS utilizzando il carico globale bilanciato:

Grafico che mostra il tempo di risposta 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 un in ogni regione è inferiore alla capacità di servizio totale in quella regione, hanno una latenza simile per l'utente finale perché gli utenti vengono sempre reindirizzati la 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. Questo include il caricamento tradizionale bilanciatori del carico, bilanciatori del carico di rete passthrough esterni su Google Cloud bilanciatori del carico delle applicazioni esterni in una singola regione (ad esempio, utilizzando Livello Standard networking). Le latenze media e massima delle richieste aumentano di oltre un fattore di 10, generando esperienze utente scadenti che a loro volta potrebbero portare a un calo significativo di utenti.

  • Bilanciatori del carico delle applicazioni esterni globali con backend in più regioni consenti l'overflow del traffico verso la regione più vicina disponibile per la pubblicazione e la capacità di archiviazione. Ciò porta a un aumento misurabile ma relativamente basso delle latenza per l'utente finale e offre un'esperienza utente molto migliore. Se le tue non è in grado di fare lo scale out in una regione abbastanza rapidamente, l'opzione consigliata è un bilanciatore del carico delle applicazioni esterno globale. Anche durante l'intera regione dei server delle applicazioni utente, il traffico viene rapidamente reindirizzato in regioni diverse ed evita un'interruzione del servizio completo.

Esegui la pulizia

Elimina il progetto

Il modo più semplice per eliminare la fatturazione 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: