Archivo de la etiqueta: azure

Azure AD Privileged Identity Management

Dentro de la suite de seguridad que nos proporciona Azure EMS, encontramos la solución ante una de las dudas que muchos usuarios y administradores del servicio han tenido.

¿Cómo concederíamos acceso administrador o de servicio a nuestro tenant de Office 365 o Azure Active Directory durante un tiempo limitado o mediante revisiones teniendo un registro de auditoría de todo el proceso?

La solución a ese problema se denomina: Azure AD Privileged Identity Management.

En primer lugar, para realizar un deployment de la aplicación en nuestro servicio de Azure AD, son necesarios los siguientes requisitos:

  • Acceso administrador global.
  • Licencia Azure Active Directory Premium Plan 2, la cual podemos activarla de forma independiente o a través del paquete de Azure EMS E5.

Caso de uso

Procedemos a su búsqueda en el portal de Azure y activación. Al realizar el primer acceso, automáticamente aparecerá el Security Wizard, el cual nos guiará para activar los administradores de PIM (Privileged Identity Management), revisar el acceso permanente para los administradores de los diferentes servicios como actualmente o cambiarlos a elegibles, en caso de optar por ésta segunda opción, su administración se realizará a través de diferentes peticiones y con un tiempo limitado.

Una vez que tenemos todo configurado, veremos lo siguiente en nuestro portal:

Vamos a explicar cada uno de las opciones por pasos:

  • Activate my roles: En caso de ser un administrador elegible, podremos activar los roles de administrador al servicio que nos hayan proporcionado indicando la razón de esta necesidad y por defecto, es obligatorio hacer uso de MFA para que los roles puedan ser activados.

Una vez activado, podremos observar la fecha de espiración del rol asignado:

  • Managed privileged roles: Desde esta sección podremos ver un resumen de los diferentes roles de administración que tenemos asignados en nuestro directorio, así como alertas en caso de que los valores en las políticas que hayamos definido se hayan superado, un resumen de auditoría y las diferentes opciones presentes para modificar las políticas que debe de cumplir cada rol.

Desde el historial de auditoría podremos ver el número de activaciones de roles que se ha producido durante el día, así como diferenciar por colores los diferentes roles que tenemos activos en nuestro directorio, pudiendo exportar en todo momento esta auditoría a un fichero .csv para analizar los datos mejor en nuestro cliente preferido:

Desde el apartado de configuración, podremos modificar las políticas de acceso a un determinado rol, en este caso seleccionaremos el de administrador global desde el cual podremos indicar el número de horas que vamos a permitir de acceso (mínimo 30 mins.), enviar emails de las activaciones que se producen por los administradores elegibles a los administradores actuales del directorio, requerir un número de ticket para el usuario que quiere escalar sus privilegios en el directorio y por último y de manera obligatoria, requerir MFA.

En las configuraciones de alertas podremos definir por ejemplo, el trigger con el cual queremos que nos alerte de que nuestro directorio cuenta con > X administradores, etc.

Por último, en las configuraciones de revisiones de acceso podremos definir, notificaciones de emails, recordatorios, requerir una razón para aprobar o denegar el acceso y la duración en días que una revisión de acceso estará disponible.

  • Review privileged access: Desde este último punto, podremos revisar los roles que tenemos pendientes de los usuarios elegibles en caso de que así lo hayamos configurado previamente, podremos seleccionar quién o quiénes serán los revisores y deberemos de aprobar o denegar el acceso de esos administradores elegibles con una razón, por defecto nos enviará emails recordatorios y hemos marcando un tiempo máximo de 30 días.

Conclusiones

Viendo la versatilidad del producto, es importante tenerlo en cuenta para aumentar la seguridad en nuestro directorio activo de Azure, alertarnos de diferentes aspectos de administración e incluso establecer políticas de revisiones de acceso para escalar un rol determinado en nuestro entorno.

Esperemos que os haya gustado el ejemplo de uso en un entorno real.

Azure Service Bus Topics

Otro servicio que ofrece el Service Bus de Azure, junto con las ‘Queues’, ‘Relays’ e ‘Event Hub’ son los ‘Topics’. A diferencia de las queues, donde sólo hay un receptor, en los topics puede haber múltiples. Esto es así debido al sistema que emplea basado en suscripciones, en el cual un topic  puede tener registradas múltiples suscripciones, estando cada una asociada a un receptor. Dicho receptor solo recibirá los mensajes que hayan sido previamente filtrados por la propia suscripción, lo que permite controlar la información que llega a cada receptor atendiendo, por ejemplo, al perfil del mismo.

Instalación

El proceso de instalación o creación es el mismo que el de una Azure Service Bus Queue. Unicamente tener en cuenta que ‘Messaging Tier’ debe estar establecido como mínimo en ‘Standard’, a diferencia de las queues.
La cadena de conexión se recupera de manera análoga.

Funcionamiento

El funcionamiento es muy similar al visto para las ‘queues’, con lo que todo lo comentado para estas se aplican aquí. De esta manera, este servicio es susceptible de ser empleado con diferentes lenguajes (Java, Node.js, .NET, PHP, Ruby o Python). Para los ejemplos se empleará Python.
La gestión de los topics, así como de las suscripciones pueden hacerse asimismo desde el propio portal.

Un código de ejemplo con las operaciones básicas sería el siguiente:

Conclusiones

Como se ha visto, el funcionamiento es muy similar a las colas de Services Bus, con la diferencia fundamental del número de receptores del mensaje. Esta característica, unida a la posibilidad de establecer filtros en cada suscripción, permite un grado de versatilidad con que la anterior estructura de datos no contaba.

Azure Service Bus Queues

Qué es

El Azure Service Bus Queues (ASBQ), al igual que el servicio Azure Queue Storage (se habló de el en este post) hace uso de una estructura de datos basada en cola para el envío de mensajes. A diferencia de este último, el ASBQ no requiere de una Storage Account para su funcionamiento.

Instalación

La instalación es bastante directa y sencilla. Hay que llevarla a cabo desde el portal clásico (ya que desde el portal nuevo, nos redirigirá al primero).

De este modo, en el portal clásico, hay que situarse en “Service Bus” y pinchar en “Create”. Hecho esto, aparecerá una pantalla donde se indicarán los datos del servicio.

Creando ASB 1

Se dará un namespace, el tipo será ‘messaging’, se elegirá el nivel acorde a las necesidades, así como la región (el rendimiento será mejor cuanto más cerca). Una vez creado el servicio, aparecerá en el panel.

ASB creado

Lo último que quedaría por hacer sería anotar la cadena de conexión que posteriormente se empleará en el entorno de desarrollo elegido. Para ello, hay que pinchar en el icono “Connection information”, proporcionando dicha información.

ASB connection info

Funcionamiento

Este servicio puede utilizarse mediante diversos lenguajes (Java, Node.js, .NET, etc), a modo de ejemplo se hará en Python.
La instalación de Python y su correspondiente SDK no presenta complicaciones, habiendo versión para Windows, Linux y MacOS.
Una vez instalado el SDK, ya se está en disposición de crear y eliminar colas, así como introducir mensajes y extraerlos. Cabe señalar que en el propio portal clásico se pueden crear y eliminar colas.

Un código de ejemplo en Python sería el siguiente:

Conclusiones

La modalidad que se ha visto aquí es la más simple (paso de mensajes), pero también presenta otras más elaboradas. Comparándola con la Azure Storage Queue, su utilización es si cabe más sencilla y directa, pero no tan potente y versátil. Todo depende en realidad del uso que se le dé.

Transferencia de datos utilizando Azcopy y Azure CLI

Una operación bastante común en la gestión de una cuenta de almacenamiento o Storage account en Azure es la copia de datos (se trate de un blob, fichero, etc) ya sea entre una cuenta y otra , o bien carga / descarga en local a Azure.
Estas operaciones pueden llevarse a cabo de diferentes maneras, pero aquí voy a centrarme en dos de ellas: AzCopy y Azure CLI. Decir que para los ejemplos sobre este último, se va a emplear el modo ARM, el cual se activa con:

Hay que resaltar que AzCopy resulta mucho más versátil y potente que Azure CLI, lo cual es lógico ya que es una herramienta creada específicamente para este fin, con lo cual contempla más situaciones y cuenta con más parámetros, permitiendo así una configuración mas específica. No obstante, AzCopy solo está disponible para Windows, mientras que Azure CLI es multiplataforma.

Sintaxis básica

Tanto AzCopy como Azure CLI pueden llevar a cabo la copia de blobs y ficheros.
Así, para subir un fichero a un blob y descargar todos los archivos de un blob de un container en Azure CLI en local:

Las opciones disponibles se pueden consultar acudiendo a la ayuda de Azure CLI:

Ayuda storage download Azure CLI

Por su parte, en AzCopy, para la descarga, se admiten más combinaciones más allá de la única descarga de un blob:

Y para la carga de archivos:

Respecto a la copia de blobs entre cuentas, en Azure CLI:

En AzCopy, esta misma operación puede realizarse de forma síncrona (se descarga una copia en local y esta se sube) o asíncrona (por defecto):

Llegados a este punto, a pesar de que Azure CLI también soporta la copia de archivos, al igual que AzCopy, sin embargo, este último también contempla además, otras características, por ejemplo, entre otras:

  • Importación / exportación de tablas en formato CSV o JSON.
  • Uso de un archivo de respuesta: en dicho archivo se permite especificar los parámetros al comando AzCopy, de modo que este los procesa como si hubieran indicado directamente:
  • Carpeta de archivo de diario: esta interesante funcionalidad permite reanudar operaciones inconclusas si detecta la existencia de este archivo.
  • Posibilidad de especificar el número de operaciones simultáneas a iniciar: por defecto, solo se puede llevar a cabo una operación en un mismo equipo. Esto es así para optimizar el uso de los recursos. Para realizar más de una simultáneamente, se emplearía el parámetro ‘/NC’

Conclusiones

Como se dijo al principio, AzCopy es mucho más versátil y potente a la hora de realizar copias. No hay que olvidar que el alcance de Azure CLI es la gestión de los recursos. Aún así, es perfectamente válida para las operaciones de copia habituales debido a su sencillez.

Construyendo una VPN Point-to-Site con autenticación RADIUS y AD en Microsoft Azure

Ya hemos comentado en otras ocasiones en este blog cómo establecemos una VPN Point to Site en Microsoft Azure. Aunque es una forma rápida y versátil de dar a equipos cliente acceso a nuestra red virtual de Azure, lo cierto es que nos enfrentamos a algunas limitaciones que en función del proyecto en que nos encontremos pueden ser todo un stopper para nosotros o nuestro cliente. Concretamente son las siguientes:

  • Sólo admiten 128 clientes como máximo. Como sabéis, las conexiones de App Service cuentan como un cliente.
  • El cliente sólo funciona en Windows 7 o superior (32 y 64 bits). Nos olvidamos de otras plataformas.
  • La autenticación se realiza mediante certificados, no hay nombres de usuario y contraseñas.
  • La comunicación normalmente es en un sentido, del cliente a la infraestructura de Azure y no viceversa.

Si estos puntos no nos suponen un gran problema, el P2S que Azure nos ofrece como servicio es una excelente forma de conectarnos a nuestra red virtual. Pero si resulta que lo es… ¿qué podemos hacer?

Alternativa 1: Máquina Virtual con Windows Server 2012 R2 y RRAS

Es lo primero que se nos viene a la cabeza. Pero no me cansaré de repetir que el rol de RRAS de Windows Server 2012 R2 (y versiones anteriores) no está soportado en Azure. Aunque al instalarlo nos de la sensación de que todo está OK, Azure eventualmente reinicia los adataptadores de red sintéticos asociados a dicha máquina, algo que hace que no sobreviva la configuración que hemos hecho del rol.

Los suficientemente valientes pueden probar a crear un script de autoconfiguración del rol que se ejecute cada vez que se encieda la máquina, pero os encontraréis con que el soporte de PowerShell de este rol es realmente pobre (está pensado para DirectAccess más que para VPN) y no os quedará más remedio que recurrir al viejo amigo netsh. Que la fuerza os acompañe.

Aunque consiguiéramos autoconfigurar la máquina en cada inicio esto es algo que considero bien lejos de ser estable y confiable, por lo que debíamos ir a otra alternativa.

La solución: gateway GNU/Linux con SoftEther VPN

Parece que GNU/Linux no se ve afectado por los cambios de adaptador de red de Azure, algo que nos arroja algo de luz al problema. Acto seguido necesitamos decidir con qué software implementar la solución. Decidí que SoftEther VPN era la mejor. Gracias a esto vamos a superar todas las limitaciones que hemos comentado antes.

¿Qué es SoftEther VPN?

SoftEther VPN es un potente software VPN de código abierto desarrollado por la Universidad de Tsukuba (Japón) que se posiciona como una alternativa poderosa a los sistemas de túneling existentes, ya sean los basados en RRAS de Microsoft o bien el extendido OpenVPN. ¿Qué lo hace tan genial?

  • Multi-protocolo. SoftEther VPN soporta L2TP/IPsec, SSTP, OpenVPN y SSL VPN (a través de un cliente propio).
  • Multi-plataforma, ya que corre bajo Windows, OSX, Linux, FreeBSD y Solaris.
  • Multi-arquitectura, soportando x86, x64, ARM, MIPS, SH-4, PowerPC y SPARC.
  • Multi-authentication backend: soportando usuarios y contraseñas locales, certificados X.509, Active Directory (sólo Windows) y RADIUS.

Como podéis ver se trata de un completísimo sistema de VPN que soporta prácticamente todo lo que podamos imaginar.

Autenticando con Active Directory

Os habrá llamado la atención que SoftEther VPN soporta Active Directory como backend de autenticación, pero lamentablemente sólo en el caso de que estemos ejecutando el servidor bajo Windows. Esto en Azure nos devolvería a la casilla de salida, así que tenemos que asumir que estamos en Linux. Sin embargo, en la lista también estaba RADIUS. ¿Tiene Microsoft algún servidor RADIUS que nos haga de pasarela a la autenticación de ADDS? ¡Sí! ¡El Network Policy Server! NPS para los amigos.

Nuestra arquitectura a alto nivel sería la siguiente:

gaw1

Así que dicho y hecho, nuestro escenario de demo se va a componer de tres máquinas en Azure:

  • SoftEther VPN (Linux)
  • NPS + ADDS (Windows)
  • App Server (no es indiferente el sistema operativo).

La última máquina de la lista es solo para comprobar conectividades y representa nuestra infraestructura en Azure.

Inyectando a nuestros clientes VPN P2S en la red de Azure: el adaptador de red TAP de Linux

Uno de los grandes problemas que nos podemos encontrar a la hora de conectar clientes a nuestra red virtual de Azure es que esta no es precisamente muy amiga de eso. Una red virtual de Azure se encuentra gobernada por el DHCP que Microsoft instaura en ella y por tanto si intentamos conectarlos a través de la máquina virtual que hemos desplegado, no obtendremos ningún resultado satisfactorio.

Aquí entra en juego otra de esas capacidades de Linux que hace que nos maravillemos con él cada vez que hacemos temas de networking: el adaptador de red virtual TAP. Este adaptador de red es una interfaz virtual que se encuentra integrada en el kernel de Linux y que puede ser desplegada por las aplicaciones que lo requieran. Tiene infinidad de usos en software de tunneling y virtualización.

Cuando desplegamos el adaptador, obtenemos algo similar a esto:

gaw3

Como se puede ver en la imagen, la máquina virtual de SoftEther se encuentra dentro de la red virtual de Azure, y así lo refleja el adaptador eth0. Pero… ¿y si creamos un nuevo adaptador TAP? Llamémosle tap_vpn0. Este adaptador virtual no se encuentra realmente dentro de Azure: no ve la red virtual, el DHCP de Azure no tiene efecto sobre él y es agnóstico a nuestro entorno. ¡Es el candidato perfecto para unir nuestros clientes P2S!

Sin embargo, una vez unidos los clientes a este adaptador, debemos establecer comunicación con la red virtual de Azure. Esto lo podemos conseguir fácilmente convirtiendo nuestra máquina Linux en un router a su vez (ya sabéis, activar IP forwarding como hemos comentado otras veces). De esta manera el dibujo se convierte en el siguiente:

gaw2

User Defined Routes e IP forwarding a nivel de Azure

Hecho esto, necesitamos que Azure sepa a qué gateway enviar el tráfico dirigido a los clientes VPN y permitir que esa máquina acepte tráfico que no es necesariamente para ella. A día de hoy, esto es perfectamente posible:

  • User Defined Routes (UDR). No es ni más ni menos que una definición de tablas de rutas en una red virtual de Azure. Nos permite dirigir el tráfico a donde nos interese. Este tema merecerá un artículo del blog en exclusiva.
  • IP ForwardingFundamental si usamos tablas de rutas y enviamos el tráfico a una máquina virtual, ya que por defecto está no aceptará ningún packete de red en el que ella no sea la destinataria.
El resultado

Tras todo el proceso deberíamos tener operativo todo un hub de conexiones VPN que además nos permite superar las limitaciones que comentábamos al inicio del artículo.

gaw4

El resumen y To-Do list

Como el artículo ha constituido una explicación de alto nivel de cómo conseguir en Azure una VPN P2S autenticada mediante ADDS, os dejo con una serie de pasos de alto nivel para hacer la solución más fácil de seguir:

  1. Crear una nueva red virtual de Azure y asignarle un direccionamiento. En nuestro ejemplo 172.16.0.0/24.
  2. Crear máquinas para hospedar los siguientes servicios: SoftEther VPN (Linux), NPS (Windows), ADDS (Windows). Configurar todas las IPs privadas como estáticas.
  3. Configurar SoftEther VPN de la siguiente manera:
    1. Local Bridge hacia un adaptador TAP.
    2. Autenticación basada en RADIUS contra el servidor NPS.
    3. Activar protocolos L2TP/IPsec y SSTP. Opcionalmente podemos activar OpenVPN.
    4. Generar los certificados necesarios para SSTP y distribuirlos en los clientes que vayan a acceder. Recuerda que deben coincidir con el nombre del dominio al que conectas.
  4. Elegir un direccionamiento para nuestro adaptador TAP y asignarle una IP dentro de ese direccionamiento. En nuestro ejemplo 172.17.0.0/24 y el adaptador 172.17.0.1.
  5. Instalar y configurar un servidor DHCP (a mi me encanta dnsmasqque debe ejecutarse tras arrancar SoftEther VPN para que exista la interfaz TAP. Esto es importante porque sólo debe estar enlazado (binding) a la interfaz TAP y NUNCA a eth0, donde entraría en conflicto con el de Azure. Debe servir IPs en el rango del adaptador TAP.
  6. Activar IP forwarding en la máquina Linux en /etc/sysctl.conf.
  7. Activar IP forwarding a nivel de Azure en la máquina virtual Linux.
  8. Crear una UDR que haga que el tráfico para 172.17.0.0/24 se dirija a la IP privada de la máquina virtual con SoftEther.
  9. ¡Listos para funcionar!
Explicándolo en directo

Alberto Marcos y servidor explicamos y demostramos todo esto en directo en la Global Azure Bootcamp 2016. Si te la perdiste tienes la oportunidad de ver en HD la grabación de la sesión justo aquí: https://channel9.msdn.com/Events/Microsoft-Spain-Events/Global-Azure-BootCamp-2016/Construyendo-una-VPN-Point-to-Site-con-autenticacin-RADIUS-y-AD-en-Microsoft-Azure

Happy networking!

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.

Gestión, uso y aplicación de Azure Storage Queue

El Azure Queue storage es un servicio cuyo objetivo consiste en el almacenamiento de un gran número de mensajes, los cuales pueden ser accedidos desde cualquier lugar a través de llamadas autenticadas mediante HTTP o HTTPS. Para llevar a cabo este almacenamiento se emplea una estructura de datos basada en la cola.

Creación de una cola en Azure

El primer paso para poder utilizar una cola de empieza por la creación de una storage account. Este proceso no conlleva dificultad alguna y es bastante dirigido. Lo primero que hay que hacer es entrar en el portal de azure, y después pulsar en New > Data + Storage > Storage Account

azure storage account 1

A continuación nos solicitarán los diversos datos de la storage account, nombre, tipo de localización, etc. Un punto muy importante a tener en cuenta es la selección del modo de creación de la cuenta: modo clásico o modo RM (resource manager), ya que la gestión y uso de las colas de momento no es posible hacerla en Powershell en modo RM, pero sí en modo clásico.

Una vez creada la cuenta, aparte de las colas, contamos con servicios de ficheros, tablas y blobs.

azure storage account 2Y entre la información que nos ofrece el panel de nuestra storage account creada sobre las colas, todo lo necesario (nombre de la cuenta, claves de acceso y cadenas de conexión) para poder acceder a este recurso externamente.

azure storage account 3

Gestión de la storage account en Powershell

Hay que diferenciar aquí lo que se puede hacer en modo clásico o modo RM. En ambos modos, se pueden llevar a cabo las siguientes operaciones sobre la cuenta:

  • Creación.
  • Eliminación.

El modo RM permite además de otras cosas, por ejemplo, regenerar la storage key de una cuenta

Uso de las colas

En lo que se refiere al uso del servicio de las colas (creación, eliminación), así como las operaciones típicas sobre estas (inserción de un mensaje, extracción…), solo es posible hacerlo en modo clásico, puesto que en el modo RM no hay cmdlet disponibles de momento para ello. En los ejemplo se muestran los mismos.

Ejemplos

Como ejemplos sencillos de creación, inserción de un elemento, extracción del mismo y eliminación de una cola, tendríamos los siguientes:

En .NET, puede actuar indistintamente sobre una storage account creada en modo clásico o RM:

En Powershell, sólo se puede utilizar una cola creada de una storage account creada en modo clásico:

Y esto es todo por mi parte. Espero haber mostrado un poco este servicio y las posibilidades del mismo.