Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Configure la recuperación ante desastres para Oracle JD Edwards EnterpriseOne con AWS Elastic Disaster Recovery
Creado por Thanigaivel Thirumalai () AWS
Entorno: producción | Tecnologías: infraestructura, migración, redes | Carga de trabajo: Oracle |
AWSservicios: AWS Elastic Disaster Recovery; Amazon EC2 |
Resumen
Los desastres provocados por catástrofes naturales, fallos en las aplicaciones o interrupciones de servicios son perjudiciales para los ingresos y provocan tiempo de inactividad en las aplicaciones corporativas. Para reducir las repercusiones de este tipo de eventos, la planificación de la recuperación ante desastres (DR) es fundamental para las empresas que adoptan los sistemas de planificación de recursos EnterpriseOne empresariales (ERP) de JD Edwards y otro software de misión crítica y empresarial.
Este patrón explica cómo las empresas pueden utilizar AWS Elastic Disaster Recovery como una opción de recuperación ante desastres para sus aplicaciones de JD Edwards. EnterpriseOne También describe los pasos para utilizar la conmutación por error y la recuperación ante fallos de Elastic Disaster Recovery a fin de crear una estrategia de recuperación ante desastres entre regiones para las bases de datos alojadas en una instancia de Amazon Elastic Compute Cloud (AmazonEC2) en la nube. AWS
Nota: Este patrón requiere las regiones principal y secundaria en las que se alojará la implementación de DR entre regiones. AWS
Oracle JD Edwards EnterpriseOne
AWSElastic Disaster Recovery minimiza el tiempo de inactividad y la pérdida de datos con una recuperación rápida y confiable de las aplicaciones locales y basadas en la nube mediante el uso de un almacenamiento asequible, un mínimo de cómputo y recuperación. point-in-time
AWSproporciona cuatro patrones de arquitectura de DR principales. Este documento se centra en la instalación, configuración y optimización mediante una estrategia de prueba piloto. Esta estrategia le ayuda a crear un entorno de DR de costo reducido, en el que inicialmente se aprovisiona un servidor de replicación para replicar los datos de la base de datos de origen. El servidor de base de datos propiamente dicho se aprovisiona solo cuando se inicia un proceso de recuperación de desastres. Esta estrategia elimina los gastos de mantenimiento de un servidor de base de datos en la región de DR. En su lugar, paga por una EC2 instancia más pequeña que sirve como servidor de replicación.
Requisitos previos y limitaciones
Requisitos previos
Una cuenta de AWS activa.
Una EnterpriseOne aplicación de JD Edwards que se ejecuta en Oracle Database o Microsoft SQL Server con una base de datos compatible en estado de ejecución en una EC2 instancia gestionada. Esta aplicación debe incluir todos los componentes EnterpriseOne básicos de JD Edwards (servidor empresarial, HTML servidor y servidor de bases de datos) instalados en una AWS región.
Un rol de AWS Identity and Access Management (IAM) para configurar el servicio Elastic Disaster Recovery.
Una red para ejecutar Elastic Disaster Recovery, configurada de acuerdo con los ajustes de conectividad requeridos.
Limitaciones
Puede utilizar este patrón para replicar todos los niveles, a menos que la base de datos esté alojada en Amazon Relational Database Service (RDSAmazon), en cuyo caso le recomendamos que utilice la funcionalidad de copia entre regiones de Amazon. RDS
Elastic Disaster Recovery no es compatible con CloudEndure Disaster Recovery, pero puedes actualizarlo desde CloudEndure Disaster Recovery. Para obtener más información, consulta la documentación FAQde Elastic Disaster Recovery.
Amazon Elastic Block Store (AmazonEBS) limita la velocidad a la que se pueden tomar instantáneas. Puede replicar un número máximo de 300 servidores en una sola AWS cuenta mediante Elastic Disaster Recovery. Para replicar más servidores, puede usar varias AWS cuentas o varias AWS regiones de destino. (Deberá configurar Elastic Disaster Recovery por separado en cada cuenta y región). Para más información, consulte las Prácticas recomendadas en la documentación de Elastic Disaster Recovery.
Las cargas de trabajo de origen (la EnterpriseOne aplicación y la base de datos de JD Edwards) deben alojarse en EC2 instancias. Este patrón no admite cargas de trabajo en las instalaciones o en otros entornos de nube.
Este patrón se centra en los EnterpriseOne componentes de JD Edwards. Un plan completo de DR y continuidad empresarial (BCP) debe incluir otros servicios básicos, que incluyen:
Redes (nube privada virtual, subredes y grupos de seguridad)
Active Directory
Amazon WorkSpaces
Elastic Load Balancing
Un servicio de base de datos gestionado como Amazon Relational Database Service (AmazonRDS)
Para obtener información adicional sobre los requisitos previos, configuraciones y limitaciones, consulte la documentación de Elastic Disaster Recovery.
Versiones de producto
Oracle JD Edwards EnterpriseOne (versiones compatibles con Oracle y SQL Server basadas en los requisitos técnicos mínimos de Oracle)
Arquitectura
Pila de tecnología de destino
Una sola región y una única nube privada virtual (VPC) para producción y no producción, y una segunda región para DR
Zonas de disponibilidad únicas para asegurar una baja latencia entre los servidores
Un equilibrador de carga de aplicación que distribuya el tráfico de red para mejorar la escalabilidad y la disponibilidad de las aplicaciones en varias zonas de disponibilidad
Amazon Route 53 proporcionará la configuración del Sistema de nombres de dominio (DNS)
Amazon ofrecerá WorkSpaces a los usuarios una experiencia de escritorio en la nube
Amazon Simple Storage Service (Amazon S3) para almacenar copias de seguridad, archivos y objetos
Amazon CloudWatch para el registro, la supervisión y las alarmas de aplicaciones
Amazon Elastic Disaster Recovery, para la recuperación de desastres
Arquitectura de destino
El siguiente diagrama muestra la arquitectura de recuperación ante desastres interregional de JD Edwards EnterpriseOne mediante Elastic Disaster Recovery.
Procedimiento
A continuación puede ver un resumen de alto nivel del proceso. Para más información, consulte la sección Epics.
La replicación de Elastic Disaster Recovery comienza con una sincronización inicial. Durante la sincronización inicial, el agente de AWS replicación replica todos los datos de los discos de origen en el recurso correspondiente de la subred del área de almacenamiento.
La replicación continua sigue realizándose indefinidamente una vez finalizada la sincronización inicial.
Debe revisar los parámetros de lanzamiento, que incluyen las configuraciones específicas del servicio y una plantilla de EC2 lanzamiento de Amazon, una vez que se haya instalado el agente y se haya iniciado la replicación. Cuando se indique que el servidor de origen está listo para la recuperación, podrá iniciar las instancias.
Cuando Elastic Disaster Recovery emite una serie de API llamadas para iniciar la operación de lanzamiento, la instancia de recuperación se inicia inmediatamente de AWS acuerdo con la configuración de lanzamiento. El servicio activa automáticamente un servidor de conversión durante el inicio.
La nueva instancia se activa una vez AWS finalizada la conversión y está lista para usarse. El estado del servidor de origen en el momento del lanzamiento se representa mediante los volúmenes asociados a la instancia lanzada. El proceso de conversión implica cambios en los controladores, la red y la licencia del sistema operativo para garantizar que la instancia se inicie de forma nativa. AWS
Tras el lanzamiento, los volúmenes recién creados ya no se mantienen sincronizados con los servidores de origen. El agente de AWS replicación sigue replicando de forma rutinaria los cambios realizados en los servidores de origen en los volúmenes del área de almacenamiento, pero las instancias lanzadas no reflejan esos cambios.
Al iniciar una nueva instancia de simulacro o recuperación, los datos siempre se reflejan en el estado más reciente que se ha replicado desde el servidor de origen a la subred del área transitoria.
Cuando el servidor de origen esté marcado como preparado para la recuperación, podrá iniciar las instancias.
Nota: El proceso funciona en ambos sentidos: para la conmutación por error de una AWS región principal a una región DR y para la conmutación por error al sitio principal, una vez que se ha recuperado. Puede preparar la conmutación por recuperación invirtiendo la dirección de replicación de los datos desde el equipo de destino al equipo de origen de forma totalmente orquestada.
Entre las ventajas del proceso descrito en este patrón se incluyen las siguientes:
Flexibilidad: los servidores de replicación escalan horizontal y verticalmente en función del conjunto de datos y del tiempo de replicación, por lo que puede realizar pruebas de DR sin interrumpir las cargas de trabajo de origen ni la replicación.
Fiabilidad: la replicación es sólida, no disruptiva y continua.
Automatización: esta solución proporciona un proceso unificado y automatizado para las pruebas, la recuperación y la conmutación por recuperación.
Optimización de costos: puede replicar y pagar solo por los volúmenes necesarios, y pagar por los recursos de cómputo en el sitio de DR solo cuando esos recursos estén activados. Puede utilizar una instancia de replicación con costes optimizados (le recomendamos que utilice un tipo de instancia con optimización informática) para varias fuentes o para una sola fuente con un gran volumen. EBS
Automatizar y escalar
Al realizar una recuperación ante desastres a gran escala, los EnterpriseOne servidores de JD Edwards dependerán de otros servidores del entorno. Por ejemplo:
Los servidores de EnterpriseOne aplicaciones de JD Edwards que se conectan a una base de datos EnterpriseOne compatible con JD Edwards durante el arranque dependen de esa base de datos.
EnterpriseOne Los servidores de JD Edwards que requieren autenticación y necesitan conectarse a un controlador de dominio durante el arranque para iniciar los servicios dependen del controlador de dominio.
Por este motivo, le recomendamos que automatice las tareas de conmutación por error. Por ejemplo, puede usar AWS Lambda o AWS Step Functions para automatizar los scripts de EnterpriseOne inicio de JD Edwards y los cambios en el balanceador de carga para automatizar el end-to-end proceso de conmutación por error. Para obtener más información, consulta la entrada del blog Cómo crear un plan de recuperación ante desastres escalable con AWS Elastic
Herramientas
AWSservicios
Amazon Elastic Block Store (AmazonEBS) proporciona volúmenes de almacenamiento a nivel de bloques para usarlos con EC2 instancias.
Amazon Elastic Compute Cloud (AmazonEC2)
proporciona capacidad informática escalable en la AWS nube. Puede lanzar tantos servidores virtuales como necesite y escalarlos o reducirlos con rapidez. AWSElastic Disaster Recovery
minimiza el tiempo de inactividad y la pérdida de datos con una recuperación rápida y fiable de las aplicaciones locales y basadas en la nube mediante un almacenamiento asequible, un cálculo y point-in-time una recuperación mínimos. Amazon Virtual Private Cloud (AmazonVPC)
le ofrece un control total sobre su entorno de redes virtuales, incluida la ubicación de los recursos, la conectividad y la seguridad.
Prácticas recomendadas
Prácticas recomendadas generales
Elabore con antelación un plan de acción en caso de que se produzca un evento de recuperación real.
Después de configurar Elastic Disaster Recovery correctamente, cree una AWS CloudFormation plantilla que pueda crear la configuración a pedido, en caso de que sea necesario. Determine el orden en el que deben lanzarse los servidores y las aplicaciones, y regístrelo en el plan de recuperación.
Realice un simulacro regular (se aplican EC2 las tarifas estándar de Amazon).
Supervise el estado de la replicación en curso mediante la consola de Elastic Disaster Recovery o mediante programación.
Proteja las point-in-time instantáneas y confirme antes de finalizar las instancias.
Cree un IAM rol para la instalación del Agente de AWS Replicación.
Habilite la protección de finalización de las instancias de recuperación en un escenario real de DR.
No utilice la AWS acción Desconectarse de la consola de Elastic Disaster Recovery para los servidores en los que haya lanzado instancias de recuperación, ni siquiera en el caso de que se trate de un evento de recuperación real. Al realizar una desconexión, se cancelan todos los recursos de replicación relacionados con estos servidores de origen, incluidos sus point-in-time (PIT) puntos de recuperación.
Cambie la PIT política para cambiar la cantidad de días de retención de las instantáneas.
Edite la plantilla de lanzamiento, en la configuración de lanzamiento de Elastic Disaster Recovery, para configurar la subred, el grupo de seguridad y el tipo de instancia correctos para su servidor de destino.
Automatice el proceso de end-to-end conmutación por error mediante Lambda o Step Functions para automatizar los scripts de inicio de JD EnterpriseOne Edwards y los cambios en el balanceador de carga.
Optimización y consideraciones de JD Edwards EnterpriseOne
Vaya PrintQueuea la base de datos.
MediaObjectsMudarse a la base de datos.
Excluya los registros y la carpeta temporal de los servidores lógicos y por lotes.
Excluya la carpeta temporal de Oracle WebLogic.
Cree scripts para el inicio después de la conmutación por error.
Excluya el tempdb del servidor. SQL
Excluya el archivo temporal de Oracle.
Epics
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Configure la red de replicación. | Implemente su EnterpriseOne sistema JD Edwards en la AWS región principal e identifique la AWS región para la DR. Siga los pasos que se indican en la sección de requisitos de la red de replicación de la documentación de Elastic Disaster Recovery para planificar y configurar su red de replicación y DR. | AWSadministrador |
Determine RPO yRTO. | Identifique el objetivo de tiempo de recuperación (RTO) y el objetivo del punto de recuperación (RPO) para los servidores de aplicaciones y la base de datos. | Arquitecto de la nube, arquitecto de DR |
Habilite la replicación para AmazonEFS. | Si procede, habilite la replicación desde la región AWS principal a la región DR para sistemas de archivos compartidos como Amazon Elastic File System (AmazonEFS) mediante AWS DataSync rsync u otra herramienta adecuada. | Administrador de la nube |
Administre DNS en caso de recuperación ante desastres | Identifique el proceso para actualizar el Sistema de Nombres de Dominio (DNS) durante el simulacro de DR o la DR real | Administrador de la nube |
Cree un IAM rol para la configuración. | Sigue las instrucciones de la sección de inicialización y permisos de Elastic Disaster Recovery de la documentación de Elastic Disaster Recovery para crear un IAM rol que inicialice y administre el AWS servicio. | Administrador de la nube |
Configure la interconexión. VPC | Asegúrese de que la fuente y el destino VPCs estén sincronizados y sean accesibles entre sí. Para obtener instrucciones de configuración, consulta la VPCdocumentación de Amazon. | AWSadministrador |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Inicialice Elastic Disaster Recovery. | Abra la consola de Elastic Disaster Recovery | AWSadministrador |
Configure los servidores de replicación |
| AWSadministrador |
Configure los volúmenes y los grupos de seguridad. |
| AWSadministrador |
Configure los ajustes adicionales. |
| AWSadministrador |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Cree un IAM rol. | Cree un IAM rol que contenga la | AWSadministrador |
Compruebe los requisitos. | Compruebe y complete los requisitos previos de la documentación de Elastic Disaster Recovery para instalar el agente de AWS replicación. | AWSadministrador |
Instale el agente AWS de replicación. | Siga las instrucciones de instalación de su sistema operativo e instale el agente de AWS replicación.
Repita estos pasos en el servidor restante. | AWSadministrador |
Supervisar la replicación | Regrese al panel Servidores de origen de Elastic Disaster Recovery para supervisar el estado de la replicación. La sincronización inicial tardará algún tiempo en función del tamaño de la transferencia de datos. Cuando el servidor de origen esté completamente sincronizado, el estado del servidor se actualizará a Listo. Esto significa que se ha creado un servidor de replicación en el área de ensayo y que los EBS volúmenes se han replicado desde el servidor de origen al área de almacenamiento provisional. | AWSadministrador |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Edite la configuración de lanzamiento. | Para actualizar la configuración de lanzamiento de las instancias de simulacro y recuperación, en la consola de Elastic Disaster Recovery | AWSadministrador |
Configure los ajustes generales de lanzamiento. | Revise la configuración general de lanzamiento según sus necesidades.
Para obtener más información, consulte la Configuración general de lanzamiento en la documentación de Elastic Disaster Recovery. | AWSadministrador |
Configura la plantilla de EC2 lanzamiento de Amazon. | Elastic Disaster Recovery utiliza las plantillas de lanzamiento de Amazon EC2 para lanzar instancias de perforación y recuperación para cada servidor de origen. La plantilla de lanzamiento se crea automáticamente para cada servidor de origen que añada a Elastic Disaster Recovery después de instalar el agente de AWS replicación. Debes configurar la plantilla de EC2 lanzamiento de Amazon como plantilla de lanzamiento predeterminada si quieres usarla con Elastic Disaster Recovery. Para obtener más información, consulta la plantilla de EC2 lanzamiento en la documentación de Elastic Disaster Recovery. | AWSadministrador |
| Tarea | Descripción | Habilidades requeridas |
|---|---|---|
Inicie el simulacro |
Para obtener más información, consulte las Preparación para la conmutación por error en la documentación de Elastic Disaster Recovery. | AWSadministrador |
Valide el simulacro. | En el paso anterior, lanzó nuevas instancias de destino en la región de DR. Las instancias de destino son réplicas de los servidores de origen basadas en la instantánea realizada al iniciar el lanzamiento. En este procedimiento, te conectas a tus máquinas de EC2 destino de Amazon para confirmar que funcionan según lo previsto.
| |
Iniciar la conmutación por error. | La conmutación por error es la redirección del tráfico de un sistema principal a un sistema secundario. Elastic Disaster Recovery le ayuda a realizar una conmutación por error al iniciar instancias de recuperación en ese momento. AWS Cuando se lanzan las instancias de recuperación, el tráfico de sus sistemas principales se redirige a estas instancias.
Para más información, consulte las Efectuar una conmutación por error en la documentación de Elastic Disaster Recovery. | AWSadministrador |
Inicie la conmutación por recuperación. | El proceso para iniciar una conmutación por recuperación es similar al proceso para iniciar una conmutación por error.
Para más información, consulte las Efectuar una conmutación por recuperación en la documentación de Elastic Disaster Recovery. | AWSadministrador |
Inicie los EnterpriseOne componentes de JD Edwards. |
Deberá incorporar los cambios en Route 53 y Application Load Balancer para que funcione el EnterpriseOne enlace de JD Edwards. Puede automatizar estos pasos mediante Lambda, Step Functions y Systems Manager (Run Command). Nota: Elastic Disaster Recovery realiza la replicación a nivel de bloque de los EBS volúmenes de EC2 instancias de origen que alojan el sistema operativo y los sistemas de archivos. Los sistemas de archivos compartidos que se crearon con Amazon EFS no forman parte de esta replicación. Puede replicar los sistemas de archivos compartidos en la región de DR utilizando AWS DataSync, como se indica en el primer episodio, y luego montar estos sistemas de archivos replicados en el sistema de DR. | J.D. Edwards EnterpriseOne CNC |
Resolución de problemas
| Problema | Solución |
|---|---|
El estado de la replicación de los datos del servidor de origen es Estancado y la replicación se retrasa. Si comprueba los detalles, el estado de la replicación de datos muestra Agente no encontrado. | Compruebe que el servidor de origen estancado está en funcionamiento. Nota: Si el servidor de origen deja de funcionar, el servidor de replicación finaliza automáticamente. Para obtener más información sobre problemas de retardo, consulte Problemas de retardo en la replicación en la documentación de Elastic Disaster Recovery. |
La instalación del agente de AWS replicación en la EC2 instancia de origen falla en la RHEL versión 8.2 después de escanear los discos. | Antes de instalar el agente de AWS replicación en RHEL 8, CentOS 8 u Oracle Linux 8, ejecute:
Para más información, consulte las Requisitos de instalación de Linux en la documentación de Elastic Disaster Recovery. |
En la consola de Elastic Disaster Recovery, verá el servidor de origen como Listo con retardo, y el estado de replicación de datos como Estancado. Según el tiempo que el agente de AWS replicación no esté disponible, el estado puede indicar un retraso elevado, pero el problema sigue siendo el mismo. | Utilice un comando del sistema operativo para confirmar que el agente de AWS replicación se está ejecutando en la EC2 instancia de origen o confirme que la instancia se está ejecutando. Tras corregir los problemas, Elastic Disaster Recovery reiniciará el escaneo. Espere a que se hayan sincronizado todos los datos y el estado de la replicación sea Correcto antes de iniciar un simulacro de DR. |
Replicación inicial con retardo elevado. En la consola de Elastic Disaster Recovery, puede ver que el estado de sincronización inicial es extremadamente lento para un servidor de origen. | Compruebe los problemas de retardo en la replicación documentados en la sección Problemas de retardo en la replicación de la documentación de Elastic Disaster Recovery. Es posible que el servidor de replicación no pueda gestionar la carga debido a las operaciones informáticas intrínsecas. En ese caso, intenta actualizar el tipo de instancia tras consultar con el equipo de AWS Technical Support |
Recursos relacionados
Cómo crear un plan de recuperación ante desastres escalable con AWS Elastic Disaster Recovery
(entrada AWS del blog) AWSIntroducción técnica a Elastic Disaster Recovery
(curso de creación de AWS habilidades; requiere iniciar sesión)
