Información general sobre el fundamento de confiabilidad
La confiabilidad garantiza que tu aplicación puede cumplir los compromisos contraídos con los clientes. La arquitectura de la confiabilidad en el marco de trabajo de la aplicación garantiza que las cargas de trabajo están disponibles y pueden recuperarse de errores a cualquier escala.
La creación de la confiabilidad incluye:
- Garantizar una arquitectura de alta disponibilidad.
- Recuperarse de errores como la pérdida de datos, un tiempo de inactividad importante o incidentes de ransomware.
Para evaluar la confiabilidad de la carga de trabajo mediante los principios que se encuentran en Microsoft Azure Well-Architected Framework, realice la revisión de Microsoft Azure Well-Architected.
Para obtener más información, explore el siguiente vídeo sobre cómo profundizar más en la confiabilidad de la carga de trabajo de Azure:
En el desarrollo de aplicaciones tradicional se ha hecho especial hincapié en el aumento del tiempo medio entre errores. Se invertían esfuerzos en intentar impedir que se produjeran errores del sistema. En la informática en la nube, es necesario tener una mentalidad distinta como consecuencia de diversos factores:
- Los sistemas distribuidos son complejos. Un error en un punto puede caer en cascada en todo el sistema.
- Los costos de los entornos en la nube se mantienen bajos a través del hardware básico. Se deben esperar errores de hardware ocasionales.
- Las aplicaciones suelen depender de servicios externos. Esos servicios podrían no estar disponibles temporalmente o limitar los usuarios de gran volumen.
- Los usuarios actuales esperan una aplicación que esté disponible las 24 horas del día, los 7 días de la semana, sin quedarse nunca sin conexión.
Todos estos factores implican que las aplicaciones en la nube deben diseñarse para esperar errores ocasionales y recuperarse de ellos. Azure tiene muchas características de resistencia ya integradas en la plataforma, como estos ejemplos:
- Azure Storage, Azure SQL Database y Azure Cosmos DB proporcionan replicación de datos integrada entre zonas de disponibilidad y regiones.
- Las instancias de Azure Managed Disks se colocan automáticamente en unidades de escalado de almacenamiento diferentes, con el fin de limitar los efectos de los errores de hardware.
- Las máquinas virtuales de un conjunto de disponibilidad se distribuyen entre varios dominios de error. Un dominio de error es un grupo de máquinas virtuales que comparten una fuente de alimentación común y un conmutador de red. La propagación de máquinas virtuales entre dominios de error limita el efecto de errores de hardware físico, interrupciones de red o interrupciones de energía.
- Las zonas de disponibilidad son ubicaciones físicamente independientes dentro de una región de Azure. Cada zona consta de uno o varios centros de datos equipados con una infraestructura de alimentación, refrigeración y redes independientes. Gracias a las zonas de disponibilidad, puede diseñar y usar aplicaciones y bases de datos que cambian automáticamente entre zonas sin interrupción. Este enfoque garantiza la confiabilidad si se ve afectada una zona. Para más información, consulte regiones de Azure y zonas de disponibilidad.
Incluso con estas características, todavía tiene que crear resistencia en la aplicación. Las estrategias de resistencia pueden aplicarse a todos los niveles de la arquitectura. Algunas mitigaciones son más tácticas por naturaleza, por ejemplo, reintentar una llamada remota después de un error de red transitorio. Otras mitigaciones son más estratégicas, como la conmutación por error de toda una aplicación en una región secundaria.
Las mitigaciones tácticas pueden suponer una gran diferencia. Aunque es poco frecuente que toda una región experimente una interrupción, los problemas transitorios, como la congestión de la red, son más comunes. Dirigirse primero a estos problemas. También es importante contar con una supervisión y un diagnóstico adecuados para detectar los errores en el momento en que se producen, así como para encontrar las causas principales.
Cuando se diseña una aplicación para que sea resistente, se deben comprender los requisitos de disponibilidad. ¿Cuánto tiempo de inactividad es aceptable? La cantidad de tiempo de inactividad es en parte una función del costo. ¿Cuánto cuesta el tiempo de inactividad potencial a su negocio? ¿Cuánto debe invertir para que la aplicación tenga alta disponibilidad?
Temas y procedimientos recomendados
El pilar de confiabilidad trata los siguientes temas y procedimientos recomendados para ayudarle a crear una carga de trabajo resistente:
| Artículo sobre confiabilidad | Descripción |
|---|---|
| Principios de diseño de la confiabilidad | Estos principios críticos se usan como objetivos para evaluar la confiabilidad de una aplicación implementada en Azure. |
| Diseño para la confiabilidad | Tenga en cuenta cómo los sistemas usan zonas de disponibilidad, realizan escalabilidad, responden a errores y otras estrategias que optimizan la confiabilidad en el diseño de aplicaciones. |
| Lista de comprobación de resistencia para servicios de Azure específicos | Todas las tecnologías tienen sus propios modos de error particulares que debe tener en cuenta al diseñar e implementar la aplicación. Use esta lista de comprobación para revisar las consideraciones de resistencia para servicios específicos de Azure. |
| Requisitos funcionales y no funcionales de destino | Los requisitos funcionales y no funcionales de destino, como los destinos de disponibilidad y los destinos de recuperación, permiten medir el tiempo de actividad y el tiempo de inactividad de las cargas de trabajo. Tener destinos claramente definidos es fundamental para obtener un objetivo de trabajo y medición. |
| Resistencia y dependencias | Programar la recuperación de errores en el sistema debe formar parte de las fases de arquitectura y diseño desde el principio para evitar el riesgo de que se produzcan errores. Para que la aplicación funcione por completo, se necesitan dependencias. |
| Alta disponibilidad mediante zonas de disponibilidad | Las zonas de disponibilidad pueden usarse para distribuir una solución en varias zonas dentro de una región, lo que permite que una aplicación siga funcionando cuando se produce un error en una zona. |
| Servicios disponibles | La disponibilidad de los servicios entre regiones de Azure depende del tipo de región. La directiva general de Azure sobre la implementación de servicios en una región determinada se basa principalmente en el tipo de región, las categorías de servicio y la demanda del cliente. |
| Terminología de la zona de disponibilidad | Para conocer mejor las regiones y las zonas de disponibilidad en Azure, le resultará más fácil comprender los términos o conceptos clave. |
| Procedimientos recomendados para la confiabilidad en aplicaciones | Durante la fase de arquitectura, concéntrese en implementar procedimientos que satisfagan los requisitos empresariales, identifique puntos de error y minimice el alcance de los errores. |
| Prueba de confiabilidad | Se deben realizar pruebas periódicas con cada cambio principal para validar los umbrales, los objetivos y los supuestos existentes. |
| Supervisión para la confiabilidad | Obtenga una visión general del mantenimiento de la aplicación. En caso de error, es necesario saber que se ha producido, cuándo y por qué. |
| Patrones de confiabilidad | Las aplicaciones deben diseñarse e implementarse para maximizar la disponibilidad. |