Práctica recomendada 10.2: seleccione una arquitectura adecuada para sus requisitos de disponibilidad y capacidad
Hay patrones de arquitectura estándar para la disponibilidad de SAP que se ajustan a los requisitos de la mayoría de los clientes que implementan SAP on AWS. Utilice las siguientes sugerencias para determinar qué patrones se ajustan mejor a sus requisitos de disponibilidad y capacidad. Evalúe el riesgo y el impacto de cada situación de error frente a los requisitos de su empresa.
Puede encontrar información adicional sobre la disponibilidad en SAP en el siguiente documento técnico: Architecture Guidance for Availability and Reliability of SAP on AWS .
Sugerencia 10.2.1: identifique todos los componentes y servicios de AWS que son necesarios para su sistema SAP
Identifique todos los componentes técnicos que necesita su sistema SAP; empiece por los principales (base de datos, servidores de la aplicación, servicios centrales, sistemas de archivos globales) y luego identifique los componentes opcionales (por ejemplo, Web Dispatcher, SAProuter o Cloud Connector, entre otros). Determine los servicios de AWS necesarios para admitir estos componentes.
Sugerencia 10.2.2: utilice los SLA, la durabilidad, la disponibilidad y los datos históricos como una guía para la posibilidad de error
La posibilidad del error es subjetiva. Los SLA publicados y los datos de rendimiento pasado solo se pueden utilizar para guiarse ante el riesgo de posibles errores futuros. Sin embargo, la frecuencia supuesta de diversas situaciones sigue siendo una fuente de datos útiles. Algo que estadísticamente tiene la posibilidad de suceder una vez al año podría tener una mayor repercusión en las decisiones de diseño que un error que aún no ha tenido lugar.
La siguiente información se puede utilizar para comprender mejor los servicios:
-
AWS Personal Health Dashboard
proporciona alertas y orientación en materia de corrección cuando AWS experimenta eventos que podrían afectarlo -
Se publican resúmenes posteriores a eventos de AWS
para todos los eventos de servicios importantes que afectan la disponibilidad del servicio de AWS -
El acuerdo de nivel de servicio de computación de Amazon
enumera los SLA de los servicios de computación -
Documentación de AWS: Durabilidad y disponibilidad de Amazon EBS
-
Documentación de AWS: Disponibilidad y protección de datos de Amazon EFS
-
Documentación de AWS: Recomendaciones sobe resiliencia de AWS Direct Connect
También se debe evaluar la posibilidad de error de otros servicios de soporte, incluidos, entre otros, servicios de nombre de dominio, equilibradores de carga y funciones sin servidor.
Puede encontrar más información en el documento técnico Architecture Guidance for Availability and Reliability of SAP on AWS .
Sugerencia 10.2.3: pruebe opciones de agrupación en clústeres, resiliencia y balanceadores de carga
Un sistema SAP se puede distribuir en varios hosts con mecanismos diferentes para garantizar la disponibilidad. Por ejemplo, se puede utilizar una solución de agrupación en clústeres para proteger los únicos puntos de error (por ejemplo, la base de datos de SAP y los servicios centrales de SAP). El nivel de la aplicación SAP se puede escalar horizontalmente, y se puede utilizar el balanceador de carga para hacer que el despachador web tenga una alta disponibilidad.
-
Documentación de AWS: SAP on AWS – IBM Db2 HADR with Pacemaker (SAP on AWS: IBM Db2 HADR con Pacemaker)
-
Documentación de AWS: SQL Server Deployment for High Availability (Implementación de SQL Server para obtener una alta disponibilidad)
-
Documentación de SAP: High Availability Partners (Socios de alta disponibilidad)
Sugerencia 10.2.4: determine la disponibilidad de las familias de instancias de EC2 dentro de las AZ
Algunas familias de instancias de Amazon EC2 (por ejemplo, X y U) no están disponibles en todas las AZ. Consulte con su equipo de cuenta de AWS o con AWS Support para confirmar que las familias de instancias de EC2 que desea utilizar están disponibles en las AZ previstas. Tenga en cuenta que los identificadores lógicos de las AZ podrían ser diferentes en distintas cuentas. Consulte la documentación de AWS para obtener más información.
-
Documentación de AWS: ID de AZ para sus recursos de AWS
Sugerencia 10.2.5: investigue estrategias para garantizar la capacidad
La mejor manera de ayudar a garantizar la capacidad es tener una instancia de tamaño similar disponible en caso de error. Otras estrategias incluyen opciones nativas en la nube (por ejemplo, instancias bajo demanda, recuperación de instancias de EC2) o reasignación de capacidad compartida.
Le recomendamos que establezca un compromiso de capacidad en al menos dos AZ en las que se residan instancias de Amazon EC2 que admitan únicos puntos de error de SAP, de manera que la capacidad esté disponible en el momento en que la necesite.
La capacidad de EC2 se puede reservar utilizando las instancias reservadas zonales o reservas de capacidad bajo demanda . Tanto las instancias reservadas zonales como las reservas de capacidad bajo demanda se pueden compartir entre cuentas de AWS que se encuentran dentro de la misma organización de AWS, lo que posibilita utilizar capacidad de sacrificio de otro entorno en caso de un error significativo (por ejemplo, una falla total en una AZ).
En el siguiente recurso, podrá encontrar más orientación sobre las reservas de capacidad:
-
Documentación de AWS: Architecture Guidance for Availability and Reliability of SAP on AWS
Sugerencia 10.2.6: diseñe su VPC en múltiples AZ
Diseñe su VPC y subredes de manera tal que las instancias se puedan aprovisionar en múltiples AZ, incluso si su diseño inicial solo está pensado para una o dos AZ. Esto le aporta resiliencia a su diseño y ayuda a garantizar que la conectividad y el acceso a los servicios se puedan confirmar con anticipación.
