¿Por dónde empiezo?
Ahora que hemos sentado las bases de las plataformas de nube, en la Parte 0 de esta serie, publicada hace ya algún tiempo, es hora de remangarse un poco y empezar a crear cosas en Azure.
Hay algunos elementos que debemos preparar antes de crear nuestra primera máquina virtual, pero como veréis no es nada complicado, y de esta forma empezaremos con un entorno ordenadito que no nos traerá problemas en cuanto empecemos a crecer en la nube.
Grupo de afinidad
El primer concepto que quiero introducir hoy es el de “grupo de afinidad”, este debe ser el primer elemento que creamos en nuestra suscripción de Azure y el que sirve de base a todo lo demás.
El grupo de afinidad tiene dos funciones realmente, una a nivel lógico y otra a nivel más físico, relacionada con la asignación de recursos.
A nivel lógico, los grupos de afinidad permiten agrupar recursos de procesamiento y almacenamiento que tienen una relación entre ellos, por ejemplo, el almacenamiento (VHD) que usa una determinada máquina virtual. En una perspectiva un poco más amplia, podemos considerar también un conjunto de máquinas virtuales relacionadas entre ellas, o que comparten alguna característica común, por ejemplo los recursos asignados a un departamento, u organización, en el caso de que gestionemos varias entidades desde una misma suscripción.
Esta sería la parte lógica que nos ayuda a tener la casa ordenada desde el punto de vista del administrador de recursos en la nube. Por otra parte, el grupo de afinidad tiene también unas implicaciones físicas en lo que toca a la asignación y consumo de recursos, como hemos comentado anteriormente.
Los aspectos principales que los grupos de afinidad nos permiten controlar a nivel físico son el rendimiento y los costes. Un grupo de afinidad está asociado a un determinado CPD de Azure, pero como todos sabemos, en Azure los CPDs están constituidos por contenedores con clusters y racks (cada contenedor se encarga de una serie de servicios concretos de la plataforma), por lo que es interesante tener un poquito más de control sobre la colocación de los elementos de nuestra plataforma dentro del mismo.
Por exagerar un poco el ejemplo para que quede del todo claro, seguro que a ninguno se nos ocurriría crear el almacenamiento de una máquina virtual en el CPD de Chicago y ejecutar la máquina virtual en el CPD de Ámsterdam (aunque quisiéramos no sería posible, pero para que se entienda el concepto). Esto generaría una latencia tremenda perjudicando el rendimiento, además de los costes a nivel de comunicaciones, una vez que en Azure se facturan los datos enviados fuera del CPD.
Al colocar los recursos dentro del mismo grupo de afinidad, no solo estamos agrupándolos en términos lógicos pero también le estamos diciendo a Azure que esos recursos deben colocarse los más próximo posible dentro del CPD, si posible en el mismo cluster o contenedor. Esto reduce la latencia y optimiza el rendimiento del entorno.
La creación del grupo de afinidad es bastante sencilla, solo tenemos que darle un nombre, una descripción (opcional), la suscripción asociada e indicar en que CPD de Azure va a “vivir” este grupo de afinidad. Una vez hecho esto, estamos listos para crear los recursos asociados al grupo de afinidad y Azure se encargará del resto.
Creación de grupo de afinidad en Azure
De momento esta opción solo está disponible a través del portal “antiguo” de Azure, el que se encuentra en producción. El nuevo portal está en Preview por lo que es de esperar que, poco a poco, todo vaya encontrando su lugar allí también. La creación del grupo de afiniddad se realiza entrando a Configuración –> Grupos de Afinidad.
Grupos de afinidad en el portal de Azure
Este fue el primer paso en nuestro viaje hacía la nube, en los proximo pasos nos iremos acercando a nuestro objetivo a través del almacenamiento y la red. Espero que disfrutéis del viaje tanto como yo.
Entradas relacionadas:
-
De “nada” a la “nube” en 0, : http://blogs.itpro.es/pdias/2014/03/31/de-nada-a-la-nube-en-0/
Comments ( 2 )
Hola Paulo. Muy interesante tu articulo. Me ha generado una duda: Cuando creas una red virtual, esa por lo que yo he visto, no se asocia al grupo de afinidad, si bien es cierto que la puedes asociara unos sites concretos, como por ejemplo "Europa Oeste" Cunado creas las máquinas y quieres asignarlas a un grupo de afinidad tienes para elegir, bien la ubicacion geografica de microsoft, bien tu red virtual o bien tu Grupo de afinidad. Da la sensacion de que estos dos ultimos elementos quedan desligados. Si es asi (o estoy haciendo algo mal), como afecta esto al rendimiento? Muchas gracias por tu tiempo
Hola, Hubo un cambio a nivel de la definición de redes virtuales en Azure, tras el cual las redes se crean directamente en una de las geografías disponibles. Las redes creadas previamente al cambio, aún conservan la información del grupo de afinidad al que están asociadas, pero esta información solo es visible desde el antiguo portal de gestión, en el Nuevo este dato ya se oculta presentándose solamente la ubicación donde existen. En relación a la colocación de las máquinas virtuales, la decisión de donde asociarlas depende de sus funciones. Si las asociamos a un determinado datacenter, se colocaran ahí pero sin cualquier relación con el resto de servicios que tengamos. Si las conectamos a determinada red virtual, entonces les estamos habilitando la comunicación con otras máquinas que tengamos en esa misma red. Si por ultimo las ponemos en el mismo grupo de afinidad, le estamos pidiendo a Azure que físicamente las ubique cerca del resto de recursos de ese grupo de afinidad, es decir, que intente mantener esas máquinas todas en el mismo cluster/contenedor. De todas formas es muy probable que el concepto de grupo de afinidad acabe desapareciendo con el tiempo, una vez que en el portal nuevo ya no aparece por ninguna parte, y en el antiguo se ha caído de cosas como la red (aunque su existencia en la red era por motivos lógicos, nada más). Saludos, Paulo Dias