# Fiabilidad
El pilar de la fiabilidad incluye la capacidad de una carga de trabajo para llevar a cabo la función prevista de forma correcta y consistente en el momento esperado. Esto incluye la capacidad de operar y probar la carga de trabajo a través de su ciclo de vida completo. Para muchas empresas, contar con una buena arquitectura en pos de garantizar la fiabilidad es un requisito clave para las cargas de trabajo de SAP. Esto se debe a la vital importancia de muchas de las cargas de trabajo de SAP y a la necesidad de comprender la arquitectura de SAP y las restricciones que esto impone.
Al igual que con otros pilares, le recomendamos revisar AWS Well-Architected Framework, en especial las prácticas recomendadas relacionados con los fundamentos, la administración de cambios y la administración de errores. Al considerar la fiabilidad con SAP Lens, concéntrese primero en tener una comprensión clara y equilibrada de sus requisitos no funcionales en los sistemas individuales, incluidas las prioridades empresariales que impulsan estos requisitos. Luego, diferenciamos entre la disponibilidad y la Desaster Recovery (DR, recuperación de desastres). La disponibilidad se relaciona con situaciones en las que es posible que un usuario final continúe accediendo al sistema SAP, a pesar del error de un componente. Por el contrario, en una situación en la que toda la carga de trabajo deja de estar disponible, se declararía un evento de DR.
# 10. Diseñe para tolerar errores
**¿Cómo diseña su carga de trabajo de SAP para tolerar errores?** Trabaje a partir de los requisitos de su empresa para definir un enfoque con el que pueda cumplir las metas de disponibilidad de sus datos e infraestructura de SAP. Por cada situación de error, los requisitos de resiliencia, la pérdida de datos aceptable y el Mean Time To Recover (MTTR, tiempo medio de recuperación) deben ser proporcionales a la criticidad del componente y las aplicaciones empresariales que admite. Los patrones arquitectónicos proporcionados para la garantizar la disponibilidad de SAP cumplen con la mayoría de los requisitos del cliente; sin embargo, se pueden adaptar de acuerdo con los criterios que defina. Estos criterios deben incluir el riesgo percibido y el impacto de cada error, además de tener en cuenta el costo y el rendimiento. En todos los casos, utilice pruebas iniciales y periódicas para validar sus decisiones.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/design-principle-10.html)
Para más información, consulte la siguiente información:
+ Documentación de AWS: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) incluidas [Failure Scenarios (Situaciones de error)](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-failure-scenarios) y patrones de arquitectura
+ Documentación de AWS: [Amazon Builders' Library: estabilidad estática con AZ](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ Documentación de AWS: [Conectividad de red altamente disponible en varios centros de datos](https://d0.awsstatic.com/aws-answers/AWS_Multiple_Data_Center_HA_Network_Connectivity.pdf)
+ Documentación de SAP: [SAP HANA System Architecture Overview (Información general de la arquitectura del sistema SAP HANA)](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/LATEST/en-US/1b4477a539ab4b77a3bfe2a6835b5e0e.html)
# Práctica recomendada 10.1: convenga las metas de disponibilidad de la carga de trabajo de SAP que se alinean con sus requisitos comerciales
Comprender sus metas de disponibilidad es el primer paso para concentrarse en los factores importantes para su organización. De esta forma, podrá definir los criterios que se pueden utilizar para evaluar sus patrones arquitectónicos.
**Sugerencia 10.1.1: identifique las aplicaciones SAP dentro de su alcance y sus interdependencias**
Identifique las aplicaciones SAP que implementó o implementará en AWS. Comprenda las dependencias de estas aplicaciones, sin importar su ubicación.
**Sugerencia 10.1.2: clasifique los sistemas según el impacto del error**
No existe un estándar general para clasificar sistemas que esté alineado con la disponibilidad planificada y el riesgo de error. Definir sistemas utilizando expresiones como “esencial” o “de gran importancia” puede ayudar a definir patrones, identificar agrupaciones de aplicaciones y justificar costos. Las aplicaciones de producción podrían verse afectadas de manera diferente por una interrupción. Entre los factores por considerar, se podrían encontrar los siguientes:
+ Generación de ingresos o creación de informes de ingresos
+ Orientación externa o interna
+ Negocio principal frente a soporte técnico
+ Alto acoplamiento frente a un bajo acoplamiento con otros sistemas
Los entornos que no son de producción también pueden jugar un rol importante en apoyar de forma indirecta a la empresa. También deben clasificarse según la fase y la escala del proyecto, teniendo en cuenta las rutas de transporte (como empresas habituales y proyectos) y el rol de apoyo (como desarrollo, prueba de unidad, copia de producción y formación).
**Sugerencia 10.1.3: evalúe el impacto empresarial de una interrupción**
El impacto debe ser cuantificable y debe tener en cuenta la duración de la interrupción. Algunos ejemplos de áreas de impacto son el estado y la seguridad, las finanzas, los asuntos legales y normativos y la marca.
**Sugerencia 10.1.4: comprenda los requisitos normativos y de conformidad**
Comprenda los requisitos normativos y de conformidad en cuanto a la residencia de datos y la distancia entre ubicaciones para ayudar a garantizar la continuidad de la empresa.
**Sugerencia 10.1.5: defina el porcentaje mínimo aceptable de tiempo de disponibilidad (uptime)**
Para cada sistema, o grupo de sistemas, acuerde y documente un porcentaje de disponibilidad aceptable que coincida con los requisitos de la empresa. Los siguientes términos se utilizan en este contexto
+ MTTR: tiempo medio de recuperación
+ RTO: objetivo de tiempo de recuperación
+ RPO: objetivo de punto de recuperación
Puede encontrar una explicación completa de los términos en Well-Architected Framework [fiabilidad]: [Disponibilidad](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) . Puede encontrar información adicional sobre la fiabilidad en SAP en el siguiente documento técnico:
+ Documentación de AWS: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
# 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](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) .
**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](https://aws.amazon.com/premiumsupport/technology/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](https://aws.amazon.com/premiumsupport/technology/pes/) 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](https://aws.amazon.com/compute/sla/) enumera los SLA de los servicios de computación
+ Documentación de AWS: [Durabilidad y disponibilidad de Amazon EBS](https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/durability-and-availability-3.html)
+ Documentación de AWS: [Disponibilidad y protección de datos de Amazon EFS](https://aws.amazon.com/efs/faq/#Data_protection_and_availability)
+ Documentación de AWS: [Recomendaciones sobe resiliencia de AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/?nc=sn&loc=4&dn=2)
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](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) .
**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 NetWeaver Deployment and Operations Guide for Windows - High Availability System Deployment (Guía de operaciones e implementación de SAP NetWeaver para Windows: implementación del sistema de alta disponibilidad)](https://docs.aws.amazon.com/sap/latest/sap-netweaver/net-win-high-availability-system-deployment.html)
+ Documentación de AWS: [SAP on AWS – IBM Db2 HADR with Pacemaker (SAP on AWS: IBM Db2 HADR con Pacemaker)](https://docs.aws.amazon.com/sap/latest/sap-ibmdb2/sap-ibm-pacemaker.html)
+ Documentación de AWS: [SQL Server Deployment for High Availability (Implementación de SQL Server para obtener una alta disponibilidad)](https://docs.aws.amazon.com/sap/latest/sap-netweaver/sql-server-deployment-for-high-availability.html)
+ Documentación de SAP: [High Availability Partners (Socios de alta disponibilidad)](https://wiki.scn.sap.com/wiki/display/SI/High+Availability+Partner+Information)
**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](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)
**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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html) o [reservas de capacidad bajo demanda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-using.html) . 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](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
**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.
# Práctica recomendada 10.3: defina un enfoque para ayudar a garantizar la disponibilidad de datos críticos de SAP
Los datos empresariales de una aplicación SAP se almacenan principalmente dentro de la base de datos. No obstante, la base de datos también puede alojar datos basados en archivos de archivos binarios (por ejemplo, archivos ejecutables, bibliotecas y scripts, entre otros), configuraciones e interfaces. El enfoque seleccionado debe ser capaz de examinar las opciones de durabilidad, coherencia y recuperación para que coincidan con la criticidad de los datos y el nivel de pérdida de datos aceptable (RPO).
**Sugerencia 10.3.1: evalúe los requisitos de MTTR e identifique cómo se pueden cumplir**
En [fiabilidad] [Sugerencia 10.1.5: defina el porcentaje mínimo aceptable de tiempo de disponibilidad (uptime)](best-practice-10-1.md) , habrá definido los requisitos de MTTR para cada una de sus aplicaciones. Después de evaluar el riesgo de errores y los mecanismos para proteger la disponibilidad del sistema, confirme que se pueden cumplir sus requisitos y documente las expectativas de MTTR frente a cada situación de error. Si es necesario hacer concesiones por costo, complejidad o coherencia consulte con los propietarios de la empresa para llegar a un acuerdo.
**Sugerencia 10.3.2: determine en qué situaciones de error sería necesaria una recuperación desde la copia de seguridad**
La copia de seguridad suele ser un mecanismo secundario para garantizar o recuperar la disponibilidad, pero la mayoría de las arquitecturas dependerán en cierta medida de las copias de seguridad. Los siguientes son ejemplos de situaciones de error que podrían utilizarse para orientar su análisis. La granularidad de las situaciones, la clasificación y el impacto variarán según sus requisitos y arquitectura.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/best-practice-10-3.html)
**Sugerencia 10.3.3: determine dónde si es necesario hacer una replicación de datos**
La replicación de datos se utiliza para mejorar la fiabilidad, ya que se tienen copias de los mismos datos en varias ubicaciones. Suele ser un requisito para los sistemas con un RPO bajo. Al determinar si se requiere replicación para la disponibilidad o la recuperación, considere si el servicio es zonal (por ejemplo, Amazon EC2 y Amazon EBS y las bases de datos compatibles) o regional (por ejemplo, almacenamiento compartido o Simple Storage Service [Amazon S3]).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/best-practice-10-3.html)
[AWS DataSync](https://aws.amazon.com/datasync/) se puede utilizar para proteger [Amazon EFS](https://aws.amazon.com/premiumsupport/knowledge-center/datasync-transfer-efs-cross-region/) y [Amazon FSx](https://aws.amazon.com/blogs/aws/aws-datasync-update-support-for-amazon-fsx-for-windows-file-server/) en las diferentes regiones, si es necesario.
[CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) se replica continuamente a nivel de la instancia entre las AZ o las regiones de disponibilidad, incluidas las cuentas de AWS.
**Replicación de Simple Storage Service (Amazon S3)**
Las copias de seguridad y otros métodos de almacenamiento de objetos se pueden guardar en Simple Storage Service (Amazon S3) y replicar por medio de [la replicación de Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/features/replication/) .
**Sugerencia 10.3.4: cree una estrategia para garantizar la consistencia de los datos de configuración y de los archivos binarios**
Es importante tener datos de configuración y archivos binarios consistentes para garantizar un comportamiento predecible y una configuración probada tras la ocurrencia de un error. Esto puede comprender paquetes de sistema operativo, parámetros de aplicación y configuración de clústeres. Determine cómo garantizar la consistencia en todas las instancias de una aplicación, incluidas aquellas cuyo propósito es aportar resiliencia (por ejemplo, servidores de aplicación adicionales y nodos de base de datos secundarias, entre otros).
Amazon EFS, Amazon FSx y Simple Storage Service (Amazon S3) brindan una ubicación duradera para archivos binarios compartidos o configuraciones administradas de forma centralizada.
Consulte [excelencia operativa] [Práctica recomendada 2.1: utilice el control de versiones y la administración de configuración](best-practice-2-1.md) para los mecanismos de control de versiones y administración de la configuración.
**Sugerencia 10.3.5: tenga un enfoque integral para la consistencia de los datos**
El enfoque para garantizar la consistencia de los datos críticos de SAP no solo debe centrarse en un único conjunto de datos, sino que también debe tener en cuenta las dependencias dentro de los conjuntos de datos y los sistemas, así como las que existen entre ellos. Por ejemplo, si necesitara recuperar un sistema SAP BW, pero no los sistemas de origen de los que se abastece, ¿cuál sería el impacto sobre los indicadores de cambio y con qué mecanismos garantizaría una recuperación consistente?
**Sugerencia 10.3.6: cree una estrategia para interfaces que permita reproducir o reenviar datos**
En el caso del intercambio de datos entre sistemas, determine si la integración está débilmente acoplada y si los datos se pueden reproducir o reenviar, ya sea en el origen o en el destino. Revise si hay capacidades de cola para permitir que la situación se suspenda o se almacene en caché durante una interrupción.
**Sugerencia 10.3.7: evalúe utilizar un búnker de datos**
Las situaciones de error que dan como resultado que los datos en línea se vuelvan inutilizables o no estén disponibles debido a, por ejemplo, una eliminación accidental o un acto malicioso pueden requerir un enfoque diferente para ayudar a garantizar que los datos estén protegidos o sean recuperables.
Si bien la mejor defensa es la prevención por medio de un marco de seguridad que garantice el aislamiento de la red y el control de acceso, el impacto debe considerarse en el contexto de la recuperación y la resiliencia.
Se suele utilizar una *cuenta de copia de seguridad de solo escritura* con un período de retención reducido en esta situación inusual, pero de repercusiones potencialmente grandes.
+ SAP Lens [seguridad]: [Práctica recomendada 8.3: proteja sus mecanismos de recuperación de datos para resguardarse contra amenazas](best-practice-8-3.md)
# Práctica recomendada 10.4: valide el diseño en función de un grupo de criterios basados en sus requisitos empresariales
Establezca un conjunto de criterios basados en los requisitos de su empresa, equilibrando el riesgo de error, el impacto en la empresa y las compensaciones aceptables. Utilice estos criterios para validar el diseño y hacer los ajustes necesarios.
**Sugerencia 10.4.1: evalúe el costo que una interrupción supondría para su empresa**
Los errores, ya sea de los servicios de AWS o de los componentes de SAP, afectarán su sistema SAP de manera diferente según las estrategias de resiliencia y recuperación que aplique. El tipo de error determinará la duración de la interrupción (RTO) y la posible pérdida de datos (RPO).
Por cada error, evalúe el riesgo de una interrupción y el costo para su empresa. Por ejemplo, ¿existen procesos de generación de ingresos que se verán afectados? Y, en tal caso, ¿cuál sería costo por hora asociado con la falta de disponibilidad del sistema?
**Sugerencia 10.4.2: evalúe el costo de su arquitectura**
En los entornos de SAP, los elementos más costosos de la factura mensual de AWS generalmente están relacionados con Amazon EC2 y los servicios de almacenamiento. Comprenda las implicaciones de costos, de manera que pueda seleccionar la mejor arquitectura para cumplir con sus requisitos de fiabilidad. Entre algunos colaboradores clave, se encuentran:
+ Los patrones de implementación que no maximizan la utilización del hardware
+ Las copias redundantes de datos
+ Los costos de licencia del sistema operativo
+ Los costos de licencia del software de agrupación
+ Los costos asociados con el mantenimiento, las pruebas y los recursos calificados
Consulte [optimización de costos] [las prácticas recomendadas para la optimización de costos](cost-optimization.md) para más detalles.
**Sugerencia 10.4.3: evalúe su diseño en función de los otros pilares del marco**
La fiabilidad no se puede diseñar de forma aislada, sino que debe evaluarse en función del resto de los pilares de AWS Well-Architected Framework. A continuación, se enumeran algunos ejemplos de preguntas que podría hacer para llevar a cabo dicha evaluación:
+ Excelencia operativa: ¿tiene la experiencia y las habilidades para administrar la solución?
+ Seguridad: ¿están protegidos sus datos durante la replicación, la recuperación, etc.?
+ Rendimiento: ¿la replicación o la actividad de la copia de seguridad afectan el rendimiento del usuario?
+ Optimización de costos: ¿el costo de la solución se alinea con el riesgo asumido?
# 11. Detecte los errores y reaccione ante ellos
**¿Cómo detecta y reacciona ante errores que afectan su carga de trabajo de SAP?** Diseñe cómo el software o los procedimientos operativos pueden ayudar a garantizar el estado y la resiliencia de su carga de trabajo de SAP. Supervise los errores potenciales y reales, centrándose, de ser posible, en la prevención. Considere si un componente está distribuido o es un único punto de error y diseñe una solución de resiliencia que minimice el impacto en su carga de trabajo. Además de realizar pruebas periódicamente para comprender su perfil de riesgo, examine cómo la automatización podría mejorar su resiliencia.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/design-principle-11.html)
Para obtener más información, consulte lo siguiente:
+ Documentación de AWS: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) incluido [Failure Scenarios](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-failure-scenarios) y [Architecture Patterns (Patrones de arquitectura)](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-patterns)
# Práctica recomendada 11.1: supervise errores de la aplicación SAP, de los recursos de AWS y de la conectividad
La supervisión de errores de la aplicación SAP, de los recursos de AWS y de la conectividad ayudan a reaccionar ante errores potenciales o reales de manera oportuna.
**Sugerencia 11.1.1: utilice AWS Personal Health Dashboard y las notificaciones**
El [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) brinda una vista personalizada del estado de los servicios de AWS que potencian sus aplicaciones, lo que le permite ver rápidamente cuándo hay problemas que afectan su carga de trabajo de SAP. Por ejemplo, en el caso que se pierda un volumen de [Amazon Elastic Block Store (Amazon EBS)](https://aws.amazon.com/ebs/) asociado con una de sus instancias de [Amazon EC2](https://aws.amazon.com/ec2/) .
El panel también brinda notificaciones de proyecciones, y podrá configurar alertas en múltiples canales, incluido el correo electrónico, de modo que reciba información oportuna y relevante para ayudar a planificar los cambios programados. Por ejemplo, en el caso de que se lleven a cabo actividades de mantenimiento del hardware de AWS que afecten a una de sus instancias de [Amazon EC2,](https://aws.amazon.com/ec2/) recibirá una notificación más detallada para ayudarlo a planificar y tratar de manera oportuna cualquier problema asociado con el cambio que va a ocurrir.
**Sugerencia 11.1.2: evalúe los servicios de AWS para comprender el estado de su sistema SAP**
AWS brinda una cantidad de [servicios de administración y de gobernanza](https://aws.amazon.com/products/management-and-governance/) que debe evaluar. Céntrese en las métricas que indican un error potencial o real, como errores en la instancia de EC2, utilización elevada de la CPU y utilización del sistema de archivos.
Consulte el pilar de la excelencia operativa para obtener más detalles:
+ SAP Lens [excelencia operativa]: [Práctica recomendada 1.1: implemente los requisitos previos para la supervisión de SAP on AWS](best-practice-1-1.md)
+ SAP Lens [excelencia operativa]: [Práctica recomendada 1.4: implemente la supervisión de la configuración de la carga de trabajo](best-practice-1-4.md)
**Sugerencia 11.1.3: evalúe la capacidad de las herramientas de SAP para supervisar errores**
Las herramientas de SAP, como Solution Manager y Landscape Manager, permiten ver cualquier dato de supervisión en el contexto de la aplicación. Las siguientes soluciones de supervisión están disponibles en SAP. Revise cualquier costo de licencia adicional como parte de la evaluación de estas herramientas.
+ Documentación de SAP: [SAP Focused run (Ejecución de SAP Focused)](https://support.sap.com/en/alm/sap-focused-run.html)
+ Documentación de SAP: [SAP Solution Manager](https://support.sap.com/en/alm/solution-manager.html)
+ Documentación de SAP: [SAP Landscape Management (LaMa)](https://help.sap.com/viewer/lama_help)
+ Notas de SAP: [2574820 - SAP Landscape Management Cloud Manager for Amazon Web Services (AWS)](https://launchpad.support.sap.com/#/notes/2574820) [Se necesita acceso al portal de SAP]
**Sugerencia 11.1.4: evalúe herramientas de terceros para la supervisión de AWS y SAP**
Las siguientes soluciones de supervisión están disponibles en AWS Marketplace. Debe evaluar estas y otras herramientas de terceros.
+ Documentación de AWS: [Soluciones de supervisión en AWS Marketplace](https://aws.amazon.com/marketplace/b/2649280011?ref_=mp_nav_category_2649280011)
# 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](design-principle-1.md) .
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](design-principle-16.md) .
**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:
+ Uso de soluciones de replicación y clúster para alternar el nodo principal y secundario
+ Exceso de capacidad y mecanismos para escalar y reducir verticalmente a fin de facilitar las interrupciones consecutivas
+ Uso de un enfoque de revisión en tiempo real para el sistema operativo, en caso de ser posible
+ [SUSE Linux Enterprise Live Patching](https://www.suse.com/products/live-patching/)
+ [Documento técnico Red Hat Reducing Downtime for SAP HANA (Reducción del tiempo de inactividad para SAP HANA)](https://www.redhat.com/cms/managed-files/pa-sap-hana-reducing-downtime-overview-f22788pr-202004-en.pdf)
+ Documentación de AWS: [AWS Systems Manager Patch Manager Patch Groups (Grupos de parches de AWS Systems Manager Patch Manager)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ Notas de SAP: [1913302 - HANA: Suspend DB connections for short maintenance tasks (HANA: suspenda conexiones de base de datos para tareas de mantenimiento breves)](https://launchpad.support.sap.com/#/notes/1913302) [Se necesita acceso al portal de SAP]
+ Notas de SAP: [2077934 - Rolling kernel switch in HA environments (2077934: Rolling Kernel Switch en entornos de alta disponibilidad)](https://launchpad.support.sap.com/#/notes/2077934) [Se necesita acceso al portal de SAP]
+ Notas de SAP: [953653 - Rolling Kernel Switch](https://launchpad.support.sap.com/#/notes/953653) [Se necesita acceso al portal de SAP]
+ Notas de SAP: [2254173 - Linux: Rolling Kernel Switch in Pacemaker-based NetWeaver HA environments (Linux: Rolling Kernel Switch en entornos de alta disponibilidad de NetWeaver basados en Pacemaker)](https://launchpad.support.sap.com/#/notes/2254173) [Se necesita acceso al portal de SAP]
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](https://wiki.scn.sap.com/wiki/display/SI/Certified+HA-Interface+Partners) . 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](https://aws.amazon.com/ec2/autoscaling) .
+ Blog de SAP on AWS: [Using AWS to enable SAP Application Auto Scaling (Uso de AWS para habilitar el escalado automático de aplicaciones SAP)](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
+ Documentación de AWS: [Amazon EC2 Instance Types for SAP](https://aws.amazon.com/sap/instance-types/)
+ Notas de SAP: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products (Aplicaciones SAP en AWS: bases de datos, sistemas operativos y productos de Amazon EC2 compatibles)](https://launchpad.support.sap.com/#/notes/1656099) [Se necesita acceso al portal de SAP]
**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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/best-practice-11-2.html)
Puede obtener más información sobre las reservas de capacidad en [fiabilidad] [Sugerencia 10.2.5: investigue estrategias para garantizar la capacidad](best-practice-10-2.md) y en el documento técnico de AWS: [Architecture Guidance for Availability and Reliability of SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) .
Puede consultar las instancias reservadas disponibles en su cuenta de AWS por medio de los [informes de instancias reservadas de AWS Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-default-reports.html#ce-ri-reports) .
**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:
+ Servicio de AWS: [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html)
+ Servicio de AWS: [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)
+ Servicio de AWS: [Route 53](https://aws.amazon.com/route53/faqs/)
+ Servicio de AWS: [Puerta de enlace de tránsito de AWS](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html)
+ Servicio de AWS: [Amazon S3](https://aws.amazon.com/s3/)
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:
+ Documentación de AWS: [Kit de herramientas de resistencia de AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ Documentación de AWS: [AWS VPN CloudHub](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-vpn-cloudhub.html)
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:
+ Documentación de AWS: [SAP on AWS High Availability with Overlay IP Address Routing (SAP on AWS: alta disponibilidad con enrutamiento de direcciones IP superpuestas)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html)
# Práctica recomendada 11.3: defina un enfoque para restaurar la disponibilidad del servicio
La restauración de la disponibilidad supone que, para una situación de error específica, se producirá alguna pérdida de servicio. El enfoque de restauración adoptado debe incluir examinar la cantidad de tiempo necesario para restaurar el servicio y las acciones necesarias para alcanzar el objetivo de disponibilidad.
**Sugerencia 11.3.1: habilite la recuperación de instancias en instancias de EC2**
Puede crear una alarma de Amazon CloudWatch que supervise una instancia de Amazon EC2 y recupere automáticamente la instancia si se daña debido a un error de hardware subyacente. Con esta acción, se puede eliminar la necesidad de una intervención manual, pero los tiempos de inicio, reinicio de la aplicación y de carga deben tenerse en cuenta en el Objetivo de tiempo de recuperación (RTO). Si tiene la intención de utilizar una solución de clúster para protegerse contra errores de hardware, debe evaluar si la recuperación de instancias es compatible con la solución de clúster.
+ Documentación de AWS: [Recuperación de instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
**Sugerencia 11.3.2: prepare una estrategia para reconstruir instancias de EC2 utilizando AMI e infraestructura como código**
El beneficio de la infraestructura como código es la capacidad de crear y deshacer entornos enteros mediante programación. Si su arquitectura está diseñada para la resiliencia, puede implementar un entorno en cuestión de minutos con ayuda de las [plantillas de AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) o [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) . La automatización es crucial para mantener una alta disponibilidad y lograr una rápida recuperación.
Deberá evaluar los siguientes servicios de AWS como parte de su estrategia:
+ Servicio de AWS: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ Servicio de AWS: [AWS Launch Wizard para SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html)
+ Servicio de AWS: [Kit de desarrollo de la nube de AWS](https://aws.amazon.com/cdk/)
+ Blog de SAP on AWS: [DevOps for SAP (DevOps para SAP)](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**Sugerencia 11.3.3: comprenda los errores de Amazon EBS**
Que se produzcan errores en uno o más volúmenes de EBS podría afectar la disponibilidad y la durabilidad de su carga de trabajo de SAP. Por lo tanto, debe comprender las tasas de error, los mecanismos de notificación y las opciones de recuperación de Amazon EBS.
+ Documentación de AWS: [Duración de Amazon EBS](https://aws.amazon.com/ebs/features/#Amazon_EBS_availability_and_durability)
+ Documentación de AWS: [Monitorear el estado de los volúmenes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html)
+ Servicio de AWS: [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)
+ Documentación de AWS: [Recuperación de volúmenes con instantáneas de Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
**Sugerencia 11.3.4: prepare una estrategia para reaccionar a las notificaciones de AWS Personal Health Dashboard**
Debe tener una estrategia para recibir notificaciones de AWS Personal Health Dashboard y actuar en función de ellas. Esto podría incluir el uso de CloudWatch para iniciar Amazon SNS o la integración con sus herramientas de ITSM a través de [la API de AWS Health](https://docs.aws.amazon.com/health/latest/ug/health-api.html) .
**Sugerencia 11.3.5: asegúrese de estar protegido contra eventos accidentales o maliciosos que afecten la disponibilidad**
Debe tener en cuenta los siguientes enfoques para asegurarse de estar protegido contra eventos accidentales o maliciosos que podrían afectar la disponibilidad de su carga de trabajo de SAP.
+ Implemente un [principio de privilegio mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) y aplique la separación de funciones dentro de AWS Identity and Access Management.
+ Siga la guía que se detalla en el artículo del Centro de conocimientos de AWS [How do I protect my data against accidental EC2 instance termination? (¿Cómo protejo mis datos contra la terminación de una instancia de EC2?)](https://aws.amazon.com/premiumsupport/knowledge-center/accidental-termination/)
+ Siga las [prácticas recomendadas establecidas para Amazon EC2.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
+ También le recomendamos seguir la guía de seguridad que se detalla en [seguridad] [Práctica recomendada 8.3: proteja sus mecanismos de recuperación de datos para resguardarse contra amenazas.](best-practice-8-3.md)
**Sugerencia 11.3.6: identifique dependencias adicionales a las de su carga de trabajo de SAP enAWS**
Comprenda las dependencias subyacentes de sus procesos empresariales de SAP, incluidos los servicios compartidos y los componentes o sistemas de soporte. Entre algunos ejemplos, se incluyen Active Directory, DNS, proveedores de identidad, servicios de SaaS y sistemas locales. Evalúe el impacto del error y las mitigaciones necesarias.
# Práctica recomendada 11.4: realice pruebas periódicas de resiliencia
Pruebe periódicamente la resiliencia en situaciones de errores críticos para demostrar que el software y los procedimientos tienen un resultado predecible. Evalúe cualquier cambio en la arquitectura, software o personal de soporte para determinar si es necesario realizar pruebas adicionales.
**Sugerencia 11.4.1: defina las situaciones de error críticas dentro de su alcance en función de los requisitos de su empresa**
Debe definir qué situaciones de error críticas puede probaren función de sus requisitos empresariales. Los siguientes son ejemplos de situaciones de error que podrían servir de guía para su análisis. La granularidad, cobertura, clasificación o impacto de las situaciones variarán según sus requisitos y arquitectura.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/best-practice-11-4.html)
**Sugerencia 11.4.2: defina un conjunto de casos de prueba para simular errores críticos**
Debería tener un conjunto completo de pruebas definidas para simular las situaciones de error críticas que afectarían su carga de trabajo de SAP.
Debe tener en cuenta que, para algunas situaciones de error, es posible que una simulación no represente completamente el error real que ocurriría. Por ejemplo, para simular un problema de hardware, no puede causar un error en una instancia de EC2, pero, en el caso de las instancias basadas en Nitro, puede generar un pánico del kernel para que la instancia se reinicie.
Además, [AWS Fault Injection Simulation](https://aws.amazon.com/fis/) está diseñado para ayudar a simular errores dentro de sus recursos de AWS.
+ Documentación de AWS: [Guía de configuración de alta disponibilidad para SAP HANA on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-ha-configuration.html)
+ Documentación de AWS: [Enviar una interrupción de diagnóstico](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/diagnostic-interrupt.html#diagnostic-interrupt-prereqs)
**Sugerencia 11.4.3: defina el comportamiento esperado para cada caso de prueba**
Debería documentar una serie de resultados esperados que sirvan como estándares de referencia de sus pruebas.
**Sugerencia 11.4.4: defina un enfoque para evaluar el impacto de un cambio y las pruebas posteriores requeridas**
Debería definir un enfoque para evaluar el impacto de un cambio en su entorno y el número de pruebas que se deben realizar tras ese cambio con el fin de garantizar que no invalide su enfoque de disponibilidad y fiabilidad. Entre algunos ejemplos de cambios, se incluyen actualizaciones de software, revisiones y cambios de parámetros.
**Sugerencia 11.4.5: defina un cronograma de pruebas**
Asegúrese de contar con un cronograma de pruebas en el que se contemple la implementación inicial, las pruebas de los cambios y la validación periódica de su entorno.
**Sugerencia 11.4.6: revise los resultados de las pruebas**
Según los resultados de la prueba, identifique cualquier mejora en los casos de prueba, la configuración o la arquitectura.
**Sugerencia 11.4.7: defina las actividades requeridas para hacer una reversión a un estado previo a la prueba**
En cada prueba, debe definir las actividades necesarias para revertir el estado anterior a la prueba. Esto es para garantizar que cada caso de prueba esté aislado de otras pruebas y que la prueba no afecte la disponibilidad y fiabilidad de un sistema de producción.
# Práctica recomendada 11.5: automatice la reacción ante errores
Puede minimizar el impacto en el servicio al automatizar la respuesta ante errores. Diseñe acciones automáticas para responder ante errores y situaciones de deterioro de la capacidad o pérdida de conectividad. Asegúrese de que se definan criterios de arbitraje claros para evitar falsos positivos.
**Sugerencia 11.5.1: evalúe su automatización por riesgo de corrupción**
Ante la presencia de componentes en los que hay riesgo de corrupción de datos, asegúrese de que su solución de alta disponibilidad (HA) tenga en cuenta el método de replicación de datos, la estabilidad de la conectividad y el conocimiento de aplicaciones, y que evite situaciones de “cerebro dividido”.
**Sugerencia 11.5.2: evalúe los mecanismos de comprobación de estado que inician la automatización**
Los controles de estado deben diseñarse con controles para ayudar a garantizar que las automatizaciones no se inicien como resultado de falsos positivos.
# 12. Haga un plan de recuperación de datos
**¿Cómo planifica la recuperación lógica de datos para su carga de trabajo de SAP?** Defina un enfoque a partir de los requisitos comerciales que se centre en recuperar o reconstruir sus datos comerciales. Dependiendo de cómo haya diseñado la resiliencia, diferentes situaciones pueden encajar en esta categoría. Como mínimo, su enfoque de creación de copias de seguridad o de DR debe protegerlo contra la eliminación accidental, la corrupción de datos lógicos y el malware. Sea deliberado acerca de la decisión de restaurar y tenga en cuenta el tiempo para volver al servicio y las dependencias entre los sistemas.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/sap-lens/design-principle-12.html)
# Práctica recomendada 12.1: establezca un método para la recuperación coherente de datos empresariales
Defina planes de recuperación de datos que puedan ayudar a garantizar la coherencia de los datos empresariales para un sistema individual en caso de pérdida o corrupción de datos.
**Sugerencia 12.1.1: asegúrese de que las copias de seguridad de la base de datos sean coherentes mediante el uso de mecanismos de copia de seguridad que conozcan el estado de la base de datos.**
SAP brinda mecanismos para hacer una integración con la capacidad de creación de copias de seguridad de un proveedor de base de datos (por ejemplo, brtools) y proporciona visibilidad dentro de las consolas de administración o transacciones de SAP. Además, hay opciones para integrar proveedores de copia de seguridad de terceros o almacenar soluciones que incluyen [AWS Backint Agent para SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html) . Estas opciones admitidas tienen conocimiento del estado de la base de datos, puesto que capturan cambios continuamente o desactivan la base de datos (pausando o reduciendo la actividad) mientras se toma una copia consistente, por ejemplo, al usar instantáneas de almacenamiento.
Revise las guías de SAP para proveedores de bases de datos individuales, así como la documentación de AWS:
+ Documentación de AWS: [AWS Backint Agent para SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html)
+ Documentación de SAP: [Guide Finder for SAP NetWeaver and ABAP Platform (Buscador de guías de SAP NetWeaver y ABAP)](https://help.sap.com/viewer/nwguidefinder)
+ Blog de SAP on AWS: [How to back up Microsoft SQL Server databases for SAP with VSS Snapshots (Cómo realizar una copia de seguridad de las bases de datos de Microsoft SQL Server para SAP con instantáneas de VSS)](https://aws.amazon.com/blogs/awsforsap/how-to-back-up-microsoft-sql-server-databases-for-sap-with-vss-snapshots/)
+ Blog de AWS: [Taking crash-consistent snapshots across multiple Amazon EBS volumes on an Amazon EC2 instance (Captura de instantáneas coherentes ante bloqueos en varios volúmenes de Amazon EBS en una instancia de Amazon EC2)](https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/#:~:text=AWS%20Storage%20Blog-,Taking%20crash%2Dconsistent%20snapshots%20across%20multiple%20Amazon%20EBS,on%20an%20Amazon%20EC2%20instance&text=Snapshots%20retain%20the%20data%20from,to%20as%20crash%2Dconsistency).)
**Sugerencia 12.1.2: evalúe la durabilidad y la capacidad de recuperación de los datos basados en archivos que son críticos para su empresa.**
Los datos empresariales que no se almacenan en una base de datos pueden requerir una estrategia de copia de seguridad independiente.
En un sistema estándar de SAP NetWeaver, esto a menudo suele suponer el uso de archivos de interfaz basados en archivos, contenido del directorio de transporte de SAP y registros, entre ellos, registros de lotes, de trabajos y de directorios de procesos de trabajo. Los sistemas de soporte y los que no pertenecen a SAP NetWeaver, como las soluciones de administración de documentos, pueden tener otros datos comerciales basados en archivos que deben evaluarse. Evalúe [Amazon EFS](https://aws.amazon.com/efs/) o [Amazon FSx](https://aws.amazon.com/fsx/) para aumentar la disponibilidad y durabilidad de dichos sistemas de archivos.
Las copias de seguridad del sistema de archivos se pueden realizar utilizando instantáneas, AWS Backup o soluciones de copias de seguridad de terceros.
Los datos empresariales deben evaluarse independientemente de los archivos binarios y los datos de configuración, que podrían volver a aprovisionarse a través de la descarga, reinstalación o la infraestructura como código de SAP. Consulte el siguiente recurso:
+ SAP Lens [excelencia operativa]: [Sugerencia 12.2.1: defina un enfoque de infraestructura como código para la creación y los cambios de configuración](best-practice-12-2.md)
+ SAP Lens [excelencia operativa]: [Sugerencia 12.2.2: defina un enfoque para las copias de seguridad de los contenidos del sistema de archivos, incluido el volumen principal](best-practice-12-2.md)
**Sugerencia 12.1.3: evalúe la durabilidad y ubicación de las copias de seguridad y de los registros de la base de datos**
Las copias de seguridad y los registros contienen información sobre sus datos en tiempo real, pero pueden fallar. Considere cómo minimizar el impacto de un error al evaluar la ubicación de sus copias de seguridad en relación con sus copias de datos activas. Es clave que tenga en cuenta lo siguiente:
+ El tiempo que lleva asegurar las copias de seguridad afecta el punto de recuperación.
+ El tiempo que lleva restaurar o recuperar las copias de seguridad afecta el tiempo de recuperación.
Puede encontrar más información en la siguiente documentación:
+ Documentación de AWS: [AWS Backint Agent para HANA](https://aws.amazon.com/backint-agent/)
+ Documentación de AWS: [Restauración rápida de instantáneas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html)
+ Documentación de AWS: [Opciones de replicación de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html)
**Sugerencia 12.1.4: evalúe sus requisitos para una recuperación a un momento dado**
Si se le exigiera hacer una recuperación hacia un momento dado, ¿se lo permitiría su diseño de copias de seguridad? ¿El método de copia de seguridad tiene conocimiento de la base de datos y puede hacer avanzar su base de datos a un punto de recuperación coherente? ¿Ha considerado alguna recuperación basada en archivos para mantener la coherencia?
Considere lo siguiente:
+ El intervalo de registro y la rapidez con la que se protegen los registros
+ Copias de seguridad progresivas o diferenciales para mejorar el tiempo de recuperación
+ Exigencia de un catálogo de copias de seguridad u otro mecanismo
+ ¿Es posible usar la base de datos o las opciones de almacenamiento para retroceder en el tiempo?
**Sugerencia 12.1.5: revise mecanismos de recuperación por pérdida de datos**
Determine las implicaciones de recuperarse de una situación de pérdida de datos importante, como la corrupción o eliminación de datos o una implementación de código defectuosa que no se puede revertir. Evalúe la propagación de la pérdida de datos al usar replicaciones de bases de datos o basadas en almacenamiento, y el impacto del RTO y RPO al usar un mecanismo de restauración secundario, como las copias de seguridad.
**Sugerencia 12.1.6: cree un búnker de datos**
Siga la guía que se encuentra en [Sugerencia 10.3.7: determine en qué situaciones de error sería necesaria una recuperación desde la copia de seguridad](best-practice-10-3.md) y cree un búnker de datos para proteger sus copias de seguridad de una eliminación accidental o actividades maliciosas.
# Práctica recomendada 12.2: establezca un método para la recuperación de datos de configuración
Varios tipos diferentes de datos, que son necesarios para ejecutar una carga de trabajo de SAP, no residen en la base de datos de SAP. Esto incluye la configuración del sistema operativo, los metadatos para recrear los recursos de AWS requeridos y los datos requeridos por las aplicaciones SAP almacenadas en un sistema de archivos. Defina un proceso para recuperar o recrear estos datos en caso de que se pierdan.
**Sugerencia 12.2.1: defina un enfoque de infraestructura como código para la creación y los cambios de configuración**
Los cambios manuales realizados directamente en instancias individuales pueden provocar rápidamente inconsistencias en la configuración entre sistemas y una dependencia en las copias de seguridad para recuperar el estado. Al usar infraestructura como código, puede implementar sus sistemas SAP e implementar cambios de la misma forma que administraría el código de la aplicación. Los mecanismos de DevOps, como una canalización de código, pueden brindar control y pruebas adicionales para ayudar a garantizar la consistencia y la repetibilidad de su infraestructura.
Deberá evaluar los siguientes servicios de AWS como parte de su enfoque:
+ Servicio de AWS: [AWS Launch Wizard para SAP](https://aws.amazon.com/launchwizard/)
+ Servicio de AWS: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ Servicio de AWS: [Kit de desarrollo de la nube de AWS](https://aws.amazon.com/cdk/)
+ Blog de SAP on AWS: [DevOps for SAP (DevOps para SAP)](https://aws.amazon.com/blogs/awsforsap/category/devops/)
+ Documentación de AWS: [Introducción a DevOps en AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/welcome.html)
**Sugerencia 12.2.2: defina un enfoque para las copias de seguridad de los contenidos del sistema de archivos, incluido el volumen principal**
Los paquetes y la configuración del sistema operativo, los archivos binarios de la aplicación y el contenido del sistema de archivos son parte integral de un sistema SAP en ejecución, pero no forman parte de la copia de seguridad de la base de datos central de SAP. Evalúe los mecanismos para asegurar y restaurar estos datos, lo que incluye las Amazon Machine Images (AMI, imágenes de máquina de Amazon), las instantáneas de volúmenes de EBS y otras opciones de copias de seguridad.
Debe tenerse en cuenta la frecuencia y la alineación de las AMI, las instantáneas y las copias del sistema de archivos, así como la granularidad de la recuperación y el tiempo necesario.
En ciertos escenarios, el uso de la infraestructura como código podría reducir los requisitos de copia de seguridad para datos no empresariales al centrarse en la recreación y no en la restauración.
+ Documentación de SAP: [Directorios y sistemas de archivos requeridos](https://help.sap.com/viewer/910828cec5d14d6685da380aec1dc4ae/CURRENT_VERSION/en-US/de6cad1446a743d3853dbcae48bddfba.html)
+ Documentación de AWS: [Diseño de una solución de copias de seguridad y recuperación](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/design.html)
**Sugerencia 12.2.3: registre en un documento cualquier configuración manual**
Cualquier actividad manual que no esté contenida en la base de datos o que pueda implementarse por código o restaurarse mediante copias de seguridad de volúmenes debe registrarse para garantizar que se pueda recrear un sistema SAP en el peor de los casos.
# Práctica recomendada 12.3: defina un enfoque de recuperación para todo su catálogo de SAP
Si su catálogo de SAP consta de varios sistemas SAP, debe crear un enfoque detallado en el que defina el orden en que se recuperará cada sistema, en función de las prioridades empresariales. Evalúe cómo la pérdida de datos podría afectar la coherencia entre los sistemas y las operaciones empresariales.
**Sugerencia 12.3.1: cree un plan de continuidad empresarial en el que se contemple la prioridad de restauración y los planes para garantizar la coherencia**
Tenga un BCP que fije la prioridad de restauración de cada sistema SAP en función de la clasificación de sistemas que se determina en [fiabilidad]: [Sugerencia 10.1.2: clasifique los sistemas según el impacto del error](best-practice-10-1.md) . El plan también debe considerar el impacto de los requisitos de consistencia entre sistemas y el uso de bases de datos de multiinquilinos en la prioridad de restauración.
**Sugerencia 12.3.2: evalúe todas las dependencias de servicios compartidos**
Al definir su enfoque de recuperación, considere qué servicios compartidos son parte de la base para ejecutar su carga de trabajo de SAP (por ejemplo, DNS, Active Directory) o son necesarios para realizar la restauración en sí (por ejemplo, herramientas de copia de seguridad). Evalúe los riesgos y los prerrequisitos de restauración vinculados a estas dependencias.
**Sugerencia 12.3.3: cree manuales de procedimiento que sirvan como guías en situaciones de desastres**
Definir de antemano un manual de procedimientos garantizará que se sigan una serie de pasos probados en situaciones de desastres, lo que ayuda a reducir el riesgo o la probabilidad de que no se lleven a cabo actividades fundamentales.
# Práctica recomendada 12.4: realice pruebas periódicas para validar su procedimiento de recuperación
Pruebe periódicamente sus estrategias de recuperación ante situaciones de errores críticos para demostrar que el software y los procedimientos generan un resultado predecible y para validar el estado de los archivos de copia de seguridad. Debe evaluar cualquier cambio en la arquitectura, el software o el personal de soporte para determinar si es necesario realizar pruebas adicionales.
**Sugerencia 12.4.1: identifique situaciones de error para las pruebas de recuperación**
Deberá identificar las posibles situaciones de error en las que se necesitará una recuperación. Para ello, básese en lo detallado en [fiabilidad]: [Sugerencia 10.3.2: determine en qué situaciones de error sería necesaria una recuperación desde la copia de seguridad](best-practice-10-3.md) y decida el nivel apropiado de pruebas requeridas para validar el proceso y la herramienta.
**Sugerencia 12.4.2: determine el impacto que tendrá un cambio en el sistema en su estrategia de recuperación.**
Defina un enfoque para evaluar el impacto de un cambio y las pruebas de recuperación posteriores necesarias para garantizar que no invalide su estrategia. Entre los ejemplos de los tipos de cambios que podrían afectar la recuperación de su carga de trabajo, se incluyen actualizaciones de software, las revisiones y los cambios de parámetros.
También se debe planificar una prueba de recuperación en caso de que se produzca un cambio significativo en el modelo operativo utilizado para dar soporte a sus entornos de SAP, por ejemplo, un cambio en los socios proveedores de los servicios administrados o en el personal clave.
**Sugerencia 12.4.3: defina un plan de prueba de recuperación**
Debe tener un conjunto completo de pruebas definidas para simular las situaciones de errores críticos de las que necesitaría recuperarse. Las pruebas de recuperación deben planificarse durante la implementación inicial y luego periódicamente o cuando sea necesario.
+ SAP Lens [excelencia operativa]: [Práctica recomendada 4.3: pruebe periódicamente los planes de continuidad de la empresa y la recuperación de errores](best-practice-4-3.md) .