GSP045

Descripción general

En este lab práctico, leerás sobre algunos casos del mundo real, recrearás entornos y trabajarás para mejorar el rendimiento de algunas redes problemáticas.

Sería divertido intentar comparar las diferentes instancias entre sí, como el caso de uso de solución de problemas, de manera que puedas comprobar los resultados y familiarizarte con los pasos utilizados para mejorar el rendimiento de tus propios sistemas.

Este lab se adaptó de entradas de blog realizadas por Colt McAnlis: Core Count and the Egress problem y Internal IP vs External IP. Colt escribe sobre el rendimiento de redes de Google Cloud en Medium.

Objetivos

• Cómo probar el rendimiento y la conectividad de red con herramientas de código abierto
• Cómo inspeccionar el tráfico de red con herramientas de código abierto
• Cómo puede el tamaño de tu máquina afectar el rendimiento de la red

Requisitos previos

• Conocimiento básico de los servicios de Google Cloud (ese conocimiento se obtiene mejor en los labs de Google Cloud Essentials)
• Conocimiento básico de herramientas de redes de Google Cloud y TCP/IP (ese conocimiento se obtiene en los primeros labs de la Quest “Networking in the Google Cloud”)
• Conocimiento básico de la línea de comandos de Unix/Linux

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)

Nota: Usa una ventana de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar su lab y acceder a la consola de Google Cloud

1. Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab que tiene estos elementos:

   • El botón Abrir la consola de Google
   • Tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haga clic en Abrir la consola de Google. El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ve el diálogo Elegir una cuenta, haga clic en Usar otra cuenta.

3. Si es necesario, copie el nombre de usuario del panel Detalles del lab y péguelo en el cuadro de diálogo Acceder. Haga clic en Siguiente.

4. Copie la contraseña del panel Detalles del lab y péguela en el cuadro de diálogo de bienvenida. Haga clic en Siguiente.

   Importante: Debe usar las credenciales del panel de la izquierda. No use sus credenciales de Google Cloud Skills Boost. Nota: Usar su propia Cuenta de Google podría generar cargos adicionales.

5. Haga clic para avanzar por las páginas siguientes:

   • Acepte los términos y condiciones.
   • No agregue opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No se registre para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Cloud en esta pestaña.

Nota: Para ver el menú con una lista de los productos y servicios de Google Cloud, haga clic en el Menú de navegación que se encuentra en la parte superior izquierda de la pantalla.

El objetivo de este lab es mostrarte las relaciones entre el tamaño del núcleo y la capacidad de procesamiento, por lo que se incluyen 6 instancias ya integradas. Se crearon cuando iniciaste el lab.

• En la consola de Cloud, navega al menú de navegación > Compute Engine > Instancias de VM para ver tus instancias:

Nota: La instancia de tu región y zona puede diferir de las que se muestran en la captura de pantalla.

Prueba de conexión

Ejecuta una prueba de conexión rápida para garantizar que todo funcione correctamente.

1. Para establecer una conexiónSSH en instance-1, haz clic en el botón SSH junto al nombre en la consola.

2. En tu nueva ventana de shell, haz ping en otra de tus instancias, ejecuta el siguiente comando y reemplaza la dirección IP externa <external ip address of instance-2> por instance-2:

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

Resultado de ejemplo:

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 4001 ms rtt min/avg/max/mdev = 0.409/0.792/1.894/0.554 ms

3. Haz ping en otra. Reemplaza <external ip address of instance-3> por la dirección IP externa de instance-3 y haz ping en ella:

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

Resultado de ejemplo:

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 3999 ms rtt min/avg/max/mdev = 0.270/0.568/1.596/0.514 ms

Todo luce bien. Continuemos.

Revisa las reglas de firewall

Las reglas de firewall también se crean para este lab.

• Para ver lo que son, navega a Menú de navegación > Herramientas de redes > Redes de VPC > Firewall y haz clic en el firewall de iperftesting.

La regla de firewall iperftesting utiliza la siguiente configuración:

Campo	Valor	Comentarios
Nombre	iperftesting	Nombre de la nueva regla
Destinos	Todas las instancias de la red
Rangos de IP de origen	0.0.0.0/0	Abriremos el firewall para cualquier dirección IP de Internet.
Protocolos y puertos	tcp:5001; udp:5001
Dirección del tráfico	Ingress
Acción en caso de coincidencia	Permitir

Ya puedes comenzar a utilizar el lab.

Caso de uso 1: herramientas de redes y número de núcleos de Compute Engine

En la primera situación, verás cómo el tamaño de las máquinas que se utilizan afecta la capacidad de procesamiento que puedes medir.

Dobermanifesto es una red de microblogs de video exclusiva para mascotas. Los videos basados en animales pueden subirse en todo el mundo y enviarse a cualquier lugar para ser vistos y experimentados.

Mientras se transferían datos desde y hacia sus backends de Compute Engine, el ancho de banda observado no era tan alto como se esperaba:

Tarea 1. Cómo reproducir el comportamiento

Para intentar reproducir este comportamiento, se crearon dos instancias en la misma zona y se ejecutó iperf 100 veces entre ellas.

Este rendimiento fue aún peor. Obviamente, la prueba tenía algún error. Necesitamos más información y un conjunto más detallado de pasos para reproducir el problema de la empresa.

Ahora, tú configurarás la situación.

Entorno de Dobermanifesto

1. Regresa a la ficha de Instancias de VM en la consola de Compute Engine.

2. Establece una conexión SSH a instance-1 (1 CPU virtual con 3.75 GB) y ejecuta este comando para configurar un “receptor” iperf:

iperf -s

3. Luego, establece una conexión SSH a instance-2 (1 CPU virtual con 3.75 GB) y genera tráfico iperf que dirija a instance-1:

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

Resultado de ejemplo:

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. Vuelve a instance-1 y finaliza el receptor ingresando CTRL + C.

Entorno de pruebas

1. Regresa a la consola de Compute Engine y abre otra ventana de SSH a instance-6 (1 CPU virtual e2-micro con 6 GB).

2. Ejecuta el siguiente comando y configúralo como un “receptor”.

iperf -s

Resultado de ejemplo:

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

3. En la ventana de SSH de instance-2, prueba la conexión a instance-6:

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

Resultado de ejemplo:

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. Vuelve a instance-6 y finaliza el receptor ingresando CTRL + C.

¿Qué pasó? Parece que aumentó el ancho de banda. Es posible que esto también haya ocurrido en tu caso. O puede que haya sido menos.

En la siguiente sección, veremos cómo el número total de núcleos limita el ancho de banda y que, con el número de núcleos en este rango pequeño (1), el ancho de banda nunca superará los 2 Gbits/s aproximadamente. Como resultado, la velocidad de la red es lenta y el ancho de banda está restringido, algo similar a los que experimentaba Dobermanifesto. Cuando pruebas máquinas con 4 CPU en un minuto, los resultados serán mayores.

El número de núcleos se correlaciona con los Gb/s

¿Por qué los resultados fueron parecidos? La documentación para Compute Engine señala la siguiente conclusión:

El tráfico de salida de una máquina virtual está sujeto al límite máximo de la capacidad de procesamiento de salida de red. Los límites dependen de la cantidad de CPU virtuales que tenga una instancia de máquina virtual. Para alcanzar el rendimiento máximo, cada núcleo tiene un límite de 2 Gbits/segundo (Gbps). Cada núcleo adicional aumenta el límite de la red hasta un máximo teórico de 16 Gbps por cada máquina virtual.

Esto significa que, mientras más CPU virtuales haya en tu red, más capacidad de procesamiento tendrás.

Para averiguar cómo se ve esto en la práctica, se configuraron distintos grupos de tamaño del núcleo en la misma zona y se ejecutó 1,000 veces el iperf entre ellos.

A medida que aumenta el número de núcleos, también lo hacen las capacidades de procesamiento promedio y máxima. Incluso con esta prueba simple, puedes ver ese límite estricto de 16 Gbps en las máquinas más altas.

Nota: Si ejecutas el iperf con varios subprocesos (8 aproximadamente), puedes exceder los 10 Gbps y aumentar hasta unos 16 Gbps con una máquina e2-standard-16 o superior. En este entorno de lab, no tenemos una máquina con ese tamaño, pero hagamos a continuación una prueba con varios subprocesos. También hay VMs de costo superior en las series N2, N2D, C2 o C2D que te permiten seleccionar una configuración de nivel 1 de ancho de banda alto y alcanzar 50-100 Gbps.

Tarea 2. Cómo mejorar los resultados

La red que tiene Dobermanifesto utiliza máquinas con 1 CPU virtual. Es probable que aumentar el tamaño del núcleo ayude a que Dobermanifesto obtenga mejores resultados. Es momento de probar la teoría.

1. Establece una conexión SSH a instance-3 (4 CPU virtuales con 15 GB de memoria) y ejecuta este comando:

iperf -s

Resultado de ejemplo:

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

2. Establece una conexión SSH a instance-4 (4 CPU virtuales con 15 GB de memoria):

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

Resultado de ejemplo:

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. Ahora, inténtalo de nuevo con 4 subprocesos:

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

4. Y con 8 subprocesos:

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

5. Vuelve a instance-3 y finaliza el receptor ingresando CTRL + C.

En estos experimentos, tanto el servidor como el cliente eran máquinas de 4 CPU virtuales y la velocidad aumentó de manera considerable. La tasa de transferencia aumentó 6.64 GBytes y el ancho de banda, 5.71 Gbits/s. Con varios subprocesos, el rendimiento pudo alcanzar el límite para ese número de núcleos.

6. Sigue realizando pruebas con instance-5, una máquina de 4 CPU virtuales con mayor rendimiento, tipo de instancia “highcpu-4”.

Este tipo de instancia tiene CPU más rápidas, pero menos memoria. ¿Qué diferencias ves, si es que ves alguna? ¿Con varios subprocesos?

Ahora el equipo de Dobermanifesto necesita decidir qué ruta tomar. Después de perfilar su uso de CPU y observar la información de precios, decidieron usar una máquina e2-standard-4, que les proporcionó una capacidad de procesamiento en promedio 4 veces mayor, pero que resultó ser más económica que las máquinas e2-standard-8.

Uno de los beneficios de migrar a la máquina más grande es que, en realidad, se ejecuta con menos frecuencia. Resulta que sus máquinas pasaban mucho tiempo activadas solo para transferir datos. Con el nuevo tamaño, sus instancias tenían más tiempo de inactividad, lo que permitía que el balanceador de cargas redujera a diario el número total de instancias. Entonces, por un lado, terminaron pagando por una máquina de nivel superior, pero, por el otro, utilizarán menos horas de núcleo mensualmente.

Una vez que tu rendimiento influya directamente en los resultados, se deberán considerar muchas ventajas y desventajas matizadas.

Caso de uso 2: herramientas de redes de Google Cloud con IP internas

En el siguiente ejemplo, utilizarás iperf para probar la velocidad de la capacidad de procesamiento. Configurarás una máquina como el servidor y, luego, dirigirás otras máquinas a ella y compararás los resultados.

Gecko Protocol es una empresa B2B que ofrece un protocolo de herramientas de redes ligero y personalizado, creado para videojuegos y otros sistemas de gráficos en tiempo real. Su capacidad de procesamiento era inferior a la esperada para sus máquinas backend, que eran responsables de transferir y transcodificar grandes archivos de video y gráficos.

Este es el resultado de la prueba iperf de referencia:

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

Cuando se duplicó la prueba, la configuración de la red era idéntica, pero los resultados fueron muy diferentes:

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/s era mucho mayor que lo que Gecko Protocol veía en sus gráficos. Entonces, ¿qué es lo que sucede?

Ahora, recrea esta situación.

1. En la consola, establece una conexión SSH a instance-1 y configura el receptor iperf:

iperf -s

Resultado de ejemplo:

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

2. Establece una conexión SSH a instance-2 y verifica la conexión de la dirección IP externa:

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

Resultado de ejemplo:

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

Después de investigar junto con Gecko Protocol, se descubrió que estaban usando IPs externas para conectar sus máquinas, mientras que la prueba utilizó IPs internas. Cuando las máquinas están en una red, conectarlas a IP internas generará una capacidad de procesamiento más rápida.

3. Ahora, verifica la conexión con la dirección interna:

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

Resultado de ejemplo:

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

Observa las dos diferentes tasas de transferencia y de ancho de banda. En este ejemplo, cambiar la dirección IP interna dio como resultado una mejora de 0.9 GB en la tasa de transferencia y una mejora de 0.78 Gbits/s en el ancho de banda. Acabas de demostrar que la conexión interna es más rápida.

Según lo que aprendiste cuando resolviste el problema de Dobermanifesto, ¿crees que puede mejorarse aún más la velocidad de la red usando una máquina más grande? instance-2 es solo 1 CPU virtual. ¿Qué tan rápida será la conexión si la máquina es un poco más grande? ¿Y si fuese mucho más grande? Sigue realizando pruebas con la dirección IP interna (pero, si tienes tiempo, no dudes en probar también la externa).

Máquina de 4 CPU virtuales

• Establece una conexión SSH a instance-3 y prueba la conexión con la dirección IP interna:

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

Resultado de ejemplo (tus resultados pueden variar):

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

Máquina de 4 CPU elevadas

• Establece una conexión SSH a instance-5 y prueba la conexión con la dirección IP interna:

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

Resultado de ejemplo:

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

Esto realmente mejora la tasa de capacidad de procesamiento.

Al parecer, Gecko Protocol también deberá pensar qué tamaño de núcleo será mejor. Esta pequeña sesión de depuración dio como resultado que su transferencia de datos de video y gráficos fuera 14 veces mejor. Es una gran diferencia, si consideramos que su oferta se basa en el rendimiento de servicios de backend para situaciones de computación de alto rendimiento.

Tarea 3: Cómo realizar pruebas en tu entorno

Este lab no abarca cómo probar tu propio sistema, pero aquí encontrarás información adicional. Para obtener más detalles sobre cómo probar tu propia red, lee Diagnosing Network Speed with Iperf.

Si tienes tiempo y quieres configurar una VM para probarla, no dudes en hacerlo. Cuando crees tus VMs, asegúrate de utilizar la etiqueta y regla de firewall “iperftest”. Prueba tu dirección IP tanto interna como externa.

Opciones de configuración para probar la velocidad de tu propia red

1. En la consola, ve al Menú de navegación > Herramientas de redes > Redes de VPC > Firewall.

2. Haz clic en Crear una regla de firewall. Usa la siguiente configuración para crear una regla de firewall:

Campo	Valor	Comentarios
Nombre	iperf-testing	Nombre de la nueva regla
Destinos	Todas las instancias de la red
Rangos de IP de origen	0.0.0.0/0	Abriremos el firewall para cualquier dirección IP de Internet.
Dirección del tráfico	ingress
Acción en caso de coincidencia	Permitir
Protocolos y puertos	tcp:5001; udp:5001

3. Haz clic en Crear.

Haz clic en Revisar mi progreso para verificar el objetivo. Crear una regla de firewall

La tendencia es lograr que la carga de trabajo se acerque lo más posible al 100%, lo que deja poco espacio para que se desfragmente el disco, etcétera.

Entre 90% y 93%, el uso será correcto, pero, si llega al 98%, disminuirá el rendimiento porque tendrás mucha contención.

Cuando realices la prueba, si disminuye el rendimiento de IO, revisa los contadores de regulación. Si no se los está regulando, revisa el uso de la CPU. Si es muy elevado, ese es el problema.

Tarea 4. Si tienes más tiempo

En la interfaz del lab, en Recursos para estudiantes en el lado izquierdo, verás vínculos de videos relacionados con este lab. Vale la pena mirarlos.

¡Felicitaciones!

¡Felicitaciones! En este lab, aprendiste a probar la conectividad y el rendimiento de redes con herramientas de código abierto y aprendiste cómo el tamaño de tu máquina puede afectar el rendimiento de la red.

Próximos pasos y más información

• Ve la entrada de blog de Google CloudUsing Google's cloud networking products: a guide to all the guides.
• Lee la documentación de las Herramientas de redes de Compute Engine.
• Obtén más información acerca de las Subredes.
• Publica preguntas y encuentra respuestas en Stackoverflow con las etiquetas google-compute-engine o google-cloud-platform.

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 4 de octubre de 2023

Prueba más reciente del lab: 4 de octubre de 2023

Copyright 2024 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.