Práctica recomendada 11.2: defina un enfoque para mantener la disponibilidad - SAP Lens

Práctica recomendada 11.2: defina un enfoque para mantener la disponibilidad

Mantenga la disponibilidad con una arquitectura resiliente que pueda sostener el error de un solo componente técnico o servicio de AWS. Entre los mecanismos, se podrían enumerar la capacidad redundante, los balanceadores de carga y los clústeres de software, entre otros.

Sugerencia 11.2.1: evite errores por agotamiento de recursos o deterioro del servicio

Investigue el aprovisionamiento excesivo de recursos, la supervisión proactiva del crecimiento y la limitación del uso mediante la fijación de límites.

El pilar de excelencia operativa cubre las diferentes formas en que puede comprender el estado de su aplicación SAP y garantizar que se toman las medidas correctas, consulte [Excelencia operativa]: 1. Diseñe la carga de trabajo de SAP para permitir la comprensión y la reacción a su estado .

El pilar de rendimiento puede ser de ayuda para orientarse sobre cómo hacer ajustes de tamaño correctos y sobre la capacidad de escalado [rendimiento]: 16. Comprenda las opciones de optimización y rendimiento en curso .

Sugerencia 11.2.2: tenga una estrategia de mantenimiento programado

Si su empresa tiene la obligación de minimizar las interrupciones programadas, debe desarrollar una estrategia de mantenimiento en todos los niveles: aplicación SAP, base de datos, sistema operativo y AWS. Considere lo siguiente:

También debe evaluar las capacidades elásticas de los servicios de AWS para reducir el tiempo de inactividad general del mantenimiento programado mediante el aumento temporal del rendimiento. Por ejemplo, escalar verticalmente el tamaño de la instancia de Amazon EC2 que ejecuta su base de datos para brindar más capacidad de procesamiento y rendimiento de almacenamiento para actividades de actualización, o cambiar los tipos de volúmenes de EBS de gp2 a io2 a fin de mejorar el rendimiento de almacenamiento durante una reorganización de la base de datos.

Sugerencia 11.2.3: proteja los únicos puntos de error de SAP con clústeres de software u otros mecanismos

Puede utilizar una solución de clústeres de alta disponibilidad para la conmutación por error autónoma del único punto de error de SAP (servicios centrales y base de datos) en las AZ.

Existen múltiples soluciones de agrupación en clústeres certificadas por SAP enumeradas en el sitio web de SAP . Las soluciones de agrupamiento en clústeres de SAP son compatibles con los propios proveedores de software de clústeres, no con SAP. SAP solo certifica la solución. Cualquier solución personalizada no está certificada y necesitará el respaldo del creador de la solución.

Si elije no utilizar una solución de agrupamiento en clústeres para su único punto de error (SPOF), considere recurrir a la creación de scripts o a manuales de procedimientos para minimizar los errores asociados con los servicios de restauración.

Sugerencia 11.2.4: capacidad redundante o escalado automático para los componentes que la soportan

Evalúe los cambios de capacidad estáticos, dinámicos y programados para que coincidan con su uso. Examine los requisitos mínimos de capacidad y cómo se verían afectados por errores y mantenimiento. Efectúe un sobreaprovisionamiento cuando sea adecuado para darse el tiempo de recuperarse del error.

Si necesita mantener el 100 % de la capacidad en caso de que se produzca un error en la zona de disponibilidad, debería considerar implementar la aplicación en tres AZ, cada una con el 50 % de la capacidad total requerida.

Además de implementar la capa del servidor de la aplicación SAP en varias AZ, podría considerar escalar soluciones como la que se describe en el siguiente artículo del blog de SAP on AWS, la cual se centra en aprovechar las capacidades de Amazon EC2 Auto Scaling .

Sugerencia 11.2.5: garantice la disponibilidad de capacidad para todos los casos de errores identificados

Los siguientes son ejemplos de situaciones de error que podrían utilizarse para orientar su análisis. La granularidad, cobertura, clasificación o impacto de las situaciones variarán según sus requisitos y arquitectura.

Ejemplos de situaciones de error Riesgo comparativo de ocurrencia
Mantenimiento planificado o controlado Planificado
Recurso agotado o comprometido (uso elevado de la CPU/sistema de archivos lleno/memoria insuficiente/problemas de almacenamiento) Medio
Error de componente distribuido sin estado (por ejemplo, despachadores web) Medio
Error de componente distribuido con estado (por ejemplo, servidores de aplicaciones) Medio
Único punto de error (base de datos o servicios centrales de SAP) Medio
Error de red o de AZ Bajo
Error en servicio central (DNS/Amazon EFS/llamada a la API) Bajo/medio
Corrupción/eliminación accidental/actividades maliciosas/implementación de código defectuoso Bajo
Error de región Muy bajo

Puede obtener más información sobre las reservas de capacidad en [fiabilidad] Sugerencia 10.2.5: investigue estrategias para garantizar la capacidad y en el documento técnico de AWS: Architecture Guidance for Availability and Reliability of SAP on AWS .

Puede consultar las instancias reservadas disponibles en su cuenta de AWS por medio de los informes de instancias reservadas de AWS Cost Explorer .

Sugerencia 11.2.6: utilice servicios de AWS que tengan disponibilidad inherente cuando corresponda

Varios servicios de AWS tienen disponibilidad inherente como parte de su diseño y se ejecutan en varias AZ para lograr un alto grado de disponibilidad. Entre algunos de los servicios relevantes utilizados en el contexto de SAP, se incluyen los siguientes:

Además, los componentes que usan servicios sin estado, como los hosts bastión o SAPRouter, pueden recurrir a grupos de Auto Scaling para lograr una alta disponibilidad.

Sugerencia 11.2.7: siga las prácticas recomendadas de AWS para garantizar la conectividad de la red

Evalúe una o más de las siguientes prácticas recomendadas de AWS para garantizar la resiliencia de la conectividad a través de la red a la región de AWS en uso:

Si su solución de clúster se basa en una IP superpuesta, considere lo siguiente para habilitar el acceso desde el exterior de la VPC: