IBM Cloud Introducción a la VPC

Una VPC es una oferta de nube pública que las empresas utilizan para establecer su propio entorno informático de tipo nube privada en la infraestructura de nube pública compartida. Una VPC proporciona a una empresa la capacidad de definir y controlar una red virtual que está aislada de forma lógica de todos los demás arrendatarios de nube pública, de manera que se crea un lugar privado y seguro en la nube pública.

Imagine la infraestructura de un proveedor de nube como un edificio de pisos residenciales en los que viven distintas familias. Ser inquilino de una nube pública es como compartir un apartamento con unos cuantos compañeros de piso. Por otro lado, tener una VPC es como tener un piso propio, nadie más tiene la llave y nadie puede entrar en él sin el permiso del propietario. El aislamiento lógico de la VPC se implementa utilizando funciones de red virtual y prestaciones de seguridad que otorgan al cliente empresarial un control detallado sobre las direcciones IP o las aplicaciones que pueden acceder a recursos concretos. Es análogo a los controles de "sólo amigos" o "público/privado" de las cuentas de redes sociales que se utilizan para restringir quién puede o no puede ver tus publicaciones, que de otro modo serían públicas.

Con IBM Cloud VPC, puede utilizar la interfaz de usuario, la CLI y la API para aprovisionar manualmente instancias de servidor virtual para VPC con un alto rendimiento de red. La infraestructura VPC contiene varias ofertas de infraestructura como servicio ( IaaS ), entre ellas Virtual Servers for VPC. La siguiente información le ayudará a comprender un sencillo caso práctico que incluye la planificación, la creación y la configuración de recursos para la VPC, además de presentarle más descripciones generales y guías de aprendizaje de VPC. Para obtener más información sobre VPC, consulte la Guía de inicio de Virtual Private Cloud (VPC).

SAP en IBM Cloud

SAP NetWeaver es el núcleo de las pilas de tecnología de SAP y es la plataforma utilizada para las aplicaciones ABAP y Java. El sistema SAP puede instalarse y configurarse en IBM Cloud para varios tipos de sistemas y bases de datos.

Para obtener más información sobre las arquitecturas del sistema SAP en IBM Cloud VPC, consulte las arquitecturas de referencia de la infraestructura para SAP para cada tipo de base de datos compatible. Por ejemplo, SAP NetWeaver 7.x en UNIX con HANA en IBM Cloud VPC es la arquitectura de referencia dedicada para esta solución SAP.

Dónde ejecutar los scripts

Los scripts se ejecutan desde su Servidor de Despliegue porque el Servidor de Despliegue tiene Terraform y Ansible ya instalados. Los kits SAP deben descargarse en el almacenamiento temporal que se le haya asignado en el servidor de implantación. Ansible instalan los kits en función de la ubicación de los kits especificada en los archivos de configuración.

Requisitos previos

• Antes de desplegar cualquiera de las soluciones automatizadas de SAP en IBM Cloud VPC, debe crearse un Servidor de despliegue (Servidor Bastion) en la región elegida. El Servidor de Despliegue (Servidor Bastion) se utiliza para descargar y almacenar los soportes específicos de la solución SAP necesarios para el posterior despliegue de la automatización. El Servidor de Despliegue (Servidor Bastion) se utiliza tanto para escenarios de despliegue CLI, como para despliegues Schematics UI. El Servidor de Despliegue debe existir en la misma VPC que el sistema SAP HANA primario. Para obtener más información sobre cómo crear el servidor de implementación (servidor bastión) y su VPC correspondiente, consulte Automatizar el servidor bastión SAP: repositorio de almacenamiento de medios SAP.

• Un par de claves SSH que se utilizarán para conectarse a las VSI. La clave pública debe cargarse en IBM Cloud y añadirse manualmente en SAP HANA sistema primario VSI en /root/.ssh/authorized_keys.

• Un sistema primario SAP HANA sin HA desplegado, en una VSI de una región diferente a la elegida para el sistema secundario SAP HANA (basado en uno de los siguientes SO: SUSE Linux Enterprise Server 15 SP 4 para SAP, SUSE Linux Enterprise Server 15 SP 3 para SAP, Red Hat Enterprise Linux 8.6 para SAP o Red Hat Enterprise Linux 8.4 para SAP ) en una VPC IBM Cloud Gen2, en un único host (con o sin HA).

• Se debe realizar una copia de seguridad completa de la base de datos en el sistema primario para la base de datos del sistema y todas las bases de datos de los inquilinos.

Las imágenes del sistema operativo IBM Cloud utilizadas para validar esta automatización se mencionan en el archivo Léame.

Para ahorrar costes, el servidor de despliegue (Bastion Server), con su almacenamiento dedicado a los medios SAP, puede retirarse una vez que las soluciones SAP se hayan implantado con éxito en la nube IBM Cloud VPC. O bien, puede conservar el Servidor de Despliegue (Servidor Bastión) y utilizarlo como host de salto para esa región específica y futuros despliegues.

Esta automatización se ofrece sin coste alguno; sin embargo, la infraestructura suministrada tiene un coste.

SAP Guía de valores del proyecto - IBM Cloud VPC y automatización de copias de seguridad de HANA db en Cloud Object Storage

SAP los proyectos varían mucho en alcance y presupuesto, pero ninguno se considera trivial. Tanto si se trata de entregar un nuevo sistema SAP como de introducir cambios en uno ya existente, la exigencia de no cometer errores en la ejecución y de reducir el tiempo del proyecto para obtener beneficios está siempre presente.

En muchos escenarios de proyectos SAP, el despliegue de un sistema SAP suele ser una tarea clave y repetida. Esta guía de valor del proyecto cubre el despliegue automatizado de IBM Cloud VPC y HANA db cross-regions DR. Encontrará más información sobre SAP NetWeaver de la base de datos HANA y el servidor de aplicaciones adicional(AAS)a la instancia SAP y la instancia HANA en sus respectivas secciones.

Dado que este sistema es una parte clave de su proyecto SAP, desea habilitar una arquitectura de recuperación ante desastres interregional para su base de datos productiva existente SAP HANA.

SAP HANA módulo de automatización de la recuperación en caso de catástrofe de db cross-regions

SAP HANA el módulo de automatización de recuperación ante desastres (DR) de db cross-regions se desarrollará como módulo de automatización independiente que se integrará en cualquier solución SAP desplegada que se ejecute en la base de datos HANA.

SAP HANA Cloud ofrece opciones para replicar su base de datos SAP HANA Cloud de forma sincrónica dentro de la misma zona de disponibilidad o de forma asincrónica a otras zonas de disponibilidad en otra región desde octubre de 2021.

Con estas opciones, puede configurar una arquitectura de alta disponibilidad (HA) y/o una arquitectura de recuperación ante desastres (DR) ejecutando el módulo de automatización entre regiones de HANA DR sobre un producto SAP existente que se ejecute en HANA db.

En los diagramas siguientes, la base de datos SAP HANA se representa como un pasivo secundario de HANA. Se ilustran las arquitecturas de replicación síncrona y asíncrona para escenarios de HA y DR.

Diferentes valores de RPO/RTO pueden asociarse a diferentes tipos de fallos. Se espera que los sistemas críticos para las empresas funcionen con un RPO de pérdida de datos cero en caso de fallos locales, y a menudo incluso en caso de catástrofe. Pero los retos de la recuperación ante catástrofes son distintos de los fallos recuperables localmente. Para lograr un RPO cero y un RTO bajo, los datos deben replicarse de forma sincrónica a través de distancias más largas, lo que repercute en el rendimiento habitual del sistema y puede requerir soluciones de reserva y conmutación por error más caras. Todo ello conduce a decisiones de compromiso en torno a los atributos de funcionalidad, coste y complejidad de la recuperación de fallos.

Así funciona la replicación del sistema. Cuando el sistema secundario se ejecuta en modo de replicación en vivo, cada componente de servicio establece una conexión con su homólogo del sistema primario y solicita una instantánea de los datos. A partir de ahí, se replican todos los cambios registrados en los sistemas primarios.

¿Qué ocurre si falla la replicación?

Si la replicación falla debido a un fallo en la red, entonces se puede configurar para confirmar la transacción, o para fallar la confirmación en el sistema primario, hasta que se restablezca la replicación.

SAP HANA admite contenedores de bases de datos multiusuario. La replicación del sistema sólo puede establecerse para el sistema en su conjunto, no por inquilino individual.

Siempre que los registros se persisten en el sistema primario (es decir, se escriben en los volúmenes de registro de cada servicio), también se envían al sistema secundario. Una transacción en el sistema primario no se confirma hasta que los registros de rehacer se replican, según lo determinado por una opción de replicación de registro:

• Sincrónico (utilizado para HA): El sistema primario espera para comprometer la transacción, hasta que recibe una respuesta de que el registro se persiste en el sistema secundario. Este modo garantiza la coherencia inmediata entre ambos sistemas, a costa de retrasar la transacción por el tiempo de transmisión de datos y persistencia en el sistema secundario.

• Sincrónico en memoria: El sistema primario consigna la transacción después de recibir la respuesta de que el sistema secundario ha recibido el registro, pero antes de persistirlo. El retraso de la transacción en el sistema primario es menor, porque sólo incluye el tiempo de transmisión de los datos.

• Asíncrono (utilizado para DR): El sistema primario consigna la transacción después de enviar el registro sin esperar respuesta. De este modo se elimina la latencia de sincronización, con el riesgo de que se produzcan pequeñas pérdidas teóricas de datos en caso de fallo. Este modo es más útil cuando el sitio secundario está a cientos de kilómetros del primario, o cuando reducir la latencia es fundamental.

HSR sincroniza los datos entre un sistema HANA primario y otro secundario, garantizando que sus datos críticos sigan siendo accesibles incluso durante eventos inesperados.

Replicación del sistema Actualización continua (sincrónica y asincrónica) del sistema secundario por parte del sistema primario, incluida la carga de tablas en memoria y la reproducción continua de registros en el sistema secundario (si está configurado).

SAP HANA la replicación del sistema ofrece la posibilidad de copiar y sincronizar continuamente una base de datos SAP HANA a una ubicación secundaria en el mismo centro de datos o en otro. Por lo general, la replicación de sistemas se utiliza para apoyar la alta disponibilidad y la recuperación de desastres.

Distancia entre los centros de datos:

• La replicación del sistema ofrece modos de replicación síncrona y asíncrona para adaptarse a la latencia de la red.
• Si la distancia entre sus sitios es inferior a 100 km, puede utilizar el modo de replicación síncrona SYNC o SYNCMEM.
• Si la distancia entre sus sitios es superior a 100 km, puede utilizar el modo de replicación asíncrona ASYNC.

Transit Gateway

Con IBM Cloud Transit Gateway puede crear una o varias pasarelas de tránsito para conectar VPC entre sí. También puede conectar la infraestructura clásica de IBM Cloud a una pasarela de tránsito para proporcionar una comunicación fluida con los recursos de la infraestructura clásica. Cualquier nueva red que conecte a una pasarela de tránsito se pondrá automáticamente a disposición de todas las demás redes conectadas a ella, de modo que podrá ampliar su red a medida que crezca.

Las pasarelas de tránsito proporcionan flexibilidad ya que le permiten añadir redes a pasarelas locales. Las redes se pueden conectar a varias pasarelas locales y a una sola pasarela global, lo que le permite mantener el tráfico local en una pasarela local.

IBM Cloud Transit Gateway admite el enrutamiento local y global entre las VPC y la infraestructura clásica de IBM Cloud. Todas las opciones de enrutamiento permanecen dentro de la infraestructura privada de IBM Cloud sin operar en la Internet pública, y están optimizadas para el rendimiento. IBM Cloud Transit Gateway permite a los clientes una mayor flexibilidad, redundancia y velocidad en el escalado de sus cargas de trabajo, y en la conexión de redes aisladas que se ejecutan en IBM Cloud.

• Crear una pasarela de tránsito.

• El sitio Transit Gateway ya está creado y disponible.

• La pasarela de tránsito muestra dos conexiones que tienen la instancia VSIs HANA db en 2 regiones separadas.

Automatización para la instalación de SAP

La automatización basada en scripts Terraform y playbooks Ansible se utiliza para la habilitación de protección de recuperación ante desastres entre regiones para un sistema SAP HANA noHA en VSI. Ansible es un motor de automatización de TI de código abierto que puede utilizarse para configurar sistemas, desplegar software y orquestar flujos de trabajo para apoyar el despliegue de aplicaciones y las actualizaciones del sistema. Para obtener más información sobre Ansible, consulte la documentación de Ansible.

Los playbooks de Ansible son llamados directamente por los scripts de Terraform. Primero se crean los elementos de infraestructura de la VPC mediante los scripts de Terraform y, a continuación, se utilizan los playbooks de Ansible para la configuración de LVM, la configuración del SO y para la instalación del sistema secundario de SAP HANA junto con la configuración y habilitación de DR.