# 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?