Archivo de la etiqueta: aws

Conectando redes con NAT e IP dinámicas mediante VPN site to site a Azure

Como os hemos explicado en otras ocasiones, en Plain Concepts estamos estableciendo las redes de todas nuestras oficinas en torno a un hub central en Microsoft Azure, siguiendo una topología de estrella. La topología que tenemos diseñada se parecería –en grandes rasgos- a lo siguiente:

image

Evidentemente, utilizaríamos las capacidades del Azure Network Gateway con enrutamiento dinámico para poder establecer múltiples túneles IPsec site to site entre las distintas sedes. Sin embargo, y tal y como os hemos comentado en otros artículos, es necesario cumplir con una serie de requisitos para poder conectarse a Azure, entre los que se encuentran:

  • Disponer de un dispositivo gateway compatible, o bien una máquina Windows Server 2012 R2 ó UNIX (GNU/Linux incluido).
  • No debe haber ninguna clase de NAT entre los gateway que vamos a conectar, es decir, el nuestro y el de Azure.
  • Debemos disponer de una IP pública fija.

En una de nuestras oficinas nos hemos encontrado con un problema: no teníamos la posibilidad de disponer de IP fija, con lo que incumplíamos los requisitos y se tornaba imposible conectar la oficina dados los requerimientos. El procedimiento obvio era contratar una IP fija, pero ningún proveedor de fibra nos ha dado la opción, y como tampoco es menester de este artículo o blog discutir sobre las telcos, vamos sencillamente a tomar esa restricción como insalvable. La situación es esta:

image

Solución 1: Azure User Defined Routes e IP forwarding

Entre las grandes novedades del Build 2015 se encuentran importantes mejoras en el networking de Azure con la inclusión de las siguientes características:

Usando estas características podríamos establecer una máquina virtual en Azure como dispositivo de gateway para nuestra red virtual, de forma similar a como hicimos con Amazon Web Services. Así podríamos superar algunas de las limitaciones impuestras por el gateway de Azure.

Aunque esta sería la solución ideal, he de decir que me encontré con dificultades configurando el dispositivo y con muy poca documentación al respecto. Nada que reprocharle a Microsoft dado que son características que llevan muy poco tiempo publicadas; así que es una mera cuestión de esperar algunos meses a que tengamos documentación detallada.

Solución 2: Utilizar Amazon Web Services como intermediario

No podemos decir que no estemos sacando provecho del experimiento que hicimos para el Global Azure Bootcamp 2015. Si entre la red de Sevilla y la red de Azure ponemos alguna pasarela que sí cumpla con los requerimientos de Azure y las reestricciones de Sevilla, esta máquina podría encargarse de dirigir el tráfico entre ambos entornos.

Podríamos haber cumplido este requerimiento utilizando la red on-premises de Madrid, pero nos pareció oportuno dar a Sevilla independencia desde el punto de vista de infraestructura, por lo que desplegar una máquina en Amazon Web Services me pareció una solución ideal. El diagrama sería el siguiente:

image

Implementando la solución 2: los pasos

La implementación de la solución 2 se realiza a través de los siguientes pasos:

  1. Crear una VPC en AWS con una máquina virtual basada en GNU/Linux. En mi caso elegí Ubuntu 14.04 LTS, pero serviría cualquier distribución, incluso algún otro sabor de UNIX como FreeBSD.
  2. Configurar la red virtual de Azure y su gateway para conectar con la recién creada red de Amazon, tal y como ya explicamos en este artículo.
  3. Ya establecida la conexión en Azure y Amazon, debemos realizar lo propio en la misma máquina entre Sevilla y Amazon, asegurándonos de cumplir con los requerimientos de Sevilla, es decir, usar IP dinámica.

Estableciendo un túnel IPsec con IP dinámica en un extremo

El núcleo tecnológico de este artículo es precisamente establecer un túnel entre dos extremos: uno con IP fija y otro con IP dinámica utilizando IPsec, cosa que es posible si tenemos control de ambos. Dada la buena experiencia que nos ha dado siempre, he optado de nuevo por usar StrongSwan, con su potente implementación de IPsec con IKEv2. StrongSwan corre sobre Linux, Android, FreeBSD y Mac OSX.

Cabe destacar que no hemos usado ningún protocolo adicional para el transporte comó podría ser L2TP, dado que IPsec con IKEv2 ha funcionado estupendamente en modo túnel.

La máquina GNU/Linux usada para la implementación tiene las siguientes características:

  • 1 único nucleo de CPU
  • 1 GB de RAM
  • 1 adaptador de red con dirección IP privada asociada
  • 1 IP pública que mapee los puertos 500/UDP y 4500/UDP al adaptador de la máquina virtual

 Configurando la máquina en Sevilla

Así pues entramos en la máquina GNU/Linux y ejecutamos:

Tras lo cual estamos listos para configurar el stack de IPsec en el extremo de Sevilla en el archivo /etc/ipsec.conf:

Los parámetros importantes a explicar son:

  • left. El extremo izquierdo del túnel, habitualmente la máquina que inicia la conexión. Normalmente aquí especificaríamos una dirección IP, pero recordemos que nuestra IP es dinámica, por lo que utilizamos una resolución de dominio precedida por %. Este modificador indica que aunque le vamos a sugerir una IP, aceptaremos cualquiera.
  • leftsubnet. La subred que vamos a exponer a través del túnel.
  • leftid. Importantísimo parámetro en el caso de una IP dinámica. Es un identificador que deberá cuadrar con el que el otro extremo solicite en el momento de la conexión, de forma que IPsec sepa que se está conectando al lugar correcto. Va precedido de @ para indicar que el dominio no debe resolverse, ya que se usa sólo como identificación.
  • right. El extremo derecho del túnel. Este es Amazon y aquí si tenemos una IP pública fija.
  • rightsubnet. La subred en el otro extremo a la que querremos acceder a través del túnel.
  • rightid. Similar al leftid.

Y tras ello debemos poner la PSK en /etc/ipsec.secrets:

Esta configuración nos debería permitir establecer la conexión, pero para que los paquetes que pasen por la máquina entren por el túnel debemos especificar la política correcta en iptables:

Si además estamos usando iptables para filtrar tráfico deberemos poner las reglas correspondientes para permitir los puertos 500/UDP y 4500/UDP.

Configurando la máquina en Amazon Web Services

Recordemos que esta máquina va a conectar tanto a Sevilla como a Azure, por lo que debemos configurar StrongSwan adecuadamente. Voy a presuponer que hemos realizado ya en ella los pasos detallados en este artículo y tenemos nuestro túnel con Azure ya funcionando.

¡No olvides permitir el tráfico IPsec en el Security Group de AWS!

image

Después hay que modificar el /etc/ipsec.conf:

Tras ello, de igual forma que hicimos en el gateway de Sevilla, deberemos configurar el archivo /etc/ipsec.secrets con las PSK tanto de Sevilla como de Azure, para poder establecer ambos túneles.

Y del mismo modo, las políticas de iptables:

Llegados este punto ya sólo nos queda hacer ipsec restart en ambas máquinas y consultar desde la máquina de Amazon el estado de ambos túneles. Si todo ha ido bien deberíamos poder ver algo parecido a lo siguiente:

image

Comprobamos el resultado con un PING de Sevilla a Azure:

Ping Sevilla-Azure

 

Y si hacemos un PING desde Azure a una máquina de la red de Sevilla:

Ping Azure-Sevilla

Algunos consejos ante posibles problemas

  • Muchos de los problemas de configuración que se pueden presentar estableciendo túneles IPsec suelen estar en la configuración de ambos extremos. ¡Asegurate de que cuadran perfectamente entre ellos!
  • En otras ocasiones, puede haber problemas de conectividad de red y firewalls, comprueba todas las políticas.
  • ¿Sigues con problemas? Examinar el log de StrongSwan puede ayudarnos a diagnosticar. Lo encontrarás por defecto en el Syslog, en /var/log/syslog.
  • Si el dispositivo o máquina donde establecéis el túnel es al mismo tiempo la puerta de enlace por defecto, no será necesario tocar ninguna tabla de rutas.
  • ¿Más dudas? ¡Déjanos un comentario!

Happy networking!

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)

Global Azure BOOTCAMP 2015: Conectando Amazon Web Services y Microsoft Azure

bootcamp2015

El próximo sábado 25 de abril de 2015 tendrá lugar en Madrid uno de los eventos más importantes del año relacionado con Microsoft Azure: el Global Azure BOOTCAMP 2015. Realizado en paralelo en más de 134 localizaciones y reuniendo a aproximadamente 200 profesionales del mundo de la infraestructura y los sistemas definitivamente conforma un panorama que… ¡no te puedes perder!

Este año Alberto Marcos y servidor –Carlos Milán– tendremos el honor de dar una de las charlas en el track de sistemas donde hablaremos de algo que esperemos que como mínimo no os deje indiferentes: vamos a establecer un entorno híbrido entre Amazon Web Services con Microsoft Azure:

AmazonAzure

¿Cómo es posible esto? ¿Qué aplicación tiene en escenarios reales? ¿Qué situación vamos a presentar? ¡Te lo contaremos todo y responderemos a las preguntas que nos quieras hacer el próximo sábado 25 de abril en el Global Azure BOOTCAMP 2015 en las oficinas de Microsoft Ibérica del Centro Empresarial La Finca! ¡Te esperamos junto a todo un elenco de expertos en Microsoft Azure!

Registro (asistencia gratuita)

Enlace relacionado: Global Azure BOOTCAMP 2015 – Madrid