Arquitectura de referencia: SAP S/4HANA en Google Cloud

Esta arquitectura de referencia está dirigida a personas que evalúan Google Cloud como una plataforma para implementar cargas de trabajo de SAP S/4HANA. Incluye consideraciones durante la fase de planificación, modelos de implementación y automatización, y procedimientos operativos comunes, como las tareas de Backup and DR.

Google Cloud proporciona una infraestructura certificada para SAP que es rentable, confiable, segura y de alto rendimiento a la hora de ejecutar SAP S/4HANA en SAP HANA. Para obtener una lista completa de las soluciones de SAP admitidas en Google Cloud, consulta SAP en Google Cloud.

Arquitectura

En los siguientes diagramas, se muestra una vista de alto nivel de tres modelos de implementación comunes para SAP S/4HANA: centralizado, distribuido y distribuido con alta disponibilidad.

Implementación centralizada

En una implementación centralizada, puedes instalar SAP S/4HANA y la base de datos de SAP HANA en la misma instancia de VM de Compute Engine. Recomendamos este enfoque en los entornos que no se usan para producción, como entornos de zona de pruebas y de desarrollo.

En el siguiente diagrama, se muestra una arquitectura de referencia para SAP S/4HANA en SAP HANA en una implementación centralizada. Ten en cuenta que SAP ASCS, PAS, WD y la base de datos de SAP HANA se instalan en la misma instancia de VM.

Diagrama de arquitectura para SAP S/4HANA en Google Cloud en una implementación centralizada.

Implementación distribuida

En una implementación distribuida, puedes instalar los diferentes componentes en diferentes instancias de Compute Engine. Recomendamos este enfoque para los entornos de producción o los entornos que requieran mucha capacidad de procesamiento a fin de controlar cargas de transacciones pesada.

En el siguiente diagrama, se muestra una arquitectura de referencia para SAP S/4HANA en una implementación distribuida. Ten en cuenta que SAP ASCS, PAS, WD y HANA se instalan en instancias diferentes de VM.

Diagrama de arquitectura para SAP S/4HANA en Google Cloud en una implementación distribuida.

Implementación distribuida con alta disponibilidad

En una implementación distribuida con alta disponibilidad, los clústeres de Linux se configuran en todas las zonas para ayudar a proteger contra fallas de componentes en una región determinada. Puedes implementar un clúster de Linux entre zonas mediante una configuración activa y pasiva, o una configuración activa/activa. En ambos casos, debes comenzar por configurar dos instancias de VM de Compute Engine en zonas diferentes para obtener una máxima redundancia, cada una con su propia base de datos de SAP HANA. En el siguiente diagrama, se muestra una arquitectura de SAP S/4HANA que usa un clúster de Linux para lograr una alta disponibilidad en la aplicación y en la base de datos de SAP HANA:

Diagrama de arquitectura para SAP S/4HANA en Google Cloud en una implementación distribuida de alta disponibilidad.En los siguientes diagramas, se muestra una base de datos de SAP HANA con alta disponibilidad durante el funcionamiento normal y una operación de toma de control:

  • Operación normal:

    Diagrama de la arquitectura para la alta disponibilidad de SAP HANA en Google Cloud durante el funcionamiento normal.

  • Operación de toma de control:

    Diagrama de arquitectura para la alta disponibilidad de SAP HANA en Google Cloud durante la operación de toma de control.

Para combinar la alta disponibilidad y la recuperación ante desastres de la base de datos, puedes usar la replicación del sistema SAP HANA. En el siguiente diagrama, se muestra una combinación de ambos para lograr la máxima disponibilidad y tolerancia a errores:

Diagrama de arquitectura de alto nivel para SAP S/4HANA en Google Cloud con alta disponibilidad y recuperación ante desastres.

El clúster que administra la alta disponibilidad incluye las siguientes funciones y características:

  • Dos VMs de host, cada una con una instancia de SAP HANA.
  • Replicación síncrona del sistema SAP HANA.
  • El administrador de recursos del clúster de alta disponibilidad de Pacemaker
  • Un mecanismo de protección que protege el nodo con errores.
  • Reinicio automático de la instancia con errores como la instancia secundaria nueva

La arquitectura de la aplicación es similar. En este caso, el clúster administra SAP Central Services (ASCS) de ABAP y Enqueue Replication Server o Enqueue Replicator (ERS) que se usan para proporcionar al sistema SAP S/4HANA con alta disponibilidad en caso que suceda algo con cualquiera de las instancias de ASCS y ERS.

Según la versión de SAP S/4HANA que uses, Enqueue Server y Enqueue Replication Server/Enqueue Replicator se ejecutan en una versión diferente:

  • S/4HANA 1709 y versiones anteriores: ENSA1 y ERS.
  • S/4HANA 1809 o posterior: ENSA2 y ERS2.

En el siguiente diagrama, se muestra un sistema SAP S/4HANA que usa un clúster de Pacemaker para limitar los puntos únicos de falla del servidor de mensajes y del servidor de cola:

Diagrama de arquitectura de SAP NetWeaver, con una base de datos, en una implementación de alta disponibilidad en Google Cloud.

Los detalles sobre la implementación del sistema de alta disponibilidad y el agrupamiento en clústeres de Linux entre zonas se analizan más adelante en este documento.

Nota sobre el balanceo de cargas

En un entorno SAP S/4HANA distribuido, el balanceo de cargas es obligatorio. Puedes configurar el balanceo de cargas de la aplicación con una combinación de la capa de aplicación de SAP y los balanceadores de cargas de red. Para obtener más información, consulta la sección Implementaciones de VIP del balanceador de cargas de red de transferencia interno en la guía de planificación de alta disponibilidad para SAP NetWeaver en Google Cloud.

Componentes de implementación

SAP S/4HANA consta de los siguientes componentes técnicos:

  • Base de datos de SAP HANA
  • ASCS: ABAP SAP Central Services
    • Contiene el servidor de mensajes y Enqueue Server, que se requieren en cualquier sistema SAP ABAP.
    • Se implementa en su propia instancia de VM en implementaciones de alta disponibilidad o en la instancia de VM que aloja PAS.
    • En las implementaciones de alta disponibilidad, un administrador de recursos de clústeres de Linux, como Pacemaker, administra los recursos de ASCS.
  • ERS: Enqueue Replication Server o Enqueue Replicator
    • Se implementa en implementaciones de alta disponibilidad para mantener una réplica de la tabla de bloqueo en caso de que algo suceda con la instancia de ASCS.
    • Lo gestiona un administrador de recursos de clústeres de Linux, como Pacemaker
  • PAS: servidor de aplicaciones principal
    • El primer o único servidor de aplicaciones del sistema SAP.
  • AAS: servidor de aplicaciones adicional
    • Por lo general, se implementa para el balanceo de cargas a nivel de las aplicaciones. También puedes instalar varias instancias de AAS para lograr una mayor disponibilidad desde la perspectiva de la capa de aplicación. Si uno de los servidores de aplicaciones deja de funcionar, todas las sesiones de usuario conectadas a ese servidor de aplicaciones finalizan, pero los usuarios pueden acceder de nuevo al otro AAS en el entorno
  • Puerta de enlace de SAP NetWeaver
    • Se implementa como un sistema independiente o como parte del sistema SAP S/4HANA.
    • Permite que el sistema conecte dispositivos, entornos y plataformas a sistemas SAP con el protocolo de datos abiertos (OData).
  • Servidor de frontend de SAP Fiori
    • Se implementa como un sistema independiente o como parte del sistema SAP S/4HANA.
    • El sistema ABAP de SAP NetWeaver se usa para alojar aplicaciones de SAP Fiori.
  • WD: despachador web (opcional)
    • Balanceador de cargas de software inteligente que distribuye solicitudes HTTP y HTTPS, según el tipo de aplicación, a PAS y AAS

Los siguientes servicios de Google Cloud se usan en la implementación de SAP S/4HANA:

Servicio Descripción
Herramientas de redes de VPC

Conecta tus instancias de VM entre sí y con Internet.

Cada instancia de VM es miembro de una red heredada con un solo rango de IP global o una red de subred recomendada, en la que la instancia es miembro de una subred única que forma parte de una red más grande.

Ten en cuenta que una red de nube privada virtual (VPC) no puede abarcar varios proyectos de Google Cloud, pero un proyecto de Google Cloud puede tener varias redes de VPC.

Para conectar recursos de varios proyectos a una red de VPC común, puedes usar la VPC compartida para que los recursos se comuniquen entre sí de manera segura y eficiente a través de direcciones IP internas de esa red. Para obtener información sobre cómo aprovisionar una VPC compartida, incluidos los requisitos, los pasos de configuración y el uso, consulta Aprovisiona la VPC compartida.

Compute Engine Crea y administra VMs con el sistema operativo y la pila de software que elijas.
Hyperdisk y Persistent Disk

Puedes usar Persistent Disk y Google Cloud Hyperdisk:

  • Los volúmenes de Persistent Disk están disponibles como unidades de disco duro estándar (HDD) o unidades de estado sólido (SSD). En el caso de los discos persistentes balanceados y los discos persistentes SSD, la replicación asíncrona de PD proporciona la replicación asíncrona de los datos de SAP entre dos regiones de Google Cloud.
  • Los volúmenes de Hyperdisk Extreme proporcionan opciones de IOPS y capacidad de procesamiento máximas más altas que los volúmenes de discos persistentes SSD.
  • De forma predeterminada, Compute Engine encripta el contenido en reposo del cliente, incluido el contenido dentro de los volúmenes de Hyperdisk y Persistent Disk. Para obtener más información sobre la encriptación de discos y las opciones de encriptación posibles, consulta Información sobre la encriptación de discos.
Consola de Google Cloud

Herramienta para navegador que administra los recursos de Compute Engine.

Usa una plantilla para describir todas las instancias y recursos de Compute Engine que necesitas. No es necesario crear y configurar los recursos de forma individual ni determinar las dependencias, ya que la consola de Google Cloud lo hace por ti.
Cloud Storage Puedes almacenar tus copias de seguridad de bases de datos de SAP en Cloud Storage para conseguir una mayor durabilidad y confiabilidad, con replicación.
Cloud Monitoring

Brinda visibilidad sobre la implementación, el rendimiento, el tiempo de actividad y el estado de Compute Engine, la red y los discos de almacenamiento persistente.

Monitoring recopila métricas, eventos y metadatos de Google Cloud y los usa para generar estadísticas a través de paneles, gráficos y alertas. Puedes supervisar las métricas de procesamiento sin costo a través de Monitoring.
IAM

Proporciona un control unificado sobre los permisos para los recursos de Google Cloud.

IAM te permite controlar quién puede realizar operaciones de plano de control en las VMs, incluidas la creación, la modificación y la eliminación de VMs y discos de almacenamiento persistente, y la creación y modificación de redes.
Filestore

Almacenamiento de archivos NFS completamente administrado y de alto rendimiento de Google Cloud.

En el caso de las implementaciones de alta disponibilidad de varias zonas, te recomendamos usar Filestore Enterprise que tiene un ANS de disponibilidad del 99.99%. Para obtener información sobre los niveles de servicio de Filestore, consulta Niveles de servicio.
Cloud Volumes ONTAP de NetApp

Una solución de almacenamiento inteligente y con funciones completas que implementas y administras tú mismo en una instancia de VM de Compute Engine.

Para obtener más información sobre Cloud Volumes ONTAP de NetApp, consulta Descripción general de Cloud Volumes.
Google Cloud NetApp Volumes

Una solución de almacenamiento de archivos NFS y SMB completamente administrada de Google Cloud, con la tecnología de NetApp Cloud Volumes ONTAP.

Según la región, puede haber varios niveles de servicio disponibles para seleccionar. Para obtener más información, consulta Niveles de servicio.

Consideraciones del diseño

En esta sección, se proporciona orientación para ayudarte a usar esta arquitectura de referencia para desarrollar una arquitectura que cumpla con tus requisitos específicos de seguridad, confiabilidad, eficiencia operativa, costo y rendimiento.

Herramientas de redes

Existen varias formas de implementar un sistema SAP S/4HANA desde la perspectiva de las herramientas de redes, y la forma en que implementas tu red tiene un impacto significativo en su disponibilidad, resiliencia y rendimiento. Como se mencionó antes, una nube privada virtual (VPC) es una red privada aislada y segura que se aloja en Google Cloud. Las VPC son globales en Google Cloud, por lo que una sola VPC puede abarcar varias regiones sin tener que comunicarse a través de Internet.

Una implementación típica de SAP coloca las instancias de sistemas de alta disponibilidad en diferentes zonas de la misma región para garantizar la resiliencia y proporcionar una latencia baja. Las subredes pueden abarcar varias zonas debido a las capacidades de Google Cloud. Estas capacidades también simplifican el agrupamiento en clústeres de SAP porque la dirección IP virtual (VIP) del clúster puede estar en el mismo rango que las instancias de los sistemas de alta disponibilidad. Esta configuración protege la IP flotante mediante un balanceador de cargas de aplicaciones interno y se aplica al agrupamiento en clústeres de alta disponibilidad de la capa de la aplicación (ASCS y ERS) y de la capa de la base de datos de SAP HANA (SAP HANA principal y secundario).

Existen varias formas de compilar tu red y conectar el sistema SAP S/4HANA con la infraestructura:

  • El intercambio de tráfico entre redes de VPC conecta dos redes de VPC para que los recursos de cada red puedan comunicarse entre sí. Las redes de VPC pueden estar alojadas en el mismo proyecto de Google Cloud, en proyectos distintos de la misma organización o, incluso, en proyectos diferentes de organizaciones distintas. El intercambio de tráfico entre redes de VPC establece una conexión directa entre dos redes de VPC, cada una con sus propias subredes, lo que permite una comunicación privada entre los recursos de las VPC con intercambio de tráfico.

  • La VPC compartida es una función en Google Cloud que permite a una organización conectar recursos desde varios proyectos a una red de VPC común. Los sistemas que usan una VPC compartida pueden comunicarse de manera eficiente y segura a través de direcciones IP internas. Puedes administrar de manera centralizada los recursos de red, como subredes, rutas y firewalls en un proyecto host, mientras delegas responsabilidades administrativas para crear y administrar recursos individuales a los proyectos de servicio. Esta separación de problemas simplifica la administración de la red y aplica políticas de seguridad coherentes en toda la organización.

Para los sistemas SAP, por lo general, se recomienda agrupar los recursos por tipo de entorno. Por ejemplo, los entornos de producción no deben compartir recursos de procesamiento con entornos que no sean de producción para proporcionar un aislamiento adecuado, pero puedes usar una VPC compartida para una capa común de conectividad entre tus proyectos. También puedes usar VPC independientes y el intercambio de tráfico entre VPC para conectar proyectos.

Mientras diseñas tu red, comienza con un proyecto host que contenga una o más redes de VPC compartida. Puedes vincular proyectos de servicio adicionales a un proyecto host, lo que permite que los proyectos de servicio participen en la VPC compartida. Según tus necesidades, puedes implementar SAP S/4HANA en una sola VPC compartida o varias VPC compartidas. Los dos casos difieren en términos de control de red, aislamiento de entorno de SAP e inspección de red:

  • Situación 1: Implementa SAP S/4HANA en una sola VPC compartida Esto simplifica la implementación y reduce la sobrecarga administrativa a expensas de un menor aislamiento entre las redes.
  • Situación 2: Implementa SAP S/4HANA en varias VPC compartidas. Esto aumenta el aislamiento de red y agrega seguridad a expensas de aumentar la complejidad y la sobrecarga administrativa.

También es posible usar un enfoque híbrido. Por ejemplo, puedes usar una VPC compartida para el entorno de producción y una VPC compartida para todos los sistemas que no son de producción. Para obtener más información, consulta la sección “Herramientas de redes” en Lista de tareas general para SAP en Google Cloud.

Puntos únicos de fallo

Un sistema SAP S/4HANA tiene algunos puntos únicos de falla comunes que pueden afectar la disponibilidad del sistema:

  • SAP Central Services, como el servidor de mensajes y Enqueue Server
  • Servidor de aplicaciones SAP
  • Base de datos de SAP HANA
  • SAP Web Decrypter, si se usa como frontend para el acceso HTTP/HTTPS al sistema
  • Almacenamiento compartido, como NFS

Existen varias opciones para reducir el impacto de esos puntos únicos de fallo, y estas opciones implican implementar el sistema mediante soluciones de alta disponibilidad, servicios de replicación o usar otras funcionalidades que protejan el sistema contra fallas. Cuando planifiques el sistema SAP S/4HANA, te recomendamos que analices esos puntos únicos de fallo y que planifiques en consecuencia. Si deseas obtener una descripción general de las soluciones alternativas que puedes usar para administrar los puntos únicos de fallo, consulta las siguientes secciones de esta guía:

Disponibilidad y continuidad

Durante la fase de planificación de la implementación de un sistema SAP S/4HANA, debes especificar los siguientes datos para definir la disponibilidad y continuidad del sistema:

  • Objetivos de nivel de servicio (SLO): un valor objetivo o rango de valores para un nivel de servicio que se mide a través de un indicador de nivel de servicio (SLI). Por ejemplo: rendimiento, disponibilidad y confiabilidad.
  • Indicadores de nivel de servicio (SLI): métricas, como la latencia, que ayudan a medir el rendimiento de un servicio. Es una medida cuantitativa definida con cuidado sobre algún aspecto del nivel de servicio que se proporciona.
  • Acuerdo de Nivel de Servicio (ANS): un contrato de servicio entre dos partes (proveedor, cliente) que define un acuerdo sobre el servicio proporcionado en términos medibles llamados objetivos de nivel de servicio (SLO).
  • Objetivo de tiempo de recuperación (RTO): la duración máxima tolerable entre un incidente de pérdida de datos y su mitigación.
  • Objetivo de punto de recuperación (RPO): el objetivo de punto de recuperación (RPO) es la cantidad máxima de datos que se pueden perder, medir a tiempo, sin causar un daño significativo. En la práctica, esto se traduce al momento en el que el estado de los datos afectados debe recuperarse después de un evento de pérdida de datos.

Según los datos y los valores acordados entre todas las partes interesadas, el sistema SAP S/4HANA se basa en capacidades como la alta disponibilidad o la recuperación ante desastres:

  • Alta disponibilidad (HA): la capacidad de un sistema que admite el objetivo de la continuidad del negocio, a la vez que garantiza que los datos y servicios estén disponibles para los usuarios cuando lo necesiten. La forma habitual de lograr esta capacidad es habilitar la redundancia, incluida la redundancia de hardware, de red y del centro de datos.
  • Recuperación ante desastres (DR): la capacidad que tiene un sistema de protegerse de las interrupciones no planificadas a través de métodos de recuperación confiables y predecibles en un hardware o una ubicación física diferentes.

La alta disponibilidad y la recuperación ante desastres son compatibles, pero abarcan diferentes casos y situaciones. Por ejemplo, una solución de alta disponibilidad te permite continuar con las operaciones si uno de los elementos del sistema tiene un tiempo de inactividad o una interrupción no planificados sin causar ninguna interrupción para tus usuarios. Lo mismo se puede decir sobre una solución de DR, con la excepción de experimentar una interrupción desde el momento en que se produce la interrupción hasta que la solución de DR inicia los elementos defectuosos del sistema en una ubicación diferente.

En las siguientes secciones, se proporciona una descripción general de las diferentes opciones que tienes cuando planificas y, luego, implementas tu sistema SAP S/4HANA en Google Cloud.

Tipos de máquinas compatibles con SAP S/4HANA

Google Cloud ofrece tipos de instancias de Compute Engine VM que están certificados por SAP para cumplir con los requisitos de tamaño cuando implementas SAP S/4HANA Obtén más información sobre el dimensionamiento en Google Cloud y los tipos de máquina Son compatibles, consulta los siguientes documentos:

Los tipos personalizados de máquinas para SAP HANA en Google Cloud también están certificados por SAP. Puedes ejecutar instancias de SAP HANA con menos de 64 CPU virtuales, siempre que mantengas una proporción de CPU virtuales y memoria de al menos 1:6.5.

Para ver los números de SAPS de las máquinas virtuales de Compute Engine que están certificadas para aplicaciones SAP, consulta SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types.

SAP también proporciona una lista certificada de ajustes de configuración de Google Cloud para SAP HANA en su sitio web. Para obtener más detalles, consulta Directorio de hardware de SAP HANA certificado y compatible.

Planifica regiones y zonas

Cuando implementas una VM, debes elegir una región y una zona. Una región es una ubicación geográfica específica en la que puedes ejecutar tus recursos y corresponde a una o más ubicaciones de centros de datos que se encuentran relativamente cerca entre sí. Cada región tiene una o más zonas con conectividad, alimentación y enfriamiento redundantes.

Se puede acceder a los recursos globales, como las imágenes de disco preconfiguradas y las instantáneas de disco, desde diversas regiones y zonas. A los recursos regionales, como las direcciones IP externas estáticas, solo pueden acceder recursos que se encuentran en la misma región. A los recursos zonales, como las VMs y los discos, solo pueden acceder los recursos que se encuentran en la misma zona. Para obtener más información, consulta Recursos globales, regionales y zonales.

Regiones y zonas de Google Cloud.

Cuando elijas una región y una zona para tus VMs, ten en cuenta lo siguiente:

  • La ubicación de tus usuarios y recursos internos, como el centro de datos o red corporativa. Para disminuir la latencia, selecciona una ubicación cercana a los usuarios y recursos.
  • Las plataformas de la CPU que están disponibles para esa región y zona. Por ejemplo, los procesadores Broadwell, Haswell, Ice Lake y Skylake de Intel son compatibles con cargas de trabajo de SAP NetWeaver en Google Cloud.
  • Asegúrate de que el servidor de aplicaciones SAP y tu base de datos estén en la misma región.

Opciones de almacenamiento para SAP S/4HANA

Las siguientes son las opciones de almacenamiento que ofrece Google Cloud y que están certificadas por SAP para usarse con SAP S/4HANA y SAP HANA.

Para obtener información general sobre las opciones de almacenamiento en Google Cloud, consulta Opciones de almacenamiento.

Persistent Disk

  • Discos persistentes estándar (pd-standard): Almacenamiento en bloque eficiente y económico respaldado por unidades de disco duro estándar (HDD) para controlar la lectura y escritura secuencial operaciones, pero no están optimizadas para controlar tasas altas de operaciones aleatorias de entrada y salida por segundo (IOPS).
  • Disco persistente SSD (pd-ssd): proporciona almacenamiento en bloque confiable y de alto rendimiento respaldado por unidades de estado sólido (SSD).
  • Disco persistente balanceado (pd-balanced): proporciona almacenamiento en bloque basado en SSD rentable y confiable.
  • Disco persistente extremo (pd-extreme): basado en SSD; proporciona opciones de capacidad de procesamiento y de IOPS máximas mayores que pd-ssd para los tipos de máquinas más grandes de Compute Engine. Para obtener más información, consulta Discos persistentes extremos.

Hyperdisk

  • Hyperdisk Extreme (hyperdisk-extreme): proporciona opciones de IOPS y capacidad de procesamiento máximas más altas que los volúmenes de Persistent Disk basados en SSD. Para seleccionar el rendimiento necesario, aprovisiona IOPS, que determinan la capacidad de procesamiento. Su mejor uso es alojar los directorios /hana/data y /hana/log. Para obtener más información, consulta Acerca de Google Cloud Hyperdisk.

  • Hiperdisco balanceado (hyperdisk-balanced): la mejor opción para la mayoría de las cargas de trabajo Recomendamos esta opción para usarla con bases de datos que no requieren el rendimiento de Hyperdisk Extreme. Para seleccionar el rendimiento que necesitas, aprovisiona las IOPS y la capacidad de procesamiento. Puedes usar volúmenes de Hyperdisk Balanced para alojar los directorios /hana/data y /hana/log. Para obtener más información, consulta Acerca de Google Cloud Hyperdisk.

Persistent Disk y Hyperdisk están diseñados para ofrecer una alta durabilidad. Para garantizar la integridad de los datos, los almacenan de forma redundante. Cada volumen de Persistent Disk puede almacenar hasta 64 TB, por lo que puedes crear grandes volúmenes lógicos sin administrar conjuntos de discos. Los volúmenes de Hyperdisk también permiten hasta 64 TB de almacenamiento, según el tipo que uses. Una característica clave es que los volúmenes de Persistent Disk y de Hyperdisk se encriptan automáticamente para proteger los datos.

Luego de la creación, una instancia de VM de Compute Engine asigna un Persistent Disk raíz o Hyperdisk de forma predeterminada que contiene el sistema operativo. Puedes agregar más opciones de almacenamiento a la instancia de VM según sea necesario.

Para las implementaciones de SAP, revisa las opciones para almacenar recomendadas en Opciones de almacenamiento y estructura de directorios de SAP.

Soluciones de uso compartido de archivos

Hay varias soluciones de uso compartido de archivos disponibles en Google Cloud, incluidas las siguientes:

  • Filestore: almacenamiento de archivos NFS completamente administrado y de alto rendimiento de Google Cloud con disponibilidad regional.
  • Google Cloud NetWeaver Volumes: una solución de almacenamiento de archivos NFS o SMB completamente administrada de Google Cloud.
  • NetApp Cloud Volumes ONTAP: Una solución de almacenamiento inteligente y con funciones completas que implementas y administras tú mismo en una VM de Compute Engine.
  • NetApp Cloud Volumes Service para Google Cloud: Una solución de almacenamiento de archivos de alto rendimiento y completamente administrada de NetApp que puedes implementar desde la consola de Google Cloud.

Si deseas obtener más información sobre las soluciones de uso compartido de archivos para SAP S/4HANA en Google Cloud, consulta Soluciones para compartir archivos para SAP en Google Cloud.

Cloud Storage para el almacenamiento de objetos

Cloud Storage es un depósito de objetos para archivos de cualquier tipo o formato. Tiene un almacenamiento prácticamente ilimitado, y no debes preocuparte por aprovisionarlo o agregar más capacidad. Un objeto en Cloud Storage contiene datos de archivos y sus metadatos asociados, y puede tener un tamaño de hasta 5 terabytes. Un bucket de Cloud Storage puede almacenar cualquier cantidad de objetos.

Es una práctica común usar Cloud Storage con el fin de almacenar archivos de copia de seguridad para casi cualquier propósito. Por ejemplo, Cloud Storage es un buen lugar para almacenar las copias de seguridad de la base de datos de SAP HANA. Para obtener información sobre la planificación de copias de seguridad de la base de datos, consulta Copia de seguridad y recuperación de la base de datos. También puedes usar Cloud Storage como parte de un proceso de migración.

Además, puedes usar el servicio de copia de seguridad y DR como una solución centralizada para las operaciones de copia de seguridad y recuperación ante desastres. Este servicio admite una gran variedad de bases de datos, incluido SAP HANA. Para obtener más información, consulta Soluciones de copia de seguridad y recuperación ante desastres con Google Cloud.

Elige tu opción de Cloud Storage según la frecuencia con la que necesites acceder a los datos. Para acceder con frecuencia, por ejemplo, varias veces al mes, selecciona la clase Standard Storage. Para el acceso poco frecuente, selecciona el almacenamiento Nearline o Coldline. Para los datos archivados, a los que no esperas acceder, selecciona Archive Storage.

Opciones de almacenamiento y estructura de directorios de SAP

En las siguientes tablas, se describen las estructuras de directorios de Linux para las bases de datos de SAP HANA y las instancias de SAP ABAP en Google Cloud.

  • Opciones de almacenamiento recomendadas para la estructura de directorios de Linux en SAP HANA:

    Directorio de SAP HANA Opción de almacenamiento recomendada en Google Cloud
    /usr/sap Disco persistente balanceado
    /hana/data Persistent Disk o Hyperdisk basados en SSD
    /hana/log Persistent Disk o Hyperdisk basados en SSD
    /hana/shared* Disco persistente balanceado
    /hanabackup* Disco persistente balanceado

    Nota: En las implementaciones distribuidas, /hana/shared y /hanabackup también se pueden activar como un sistema de archivos de red mediante una solución de NFS, como Filestore.

    Si deseas obtener información sobre el almacenamiento en discos persistentes que SAP certificó para su uso con SAP HANA, consulta Almacenamiento en discos persistentes para SAP HANA.

  • Opciones de almacenamiento recomendadas para la estructura de directorios de Linux en la instancia de SAP ABAP:

    Directorio Opción de almacenamiento recomendada en Google Cloud
    /sapmnt† Disco persistente balanceado
    /usr/sap Disco persistente balanceado

    En las implementaciones distribuidas, /sapmnt también se puede activar como un sistema de archivos de red a través de una solución de NFS, como Filestore.

    Si deseas obtener información sobre el almacenamiento en discos persistentes que SAP certificó para su uso con instancias de SAP ABAP, consulta Almacenamiento en discos persistentes para aplicaciones de SAP.

Compatibilidad del SO con SAP S/4HANA

Cuando eliges un sistema operativo (SO) para SAP NetWeaver en Google Cloud, además de confirmar que la versión del SO está certificada por SAP, también debes confirmar que las tres empresas, SAP, el proveedor del SO y Google Cloud, siguen siendo compatibles con la versión del SO.

Tu decisión también debe tener en cuenta lo siguiente:

  • Si una versión del SO determinada está disponible en Google Cloud. Las imágenes del SO que proporciona Compute Engine están configuradas para que funcionen con Google Cloud. Si un SO no está disponible en Google Cloud, puedes usar tu propia imagen de SO (BYOI) y licencia. Compute Engine hace referencia a las imágenes de SO de BYOI como imágenes personalizadas.
  • Las opciones de licencia disponibles para una versión determinada del SO. Revisa si la versión del SO tiene una opción de licencia a pedido o si necesitas usar tu propia suscripción (BYOS) del proveedor del SO.
  • Si las capacidades integradas de alta disponibilidad de una versión del SO determinada están habilitadas para Google Cloud.
  • Las opciones de descuento por compromiso de uso para imágenes de SLES para SAP y RHEL para SAP.

Los siguientes sistemas operativos están certificados por SAP para usarse con SAP NetWeaver en Google Cloud:

Puedes encontrar más información sobre versiones específicas de SO y su compatibilidad con SAP S/4HANA y SAP HANA en las siguientes guías:

Opción SAP HANA Fast Restart

Para SAP HANA 2.0 SP04 y versiones posteriores, Google Cloud recomienda enfáticamente la opción SAP HANA Fast Restart.

Esta opción se habilita de forma automática cuando implementas SAP HANA mediante los siguientes módulos de Terraform que proporciona Google Cloud: módulo sap_hana o sap_hana_ha, versión 202309280828 o posterior. Para obtener información sobre cómo habilitar de forma manual el reinicio rápido de SAP HANA, consulta Habilita el reinicio rápido de SAP HANA.

SAP HANA Fast Restart reduce los tiempos de reinicio en caso de que SAP HANA finalice, pero el sistema operativo permanezca en ejecución. Para reducir el tiempo de reinicio, SAP HANA aprovecha la funcionalidad de memoria persistente de SAP HANA MAIN para conservar los fragmentos de datos MAIN de las tablas de almacenamiento de columnas en DRAM que se asignan al sistema de archivos tmpfs.

Además, en las VMs de las familias M2 y M3 de los tipos de máquinas con optimización de memoria de Compute Engine, el reinicio rápido de SAP HANA mejora el tiempo de recuperación si se producen errores que no se pueden corregir en la memoria. Para obtener más información, consulta Opción de reinicio rápido de SAP HANA.

Arquitectura de implementación para SAP HANA

SAP HANA es un componente clave de cualquier sistema SAP S/4HANA porque funciona como una base de datos para el sistema. Existen dos arquitecturas posibles que puedes usar cuando implementas la base de datos de SAP HANA: escalamiento vertical y escalamiento horizontal.

Arquitectura de escalamiento vertical

En el siguiente diagrama, se muestra una arquitectura de escalamiento vertical para SAP HANA en Google Cloud: En el diagrama, observa la implementación en Google Cloud y el diseño del disco. Puedes usar Cloud Storage para hacer una copia de seguridad de tus copias de seguridad locales disponibles en /hanabackup. Esta activación debe tener un tamaño igual o superior al de la activación de datos.

Diagrama de la arquitectura para la implementación de un sistema de escalamiento vertical de SAP HANA en Google Cloud

Arquitectura de escalamiento horizontal

La arquitectura de escalamiento horizontal para SAP HANA consta de un host principal, varios hosts de trabajador y, de forma opcional, uno o más hosts de reserva. Los hosts están interconectados a través de una red que admite el envío de datos entre hosts a velocidades de hasta 32 Gbps o hasta 100 Gbps en tipos de máquinas seleccionados con redes de ancho de banda alto.

A medida que aumenta la demanda de carga de trabajo, sobre todo cuando se usa el procesamiento analítico en línea (OLAP), se puede distribuir la carga entre todos los hosts con una arquitectura de escalamiento horizontal de varios hosts.

En el siguiente diagrama, se muestra una arquitectura de escalamiento horizontal para SAP HANA en Google Cloud:

Diagrama de arquitectura para la implementación de un sistema de escalamiento horizontal de SAP HANA en Google Cloud.

Arquitectura de implementación para SAP S/4HANA

Como se mencionó en la sección Arquitectura, hay varias arquitecturas de implementación que puedes usar para implementar SAP S/4HANA en Google Cloud.

Arquitectura de dos niveles

Esta arquitectura se presenta en la sección implementación centralizada. En el siguiente diagrama, se muestran algunos detalles de una arquitectura de dos niveles para SAP S/4HANA que se ejecuta en una VM de Compute Engine:

Arquitectura de dos niveles para SAP S/4HANA en una VM de Compute Engine en Google Cloud.

Arquitectura de tres niveles

Esta arquitectura se presenta en la sección implementación distribuida. Puedes usar esta arquitectura para implementar sistemas SAP S/4HANA de alta disponibilidad. En el siguiente diagrama, se muestran algunos detalles de una arquitectura de tres niveles para SAP S/4HANA que se ejecuta en las VMs de Compute Engine:

Arquitectura de tres niveles para SAP S/4HANA en las VMs de Compute Engine en Google Cloud.

En esta arquitectura, el sistema SAP S/4HANA distribuye el trabajo a través de varios servidores de aplicaciones de NetWeaver (AS), cada uno alojado en una VM independiente. Todos los nodos de NetWeaver AS comparten la misma base de datos, que se aloja en una VM separada. Todos los nodos de NetWeaver AS se activan y acceden a un sistema de archivos compartidos que aloja los perfiles de SAP NetWeaver. Este sistema de archivos compartidos se aloja en un volumen de disco persistente compartido entre todos los nodos o en una solución de uso compartido de archivos compatible.

Security, privacy, and compliance

En esta sección, se proporciona información sobre la seguridad, la privacidad y el cumplimiento para ejecutar SAP S/4HANA en Google Cloud.

Cumplimiento y controles soberanos

Si necesitas que tu carga de trabajo de SAP se ejecute de acuerdo con los requisitos de residencia de datos, de control de acceso, de personal de asistencia o reglamentarios, debes planificar el uso de Assured Workloads, un servicio que te ayuda a ejecutar cargas de trabajo seguras y que cumplen con las normativas en Google Cloud sin perjudicar la calidad de tu experiencia en la nube. A fin de obtener más información, consulta Cumplimiento y controles soberanos para SAP en Google Cloud.

Herramientas de redes y seguridad de red

Ten en cuenta la información de las siguientes secciones cuando planifiques las herramientas de redes y la seguridad de red.

Modelo de privilegio mínimo

Una de tus primeras líneas de defensa es restringir quién puede alcanzar tu red y tus VMs. Para ello, usa las reglas de firewall de VPC. De forma predeterminada, el firewall bloquea todo el tráfico a las VMs, incluso desde otras VM, a menos que crees reglas para permitir el acceso. La excepción es la red predeterminada que se crea de forma automática con cada proyecto y tiene reglas de firewall predeterminadas.

Cuando creas reglas de firewall de VPC, puedes restringir todo el tráfico de un conjunto determinado de puertos a direcciones IP de origen específicas. Para restringir el acceso a las direcciones IP, los protocolos y los puertos específicos que necesitan acceso, sigue el modelo de privilegio mínimo. Por ejemplo, siempre configura un host de bastión y permite comunicaciones SSH en tu sistema SAP NetWeaver solo desde ese host.

Redes personalizadas y reglas de firewall

Puedes usar una red a fin de definir una IP de puerta de enlace y el rango de red para las VM adjuntas a esa red. Todas las redes de Compute Engine usan el protocolo IPv4. Todos los proyectos de Google Cloud cuentan con una red predeterminada que tiene opciones de configuración y reglas de firewall preestablecidas, pero te recomendamos que agregues una subred personalizada y reglas de firewall basadas en un modelo de privilegio mínimo. De forma predeterminada, una red recién creada no tiene reglas de firewall y, por lo tanto, no tiene acceso a la red.

Te recomendamos agregar más de una subred si deseas aislar partes de tu red o satisfacer otros requisitos. Para obtener más información, consulta Redes y subredes.

Las reglas del firewall aplican a toda la red y a todas las VMs en ella. Puedes agregar una regla de firewall que permita el tráfico entre VMs de la misma red y entre subredes. También puedes configurar firewalls para que se apliquen a VMs de destino específicas mediante etiquetas de red.

Debido a que SAP requiere acceso a ciertos puertos, debes agregar reglas de firewall para permitir el acceso a los puertos que indica SAP.

Rutas

Las rutas son recursos globales conectados a una red única. Las rutas que crea el usuario aplican a todas las VMs en una red. Esto significa que puedes agregar una ruta que desvía el tráfico de VM a VM dentro de la misma red y a través de subredes sin necesidad de direcciones IP externas.

Para otorgar acceso externo a recursos de Internet, inicia una VM sin dirección IP externa y configura otra VM como una puerta de enlace NAT. Esta configuración requiere que agregues tu puerta de enlace NAT como una ruta para tu instancia de SAP.

Hosts de bastión y puertas de enlace NAT

Si tu política de seguridad requiere VMs que sean realmente internas, debes configurar un proxy NAT de forma manual en tu red y una ruta correspondiente para que las VMS puedan acceder a Internet. Es importante tener en cuenta que no puedes conectarte directamente a una instancia de VM interna a través de SSH.

Para conectarte a esas máquinas internas, debes configurar una instancia de bastión que tenga una dirección IP externa y, luego, crear un túnel a través de ella. Cuando las VMs no tienen direcciones IP externas, solo se puede acceder a ellas desde otras VMs de la red o a través de una puerta de enlace de VPN administrada. Puedes aprovisionar las VMs en tu red a fin de que actúen como retransmisiones de confianza para las conexiones entrantes, llamadas hosts de bastión, o salidas de red, llamadas puertas de enlace NAT. Para obtener una conectividad más transparente sin configurar esas conexiones, puedes usar un recurso administrado de puerta de enlace de VPN.

Hosts de bastión para las conexiones entrantes

Los hosts de bastión proporcionan un punto de entrada externo a una red que contiene VMs de red privada. Este host puede proporcionar un único punto de fortificación o auditoría y puede iniciarse y detenerse para habilitar o inhabilitar la comunicación SSH entrante desde Internet.

Host de bastión en una situación de SSH

El acceso SSH a las VMs que no tienen una dirección IP externa se puede lograr si primero te conectas a un host de bastión. Aunque el endurecimiento completo de un host de bastión no está incluido en este documento, te presentamos algunos pasos iniciales que se pueden seguir:

  • Limitar el rango CIDR de las IP de origen que se pueden comunicar con el bastión.
  • Configurar las reglas de firewall para permitir el tráfico SSH a VM privadas solo desde el Host de bastión

De forma predeterminada, el SSH en VM está configurado de modo que use claves privadas para la autenticación. Cuando usas un Host de bastión, primero debes acceder a él y, luego, a tu VM privada de destino. Debido a este acceso en dos pasos, te recomendamos que uses el reenvío del agente de SSH para alcanzar la VM de destino, en lugar de almacenar la clave privada de la VM de destino en el host de bastión. Debes hacer esto incluso si usas el mismo par clave-valor para las VMs de bastión y de destino porque el bastión tiene acceso directo solo a la mitad pública del par de claves.

Puertas de enlace NAT para la transferencia de datos salientes

Cuando una VM no tiene una dirección IP externa asignada, no puede establecer conexiones directas a servicios externos, incluidos otros servicios de Google Cloud. Para permitir que estas VMs alcancen servicios en Internet, puedes establecer y configurar una puerta de enlace NAT. La puerta de enlace NAT es una VM que puede enrutar el tráfico en nombre de cualquier otra VM de la red. Usa una puerta de enlace NAT por red. Una puerta de enlace NAT de VM única no tiene alta disponibilidad y no puede admitir una capacidad de procesamiento alta para varias VMs. Si deseas obtener información sobre cómo configurar una VM para que actúe como puerta de enlace NAT, consulta la guía de implementación de tu sistema operativo:

Cloud VPN

Puedes conectar de forma segura tu red existente a Google Cloud a través de una conexión VPN que usa IPsec mediante Cloud VPN. Una puerta de enlace de VPN encripta el tráfico que viaja entre las dos redes, el que, luego, es desencriptado por la otra puerta de enlace de VPN. Esto protege sus datos mientras viajan por Internet. Puedes controlar de forma dinámica qué VMs pueden enviar tráfico a través de la VPN mediante etiquetas de instancia en las rutas. Los túneles de Cloud VPN se facturan con una tarifa mensual estática más los cargos estándar por la transferencia de datos salientes. Ten en cuenta que la conexión de dos redes en el mismo proyecto genera cargos estándar por la transferencia de datos salientes. Para obtener más información, consulte:

Seguridad para los buckets de Cloud Storage

Si usas Cloud Storage para alojar copias de seguridad de tus datos y volúmenes de registro, asegúrate de usar TLS (HTTPS) cuando envíes datos a Cloud Storage desde tus VMs para proteger los datos en tránsito.

Si bien Cloud Storage encripta los datos en reposo automáticamente, puedes especificar tus propias claves de encriptación si tienes tu propio sistema de administración de claves.

Límites de notificaciones por correo electrónico

Para ayudar a proteger tus sistemas y los de Google contra el abuso, Google Cloud aplica limitaciones al envío de correos electrónicos desde Compute Engine. Esto tiene implicaciones para la transacción SCOT en sistemas SAP NetWeaver ABAP porque requiere una configuración específica en comparación con los sistemas locales.

Para obtener más información, incluida la información sobre cómo configurar SCOT, consulta Envía correos electrónicos desde una instancia.

Para obtener más información sobre los recursos de seguridad para tu entorno de SAP en Google Cloud, consulta los siguientes vínculos:

Confiabilidad

En esta sección, se proporciona información sobre aspectos relacionados con la confiabilidad para ejecutar SAP S/4HANA en Google Cloud.

Alta disponibilidad y recuperación ante desastres

La alta disponibilidad (HA) y la recuperación ante desastres (DR) son conjuntos de técnicas, prácticas de ingeniería y principios de diseño para controlar la continuidad empresarial en caso de fallas. Estos enfoques funcionan mediante la eliminación de los puntos únicos de fallo y el suministro de la capacidad de reanudar rápidamente las operaciones después de una interrupción del sistema o componente con una alteración empresarial mínima. La recuperación de errores es el proceso de recuperación y reanudación de operaciones después de una interrupción debido a un componente con errores.

Por ejemplo, las siguientes son algunas herramientas de alta disponibilidad y DR que puedes usar:

A continuación, presentamos más detalles sobre algunas de estas herramientas:

  • Agrupamiento en clústeres de Linux en zonas diferentes: Configura tu clúster de Linux en zonas diferentes para proteger contra fallas de componentes en una región determinada.

    En la capa de la aplicación de SAP NetWeaver, puedes implementar un clúster de Linux en varias zonas para reducir el impacto de una falla en el ASCS y hacer que tenga alta disponibilidad en ambos nodos en diferentes zonas. Luego, el clúster de Linux mueve el ASCS al nodo en espera en caso de que el nodo principal tenga algún problema o se esté realizando mantenimiento. Además, puedes usar un Enqueue Replication Server para replicar el contenido de la tabla en cola para que Enqueue Server mantenga el contenido de la tabla en cola en el nodo en espera en caso de que el proceso ascienda de principal a en espera.

    En la capa de la base de datos de SAP HANA, puedes implementar un clúster de Linux entre zonas mediante una configuración activa y pasiva, o una configuración activa/activa. En ambos casos, debes comenzar por configurar dos instancias de Compute Engine en zonas separadas, cada una con su propia base de datos de SAP HANA.

    • Configuración activa/pasiva: Configura una instancia como el nodo principal del clúster (activa) y la otra como el nodo secundario (pasiva). Usa la replicación del sistema (SR) de SAP HANA para configurar el nodo secundario de modo que se convierta en el principal si este falla. Para obtener más información sobre cómo configurar y establecer la SR de HANA, consulta HANA System Replication (Replicación del sistema de HANA).
    • Configuración activa/activa (habilitada para lectura): Configura ambas instancias para que estén activas, pero que el nodo secundario sea de solo lectura. Esta configuración se basa en la repetición continua de registros. La IP virtual (VIP) está configurada para apuntar al nodo de lectura y escritura actual. Para obtener más información, consulta Activa/Activa (lectura habilitada).

    Además, es posible usar la replicación del sistema SAP HANA como una solución de recuperación ante desastres. La base de datos principal replica su contenido en la base de datos en espera, que se puede usar en caso de que la principal se desconecte, lo que permite que el sistema SAP siga funcionando hasta que se restablezca el servicio en la base de datos principal. En este caso, el ascenso del nodo secundario no ocurre automáticamente, debe realizarse de forma manual. También puedes combinar la HA y la DR en SAP HANA para aumentar la resiliencia y la disponibilidad. Para obtener más información, consulte:

  • Migración en vivo: Compute Engine ofrece migración en vivo para mantener las instancias de VM en ejecución, incluso cuando ocurre un evento del sistema host, como una actualización de software o hardware. En esa situación, Compute Engine realiza una migración en vivo de tu instancia en ejecución a otro host en la misma zona, en lugar de requerir que se reinicie la instancia en ejecución. El mecanismo replica el estado de la VM de la instancia original, por lo que, cuando aparece la nueva instancia, ya tiene cargada la memoria de la instancia original.

    En el caso poco frecuente de que la migración en vivo no se realice, la máquina virtual con errores se reinicia de manera automática en el nuevo hardware dentro de la misma zona. Para obtener más información, consulta Proceso de migración en vivo durante los eventos de mantenimiento.

Optimización de costos

En esta sección, se proporciona información sobre licencias, descuentos y estimación del tamaño de la carga de trabajo.

Licencias

Si eres cliente de SAP, puedes usar tu licencia existente para implementar SAP S/4HANA con Google Cloud con el modelo de licencia adquirida por el usuario (BYOL). Google Cloud admite el modelo BYOL para casos de uso de producción y no producción. Las licencias del sistema operativo están incluidas en los precios de Compute Engine.

Como alternativa, también puedes usar tu propia imagen de SO y licencias. Para obtener más información, consulta Imágenes de SO personalizadas.

Descuentos

Con el modelo de precios de “pago por uso” de Google Cloud, solo pagas por los servicios que usas. No es necesario que te comprometas a un tamaño o servicio en particular; puedes modificar o detener el uso según sea necesario. Para las cargas de trabajo predecibles, Compute Engine proporciona descuentos por compromiso de uso (CUD) que ayudan a reducir el costo de tu infraestructura, ya que se compromete a un contrato a cambio de grandes descuentos en los precios de uso de VMs.

Google Cloud ofrece estos descuentos a cambio de adquirir contratos de compromiso de uso, también conocidos como compromisos. Cuando compras un compromiso, te comprometes a usar una cantidad mínima de recursos o a realizar un gasto mínimo durante un período específico de uno o tres años. Estos descuentos te ayudan a reducir la factura mensual de los recursos que usa tu sistema SAP S/4HANA. Para obtener más información, consulta Descuentos por compromiso de uso (CUD).

Estimaciones de tamaño

Los siguientes recursos proporcionan información sobre cómo realizar estimaciones de tamaño para tus sistemas SAP antes de migrarlos a Google Cloud:

Eficiencia operativa

En esta sección, se proporciona información sobre cómo optimizar la eficiencia operativa de SAP S/4HANA en Google Cloud.

Crear copia de seguridad y de recuperación

Crea copias de seguridad de tu servidor de aplicaciones y de la base de datos de forma periódica para que puedas recuperarlos en caso de una falla del sistema, daños en los datos o cualquier otro problema.

Tienes varias opciones para crear una copia de seguridad de los datos de SAP HANA en Google Cloud, incluidas las siguientes:

Crea una copia de seguridad en Cloud Storage

A partir de la versión 3.0, el agente de Google Cloud para SAP admite la función Backint, que permite a SAP HANA crear copias de seguridad y recuperar copias de seguridad de bases de datos directamente desde Cloud Storage. Esta nueva función está disponible para instancias de SAP HANA que se ejecutan en instancias de VM de Compute Engine, servidores de la solución Bare Metal, servidores locales o en otras plataformas en la nube a fin de que puedas crear copias de seguridad directamente y recuperarte de Cloud Storage sin necesidad de almacenamiento en disco persistente para tus copias de seguridad. Para obtener más información, consulta la guía de operaciones de SAP HANA

Para obtener información sobre la certificación de SAP de esta función del agente, consulta la nota de SAP 2031547: descripción general de las herramientas de copia de seguridad de terceros certificadas por SAP y el proceso de asistencia asociado.

En el siguiente diagrama, se muestra el flujo de copias de seguridad cuando usas la función de Backint del agente de Google Cloud para SAP:

Diagrama que muestra la copia de seguridad de los datos de SAP HANA en Cloud Storage mediante el agente de Google Cloud para SAP.

Crea copias de seguridad en discos

Puedes usar la función de copia de seguridad y recuperación nativas de SAP con volúmenes de Persistent Disk de Compute Engine y usar un bucket de Cloud Storage para el almacenamiento a largo plazo de las copias de seguridad.

Durante el funcionamiento normal SAP HANA guarda de forma automática los datos de la memoria en el disco en puntos de guardado regulares. Además, todos los cambios en los datos se capturan en las entradas del registro para rehacer. Se escribe una entrada de registro para rehacer en el disco después de cada transacción de base de datos confirmada.

Desde SAP HANA 2.0 y versiones posteriores, usa SAP HANA Cockpit para crear copias de seguridad de SAP HANA.

En el siguiente diagrama, se muestra el flujo de la función de copia de seguridad de SAP HANA:

Diagrama que muestra una copia de seguridad de los datos de SAP HANA en un disco de almacenamiento persistente.

Crea copias de seguridad de los discos con instantáneas

Otra opción que puedes agregar a la estrategia de copia de seguridad es tomar instantáneas de discos completos mediante la función de instantánea de disco de Compute Engine. Por ejemplo, puedes tomar instantáneas programadas del disco que aloja tu directorio /hanabackup para usarlas en situaciones de recuperación ante desastres. También es posible usar instantáneas de disco para crear copias de seguridad y recuperar el volumen de datos de SAP HANA. Para garantizar la coherencia de la aplicación, toma instantáneas cuando no se realicen cambios en el volumen de destino. Las instantáneas se generan en el nivel del bloque.

Después de la primera instantánea, cada instantánea posterior es incremental y almacena solo los cambios de bloque incrementales, como aparece en este diagrama.

Cuando usas la versión 3.0 o posterior del agente de Google Cloud para SAP, puedes crear copias de seguridad y realizar la recuperación de SAP HANA con la función de instantánea de disco del agente. Si deseas obtener más información, consulta Copia de seguridad y recuperación para SAP HANA mediante instantáneas de disco.

Diagrama que muestra la copia de seguridad de los datos de SAP HANA mediante instantáneas de disco.

Recuperación

Las herramientas de recuperación de SAP HANA pueden recuperar el momento más reciente o un momento específico, y puedes usarlas para restablecer a un sistema nuevo o crear una copia de la base de datos. A diferencia de las copias de seguridad, que puedes ejecutar mientras la base de datos está en funcionamiento, solo puedes usar las herramientas de recuperación mientras la base de datos está inactiva. Puedes elegir una opción adecuada entre las siguientes:

  • Restablece al estado más reciente mediante uno de los siguientes recursos:
    • Instantánea o copia de seguridad completa
    • Copia de seguridad de registros
    • Entradas de registro para rehacer que aún están disponibles
  • Restablecimiento a un momento en el pasado
  • Restablecimiento a una copia de seguridad completa especificada

Supervisión

Para supervisar y proporcionar asistencia para las cargas de trabajo de SAP que se ejecutan en instancias de VM de Compute Engine y servidores de la solución Bare Metal, Google Cloud proporciona el agente para SAP.

Según lo exige SAP, para obtener asistencia de SAP y permitir que SAP cumpla con sus acuerdos de nivel de servicio (ANS), debes instalar el Agente de Google Cloud para SAP en todas las instancias de VM de Compute Engine y los servidores de la solución Bare Metal que ejecutan cualquier sistema SAP. Para obtener más información sobre los requisitos previos de asistencia, consulta la nota de SAP Nota de SAP 2456406: SAP en Google Cloud Platform: requisitos previos de compatibilidad.

Además de la recopilación obligatoria de métricas de SAP Host Agent, en Linux, el agente de Google Cloud para SAP incluye funciones opcionales como la recopilación de métricas de Process Monitoring y métricas de validación de Workload Manager. Puedes habilitar estas funciones que habilitan productos y funciones como la administración de cargas de trabajo para tus cargas de trabajo de SAP.

Optimización del rendimiento

En esta sección, se proporciona información sobre cómo optimizar el rendimiento de las cargas de trabajo de SAP S/4HANA mediante el tamaño y la configuración de la red.

Dimensionamiento

Hay varias opciones de dimensionamiento disponibles según el tipo de implementación. En el caso de las implementaciones greenfield, te recomendamos usar la herramienta SAP Quick Sizer. Para obtener información detallada, consulta la página sobre dimensionamiento de SAP. SAP también proporciona guías con tablas que te ayudan a determinar los requisitos de soluciones y herramientas específicas a fin de migrar las soluciones locales actuales a Google Cloud. Por ejemplo, consulta Directorio de hardware de SAP HANA certificado y compatible y nota de SAP Nota de SAP 2456432 - Aplicaciones de SAP en Google Cloud: Productos compatibles y Tipos de máquinas de Google Cloud SAP y Google Cloud usan diferentes unidades para medir las IOPS (operaciones de entrada y salida por segundo). Consulta a tu socio de SI (integrador de sistemas) para convertir los requisitos de tamaño de SAP en una infraestructura de Google Cloud del tamaño adecuado.

Antes de migrar los sistemas existentes de SAP ECC a S/4HANA, SAP recomienda que ejecutes el informe /SDF/HDB_SIZING, como se describe en la nota de SAP 1872170 - ABAP en el informe de tamaño de HANA (S/4HANA). , Suite en HANA...). En este informe sobre dimensionamiento, se analizan las necesidades actuales de procesamiento y memoria de tu sistema fuente, y se proporciona información sobre los requisitos para trasladarse a S/4HANA.

Configuración de red

Las capacidades de tu red de VMs de Compute Engine se determinan por su familia de máquinas y no por la interfaz de red (NIC) ni la dirección IP.

Según su tipo de máquina, la instancia de VM es capaz de tener una capacidad de procesamiento de red de 2 a 32 Gbps. Ciertos tipos de máquinas también admiten capacidad de procesamiento de hasta 100 Gbps, lo que requiere el uso del tipo de interfaz NIC virtual (gVNIC) de Google con una configuración de red Tier_1. El logro de estas tasas de capacidad de procesamiento depende aún más de la dirección del tráfico y del tipo de dirección IP de destino.

Las interfaces de red de VMs de Compute Engine están respaldadas por la infraestructura de red redundante y resiliente mediante componentes de red físicos y definidos por software. Estas interfaces heredan la redundancia y la resiliencia de la plataforma subyacente. Se pueden usar varias NIC virtuales para la separación de tráfico, pero no ofrecen beneficios adicionales de resiliencia ni rendimiento.

Una sola NIC proporciona el rendimiento necesario para las implementaciones de SAP HANA en Compute Engine. Tu caso de uso en particular, los requisitos de seguridad o las preferencias también pueden requerir interfaces adicionales para separar el tráfico, como el tráfico de Internet, el tráfico interno de replicación del sistema SAP HANA o algún otro flujo que podría beneficiarse de reglas de políticas de red específicas. Te recomendamos que uses la encriptación de tráfico que ofrece la aplicación y que protejas el acceso a la red según la política de firewall de privilegio mínimo para restringir el acceso.

Considera la necesidad de separar el tráfico al comienzo como parte del diseño de tu red y asignar NIC adicionales cuando implementes las VMs. Debes conectar cada interfaz de red a una red de VPC diferente. La elección de la cantidad de interfaces de red depende del nivel de aislamiento que se necesite, con hasta 8 interfaces para VMs con 8 CPU virtuales o más.

Por ejemplo, puedes definir una red de VPC para los clientes de aplicaciones SQL de SAP HANA, como los servidores de aplicaciones SAP NetWeaver y las aplicaciones personalizadas, y una red de VPC independiente para el tráfico entre servidores, como SAP Replicación del sistema HANA Ten en cuenta que demasiados segmentos pueden complicar la administración y la solución de problemas de red. Si cambias de opinión más adelante, puedes usar las imágenes de máquina de Compute Engine para volver a crear tu instancia de VM y, a su vez, conservar toda la configuración, los metadatos y los datos asociados.

Para obtener más información, consulte:

Implementación

En esta sección, se proporciona información relacionada con la implementación de SAP S/4HANA en Google Cloud.

Notas importantes de SAP previas a la implementación

Antes de comenzar a implementar un sistema SAP S/4HANA en Google Cloud, lee las siguientes notas de SAP. Además, antes de comenzar cualquier implementación de SAP, revisa SAP Marketplace en busca de notas y guías de instalación de productos actualizadas.

Automatización de la implementación

Para instalar SAP S/4HANA en Google Cloud, puedes usar las siguientes opciones de implementación:

  • Para automatizar la implementación de un sistema distribuido o distribuido con alta disponibilidad (HA), puedes usar la herramienta de automatización de implementación guiada en Workload Manager. Esta herramienta te permite configurar y, luego, implementar cargas de trabajo de SAP compatibles directamente desde la consola de Google Cloud, o generar y descargar el código equivalente de Terraform y Ansible. Para obtener más información, consulta Acerca de la automatización de la implementación guiada.
  • Para automatizar la implementación de un sistema SAP HANA centralizado o distribuido, puedes usar las configuraciones de Terraform que proporciona Google Cloud. Para obtener más información, consulta la guía de implementación para tu situación de SAP HANA.

¿Qué sigue?