1 Principales servicios en la

nube: arquitectura de Azure y

garantías de servicio
 BIENVENIDA
Azure proporciona una red mundial de centros de datos seguros en
los que puede implementar sus servicios. Obtenga información sobre

la arquitectura física de Azure, cómo se proporciona redundancia y

qué tipo de garantías de servicio ofrece Microsoft.

En este módulo, aprenderá a:

 Explorar la estructura física de la infraestructura de Azure

 Obtendrá información sobre los contratos de nivel de servicio

proporcionados por Azure

2
 Aprenderá a proporcionar sus propios acuerdos de nivel de
servicio para las aplicaciones

Requisitos previos

Ninguno

Introducción 3 min

Descripción de los centros de datos y las regiones en Azure 5 min

Descripción de las zonas geográficas en Azure 3 min

Descripción de las zonas de disponibilidad en Azure 5 min

Descripción de los pares de regiones en Azure 5 min

 Descripción de los Acuerdos de Nivel de Servicio para Azure 6
min

Composición de Acuerdo de Nivel de Servicio entre servicios 5

min

Mejora de la confiabilidad de la aplicación en Azure 8 min

Resumen 5 min

3
 INTRODUCCIÓN
Posee un pequeño negocio con un amplio conjunto de servicios

basados en web con los que los clientes están encantados. La única
dificultad es que algunos clientes experimentan un retraso de red

cuando acceden a los servicios desde ubicaciones lejanas. Este

problema solía ser costoso de resolver: se necesitaban nuevos centros

de datos y costosas redes para conectarse a ellos. Para esto, el

4 surgimiento de la informática en la nube ha facilitado la solución.

Microsoft Azure proporciona una infraestructura confiable, con

redundancia y de bajo consumo que abarca más de 100 instalaciones

de alta seguridad a nivel mundial, vinculadas por una de las mayores

redes del planeta. Azure le permite obtener un alcance

global con presencia local, mantener sus datos seguros y conforme

a las leyes locales, y reducir la contaminación gracias a los centros de

datos de Microsoft que son respetuosos con el medio ambiente.

Objetivos de aprendizaje

En este módulo, aprenderá a:

 Explorar la estructura física de la infraestructura de Azure

  Entender los contratos de nivel de servicio proporcionados
por Azure

 Aprenderá a proporcionar acuerdos de nivel de servicio para

las aplicaciones

5
 DESCRIPCIÓN DE LOS
CENTROS DE DATOS Y
LAS REGIONES EN AZURE
Microsoft Azure está formado por centros de datos ubicados en
todo el mundo. Al aprovechar un servicio o crear un recurso como

una máquina virtual o una base de datos SQL, usa equipamiento físico
en una o varias de estas ubicaciones.

Los centros de datos específicos no se exponen directamente a los

usuarios finales, sino que Azure los organiza en regiones.
6
¿Qué es una región?

Una región es un área geográfica del planeta que contiene al menos

un centro de datos, aunque podrían ser varios centros de datos

cercanos y conectados mediante una red de baja latencia. Azure

asigna y controla los recursos de forma inteligente dentro de cada

región para garantizar que las cargas de trabajo están bien

compensadas.

Al implementar un recurso en Azure, es habitual tener que elegir la

región en la que quiere que se implemente el recurso.

Algunos ejemplos de regiones son: Oeste de EE. UU., Centro de

Canadá, Europa Occidental, Este de Australia y Japón Occidental. A

continuación puede ver todas las regiones disponibles a fecha de

febrero de 2020:
 Importante

Algunos servicios o características de las máquinas virtuales solo están

disponibles en determinadas regiones, por ejemplo, determinados tipos

de almacenamiento o tamaños de máquinas virtuales. También hay

algunos servicios globales de Azure que no requieren que seleccione

una región concreta, como Microsoft Azure Active Directory, Microsoft

Azure Traffic Manager o Azure DNS.

 ¿Por qué es importante?

Azure tiene más regiones globales que cualquier otro proveedor de

servicios en la nube. Esto le da la flexibilidad necesaria para acercar

las aplicaciones a los usuarios estén donde estén. También

proporciona una mejor escalabilidad, redundancia y conserva un
7 mejor alojamiento de datos de sus servicios.

Regiones de Azure especiales

Azure tiene regiones especializadas que se pueden usar al crear las

aplicaciones, en lo referente al cumplimiento normativo o a aspectos

legales. Entre ellas se incluyen las siguientes:

 US DoD (centro), US Gov Virginia, US Gov Iowa y más: son

instancias físicas y lógicas con aislamiento de red de Azure

para asociados y agencias de la administración pública de EE.

UU. Estos centros de datos están operados por personas

estadounidenses sometidas a evaluación e incluyen

certificaciones de cumplimiento adicionales.

 Este de China, Norte de China y más: estas regiones están

disponibles gracias a una exclusiva asociación entre Microsoft

 y 21Vianet, por el cual Microsoft no mantiene directamente
los centros de datos.

Las regiones se utilizan para identificar la ubicación de los recursos,

pero hay otros dos términos que también debe conocer: zonas

geográficas y zonas de disponibilidad.

8
 DESCRIPCIÓN DE LAS
ZONAS GEOGRÁFICAS EN
AZURE
Azure divide el mundo en zonas geográficas que se definen mediante
límites geopolíticos o fronteras de países. Una zona geográfica de

Azure es un mercado diferenciado que normalmente contiene dos o

más regiones que conservan los límites de cumplimiento y residencia

de datos. Esta división tiene varias ventajas.

 Las zonas geográficas permiten a los clientes con necesidades

9 específicas de residencia de datos y cumplimiento normativo
mantener sus datos y aplicaciones cerca.

 Una zona geográfica garantiza que se cumplan los requisitos

de residencia, soberanía, cumplimiento normativo y resistencia

de los datos dentro de las fronteras geográficas.

 Las zonas geográficas son tolerantes a errores hasta el punto

de resistir una interrupción total del funcionamiento de una

región gracias a su conexión con nuestra infraestructura de

red dedicada de alta capacidad.

Sugerencia

La residencia de datos hace referencia a la ubicación geográfica o física

de los datos o la información de una organización. Define los requisitos

legales o normativos impuestos a los datos según el país o región en la

 que residen y es una consideración importante a la hora de planificar
el almacenamiento de datos de su aplicación.

La zonas geográficas se dividen en las siguientes áreas:

 América

 Europa
 Asia Pacífico

 Oriente Medio y África

Cada región pertenece a una sola zona geográfica y se le aplican

reglas de disponibilidad del servicio, cumplimiento y soberanía o

residencia de datos específicas. Consulte la documentación para

obtener más información (hay un vínculo disponible en la unidad de

resumen).
1
0
 DESCRIPCIÓN DE LAS
ZONAS DE
DISPONIBILIDAD EN
AZURE
A fin de proteger la información en caso de error, deberá asegurarse

de que los servicios y datos son redundantes. Si hospeda su

infraestructura, esto requiere la creación de entornos de hardware

duplicados. Azure puede ayudar a que la aplicación tenga alta

disponibilidad a través de zonas de disponibilidad.
1
1 ¿Qué es una zona de disponibilidad?

Las zonas de disponibilidad son centros de datos separados

físicamente dentro de una región de Azure.

Cada zona de disponibilidad consta de uno o varios centros de datos

equipados con alimentación, refrigeración y redes independientes.

Cada una se configura para constituir un límite de aislamiento. Si una

zona deja de funcionar, la otra continúa trabajando. Las zonas de

disponibilidad están conectadas a través de redes de fibra óptica de

alta velocidad privadas.

1
2

Regiones admitidas

No todas las regiones son compatibles con las zonas de

disponibilidad. Para garantizar la resistencia, hay tres zonas

independientes como mínimo en las siguientes regiones.

 Centro de EE. UU.

 Este de EE. UU. 2

 Oeste de EE. UU. 2

 Oeste de Europa

 Centro de Francia
  Norte de Europa

 Sudeste Asiático

Sugerencia

Esta lista de regiones admitidas está aumentando: consulte la

documentación para obtener la información más reciente.

Uso de zonas de disponibilidad en sus aplicaciones

Si quiere usar zonas de disponibilidad para ejecutar aplicaciones

críticas y conseguir una alta disponibilidad en la arquitectura de sus

aplicaciones, coloque sus recursos de proceso, almacenamiento, red y

datos dentro de una zona y replíquelos en otras. Tenga en cuenta que

la duplicación de los servicios y la transferencia de datos entre zonas

1 podrían suponer un costo.
3
Las zonas de disponibilidad son principalmente para las máquinas
virtuales, los discos administrados, los equilibradores de carga y las

bases de datos SQL. Los servicios de Azure que admiten zonas de

disponibilidad se dividen en dos categorías:

 Servicios de zona: ancle el recurso a una zona específica (por

ejemplo, máquinas virtuales, discos administrados, direcciones

IP).

 Servicios de redundancia de zona: la plataforma se replica

automáticamente entre zonas (por ejemplo, almacenamiento

con redundancia de zona, SQL Database).

Consulte la documentación para determinar qué elementos de la

arquitectura puede asociar a una zona de disponibilidad.
1
4
 DESCRIPCIÓN DE LOS PARES DE REGIONES EN AZURE

Las zonas de disponibilidad se crean con uno o varios centros de

datos, y dentro de cada región hay un mínimo de tres zonas. Pero es

posible que un desastre lo suficientemente grande provoque una

interrupción tan grave como para afectar incluso a dos centros de

datos. Por eso Azure también crea pares de regiones.

¿Qué es un par de regiones?

Cada región de Azure se empareja siempre con otra región de la

misma zona geográfica (por ejemplo, EE. UU., Europa o Asia) que se

encuentre como mínimo a 500 km de distancia. Este enfoque

permite la replicación de recursos, como el almacenamiento en la
1
5 máquina virtual, en una zona geográfica, lo que ayuda a reducir la
probabilidad de que se produzcan interrupciones provocadas por

eventos como desastres naturales, disturbios civiles, cortes del

suministro eléctrico o interrupciones de la red física que afecten de

forma simultánea a ambas regiones. Si una región de un par se ve

afectada por un desastre natural, por ejemplo, los servicios

conmutarán por error automáticamente a la otra región de su par de

regiones.

Algunos pares de regiones de ejemplo en Azure son Oeste de EE. UU.

y Este de EE. UU., o Sudeste Asiático y Asia Oriental.
 Puesto que las dos regiones están directamente conectadas y lo

suficientemente lejos como para estar aisladas contra desastres

regionales, puede usarlas para proporcionar redundancia de datos y

servicios de confianza. Algunos servicios ofrecen un almacenamiento

con redundancia geográfica automática utilizando los pares de

regiones.

Entre las ventajas adicionales de los pares de región se incluyen las

siguientes:

1
6  Si hay una gran interrupción de Azure, se da prioridad a una

región de cada par para asegurarse de que al menos una se

restaure lo más rápido posible para las aplicaciones

hospedadas en ese par de regiones.

 Las actualizaciones planeadas de Azure se implementan una a

una en regiones emparejadas para minimizar el tiempo de

inactividad y el riesgo de interrupción de la aplicación.

 Los datos siguen residiendo en la misma zona geográfica que

su pareja (excepto Sur de Brasil) con fines de jurisdicción fiscal

y de aplicación de la ley.

Tener un conjunto ampliamente distribuido de centros de datos

permite a Azure proporcionar una alta garantía de disponibilidad.

Veamos lo que significa.
1
7
 DESCRIPCIÓN DE LOS ACUERDOS DE NIVEL DE SERVICIO PARA
AZURE

Microsoft mantiene su compromiso de ofrecer a los clientes servicios

y productos de alta calidad mediante la adhesión a prácticas,

estándares y directivas operativas completas. Los documentos

formales llamados Acuerdos de Nivel de Servicio (SLA) capturan las

condiciones específicas que definen los estándares de rendimiento

que se aplican a Azure.

 Los Acuerdos de Nivel de Servicio describen el compromiso de

Microsoft a la hora de proporcionar a los clientes de Azure

estándares de rendimiento específicos.
1
8  Hay Acuerdos de Nivel de Servicio para los servicios y
productos individuales de Azure.

 Los Acuerdos de Nivel de Servicio también especifican qué

ocurre si un servicio o producto no puede cumplir la

especificación de un Acuerdo de Nivel de Servicio que lo

controla.

Importante

Azure no proporciona contratos de nivel de servicio para la mayoría de

los servicios en los niveles Gratis o Compartido. Además, los productos

gratuitos como Azure Advisor normalmente carecen de Acuerdo de

Nivel de Servicio.
 Acuerdos de Nivel de Servicio para productos y servicios de
Azure

Hay tres características clave del Acuerdo de Nivel de Servicio para

servicios y productos de Azure:

1. Objetivos de rendimiento

2. Tiempo de actividad y garantías de conectividad

3. Créditos de servicio

Objetivos de rendimiento

Un Acuerdo de Nivel de Servicio define los objetivos de rendimiento

para un servicio o producto de Azure. Los objetivos de rendimiento

que define un Acuerdo de Nivel de Servicio son específicos para cada

1
9 producto y servicio de Azure. Por ejemplo, los objetivos de

rendimiento para algunos servicios de Azure se expresan como

garantías de tiempo de actividad o tasas de conectividad.

Tiempo de actividad y garantías de conectividad

Un Acuerdo de Nivel de Servicio típico especifica los compromisos de

objetivo de rendimiento comprendidos entre 99,9 % ("tres 9") y

99,999 % ("cinco 9"), para cada producto o servicio de Azure

correspondiente. Estos objetivos se pueden aplicar a dichos criterios

de rendimiento como el tiempo de actividad o los tiempos de

respuesta para los servicios.

En la siguiente tabla se indica el tiempo de inactividad acumulativo

potencial para varios niveles del Acuerdo de Nivel de Servicio a lo

largo de varias duraciones:
 Porcentaje de Tiempo de Tiempo de Tiempo de
Acuerdo de inactividad inactividad inactividad
Nivel de por semana por mes por año
Servicio

99 1,68 horas 7,2 horas 3,65 días

99,9 10,1 minutos 43,2 minutos 8,76 horas

99,95 5 minutos 21,6 minutos 4,38 horas

99,99 1,01 minutos 4,32 minutos 52,56 minutos

99,999 6 segundos 25,9 segundos 5,26 minutos

Por ejemplo, las operaciones de escritura del Acuerdo de Nivel de

Servicio para el servicio de Azure Cosmos DB (base de datos) ofrece

un tiempo de actividad del 99,999 %, lo que incluye los compromisos

2
0 de baja latencia de menos de 10 milisegundos en operaciones de

lectura y escritura de la base de datos.

Créditos de servicio

Los Acuerdos de Nivel de Servicio también describen cómo

responderá Microsoft si un producto o servicio de Azure no cumple
las especificaciones de su Acuerdo de Nivel de Servicio.

Por ejemplo, los clientes pueden recibir un descuento en su factura de

Azure como compensación por el bajo rendimiento de un servicio o

producto de Azure. En la siguiente tabla se explica este ejemplo con

más detalle.

La primera columna de la siguiente tabla muestra los objetivos del

Acuerdo de Nivel de Servicio de porcentaje de tiempo mensual para

 una instancia única de máquina virtual de Azure. La segunda columna
muestra el importe del crédito de servicio correspondiente que recibe

si el tiempo de actividad real es menor que el objetivo especificado

en el Acuerdo de Nivel de Servicio durante ese mes.

PORCENTAJE DE TIEMPO DE PORCENTAJE DE CRÉDITO DE

ACTIVIDAD MENSUAL SERVICIO

< 99,9 10

< 99 25

< 95 100

2
1
 COMPOSICIÓN DE
ACUERDO DE NIVEL DE
SERVICIO ENTRE
SERVICIOS
Al combinar los Acuerdos de Nivel de Servicio entre distintas ofertas

de servicio, el acuerdo resultante se denomina Acuerdo de Nivel de

Servicio compuesto. El Acuerdo de Nivel de Servicio compuesto

resultante puede proporcionar valores de tiempo de actividad

superiores o inferiores, dependiendo de la arquitectura de la
2
aplicación.
2

Calcular el tiempo de inactividad

Considere una aplicación web de App Service que escribe en Azure

SQL Database. Estos servicios de Azure actualmente tienen los

siguientes Acuerdos de Nivel de Servicio:

 En este ejemplo, si se produce un error en cualquiera de los servicios,
se producirá un error en toda la aplicación. En general, los valores de

probabilidad individual para cada servicio son independientes. Pero el

valor de Acuerdo de Nivel de Servicio compuesto para esta aplicación

es:

99.95 percent × 99.99 percent = 99.94 percent

Nota

Para el cálculo del Acuerdo de Nivel de Servicio y el tiempo de

inactividad, tenga en cuenta que, cada vez que vea un número con la
etiqueta o el símbolo de "por ciento" (%), dicho número debe dividirse

por 100. Si tuviera que especificar el cálculo de Acuerdo de Nivel de

Servicio arriba, los valores reales serían 0.9995 * 0.9999 = 0.9994.
2
3 Esto significa que la probabilidad de error combinada es mayor que
los valores individuales de Acuerdo de Nivel de Servicio. Esto no es

sorprendente, porque una aplicación que depende de varios servicios

tiene más puntos de error posibles.

Por otra parte, puede mejorar el Acuerdo de Nivel de Servicio

compuesto mediante la creación de rutas de reserva independientes.

Por ejemplo, si la instancia de SQL Database no está disponible,

puede colocar transacciones en una cola para procesarlas más

adelante.
2
4

Con este diseño, la aplicación sigue estando disponible, aunque no

pueda conectarse a la base de datos. Pero se produce un error si la

base de datos y la cola fallan al mismo tiempo.

Si el porcentaje de tiempo previsto para un error simultáneo

es 0,0001 X 0,001, el Acuerdo de Nivel de Servicio compuesto para

esta ruta combinada de una base de datos o una cola sería:

1.0 − (0.0001 × 0.001) = 99.99999 percent

Por lo tanto, si agregamos la cola a nuestra aplicación web, el

Acuerdo de Nivel de Servicio compuesto total es:

99.95 percent × 99.99999 percent = ~99.95 percent

 Tenga en cuenta que hemos mejorado nuestro comportamiento de
Acuerdo de Nivel de Servicio. Pero este enfoque tiene ventajas e

inconvenientes: la lógica de la aplicación es más complicada, tendrá

que pagar más para agregar compatibilidad con la cola y pueden

darse problemas de coherencia de datos que tendrá que afrontar

debidos al comportamiento de reintento.

2
5
 MEJORA DE LA
CONFIABILIDAD DE LA
APLICACIÓN EN AZURE
Puede usar los Acuerdos de Nivel de Servicio para evaluar cómo las
soluciones de Azure cumplen los requisitos empresariales y las

necesidades de sus clientes y usuarios. Al crear sus propios Acuerdos

de Nivel de Servicio, puede establecer objetivos de rendimiento que

se adapten a su aplicación de Azure específica. Este enfoque se

conoce como un Acuerdo de Nivel de Servicio de aplicación.

2 Comprender los requisitos de aplicación

6
La creación de una solución eficaz y de confianza de Azure requiere

conocer los requisitos de carga de trabajo. Después puede

seleccionar servicios, productos de Azure y aprovisionar los recursos

según esos requisitos. Es importante comprender los Acuerdos de

Nivel de Servicio de Azure que definen los objetivos de rendimiento

de los productos y servicios de Azure dentro de la solución. Este

conocimiento le ayudará a crear Acuerdos de Nivel de Servicio de la

aplicación factibles.

En un sistema distribuido, se pueden producir errores. Pueden

producirse errores de hardware. La red puede tener errores

transitorios. En raras ocasiones, todo un servicio o toda una región

pueden experimentar interrupciones, pero incluso estas deben

planificarse.
 Resistencia

Resistencia es la capacidad de un sistema de recuperarse de los

errores y seguir funcionando. No se trata de evitar los errores, sino de

responder a ellos de manera que se evite el tiempo de inactividad o la

pérdida de datos. El objetivo de la resistencia es devolver la aplicación

a un estado plenamente operativo después de un error. Dos aspectos

importantes de la resistencia son la alta disponibilidad y la

recuperación ante desastres.

Cuando diseñe la arquitectura, hágalo buscando la resistencia y

realice un Análisis del modo de error (FMA). El objetivo del análisis del

modo de error es identificar los posibles puntos de error y definir
2 cómo responderá la aplicación a esos errores.
7
Costo y complejidad frente a alta disponibilidad

La disponibilidad se refiere al tiempo que un sistema es funcional y

está en funcionamiento. Maximizar la disponibilidad requiere

implementar medidas para evitar posibles errores en el servicio. Pero

puede ser difícil y caro desarrollar medidas preventivas y a menudo

da como resultado soluciones complejas.

A medida que aumenta la complejidad de la solución, tendrá más

servicios que dependen entre sí. Por tanto, podría omitir posibles
puntos de error en la solución si tiene varios servicios

interdependientes.
 Sugerencia

Por ejemplo: Una carga de trabajo que requiere un tiempo de

actividad del 99,99 % no debe depender de un servicio con un

Acuerdo de Nivel de Servicio del 99,9 %.

La mayoría de proveedores prefieren maximizar la disponibilidad de

sus soluciones de Azure, ya que minimiza el tiempo de inactividad.

Pero a medida que aumente la disponibilidad, también aumentará el

costo y la complejidad de la solución.

Sugerencia

Por ejemplo: Un Acuerdo de Nivel de Servicio que define un tiempo de

2 actividad del 99,999 % solo permite aproximadamente 5 minutos de
8
inactividad total por año.

El riesgo del tiempo de inactividad potencial es acumulativo entre

distintos niveles de Acuerdo de Nivel de Servicio, lo que significa que

las soluciones complejas pueden afrontar mayores desafíos de

disponibilidad. Por lo tanto, la importancia de la alta disponibilidad

para sus requisitos determinará cómo controla la adición de

complejidad y costo con su Acuerdo de Nivel de Servicio de

aplicación.

Consideraciones para definir los Acuerdos de Nivel de Servicio de

aplicación

 Si su Acuerdo de Nivel de Servicio de aplicación define

objetivos de rendimiento de cuatro 9 (99,99 %), recuperarse
 de errores mediante la intervención manual puede no ser
suficiente para cumplir el Acuerdo de Nivel de Servicio. En su

lugar, la solución de Azure debe autodiagnosticarse y

recuperarse automáticamente.

 Es difícil responder a errores con la rapidez suficiente para

satisfacer los objetivos de rendimiento de Acuerdos de Nivel

de Servicio que superen los cuatro 9.

 Considere detenidamente el período de tiempo en el que se

miden los objetivos de rendimiento de Acuerdo de Nivel de

Servicio de la aplicación. Cuanto menor sea la ventana de

tiempo, más estrictas serán las tolerancias. Si define su

Acuerdo de Nivel de Servicio de la aplicación como el tiempo

de actividad por hora o diario, deberá comprender que estas

2
9 tolerancias más estrictas podrían no permitir objetivos de

rendimiento factibles.
 RESUMEN

Microsoft  proporciona más presencia global que cualquier otro

proveedor en la nube, con más de 54 regiones distribuidas en todo el

mundo. Esta infraestructura le ofrece la escala necesaria para acercar

las aplicaciones a los usuarios en todo el mundo. Azure también ha

dedicado regiones para admitir el uso de la administración pública y

las aplicaciones que deben implementarse en China para que pueda

asegurar la residencia y seguridad de los datos y cumplir los

requisitos de resistencia para los clientes independientemente del

tipo de requisitos empresariales que tenga.

Más información

Visite los siguientes vínculos para obtener más información sobre

3
0 algunos de los temas analizados en este módulo.

 Regiones de Azure

 Zonas geográficas de Azure

 Acuerdos de Nivel de Servicio de Azure

 Diseño de aplicaciones resistentes de Azure

 Criterios para elegir un servicio de proceso de Azure