Uso y gestión de Azure IoT Hub

Introducción al Azure IoT Hub

El Azure IoT (Internet of Things) Hub es un servicio que permite gestionar, controlar y monitorizar dispositivos o unidades mediante el uso de mensajes. Cada dispositivo puede tener conectados multitud de sensores, los cuales a su vez son objeto de monitorización. Este servicio por lo tanto centraliza toda esa información, y permite su posterior tratamiento o gestión.

Creación del recurso en el portal de Azure

La creación del Azure IoT Hub es bastante sencilla y directa. Basta con seleccionar la app del menú (New > Internet of Things > Azure IoT Hub). Se rellenan los datos, y se selecciona el nivel de servicio.

Azure IoT nuevo Hub

Para este ejemplo, se ha empleado el nivel F1 Free, que sólo contempla la monitorización de una unidad y un máximo de 8000 mensajes al día.

Desde el panel de control, se muestran los datos del servicio, como el grupo de recurso al que pertenece, el hostname, el nivel de servicio contratado, etc. También se pueden ver el uso de las unidades así como su monitorización.

Azure IoH dashboard

Por otra parte, otro dato esencial para llevar a cabo la conexión desde la aplicación que se desarrolle con el Hub es la cadena de conexión, la cual se puede consultar en el icono de la llave del panel de control.

Azure IoT Keys

Aplicaciones y uso

El objetivo principal de este servicio es el control y monitorización de dispositivos o unidades mediante el uso de mensajes. Para llevar a cabo dicha tarea, existen una serie de herramientas:

  • Windows: la herramienta Device Explorer permite monitorizar todas las unidades, así como enviar y recibir mensajes desde y hacia los dispositivos. Para su configuración solo requiere indicar la cadena de conexión y la clave principal del Azure IoT Hub creado.

Device Explorer

  • Linux: en este caso se dispone del iothub-explorer, herramienta de tipo CLI que requiere de Node.js para su funcionamiento.

iothub_explorer

Ejemplo

Para ilustrar todo lo anterior, se propone un ejemplo, bajo Windows, donde un programa simula un anemómetro (representa el dispositivo), el cual envia mensajes periódicamente al IoT Hub. Con el Device Explorer se monitorizan dichos mensajes, en forma de eventos.

El código del simulador en C# es el siguiente:

Y al ejecutarse, el Device Explorer recoge los mensajes enviados del dispositivo al Hub:

Simulador anemometro 2

Conclusiones

Evidentemente, las posibilidades del Azure IoT Hub van mucho más allá de lo expuesto aquí. Supone el punto de partida para otros servicios IoT, como por ejemplo el Event Hub, el cual permite la telemetría de datos (de una manera más específica) provenientes de apps, websites o dispositivos.

Esto es todo por mi parte. Hasta el próximo post.

Migrando de Azure Classic (ASM) a Azure Resource Manager (ARM)

Aunque esta publicación la materializa servidor, he de comentar que es un trabajo del equipo completo de Enterprise IT de Plain Concepts, donde todos y cada uno de nosotros estuvimos involucrados con las distintas tareas que voy a comentar aquí.

Llevamos ya unos cuántos meses contándoos la potencia y enormes ventajas del nuevo modelo de recursos de Azure, que cambia nuestra forma de entender y trabajar con la plataforma… y lo hace para muy bien. Sin embargo, hacemos una confesión pública en estas líneas: el core de la infraestructura de Plain Concepts aún se encontraba en el modelo clásico. Y es que aunque seguimos totalmente un modelo customer first, lo coherente es predicar con el ejemplo, mas sea dicho que estábamos ansiosos de disponer de todas las ventajas de ARM en nuestro entorno productivo.

No queriendo dilatar más la situación planificamos la migración de toda la infraestructura. ¿Cómo procedimos a ello? Es justamente lo que os voy a contar en esta publicación.

¿Qué servicios necesitan migrarse?

Los servicios sobre los que vamos a tener que trabajar son sobre todo los basados en IaaS y todos los que de alguna manera estén relacionados con los mismos. A continuación os voy a enumerar los más importantes:

  • Storage Accounts.
  • Virtual Machines.
  • Virtual Networks, incluyendo gateways, network security groups, reservas de direcciones IP, etc…
  • Cloud Services. Cuidado aquí, porque si estáis utilizando máquinas virtuales auto-escaladas debéis pasar a utilizar los Azure VM Scale-Sets, que quedan fuera del ámbito de este artículo.
  • Traffic Manager.
  • Backup.

La mayor parte de los servicios basados en PaaS no necesitan atención alguna, ya que automáticamente pasan a beneficiarse del modelo ARM. Entre estos servicios encontramos App Service o SQL Database.

También es interesante mencionar servicios que de momento sólo funcionan en el modo clásico, como StorSimple o Azure Site Recovery.

Estrategias de migración

Muchos ya habréis adivinado lo que voy a comentar a continuación: no hay un botón mágico ni una forma automatizada de mover servicios entre ASM (modo clásico) y ARM. Por tanto, cuando afrontamos un movimiento implica crear de nuevo el servicio en ARM y mover toda la información en un proceso bastante manual.

Hay dos formas de afrontar la migración:

  • Utilizar los scripts de PowerShell de FullScale180 que Microsoft menciona en su documentación oficial. Estos se encuentran en un repositorio de GitHub, justamente aquí.
  • Preparar nosotros mismos un proceso adaptado a las necesidades del entorno.

Después de examinar los scripts y reconocer el enorme trabajo que se llevó a cabo con los mismos, decidimos que era mejor optar por llevar a cabo el proceso de forma manual, fundamentalmente motivados por tener un mayor control.  Los scripts migran una única máquina virtual por ejecución y realizan una serie de asunciones sobre las redes virtuales, los network security groups y los discos que preferíamos tener más controlados. ¡No obstante no dejes de echarles un vistazo por si se adaptan a tus necesidades y te ahorran mucho trabajo!

Para nuestra migración nos marcamos una serie de requisitos:

  • Copiar el entorno 1:1, es decir un clon idéntico del que tenemos en ASM. Esto implica que no vamos a redesplegar y reconfigurar servicios.
  • Como consecuencia del punto anterior, debe mantener el mismo direccionamiento IP y subredes que ya teníamos definidas en la red virtual de ASM.
  • Como no podía ser de otra forma, también debemos tener una configuración similar en la puerta de enlace VPN que creemos en el servicio.

Estos requisitos nos llevan a una estrategia de irremediable corte de servicio, planificado a una hora fuera de oficina. Con otro tipo de requisitos podríamos hacer el movimiento sin prácticamente ningún corte. Y con estos puntos en mente ya podíamos elaborar nuestro backlog particular.

El backlog

Que a alto nivel consistía en lo siguiente:

  1. Asegurarnos de que tenemos acceso administrativo a Azure y Office 365 sin necesidad de ADFS. Dado que nuestros ADFS se encuentran en Azure y ASM, siendo parte de la infraestructura que vamos a migrar, sería muy divertido apagarlos y que se nos cierre o caduque la sesión que tenemos abierta.
  2. Crear el o los grupos de recursos de ARM donde vamos a alojar todos los nuevos elementos de nuestra infraestructura.
  3. Crear las Storage Account necesarias en ARM, tanto las estándar como las premium.
  4. Crear la red virtual en ARM y configurarle el direccionamiento análogo al que ya teníamos en ASM.
  5. Realizar el corte de servicio fuera de oficina y comenzar con la intervención oficial.
  6. Copiar todos los VHDs de las máquinas virtuales existentes de las Storage Account ASM a ARM.
  7. Crear en ARM las máquinas virtuales utilizando los discos que hemos copiado en el paso 6.
  8. Crear los balanceadores de carga internos y externos.
  9. Restablecer las conexiones Site to Site con las distintas localizaciones on-premises de Plain Concepts.
  10. Realizar los cambios DNS oportunos.
  11. Comprobar el funcionamiento del entorno.

Copiando VHDs entre ASM y ARM

La primera tarea es una de las más triviales, pero quizás la que más dolor de cabeza nos dio. Consiste en copiar los VHDs de las máquinas virtuales de una Storage Account basada en ASM a otra que lo esté en ARM. Ambas cuentas de almacenamiento operan de forma indistinta y por tanto se utilizan igual. La herramienta altamente recomendada para esta tarea es AzCopy, que realiza una copia asíncrona entre las cuentas sin necesidad de descargárnosla a nuestra máquina. Su sintaxis es extremadamente simple:

¿Qué nos dio dolor de cabeza? Que la copia fue más lenta de lo que habíamos estimado originalmente, cosa que no nos ocurrió con todas nuestras Storage Account. Es posible, que tal y como advierte TheCodeJunkie es este post, estuviéramos trabajando sobre una Storage Account muy antigua que no tenía ciertas capacidades, pero es un tema en el que no entramos en profundidad. Nos tocó ser pacientes sin más.

Como detalle recordad que copiamos discos y no plantillas de máquinas virtuales. No se trata de imágenes con sysprep aplicado.

Creando máquinas virtuales con nuestro disco como disco del sistema

Cuando ya tenemos nuestros discos en la Storage Account ARM, podemos proceder a crear las máquinas virtuales. Sin embargo, lo primero con lo que nos encontramos es que a día de hoy no hay ninguna opción en el portal para crear una máquina virtual ARM utilizando un disco existente en lugar de las plantillas de la galería. Afortunadamente, la capacidad sí que se encuentra ahí y podemos utilizarla, sólo que para ello tendremos que utilizar una plantilla JSON.

Si vamos al repositorio GitHub de la Azure Quickstart Templates, encontraremos una que nos llama mucho la atención: 101-vm-from-user-image. ¡Justo lo que necesitamos! Si examinamos la plantilla veremos que promete, pero que se nos queda corta para nuestras necesidades debido a que:

  • Está preparada para crear una máquina virtual desde una imagen con sysprep a modo de plantilla, no una VM ya existente.
  • Crea una red virtual por cada máquina que creemos.
  • No especifica dirección IP privada para la máquina.
  • No especifica Storage Account para los diagnósticos.
  • No especifica grupo de disponibilidad.
  • Los nombres de los recursos no se adaptan a nuestra nomeclatura.

¡Pero esto no es ningún problema! La plantilla nos da un estupendo punto de partida para modificarla y adaptarla a nuestras necesidades, que tras pasar por nuestro particular taller quedó así:

ATENCIÓN: Esta plantilla está preparada para máquinas de un solo disco (el del sistema). Necesita una ligera adaptación muy trivial para máquinas donde se usa más de un disco para que estos se desplieguen junto con el resto. ¿Y no nos valdría esta plantilla y ya adjuntamos el resto de discos después? La respuesta es NO. La razón es que al introducir la plantilla en Azure y ejecutarla, este aprovisiona la VM y la arranca. Si al arrancar el sistema no encuentra las unidades donde espera encontrar datos –como por ejemplo, las bases de datos de un controlador de dominio-, la máquina se puede volver inconsistente, pudiendo llegar a perderla.

Aplicando plantillas JSON en Azure

Nada más sencillo que acudir al portal y buscar el elemento Template deployment.

image

Tras lo cual copiamos y pegamos nuestra plantilla en el editor de texto:

image

Tras guardar la plantilla, Azure comprobará que la sintaxis JSON es correcta y en caso afirmativo, nos permitirá pasar a los parámetros. Que quedan tal y como hemos definido:

image

Y tras ello Azure comenzará con el trabajo de implementación de la máquina. Como comentamos en otra ocasión, la potencia de ARM nos permitirá guardar la plantilla que generamos para futuros usos. Es importante reseñar que pueden producirse errores de ejecución en la plantilla, que solo veremos al aplicarla (ej: nombres de recursos que ya se encuentran en uso). Si tenemos el infortunio de caer en esta situación, no tendremos más remedio que eliminar manualmente los elementos creados (o bien el grupo de recursos si trabajábamos de nuevas con él) y comenzar de nuevo.

Conclusiones

Mover infraestructura de ASM a ARM no es a día de hoy un trabajo automático y requiere de un extenso análisis y elaboración de estrategia en función del tamaño y la criticidad del entorno. Las ventajas del movimiento a ARM son evidentes y hacen que en la mayoría de los casos compense el esfuerzo. Por otro lado y desde el punto de vista de seguridad, dado que nunca eliminamos en el entorno original de ASM, siempre existe la posibilidad de hacer rollback si las cosas llegasen a ponerse muy feas durante el proceso.

¿Te ha resultado interesante? ¡Déjanos un comentario si nos quieres decir algo!

Happy ARMing!

Configurar un ILB con PowerShell en Azure Resource Manager

De acuerdo con la documentación de azure, tenemos no una ni dos, sino cuatro formas distintas de definir un balanceador interno de carga en Azure Resource Manager desde cero. Ahora bien, ¿qué sucede cuando ya se tiene infraestructura desplegada y se desea balancear?

Antes de nada… ¿qué es un balanceador interno?

Un ILB (siglas en inglés) proporciona balanceo de carga de red entre máquinas virtuales que residan en la misma red virtual de Azure. Este servicio permite la creación de servicios configurados en alta disponibilidad, de forma que, ante picos elevados de carga, el trabajo se distribuye equitativamente entre los miembros del grupo balanceado. Igualmente, en caso de que alguna máquina del grupo balanceado deje de funcionar, ya sea por tareas de mantenimiento, error de configuración, o fallo de la máquina virtual, el balanceador detecta que la máquina afectada ya no está disponible, y de forma dinámica redistribuye la carga entre el resto de máquinas virtuales del grupo balanceado.

Un escenario básico se correspondería con el siguiente diagrama:

ilb

Se tienen dos máquinas que actúan como servidor Web, dos interfaces de red, el balanceador de carga, y una IP privada que es donde se van a recibir todas las peticiones de servicio.

Descripción del escenario propuesto:

Se tiene un servidor web linux, que está proporcionando un servicio, pero se desea cambiar la configuración “servidor único” por una configuración balanceada, para obtener los beneficios de reducir la carga del servicio en la máquina original, así como conseguir tener una infraestructura más resistente a fallos.

En este caso, una opción sencilla es desplegar una máquina idéntica a la máquina original, y configurar el balanceo de carga a posteriori.

Para asegurarse de que la segunda máquina es una copia idéntica de la primera, es posible utilizar un software como rsync.

Así pues, en este escenario tenemos ya dos máquinas virtuales, con sus correspondientes interfaces de red, y todo está ya funcionando. Sólo falta balancear el sistema.

Paso a paso

En primer lugar, toca iniciar sesión en Azure. En el ejemplo, mi cuenta sólo está adscrita a una suscripción de Azure. En caso de que estuviese dado de alta en más de una, habría que usar los cmdlets “Get-Azure-RmSubscription” y“Select-AzureRmSubscription” para determinar el ID de la subscripción que se desea utilizar, y así poder seleccionarla.

login_vm

Como las máquinas virtuales ya existen, pertenecen a una red virtual de Azure. En este caso, tendremos que averiguar en qué red están con el cmdlet “get-AzureRmVirtualNetwork”. Este cmdlet nos permite seleccionar la red virtual en la que están las máquinas virtuales, y así poder trabajar con sus subredes.

De esta forma, se puede crear la IP de frontend que va a definir el punto de entrada de las solicitudes del servicio balanceado. A continuación, se crea el backend que recibe el tráfico del frontend.

 

createFrontEndBackEnd

Una vez se ha creado todo lo necesario, se puede proceder a crear el balanceador de carga:

ilb-ps

Ahora es cuando empieza lo interesante: Se tienen las máquinas virtuales, las interfaces de red, y el balanceador de carga. Toca ir juntando las piezas para formar el puzzle.

Se obtiene la configuración de cada interfaz de red de las VM, y se le asigna el backend del balanceador de carga. A continuación, se guarda la configuración de la interfaz de red, y con esto se asigna dicha interfaz al balanceador de carga interno:

setInterface

Una vez asignadas ambas interfaces, el balanceador de carga interno estará listo para su uso.

Desde el portal de Azure se puede examinar la configuración del balanceador.

backend

Y finalmente llega la prueba de fuego: testear el servicio balanceado. Como las máquinas son servidores linux, la forma más sencilla de hacerlo es editar la página de inicio de Apache con versiones diferentes de la web, de forma que la respuesta que devuelve cada servidor sea diferente. En este caso, se ha optado por hacer que cada máquina devuelva “server1” o “server2” dependiendo de cuál de ellos está sirviendo la respuesta.

balanceado

En esta prueba, primero se hace una conexión en local al servidor, a ver de qué máquina se trata, y a continuación se hace una petición al ILB, para ver qué máquina nos está respondiendo. Se puede ver que, en cada caso, la respuesta la devuelve una máquina distinta, así que el balanceador funciona correctamente.

Al ser un servicio balanceado, en caso de que uno de los servidores deje de funcionar, la sonda se encargará de determinar en un intervalo máximo de 45 segundos que la máquina afectada no debe de seguir dando servicio (en el caso de que la máquina falle justo después de una sonda, ésta ha de fallar dos veces consecutivas para que el ILB deje de usarla para servir respuestas, en un intervalo de 15 segundos entre cada sondeo).

Conclusiones

De esta forma, se puede configurar un servicio balanceado usando PowerShell. Hay documentación que automatiza el proceso incluyendo la creación de servidores e interfaces de red. Actualmente, ése es un proceso muy interesante si tenemos en cuenta que actualmente hay una limitación muy importante en la configuración de los balanceadores de carga, y que se describe en la siguiente sección.

A continuación, se adjunta un script que resume los pasos llevados a cabo para montar el servicio.

script

Limitaciones actuales

Ambas máquinas deben estar en el mismo grupo de disponibilidad. En el modo clásico, se pueden añadir o quitar libremente máquinas virtuales de un grupo, pero en modo Resource Manager, aún no hay soporte para ello. En caso de que ambas máquinas no estén en el mismo grupo de disponibilidad (Availability Set), aparecerá un mensaje de error similar a este:

different-availabilitySet

En el modo Service Manager de Azure, sí que es posible asignar una VM a un Availability Set sin ningún tipo de problema. Cabe esperar que en un futuro próximo esta funcionalidad también esté disponible en el modo Resource Manager.