La resolución de nombres en Microsoft Azure

La resolución de nombres dentro de una red puede ser una pieza muy importante, sobre todo cuando la asignación de IPs se realiza a través de un DHCP. La plataforma Microsoft Azure nos provee de su propio servidor DNS, el cual nos permite localizar máquinas específicas de nuestra suscripción. En PaaS no tiene mucho sentido, ya que el nombre de las máquinas es aleatorio y la forma de trabajar también es diferente, pero en IaaS elegimos el nombre de cada una de ellas en el momento de la creación, por lo que puede ser útil para alcanzar dicha máquina.

Cuando trabajas con Virtual Networks en Azure tienes dos opciones: Hacer uso del DNS que proporciona la plataforma o bien agregar tu propio servidor DNS para que resuelva los nombres. En el primer caso, es necesario tener las siguientes consideraciones:

1. Cuando creamos las máquinas virtuales, siempre se nos pide que indiquemos el cloud service donde queremos alojarlas. Por defecto está seleccionada siempre la creación de uno nuevo:

Virtual Machine Configuration

Este cloud service básicamente es un contenedor donde se alojan las VMs virtuales y, como se puede ver en la imagen, nos proporciona un DNS público sobre el que trabajar. Si quisiéramos que distintas máquinas de nuestra red virtual se vieran entre sí, utilizando el servidor DNS de la plataforma, es necesario que compartan el mismo cloud service para que el servidor DNS pueda resolver el nombre. Incluso si dos máquinas están en la misma subnet pero en diferentes cloud services, el servidor DNS que provee la plataforma no será capaz de resolverlo, ya que se encuentran en dos espacios DNS diferentes.

Ejemplo: tengo dos máquinas dentro de Azure-FrontEnd llamadas gisazure01 y gisazure07 pero cada una tiene su propio cloud service, por lo que tienen configurados servidores DNS distintos. La máquina gisazure01 está dentro de gisazure01.cloudapp.net y gisazure07 está dentro de efe2azure07.cloudapp.net. No será posible que se vean entre ellas utilizando el DNS proporcionado por la plataforma. Para resolverlo deberíamos incluir las dos máquinas en el mismo cloud service o bien agregar un servidor DNS propio, como te explico en el paso 2 :)

2. Si quisiéramos tener cloud services distintos para nuestras máquinas, necesitamos hacer uso de un servidor DNS externo. Para ello debemos darle ese rol a una de nuestras máquinas virtuales, ya esté alojada en el cloud o bien en un servidor on premise, haciendo uso de una VPN S2S. En este caso, no basta con indicar la IP de una máquina como servidor DNS, sino que también es necesario configurarla y añadir las máquinas en el registro. Para ello, una de tus máquinas tendría que tener el role DNS y configurarlo (Server Manager > Manage > Add roles and Features > Elegir el role DNS Server, agregar la zona, añadir los equipos que queremos resolver y su IP, etcétera).

Una vez instalado, es necesario indicar dentro de la configuración de tu red virtual (apartado CONFIGURE) la IP de la máquina que tiene este rol:

VNET configure DNS Server

Lo ideal sería que esta fuera la primera máquina añadida dentro de la red virtual. En caso contrario, para las máquinas existentes dentro de la red virtual es necesario reiniciar las mismas , para que obtengan la nueva configuración y apunten a este servidor DNS en lugar del que tenían por defecto.

Para comprobar que podemos resolver los nombres de las máquinas podemos hacerlo usando nslookup. Por ejemplo: nslookup gisazure01.gislocal.

Aquí tenéis más información sobre la resolución de nombres en Azure: Azure Name Resolution

¡Saludos!

Actualizar tu Windows Phone a Windows Phone 8.1 a través de Preview for Developers

Después de las novedades anunciadas durante el Build sobre Windows Phone, no es de extrañar que muchos de nosotros tengamos la urgencia de querer instalar en nuestros dispositivos la nueva versión del sistema operativo. En este post voy a contaros cómo he actualizado mi Nokia Lumia 925 en tan solo unos minutos.

Registrarse como desarrollador de App Studio

En este enlace podemos registrarnos como desarrolladores de Windows Phone de tres formas distintas:

Windows Phone Preview for Developers Prerequisites

La primera de ellas está orientada para aquellas personas que quieran subir sus desarrollos al Store, por lo que es necesario el pago de 19 USD. La segunda opción se utiliza para desarrollar y testear aplicaciones en tu propio Windows Phone y no supone ningún coste (para más información sobre App Studio puedes mirar en el sitio official). Por último, tambien podemos descargar las herramientas de desarrollo y desbloquear nuestro dispositivo como herramienta de testing. En mi caso he elegido la segunda opción para poder llevar a cabo el registro.

Descargar la aplicación Preview for Developers

En el siguiente enlace, o bien buscando en el Store, descargamos la aplicación llamada Preview for Developers. Una vez instalada, avanzamos a través de las siguientes pantallas haciendo uso del Live ID que hemos registrado en el paso anterior:

Preview for Developers steps

A partir de este momento podemos acceder a Configuración > Actualizar el teléfono > Buscar actualizaciones para comenzar el proceso de actualización (Es posible que haya que realizar este paso más de una vez).

El resultado:

BlXwOR1CYAEY-mm

Espero que sea de utilidad.

¡Saludos!

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!