Arquitectura de referencia: SAP Business Suite en SAP ASE o IBM Db2 en Google Cloud

Esta arquitectura de referencia está dirigida a personas que evalúan Google Cloud como una plataforma para implementar aplicaciones de SAP Business Suite en SAP ASE o IBM Db2. Incluye consideraciones durante la fase de planificación, modelos de implementación y automatización, y procedimientos operativos comunes, como las tareas de copia de seguridad y DR.

Google Cloud ofrece una infraestructura rentable, confiable, segura y de alto rendimiento certificada por SAP para ejecutar SAP Business Suite en SAP ASE o IBM Db2. 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 Business Suite: centralizado, distribuido y distribuido con alta disponibilidad.

Implementación centralizada

En una implementación centralizada, puedes instalar SAP Business Suite y la base de datos de SAP ASE o IBM Db2 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 las siguientes secciones, se muestran arquitecturas de referencia de SAP Business Suite en IBM Db2 y SAP ASE en implementaciones centralizadas.

Implementación centralizada de SAP Business Suite con SAP ASE

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

Diagrama de arquitectura de SAP Business Suite en SAP ASE en Google Cloud en una implementación centralizada.

Implementación centralizada de SAP Business Suite con IBM Db2

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

Diagrama de arquitectura de SAP Business Suite en IBM Db2 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.

Implementación distribuida de SAP Business Suite con SAP ASE

En el siguiente diagrama, se muestra una arquitectura de referencia de SAP Business Suite en SAP ASE en una implementación distribuida. Ten en cuenta que SAP ASCS, PAS, WD y ASE se instalan en instancias de VM diferentes.

Diagrama de arquitectura de SAP Business Suite en SAP ASE en Google Cloud en una implementación distribuida.

Implementación distribuida de SAP Business Suite con IBM Db2

En el diagrama siguiente, se muestra una arquitectura de referencia de SAP Business Suite en IBM Db2 en una implementación distribuida. Ten en cuenta que SAP ASCS, PAS, WD e IBM Db2 se instalan en instancias de VM diferentes.

Diagrama de arquitectura de SAP Business Suite en IBM Db2 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/pasiva. 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 ASE o IBM Db2.

  • Implementación distribuida de SAP ASE con alta disponibilidad: Puedes implementar una base de datos de SAP ASE de alta disponibilidad y tolerante a desastres (HADR) en Google Cloud que es compatible con SAP. Si deseas obtener más información, consulta la guía de planificación para SAP ASE.

    En el siguiente diagrama, se ilustra una arquitectura de SAP Business Suite en SAP ASE que usa un clúster de Linux para lograr una alta disponibilidad en la aplicación y en la base de datos:

    Diagrama de arquitectura de SAP Business Suite en SAP ASE en Google Cloud en una implementación distribuida de alta disponibilidad.

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

    • Tres VMs de host, dos hosts con una instancia de base de datos y uno con Fault Manager
    • Replicación síncrona de SAP ASE.
    • El administrador de recursos del clúster de alta disponibilidad de Pacemaker
    • Un mecanismo de protección que usa Fault Manager para garantizar el aislamiento de los recursos con errores.
    • Reinicio automático de la instancia con errores como la nueva instancia secundaria y registro nuevo automático para la replicación de SAP ASE.
  • Implementación distribuida de IBM Db2 con alta disponibilidad: Puedes implementar una base de datos de IBM Db2 con alta disponibilidad y tolerante a desastres (HADR) en Google Cloud que sea compatible con SAP. Si deseas obtener más información, consulta la Guía de planificación de IBM Db2 para SAP.

    Puedes configurar un clúster de HADR de Pacemaker de dos hosts con la solución de agrupamiento en clústeres que proporciona IBM para Db2. Si deseas obtener más información, consulta la Guía de administración de bases de datos para SAP en IBM Db2 para Linux, Unix y Windows en el PDF de SAP.

    En el siguiente diagrama, se ilustra una arquitectura de SAP Business Suite en IBM Db2 que usa un clúster de Linux para lograr una alta disponibilidad en la aplicación y en la base de datos.

    Diagrama de arquitectura de SAP Business Suite en IBM Db2 en Google Cloud en una implementación distribuida de alta disponibilidad.

    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 IBM Db2.
    • Replicación síncrona de HADR de IBM Db2.
    • Un administrador de recursos de clúster de alta disponibilidad de Linux, como Pacemaker.
    • Un mecanismo de protección que protege el nodo con errores.
    • Un balanceador de cargas de aplicaciones interno para enrutar la VIP al nodo activo.
    • Reinicio automático de la instancia con errores como la nueva instancia secundaria y reregistro automático para HADR de IBM Db2.

La arquitectura de la aplicación es similar. En este caso, el clúster administra ABAP SAP Central Services (ASCS) y Enqueue Replication Server o Enqueue Replicator (ERS) que se usan para proporcionar al sistema SAP Business Suite una alta disponibilidad en caso de que algo le ocurra a cualquiera de las instancias de ASCS y ERS.

Según la versión de SAP NetWeaver que uses con el sistema de SAP Business Suite, Enqueue Server y Enqueue Replication Server / Enqueue Replicator se ejecutan en una versión diferente:

En el siguiente diagrama, se muestra un sistema de SAP Business Suite que usa un clúster de Pacemaker para limitar los puntos únicos de fallo del servidor de mensajes y Enqueue Server:

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 distribuido de SAP Business Suite en SAP ASE o IBM Db2, 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 Business Suite en SAP ASE o IBM Db2 consta de los siguientes componentes técnicos:

  • Base de datos SAP ASE o IBM Db2
  • Fault Manager, solo en SAP ASE
    • Tiene su propio servidor host y supervisa los servidores principal y en espera. Fault Manager garantiza una alta disponibilidad de SAP ASE mediante el inicio de la conmutación por error automática. Supervisa los componentes siguientes: Replication Management Agent, servidor de replicación, aplicaciones, bases de datos y sistema operativo. También te permite comprobar el estado de la base de datos y reiniciarla, si es necesario.
  • 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 de SAP Business Suite.
    • 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 de SAP Business Suite.
    • 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 Business Suite en SAP ASE o IBM Db2:

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 de SAP Business Suite desde la perspectiva de 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 ASE o IBM Db2 (principal y secundario).

Existen varias formas de compilar tu red y conectar el sistema de SAP Business Suite 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 Business Suite en una sola VPC compartida o en varias VPC compartidas. Las dos situaciones difieren en términos de control de red, inspección de red y aislamiento del entorno de SAP:

  • Situación 1: Implementación de SAP Business Suite 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 Business Suite 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 de SAP Business Suite en SAP ASE o IBM Db2 tiene algunos puntos únicos de fallo 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 SAP ASE o IBM Db2
  • 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 de SAP Business Suite o SAP ASE o IBM Db2, 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 Business Suite en SAP ASE o IBM Db2, 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.

En función de los datos y los valores acordados entre todas las partes interesadas, el sistema de SAP Business Suite 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 de SAP Business Suite en SAP ASE o IBM Db2 en Google Cloud.

Tipos de máquinas compatibles con las instancias de SAP Business Suite

Google Cloud ofrece tipos de instancias de VM de Compute Engine que están certificados por SAP para cumplir con los requisitos de tamaño cuando implementas SAP Business Suite con SAP ASE o IBM Db2. Si deseas obtener más información sobre el dimensionamiento en Google Cloud y los tipos de máquinas compatibles, consulta los siguientes documentos:

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 para almacenar SAP Business Suite

Las siguientes son las opciones de almacenamiento que ofrece Google Cloud y que están certificadas por SAP para usarse con SAP Business Suite y SAP ASE o IBM Db2.

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. 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. 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 de SAP Business Suite en Google Cloud, consulta Soluciones de uso compartido de 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 ASE o IBM Db2. 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, incluidos SAP ASE o IBM Db2. 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 ASE

En las siguientes tablas, se describen las estructuras de directorios para el sistema de SAP Business Suite en la base de datos de SAP ASE en Google Cloud.

  • Estructura de directorios de Linux recomendada para una instancia de SAP ABAP genérica:

    Directorio de Linux 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.

  • La siguiente es la estructura de directorios de Linux recomendada para SAP Business Suite en SAP ASE en Google Cloud.

    Ten en cuenta que todos los datos y archivos de registro de la base de datos de SAP ASE deben ubicarse en el directorio /sybase/SAP_SID. Reemplaza SAP_SID por el identificador del sistema SAP (SID), que es el número de instancia de SAP que usaste durante la instalación de la base de datos.

    Directorio de SAP ASE Opción de almacenamiento recomendada en Google Cloud
    /usr/sap Disco persistente balanceado
    /sybase/SAP_SID/sapdata1 Persistent Disk o Hyperdisk basados en SSD
    /sybase/SAP_SID/log_dir Persistent Disk o Hyperdisk basados en SSD
    /sybase/SAP_SID/saptemp Disco persistente balanceado
    /sybase/SAP_SID/sapdiag Disco persistente balanceado

    Si deseas obtener información de SAP sobre la ejecución de SAP ASE, consulta Aplicaciones SAP en SAP Adaptive Server Enterprise: prácticas recomendadas para la migración y el entorno de ejecución.

  • A continuación, se muestra la estructura de directorios de Windows recomendada para SAP Business Suite en SAP ASE en Google Cloud. La siguiente estructura de directorios se aplica a la instalación del servidor central.

    Drive Descripción Opción de almacenamiento recomendada en Google Cloud
    C:\ Inicio Disco persistente balanceado
    D:\ Objetos binarios de la base de datos Disco persistente balanceado
    E:\ Archivos de datos de la base de datos Persistent Disk o Hyperdisk basados en SSD
    L:\ Archivos de registro de la base de datos Persistent Disk o Hyperdisk basados en SSD
    P:\ Archivo de página Disco persistente balanceado
    S:\ Directorios /usr/sap y /sapmnt Disco persistente balanceado
    T:\ Directorios temp y saptemp Disco persistente balanceado
    X:\ Copia de seguridad Disco persistente balanceado

    Si deseas obtener información de SAP sobre la ejecución de SAP ASE, consulta Aplicaciones SAP en SAP Adaptive Server Enterprise: prácticas recomendadas para la migración y el entorno de ejecución.

Opciones de almacenamiento y estructura de directorios de IBM Db2

En las siguientes tablas, se describen las estructuras de directorios del sistema SAP Business Suite en la base de datos IBM Db2 en Google Cloud.

  • Estructura de directorios de Linux recomendada para SAP Business Suite en IBM Db2 en Google Cloud:

    Estructura de directorios de IBM Db2 Opción de almacenamiento recomendada en Google Cloud
    /sapmnt Disco persistente balanceado
    /usr/sap Disco persistente balanceado
    /db2/DB_SID Disco persistente balanceado
    /db2/DB_SID/db2dump Disco persistente balanceado
    /db2/DB_SID/sapdata1 Persistent Disk o Hyperdisk basados en SSD
    /db2/DB_SID/log_dir Persistent Disk o Hyperdisk basados en SSD
    /db2/DB_SID/saptmp1 Disco persistente balanceado
    /db2backup Disco persistente balanceado

    Si deseas obtener información de SAP sobre cómo ejecutar sistemas SAP en IBM Db2, consulta SAP en IBM Db2 para Linux, UNIX y Windows.

  • La siguiente es la estructura de directorios de Windows recomendada para SAP Business Suite en IBM Db2 en Google Cloud. Esta estructura de directorios se aplica a la instalación del servidor central.

    Drive Descripción Opción de almacenamiento recomendada en Google Cloud
    C:\ Inicio Disco persistente balanceado
    D:\ Objetos binarios de la base de datos Disco persistente balanceado
    E:\ Archivos de datos de la base de datos Persistent Disk o Hyperdisk basados en SSD
    L:\ Archivos de registro de la base de datos Persistent Disk o Hyperdisk basados en SSD
    P:\ Archivo de página Disco persistente balanceado
    S:\ Directorios /usr/sap y /sapmnt Disco persistente balanceado
    T:\ Directorios temp y saptemp Disco persistente balanceado
    X:\ Copia de seguridad Disco persistente balanceado

    Para obtener más información sobre las estructuras de directorios, consulta la guía de planificación de SAP NetWeaver. Para obtener información sobre cómo calcular el tamaño del archivo de paginación, consulta la nota de SAP 1518419: Archivo de paginación y memoria virtual requeridos por el sistema SAP.

Compatibilidad del SO con SAP Business Suite

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 Business Suite y SAP ASE o IBM Db2 en las siguientes guías:

Arquitectura de implementación para SAP ASE

SAP ASE es un componente clave de cualquier sistema de SAP Business Suite porque funciona como uno de los tipos de bases de datos posibles para el sistema.

En el siguiente diagrama, se muestra una arquitectura de implementación para SAP ASE en Google Cloud. En el diagrama, toma nota de 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 /sybasebackup. Esta activación debe tener un tamaño igual o superior al de la activación de datos.

Diagrama de arquitectura para la implementación de SAP ASE en Google Cloud.

Arquitectura de implementación para IBM Db2

IBM Db2 es un componente clave de cualquier sistema de SAP Business Suite porque funciona como uno de los tipos de bases de datos posibles para el sistema.

En el siguiente diagrama, se muestra una arquitectura de implementación para IBM Db2 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 /db2backup. 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 IBM Db2 en Google Cloud

Arquitectura de implementación para SAP Business Suite

Como se mencionó en la sección Arquitectura, hay varias arquitecturas de implementación que puedes usar para implementar SAP Business Suite en SAP ASE o IBM Db2 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 Business Suite que se ejecuta en una VM de Compute Engine:

Arquitectura de dos niveles para SAP Business Suite en SAP ASE o IBM Db2 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 de SAP Business Suite de alta disponibilidad. En el siguiente diagrama, se muestran algunos detalles de una arquitectura de tres niveles para SAP Business Suite que se ejecuta en las VMs de Compute Engine:

Arquitectura de tres niveles para SAP Business Suite en SAP ASE o IBM Db2 en una VM de Compute Engine en Google Cloud.

En esta arquitectura, el sistema de SAP Business Suite distribuye el trabajo en varios servidores NetWeaver Application Server (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 Business Suite en SAP ASE o IBM Db2 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 Business Suite en SAP ASE o IBM Db2 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:

Alta disponibilidad de SAP ASE

Puedes lograr una alta disponibilidad para tu base de datos SAP ASE en Google Cloud mediante la configuración de la replicación síncrona entre los servidores principal y en espera, lo que permite que los dos servidores estén siempre sincronizados con cero pérdidas de datos. En Google Cloud, se admite la opción siempre activa de SAP ASE, que es un sistema de alta disponibilidad y recuperación ante desastres (HADR). Para obtener más información, consulta la guía de planificación de SAP ASE.

Las instancias de VM que alojan los servidores principales y en espera deben tener los siguientes componentes:

  • SAP ASE
  • SAP Host Agent, que supervisa el uso del servidor de la CPU, la memoria y otros recursos
  • Agente de administración de replicación (RMA)
  • SAP ASE Cockpit, que realiza actividades de la base de datos
  • Fault Manager, que tiene su propio servidor host. Supervisa los servidores SAP ASE primario y en espera. Fault Manager garantiza una alta disponibilidad de ASE mediante el inicio de la conmutación por error automática. Supervisa los componentes siguientes: RMA, servidor de replicación, aplicaciones, bases de datos y sistema operativo. También te permite comprobar el estado de la base de datos y reiniciarla, si es necesario.

Para mejorar la disponibilidad del sistema, un clúster de SAP ASE permite mover las cargas de trabajo al nodo secundario mediante la supervisión de la falla del nodo principal. En el siguiente diagrama, se muestra una arquitectura de referencia de alto nivel que demuestra cómo se pueden instalar los componentes de SAP ASE descritos en Google Cloud.

Arquitectura para un sistema SAP ASE de alta disponibilidad en Google Cloud

Recuperación ante desastres de SAP ASE

El sistema HADR de SAP ASE con recuperación ante desastres (DR) consta de tres servidores de SAP ASE:

  • Servidor principal: Este servidor controla todo el procesamiento de transacciones.
  • Nodo en espera: Este servidor actúa como un nodo en espera activo para el servidor principal y contiene copias de las bases de datos designadas del servidor principal.
  • Nodo de DR: Este servidor se encuentra geográficamente distante y crea copias de seguridad de las bases de datos designadas del servidor principal.

En el siguiente diagrama, se muestra el flujo de la recuperación ante desastres de SAP ASE:

Arquitectura para un sistema SAP ASE en Google Cloud con recuperación ante desastres

Alta disponibilidad y recuperación ante desastres de IBM Db2

Puedes lograr la alta disponibilidad y la recuperación ante desastres (HADR) para tu base de datos de IBM Db2 de la siguiente manera:

  • Debes implementar dos instancias independientes de tu base de datos de IBM Db2: una principal y la otra en espera. Debes mantenerlos sincronizados. Si falla la instancia principal, la instancia en espera se hará cargo de la carga de trabajo.

    La instancia principal controla las conexiones y transacciones de los clientes, y las registra en los registros. Estos registros se envían a través de TCP/IP al servidor en espera, que los usa para actualizar su base de datos y mantenerse sincronizado con la instancia principal.

  • Debido a que HADR no tiene la detección de fallas y la automatización, también debes implementar Pacemaker. Pacemaker supervisa ambas instancias y, si la instancia principal falla, Pacemaker activa la apropiación de HADR por parte de la instancia en espera, lo que garantiza que la dirección IP flotante se asigne a la instancia principal nueva.

    Pacemaker controla la administración del clúster, y se usa una VIP junto con el balanceador de cargas de aplicaciones interno para enrutar las solicitudes de la aplicación a la instancia principal.

Arquitectura para un sistema IBM Db2 en Google Cloud con alta disponibilidad y recuperación ante desastres

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 Business Suite en 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.

Si deseas obtener información sobre la licencia para SAP ASE en Google Cloud, consulta la sección “Licencias de SAP” en la Guía de planificación de SAP ASE.

Para implementar IBM Db2 para SAP en Google Cloud, debes usar una licencia adquirida por el usuario. Puedes obtener una licencia de SAP o de IBM. Para obtener más información sobre licencias y asistencia, consulta la nota de SAP 1168456 - DB6: Proceso de asistencia y fechas de fin de la asistencia para IBM Db2 LUW.

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 de SAP Business Suite. 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 Business Suite en SAP ASE o IBM Db2 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 tus datos de SAP ASE o IBM Db2 en Google Cloud, incluidas las siguientes:

Crea una copia de seguridad y recupera SAP ASE

Puedes usar las siguientes opciones para crear una copia de seguridad y recuperar una base de datos de IBM Db2 en Google Cloud:

  • Copia de seguridad y recuperación mediante discos: Puedes usar los mecanismos de copia de seguridad y recuperación flexibles de SAP ASE en combinación con los tipos de Hyperdisk y Persistent Disk que proporciona Compute Engine. Para almacenar copias de seguridad durante un período más largo, puedes usar Cloud Storage.

    En el siguiente diagrama, se muestra cómo se usan los discos y Cloud Storage para almacenar copias de seguridad de una base de datos de SAP ASE:

    Diagrama que muestra la copia de seguridad de los datos de SAP ASE en discos y Cloud Storage

  • Copia de seguridad y recuperación mediante instantáneas de disco: 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 /sybasebackup 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 ASE. 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:

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

Crea una copia de seguridad de una base de datos de IBM Db2

Puedes crear una copia de seguridad de una base de datos de IBM Db2 con cualquiera de las siguientes opciones:

  • Usa los modos en línea y sin conexión que proporciona IBM:
    • Modo en línea: En este modo, los usuarios pueden seguir trabajando mientras se crea la copia de seguridad de la base de datos.
    • Modo sin conexión: En este modo, la base de datos se cierra por completo, lo que la hace inaccesible para los usuarios mientras se crea la copia de seguridad.
  • Crea una copia de seguridad de tu base de datos de IBM Db2 y recupérala con instantáneas de disco: Otra opción que puedes agregar a tu estrategia de copia de seguridad es tomar instantáneas de discos completos con la función de instantánea de disco de Compute Engine. Por ejemplo, puedes tomar instantáneas programadas del disco que aloja tu directorio /db2backup 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 IBM Db2. 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:

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

El proceso para crear la copia de seguridad de la base de datos depende de la cantidad de particiones que tenga tu base de datos de IBM Db2:

  • Base de datos de partición única: En esta configuración, puedes crear una copia de seguridad completando los siguientes pasos:

    1. Como usuario db2DB_SID, accede al servidor de la base de datos.

    2. Ejecuta el siguiente comando:

      db2 backup db DB_SID

      Reemplaza DB_SID por el identificador del sistema de la base de datos (SID).

  • Base de datos de varias particiones: En esta configuración, puedes crear una copia de seguridad si completas los siguientes pasos:

    1. Como usuario db2DB_SID, accede al servidor de la base de datos.

    2. Ejecuta el siguiente comando:

      db2 "backup db DB_SID on ALL DBPARTITIONNUMS..."

      Reemplaza DB_SID por el identificador del sistema de la base de datos (SID).

    También puedes usar la herramienta DBA Cockpit proporcionada por IBM para crear una copia de seguridad de la base de datos. Para obtener más información sobre cómo crear una copia de seguridad de una base de datos de IBM Db2, consulta el documento de SAP Cómo crear una copia de seguridad de una base de datos.

Recupera una base de datos de IBM Db2

Puedes recuperar tu base de datos de IBM Db2 desde una copia de seguridad correcta. La recuperación de la base de datos depende de la accesibilidad al archivo de historial actualizado, ya que desde allí se accede a toda la información sobre las imágenes de copia de seguridad y los archivos de registro.

  • Para recuperar tu base de datos de IBM Db2 desde una copia de seguridad, completa los siguientes pasos:

    1. Como el usuario db2DB_SID o SAP_SIDadm, accede al servidor de la base de datos.

    2. Ejecuta el siguiente comando:

      db2 RECOVER DB DB_SID

      Reemplaza DB_SID por el identificador del sistema de la base de datos (SID).

  • Para recuperar tu base de datos de IBM Db2 en un momento específico, completa los siguientes pasos:

    1. Como el usuario db2DB_SID o SAP_SIDadm, accede al servidor de la base de datos.

    2. Ejecuta el siguiente comando:

      db2 RECOVER DB DB_SID to LOCAL_TIME_ON_DB_SERVER

      Reemplaza lo siguiente:

      • DB_SID: Es el identificador del sistema de base de datos (SID).
      • LOCAL_TIME_ON_DB_SERVER: La hora local en tu servidor de base de datos

    Para obtener más información sobre cómo recuperar una base de datos de IBM Db2, consulta el documento de SAP Recuperación de base de datos con el comando RECOVER.

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 Business Suite a través del 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. Para obtener más información, consulta la 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.

Para dimensionar una base de datos de SAP ASE, consulta el documento de SAP Tamaño de SAP ASE.

Para dimensionar una base de datos IBM Db2, consulta las comparativas de tamaño de SAP.

Para obtener información sobre los requisitos de hardware para ejecutar SAP ASE o IBM Db2 con diferentes versiones de sistema operativo y SAP NetWeaver, consulta el documento de SAP Guide Finder for SAP NetWeaver and ABAP Platform.

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 ASE o IBM Db2 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 de HADR de IBM Db2 o SAP ASE, 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.

Para obtener más información, consulte:

Implementación

En esta sección, se proporciona información relacionada con la implementación de SAP Business Suite en SAP ASE o IBM Db2 en Google Cloud.

Notas importantes de SAP previas a la implementación

Antes de comenzar a implementar un sistema de SAP Business Suite 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.

Para obtener más información sobre cómo instalar SAP ASE o IBM Db2, consulta los vínculos siguientes:

Automatización de la implementación

Automatiza la implementación de SAP ASE

Para automatizar la implementación de la infraestructura necesaria a fin de ejecutar SAP ASE y SAP NetWeaver en Linux en Google Cloud, puedes usar las configuraciones de Terraform que proporciona Google Cloud. Para obtener más información, consulta las guías de implementación para tu situación.

Para obtener información sobre la planificación de la implementación de SAP ASE, consulta los siguientes vínculos:

Automatiza la implementación de IBM Db2

Para automatizar la implementación de la infraestructura necesaria para ejecutar IBM Db2 y SAP NetWeaver en Linux en Google Cloud, puedes usar las opciones de configuración de Terraform que proporciona Google Cloud. Para obtener más información, consulta las guías de implementación para tu situación.

Para obtener información sobre la planificación de la implementación de SAP ASE, consulta los siguientes vínculos:

¿Qué sigue?