Los datacenters de Azure están diseminados por todo el mundo. Cuando creamos un servcio en Azure debemos especificar en qué region queremos crear dicho servicio. Ahí se determina el datacenter donde nuestro servicio se ejecutará. Normalmente el criterio para seleccionar una región de Azure tiene que ver con la proximidad de los usuarios que lo usarán. Habitualmente seleccionaremos la región más próxima a los usuarios. Algunos servicios no están disponibles en todas la regiones, algunos sí, y también tenemos la opción de colocar nuestros servicios estratégicamente en varias regiones para así alcanzar a un público global.
Los datacenters de azure están ubicados en las siguientes áreas:
- América: Central US, East US, Eas US 2, NorthCentral US, South Central US, West US, Uest US 2, US Gov Arizona, US Gov Iowa, US Gov Texas, US Gov Virgina, Canada Central, Canada East, Brasil South
- Europa: France Central, France South, Germany Central, Germany NorthEast, North Europe, West Europe, UK South, UK West.
- Asia Pacific: Autralia East, Australia South East, China East, China North, Central India, West India, Japan East, Japan West, Korea Central, Korea South, East Asia, South East Asia.
- Africa: South Africa West, South Africa North
Los datacenters siguen el principio de emparejamiento, de modo que cada datacenter tiene su contraparte en la misma región geográfica, con excepción de Brasil South que empareja con South Central US. El propósito principal de estos emparejamientos es el de permitir soluciones de recuperación frente a desastres permaneciendo en la misma región geográfica. Esto ayuda sobre todo en el cumplimiento con requisitos legales o regulatorios que obligan a mantener los datos bajo una misma legislación y condiciones, cosa que se puede garantizar en el caso de que los datos siempre permanezcan en la misma ubicación geográfica sujeta por las mismas leyes. Además esto proporciona una cobertura por posibles daños o desastre a nivel de datacenter.
Las características generales de los datacenter son las siguientes:
- Los servidores están contenidos en una infraestructura preensamblada en contenedores, pudiendo aprovisionar hasta miles de servidores virturales rápidamente.
- Los datacenter incluyen sistemas de alimentación ininterrumpida, fuentes de alimentación alternativas para todos los componentes además de sistemas de alimentación en backup pudiendo mantener todo el datacenter funcionando en caso de un desastre.
- Redes redundantes de alta velocidad que conectan los clusters en los datacenters
- Redes ópticas de alta velocidad que conectan los datacenters entre sí y con Internet.
- Los datos de un datacenter pueden ser replicados hasta a tres clusteres distintos en caso de que necesitemos alta disponibilidad y entre datacenters emparejados en la misma región para temas de recurperación frente a desastres.
- La seguridad física y de nivel de red en los datacenters de Azure cumple con la mayoria de estándares internacionales.
- Los servidres en cada datacenter estan configurados en cluster, y cada cluster incluye múltiples armarios rack de servidores. La gestión está automatizada para manejar el aprovisionamiento de servicios, escalado dinámico y gestión de fallos de hardware.
Un ejemplo de la versatilidad que ofrece esta estructura de Datacenters y regiones es “Azure Availability Zones”. Para aplicaciones críticas no ofrece protección frente a pérdida de datacenters, opción de Business Continuity and Disaster Recovery (BCDR) y un SLA del 99,99 % en máquinas virtuales.
Se trata de separar la máquinas virtuales a través de las zonas, creando una red virtual con balanceadores en cada Site. La aplicación seguirá funcionando aun cuando hayan serveros problemas en cualquiera de las ubicaciones físicas.
Los pasos de alto nivel como ejemplo serían:
Primero crear un zone-redundant Load Balancer, posteriormente crear dos subnets, una para el entorno Front-end y otra para una posible base de datos. Acto seguido crear máquinas virtuales en tres Availability Zones, configurar la base de datos como zone-redundant, añadir las máquinas virtuales al back-end pool del load balancer y finalmente desplegar la aplicación en las máquinas virtuales