Práctica recomendada 17.2: evalúe las características de costos de su patrón de arquitectura de aplicaciones SAP - SAP Lens

Práctica recomendada 17.2: evalúe las características de costos de su patrón de arquitectura de aplicaciones SAP

Mientras diseña la arquitectura de su infraestructura SAP, tenga en cuenta el costo del número de componentes de infraestructura y también su tamaño y ubicación. Al establecer los requisitos empresariales de la solución y reconocer el riesgo y las oportunidades de optimización, puede obtener importantes ahorros de costos.

Sugerencia 17.2.1: revise los patrones de instalación de SAP seleccionados

Para cada aplicación SAP, defina la naturaleza de su patrón de implementación: independiente, distribuido o de alta disponibilidad. Seleccione el modelo arquitectónico que ofrece el mejor equilibro entre costos y características de fiabilidad para satisfacer los requisitos de su empresa. Un método útil es cuantificar el costo que significaría una interrupción de su empresa y trabajar a partir de ese punto. Compare el riesgo de un error individual que afecte la disponibilidad con el costo de reducir ese riesgo.

Además, considere si su arquitectura tiene la flexibilidad de implementar un ajuste de tamaño correcto. Se pueden ahorrar costos con la concesión de licencias de sistemas operativos y con el almacenamiento y la administración de múltiples servidores de aplicaciones en un solo host. A nivel de las aplicaciones, existen diversos tamaños de instancias con un alto grado de especificidad para la CPU y la memoria y cuyos precios son casi invariables en las familias de instancias compatibles. La implementación de instancias más pequeñas puede ofrecer más opciones para la reutilización de instancias y el escalado basado en cargas de trabajo.

Evalúe los grupos lógicos y considere el efecto de combinar componentes, sistemas (SID) o infraestructuras. ¿Estas actividades incrementarían la complejidad operativa y disminuirían la fiabilidad?

Sugerencia 17.2.2: evalúe las excepciones para el uso de tenencias múltiples o el alojamiento de varias bases de datos en un solo host

En la mayoría de las bases de datos, ajuste el tamaño de cada sistema de forma independiente y aproveche el ajuste flexible del tamaño de las instancias para cumplir los requisitos de los sistemas. En algunos casos, es conveniente desviarse de esa recomendación por cuestiones de costos. Por ejemplo:

  • Cuando un componente basado en HANA requiere menos memoria que la instancia de EC2 más pequeña disponible, considere utilizar contenedores de bases de datos de multiinquilinos de SAP HANA. Cuando el alojamiento se lleva a cabo con otros componentes, se posibilita el uso eficiente de los recursos de computación.

  • Cuando se utilizan modelos de licencias de bases de datos basadas en núcleos para bases de datos relacionales, incluidas Oracle y SQL Server.

  • Cuando se tienen aplicaciones que están estrechamente acopladas o pueden acoplarse de esa manera para cumplir con requisitos de tiempo de disponibilidad (uptime) y dependencias de versiones. Esto incluye herramientas de administración (por ejemplo, Solution Manager y SAP HANA Cockpit) y algunas opciones de SAP NetWeaver Gateway Deployment (Fiori y ECC).

Sugerencia 17.2.3: evalúe el uso del patrón de instalación de un solo host para los sistemas que no requieren resiliencia y escalabilidad

Para las aplicaciones o entornos individuales, debe considerar las ventajas de un modelo de alojamiento único. Esta acción puede ayudar a ahorrar costos del sistema operativo, de la duplicación de almacenamiento, de licencias de software y de servicios administrados. Entre algunas opciones de arquitectura frecuentes, especialmente para las infraestructuras que no son de producción, se encuentran las siguientes:

Sugerencia 17.2.4: elija la región más rentable que satisfaga sus requisitos

Las principales razones para seleccionar una región de SAP son la proximidad, la residencia de los datos y la disponibilidad de los servicios. Para las implementaciones donde hay una opción, tenga presente que cada región de AWS ofrece precios basados en las condiciones del mercado local, por lo que los precios de servicio de AWS son distintos en cada región. Repase las diferencias de precios y su efecto potencial.

Sugerencia 17.2.5: aplique arquitecturas que pueden escalarse en caso de error

Los mecanismos de recuperación y la elasticidad de la nube permiten un diseño en el que los recursos redundantes no deben estar activos y al 100 % de su capacidad. Si los requisitos de su negocio permiten un RTO o RPO más flexible, considere los siguientes puntos.

En el caso de las bases de datos, tenga en cuenta lo siguiente:

  • Si sus RPO lo permiten, considere un nodo de base de datos secundario o de respaldo que no requiera una capacidad de computación equivalente para aplicar cambios con respecto al nodo principal. Teniendo en cuenta el efecto del tiempo de recuperación, contemple las ventajas en los costos de implementar una instancia más pequeña o compartida para su nodo secundario y escálelo verticalmente cuando se requiera. Si se utiliza una instancia más pequeña, se mantiene una relación 1:1 entre las instancias primarias y secundarias del sistema. Una arquitectura de instancias compartidas agrupa la base de datos secundaria con una base de datos del sistema no duplicada en una sola instancia. En caso de error, el sistema no duplicado debe detenerse antes de que pueda ocurrir una adquisición. De esta manera, aumenta el RTO.

  • Si utiliza una instancia más pequeña para la base de datos de SAP HANA secundaria, desactive la carga previa de memoria para permitir una huella de memoria menor en el respaldo y reducir los costos. SAP calcula los requisitos de memoria en el documento de ayuda para el uso del sistema secundario.

  • Si su RTO y sus requisitos de resiliencia lo permiten, considere enfoques de creación de copias de seguridad de datos y registros que utilicen almacenamiento Multi-AZ (como Amazon FSx, Amazon EFS o Amazon S3). Estos enfoques permiten la protección geográfica de datos sin requerir recursos secundarios redundantes. En caso de error, se pueden crear recursos secundarios bajo demanda y restaurarlos rápidamente desde las copias de seguridad de ubicaciones transversales y almacenamiento de registros.

En el caso de la aplicación, tenga en cuenta lo siguiente:

  • La recuperación de instancias de AWS consiste en el uso de una alarma de CloudWatch para supervisar una instancia de Amazon EC2. Recupera automáticamente la instancia si queda inhabilitada debido a un error de hardware preexistente. Evalúe si las situaciones de error cubiertas proporcionan protección suficiente.

  • En las situaciones en las que el servidor de una aplicación debe recrearse rápidamente, entre algunas de las opciones, se encuentran las instancias de EC2 que se aprovisionan, pero no se ejecutan, las AMI con plantillas, la replicación de almacenamiento con servidores de pruebas frecuentes o la infraestructura como código.

Sugerencia 17.2.6: considere el costo de la capacidad de computación mínima durante un error

Distribuir los componentes de SAP en varias AZ puede reducir los costos incurridos para las reservas de capacidad en caso de error. Al distribuir componentes en varias AZ, se evita la necesidad de tener capacidad de exceso porque ya tiene parte de su carga de trabajo diseminada geográficamente. Esta medida minimiza el impacto en caso de un error de la AZ.

Por ejemplo, si el 100 % de capacidad es un requisito de disponibilidad para las situaciones de error incluida la pérdida de una AZ, en vez de aprovisionar el 200 % de capacidad en dos AZ, aprovisione el 150 % de capacidad en tres.

SAP production account with three availability zones, each hosting application and database instances.
Figura: ejemplo de una arquitectura de tres AZ con el 150 % de capacidad en operaciones normales

Sugerencia 17.2.7: evalúe el uso de opciones de recuperación basadas solo en almacenamiento

En general en AWS, recomendamos la replicación de bases de datos en lugar de la replicación de almacenamiento para garantizar la protección del rango más amplio de situaciones de error. En el caso de la capa de la aplicación o de las instancias menos críticas, se puede reducir costos mediante una solución de DR que utilice replicación de almacenamiento sin computación. También minimiza la complejidad asociada con la administración de cambios.

Sugerencia 17.2.8: entender los costos relacionados con las redes

Los clientes de SAP suelen requerir una conexión segura entre la red en las instalaciones y Amazon VPC. Mediante el uso de una conexión de Direct Connect del tamaño adecuado o una conexión VPN o ambas, es posible cumplir los requisitos de rendimiento y fiabilidad a la par que se reducen costos.

Los costos de transferencia de datos varían según la región, la VPC y el diseño de la AZ. Evalúe de qué manera la distribución y la replicación de sus componentes de SAP se pueden optimizar sin comprometer la fiabilidad.

Por ejemplo, si dos sistemas que transfieren grandes cantidades de datos están en ubicaciones separadas, considere el efecto en los costos de transferencia de datos.

Puede encontrar más guías en el pilar de costo del plan de revisión de Well-Architected Framework para la transferencia de datos, en el pilar de optimización de costos .