Microsoft Azure IaaS: Availability Sets sin alta disponibilidad de los servicios == FAIL

Hace unas semanas, estuve hablando de la importancia de los availability sets y la configuración del balanceo de carga en IaaS. Lo cierto es que estas dos configuraciones deben acompañarse la una a la otra ya que, en caso contrario, podemos pensar que la plataforma de Microsoft Azure se está comportando de manera sospechosa.

Para verlo claro, un escenario común puede ser el siguiente:

Dentro de IaaS, tenemos configurados varios availability sets. Es importante saber que a día de hoy cuando se tienen todas las máquinas dentro de availability sets, no se recibe notificación vía email, informando de que se va a llevar a cabo un mantenimiento de la plataforma y cuáles son los horarios en los que se va a producir el mismo. Este comportamiento tiene su lógica, ya que en teoría todas tus máquinas tienen alta disponibilidad y el impacto es el esperado, al igual que ocurre en PaaS. Un ejemplo de este tipo de notificaciones es el siguiente:

Upcoming maintenance Microsoft Azure

Una vez que el proceso ha finalizado, volvemos a recibir un nuevo correo confirmado que el mantenimiento ha sido completado.

Maintenance completed

La confusión viene cuando tenemos máquinas virtuales con alta disponibilidad (haciendo uso de load-balanced sets), donde el impacto es menor, y se tiene además un conjunto de máquinas dentro de un availability set que no tienen alta disponibilidad y, si una de ellas se cae, no hay otra que se encargue de “tomarla el relevo”, por lo que en ese escenario se perciben dos cosas: por un lado que, al tener las máquinas dentro de availability sets, no se está recibiendo la información relacionada con el mantenimiento y las caídas y, por otro lado, que tenemos unas máquinas sin alta disponibilidad que se están cayendo de manera “aleatoria”, lo cual no es del todo cierto.

Visto este escenario, la conclusión a día de hoy es la siguiente: por un lado es necesario identificar todas aquellas máquinas que no tienen alta disponibilidad y ver si es posible que la tengan y, un segundo punto, desligar aquellas máquinas que no tienen alta disponibilidad de los availability sets, porque no tiene sentido… (A no ser que se me escape algún escenario en el cual máquinas dentro de un availability set necesiten que se actualicen a horas distintas…Sin trabajar en conjunto). Al final necesito saber cuándo van a ocurrir los mantenimientos para aquellas máquinas que no tienen alta disponibilidad, para asumir la caída del servicio y que no pille de sorpresa.

En este post en inglés se detalla el mismo hecho y, si bien es cierto que podría ser necesario recibir dichas notificaciones independientemente de los availability sets que tengamos configurados, creo que la confusión sobre el funcionamiento de esta característica nos está dando algún que otro susto.

Por lo que recordad: Si no hay alta disponibilidad, no se incluye en un availability set.

¡Saludos!

Configurar una red virtual con Microsoft Azure Virtual Networks

En un post anterior mencioné todo lo que está cubierto a día de hoy dentro del apartado Virtual Networks de Microsoft Azure, en un formato para desarrolladores. Hoy me gustaría centrarme en cómo podemos configurar estas redes virtuales dentro de la plataforma.

Una red virtual puede estar compuesta por Cloud Services (Web roles y Worker roles) y Virtual Machines. Para poder crear una tenemos a nuestra disposición un asistente a través del portal, donde podemos definir de forma visual cuáles serán las características de nuestra red. A través del botón NEW, podemos acceder al apartado NETWORK SERVICES y seleccionamos CUSTOM CREATE.

Virtual Network Details

Lo primero que debemos elegir cuando creamos una nueva red virtual es un nombre, el cual no puede contener ni espacios ni comenzar con un número. Por otro lado, es necesario seleccionar o crear un Affinity Group. Los grupos de afinidad son una forma de agrupar los servicios de una suscripción en base a la localización geográfica donde ellos deben encontrarse, con el fin de asegurar que los mismos están cercanos y tienen un rendimiento adecuado. Es altamente recomendable trabajar con estos grupos ya que nos permiten evitar el despliegue de servicios en un datacenter distinto al que se desea (es muy común equivocarse entre dos data center próximos y experimentar problemas de rendimiento, sin darse cuenta de que realmente el problema es la ubicación). Toda red virtual debe pertenecer a un affinity group, con el objetivo de que todos los servicios involucrados estén dentro del mismo datacenter. En este asistente podemos seleccionar uno de los que ya tenemos creados o bien crear uno directamente, seleccionando el nombre del mismo y la ubicación:

1

DNS Servers and VPN Connectivity

En el siguiente punto del asistente existen varias características independientes que podemos configurar:

DNS Servers

Cuando hablamos de la resolución de nombres en la plataforma, Microsoft Azure nos proporciona de manera automática sus propios servidores DNS sin que debamos realizar ninguna gestión o configuración adicional. Sin embargo, dependiendo de nuestras necesidades, podemos configurar un DNS que ya tengamos alojado on premise, para cuando necesitamos tener resolución de nombres entre las máquinas que están en el cloud y las que están en local, o bien podemos subir nuestro propio servidor DNS a la nube. Es posible añadir hasta 12 servidores de DNS. En mi caso, he añadido un servidor que se va a encontrar dentro de mi red virtual:

2

La modificación de los servidores DNS una vez creada la red y añadidas máquinas a la misma está permitido, pero es importante tener en cuenta que en este caso será necesario reiniciar todas las máquinas que estén dentro de esta red para poder obtener la nueva configuración.

Point-to-Site

Como se comentó en un post anterior, Point-to-site nos permite crear una VPN donde los clientes puedan conectarse de manera rápida y ocasional a nuestra red alojada en Microsoft Azure. Esta configuración se puede establecer una vez creada la red virtual, por lo que no es necesario detenerse en ella. En este post sólo voy a centrarme en la red virtual, no en las configuraciones VPN.

Site-to-Site

Una configuración que si es obligatoria durante el asistente es para Site-to-site, por lo que sería necesario aportar los datos en el momento de la creación de la red virtual.

Virtual Network Address Spaces

Este es el punto donde debemos prestar más atención. Para los que somos puramente desarrolladores, puede que sea con el que estemos menos familiarizados, ya que debemos tener en cuenta ciertos valores que normalmente forman parte del cometido de nuestros compañeros de IT.

Para empezar, debemos saber qué tipo de rango de IPs privadas debemos seleccionar:

  • Clase A (10.0.0.0 a 10.255.255.255), la cual se suele utilizar en redes muy grandes.
  • Clase B (172.16.0.0 a 172.16.255.255), para redes de tamaño mediano.
  • Clase C (192.168.0.0 a 192.168.255.255) para aquellas redes más pequeñas.

Lo habitual es que utilicemos el mismo rango que tenemos en local, si tenemos en mente conectar las redes entre ellas. Se puede indicar dentro de ese rango desde qué IP queremos comenzar a contar, modificando el valor de STARTING IP, así como modificar el rango dentro de las clases (En mi caso he alterado el rango 192.168.0.0 por 192.168.1.0). Por otro lado, es importante saber que no es posible crear redes virtuales con IPv6.
Una vez que hemos elegido la clase de rango, debemos también reservar cuántas IPs queremos dentro del mismo, a través del desplegable CIDR (ADDRESS COUNT). Pensando en PaaS, es muy importante seleccionar una rango considerable en función del escalado que se espera para los servicios que se alojarán en esta red.

Por otro lado, también es posible la creación de subnets dentro de nuestra red virtual. No existe un límite establecido en la creación de las mismas, siempre y cuando estén contenidas dentro del rango de IPs elegidas para nuestra red y que no se solapen entre sí. Si llegamos al límite de IPs, al crear la última subnet veremos que la configuración se torna gris, con el objetivo de no permitir que puedan agregar más. Si quisiéramos modificar la cantidad de IPs reservadas para poder crear más subnets, basta con eliminar la última definida y modificar el tamaño de la red.

En la siguiente imagen se muestra cómo quedaría una red configurada dentro del rango 192.168.1.0 con dos subnets llamadas front-end (de 192.168.1.0 a 192.168.1.15) y back-end (de 192.168.1.16 a 192.168.1.31).

3

Si bien es cierto que en la imagen anterior aperecen 32 IPs reservadas, algunas de ellas serán utilizadas por la plataforma para su gestión interna. Por ejemplo, en la primera subnet que abarca desde la IP 192.168.1.0 a 192.168.1.15 se comenzarán a asignar IPs desde la 192.168.1.4.

Añadiendo máquinas dentro de la red virtual

Una vez que hemos finalizado la configuración de la red virtual, ya estamos listos para comenzar a agregar máquinas a la misma. Como comentaba al inicio del post, una red virtual puede estar compuesta por Cloud Services y Virtual Machines. Dependiendo del tipo de servicio que queramos incluir se procederá de una manera u otra:

Virtual Machines

En el caso de las virtual machines, la forma de indicar que una máquina pertenece a una red virtual es a través del asistente de creación de la misma. Para ello debemos elegir el modo FROM GALLERY y en el segundo paso del asistente podremos seleccionar la red en el apartado REGION/AFFINITY GROUP/VIRTUAL NETWORK:

Virtual Machine Configuration wizard

Cloud Services

En el caso de PaaS es necesario añadir la configuración de red a través del archivo ServiceConfiguration.cscfg, utilizando la sección NetworkConfiguration dentro de ServiceConfiguration. Basándonos en la configuración que tiene mi red virtual, una configuración podría ser la siguiente:

  <NetworkConfiguration>
    <VirtualNetworkSite name="gis-virtual-network" />
    <AddressAssignments>
      <InstanceAddress roleName="WebApp">
        <Subnets>
          <Subnet name="front-end" />
        </Subnets>
      </InstanceAddress>
      <InstanceAddress roleName="WebApi">
        <Subnets>
          <Subnet name="front-end" />
        </Subnets>
      </InstanceAddress>
      <InstanceAddress roleName="WorkerRole">
        <Subnets>
          <Subnet name="back-end" />
        </Subnets>
      </InstanceAddress>
    </AddressAssignments>
  </NetworkConfiguration>

Como se puede observar en ninguno de los dos casos especificamos qué IP tendrá cada máquina, debido a que es la propia plataforma las asigna a través de DHCP. Estas direcciones permanecen con la máquina hasta que se detiene y se libera (al seleccionar SHUTDOWN de una máquina se pone en estado Deallocated). Es importante tenerlo en cuenta si una máquina actúa como servidor DNS o como controlador de dominio.
También es importante saber que no es posible modificar el rango de una subred ni eliminarla una vez que se han añadido servicios en ella. Del mismo modo, no se admite la posibilidad de mover servicios dentro y fuera de las redes virtuales. La única forma de incluir o eliminar una máquina es eliminando y volviendo a crear el servicio.

Por ejemplo, si en PaaS intentamos realizar una modificación en la configuración de red para alguno de los roles obtendremos el siguiente error:

A virtual network site cannot be added or removed during deployment update or upgrade

Otro caso que nos puede ocurrir es que intentemos asociar una máquina virtual, ya sea de PaaS o IaaS, a una subred que ya tiene asignadas todas las IPs. En este caso la plataforma nos devolverá un error:

Ejemplo de error en IaaS:

virtual network exceeded allocation

Una vez que hayamos desplegado diferentes máquinas dentro de nuestra red, podremos ver los recursos asociados dentro de la misma en el apartado VIRTUAL NETWORKS, seleccionando nuestra red, en el DASHBOARD:

DASHBOARD virtual network

Espero que sea de utilidad.

¡Saludos!

Acceso remoto a nuestras VM en Microsoft Azure desde Mac OS

2969-1-microsoft-remote-desktop
Como sabéis, cuando queremos acceder a una instancia desplegada en Microsoft Azure, basta con hacer clic en el botón CONNECT para obtener un archivo RDP para el acceso.

Si trabajamos desde Mac OS, cuando tenemos instalado Office para Mac, todos los archivos RDP están asociados de manera predeterminada a Remote Desktop Connection for Mac. Sin embargo, al intentar acceder a las máquinas, he podido comprobar que la aplicación no me permite el acceso, alegando lo siguiente:

Remote desktop connection for Mac

Básicamente, lo que ocurre es que la herramienta no soporta los sistemas operativos Windows Server 2012/Windows 8.1.

Para solucionar este inconveniente, Microsoft desarrolló una nueva aplicación llamada Microsoft Remote Desktop, la cual está disponible en el App Store de forma totalmente gratuita. Esta herramienta apareció en primer lugar para Windows 8 y Windows 8 RT, pero tiempo después se lanzó para otros SO, incluyendo iOS y Android.

Una vez instalada la aplicación, los archivos de tipo RDP se asociarán con la misma y podremos conectarnos con las máquinas Windows Server 2012 alojadas en el cloud.

Microsoft Remote Desktop rdp

Espero que sea de utilidad.

¡Saludos!