Archivo de la etiqueta: evento

Evento: Conectando Microsoft Azure con Amazon Web Services (Almería)

¡El próximo jueves 18 de febrero vuelvo a las tierras del sur donde estaré dando una reedición de la sesión que Alberto Marcos y servidor dimos en el Global Azure BootCamp 2015!

  • Título: Conectando Microsoft Azure con Amazon Web Services
  • Fecha: jueves, 18 de febrero de 2016
  • Hora:  12:15 – 14:15
  • Ubicación: Sala de Grados del Edificio de Gobierno – Universidad de Almería, Almería
  • Abstract: ¡Microsoft Azure y Amazon Web Services pueden vivir juntos! En esta charla mostraré cómo podemos establecer un escenario híbrido que nos permita conectar ambas plataformas de cloud computing y una serie de escenarios de ejemplo donde podemos aprovechar esta integración.
  • Registro: No es necesario registrarse, ¡entrada libre!
  • Ponente: Carlos Milán Figueredo – Enterprise Team Lead (Plain Concepts)

¡Allí os espero!

Webinar: Balanceo de carga en entornos híbridos con KEMP y Azure

Soy consciente de que avisamos con muy poca antelación, pero a posteriori estará disponible la grabación del evento que podréis ver con tranquilidad.

  • Título: Balanceo de carga en entornos híbridos con KEMP Technologies y Microsoft Azure
  • Fecha: martes, 12 de enero de 2015
  • Hora:  11:00 – 12:00
  • Ubicación: Webinar online
  • Abstract: En este webinar usted será capaz de comprender las ventajas que le ofrece la nube de Microsoft con MS Azure y a su vez solucionar las principales dudas que surgen al cambiar a un escenario híbrido gracias al balanceo de carga en entornos híbridos junto con KEMP Technologies.
  • Registro : Enlace de acceso
  • Ponente: Carlos Milán Figueredo – Enterprise Team Lead (Plain Concepts)

¡No os perdáis tampoco el post de Antonio López Márquez sobre cómo mander notificaciones Push a móviles desde PowerShell!

Evento: Workshop de Introducción a Azure – Universidad de Almería

El próximo viernes 4 de diciembre servidor va estar por Almería, iniciando el puente de la Constitución Española de la mejor forma posible: dando un completo Workshop de Introducción a Microsoft Azure en la Universidad de Almería. Tanto si no conoces Azure como si quieres descubrir algunas de sus novedades más destacadas como el Azure Resource Manager, ¡no dejes de visitarnos si te encuentras por la zona!

  • Título: Workshop: Introducción a Microsoft Azure
  • Fecha: viernes 4 de diciembre de 2015
  • Hora:  11:15 – 14:00
  • Ubicación: Aula mac – CITE III – Universidad de Almería – Almería
  • Abstract:
    • Presentación y Plain Concepts: ¿quiénes somos?
    • Introducción al Cloud Computing
    • El nuevo paradigma de la computación y la infraestructura
    • Introducción a Microsoft Azure
    • Networking: las redes son serious business en Azure.
    • Máquinas virtuales, cuestiones de rendimiento.
    • DEMO
    • Una nueva etapa en Microsoft Azure: Azure Resource Manager
    • Diferencias entre el Azure Classic Mode y el Azure Resource Manager
    • Azure VM Scale Sets
    • DEMO: Desplegando infraestructura mediante plantillas JSON y DSC
    • Gestionando la identidad corporativa: Azure Active Directory, la federación, el SSO y la autenticación basada en claims
    • DEMO
    • Intercambio de opiniones y debate
  • Registro : Enlace de acceso
  • Ponente: Carlos Milán Figueredo – Enterprise Team Lead (Plain Concepts)

Evento: la Teoría de la Evolución en la nube, novedades de Azure

¡Alberto Marcos y servidor, Carlos Milán- volvemos a la carga en los escenarios de Microsoft Ibérica, donde vamos a participar en una interesante jornada sobre distintas novedades de Microsoft Azure que se han acontecido en los últimos meses. En este caso, hablaremos de lo último de Azure Active Directory, incluyendo su nueva vertiente Bussiness to Consumer (AAD B2C) ¡Registro gratuito, no te lo pierdas!

  • Título: Identificando a los protagonista de la transformación (Azure AD B2B y Azure AD B2C)
  • Fecha: miércoles, 2 de diciembre de 2015
  • Hora:  10:30 – 11:15 (evento total de 9:15 a 14:00)
  • Ubicación: CIFF Universidad de Alcalá – Calle María de Molina, 27, 28006
  • Abstract: La singularidad tecnológica puede suponer una ruptura en el concepto de evolución que tenemos hasta la fecha. Sin embargo, hasta ese momento aún es necesario disponer del mejor equipo de personas a nuestro alrededor. A la hora de gestionar nuestros recursos uno de las necesidades más importantes es contar con una solución completa de gestión de la identidad como Azure Active Directory. Pero no solo eso, nuestro trabajo no solo se limita a nuestra empresa; la colaboración es clave para avanzar. Soluciones como Azure AD Business to Business o Bussiness to Consumers proporcionan el sistema de gestión perfecto para gestionar la identidad entre diferentes empresas o con diferentes proveedores.
  • Registro : Enlace de acceso
  • Ponentes:
    • Alberto Marcos González – Solution Specialist (Microsoft)
    • Carlos Milán Figueredo – Enterprise Team Lead (Plain Concepts)

Evento : SIMO Educación – Office 365 Híbrido: ven a la nube sin despegar los pies del suelo

Continuando con la agenda de eventos en el mes de Octubre. En esta ocasión,  Plain Concepts estará presente en  el salón de tecnología para la enseñanza SIMO Educación para poder hablar sobre una de las particularidades de Office 365 híbrido, el movimiento de buzonesde tu máquina local a Office 365 y viceversa .

¡Te esperamos en el stand de Microsoft!

  • Título: Office 365 Híbrido: ven a la nube sin despegar los pies del suelo
  • Fecha:  días 28,29 y 30 de Octubre de 2015
  • Hora:  
    • Miércoles 28 de Octubre de 16:00 a 16:20 CET
    • Jueves 29 de Octubre : 10:30 a 10:50 CET
    • Viernes 30 de Octubre : 15:30-15:50 CET
  • Ubicación: Stand de Microsoft – SIMO Educación : Parque Ferial Juan Carlos I – 28042  Madrid
  • Idioma: Español
  • Abstract: ¿Quieres moverte a la nube de forma gradual y a tu propio ritmo? ¡Te enseñamos como mediante un escenario híbrido con Exchange Server podemos mover buzones de tu máquina local a Office 365 y viceversa!
  • Registro :  Enlace de acceso
  • Ponentes:
    • Alfredo Tercero García – Enterprise Engineer

Notas post-evento: Non Stop IT!– Soluciones de backup y disaster recovery

Cómo muchos sabréis, el tiempo encima de un escenario es limitado, por lo que siempre que preparamos los eventos lo hacemos teniendo en cuenta los tiempos para que al menos podáis ver un ejemplo práctico de una solución funcionando. Sin embargo los tiempos en la nube son muy variables y pueden ir totalmente en contra de uno cuando está haciendo la demo. Hoy Alberto Marcos y servidor hemos estado mostrando Azure Site Recovery como herramienta de migración a Azure desde máquinas físicas o VMWare usando Amazon Web Services como ejemeplo. Aunque os hemos enseñado el escenario montado, en el momento de hacer failover los tiempos se han extendido mucho y no hemos podido mostraros como lo hacía, así que escribimos este mensaje en el blog para mostraros al final cómo quedaba la situación:

image

Aquí podéis ver como el failover tardó aproximadamente 15 minutos en hacerse. Ojo, esto no quiere decir que perdiéramos 15 minutos de información –que en realidad fue a penas un par de minutos- sino que desde que presionamos el botón hasta que la operación se inicia pasan 15 minutos. La nota mental que hacemos de esta experiencia es darle al botón al principio de charla y no en la demo. Aquí podéis ver cómo las máquinas aparecieron migradas a Azure:

image

Por supuesto, eventualmente Alberto, servidor o algún integrante del equipo dedicaremos un post a esta tecnología de migración que nos ha parecido apasionante.

¡Gracias por seguirnos!

Evento: Non Stop IT! – Soluciones de backup y disaster recovery

Seguimos de eventos en este mes de septiembre, y esperamos que los siguientes. En esta ocasión la semana que viene estaremos Alberto Marcos y servidor vamos a hablar de Azure Disaster Recovery y de cómo puede ayudarnos a migrar a Azure. Si estás pensando en mover tu infraestructura, ¡esta es tu charla!

¡Te esperamos en las oficinas de Microsoft Ibérica!

  • Título: Yendo más allá, entornos híbridos o migración a la nube
  • Fecha: martes 22 de septiembre de 2015
  • Hora: 9:30 a 14:00 CET (nuestra charla es de 12:30 a 13:15)
  • Ubicación: Oficinas de Microsoft Ibérica: Paseo Club Deportivo, 1 – 28223 Pozuelo de Alarcón (Madrid) 
  • Idioma: Español
  • Abstract: El disponer de un centro de respaldo secundario de respaldo bajo demanda a nuestra infraestructura existente es atractivo. Sin embargo, puede ser que queramos ir un paso más allá y aprovechar la escalabilidad, agilidad y economía de la nube para empezar a desplegar nuevas cargas de trabajo o migrar las ya existentes. Veremos cómo es posible realizarlo con Site Recovery y el resto de mecanismos disponibles para hacer la transición lo más asequible.
  • Ponentes:
    • Carlos Milán Figueredo – Enterprise Team Lead
    • Alberto Marcos González – Enterprise Architect

– REGISTRO GRATUITO –

¡Os esperamos!

Webinar: Azure Websites on OpenSource

Actualización (9/9/2015): ¿Te perdiste el evento? ¡Puedes ver la grabación en el mismo enlace de inscripción! Tras rellenar el formulario podrás acceder a la grabación del evento.

La semana que viene estaremos Roberto González y servidor impartiendo un webinar de Microsoft sobre el OpenSource en Azure Websites (ahora Azure AppService). Os dejamos los datos del evento:

  • Título: Azure Websites on OpenSource
  • Idioma: Inglés
  • Abstract: Azure is the most open, broad and flexible cloud platform for every customers needs, regardless of the application, framework, data source or operating system their solution may require. Whether you’re interested in various Linux flavors, Docker, MongoDB, Hadoop or languages like Java, Python, PHP and Ruby, you will find first-class support for all. This is the second webinar of a series around OpenSource on Azure, and it will provide an insight of Azure Websites. Azure Websites is a fully managed Platform-as-a-Service (PaaS) that enables you to build, deploy and scale enterprise-grade web apps in seconds. Most importantly, it speaks your language – be it ASP.NET, Java, PHP, Node.js or Python. You can also run your favorite web apps and CMS solutions including, but not restricted to WordPress, Drupal and Joomla.
  • Fecha: martes 1 de septiembre de 2015
  • Hora: 10:00 a 11:30 CET
  • Ponentes:
    • Carlos Milán Figueredo – Enterprise Team Lead
    • Roberto González Gómez – Software Development Engineer

– REGISTRO GRATUITO –

¡Os esperamos!

Conectando Microsoft Azure con Amazon Web Services: Traffic Manager

Como continuación del artículo anterior en el que explicábamos como conectar Amazon y Azure, basado en la charla que dimos Carlos Milán y yo en Global Azure BOOTCAMP 2015 de Madrid, vamos a dedicar un artículo del blog a explicar cómo balancear la carga entre las dos nubes.

Si recordáis el escenario que conseguimos montar, a través de una conexión VPN S2S teníamos visibilidad de las máquinas virtuales de ambas nubes como si estuvieran en la misma red local. Esto nos permitía dejar volar nuestra imaginación y construir prácticamente cualquier entorno.

¿Qué vamos a hacer?

La idea es continuar desarrollando un escenario un poco más complejo aprovechando que tenemos visibilidad entre ambas nubes. Lo que se nos ocurrió es montar una aplicación web que estuviera replicada, balanceada y con soporte de failover entre Amazon y Azure. Casi nada, eh 🙂

image

 

Como veis en el dibujo tenemos un bosque de AD replicando con DCs en cada nube, y unos servidores IIS que van a formar la granja sobre la que se hospedará la aplicación web. La sincronización de los cambios en la web será tanto a nivel de código como de configuración, pero la explicación de como lo hemos hecho nos la guardamos para otro post 🙂

Partiendo de que la aplicación web es la misma en todo momento si accedemos al IIS de Amazon y de Azure, ¿cómo podemos tener un balanceo real de la carga, y que además sea susceptible de hacer un failover si una nube entera falla? Aquí es donde entra en juego un servicio que nos proporciona Azure llamado Traffic Manager.

Azure Traffic Manager

Se trata de un servicio de balanceo de red basado en DNS. Básicamente lo que hacemos es establecer unos extremos o “endpoints” y en función de la política que elijamos dirigirá el tráfico de manera inteligente a los mismos.

Las políticas que podemos seleccionar son las siguientes:

  • PERFORMANCE – Dirige al extremo “más cercano” basado en la latencia.
  • ROUND-ROBIN – Distribuye equitativamente el tráfico entre todas las localizaciones. Se pueden establecer pesos.
  • FAILOVER – Dirige a la localización de “backup” si el primario falla.

Citando directamente la documentación oficial, este servicio nos aporta las siguientes ventajas:

  • Mejorar la disponibilidad de las aplicaciones críticas:  permite mejorar la disponibilidad de las aplicaciones críticas supervisando los extremos y ofreciendo funcionalidad de conmutación por error automática cuando un extremo deja de estar activo.
  • Mejorar la capacidad de respuesta para las aplicaciones de alto rendimiento: Azure permite ejecutar servicios en la nube en los centros de datos ubicados en todo el mundo. Traffic Manager puede mejorar la capacidad de respuesta de las aplicaciones y los tiempos de entrega de contenido dirigiendo a los usuarios finales al extremo con la latencia de red más baja del cliente.
  • Actualizar y realizar el mantenimiento del servicio sin tiempo de inactividad:  admite escenarios extendidos para implementaciones en la nube híbrida y locales, entre los que se incluyen los escenarios “burst-to-cloud”, “migrate-to-cloud” y “failover-to-cloud”.
  • Distribución de tráfico para implementaciones grandes y complejas: con los perfiles anidados del Traffic Manager, en que un perfil puede tener otro perfil como extremo, puede crear configuraciones para optimizar el rendimiento y la distribución para implementaciones más grandes y complejas. Para obtener más información, vea Perfiles anidados.

Implementando el escenario

La implementación es tremendamente sencilla ya que únicamente debemos utilizar PowerShell para definir el perfil de Traffic Manager. No nos vale la interfaz gráfica dado que todavía no nos permite establecer extremos externos, como es Amazon en nuestro caso.

Vamos a analizar la configuración que nosotros definimos:

image

  • TimeToLiveInSeconds: este valor representa el TTL (TimeToLive) durante el cual va a mantener los endpoints en la resolución DNS. Nosotros lo hemos establecido en el mínimo posible (30 segundos) para que en caso de caída de un extremo, ese cambio se refleje lo más rápido posible en todos los servidores DNS con los que nos podamos cruzar.
  • MonitorRelativePath: es la ruta de la aplicación web que utilizará para monitorizar si el extremo está vivo. Básicamente intenta acceder y espera un 200 OK.
  • MonitorPort: el puerto de monitorización.
  • MonitorProtocol: el protocolo de acceso para la monitorización (http/https)
  • LoadBalancingMethod: aquí definimos el tipo de política o método de balanceo que va a utilizar Traffic Manager. Entre los 3 que veíamos antes, nosotros escogimos Round Robin, y al no especificarle pesos, por defecto es 50%-50%.
  • Endpoints: con este parámetro definimos todos los extremos de nuestra aplicación, en nuestro caso uno está en Azure y otro en Amazon.
  • MonitorStatus: nos indica el estado del servicio de Traffic Manager y de los endpoints definidos.
  • Name: es el nombre del perfil de Traffic Manager.
  • DomainName: es el nombre de acceso a Traffic Manager y por ende a nuestra aplicación. Si luego definimos un CNAME como es lo usual, tenemos que apuntar a este registro. En nuestro caso tenemos azurezon.plainconcepts.com –> azurezon.trafficmanager.net.
  • Status: los perfiles los podemos tener activados o desactivados, y eso nos da mucho juego. Imaginaros dos perfiles con los mismos endpoints, donde por defecto el perfil activo sea uno que funcione por “performance” pero ante cierta situación lo podamos cambiar a “failover”.

Este es el diagrama que nos quedaría:

image

Atendiendo a los parámetros que podemos configurar, y los tipos de balanceo que nos permite Traffic Manager, podemos conseguir escenarios tan interesantes como realizar una migración controlada de una nube a otra. ¿Os imagináis ir balanceando la carga de vuestra aplicación a otra nube e ir viendo como responde? Todo eso es perfectamente posible con Traffic Manager:

image

Otro detalle que debemos tener en cuenta, aunque el impacto es mínimo, es el precio de Traffic Manager y como varía en función de los endpoints. Por ejemplo un extremo “externo a Azure” tiene un coste que es casi el doble (€0,4022/mes), respecto a los extremos que estén en Azure (€0,2681/mes).

Una vez tengamos este entorno configurado, sólo nos queda… ¡la demo final!

Vamos a tirar abajo las máquinas de una nube y automáticamente el tráfico se balanceará a la otra, donde la aplicación estará replicada y actualizada.

Pero… ¿cuánto tiempo tarda Traffic Manager en darse cuenta de que un extremo está caído? Con el TTL de 30 segundos que hemos definido, la respuesta es… 2,5 min. Creo que dos minutos y medio para un failover entre entornos cloud de proveedores distintos no está nada mal 🙂

El dato del RTO (Recovery Time Objective) se calcula en base al número de intentos que realiza Traffic Manager antes de dar un extremo como “caído” (4), por el tiempo que espera entre cada intento (30 seg), más el TTL del registro DNS que tendrá que actualizar eliminando el extremo caído (30 seg): 4*30 + 30 = 150 seg = 2,5 min

En el siguiente gráfico se ve más claro:

Traffic Manager Monitoring Sequence

Podéis encontrar más información al respecto en este artículo.

Con los dos entornos activos, y con clientes distribuidos geográficamente y sin pasar por los mismos servidores DNS intermedios, la distribución de la carga será homogénea.

image image

Una vez el acceso a una de las nubes se vea afectada, como hicimos parando las máquinas de Amazon en nuestra demo, al cabo de 2,5 min todo el tráfico será dirigido únicamente a Azure.

Esperamos que os haya gustado esta segunda parte sobre como montamos un entorno de alta disponibilidad entre nubes y queda pendiente explicaros como hicimos para replicar la aplicación web.

Os dejamos con alguna foto más de la sesión, cortesía de Carmen.

Happy networking!

DSC_0107

DSC_0108

DSC_0111

DSC_0112

Conectando Microsoft Azure con Amazon Web Services

Tal y como os prometimos, después del Global Azure BOOTCAMP 2015 de Madrid, vamos a dedicar un artículo del blog a explicar cómo Alberto Marcos y servidor –Carlos Milán– llegamos a crear un escenario híbrido entre Amazon Web Services (de ahora en adelante AWS) y Microsoft Azure. Si te perdiste nuestra charla, ¡obligatorio que leas este post!

image

¿Qué vamos a hacer?

La idea es bastante simple: vamos a enlazar una VPC (Virtual Private Cloud) de AWS con una red virtual de Azure mediante un tunel site to site IPsec. La idea es que ambas redes queden interconectadas en un entorno LAN y podamos desplegar máquinas virtuales que disfruten de visibilidad a nivel de red local de ambos entornos.

image

Gracias a esta visibilidad, podemos, entre otras cosas:

  • Facilitar enormemente las migraciones de sistemas una plataforma a otra.
  • Crear un escenario de alta disponibilidad donde esta esté garantizada por más de un proveedor de cloud.
  • Crear una infraestructura única que aproveche capacidades especiales de un proveedor que no están disponibles en otro. Por ejemplo: AWS dispone de máquinas virtuales con GPU, mientras que Azure dispone del mejor escalado vertical del mercado con las máquinas de tipo G.
  • Etc…

Definiendo conceptos

Como sabréis los visitantes de nuestro blog, no somos ni mucho menos expertos en Amazon, pero desde luego que somos expertos en Azure; así que aventurarnos en este escenario nos obligó a estudiar un poco la plataforma. Y es que AWS y Azure no son tan distintos como a primera vista pueden parecer, sino que utilizan distinta nomeclatura para elementos que son bastante análogos entre sí. Aquí hay una lista de analogías:

image

Implementando el escenario

Vamos a comenzar con la serie de pasos que seguimos para implementar el escenario donde, como podréis imaginar, hay que realizar una serie de tareas tanto en AWS como en Azure. En el artículo daremos por sentado que tenemos tanto nuestra suscripción de AWS como la de Azure listas para usar.

Direccionamiento IP

Lo primero era elegir un direccionamiento IP para trabajar con ambas redes, que pensamos que podía ser el siguiente:

image

Es muy recomendable crear ambos entornos en una localización geográfica cercana. ¡Una vez tomada la decisión, ya podíamos comenzar a trabajar!

AWS – Creando la VPC

Deberemos crear una nueva VPC en AWS:

  1. Seleccionamos VPC with a Single Public Subnet.
    image
  2. Configuramos las opciones:
    • Establecemos su direccionamiento de acuerdo a lo planeado: 10.0.0.0/16
    • Le damos un nombre cualquiera.
    • Establecemos una subnet pública de 10.0.0.0/24.
    • Resto de opciones por defecto.
      image

¡Ya tenemos red! ¡Ahora a por la pasarela!

AWS – Creando la VM gateway

AWS dispone de un servicio de gateway SaaS, pero como este no cumple con las especificaciones necesarias para conectarse con Azure, vamos a crear nuestra propia máquina virtual que actuará como gateway a Azure de nuestra red.

  1. En el servicio de EC2 vamos a seleccionar una AMI (Amazon Machine Image) Windows Server 2012 R2 Base.
    image
  2. Una instancia de tipo t2.micro es más que suficiente para nuestro laboratorio.
  3. Seleccionamos que pertenezca a la VPC que hemos creado en la tarea anterior y dejamos el resto de opciones por defecto. Opcionalmente podemos especificar una IP interna o si no asignará una por DHCP estático.
  4. En la parte de almacenamiento, servirá bien el disco SSD de 30 GB por defecto. Tras la instalación de Windows Server 2012 R2 sólo nos quedarán unos 6 GB libres de espacio en disco, pero serán suficientes para nuestro propósito.
  5. Daremos un nombre a la máquina, nosotros la llamamos GATEWAY.
  6. Creamos un nuevo Security Group para ella. Los Security Groups son reglas de firewall que nosotros establecemos para regular el tráfico en las instancias de Amazon EC2; son equivalentes a los Endpoints y Security ACLs de Azure. Para la máquina de gateway en Amazon deberemos crear uno nuevo con las siguientes reglas:
    image
    Las reglas que corresponden a los puertos UDP 4500 y 500 son las del tráfico IPsec y verás que sólo las permitimos en una IP concreta. Esta IP es la de gateway de Azure, que en este punto todavía no tenemos establecido y por tanto no conocemos. Ignóralas de momento y volveremos más tarde a añadirlas.
  7. Creamos la máquina vritual.

AWS – Elastic IPs

Si vamos a crear un gateway IPsec en una máquina virtual, no querremos que su IP pública cambie o nos inutilizará el escenario. Por ello debemos reservar una que mantenga siempre.

  1. Desde EC2 Dashboard seleccionamos Elastic IPs.
  2. Seleccionamos Allocate New Address.
  3. Le indicamos que queremos asociar la IP a una instancia de máquina virtual.
  4. Seleccionamos la máquina GATEWAY que creamos en el proceso anterior.

Con estos sencillos pasos nuestra máquina ya tiene su IP pública fija, ¡anótala! Te hará falta en el siguiente paso, ¡nos vamos a Azure!

AZURE – Creando la red virtual

Vamos a proceder a crear una red virtual nueva:

image

Las opciones a configurar serán:

  • Queremos conecitividad site-to-site VPN.
  • Especificaremos una nueva red local.
  • Como red local definiremos el direccionamiento que hemos elegido para AWS: 10.0.0.0/16
  • La IP del dispositivo VPN: debe ser la Elastic IP que reservaste en la tarea anterior desde AWS.

La configuración de la red de AWS en Azure podría quedar así:

image

Mientras que la de Azure, en el último paso del asistente, quedaría así:

image

¡No olvides crear una subnet para el gateway! La necesitarás para lo que viene justo ahora.

AZURE – Creando el gateway

Entra en la red virtual que acabas de crear y selecciona Create gateway y Dynamic routing.

Botón de selección de tipo de gateway en el momento de su creación.

Cuando esté creado podremos ver la IP asignada desde el dashboard de la red virtual:

image

Y además haremos clic en Download VPN Device Script para descargar la configuración que ejecutaremos en la máquina Windows Server 2012 R2:

image

¡Es hora de volver a AWS!

AWS – Editando Security Group

¿Recuerda el Security Group que creamos para la máquina gateway en AWS? Como ya sabemos la IP del de Azure es hora de que lo agreguemos a las reglas. Recuerda:

image

Agregamos dos nuevas Custom UDP Rule a los puertos 4500 y 500 para permitir que el tráfico IPsec fluya desde el gateway de Azure.

AWS – Configurando RRAS en el gateway Windows Server 2012 R2

En este paso no voy a entrar en mucho detalle puesto que es análogo a lo que Antonio López Márquez ya nos explicó en este otro artículo. En realidad no tenemos más que llevar a la máquina Gateway el script de PowerShell que hemos descargado del portal de Azure y ejecutarlo. Este script agregará automáticamente el rol de RRAS al servidor y configurará la conexión con el gateway de Azure.

AWS – Desactivando Source/Destination Check

El Source/Destination Check de son una serie de verificaciones que los adaptadores de red virtuales de EC2 realizan para comprobar si el tráfico que una interfaz de red recibe está verdaderamente destinado a la misma. Como resulta obvio, esto puede resultar nefasto en una máquina de gateway que hace de pasarela para el tráfico destinado a otras máquinas, por lo que debemos desactivar estas comprobaciones.

  1. Desde el dashboard de EC2 seleccionamos Network Interfaces.
  2. Seleccionamos el interface de red de nuestra máquina gateway.
  3. En Action podremos seleccionar Change Source/Dest. Check, que cambiaremos a Disabled.

image

Llegados este punto, el tunel entre AWS y Azure debería estar establecido y así tendríamos que poder verlo en el dashboard de Azure. Desde AWS no tenemos un vistazo tan gráfico y deberemos entrar en la máquina Gateway para comprobar su estado. Debería lucir tal que así:

image

Pero esto no será suficiente para que el tráfico fluya entre las máquinas de ambas redes. Necesitaremos modificar la tabla de rutas de la red de AWS para conseguirlo.

AWS – Creando una nueva tabla de rutas para la subred

Crear y modificar tablas de rutas en AWS es bastante trivial:

  1. Nos dirigiremos al dashboard de EC2 y acto seguido a Route Tables.
  2. Clic en Create Route Table. Ten en cuenta que otra posibilidad es editar la tabla de rutas principal de la VPC que creamos anteriormente. Haz este paso a tu gusto.
  3. Le ponemos un nombre y la adjuntamos a la red que hemos creado.
  4. Posteriormente deberemos asociar la tabla de rutas a la subnet pública que creamos también en pasos anteriores.

Y finalmente deberemos editar dicha tabla para agregar la ruta a Azure a través del gateway. Esto quedaría así:

image

Como podéis ver la ruta a Azure se asocia directamente a la interfaz de red que se encuentra en la máquina de gateway.

Probando el escenario

¡Y esos eran todos los pasos! Ya estamos preparados para probar el escenario que hemos explicado. Para ello vamos a desplegar un par de máquinas virtuales, una en AWS y otra en Azure, donde probaremos si tienen conectividad entre ellas. El sistema operativo es irrelevante en este caso. En nuestro lab hemos puesto una máquina adicional Windows Server 2012 R2 en AWS y una máquina con Ubuntu GNU/Linux en Azure. El esquema sería el siguiente:

image

El resultado se pudo ver en directo en la presentación, hicimos ping de forma satisfactoria de la máquina AWS a la máquina Azure y viceversa, con lo que teníamos un canal de comunicaciones seguro y establecido entre ambos datacenters.

WP_20150425_11_48_29_Pro (Medium)

Por supuesto, nuestra demo no se limitó a enseñar un ping entre máquinas, sino que realizamos algunas pruebas más, algunas de ellas muy vistosas que nos reservamos para otro artículo. Espero que este artículo os haya resultado interesante y os anime a explorar las posibilidades de interoperabilidad y conexión de Azure, ¡incluso con su plataforma rival!

Os dejamos con algunas fotos de la charla del Bootcamp donde podéis ver a Alberto y servidor en acción 🙂

Happy networking!

Enlace relacionado: Connecting Clouds – Creating a site-to-site Network with Amazon Web Services and Windows Azure

WP_20150425_11_27_52_Pro (Medium)

WP_20150425_11_33_22_Pro (Medium)

WP_20150425_11_44_05_Pro (Medium)

WP_20150425_11_45_26_Pro (Medium)

WP_20150425_11_46_09_Pro (Medium)

WP_20150425_11_48_29_Pro (Medium)