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)

Instalación de StorSimple 8X00

Hace dos días, nuestra compañera Elena nos contaba que era StorSimple, y en este artículo vamos a ver como configurarlo si ya disponemos de uno. Como vais a comprobar, la configuración es bastante sencilla, pero será ligeramente diferente dependiendo del tipo de dispositivo (8100 u 8600). En el final del articulo podéis encontrar información específica para cada uno.

Instalación hardware

Lo primero que debemos hacer es desempaquetar el dispositivo y comprobar que tenemos todos los materiales necesarios. La principal diferencia entre el 8100 y el 8600 es que este último se compone de dos módulos, por lo que tendremos algún cable más.

El propio StorSimple trae un kit para montar el dispositivo en nuestro rack, por lo que, una vez sacado de la caja y antes de cablearlo, deberemos “enracarlo”. Tras esto, llega un momento delicado, ya que si no ponemos los cables de manera correcta, nos será imposible conectar nuestro nuevo almacenamiento local con Azure.

En el caso de disponer de StorSimple 8600, deberemos conectar mediante SAS (Serial Attached SCSI) el dispositivo principal y el almacenamiento EBOD (Extended Brunch of Disks) como indica la siguiente figura (A principal, B EBOD):

image

El siguiente paso en los dos modelos es conectarlos a la corriente eléctrica. Para ello, comprobamos que los interruptores de alimentación están apagados y conectamos los respectivos cables, teniendo en cuenta que en el caso de 8600 serán dos unidades. Las fuentes de alimentación deberán ser diferentes en cada una de las dos entradas del dispositivo, así aseguraremos la alta disponibilidad.

image

Una vez conectado, encendemos los interruptores (primero los del módulo EBOD en el caso de tenerlo) y comprobamos que se encienden los LED verdes.

Ahora es turno de las conexiones de red. Este sería el mapa de estas conexiones en el dispositivo principal (el módulo EBOD no está conectado a la red):

image

Tras esto, faltaría conectar nuestro ordenador al puerto serie del StorSimple para continuar la configuración software. Es importante abrir puerto 443 (HTTPS) del Firewall, ya que lo utiliza Azure para conectarse con el StorSimple

Instalación software

Una vez acabada la instalación física, podemos volver a nuestro ordenador para continuar con el proceso. Para ello, accedemos al portal de Azure y creamos un nuevo servicio de StorSimple que llevará asociado una cuenta de almacenamiento.

image

Una vez creado, necesitaremos la clave de registro. Para ello, accedemos al servicio y en la parte inferior aparecerá el icono con la clave. Al pulsarlo nos la mostrara por pantalla. Habrá que guardarla para usarla en la configuración por PowerShell.

image

Para terminar la configuración de nuestro dispositivo físico. Para ello nos conectamos por PuTTY a la consola del dispositivo, seleccionamos el idioma y la opción [1] Inicio sesión con acceso total. La contraseña necesaria por defecto es Password1. Con el comando Invoke-HcsSetupWizard comenzaremos el proceso de instalación.

Lo primero que debemos indicar son algunos ajustes de red (IP, mascara y puerta de enlace de Data0 (interfaz conectada a internet), servidor DNS y servidor NTP) e introducir una nueva contraseña de administrador y contraseña de administrador de instantáneas (por si queremos usar este complemento). Por último, debemos introducir la clave de registro que obtuvimos en Azure. Una vez finalizado el registro, nos dará la clave de cifrado de datos. Hay que guardar esta clave, al igual que la clave de registro, ya que nos será útil en el futuro.

image

Para finalizar la instalación, accedemos de nuevo al portal de Azure, y el la pestaña dispositivos, dentro de nuestro nuevo servicio de StorSimple, aparecerá el que acabamos de configurar. Accederemos a él y pulsaremos en completar configuración de dispositivo.  Primero deberemos completar el nombre, la zona horaria, servidor DNS secundario e interfaces iSCSI. Posteriormente, deberemos introducir las direcciones IP del controlador 0 y controlador 1 dentro de la subred del dispositivo.

Con esto ya habríamos finalizado la configuración del dispositivo, los siguientes pasos serian crear volúmenes y copias de seguridad. Esto lo veremos en próximos artículos.

Configuración de StorSimple 8100: https://msdn.microsoft.com/es-es/library/azure/dn757794.aspx

Configuración de StorSimple 8600: https://msdn.microsoft.com/es-es/library/azure/dn772377.aspx

¿Stor qué …? StorSimple

Esta semana me gustaría hablaros de un appliance que lleva tiempo en el mercado: StorSimple. Es por ello que he querido dedicar este artículo a hablar de una manera genérica e introductoria de él. Este sistema (StorSimple) encaja perfectamente en el concepto de almacenamiento híbrido (también conocido como CIS: Cloud Integrated Storage), así pues entremos en materia.

FUNCIONAMIENTO

La lógica de funcionamiento de este sistema sería el siguiente, el cual podríamos dividir en varios niveles:

  • Detección de archivos más utilizados: el aparato dispone de un algoritmo que identifica cuáles son los archivos más empleados (hot files) , de tal manera que estos se situarían en los discos SSD a modo de caché.
  • Deduplicación: Cuando un archivo tiene patrones similares se eliminan por medio de la deduplicación (que nos permite ahorrar espacio de almacenamiento, ya que elimina toda aquella información que es redundante).
  • Compresión :Es capaz de detectar qué archivos se emplean más y cuales no, de tal manera que aquellos que no se emplean tan habitualmente se guardan en los discos SAS y a continuación los comprime.
  • Cifrado: Una vez comprimidos los cifra (con la clave que hayamos establecido) y los almacena en una cuenta de almacenamiento que hemos configurado .

De esta manera, tendremos por un almacenamiento en el dispositivo y otro en la nube (alcanzando un espacio mayor de almacenamiento). Todo este proceso es transparente para el usuario, para el cual, los datos estarán en la red local, independientemente del estado en el que se encuentren.

En el propio dispositivo (una vez inicializado y conectado al server de nuestro Datacenter) podemos establecer volúmenes, y también debemos establecer la cuenta de almacenamiento de Azure donde se van a guardar los datos. Podemos establecer una clave para cifrar los datos cuando se suban a Azure.

El DISPOSITIVO

Como dispositivo se trata de una serie de discos SSD y discos SAS, que nos permite tener un almacenamiento en local y en la nube. Todo esto claro, a muy “grosso modo”, ya que detrás de todo esto hay mucho más. Actualmente Microsoft dispone de varios modelos separados en varias series: los de la serie 7000 y los de la serie 8000. La diferencia más significativa (aunque no la única) entre ambas series radica en el Kernel que lleva por debajo el dispositivo . Si bien los de la serie 7000 (y anteriores) llevan un sistema Linux embebido, los de la serie 8000 ya vienen con un Windows también embebido (cosa que nos va a permitir una serie de características adicionales, pero este no va a ser el objeto de este artículo).

El dispositivo es redundante frente a posibles fallos. Dispone de 2 controladores y 2 fuentes de alimentación, pero sólo una de ellas va a estar activamente funcionando. Cada una de las controladoras consta de 4 puertos ethernet de los cuales uno va a servir para poder administrarlo vía web (MGMT), otro va a servir para conectar el appliance via iSCSI a nuestro datacenter, otro par establecer la conexión con Azure, y tendríamos un puerto adicionar para configurar.

5010_7010ApplianceBackPlane.png

LIMITACIONES

Hay algunos escenarios en los que no son recomendables como el caso de aplicaciones en tiempo real, ya que para recuperar algunos datos que estén en la cuenta de almacenamiento, aunque el periodo de latencia no sea elevado, quizá no cumpla con los requisitos exigidos.

Y hasta aquí unas breves nociones sobre StorSimple. Espero haber arrojado un poquito de luz sobre este tema. Un saludo y hasta otro post!!!

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

Configurar una VPN Point-To-Site en Azure

En anteriores artículos ya habíamos hablado de cómo configurar una red VPN Site-To-Site . En este artículo trataremos otra de las posibles configuraciones de redes privadas virtuales que es posible realizar en Microsoft Azure.

Una VPN Point-To-Site nos permite conectar nuestra máquina local de forma segura a una red virtual de Azure sin necesidad de disponer y configurar un dispositivo VPN o RRAS.  Este tipo de conexiones emplean un tunel hecho a traves del protocolo SSTP con autenticación basada en certificados entre la máquina cliente y la red virtual. Son una buena elección cuando :

  • Son pocas máquinas clientes las que necesitan conectarse a la red virtual de Azure, ya que este tipo de conectividades sólo permite que se conecten hasta 128.
  • No disponemos de un dispositivo VPN para configurar una conexión Site-To-Site, valga la redundancia.
  • Quieres conectarte de forma segura cuando estás offsite (por ejemplo cuando estás en una cafetería).

Como ejemplo, indicar que las  conexiones  de Azure App Service   a las redes virtuales son mediante Point-To-Site.

point2site

Entonces, ¿qué necesitamos para crear este tipo de redes?

  • Crear la red privada virtual y su correspondiente puerta de enlace (o gateway) de enrutamiento dinámico, ya que propicia conexiones más estables que los de tipo estático.
  • Crear los certificados que usaremos para identificar a clientes en la VPN Point-To-Site. Necesitaremos dos certificados, un certificado de raíz y un certificado cliente,  ambos autofirmados.
  • Configurar la máquina local para que se conecte a la VPN. Dicha computadora deberá tener instalado como sistema operativo Windows 7 , Windows Server 2008 R2 o versiones posteriores.

Paso 1.- Configurar la red privada virtual y su gateway.

Para crear la red virtual lo primero es ir a nuestro portal de Azure y en el menú ubicado en el lateral izquierdo de nuestra pantalla haremos click en la sección Networks.

image

Habiendo accedido a dicha sección, crearemos nuestra red virtual haciendo click en New –> Network Services –> Virtual Network –> Custom Create . Nos mostrará la primera página  asistente de instalación de creación de red virtual, donde podremos especificar el nombre y la localización en los campos Name y Location correspondiente. Luego, haremos click en la flecha ubicada en la parte inferior derecha  para avanzar al siguiente paso.

image

En la página DNS Servers and VPN Connectivity, elegiremos únicamente la opción Configure a poin-to-site VPN .

image

Avanzando a la siguiente página del asistente, especificaremos el rango de direcciones IP que los clientes VPN recibirán cuando se conecten. En nuestro caso elegiremos la configuración por defecto.

image

En la última fase del proceso, podremos comprobar que Azure nos ha creado una subred por defecto sobre la cual se conectarán los clientes VPN. No obstante, es posible configurarlo a nuestro gusto. Si queremos usar la red point-to-site  que hemos configuramos, necesitaremos agregar una subred para la puerta de enlace (la cual reserva unas 8 direcciones IP). Basta con hacer click  en Add gateway subnet . Añadido dicho espacio de direcciones,  finalizamos el proceso de creación.

image

Con la VPN ya creada , nos faltaría crear  la puerta de enlace. Basta con acceder a la red creada dentro de la sección Networks y nos iremos a la pestaña  Dashboard . En dicho menú, para crear la puerta de enlace bastará con pulsar el botón Create Gateway ubicado en la parte inferior de la pantalla.  Azure nos creará una puerta de enlace de enrutamiento dinámico. No os preocupéis si el proceso de creación tarda.

image

Paso 2.- Creación y agregación de los certificados autofirmados

Como ya hemos dicho, la necesidad  de crear certificados autofirmados se debe a que la conectividad point-to-site usa autenticación por certificados por encima del uso de contraseña de usuarios.  Aquel que no posea el certificado cliente instalado de forma correcta no podrá conectarse a nuestra red virtual, incluso si de alguna manera obtiene la dirección IP de la red.

Antes de nada, deberemos crear el certificado raíz para que lo podamos subir al portal de Azure. Nos valdremos de la herramienta makecert.exe (la cual deberemos tener en nuestro equipo local). Y despues ejecutaremos los siguientes comando desde CMD o Powershell  (la opción elegida en este ejemplo) con el nombre del certificado que nosotros queramos. En este caso utilizaremos “<Certificado_Root>” .

Posteriormente creamos el certificado raíz  (al que llamaremos <CertificadoCliente>) , para ello y sin movernos de la consola, escribiremos lo siguiente :

Ya creados , los exportaremos  para poder instalarlos en sus correspondientes sitios empleando la herramienta  certmgr.mscAllí los encontraremos dentro de la carpeta Personal donde procederemos a exportarlos, empezando  el certificado de raíz, haremos click derecho y seleccionaremos  la opción de exportar.

image

Indicar que en el certificado raíz no hay que exportar la clave privada y que deberemos guardarlo con extensión “.cer”.

image

image

Realizaremos el mismo proceso  con el certificado cliente, pero en este caso sí que deberemos exportar la clave privada y el formato deberá ser “.pfx”. Ya elegido el formato del certificado, deberemos indicarle una contraseña, que usaremos a la hora de instalarlo en el equipo cliente para poder conectarnos de forma segura en la VPN.

image

Una vez tengamos los certificados,  procederemos a su instalación. En el caso del certificado raíz, basta con ir a la sección Certificates dentro de nuestra red en el panel de Azure, donde podremos subirlo presionando en el enlace Upload a Root Certificate :

 

image

Cuando ya se haya subido, nos quedaría instalar el certificado cliente sobre la máquina que queremos que se conecte a la VPN. Si hacemos click sobre él dos veces, introducimos la contraseña que indicamos cuando lo exportamos,  ya lo tendremos instalado.

Paso 3.- Configuración de la máquina cliente

Creados e instalados los certificados, tan sólo nos quedaría configurar la máquina cliente que se conectará a la VPN Point-To-Site.  Desde nuestra pestaña Dashboard  de nuestro portal de red en Azure, observamos  que en lateral derecho en la sección Quick Glance   podremos descargar el paquete cliente VPN según el procesador de la máquina cliente :

image

Cuando hayamos terminado de descargarlo e instalarlo, si nos dirigimos a la sección de redes de la máquina local, tendremos la opción de conectarnos a la red que hemos creado.

image

Y eso es todo, no es un proceso difícil  pero sí algo largo.  Esperemos que os haya gustado. Ahora no tendréis excusa para crearos vuestra propia VPN en Azure.

¡Muchas gracias por leernos!

PowerShell Basics: Proveedores

Bienvenidos a otro artículo de la serie de “PowerShell Basics”. En la edición anterior se ha tratado el tema de las tuberías, cómo funcionan, cómo usarlas, y consideraciones de rendimiento. Hoy toca otro tema igual de interesante, aunque con un uso algo más marginal: Los proveedores.

Desde el principio: ¿Qué son los proveedores?

Ateniéndose a una definición estilo “manual de programación”, se puede decir que “Son programas basados en .NET framework que exponen la información de una fuente de datos, para que pueda visualizarse y trabajar con ella desde Windows PowerShell, accediendo a dicha información de forma similar a como se manipula un sistema de ficheros en línea de comandos”. Básicamente, lo que nos viene a decir es que los comandos que habitualmente se utilizan para trabajar con archivos/directorios en PowerShell no son “comandos aislados”, sino que han sido abstraídos a una entidad conceptual diferente (un proveedor). Esto a su vez, permite cambiar de proveedores para trabajar con otro tipos de datos, sin cambiar en demasía la forma de trabajar.

El proveedor predeterminado: PSDrive

Cuando iniciamos una consola PowerShell, por defecto se carga el proveedor PSDrive, encargado de gestionar y proporcionar el acceso a las unidades de disco y exponer operaciones de consulta y manipulación de archivos y directorios. Si alguna vez habéis escrito “ls” en PowerShell, sabed que dicho comando es un alias de “Get-ChildItem”, que es uno de los comandos proporcionados por los proveedores.

PSDrive1

Por supuesto, este proveedor expone comandos como rm para eliminar, cat (Get-Content) para revisar el contenido de un archivo, “New-Item <FolderName> -type directory” para crear una carpeta, o “New-Item <nombreArchivo> -type file” para crear un archivo.

Consultar Proveedores

PowerShell proporciona diversos proveedores para acceder a distintas fuentes de datos. Además, es posible que con la instalación de un módulo proporcionado por terceros se incluya un proveedor. Para poner orden en todo esto y tener constancia de los proveedores que hay disponibles para usar en una sesión de PowerShell, tenemos el CmdLet “Get-PSProvider”. Hay que reseñar que este comando, aunque útil, no es mágico… y es incapaz de detectarlos si no han sido cargados previamente. Esto se ve claramente en la siguiente captura, donde primero se obtiene la lista de proveedores “tal cual”. A continuación se importa un módulo, y posteriormente se aprecia cómo la carga del módulo ha agregado un nuevo proveedor a la Shell actual.

PSProvider2

A continuación, toca ver el funcionamiento de alguno de los proveedores más interesantes, como “Registry” o “Certificate”.

Proveedor Certificate

Este proveedor se carga automáticamente la primera vez que intentamos acceder al mismo. Para ello, únicamente hay que acceder a la ruta de certificados para cargar el proveedor y apuntar a la raíz de la unidad (almacén) de certificados para empezar a operar. Como se puede ver, se puede utilizar los comandos “cd” y “ls” para moverse por la estructura jerárquica del almacén, y consultar los contenidos de cada uno. Una de las cualidades en las que usar este proveedr destaca sobre el uso del snap-in de la MMC para el manejo de certificados es la consulta rápida y eliminación de certificados. Un posible escenario en el que interesaría eliminar certificados es a la hora de configurar un WebApplication Proxy para ADFS 3.0, en el caso de que la configuración haya fallado. Cada intento fallido de instalación genera un certificado autofirmado que es conveniente eliminar antes de intentar configurarlo de nuevo. De lo contrario, el almacén de certificados se va a ir llenando de información inútil que puede complicar las futuras labores de mantenimiento.

Cert_provider

Proveedor Registry

Este proveedor se conecta al registro de Windows, y permite operaciones de navegación, consulta y modificación de valores. Para ello se hace uso de los comandos cd (Set-Location) para navegar el registro, ls (Get-ChildItem) para consultar los datos del nivel actual del registro, Get-ItemProperty para consultar información de los elementos individuales, New-Item para agregar entradas al registro, Remove-Item para eliminarlas, Set-Item para modificar valores del registro…

hklm

Más información

¡Y eso es todo por hoy! Dominar cada uno de los proveedores da para un artículo cada uno, pero el objetivo de este capítulo era presentarlos y proporcionar los conceptos básicos para empezar a trabajar con ellos. Se puede consultar más información en los siguientes enlaces:

Políticas en OWA

Hoy os traemos un artículo para hablar de una característica muy concreta de Exchange Online, como son las políticas de OWA (Outlook Web App), pero que focalizan el 80% de las consultas que vemos normalmente:

Outlook Web App mailbox policies: https://technet.microsoft.com/en-us/library/dd335142(v=exchg.150).aspx

OWAPolicy
Centro de administración de EXO

 

Hay que tener en cuenta que aunque estas políticas sólo se aplican cuando los usuarios acceden vía web, en muchos entornos es el único modo de acceso soportado (esto es algo que también se puede modificar), y en el caso de los dispositivos móviles, muchos clientes de correo que está desarrollando Microsoft se basan en el cliente web.

OWA Chrome
OWA en Chrome

 

OWA Android
OWA en Android

 

Como son muchas las opciones que nos ofrecen las políticas de OWA, nos centraremos en las casuísticas más usadas o más requeridas.

Para configurar la mayoría utilizaremos PowerShell:

Set-OwaMailboxPolicy: https://technet.microsoft.com/es-es/library/dd297989(v=exchg.150).aspx

 

Vamos a ir viendo cada uno de los ejemplos, explicando cómo se configura y el resultado que podemos esperar:

Permitir o denegar ciertos ficheros adjuntos:

Como el propio nombre indica, podremos manejar las extensiones de los ficheros adjuntos que recibimos en el correo electrónico para aceptar o denegar específicamente algunas de ellas.

Por ejemplo, OWA por defecto bloquea los archivos que tenga una de las siguientes extensiones:

Extensiones bloqueadas por defecto
Extensiones bloqueadas por defecto

 

Cada política que definamos, incluida la de por defecto, trabaja con 2 listas, la de extensiones bloqueadas y la de extensiones permitidas, y con ellas trabajaremos quitando y añadiendo los tipos que nos interesen:

Office 365 users can’t open or view attachments in Outlook Web App: http://support.microsoft.com/en-us/kb/2852113

 

Ocultar la GAL:

En ciertos escenarios nos puede interesar ocultar la libreta global de direcciones del usuario sin quitarle el acceso completo a la sección de Personas. Para ello utilizaremos el siguiente cmdlet y modificaremos en nuestro caso la política de OWA por defecto:

Está opción también está disponible fácilmente desde la interfaz gráfica:

Ocultar libretas de direcciones
Ocultar libretas de direcciones

 

Este es el resultado en Chrome y en la aplicación de Android:

La sección de Directorio ya no aparece
La sección de Directorio ya no aparece

 

En Android tampoco vemos el Directorio
En Android tampoco vemos el Directorio

 

Deshabilitar la posibilidad de crear Grupos:

Una de las novedades más destacadas últimamente de Office 365 es la posibilidad de crear grupos de usuarios que serán coherentes en los distintos servicios que forman la suite. De esta manera, creando un grupo “Ventas” tendremos automáticamente un buzón compartido, un calendario compartido, un espacio en OneDrive, un grupo en Yammer, etc. Al final la idea es que el grupo funcione como una entidad única y sus miembros puedan colaborar fácilmente entre los distintos productos.

Delivering the first chapter of Groups in Office 365: http://blogs.office.com/2014/09/25/delivering-first-chapter-groups-office-365/

Sin embargo, es posible que no queramos habilitar esta funcionalidad, y como de momento los grupos se crean desde el OWA, la desactivación vendrá de la mano de las políticas de OWA 🙂

Creación de grupos habilitada
Creación de grupos habilitada

 

No aparece la posibilidad de crear un grupo
No aparece la posibilidad de crear un grupo

 

Aviso Grupos deshabilitados
Aviso Grupos deshabilitados

 

No permitir el acceso al OWA desde dispositivos móviles:

Esta opción tiene truco, ya que aunque el acceso desde el dispositivo móvil se hace a través de una aplicación web como es el OWA para iOS o para Android, si queremos deshabilitar el acceso tendremos que tocar la configuración de los servidores CAS (Client Access Server) que proporcionan el acceso a los buzones de los usuarios en Office 365.

Este es el cmdlet necesario para cambiar el valor en todo el array de servidores CAS que nos devuelve la consulta a Office 365:

Y este el resultado en la aplicación de OWA para Android:

OWA deshabilitado en Android
OWA deshabilitado en Android

 

Si tenéis curiosidad, podéis mirar la lista de parámetros con los que podemos jugar para las políticas de OWA y ver la cantidad de posibilidades que tenemos.

Esperamos que os haya parecido interesante.

¡Nos vemos en la próxima!