martes, 28 de agosto de 2018

GPU Tesla V100 ahora están disponibles en Google Cloud


Hoy nos han anunciado que ya esta disponible en Google Cloud las (GPU) NVIDIA V100 con NVLink a disposición. Estas GPU ofrecen una potencia importante para cargas de trabajo computacionales complejas.

Aparte de las nuevas V100, junto con estas ya se tenian disponibles GPU K80, P100 y P4, son excelentes para acelerar muchas cargas de cómputo y HPC alimentadas por CUDA. La GPU V100 destaca especialmente por las cargas de trabajo de AI.

Cada GPU V100 tiene 640 núcleos de tensor y ofrece hasta 125 TFLOPS de rendimiento mixto ML de precisión. Esto significa que puede obtener hasta un rendimiento de petaFLOP de ML en una sola máquina virtual (VM), lo que lo convierte en una herramienta de procesamiento muy potente para el entrenamiento ML y las cargas de trabajo de inferencia. Además, para las cargas de trabajo más exigentes, se dispone de la  red NVLink de alta velocidad entre GPU de hasta 300 GB / sy SSD local opcional para E / S de disco rápido.


Un cliente de V100 que utiliza Compute y Kubernetes Engine que trabaja en el desarrollo y la promoción de inteligencia artificial artificial segura. Usan las GPU V100 y P100, junto con las máquinas virtuales (VM) exclusivas para CPU, para ejecutar grandes trabajos de aprendizaje de refuerzo para entrenar a AI para jugar de forma cooperativa en juegos multijugador y prepararse para la competencia The International Dota 2.


En primer lugar, aumentamos la flexibilidad agregando soporte para conectar dos o cuatro V100 a una VM, lo que significa que ahora hay soporte para conectar uno, dos, cuatro u ocho V100 por VM. Esto es importante ya que le permite hacer coincidir su carga de trabajo con la cantidad óptima de potencia de la GPU. Esto más la característica personalizada de VM le permite crear una forma de máquina virtual con la CPU, la memoria, el almacenamiento y el rendimiento de la GPU V100 que satisfaga sus necesidades.


En segundo lugar, facilitamos el inicio de las GPU en Compute Engine para ML y otras cargas de trabajo informáticas al ofrecer nuevas imágenes del sistema operativo preconfiguradas y optimizadas para la carga de trabajo y el rendimiento. Simplemente cree una máquina virtual con una GPU, elija una de ellas con bibliotecas preinstaladas y comience. Estas imágenes funcionan para todas las plataformas GPU-K80, P100, P4 y V100- y vienen en tres Configuraciónes: TensorFlow, PyTorch y Base.

Los tres incluyen las últimas versiones de las herramientas de NVIDIA de las que dependen: CUDA 9.2, CuDNN 7.2 y NCCL 2.2, y son una buena opción para las cargas de trabajo de ML. La imagen base también se puede usar para otras cargas de trabajo de cómputo, como HPC, que vienen con controladores GPU preconfigurados. El uso de estas imágenes le brinda las optimizaciones de rendimiento para el uso de GPU en GCP, y en particular ayuda realmente al usar múltiples GPU V100 con NVLink para cargas de trabajo de aprendizaje profundo. Para obtener más información y para comenzar, consulte nuestra documentación de imágenes.

En tercer lugar, se ha bajado los  precios de GPU prioritarios para todas las plataformas de GPU, incluidos los V100, hasta un 70% de descuento en los precios según demanda. Esto proporciona a cualquier organización una oferta informática de muy bajo costo y elimina tener que lidiar con los precios fluctuantes de un sistema de subastas. Esto es crítico si usted está haciendo ML o HPC trabajan con un presupuesto limitado, pero son lo suficientemente flexibles como para manejar las limitaciones que vienen con máquinas virtuales "preemtibles", como una vida útil máxima de 24 horas.

¿Querer aprender más? Visite la página de productos GPU para obtener información general y precios. O formese con la documentación de GPU para conocer la disponibilidad de ubicación y cómo comenzar.

viernes, 24 de agosto de 2018

Migrar a GCP con CloudEndure (IV) – Test y Cut-Over

Una de las opciones más interesantes que tiene CloudEndure es que puedes probar las replicas que estás haciendo para verificar que son funcionales. Esto es fundamental si estás utilizando Google Cloud como solución de Disaster Recovery para tu plataforma on-premises.
Si entráis en la consola de GCP, veréis que hay máquinas y snapshots que no habéis creado vosotros. Son los que crea CloudEndure y después se utilizan para lanzar los Test y CutOver.

Para lanzar una prueba simplemente elegimos la máquina que queremos probar y le decimos “Test Mode”. También lo podemos hacer desde los detalles particulares de la máquina, donde se definía el Blueprint
Esto va a empezar a realizar diferentes tareas en nuestra plataforma GCP. Estas tareas las podremos ir viendo desde la pestaña de Job Progress . Estas tareas incluyen la creación de la máquina, discos, reglas de firewall, etc..
Una vez realizadas todas las tareas, ya podremos acceder a la réplica como si fuera cualquier otra máquina y probar que todo está correcto. Los datos de conexión (direcciones IP públicas, etc…) están en la consola de Google. Hay que recordar que la réplica se ha lanzado con la configuración que pusimos en el Blueprint, por lo que si hemos especificado una dirección IP para esa máquina, podríamos acceder utilizando dicha dirección IP (siempre que tengamos otra máquina accesible dentro de esa red, claro 🙂

Como veis ha creado una máquina llamada ubuntu-replica, que es tal cual la habíamos llamado en el Blueprint y está dentro de la red 192.168.1.0/24 que es la que estaba definida dentro de nuestro VPC.
Aqui la conexión desde la máquina instance-1 a la replica que hemos lanzado que se llamaba  ubuntu-replica.

En la consola de CloudEndure vereis que la maquina ahora ya aparece como testada (último icono de STATUS):

Una vez terminada la prueba, borramos la VM y ya estaría todo.
En caso de que lancemos un nuevo Test de una máquina que ya tiene su replica funcionando en GCP, CloudEndure borrará la replica existente en GCP y lanzará la nueva utilizando el último snapshot. De esta forma, se mantiene la consistencia.
Cut-Over
Cut-Over sería la operación correspondiente a paso a producción de la máquina. En nuestro caso, supondría que ya estamos listos para utilizar la máquina en GCP porque hemos testado la replica y es satisfactoria y ya podríamos apagar las máquinas on-premises.
A efectos técnicos, no tiene ninguna diferencia frente a una operación Test, la única diferencia es a nivel de CloudEndure que Test lo marco como “Probado” y CutOver lo marca como “CutOver” para facilidad nuestra de saber que hemos probado y que hemos pasado ya a productivo, pero no supone ninguna diferencia técnica.

Conclusión

Con todos estos posts, hemos enseñado como pasar máquinas Linux o Windows a la plataforma cloud de Google de una manera sencilla, y gratuita. Y las posibilidades que tiene son muchísimas.
En el siguiente (y último post de esta serie) haremos un resumen de las funcionalidades y las impresiones que nos ha causado CloudEndure.

Migrar a GCP con CloudEndure (III) – Consola

A estas alturas ya tenemos nuestras máquinas replicando a la nube de Google.
Desde la consola de CloudEndure vamos a poder realizar las acciones y monitorizar el estado de cada máquina y su realización desde el entorno original.
A nivel global de la consola podemos realizar operaciones como añadir otras máquinas, quitar alguna de las existentes, parar o pausar la realización…
En la parte izquierda están los diferentes apartados que podemos gestionar.
Empezamos por Machines
A nivel particular de cada máquina, la pestaña Blueprint nos va a permitir definir ciertos parámetros que se van a utilizar a la hora de poner las réplicas en ejecución. Estos parámetros son el tipo de máquina, el nombre de la máquina (tal como lo veríamos en la consola de GCP), y en que red lo vamos a lanzar así como si queremos ponerle una IP por nosotros mismos o se la pone el sistema.
Esta parte es la más importante ya que tenemos que haber definido con antelación las redes que vamos a necesitar para que todo funcione una vez esté replicado. Para un migración pura y dura de lo que se tiene en el datacenter de la organización, en la que simplemente se migran las máquinas de plataforma y no hay cambios de arquitectura, lo suyo sería definir las mismas redes y rangos que se tienen on-premises, y configurar con las mismas IP a las máquinas que corresponda.
Como se observa en la imagen también se indica el status de la replicación, tiempo estimado para que finalice, etc…pero insisto que lo importante aquí es lo que configuremos en “Blueprint” ya que os lo que afectará en donde se lancen luego las replicas.
En la pestaña de Replication Settings se tiene la misma información que se ponía al principio sobre en que región se va a replicar la máquina. Aquí podríamos cambiar si queremos que una máquina se replique a una región diferente de la especificada con anterioridad.
En la parte izquierda quedarían 2 partes que utilizaremos también. Job Progress donde vamos a poder ver como van nuestros trabajos de Test y Cut-Over y Audit Log donde tendremos un log de las operaciones realizadas contra la plataforma, como los cambios realizados a un Blueprint, cuando se han registrado máquinas, etc…
Finalmente, en la opción de Setup & info tenemos la información que introdujimos al principio sobre la conexión a GCP, región a la que se replica, etc..
En el siguiente post vamos a ver como lanzar los trabajos de Test y Cut-Over contra la plataforma de Google Cloud

Migrar a GCP con CloudEndure (II) – Instalación de agentes en Linux y Windows

Segunda parte de la series de como migrar máquinas a la nube de Google con CloudEndure. Vamos a ver como instalar los agentes en Linux y en Windows.
Si recordais, en el post anterior al final comentábamos que había un botón “Show me how” una vez configurados los parámetros de realización. Si damos a este botón aparecerá una ventana con las instrucciones de instalación tanto para Linux como para Windows.
Instalación en Linux
Simplemente hay que ejecutar los pasos que se indican en la ventana de instrucciones, pero hay que tener en cuenta que hay que tener Python instalado. En caso de que no se tenga, es necesario instalarlo con anterioridad. En mi caso en Ubuntu, instalé la versión 3 con estos pasos:
sudo apt update
sudo apt install python3.6
Hay que tener en cuenta que en las instrucciones el ejecutable que se llama es “python” y en este caso el ejecutable generado por la instalación de python se llama “python3.6” por lo que el comando completo sería:
sudo python3.6 ./installer_linux.py -t <token> –no-prompt
Como veis, el agente se instala sin ningún problema. Eso sí, a mí me tardó unos 10-15 minutos.
Instalación en Windows
La instalación en Windows es prácticamente igual que en Linux. Se descarga el instalador del agente y se lanza por linea de comandos y aparecerá una ventana en la que veréis como se va instalando el agente.
Este proceso de instalación de agentes, hay que hacerlo por cada máquina que queramos migrar a GCP
Durante la instalación de los agentes, se puede ver en la consola el status de la misma.
Nada más conectarse el agente a la consola y finalizar las tareas, ya empezará a replicar. Si entráis en los detalles de cada máquina veréis el progreso de la réplica.

Hasta aquí tendríamos ya los agentes de realización instalados y nuestras máquinas empezarían a replicarse ya en GCP. En el próximo post veremos un poco más en detalle como configurar las réplicas

Migrar a GCP con CloudEndure (I) – Preparación de entorno

Vamos a crear una serie de posts en las que explicaremos como migrar máquinas a la plataforma cloud de Google, conocida también como GCP. Google te da 300 dolares para gastar en su plataforma y que puedas probar todos los servicios que quieras, por lo que te recomiendo que te saques una cuenta gratuita para tus tests y laboratorios que con 300 dolares te dará para mucho 🙂

Para ello, utilizaremos una herramienta llamada CloudEndure que va a permitir replicar las máquinas en la nube de Google. Esta herramienta vale para migrar máquinas entre diferentes entornos incluidos Azure, Amazon AWS, VMWare o incluso Openstack, aunque ahora nos centraremos en como migrar a GCP. Espero en próximos posts poder probar e ilustrar como se realizan.
Una cuestión importante es que esta herramienta a la hora de migrar a la plataforma Google es gratuita. Los únicos costes que se van a cobrar son los de las máquinas virtuales y recursos que utilicemos en la nube de Google, pero no tendremos ningún coste de licencia por el uso de CloudEndure. Esto es importante porque CloudEndure permite probar y testar las réplicas de las máquinas virtuales antes de que hagamos el ‘corte’ y empecemos a funcionar en Google, y esos recursos que utilicemos para la réplica y para probar sí que tendrían coste.
Antes de empezar la migración, hay que hacer una serie de pasos para preparar el entorno.
Lo primero es crear un proyecto. Un proyecto a nivel de GCP es una colección de recursos agrupados bajo un mismo paragüas, que es el proyecto. Estos recursos pueden ser usuarios, maquinas virtuales, API…y su facturación. GCP asocia los costes a cada proyecto por lo que hay que tenerlo en cuenta a la hora de planificar los recursos.
Todo lo relativo a GCP se gestiona desde una consola que es accesible por http://console.cloud.google.com.  Una vez creamos el proyecto,  es necesario habilitar una cuenta de servicio, que no es más que una cuenta con unos determinados privilegios para acceder a la API de un servicio determinado. En este caso, crearemos una cuenta de servicio al que le vamos a dar acceso completo a los recursos
Para crear la cuenta de servicio, hay que ir a la sección “IAM y Administración” y elegir la opción “Cuentas de servicio”. En la pantalla que aparece, le damos a crear una nueva cuenta
Le damos el rol de “Propietario de Proyecto”. Elegimos también que nos genere una nueva clave privada y que la vamos a guardar en formato JSON.

Una vez le demos al botón de “Guardar”, nos pedirá donde salvarlo. Lo guardamos.
Con esto terminamos de preparar el entorno en Google.
Ahora vamos a la consola de gestión de CloudEndure. Accedemos a http://gcp.cloudendure.com y nos validamos con nuestra cuenta Google bajo la cual está nuestro proyecto.

Una vez entramos a la consola, lo primero será rellenar los datos de la conexión de CloudEndure a GCP. Para ello, rellanamos el ID del proyecto e importamos el JSON con la clave privada que hemos generado anteriormente.

Elegir la región donde vamos a crear las VM replicadas.
Guardamos la configuración
Y ya tendremos todo configurado en la parte de con
Se ve que aparece el botón “Show me how”. Este botón hace que aparezca una ventana con las instrucciones de instalación del agente en Linux y en Windows, lo cual veremos en el próximo post.

lunes, 20 de agosto de 2018

GitHub se integra en Google Cloud


En el ultimo congreso de Google Cloud Next de 2018, de las +100 Presentaciones nuevas, hoy en Google Cloud en Español hablamos de la integración con GitHub para permitir de forma ágil y sencilla  CI/CD.

Google Cloud y GitHub se ha  integrado la conexión de  GitHub con Cloud Build de Google, de modo de crear una  plataforma de CI/CD.

Ahora se proporciona Integración Continua (IC) rápida, transparente y comoda para cualquier repositorio en GitHub, integrado directamente en el flujo de trabajo del desarrollador de GitHub. Millones de desarrolladores trabajn en GitHub para almacenar y colaborar en torno al código fuente. Al trabajar con GitHub, se  busca la oportunidad de ayudar a que sea más fácil para cualquier repositorio agregar CI, integrar prácticas de DevOps y mejorar la velocidad y la productividad. En este lanzamiento lanzamiento es el primer paso en esa colaboración.

La integración continua impulsa la productividad del desarrollador


El desarrollo de software se basa en el trabajo en equipos y confiamos en nuestros compañeros programadores y escribir juntos el código.

Usamos sistemas de control de código, herramientas y bibliotecas para que podamos centrarnos en el código que necesitamos para escribir. Confiamos en las plataformas en la nube para que podamos desarrollar, probar, ejecutar y administrar nuestras aplicaciones de forma segura, a escala.

DevOps también se basa en la confianza. La confianza es lo que nos permite ir más rápido. Sabemos que los errores  suceden y que aprenderemos de ellos. Creamos una cultura de confianza a través de la transparencia y las decisiones basadas en datos, a través del analisis y control de los datos post mortem para la mejora continua. Usamos la automatización en todas partes, especialmente CI, para crear una red de seguridad. Cloud Build proporciona las herramientas de DevOps para liberar la productividad del desarrollador y ayudar a los equipos a ir más rápido.

Las colaboraciones se basan en la confianza también. Google y GitHub tienen una larga historia de trabajo conjunto para mejorar el desarrollo de software para todos los desarrolladores. En Google tienen una creencia compartida en los principios y prácticas de código abierto y una visión compartida de desarrolladores productivos y equipos de software. Se ha trabajado juntos en mejoras al protocolo y cliente de Git, así como a otros proyectos. Y Google también usa GitHub: los Googlers contribuyeron con cerca de 30,000 repositorios en GitHub el año pasado, algunos de los cuales se encuentran entre los proyectos más populares en GitHub.

Cloud Build y GitHub, mejor juntos


La integración de Cloud Build con GitHub hace que sea rápido adoptar CI y validar los cambios al integrar el código temprano y con frecuencia, añadiendo una serie de beneficios a los desarrolladores, directamente desde su flujo de trabajo de GitHub.

Zero-config Docker: en un solo paso, puede ejecutar compilaciones automáticas de contenedores y pruebas de cambios enviados a un repositorio de GitHub como parte de cada solicitud de extracción. GitHub detectará y recomendará automáticamente CI para los repositorios que contienen un archivo Docker.

Escalabilidad: Cloud Build satisface las crecientes necesidades de su organización. Puede pasar de una compilación única en su máquina local a varias compilaciones en paralelo en la nube en numerosos proyectos, todo en cuestión de minutos.

Seguridad: las compilaciones se ejecutan en una infraestructura protegida por la seguridad de Google. Usted obtiene el control total sobre quién puede crear y ver sus compilaciones, qué código fuente se puede usar y dónde se almacenan sus artefactos de construcción.

Flexibilidad: para casos de uso avanzado, puede incluir un archivo cloudbuild.yaml cuando configure CI utilizando Cloud Build. Esto le permite definir pasos de compilación personalizados, acelerar las compilaciones almacenando en caché una imagen Docker, crear contenedores más ligeros e implementar directamente en Google Kubernetes Engine, Google App Engine, clústeres en premisa (en alfa pronto) u otro proveedor de la nube.

Información: una vez que se completa la compilación, los detalles sobre los tiempos de construcción, y los artefactos están disponibles dentro de GitHub a través de la API Checks, para que pueda comprender y diagnosticar los resultados de la construcción desde el entorno familiar de GitHub. Los registros completos y el historial están disponibles en la interfaz

La integración entre Google cloud y  GitHub ya esta disponible en el Marketplace de GitHub.