ELZ, Landing Zone, Topología de Red y de Suscripciones.

El primer paso para disponer de infraestructura en la nube es disponer de un Datacenter Virtual estructurado para soportar el crecimiento de una manera controlada y organizada. Si bien es posible que se hagan modificaciones en el futuro y que el diseño no sea el definitivo, sí es importante tratar de que esté lo más estructurado posible para evitar esfuerzos a posteriori.

Es importante definir y seguir una política de nomenclatura que permita identificar los recursos.

Es importante decidir en qué región se van a ubicar los recursos y si se desea implementar redundancia geográfica. Si es así qué región será el respaldo natural.

Es importante definir un espacio de direcciones CIDR que, sobre todo, no presente conflictos con redes ya existentes.

Es importante pensar en el modelo de imputación de costes de cara a identificar cuántas suscripciones crear y con qué criterio. Es este punto es importante pensar si se desea crear una zona común para varios proyectos/unidades de negocio, con servicios compartidos de red o seguridad, por ejemplo, de modo que ciertos elementos de infraestructura no sea necesario implementarlos varias veces.

Es importante pensar en quién y cómo va a gestionar la infraestructura, qué roles y grupos han de tener qué permisos.

Una vez definidos estos criterios el siguiente paso natural es plasmarlo en lo que sería el esqueleto sobre el que implementar las cargas de cómputo.

Desde el punto de vista de recursos serían, al menos, una Virtual Network o VNET con una subnet, pero normalmente se desea segmentar la red por seguridad.

Azure recientemente ha implementado como blueprints un par de conjuntos de elementos que se pueden desplegar en un par de clicks que, además, es cumplen con la normativa ISO 27001.

De manera muy sencilla se puede desplegar una Landing Zone estructurada en una zona de servicios compartidos https://docs.microsoft.com/es-es/azure/governance/blueprints/samples/iso27001-shared/ y una zona de cargas de trabajo con un Application Service Environment y bbdd SQL https://docs.microsoft.com/es-es/azure/governance/blueprints/samples/iso27001-ase-sql-workload/

Diseño de ejemplo del plano técnico para cargas de trabajo de ASE y SQL compatibles con ISO 27001

No obstante como el objetivo de este blog es divulgativo destriparemos la estructura para implementar algo muy similar pero sin utilizar los blueprints.

Es habitual utilizar un modelo en el que se separa una zona de Servicios Compartidos o Tránsito de Red de una zona de Cómputo.

Es habitual también utilizar una Topología de Red HUB & SPOKE en la que una VNET centraliza el flujo de tráfico entre todas las demás, de modo que se puede hacer pasar todo el tráfico por un único punto (Virtual Appliance) mediante Rutas (UDR) y aplicar un filtrado de red adicional a los NSGs, mediante alguna tecnología de Firewall como Azure Firewall.

Ejemplo de modelo HUB & SPOKE con zona de Servicios Compartidos a la derecha y Zona de Cómputo a la Izquierda, en este caso con 3 VNets pertenecientes a 2 proyectos:

Este modelo se apoya en varios elementos básicos de Azure que es necesario conocer para poder desplegar e implementar cargas:

  • VNets y Subnets
  • VNET Peering
  • Network Security Groups (NSGs)
  • Tablas de Rutas definidas por el usuario (Route Tables)
  • Service Endpoints
  • Virtual Appliance (Azure Firewall, Palo Alto)
  • VPN Gateway

En la siguiente entrada entraremos en profundidad con cada uno de ellos.

Resiliencia, Alta disponibilidad, Redundancia, Tolerancia a fallos, Continuidad de Negocio.

Antes de ubicar cualquier aplicación en la nube (o en cualquier otro centro de datos) es importante conocer la criticidad de la aplicación y, en función de ésta, qué consecuencias estamos dispuestos a asumir en caso de que haya un problema.

Fundamentalmente hay dos parámetros que debemos considerar: el RTO y el RPO. Que son el tiempo máximo de indisponibilidad que se está dispuesto a asumir (Restauration Time Objective) y el tiempo máximo de datos que se pueden perder (Restauration Point Objective). En función de estos dos parámetros vamos a construir nuestras aplicaciones con unas arquitecturas más o menos resilientes y/o redundadas y/o respaldadas.

Hay que entender cómo está distribuido Azure y cómo podemos implementar nuestras aplicaciones. Azure tiene Centros de Datos en distintas regiones. En la misma región Azure está separando físicamente los recursos disponibles en distintas Zonas de Disponibilidad o Availability Zones.

Como siempre hay que evaluar el riesgo/beneficio. Podemos construir aplicaciones que estén distribuidas por varias zonas de disponibilidad y regiones, que soporten la indisponibilidad de toda una región de Azure, pero evidentemente su coste y complejidad serán mayores que aplicaciones desplegadas únicamente en una región.

Hay que evaluar exactamente qué queremos. De cara a tener una aplicación tolerante a fallos, podemos implementar una aplicación que preste servicio desde varias regiones en modo activo-activo, ésta soportará el fallo de una región sin pérdida de servicio, pero podría producirse un problema de corrupción de datos, o de indisponibilidad de los sistemas de autenticación, para el que esta medida es inútil.

Hay que evaluar todas las piezas que conforman el servicio y sus dependencias, así como las eventualidades contra las que queremos estar protegidos:

  • el fallo de una máquina virtual?
  • de una Zona de disponibilidad?
  • de una región entera?

Para hacer nuestras aplicaciones resilientes podemos utilizar principalmente balanceadores y clústeres que nos permitan abstraer de elementos únicos de fallo la prestación de servicio.

De cara a disponer de una contingencia que garantice la continuidad de negocio tenemos que pensar en tener los datos necesarios para restaurar el servicio respaldados, preferiblemente en una ubicación lo menos susceptible de fallar a la vez que la principal. Así mismo tenemos que considerar el tiempo que se tardaría en disponer del servicio operativo de nuevo:

  • habría que realizar acciones manuales?
  • quiénes tendrían que participar?
  • cuál es el procedimiento?
  • cuánto se tardaría?

Azure dispone se servicios que pueden gestionar y automatizar todas estas tareas. Azure backup y Azure Site Recovery nos permiten gestionar las copias de seguridad e incluso la replicación de datos y las conmutaciones de servicio en caso de fallo

Vídeo de ASR de Microsoft Mechanics

Subscriptions, Directories, Resource Groups, Management Groups…

Los recursos en el Cloud residen en suscripciones y grupos de recursos. Las suscripciones están relacionadas con un Directorio que las gobierna. Las relaciones entre directorios y suscripciones no son siempre intuitivas. Para complicarlo más una organización puede poseer varias suscripciones, y recursos de distintas suscripciones pueden conectarse.

Debemos pensar en una suscripción como una unidad organizativa, una frontera que facilita la gestión financiera conjunta de los recursos que pertenecen a la suscripción. Sobre la suscripción se asignan permisos a los distintos grupos de administración, en base a distintos roles que se pueden definir. Las suscripciones tienen límites con respecto al número de recursos que pueden crearse dentro de ellos, esos límites en ocasiones pueden ampliarse, no obstante es algo a considerar.

Los directorios a los que pertenecen las suscripciones establecen la relación de los usuarios y grupos sobre los que se pueden asignar permisos.

Algunos consideraciones adicionales, que aumentan la flexibilidad a la hora de reorganizar recursos una vez creados.

  • En una suscripción pueden crearse directorios adicionales.
  • Los recursos pueden moverse entre suscripciones y grupos de recursos.
  • Las suscripciones pueden moverse entre directorios (aunque no todos los recursos soportan la migración)

Los grupos de recursos agrupan recursos dentro de una suscripción, deben usarse para contener recursos cuyo ciclo de vida esté unido, por ejemplo todos los recursos relacionados con una aplicación.

Los Management Groups permiten crear relaciones jerárquicas que organizan las suscripciones en grandes organizaciones con muchas suscripciones, de modo que pueden asignarse políticas que apliquen a conjuntos de suscripciones.

Antes de empezar a crear recursos debemos pensar cómo vamos a organizarlos cuando vaya creciendo:

  • ¿Cómo van a administrarse los recursos, por parte de los mismos Administradores, hay distintos roles?
  • ¿Cómo van a distribuirse los costes de los recursos? por países? por unidades de negocio? por departamentos?
  • ¿Habrá recursos compartidos para evitar incurrir en duplicidades y costes innecesarios?

Analizar este tipo de cuestiones es importante, como también lo es establecer una política de etiquetado de los recursos que facilite su filtrado posterior, y una política de nomenclatura común que permita identificar rápidamente cualquier recurso en función de su nombre.

En cualquier caso estas cuestiones no son bloqueantes, no es imprescindible tomar la decisión acertada desde el principio, todas las organizaciones se han encontrado con estos problemas tras haber iniciado su despliegue de cargas en la nube, y los proveedores de Cloud han ido implementando mejoras que permiten corregir errores o adoptar nuevas estrategias con cada vez más flexibilidad.

Primeros pasos con Azure

Probablemente acercarse a Azure después de haber leído sobre sus capacidades y servicios, y pretender empezar a construir servicios o migrar cargas de trabajo debe ser algo parecido a lo que le ocurre a los escritores cuando se enfrentan al intento de iniciar un libro, el síndrome del folio en blanco.

Creo que lo más interesante para comenzar es imaginar Azure como un datacenter vacío en el que, de momento, no tienes nada, pero que, sin tener que comprar, alquilando, puedes disponer de casi cualquier tecnología, con distintos niveles de gestión.

Hay distintas formas de utilizar el Cloud, la más «primitiva» es provisionar máquinas virtuales como harías en un centro de datos OnPremise (utilizando VMware o Hyper-V, por ejemplo) e instalar en esas máquinas virtuales las aplicaciones y servicios tal y como se hacía tradicionalmente. En este caso de uso las ventajas no son tan significativas como en otros modelos: no tienes que invertir en hierro, pagas por uso (si apagas entornos no productivos cuando no están en uso, por ejemplo), lo te permite hacer pruebas y experimentar sin invertir…

Un caso de uso extendido en los primeros pasos de muchas empresas con el Cloud es utilizarlo como centro de contingencia, para poder prestar servicio en caso de caída del centro de datos principal.

Otro catalizador o motivo para emprender la migración al la nube es el hecho de tener que actualizar infraestructuras o versiones de software obsoletas. Antes de acometer la compra de Hardware, o puesto que hay que actualizar las versiones de software que soportan una aplicación, surge la oportunidad de evitar la inversión y acometer la migración cambiando el modelo, o incluso la aplicación. Es posible consumir la aplicación ofrecida por un proveedor en un modelo SaaS (Software as a Service), cambiar a aplicación, reescribir el código o, sencillamente, migrarla a infraestructura virtualizada en la nube utilizando versiones soportadas.

Pero la verdadera potencia del Cloud viene derivada del uso de servicios gestionados o PaaS (Paltform as a Service) e, incluso, Serverless, en los que no hay máquinas virtuales, e incluso ni siquiera instancias que gestionar. En ciertos casos dar el paso a este tipo de consumo requiere de aplicaciones diseñadas para funcionar bajo estos patrones de utilización, deben estar diseñadas para ello.

A la hora de emprender el viaje a la nube es importante analizar la nube a elegir, es posible y cada vez más habitual utilizar estrategias multinube, ubicando distintos servicios en las nubes públicas de distintos proveedores. Es importante considerar que, si se empiezan a utilizar tecnologías propias del fabricante empezamos a depender de la nube, hay un bloqueo o dependencia de ese proveedor.

Otro punto a considerar es lo que ya tenemos avanzado. Hay nubes en las que es necesario partir de cero. La plataforma de Microsoft está diseñada para permitir aprovechar el esfuerzo empleado en la definición de un servicio de directorio y proveedor de identidades como Active Directory, por ejemplo, en la estrategia de consumo de servicios en su nube pública Azure, además de la integración con servicios como Office 365, por ejemplo.

En cualquier caso, sea cual sea el modelo a elegir, e incluso la nube elegida, hay ciertos cimientos o andamios que es necesario establecer. Que los cimientos sean sólidos permitirá crecer con robustez, sin problemas a medio camino. Es importante invertir en una buena definición del modelo de gobierno, diseño de red y seguridad, estructura organizativa, nomenclatura, gestión de permisos.

Iremos revisando en este blog las opciones y patrones de diseño que nos permitirán hacer un uso exitoso de Azure. Espero que os resulte interesante.