GSP045

Panoramica

In questo laboratorio pratico potrai leggere alcuni scenari del mondo reale, ricreare gli ambienti e lavorare per migliorare le prestazioni di alcune reti problematiche.

Sarà divertente provare a confrontare le diverse istanze tra loro, proprio come nel caso d'uso per la risoluzione dei problemi, in modo da poter provare i risultati e familiarizzare con i passaggi utilizzati per migliorare le prestazioni dei propri sistemi.

Questo lab è stato adattato dai blog post di Colt McAnlis: Core Count and the Egress problem e Internal IP vs External IP. Colt pubblica blog sulle prestazioni della rete Google Cloud su Medium.

Obiettivi

• Come testare la connettività e le prestazioni della rete utilizzando strumenti open source
• Come ispezionare il traffico di rete utilizzando strumenti open source
• In che modo le dimensioni della macchina possono influire sulle prestazioni della rete

Prerequisiti

• Conoscenza di base dei servizi Google Cloud (meglio se ottenuta avendo seguito in precedenza i lab in Google Cloud Essentials)
• Conoscenza di base di TCP/IP e networking di Google Cloud (meglio se ottenuta avendo seguito i lab precedenti della Quest Networking in the Google Cloud).
• Conoscenza di base della riga di comando Unix/Linux

Configurazione e requisiti

Prima di fare clic sul pulsante Avvia lab

Leggi le seguenti istruzioni. I lab sono a tempo e non possono essere messi in pausa. Il timer si avvia quando fai clic su Avvia lab e ti mostra per quanto tempo avrai a disposizione le risorse Google Cloud.

Con questo lab pratico avrai la possibilità di completare le attività in prima persona, in un ambiente cloud reale e non di simulazione o demo. Riceverai delle nuove credenziali temporanee che potrai utilizzare per accedere a Google Cloud per la durata del lab.

Per completare il lab, avrai bisogno di:

• Accesso a un browser internet standard (Chrome è il browser consigliato).

Nota: utilizza una finestra del browser in incognito o privata per eseguire questo lab. Ciò evita eventuali conflitti tra il tuo account personale e l'account Studente, che potrebbero causare addebiti aggiuntivi sul tuo account personale.

• È ora di completare il lab: ricorda che, una volta iniziato, non puoi metterlo in pausa.

Nota: se hai già un account o un progetto Google Cloud personale, non utilizzarlo per questo lab per evitare addebiti aggiuntivi al tuo account.

Come avviare il lab e accedere alla console Google Cloud

1. Fai clic sul pulsante Avvia lab. Se devi effettuare il pagamento per il lab, si apre una finestra popup per permetterti di selezionare il metodo di pagamento. A sinistra, trovi il riquadro Dettagli lab con le seguenti informazioni:

   • Pulsante Apri console Google
   • Tempo rimanente
   • Credenziali temporanee da utilizzare per il lab
   • Altre informazioni per seguire questo lab, se necessario

2. Fai clic su Apri console Google. Il lab avvia le risorse e apre un'altra scheda con la pagina di accesso.

   Suggerimento: disponi le schede in finestre separate posizionate fianco a fianco.

   Note: se visualizzi la finestra di dialogo Scegli un account, fai clic su Utilizza un altro account.

3. Se necessario, copia il Nome utente dal riquadro Dettagli lab e incollalo nella finestra di dialogo di accesso. Fai clic su Avanti.

4. Copia la Password dal riquadro Dettagli lab e incollala nella finestra di dialogo di benvenuto. Fai clic su Avanti.

   Importante: devi utilizzare le credenziali presenti nel riquadro di sinistra. Non utilizzare le tue credenziali Google Cloud Skills Boost. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi.

5. Fai clic nelle pagine successive:

   • Accetta i termini e le condizioni.
   • Non inserire opzioni di recupero o l'autenticazione a due fattori, perché si tratta di un account temporaneo.
   • Non registrarti per le prove gratuite.

Dopo qualche istante, la console Google Cloud si apre in questa scheda.

Nota: puoi visualizzare il menu con un elenco di prodotti e servizi Google Cloud facendo clic sul menu di navigazione in alto a sinistra.

L'obiettivo di questo lab è mostrare le relazioni tra le dimensioni del core e la velocità effettiva, pertanto il lab include sei istanze già integrate, create quando hai avviato il lab.

• Nella console Cloud, vai a Menu di navigazione > Compute Engine > Istanze VM per visualizzare le tue istanze:

Nota: la zona e la regione dell'istanza potrebbero differire da quelle mostrate nello screenshot.

Test di connessione

Esegui un rapido test di connessione per assicurarti che tutto funzioni bene.

1. Accedi tramite SSH a instance-1 facendo clic sul pulsante SSH accanto al relativo nome nella console.

2. Nella nuova finestra della shell, esegui il ping di un'altra delle tue istanze ed esegui il comando seguente, sostituendo <external ip address of instance-2> con l'indirizzo IP esterno di instance-2:

ping -c 5 <external ip address of instance-2>

Output di esempio:

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.158.169 PING 35.194.158.169 (35.194.158.169) 56(84) bytes of data. 64 bytes from 35.194.158.169: icmp_seq=1 ttl=76 time=1.89 ms 64 bytes from 35.194.158.169: icmp_seq=2 ttl=76 time=0.409 ms 64 bytes from 35.194.158.169: icmp_seq=3 ttl=76 time=0.542 ms 64 bytes from 35.194.158.169: icmp_seq=4 ttl=76 time=0.557 ms 64 bytes from 35.194.158.169: icmp_seq=5 ttl=76 time=0.559 ms --- 35.194.158.169 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.409/0.792/1.894/0.554 ms

3. Esegui il ping di un'altra istanza. Sostituisci <external ip address of instance-3> con l'indirizzo IP esterno di instance-3 ed eseguine il ping:

ping -c 5 <external ip address of instance-3>

Output di esempio:

student-00-aafd1bd9c185@instance-1:~$ ping -c 5 35.194.187.75 PING 35.194.187.75 (35.194.187.75) 56(84) bytes of data. 64 bytes from 35.194.187.75: icmp_seq=1 ttl=64 time=1.59 ms 64 bytes from 35.194.187.75: icmp_seq=2 ttl=64 time=0.336 ms 64 bytes from 35.194.187.75: icmp_seq=3 ttl=64 time=0.338 ms 64 bytes from 35.194.187.75: icmp_seq=4 ttl=64 time=0.302 ms 64 bytes from 35.194.187.75: icmp_seq=5 ttl=64 time=0.270 ms --- 35.194.187.75 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.270/0.568/1.596/0.514 ms

Sembra tutto a posto, continua!

Esamina le regole firewall

Per questo lab sono state create anche delle regole firewall.

• Per vedere quali sono, vai a Menu di navigazione > Networking > Reti VPC > Firewall e fai clic sul firewall iperftesting.

La regola firewall iperftesting utilizza la seguente configurazione:

Campo	Valore	Commenti
Nome	iperftesting	Nome nuova regola
Destinazioni	Tutte le istanze nella rete
Intervalli IP di origine	0.0.0.0/0	Apriremo il firewall per qualsiasi indirizzo IP da internet.
Protocolli e porte	tcp:5001; udp:5001
Direzione del traffico	In entrata
Azione in caso di corrispondenza	Consenti

Ora è tutto pronto per iniziare a utilizzare il lab.

Caso d'uso 1: Numero dei core di Compute Engine e networking

In questo primo scenario vedrai come la dimensione delle macchine utilizzate influisce sulla velocità effettiva che puoi misurare.

Dobermanifesto è una rete di microblogging video esclusivamente per animali domestici. I video basati sugli animali possono essere caricati in tutto il mondo e inviati ovunque per essere visualizzati e sperimentati.

Durante il trasferimento dei dati da/verso i backend di Compute Engine, la larghezza di banda osservata non era così elevata come sperato:

Attività 1: riproduzione del comportamento

Per cercare di riprodurre questo comportamento, sono state create due istanze nella stessa zona e iperf è stato eseguito tra di loro 100 volte.

Questa prestazione è ancora peggiore! Evidentemente c'è qualcosa che non andava nel test. Abbiamo bisogno di più informazioni e di una serie più approfondita di passaggi di riproduzione da parte dell'azienda.

Ora sarai tu a impostare lo scenario.

L'ambiente di Dobermanifesto

1. Torna all'elenco delle istanze VM nella console di Compute Engine.

2. Accedi tramite SSH a instance-1 (1 vCPU 3,75 GB) ed esegui questo comando, configurando un "ricevitore" iperf:

iperf -s

3. Poi accedi tramite SSH a instance-2 (1 vCPU 3,75 GB) e genera del traffico iperf che punti a instance-1:

iperf -c <external ip address of instance-1>

Output di esempio:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.225.180.44 ------------------------------------------------------------ Client connecting to 35.225.180.44, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.20.0.4 port 56330 connected with 35.225.180.44 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0000-10.0010 sec 4.66 GBytes 4.00 Gbits/sec

4. Torna a instance-1 e inserisci Ctrl + C per chiudere il ricevitore.

Ambiente di test

1. Torna alla console di Compute Engine e apri un'altra finestra SSH in instance-6 (1 vCPU e2-micro 0,6 GB).

2. Esegui il comando seguente, configurandolo come "ricevitore":

iperf -s

Output di esempio:

student-00-aafd1bd9c185@instance-6:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

3. Nella finestra SSH di instance-2, testa la connessione a instance-6:

iperf -c <internal ip address of instance-6>

Output di esempio:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.7 ------------------------------------------------------------ Client connecting to 10.40.0.7, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.5 port 54029 connected with 10.40.0.7 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.29 GBytes 1.96 Gbits/sec

4. Torna a instance-6 e inserisci Ctrl + C per chiudere il ricevitore.

Che cosa è successo? Sembra che la larghezza di banda sia aumentata. Potrebbe essere successo anche nel tuo caso. Oppure potrebbe essere diminuita.

Nella sezione successiva vedrai come la larghezza di banda è limitata dal numero totale di core e che con un numero di core compreso in questo intervallo ridotto (numero di core pari a 1), la larghezza di banda non supererà mai i 2 Gbit/sec circa. Di conseguenza, la velocità della rete è bassa e la larghezza di banda è limitata, in modo simile a quanto accadeva a Dobermanifesto. Quando esegui il test con macchine da 4 CPU in un minuto, i risultati saranno migliori.

Il numero di core è correlato ai Gb/s

Perché i risultati non erano molto diversi? Nella documentazione per Compute Engine si afferma:

Il traffico in uscita o in partenza da una macchina virtuale è soggetto ai limiti massimi di velocità effettiva di rete in uscita. Questi limiti dipendono dal numero di vCPU di cui dispone un'istanza di macchina virtuale. Ciascun core è soggetto a un limite di 2 Gbit/secondo (Gbps) per offrire prestazioni di massimo livello. Ogni core aggiuntivo aumenta il limite di rete, fino a un massimo teorico di 16 Gbps per ogni macchina virtuale

Ciò significa che maggiore è il numero di CPU virtuali nella rete, maggiore sarà la velocità effettiva di rete che otterrai.

Per capire come si presenta in pratica, sono stati impostati gruppi di dimensioni di core diversi nella stessa zona e iperf è stato eseguito tra di loro 1000 volte.

Se aumenta il numero di core, aumenta anche la velocità effettiva media e massima. Anche con questo semplice test, puoi vedere il limite fisso di 16 Gbps sulle macchine con prestazioni più elevate.

Nota: se esegui iperf con più thread (~ 8 circa) puoi superare i 10 Gbps e arrivare fino a circa 16 Gbps utilizzando un tipo di macchina e2-standard-16 o superiore. In questo ambiente del lab non disponiamo di una macchina di tali dimensioni. Eseguiamo ora un test con più thread. Sono inoltre disponibili VM a costo più elevato nelle serie N2, N2D, C2 o C2D che consentono di selezionare una configurazione di livello 1 con larghezza di banda elevata e raggiungere 50-100 Gbps.

Attività 2: come migliorare i risultati

La rete di Dobermanifesto utilizza macchine da 1 vCPU. L'aumento delle dimensioni del core probabilmente aiuterà Dobermanifesto a ottenere risultati migliori. È ora di testare questa teoria.

1. Accedi tramite SSH a instance-3 (4 vCPU 15 GB di memoria) ed esegui questo comando:

iperf -s

Output di esempio:

student-00-aafd1bd9c185@instance-3:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. Accedi tramite SSH a instance-4 (4 vCPU 15 GB di memoria):

iperf -c <internal ip address of instance-3>

Output di esempio:

student-00-aafd1bd9c185@instance-4:~$ iperf -c 10.40.0.2 ------------------------------------------------------------ Client connecting to 10.40.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.4 port 54081 connected with 10.40.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 8.93 GBytes 7.67 Gbits/sec

3. Ora riprova con 4 thread:

iperf -c <internal ip address of instance-3> -P4

4. E con 8 thread:

iperf -c <internal ip address of instance-3> -P8

5. Torna a instance-3 e inserisci Ctrl + C per chiudere il ricevitore.

In questi esperimenti, sia il server che il client erano 4 vCPU e la velocità era notevolmente aumentata. La velocità di trasferimento è stata aumentata di 6,64 GByte e la larghezza di banda di 5,71 Gbit/sec. Con più thread, le prestazioni sono riuscite a raggiungere il limite massimo per quel numero di core.

6. Continua a testare con instance-5, che è una macchina da 4 vCPU con prestazioni più elevate, tipo di istanza "highcpu-4".

Questo tipo di istanza ha CPU più veloci, ma meno memoria. Quali differenze vedi, se ce ne sono? Con più thread?

Ora il team di Dobermanifesto deve decidere quale percorso intraprendere. Dopo aver eseguito la profilazione dell'utilizzo della CPU e aver dato un'occhiata alle informazioni sui prezzi, hanno deciso di utilizzare una macchina e2-standard-4, che ha consentito loro di aumentare di quasi 4 volte la velocità effettiva media, ma che è più economica delle macchine e2-standard-8.

Uno degli aspetti positivi del passaggio a una macchina più grande è che in realtà viene messa in funzione meno frequentemente. Si è scoperto che le macchine rimanevano attive per molto tempo, solo per trasferire dati. Con le nuove dimensioni della macchina, le istanze avevano tempi di inattività più lunghi, consentendo al bilanciatore del carico di ridurre il numero totale di istanze su base giornaliera. Di conseguenza, da un lato, pagheranno per una macchina di livello superiore, ma dall'altro utilizzeranno meno ore core su base mensile.

Se le tue prestazioni impattano direttamente sui profitti, ci sono molte sfumature di compromessi da considerare.

Caso d'uso 2: Networking di Google Cloud con IP interni

Nel prossimo esempio utilizzerai iperf per testare la velocità effettiva. Imposterai una macchina come server, verso cui punterai altre macchine e confronterai i risultati.

Gecko Protocol, un'azienda B2B che offre un protocollo di rete personalizzato e leggero costruito per i giochi e altri sistemi grafici in tempo reale, stava riscontrando una velocità effettiva inferiore al previsto per le proprie macchine di backend, responsabili del trasferimento e della transcodifica di file grafici e video di grandi dimensioni.

Ecco i risultati del loro test iperf di base:

------------------------------------------------------------ Client connecting to 104.155.145.79, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 53504 connected with 104.155.145.79 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.03 GBytes 884 Mbits/sec

Duplicando il test, la configurazione della rete era identica, ma i risultati del test erano molto diversi:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.128.0.2 ------------------------------------------------------------ Client connecting to 10.128.0.2, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.128.0.3 port 38978 connected with 10.128.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.27 GBytes 1.95 Gbits/sec

1,95 GB/sec era molto più alto di quello che Gecko Protocol vedeva nei propri grafici. Allora cosa sta succedendo?

Ora ricrea questo scenario.

1. Nella console, accedi tramite SSH a instance-1 e imposta il ricevitore iperf:

iperf -s

Output di esempio:

student-00-aafd1bd9c185@instance-1:~$ iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 128 KByte (default) ------------------------------------------------------------

2. Accedi tramite SSH a instance-2 e verifica la connessione dell'indirizzo IP esterno:

iperf -c <external ip address of instance-1>

Output di esempio:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 35.201.145.135 ------------------------------------------------------------ Client connecting to 35.201.145.135, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 58691 connected with 35.201.145.135 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.36 GBytes 1.16 Gbits/sec

Dopo un'ulteriore discussione con Gecko Protocol, abbiamo capito che stavano utilizzando IP esterni per collegare le macchine e che il test aveva utilizzato IP interni. Quando si collegano le macchine di una rete con IP interni si ottiene una velocità effettiva più elevata.

3. Ora controlla la connessione con l'indirizzo interno:

iperf -c <internal ip address of instance-1>

Output di esempio:

student-00-aafd1bd9c185@instance-2:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.8 port 42950 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 2.26 GBytes 1.94 Gbits/sec

Guarda le due diverse velocità di trasferimento e larghezze di banda. In questo esempio, il passaggio all'indirizzo IP interno ha comportato un miglioramento di 0,9 GByte nella velocità di trasferimento e di 0,78 Gbit/sec nella larghezza di banda. Hai appena dimostrato che la connessione interna è più veloce.

Basandoti su ciò che hai imparato risolvendo il problema di Dobermanifesto, è possibile migliorare ulteriormente la velocità della rete utilizzando una macchina più grande? instance-2 è solo 1 vCPU. Quanto sarà veloce la connessione se la macchina è un po' più grande? O molto più grande? Continua a testare utilizzando l'indirizzo IP interno (ma testa anche quello esterno, se hai tempo).

Macchina da 4 vCPU

• Accedi tramite SSH a instance-3 e testa la connessione con l'indirizzo IP interno:

iperf -c <internal ip address of instance-1>

Output di esempio (i tuoi risultati potrebbero differire):

student-00-aafd1bd9c185@instance-3:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.6 port 39115 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 4.53 GBytes 3.89 Gbits/sec

Macchina da 4 CPU elevate

• Accedi tramite SSH a instance-5 e testa la connessione con l'indirizzo IP interno:

iperf -c <internal ip address of instance-1>

Output di esempio:

student-00-aafd1bd9c185@instance-5:~$ iperf -c 10.40.0.5 ------------------------------------------------------------ Client connecting to 10.40.0.5, TCP port 5001 TCP window size: 45.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.40.0.3 port 39736 connected with 10.40.0.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.3 GBytes 8.84 Gbits/sec

Questo migliora davvero la velocità effettiva.

Sembra che Gecko Protocol dovrà anche pensare a quale sarà la migliore dimensione del core. Questa piccola sessione di debug ha comportato un miglioramento del trasferimento dei dati video e grafici di circa 14 volte. Che è moltissimo, considerando che la loro offerta è basata su servizi di backend prestazionali per scenari di computing ad alte prestazioni.

Attività 3: test nel tuo ambiente

Questo lab non spiega come testare il tuo sistema, ma ecco ulteriori informazioni che potranno risultarti utili. Per ulteriori informazioni su come testare la tua rete, leggi l'articolo Diagnosticare la velocità di rete con iPerf.

Se hai tempo e vuoi configurare una VM da testare, fallo pure. Quando crei le tue VM, assicurati di utilizzare il tag e la regola firewall "iperftest". Testa sia il tuo indirizzo IP interno che quello esterno.

Impostazioni per testare la velocità della tua rete

1. Nella console, vai a Menu di navigazione > Networking > Reti VPC > Firewall.

2. Fai clic su Crea regola firewall. Utilizza la seguente configurazione per creare una regola firewall:

Campo	Valore	Commenti
Nome	iperf-testing	Nome nuova regola
Destinazioni	Tutte le istanze nella rete
Intervalli IP di origine	0.0.0.0/0	Apriremo il firewall per qualsiasi indirizzo IP da internet.
Direzione del traffico	In entrata
Azione in caso di corrispondenza	Consenti
Protocolli e porte	tcp:5001; udp:5001

3. Fai clic su Crea.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Crea la regola firewall

La tendenza è quella di portare il carico di lavoro il più vicino possibile al 100%, il che lascia poco spazio per la deframmentazione del disco e così via.

Il 90-93% indica un utilizzo equilibrato, ma un valore del 98% vedrà un calo delle prestazioni poiché ci saranno molti conflitti.

Durante il test, se le prestazioni di I/O diminuiscono, osserva i contatori delle limitazioni. Se non vengono limitate, controlla l'utilizzo della CPU. Se è elevato, il problema è quello.

Attività 4: sei hai più tempo

Nell'interfaccia del lab, sotto Risorse per studenti sul lato sinistro, vedrai i link ai video relativi a questo lab. Vale davvero la pena guardarli!

Complimenti!

Complimenti! In questo lab hai imparato come testare la connettività e le prestazioni della rete utilizzando strumenti open source e come le dimensioni della tua macchina possono influire sulle prestazioni della rete.

Passaggi successivi/Scopri di più

• Scopri il post di Google Cloud Guida finale all'uso dei prodotti per il networking cloud di Google.
• Leggi la documentazione sul networking di Compute Engine.
• Scopri di più sulle subnet.
• Pubblica domande e trova risposte su Stack Overflow utilizzando i tag google-compute-engine o google-cloud-platform.

Formazione e certificazione Google Cloud

… per utilizzare al meglio le tecnologie Google Cloud. I nostri corsi ti consentono di sviluppare competenze tecniche e best practice per aiutarti a metterti subito al passo e avanzare nel tuo percorso di apprendimento. Offriamo vari livelli di formazione, dal livello base a quello avanzato, con opzioni di corsi on demand, dal vivo e virtuali, in modo da poter scegliere il più adatto in base ai tuoi impegni. Le certificazioni ti permettono di confermare e dimostrare le tue abilità e competenze relative alle tecnologie Google Cloud.

Ultimo aggiornamento del manuale: 4 ottobre 2023

Ultimo test del lab: 4 ottobre 2023

Copyright 2024 Google LLC Tutti i diritti riservati. Google e il logo Google sono marchi di Google LLC. Tutti gli altri nomi di società e prodotti sono marchi delle rispettive società a cui sono associati.