Puedes usar Google Cloud a fin de alojar soluciones de recuperación ante desastres para tus sistemas SAP que se ejecutan en Google Cloud, de forma local o en otro proveedor de servicios en la nube.
Definición de recuperación ante desastres
La recuperación ante desastres (DR) y la alta disponibilidad (HA) son dos elementos distintos en el concepto más amplio de continuidad empresarial. En esta guía, nos enfocamos en la recuperación ante desastres.
Una solución de DR está diseñada para restablecer el procesamiento de aplicaciones después de un desastre natural o provocado por el hombre, o una falla en la infraestructura que causa una interrupción a gran escala. Estas interrupciones inhabilitan el sistema de procesamiento de la aplicación principal y cualquier sistema en espera que proteja contra fallas de la infraestructura local o del sistema a pequeña escala.
Otras características de una solución de DR que la distinguen de una solución de alta disponibilidad incluyen las siguientes opciones:
- Por lo general, el sistema de recuperación en una solución de DR no es un sistema de espera activa.
- Un procedimiento de recuperación ante desastres suele requerir la intervención manual a fin de recuperar o restablecer el procesamiento de la aplicación a partir de copias de seguridad o de la replicación de los datos, de los sistemas y de la infraestructura.
- La solución incluye un sitio de recuperación que se encuentra en una ubicación geográfica diferente a la del sistema principal.
- Por lo general, el objetivo de tiempo de recuperación (RTO) para una solución de recuperación ante desastres se mide en horas, incluso en días.
En la siguiente arquitectura de ejemplo, se muestra un sistema SAP que incluye una solución de HA y una de DR. El sitio de DR, en el que se restablecerá el sistema después de un desastre, se encuentra a la derecha, en la Región 2. El sistema principal se encuentra a la izquierda, en la Región 1, y está configurado para alta disponibilidad con clústeres de conmutación por error que abarcan dos zonas. La función de copia de seguridad de la solución de DR se representa con líneas punteadas que abarcan ambas regiones. Para el almacenamiento, los sistemas usan un bucket de Cloud Storage multirregional, que se muestra en la parte inferior del diagrama.
En el ejemplo también se muestra una base de datos. Aunque la recuperación de la aplicación depende de la recuperación de los datos, los procedimientos de DR de los sistemas de bases de datos no se analizan en esta guía. Consulta la documentación de bases de datos y las notas de SAP aplicables. En esta guía en particular, nos enfocamos en el sistema SAP NetWeaver (SAP ASCS/ERS) y en los servidores de aplicaciones (SAP AAS).
Para obtener información sobre la implementación de sistemas SAP de alta disponibilidad en Google Cloud, consulta la Guía de planificación de alta disponibilidad para SAP NetWeaver en Google Cloud.
Para obtener información sobre la alta disponibilidad y la recuperación ante desastres de SAP HANA en Google Cloud, consulta la Guía de planificación de alta disponibilidad de SAP HANA y la Guía de planificación de recuperación ante desastres de SAP HANA respectivamente.
A fin de obtener información general sobre la DR en Google Cloud, consulta la Guía de planificación para la recuperación ante desastres.
Enfoques de diseño de DR para sistemas SAP que no se ejecutan en Google Cloud
Si tu sistema SAP principal no se ejecuta en Google Cloud, puedes adoptar un enfoque lift-and-shift para la solución de DR, en el que la arquitectura y el software del sistema de DR en Google Cloud son los mismos, al igual que en el sistema principal. O bien, puedes adoptar un enfoque nativo de la nube, en el que, como parte del diseño de tu solución de DR, optimizas el sistema que se recuperó para la nube, compatible con productos o servicios de Google Cloud o Google Cloud Partner.
Si usas un enfoque lift-and-shift, debes verificar que la arquitectura del sistema principal sea completamente compatible con Google Cloud. Para cualquiera de estos enfoques, debes asegurarte de que todo el software que se use tenga la licencia adecuada para su uso en Google Cloud.
Para obtener más información sobre las licencias, consulta las Condiciones del Servicio de Google Cloud Platform.
Elementos de diseño de una solución de DR para SAP NetWeaver en Google Cloud
Estos pueden incluir lo siguiente:
- Ubicación del sitio de DR
- Herramientas de redes
- Seguridad
- Consideraciones sobre las máquinas virtuales (VM)
- Opciones de copia de seguridad
- Almacenamiento
A fin de implementar cada uno de estos elementos de diseño, tienes una serie de opciones para cumplir los objetivos de recuperación y de costo.
Ubicación del sitio de DR
Cuando elijas una región de Google Cloud para tu sitio de DR, debes considerar lo siguiente:
- El área de impacto posible de cualquier desastre que pueda suceder en el sitio principal
- La ubicación de los usuarios del sistema SAP NetWeaver
- Si los recursos y las funciones de Google Cloud que usa el sistema SAP están disponibles en la región y la zona que elijas
Elige una región de Google Cloud para tu sitio de DR que esté alejada lo suficiente del sitio principal a fin de que el sitio de DR no se vea afectado por cualquier desastre que pueda ocurrir en el sitio principal. Por lo general, una distancia de 160 kilómetros o más se considera suficiente, sin embargo, las normas o los lineamientos de la organización pueden requerir una distancia mínima diferente.
Si el sistema SAP principal se ejecuta en Google Cloud, ubica el sitio de DR en cualquier región de Google Cloud que esté cerca de tus usuarios, excepto la región en la que se ejecuta el sistema principal. Las regiones de Google Cloud se encuentran bastante alejadas entre sí para que no haya dos regiones de Google Cloud que puedan verse afectadas por el mismo desastre.
Si el sistema SAP principal se ejecuta fuera de Google Cloud, ubica el sitio de DR en una región lo más cerca posible a tus usuarios sin estar en la posible zona de impacto de cualquier desastre que pueda ocurrir en el sitio principal.
En la región de DR, ubica el sistema de DR en una zona que admita los tipos de instancias de VM y otra infraestructura que requieran los sistemas SAP y de base de datos.
Después de seleccionar una región destinada el sitio de DR, es posible que debas aumentar las cuotas de recursos de la región a fin de proporcionar recursos suficientes para el sistema de DR antes de un evento.
Para obtener información sobre las ubicaciones de todas las regiones de Google Cloud, consulta Regiones y zonas.
Para ver las funciones que están disponibles en cada región, consulta Regiones y zonas disponibles.
Para consultar qué recursos de Google Cloud son globales, regionales y zonales, visita Recursos globales, regionales y zonales.
Herramientas de redes
En Google Cloud, la nube privada virtual (VPC) proporciona funcionalidad de herramientas de redes que se pueden extender por todo el mundo.
Debes crear una red de VPC para el sitio de DR si aún no existe. También debes crear una subred y un rango de IP para el sitio de DR.
Si el sistema principal se encuentra en Google Cloud, es más fácil configurar la red si el sitio principal y el de DR están en la misma red de VPC. Sin embargo, de ser necesario, es posible colocar el sitio principal y el de DR en diferentes redes de VPC o incluso en diferentes proyectos.
Cuando diseñes la solución de DR, debes considerar las siguientes rutas de comunicación:
- La conexión entre el sitio principal y el sitio de recuperación en Google Cloud
- La comunicación interna entre las aplicaciones, las bases de datos y los servidores que conforman el sistema SAP
- La conexión entre los usuarios y el sistema SAP
Para las conexiones desde sitios externos a Google Cloud, este proporciona una variedad de productos de herramientas de redes que admiten cada uno de estos puntos de conexión.
Conecta el sitio principal al sitio de DR
La conexión entre el sitio principal y el de DR es necesaria para almacenar copias de seguridad o proporcionar una ruta de replicación entre los dos sistemas a fin de que los recursos de recuperación estén disponibles de inmediato en caso de que ocurra un desastre y si deseas probar los procedimientos ante desastres.
Si el sistema principal se ejecuta en Google Cloud, el proceso para hacer que tus copias de seguridad estén disponibles en el sitio de DR es casi automático. Las instantáneas de Compute Engine se pueden designar como multirregionales. Se pueden almacenar otras copias de seguridad directamente desde el sistema principal en depósitos multirregionales de Cloud Storage para obtener disponibilidad instantánea en el sitio de DR.
Si el sistema principal no se ejecuta en Google Cloud, puedes conectar el sitio principal al sitio de DR en Google Cloud mediante Cloud Interconnect o Cloud VPN.
Si deseas ver un ejemplo de una topología de Cloud Interconnect con alta disponibilidad que, con algunos cambios, podría adaptarse a una situación de DR, consulta Establece una disponibilidad del 99.99% para la interconexión dedicada.
Para ver algunos ejemplos de topologías de puerta de enlace de VPN multirregional con alta disponibilidad que también se pueden adaptar a una situación de DR, consulta Topologías de Cloud VPN.
Una consideración clave cuando configuras tu conexión a Google Cloud desde un sitio fuera de la plataforma es el ancho de banda. La conexión debe admitir la transferencia normal de datos y las copias de seguridad en Google Cloud de forma adecuada.
Para obtener más información sobre las opciones de conexión a Google Cloud desde sitios fuera de la plataforma, consulta Productos de conectividad híbrida.
Conectividad entre las aplicaciones, las bases de datos y los servidores de SAP
Si el sistema principal se ejecuta en Google Cloud, mantener la conectividad entre las aplicaciones, las bases de datos y los servidores de SAP en el sitio de DR es una cuestión muy sencilla, que consta de diseñar los nombres de host, las subredes, los firewalls y más en el sitio principal.
Si el sistema principal no se ejecuta en Google Cloud, es posible que se requiera realizar un mayor esfuerzo en la fase de diseño para traducir la arquitectura de herramientas redes del sitio principal al de DR en Google Cloud.
Es fundamental probar los procedimientos de DR a fin de identificar y abordar cualquier problema de conectividad antes de que tu empresa dependa del sistema recuperado.
Conecta los usuarios al sitio de DR
En una recuperación, después de restablecer el sistema SAP en el sitio de DR, el tráfico de los usuarios debe redirigirse al sistema recuperado. Por lo general, se hace mediante la actualización de los alias de red en las entradas de DNS hacia las nuevas direcciones IP, que son regionales.
Si en la arquitectura de herramientas de redes se usan rutas de VPC, deberás actualizar las rutas durante la recuperación.
En Google Cloud, puedes usar Cloud DNS o usar otra solución de DNS.
Recursos regionales de redes
Si tu sistema principal se ejecuta en Google Cloud y usas los recursos de herramientas de redes regionales, como Cloud NAT o Cloud Load Balancing regional, necesitas una instancia del recurso en cada región.
Para obtener más información, sigue estas sugerencias:
Control de acceso a la red
Asegúrate de que estén abiertos los mismos puertos en el sitio de DR que en el principal.
Puedes definir reglas de firewall en la red de VPC para controlar el tráfico desde y hacia tus VM.
Si tienes un servicio de Active Directory en Windows Server, debes configurarlo antes de la recuperación y mantenerlo sincronizado con la instancia de Active Directory en el sitio principal.
Seguridad
Debes implementar los mismos controles y permisos de seguridad que tienes en el sitio principal en el sitio de DR. Las mismas regulaciones de cumplimiento también aplican a tu entorno recuperado.
Cualquier usuario o función que requiera acceso al sitio principal también lo necesitará en el sitio de DR.
Si deseas obtener información general sobre el diseño de seguridad de una solución de DR en Google Cloud, consulta Implementa controles de seguridad y cumplimiento.
Consideraciones de VM
Puedes acelerar la implementación de tus instancias de máquina virtual (VM) de Compute Engine y evitar errores de configuración en tu sitio de DR si usas las configuraciones de Terrafom proporcionadas por los productos y las funciones de Google Cloud, como Cloud Deployment Manager, imágenes personalizadas y plantillas de instancias.
Configura e implementa tus máquinas virtuales
Google Cloud proporciona archivos de configuración de Terraform y plantillas de Deployment Manager para SAP en Google Cloud que puedes usar a fin de predefinir e implementar tu sistema SAP en el sitio de DR. El uso de archivos de Terraform o Deployment Manager acelera la implementación, reduce los errores de configuración y garantiza que los sistemas SAP cumplan los requisitos de compatibilidad de SAP.
Otra opción para configurar VM con anticipación son las plantillas de instancias de Compute Engine. Usar las plantillas de instancias es una forma de acelerar la implementación y reducir la configuración manual de las VM durante la recuperación. Sin embargo, debido a que requieren reconfiguración para el sitio de DR, recuperar las VM desde un disco de arranque de recuperación podría ser más fácil, como se describe en la siguiente sección.
Para obtener más información sobre las plantillas de instancias, consulta Plantillas de instancias.
También puedes usar herramientas de organización de implementaciones, como Terraform, para administrar las implementaciones de infraestructura en Google Cloud.
Según tu RTO, puedes realizar una implementación previa de las instancias de Compute Engine o, ya que implementar una VM solo lleva unos minutos, puedes hacerlo en el momento de la recuperación.
Si realizas una implementación previa de tus VM, puedes detenerlas a fin de ahorrar costos o puedes usarlas con otros fines no esenciales hasta que sean necesarias para la recuperación.
También puedes minimizar el costo mediante la consolidación de un sistema distribuido en menos VM en el sitio de recuperación. Por ejemplo, si los servidores de aplicaciones en el sitio principal se encuentran en hosts dedicados, en el sitio de DR podrías ubicar los servidores de aplicaciones en el mismo host que los Servicios centrales de SAP. Sin embargo, debes considerar los ahorros de costos en comparación con la complejidad de tener diferentes configuraciones en cada sitio.
Disco de arranque de recuperación
Puedes crear una imagen personalizada desde el disco de arranque del host en tu sistema principal y, luego, usar la imagen personalizada para crear la instancia de recuperación en el sitio de DR.
Si el sistema se ejecuta en Google Cloud, crea una imagen personalizada si creaste y modificaste un disco de arranque persistente de Compute Engine para el sistema principal. Si usas una imagen pública de Google Cloud sin modificar, también puedes usar la imagen pública de Google Cloud en el sitio de recuperación. Para obtener más información, consulta Crea, borra y da de baja imágenes personalizadas.
Si el sistema no se ejecuta en Google Cloud, puedes importar una imagen de disco de arranque a Google Cloud desde tu entorno local o importar discos virtuales desde las VM que se ejecuten en tu estación de trabajo local o en otra plataforma en la nube.
Opciones de copia de seguridad
Google Cloud ofrece una variedad de opciones de copias de seguridad que puedes elegir cuando diseñas una solución de DR:
- Imágenes personalizadas de Compute Engine
- Instantáneas de discos persistentes de Compute Engine
- Replicación
Imágenes personalizadas de Compute Engine
A fin de crear una copia de seguridad del disco de arranque del sistema principal para su uso en la recuperación, puedes almacenarlo en Google Cloud como una imagen personalizada de Compute Engine. Para obtener más información, consulta Disco de arranque de recuperación.
Instantáneas de discos persistentes de Compute Engine
Para crear una copia de seguridad de SAP o de otros sistemas de archivos que se encuentran en un disco persistente de Compute Engine, puedes usar instantáneas de discos persistentes.
También puedes definir una programación de instantáneas para tomar instantáneas de forma automática a intervalos regulares. Consulta Crea instantáneas programadas para discos persistentes.
Las instantáneas solo proporcionan coherencia a nivel de bloque. A fin de garantizar la coherencia a nivel de los archivos, es posible que debas implementar mecanismos para suspender la actividad de escritura en los sistemas de archivos de destino durante estas instantáneas.
Replicación
Según tu solución de almacenamiento compartido y los objetivos de puntos de recuperación, puedes replicar los sistemas de archivos. La replicación se puede usar para bases de datos, almacenamiento a nivel de bloque o archivos.
Diseñar una solución de DR en la que se use la replicación es la mejor opción para las aplicaciones empresariales esenciales que tienen una tolerancia muy baja a la pérdida de datos.
Si el sistema principal se ejecuta en Google Cloud, los depósitos y las instantáneas multirregionales se replican entre las regiones seleccionadas.
Para la replicación de almacenamiento a nivel de bloque, puedes usar la replicación asíncrona de PD. La replicación asíncrona de PD proporciona un objetivo de punto de recuperación (RPO) bajo y un objetivo de tiempo de recuperación (RTO) bajo para la recuperación ante desastres activa-pasiva entre regiones.
También puedes usar la replicación que proporcionan las soluciones de almacenamiento de terceros.
Almacenamiento
Cuando diseñas una solución de DR en Google Cloud, es probable que uses varios tipos de almacenamiento, según la ubicación en la que se ejecute el sistema principal y qué almacenes.
Depósitos de Cloud Storage para archivos de copia de seguridad
Para copias de seguridad que no sean de instantáneas de discos, como los archivos que subes desde un sistema SAP que no se ejecuta en Google Cloud, crea un bucket en Cloud Storage al que puedas acceder desde el sitio principal y el de DR. Cuando creas un bucket, debes elegir una clase de almacenamiento predeterminada y una ubicación.
Selecciona una clase de almacenamiento predeterminada según el Acuerdo de Nivel de Servicio (ANS) que necesites, el uso que esperas del almacenamiento y las restricciones de costos. Para la DR, la clase Coldline Storage suele ser una buena opción.
Para la ubicación del bucket, elige una ubicación que incluya la región del sitio de DR y, si el sistema principal se ejecuta en Google Cloud, la región de este.
Si el sistema principal se encuentra en Google Cloud, elige una ubicación multirregional que incluya las regiones del sitio principal y el de DR para que puedas acceder al bucket desde ambos.
Si el sistema principal no se encuentra en Google Cloud, puedes seleccionar una ubicación de una sola región que incluya el sitio de DR para ahorrar costos.
Si el sistema principal se encuentra en Google Cloud y usas una solución de terceros para el almacenamiento compartido, es posible que la solución determine las opciones de almacenamiento. Consulta la documentación de la solución o comunícate con un representante del servicio de atención al cliente de Cloud.
Para obtener información sobre los precios, consulta Precios de Cloud Storage.
Almacenamiento para instantáneas de discos persistentes de Compute Engine
Cuando creas una instantánea, puedes especificar una ubicación de almacenamiento. La ubicación de una instantánea afecta su disponibilidad y puede generar costos de herramientas de redes cuando creas la instantánea o la restableces en un disco nuevo.
Las instantáneas se pueden almacenar en una ubicación multirregional de Cloud Storage, como asia, o en una ubicación regional de Cloud Storage , como asia-south1.
Una ubicación de almacenamiento multirregional proporciona mayor disponibilidad y puede reducir los costos de red cuando se crea o restablece una instantánea. Una ubicación de almacenamiento regional te brinda más control sobre la ubicación física de los datos.
Sin importar las opciones de ubicación que elijas, las instantáneas deben almacenarse en una ubicación accesible desde el sitio de DR.
Para obtener más información sobre las ubicaciones de las instantáneas, consulta Selecciona la ubicación de almacenamiento de una instantánea.
Para obtener información sobre el almacenamiento de instantáneas, consulta Precios de discos persistentes.
Almacenamiento de imágenes personalizadas
Después de agregar archivos de imagen personalizados a tu lista de imágenes personalizadas, Compute Engine administra el almacenamiento de las imágenes. Las imágenes que figuran en una lista de imágenes personalizadas son recursos globales, por lo que están disponibles en cualquier región.
Para obtener información sobre los precios de almacenamiento de imágenes, consulta Almacenamiento de imágenes.
Prueba tu plan de DR
Cuando completes tu plan de DR, pruébalo con frecuencia, ten en cuenta los problemas que surjan y ajústalo según corresponda.
Asegúrate de probar todos los aspectos de tu plan de DR, incluidos los siguientes:
- Copias de seguridad y programas de copias de seguridad
- Transferencia de datos de sitios fuera de la plataforma
- Recuperación de copias de seguridad almacenadas
- Controles de seguridad y acceso al sistema
- Enrutamiento de herramientas de redes
Cuando pruebes tus sistemas de DR, tus sistemas principales continuarán ejecutándose. Para evitar conflictos o situaciones de cerebro dividido, debes aislar el sistema de prueba del sistema principal y sus usuarios.
Para obtener información general sobre las pruebas de DR en Google Cloud, consulta la Guía de planificación de recuperación ante desastres.
Diseña tu solución de DR para cumplir con los RPO y RTO
Algunos productos, funciones y servicios de Google Cloud son esenciales para diseñar una solución de DR que cumpla con tus RPO y RTO.
Diseña para RPO
Cuando se diseña una solución de DR en Google Cloud para cumplir con un RPO en particular, existen dos variables que controlan el momento determinado en el que puedes recuperarte:
- Frecuencia de la copia de seguridad
- Retención de la copia de seguridad
Frecuencia de la copia de seguridad
La frecuencia de la copia de seguridad determina el tiempo máximo que puede transcurrir entre la última copia de seguridad y un desastre. Si creas tus copias de seguridad de DR cada 24 horas, podrías perder casi 24 horas de actualizaciones de datos si ocurre un desastre 23 horas y 59 minutos después de que se realizó la última copia de seguridad.
La replicación puede reducir el tiempo máximo transcurrido desde la última copia de seguridad a casi cero. Sin embargo, la replicación es costosa, por lo que puedes usarla solo para bases de datos y archivos de aplicaciones empresariales esenciales.
En una solución de DR, por lo general, las instantáneas o copias de un momento determinado se usan a fin de realizar una copia de seguridad de los sistemas de archivos de la aplicación SAP necesarios para la recuperación.
En Google Cloud, puedes automatizar las instantáneas de discos persistentes de Compute Engine mediante la creación de un programa de instantáneas por hora, diario o semanal. Sin embargo, debido a que las instantáneas de Compute Engine controlan la coherencia solo a nivel de bloque, considera suspender la actividad de escritura en los sistemas de archivos de destino durante creación de instantáneas para garantizar la coherencia a nivel de archivo.
El costo principal que se debe considerar cuando se elige una frecuencia de copia de seguridad es el costo de la transferencia de datos. El costo de almacenamiento también es un aspecto a considerar, pero tu política de retención de copias de seguridad podría tener un mayor impacto en los costos de almacenamiento que tu frecuencia de copia de seguridad.
Para obtener más información sobre las programaciones de instantáneas, consulta Crea instantáneas programadas para discos persistentes.
Retención de la copia de seguridad
La retención de las copias de seguridad determina la distancia en el tiempo en la que puedes retroceder hacia tu punto de recuperación. Retener las copias de seguridad te ayuda a protegerte contra errores lógicos, ya que permite recuperarte hasta un momento determinado antes de que exista el error lógico.
Puedes establecer políticas de retención para las instantáneas de Compute Engine y los depósitos de Cloud Storage que borran de forma automática tus archivos de copia de seguridad después de un período específico.
El costo principal que se debe considerar cuando eliges una política de retención es el costo de almacenamiento. Las instantáneas de Compute Engine reducen la cantidad de almacenamiento que se requiere para varias instantáneas mediante el almacenamiento de solo cambios incrementales a nivel de bloque después de que se almacena la primera instantánea completa.
Para obtener más información sobre la definición de políticas de retención de instantáneas, consulta Política de retención de instantáneas.
Para obtener información sobre cómo establecer políticas de retención en los depósitos de Cloud Storage, consulta Políticas de retención con bloqueo de depósitos.
Diseña para RTO
Cuando diseñas tu solución de DR de Google Cloud para cumplir con un RTO en particular, la preparación de la infraestructura, del software, de los sistemas de archivos y de los datos del sitio de DR es la variable de control principal.
Por ejemplo, para lograr un RTO muy bajo, puedes mantener un sistema de espera activa en el sitio de DR, con infraestructura implementada con anterioridad, sistemas SAP activos y datos replicados. Sin embargo, el RTO bajo tiene un costo más alto.
Puedes balancear los costos y los tiempos de recuperación si configuras una infraestructura de bajo costo o sin costo por adelantado y aplazas algunos pasos de configuración hasta el momento de la recuperación.
Por ejemplo, puedes configurar y, luego, implementar una VM por adelantado, pero luego detenerla. Los recursos conectados a la VM, como cualquier IP estática externa o discos persistentes, pueden generar cargos, pero la VM detenida no.
Debido a que puedes configurar e implementar una VM de Compute Engine en Google Cloud con cierta rapidez, es posible que puedas hacerlo en el momento de la recuperación y aun así cumplas con tu RTO, en especial si usas Terraform o Deployment Manager a fin de implementar el sistema de DR o crear la VM desde una plantilla y una imagen personalizada que crees por adelantado.
Consideraciones de cuotas y recursos para soluciones de DR de valores altos de RTO
Si no realizas una implementación previa de la infraestructura y de los sistemas, verifica tus cuotas de recursos en la región del sitio de DR de forma periódica para asegurarte de tener suficiente cuota a fin de implementar el sistema de DR.
La implementación previa de la infraestructura y los sistemas de DR que permita tu presupuesto puede ayudarte a garantizar que el sistema de DR se adapte a tus cuotas y que los recursos de Google Cloud que el sistema requiere estén disponibles cuando los necesites.
Ejemplo de arquitecturas para diferentes objetivos
En los siguientes diagramas de arquitectura, se muestran ejemplos de diseños de DR para diferentes RTO.
En cada uno de los diagramas, se muestran opciones de copia de seguridad multirregionales a la izquierda y la correspondiente configuración de SAP simplificada en el sitio de DR a la derecha.
En cada ejemplo se muestra una combinación posible de elementos de diseño de DR. Para adaptar tu diseño de DR a tus objetivos y circunstancias, puedes combinar elementos de todos los ejemplos.
Arquitectura de DR de ejemplo con RTO bajo
En el siguiente diagrama de arquitectura, se muestra un ejemplo de diseño de DR con RTO bajo.
En este diseño, se mantiene un sistema SAP casi funcional en el sitio de DR. Las VM están implementadas y activas. Los servidores de aplicaciones SAP y el servidor de la base de datos están activos, pero el servicio de la aplicación se detuvo.
En esta situación, es probable que uses las opciones de copia de seguridad que incluyen imágenes de SO almacenadas en instantáneas de discos persistentes almacenados en Compute Engine y replicación de datos entre el sitio principal y en el de DR. Para la replicación de datos, puedes usar la replicación asíncrona de PD.
Debido a que se usa la replicación de datos, el riesgo de pérdida de datos se limita a la última sincronización de la base de datos.
Para extender tu RPO en el tiempo, puedes agregar copias de seguridad de datos a Cloud Storage, que no se muestran en el diagrama. Para las instantáneas de discos persistentes, puedes usar instantáneas programadas y adaptar la política de retención a tu RPO.
Las acciones que debes realizar para recuperar un sistema de RTO bajo incluyen lo siguiente:
- Realizar una sincronización final de los archivos o recuperarlos de una instantánea de disco persistente, si es necesario
- Cambiar la base de datos principal al sitio de DR
- Iniciar la aplicación en el sitio de DR
De las tres arquitecturas de ejemplo que se muestran, el ejemplo de RTO bajo es el más costoso.
Ejemplo de un valor de RTO medio de arquitectura de DR
En la siguiente arquitectura de DR de ejemplo, se muestra un RTO más alto que el ejemplo anterior, pero un costo menor.
En este diseño, el servidor de base de datos está activo para admitir la replicación desde el sitio principal. Las VM de los servidores de aplicaciones no están activas.
En esta situación, es probable que uses las opciones de copia de seguridad que incluyen imágenes de SO y, también, instantáneas de discos persistentes almacenadas en Compute Engine y replicación de datos entre el sitio principal y el de DR. Para la replicación de datos, puedes usar la replicación asíncrona de PD.
Debido a que se usa la replicación de datos, el riesgo de pérdida de datos se limita a la última sincronización de la base de datos.
Para extender tu RPO en el tiempo, puedes almacenar copias de seguridad de los datos en un bucket de Cloud Storage, que no se muestra en el diagrama. Para las instantáneas de discos persistentes, puedes usar instantáneas programadas y adaptar la política de retención a tu RPO.
Según los requisitos del sistema de base de datos, es posible que puedas implementar tu base de datos en una VM más pequeña en el sitio de DR que la que se requiere en el sitio principal, lo que puede ayudar a reducir los costos hasta que se active el sistema de DR. En este caso, debes cambiar el tamaño de la VM al tamaño requerido durante la recuperación.
A continuación, se incluyen las acciones que debes realizar para recuperar un sistema como el siguiente:
- Implementar las instancias de VM para SAP NetWeaver y los servidores de aplicaciones desde instantáneas de discos persistentes o imágenes, si es necesario
- Sincronizar los sistemas de archivos desde instantáneas de discos persistentes o desde otro almacenamiento
- Cambiar el tamaño de la instancia de VM de la base de datos, si es necesario
- Cambiar la base de datos principal al sitio de DR
- Iniciar el servicio de la aplicación en el sitio de DR
Ejemplo de un valor alto de RTO de arquitectura de DR
En el siguiente diagrama de arquitectura, se muestra el RTO más alto de los ejemplos y es la opción de menor costo.
En este diseño, puedes implementar con anterioridad los servidores y detenerlos a fin de evitar incurrir en cargos por las VM o, para evitar costos asociados con los discos persistentes y otros recursos relacionados con las VM, puedes implementarlas como parte del proceso de recuperación.
En esta situación, es probable que uses las opciones de copia de seguridad que incluyen imágenes de SO y, también, instantáneas de discos persistentes almacenadas en Compute Engine y copias de seguridad de datos que se almacenan en Cloud Storage.
Para cumplir con tu RPO, puedes ajustar la frecuencia de la copia de seguridad y las políticas de retención de las programaciones de instantáneas y de las copias de seguridad en el bucket de Cloud Storage.
A continuación, se incluyen las acciones que debes realizar para recuperar un sistema como el siguiente:
- Implementar las instancias de VM para SAP NetWeaver, los servidores de aplicaciones y el servidor de base de datos desde instantáneas de discos persistentes multirregionales o imágenes almacenadas en Compute Engine, si es necesario
- Sincronizar los sistemas de archivos desde instantáneas de discos persistentes o desde otro almacenamiento
- Recuperar la base de datos desde los archivos de copia de seguridad que se encuentran en el bucket de Cloud Storage multirregional o en otra ubicación
- Cambiar la base de datos principal al sitio de DR
- Iniciar el servicio de la aplicación en el sitio de DR
Socios y productos para soluciones de DR de SAP en Google Cloud
Puedes encontrar socios que te ayuden con tu solución de DR en el Directorio de Google Cloud Partner.
También puedes encontrar varios productos y socios que admitan tu solución de DR en Google Cloud Marketplace.