Configurer la reprise après sinistre pour Oracle JD Edwards EnterpriseOne avec AWS Elastic Disaster Recovery

PDF

Créée par Thanigaivel Thirumalai (AWS)

Récapitulatif

Les catastrophes provoquées par des catastrophes naturelles, des défaillances d'applications ou une interruption des services nuisent aux revenus et entraînent des interruptions de service pour les applications d'entreprise. Pour réduire les répercussions de tels événements, la planification de la reprise après sinistre (DR) est essentielle pour les entreprises qui adoptent les systèmes de planification des ressources EnterpriseOne d'entreprise (ERP) de JD Edwards et d'autres logiciels critiques et critiques. 

Ce modèle explique comment les entreprises peuvent utiliser AWS Elastic Disaster Recovery comme option de reprise après sinistre pour leurs EnterpriseOne applications JD Edwards. Il décrit également les étapes à suivre pour utiliser le basculement et le retour en arrière d'Elastic Disaster Recovery pour élaborer une stratégie de reprise après sinistre interrégionale pour les bases de données hébergées sur une instance Amazon Elastic Compute Cloud (Amazon EC2) dans le cloud AWS.

Note

Ce modèle nécessite que les régions principale et secondaire pour la mise en œuvre de la reprise après sinistre interrégionale soient hébergées sur AWS.

Oracle JD Edwards EnterpriseOne est une solution logicielle ERP intégrée pour les moyennes et grandes entreprises dans un large éventail de secteurs.

AWS Elastic Disaster Recovery minimise les temps d'arrêt et les pertes de données grâce à une restauration rapide et fiable des applications sur site et dans le cloud en utilisant un stockage abordable, un calcul et point-in-time une restauration minimaux.

AWS fournit quatre modèles d'architecture de base pour la reprise après sinistre. Ce document se concentre sur l'installation, la configuration et l'optimisation à l'aide de la stratégie d'éclairage pilote. Cette stratégie vous permet de créer un environnement de reprise après sinistre à moindre coût dans lequel vous configurez initialement un serveur de réplication pour répliquer les données de la base de données source, et vous approvisionnez le serveur de base de données proprement dit uniquement lorsque vous lancez une analyse de reprise après sinistre. Cette stratégie élimine les dépenses liées à la maintenance d'un serveur de base de données dans la région DR. Au lieu de cela, vous payez pour une EC2 instance plus petite qui sert de serveur de réplication.

Conditions préalables et limitations

Prérequis

• Un compte AWS actif.

• Une EnterpriseOne application JD Edwards exécutée sur Oracle Database ou Microsoft SQL Server avec une base de données prise en charge en cours d'exécution sur une EC2 instance gérée. Cette application doit inclure tous les composants de EnterpriseOne base de JD Edwards (serveur d'entreprise, serveur HTML et serveur de base de données) installés dans une région AWS.

• Rôle AWS Identity and Access Management (IAM) pour configurer le service Elastic Disaster Recovery.

• Le réseau utilisé pour exécuter Elastic Disaster Recovery est configuré conformément aux paramètres de connectivité requis.

Limites

• Vous pouvez utiliser ce modèle pour répliquer tous les niveaux, sauf si la base de données est hébergée sur Amazon Relational Database Service (Amazon RDS), auquel cas nous vous recommandons d'utiliser la fonctionnalité de copie interrégionale d'Amazon RDS.

• Elastic Disaster Recovery n'est pas compatible avec CloudEndure Disaster Recovery, mais vous pouvez effectuer une mise à niveau depuis CloudEndure Disaster Recovery. Pour plus d'informations, consultez la FAQ de la documentation d'Elastic Disaster Recovery.

• Amazon Elastic Block Store (Amazon EBS) limite la fréquence à laquelle vous pouvez prendre des instantanés. Vous pouvez répliquer un maximum de 300 serveurs dans un seul compte AWS à l'aide d'Elastic Disaster Recovery. Pour répliquer davantage de serveurs, vous pouvez utiliser plusieurs comptes AWS ou plusieurs régions AWS cibles. (Vous devrez configurer Elastic Disaster Recovery séparément pour chaque compte et région.) Pour plus d'informations, consultez les meilleures pratiques dans la documentation d'Elastic Disaster Recovery.

• Les charges de travail sources (l' EnterpriseOne application et la base de données JD Edwards) doivent être hébergées sur EC2 des instances. Ce modèle ne prend pas en charge les charges de travail sur site ou dans d'autres environnements cloud.

• Ce modèle se concentre sur les EnterpriseOne composants de JD Edwards. Un plan complet de reprise après sinistre et de continuité des activités (BCP) doit inclure d'autres services essentiels, notamment :

  • Mise en réseau (cloud privé virtuel, sous-réseaux et groupes de sécurité)

  • Active Directory

  • Amazon WorkSpaces

  • Elastic Load Balancing

  • Un service de base de données géré tel qu'Amazon Relational Database Service (Amazon RDS)

Pour plus d'informations sur les prérequis, les configurations et les limites, consultez la documentation d'Elastic Disaster Recovery.

Versions du produit

• Oracle JD Edwards EnterpriseOne (versions prises en charge par Oracle et SQL Server selon les exigences techniques minimales d'Oracle)

Architecture

Pile technologique cible

• Une seule région et un seul cloud privé virtuel (VPC) pour la production et la non-production, et une deuxième région pour la reprise après sinistre

• Zones de disponibilité uniques pour garantir une faible latence entre les serveurs

• Application Load Balancer qui répartit le trafic réseau afin d'améliorer l'évolutivité et la disponibilité de vos applications sur plusieurs zones de disponibilité

• Amazon Route 53 fournira la configuration du système de noms de domaine (DNS)

• Amazon WorkSpaces va offrir aux utilisateurs une expérience de bureau dans le cloud

• Amazon Simple Storage Service (Amazon S3) pour le stockage de sauvegardes, de fichiers et d'objets

• Amazon CloudWatch pour la journalisation, la surveillance et les alarmes des applications

• Amazon Elastic Disaster Recovery pour la reprise après sinistre

Architecture cible

Le schéma suivant montre l'architecture de reprise après sinistre interrégionale de JD Edwards à l' EnterpriseOne aide d'Elastic Disaster Recovery.

Procédure

Voici un aperçu de haut niveau du processus. Pour plus de détails, consultez la section Epics.

• La réplication d'Elastic Disaster Recovery commence par une synchronisation initiale. Lors de la synchronisation initiale, l'agent de réplication AWS réplique toutes les données des disques sources vers la ressource appropriée dans le sous-réseau de la zone de transit.

• La réplication continue indéfiniment une fois la synchronisation initiale terminée.

• Vous passez en revue les paramètres de lancement, qui incluent les configurations spécifiques au service et un modèle de EC2 lancement Amazon, une fois l'agent installé et la réplication démarrée. Lorsque le serveur source est indiqué comme étant prêt pour la restauration, vous pouvez démarrer des instances.

• Lorsqu'Elastic Disaster Recovery émet une série d'appels d'API pour démarrer l'opération de lancement, l'instance de restauration est immédiatement lancée sur AWS conformément à vos paramètres de lancement. Le service lance automatiquement un serveur de conversion au démarrage.

• La nouvelle instance est lancée sur AWS une fois la conversion terminée et est prête à être utilisée. L'état du serveur source au moment du lancement est représenté par les volumes associés à l'instance lancée. Le processus de conversion implique des modifications des pilotes, du réseau et de la licence du système d'exploitation afin de garantir le démarrage natif de l'instance sur AWS.

• Après le lancement, les volumes nouvellement créés ne sont plus synchronisés avec les serveurs sources. L'agent de réplication AWS continue de répliquer régulièrement les modifications apportées à vos serveurs sources vers les volumes de la zone de transit, mais les instances lancées ne reflètent pas ces modifications.

• Lorsque vous démarrez une nouvelle instance de forage ou de restauration, les données sont toujours reflétées dans l'état le plus récent qui a été répliqué depuis le serveur source vers le sous-réseau de la zone de transit.

• Lorsque le serveur source est marqué comme étant prêt pour la restauration, vous pouvez démarrer des instances.

Note

Le processus fonctionne dans les deux sens : pour le basculement d'une région AWS principale vers une région DR, et pour revenir au site principal, une fois celui-ci restauré. Vous pouvez vous préparer au retour en arrière en inversant le sens de la réplication des données de la machine cible vers la machine source de manière entièrement orchestrée.

Les avantages de ce processus décrit dans ce modèle incluent :

• Flexibilité : les serveurs de réplication sont évolutifs et évolutifs en fonction du jeu de données et du temps de réplication, afin que vous puissiez effectuer des tests de reprise après sinistre sans perturber les charges de travail source ou la réplication.

• Fiabilité : la réplication est robuste, continue et sans interruption.

• Automatisation : cette solution fournit un processus unifié et automatisé pour les tests, la restauration et le retour en panne.

• Optimisation des coûts : vous pouvez uniquement répliquer les volumes nécessaires et les payer, et payer les ressources de calcul sur le site de reprise après sinistre uniquement lorsque ces ressources sont activées. Vous pouvez utiliser une instance de réplication optimisée en termes de coûts (nous vous recommandons d'utiliser un type d'instance optimisé pour le calcul) pour plusieurs sources ou une source unique avec un volume EBS important.

Automatisation et mise à l'échelle

Lorsque vous effectuez une reprise après sinistre à grande échelle, les EnterpriseOne serveurs JD Edwards dépendent des autres serveurs de l'environnement. Par exemple :

• Les serveurs EnterpriseOne d'applications JD Edwards qui se connectent à une base de données EnterpriseOne prise en charge par JD Edwards au démarrage dépendent de cette base de données.

• EnterpriseOne Les serveurs JD Edwards qui nécessitent une authentification et doivent se connecter à un contrôleur de domaine au démarrage pour démarrer les services dépendent du contrôleur de domaine.

C'est pourquoi nous vous recommandons d'automatiser les tâches de basculement. Par exemple, vous pouvez utiliser AWS Lambda ou AWS Step Functions pour automatiser les scripts de EnterpriseOne démarrage de JD Edwards et les modifications apportées à l'équilibreur de charge afin d'automatiser le end-to-end processus de basculement. Pour plus d'informations, consultez le billet de blog Création d'un plan de reprise après sinistre évolutif avec AWS Elastic Disaster Recovery.

Outils

Services AWS

• Amazon Elastic Block Store (Amazon EBS) fournit des volumes de stockage au niveau des blocs à utiliser avec les instances. EC2

• Amazon Elastic Compute Cloud (Amazon EC2) fournit une capacité de calcul évolutive dans le cloud AWS. Vous pouvez lancer autant de serveurs virtuels que vous le souhaitez et les augmenter ou les diminuer rapidement.

• AWS Elastic Disaster Recovery minimise les temps d'arrêt et les pertes de données grâce à une restauration rapide et fiable des applications sur site et dans le cloud à l'aide d'un stockage abordable, d'un calcul et point-in-time d'une restauration minimaux.

• Amazon Virtual Private Cloud (Amazon VPC) vous donne le contrôle total de votre environnement réseau virtuel, y compris le placement des ressources, la connectivité et la sécurité.

Bonnes pratiques

Bonnes pratiques générales

• Préparez un plan écrit indiquant ce qu'il faut faire en cas de véritable rétablissement.

• Après avoir correctement configuré Elastic Disaster Recovery, créez un CloudFormation modèle AWS capable de créer la configuration à la demande, en cas de besoin. Déterminez l'ordre dans lequel les serveurs et les applications doivent être lancés, et enregistrez-le dans le plan de restauration.

• Effectuez un exercice régulier (les EC2 tarifs Amazon standard s'appliquent).

• Surveillez l'état de la réplication en cours à l'aide de la console Elastic Disaster Recovery ou par programmation.

• Protégez les point-in-time instantanés et confirmez avant de mettre fin aux instances.

• Créez un rôle IAM pour l'installation d'AWS Replication Agent.

• Activez la protection contre la résiliation pour les instances de restauration dans un scénario de reprise après sinistre réel.

• N'utilisez pas l'action Disconnect from AWS dans la console Elastic Disaster Recovery pour les serveurs pour lesquels vous avez lancé des instances de restauration, même dans le cas d'un véritable événement de restauration. L'exécution d'une déconnexion met fin à toutes les ressources de réplication associées à ces serveurs sources, y compris vos points de restauration point-in-time (PIT).

• Modifiez la politique PIT pour modifier le nombre de jours de conservation des instantanés.

• Modifiez le modèle de lancement dans les paramètres de lancement d'Elastic Disaster Recovery afin de définir le sous-réseau, le groupe de sécurité et le type d'instance appropriés pour votre serveur cible.

• Automatisez le processus de end-to-end basculement en utilisant Lambda ou Step Functions pour automatiser les scripts de démarrage de JD EnterpriseOne Edwards et les modifications de l'équilibreur de charge.

EnterpriseOne Optimisation et considérations de JD Edwards

• Accédez à PrintQueuela base de données.

• Accédez à MediaObjectsla base de données.

• Excluez les journaux et le dossier temporaire des serveurs de traitement par lots et des serveurs logiques.

• Excluez le dossier temporaire d'Oracle WebLogic.

• Créez des scripts pour le démarrage après le basculement.

• Excluez le tempdb pour SQL Server.

• Excluez le fichier temporaire pour Oracle.

Épopées

Exécuter les tâches initiales et la configuration

Tâche	Description	Compétences requises
Configurez le réseau de réplication.	Implémentez votre EnterpriseOne système JD Edwards dans la région AWS principale et identifiez la région AWS pour DR. Suivez les étapes décrites dans la section Exigences relatives au réseau de réplication de la documentation Elastic Disaster Recovery pour planifier et configurer votre réseau de réplication et de reprise après sinistre.	Administrateur AWS
Déterminez le RPO et le RTO.	Identifiez l'objectif de temps de restauration (RTO) et l'objectif de point de restauration (RPO) pour vos serveurs d'applications et votre base de données.	Architecte cloud, architecte DR
Activez la réplication pour Amazon EFS.	Le cas échéant, activez la réplication depuis la région principale AWS vers la région DR pour les systèmes de fichiers partagés tels qu'Amazon Elastic File System (Amazon EFS) en utilisant AWS DataSync, rsync ou un autre outil approprié.	Administrateur du cloud
Gérez le DNS en cas de DR.	Identifiez le processus de mise à jour du système de noms de domaine (DNS) lors de l'exercice DR ou de la DR proprement dite	Administrateur du cloud
Créez un rôle IAM pour la configuration.	Suivez les instructions de la section Initialisation et autorisations d'Elastic Disaster Recovery de la documentation d'Elastic Disaster Recovery pour créer un rôle IAM afin d'initialiser et de gérer le service AWS.	Administrateur du cloud
Configurez le peering VPC.	Assurez-vous que la source et la cible VPCs sont homologues et accessibles l'une à l'autre. Pour les instructions de configuration, consultez la documentation Amazon VPC.	Administrateur AWS

Exécuter les tâches initiales et la configuration

Tâche	Description	Compétences requises
Configurez le réseau de réplication.	Implémentez votre EnterpriseOne système JD Edwards dans la région AWS principale et identifiez la région AWS pour DR. Suivez les étapes décrites dans la section Exigences relatives au réseau de réplication de la documentation Elastic Disaster Recovery pour planifier et configurer votre réseau de réplication et de reprise après sinistre.	Administrateur AWS
Déterminez le RPO et le RTO.	Identifiez l'objectif de temps de restauration (RTO) et l'objectif de point de restauration (RPO) pour vos serveurs d'applications et votre base de données.	Architecte cloud, architecte DR
Activez la réplication pour Amazon EFS.	Le cas échéant, activez la réplication depuis la région principale AWS vers la région DR pour les systèmes de fichiers partagés tels qu'Amazon Elastic File System (Amazon EFS) en utilisant AWS DataSync, rsync ou un autre outil approprié.	Administrateur du cloud
Gérez le DNS en cas de DR.	Identifiez le processus de mise à jour du système de noms de domaine (DNS) lors de l'exercice DR ou de la DR proprement dite	Administrateur du cloud
Créez un rôle IAM pour la configuration.	Suivez les instructions de la section Initialisation et autorisations d'Elastic Disaster Recovery de la documentation d'Elastic Disaster Recovery pour créer un rôle IAM afin d'initialiser et de gérer le service AWS.	Administrateur du cloud
Configurez le peering VPC.	Assurez-vous que la source et la cible VPCs sont homologues et accessibles l'une à l'autre. Pour les instructions de configuration, consultez la documentation Amazon VPC.	Administrateur AWS

Configuration des paramètres de réplication d'Elastic Disaster Recovery

Tâche	Description	Compétences requises
Initialisez Elastic Disaster Recovery.	Ouvrez la console Elastic Disaster Recovery, choisissez la région AWS cible (dans laquelle vous allez répliquer les données et lancer des instances de restauration), puis choisissez Définir les paramètres de réplication par défaut.	Administrateur AWS
Configurez des serveurs de réplication.	Dans le volet Configurer les serveurs de réplication, entrez le sous-réseau de la zone de transit et le type d'instance du serveur de réplication. Le type d'instance t3.small est sélectionné par défaut. Configurez ce paramètre en fonction de vos besoins et n'oubliez pas de tenir compte de la tarification des instances. Pour plus d'informations, consultez les EC2 tarifs Amazon. Dans la section Accès au service, choisissez Afficher les détails pour consulter le rôle lié au service et les politiques supplémentaires créées lors de l'initialisation du service. Choisissez Suivant.	Administrateur AWS
Configurez les volumes et les groupes de sécurité.	Dans le volet Volumes et groupes de sécurité, sélectionnez le type de volume EBS pour le serveur de réplication et définissez le chiffrement Amazon EBS sur Default. Sélectionnez Toujours utiliser le groupe de sécurité AWS Elastic Disaster Recovery afin qu'Elastic Disaster Recovery attache et surveille automatiquement le groupe de sécurité par défaut. Choisissez Suivant.	Administrateur AWS
Configurez des paramètres supplémentaires.	Dans le volet Paramètres supplémentaires, configurez le routage et la limitation des données, la politique PIT et les balises. Le routage et la régulation des données contrôlent la manière dont les données circulent du serveur externe vers les serveurs de réplication. Choisissez Utiliser une adresse IP privée pour la réplication des données. Dans le cas contraire, les serveurs de réplication se verront automatiquement attribuer une adresse IP publique et les données circuleront sur l'Internet public. Dans la section Politique de point in time (PIT), configurez une politique de rétention qui détermine la durée après laquelle les instantanés ne sont plus nécessaires. La période de rétention par défaut est de sept jours. Dans la section Tags, ajoutez des balises personnalisées aux ressources créées par Elastic Disaster Recovery dans votre compte AWS. Choisissez Next, passez en revue les paramètres dans le volet suivant, puis choisissez Create default pour créer le modèle par défaut.	Administrateur AWS

Configuration des paramètres de réplication d'Elastic Disaster Recovery

Tâche	Description	Compétences requises
Initialisez Elastic Disaster Recovery.	Ouvrez la console Elastic Disaster Recovery, choisissez la région AWS cible (dans laquelle vous allez répliquer les données et lancer des instances de restauration), puis choisissez Définir les paramètres de réplication par défaut.	Administrateur AWS
Configurez des serveurs de réplication.	Dans le volet Configurer les serveurs de réplication, entrez le sous-réseau de la zone de transit et le type d'instance du serveur de réplication. Le type d'instance t3.small est sélectionné par défaut. Configurez ce paramètre en fonction de vos besoins et n'oubliez pas de tenir compte de la tarification des instances. Pour plus d'informations, consultez les EC2 tarifs Amazon. Dans la section Accès au service, choisissez Afficher les détails pour consulter le rôle lié au service et les politiques supplémentaires créées lors de l'initialisation du service. Choisissez Suivant.	Administrateur AWS
Configurez les volumes et les groupes de sécurité.	Dans le volet Volumes et groupes de sécurité, sélectionnez le type de volume EBS pour le serveur de réplication et définissez le chiffrement Amazon EBS sur Default. Sélectionnez Toujours utiliser le groupe de sécurité AWS Elastic Disaster Recovery afin qu'Elastic Disaster Recovery attache et surveille automatiquement le groupe de sécurité par défaut. Choisissez Suivant.	Administrateur AWS
Configurez des paramètres supplémentaires.	Dans le volet Paramètres supplémentaires, configurez le routage et la limitation des données, la politique PIT et les balises. Le routage et la régulation des données contrôlent la manière dont les données circulent du serveur externe vers les serveurs de réplication. Choisissez Utiliser une adresse IP privée pour la réplication des données. Dans le cas contraire, les serveurs de réplication se verront automatiquement attribuer une adresse IP publique et les données circuleront sur l'Internet public. Dans la section Politique de point in time (PIT), configurez une politique de rétention qui détermine la durée après laquelle les instantanés ne sont plus nécessaires. La période de rétention par défaut est de sept jours. Dans la section Tags, ajoutez des balises personnalisées aux ressources créées par Elastic Disaster Recovery dans votre compte AWS. Choisissez Next, passez en revue les paramètres dans le volet suivant, puis choisissez Create default pour créer le modèle par défaut.	Administrateur AWS

Installation de l'agent de réplication AWS

Tâche	Description	Compétences requises
Créez un rôle IAM.	Créez un rôle IAM contenant la AWSElasticDisasterRecoveryAgentInstallationPolicy politique. Dans la section Sélectionner le type d'accès AWS, activez l'accès programmatique. Notez l'ID de la clé d'accès et la clé d'accès secrète. Vous aurez besoin de ces informations lors de l'installation de l'agent de réplication AWS.	Administrateur AWS
Vérifiez les exigences.	Vérifiez et remplissez les conditions requises dans la documentation d'Elastic Disaster Recovery pour installer l'agent de réplication AWS.	Administrateur AWS
Installez l'agent de réplication AWS.	Suivez les instructions d'installation de votre système d'exploitation et installez l'agent de réplication AWS. Pour Microsoft Windows : téléchargez les fichiers d'installation et exécutez le fichier .exe en tant qu'administrateur.  Répondez aux instructions pour terminer l'installation. Pour Linux : copiez les commandes suivantes (dans l'ordre indiqué) et collez-les dans votre session Secure Shell (SSH). La première commande télécharge le programme d'installation et la seconde l'exécute. wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py sudo python3 aws-replication-installer-init.py Répondez aux instructions pour terminer l'installation. Note Modifiez l'URL pour qu'elle reflète votre région. Répétez ces étapes pour le serveur restant.	Administrateur AWS
Surveillez la réplication.	Retournez dans le volet des serveurs Elastic Disaster Recovery Source pour surveiller l'état de la réplication. La synchronisation initiale peut prendre un certain temps en fonction de la taille du transfert de données. Lorsque le serveur source est entièrement synchronisé, l'état du serveur passe à Prêt. Cela signifie qu'un serveur de réplication a été créé dans la zone intermédiaire et que les volumes EBS ont été répliqués du serveur source vers la zone intermédiaire.	Administrateur AWS

Installation de l'agent de réplication AWS

Tâche	Description	Compétences requises
Créez un rôle IAM.	Créez un rôle IAM contenant la AWSElasticDisasterRecoveryAgentInstallationPolicy politique. Dans la section Sélectionner le type d'accès AWS, activez l'accès programmatique. Notez l'ID de la clé d'accès et la clé d'accès secrète. Vous aurez besoin de ces informations lors de l'installation de l'agent de réplication AWS.	Administrateur AWS
Vérifiez les exigences.	Vérifiez et remplissez les conditions requises dans la documentation d'Elastic Disaster Recovery pour installer l'agent de réplication AWS.	Administrateur AWS
Installez l'agent de réplication AWS.	Suivez les instructions d'installation de votre système d'exploitation et installez l'agent de réplication AWS. Pour Microsoft Windows : téléchargez les fichiers d'installation et exécutez le fichier .exe en tant qu'administrateur.  Répondez aux instructions pour terminer l'installation. Pour Linux : copiez les commandes suivantes (dans l'ordre indiqué) et collez-les dans votre session Secure Shell (SSH). La première commande télécharge le programme d'installation et la seconde l'exécute. wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py sudo python3 aws-replication-installer-init.py Répondez aux instructions pour terminer l'installation. Note Modifiez l'URL pour qu'elle reflète votre région. Répétez ces étapes pour le serveur restant.	Administrateur AWS
Surveillez la réplication.	Retournez dans le volet des serveurs Elastic Disaster Recovery Source pour surveiller l'état de la réplication. La synchronisation initiale peut prendre un certain temps en fonction de la taille du transfert de données. Lorsque le serveur source est entièrement synchronisé, l'état du serveur passe à Prêt. Cela signifie qu'un serveur de réplication a été créé dans la zone intermédiaire et que les volumes EBS ont été répliqués du serveur source vers la zone intermédiaire.	Administrateur AWS

Configuration des paramètres de lancement

Tâche	Description	Compétences requises
Modifiez les paramètres de lancement.	Pour mettre à jour les paramètres de lancement des instances de forage et de restauration, sur la console Elastic Disaster Recovery, sélectionnez le serveur source, puis choisissez Actions, Modifier les paramètres de lancement. Vous pouvez également choisir vos machines sources de réplication sur la page Serveurs source, puis choisir l'onglet Paramètres de lancement. Cet onglet comporte deux sections : Paramètres de lancement généraux et modèle de EC2 lancement.	Administrateur AWS
Configurez les paramètres généraux de lancement.	Révisez les paramètres de lancement généraux en fonction de vos besoins. Dimensionnement correct du type d'instance : si vous choisissez Basic, Elastic Disaster Recovery contourne le type d'instance que vous avez sélectionné dans le modèle de EC2 lancement Amazon et choisit automatiquement le type d'instance en fonction du système d'exploitation, du processeur et de la RAM du serveur source. Copier l'adresse IP privée : choisissez si vous souhaitez qu'Elastic Disaster Recovery s'assure que l'adresse IP privée utilisée par l'instance de forage ou de restauration correspond à l'adresse IP privée utilisée par le serveur source. Si vous avez choisi Oui, assurez-vous que la plage d'adresses IP du sous-réseau que vous avez définie dans le modèle de EC2 lancement Amazon inclut l'adresse IP privée. Pour plus d'informations, consultez la section Paramètres de lancement généraux dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Configurez le modèle EC2 de lancement Amazon.	Elastic Disaster Recovery utilise les modèles de EC2 lancement Amazon pour lancer des instances de forage et de restauration pour chaque serveur source. Le modèle de lancement est créé automatiquement pour chaque serveur source que vous ajoutez à Elastic Disaster Recovery après avoir installé l'agent de réplication AWS. Vous devez définir le modèle de EC2 lancement Amazon comme modèle de lancement par défaut si vous souhaitez l'utiliser avec Elastic Disaster Recovery. Pour plus d'informations, consultez la section Modèle de EC2 lancement dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS

Configuration des paramètres de lancement

Tâche	Description	Compétences requises
Modifiez les paramètres de lancement.	Pour mettre à jour les paramètres de lancement des instances de forage et de restauration, sur la console Elastic Disaster Recovery, sélectionnez le serveur source, puis choisissez Actions, Modifier les paramètres de lancement. Vous pouvez également choisir vos machines sources de réplication sur la page Serveurs source, puis choisir l'onglet Paramètres de lancement. Cet onglet comporte deux sections : Paramètres de lancement généraux et modèle de EC2 lancement.	Administrateur AWS
Configurez les paramètres généraux de lancement.	Révisez les paramètres de lancement généraux en fonction de vos besoins. Dimensionnement correct du type d'instance : si vous choisissez Basic, Elastic Disaster Recovery contourne le type d'instance que vous avez sélectionné dans le modèle de EC2 lancement Amazon et choisit automatiquement le type d'instance en fonction du système d'exploitation, du processeur et de la RAM du serveur source. Copier l'adresse IP privée : choisissez si vous souhaitez qu'Elastic Disaster Recovery s'assure que l'adresse IP privée utilisée par l'instance de forage ou de restauration correspond à l'adresse IP privée utilisée par le serveur source. Si vous avez choisi Oui, assurez-vous que la plage d'adresses IP du sous-réseau que vous avez définie dans le modèle de EC2 lancement Amazon inclut l'adresse IP privée. Pour plus d'informations, consultez la section Paramètres de lancement généraux dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Configurez le modèle EC2 de lancement Amazon.	Elastic Disaster Recovery utilise les modèles de EC2 lancement Amazon pour lancer des instances de forage et de restauration pour chaque serveur source. Le modèle de lancement est créé automatiquement pour chaque serveur source que vous ajoutez à Elastic Disaster Recovery après avoir installé l'agent de réplication AWS. Vous devez définir le modèle de EC2 lancement Amazon comme modèle de lancement par défaut si vous souhaitez l'utiliser avec Elastic Disaster Recovery. Pour plus d'informations, consultez la section Modèle de EC2 lancement dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS

Lancer le forage DR et le basculement

Tâche	Description	Compétences requises
Lancer un exercice	Sur la console Elastic Disaster Recovery, ouvrez la page Serveurs source et vérifiez que l'état du serveur source est Prêt. Sélectionnez tous les serveurs source pour lesquels vous souhaitez effectuer l'exercice DR. Dans le menu Initiate recovery job, choisissez Initiate drill et sélectionnez le point-in-time cliché approprié. Cela lance une tâche de restauration pour les serveurs source sélectionnés. Vous pouvez suivre l'état de la tâche dans l'onglet Historique des tâches de restauration. L'instance de forage lancée apparaît également sur la page Instances de restauration. Note Les modifications ultérieures apportées au serveur source seront synchronisées avec le serveur de réplication, et non avec l'instance de forage. Testez et vérifiez l'instance de forage DR. Sur la page Instances de restauration, sélectionnez l'instance de forage, puis choisissez Actions, Disconnect from AWS. Cela supprime l'agent de réplication AWS de l'instance de restauration et supprime toutes les ressources associées à l'instance de restauration d'Elastic Disaster Recovery. Choisissez Supprimer les instances de restauration. Cela supprime la représentation de l'instance de la console Elastic Disaster Recovery et dissocie complètement l'instance du service Elastic Disaster Recovery. Elle ne supprime pas l' EC2 instance sous-jacente. Mettez fin à l'instance DR Drill depuis la EC2 console Amazon. Pour plus d'informations, consultez la section Préparation au basculement dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Validez l'exercice.	À l'étape précédente, vous avez lancé de nouvelles instances cibles dans la région DR. Les instances cibles sont des répliques des serveurs sources basées sur le snapshot pris lorsque vous avez lancé le lancement. Dans cette procédure, vous vous connectez à vos machines EC2 cibles Amazon pour vérifier qu'elles fonctionnent comme prévu. Ouvrez la EC2 console Amazon. Choisissez Instances (en cours d'exécution). Sélectionnez l'instance cible et notez son IPv4 adresse privée. Assurez-vous que vous pouvez vous connecter à l' EC2 instance et que le JD Edwards EnterpriseOne et les composants associés sont répliqués comme prévu.
Lancez un basculement.	Un basculement est la redirection du trafic d'un système principal vers un système secondaire. Elastic Disaster Recovery vous aide à effectuer un basculement en lançant des instances de restauration sur AWS. Lorsque les instances de restauration ont été lancées, vous redirigez le trafic de vos systèmes principaux vers ces instances. Sur la console Elastic Disaster Recovery, ouvrez la page Serveurs source et vérifiez que la colonne Ready for recovery du serveur source indique Prêt et que la colonne État de réplication des données indique Healthy. Sélectionnez le serveur source. Dans le menu Initiate recovery job, sélectionnez Initiate recovery. Sélectionnez le point-in-time snapshot à partir duquel vous souhaitez lancer l'instance de restauration, puis choisissez Initiate recovery. Cela lance un travail de rétablissement. Vous pouvez surveiller l'état de la tâche sur la page Instances de restauration. Testez et vérifiez l'instance de restauration. Si nécessaire, ajustez la configuration DNS et connectez votre EnterpriseOne application JD Edwards à la base de données. Vous pouvez désormais déconnecter et mettre hors service le EnterpriseOne serveur JD Edwards source, car toutes les modifications ont été écrites dans la nouvelle instance de restauration. Enregistrez l'instance de restauration en tant que serveur source dans la région DR en suivant le processus décrit dans l'épique Installation de l'agent de réplication AWS. Pour plus d'informations, consultez la section Réalisation d'un basculement dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Lancez un retour en arrière.	Le processus de lancement d'un retour de secours est similaire au processus de lancement d'un basculement. Ouvrez la console Elastic Disaster Recovery dans la région principale. Accédez à la page Instances de restauration, sélectionnez l'instance de forage, puis choisissez Actions, Déconnexion d'AWS, Supprimer les instances de restauration. Ouvrez la console Elastic Disaster Recovery dans la région DR. Enregistrez votre nouveau EnterpriseOne serveur JD Edwards en tant que serveur source dans la région DR en installant l'agent de réplication AWS. Les données seront synchronisées avec un nouveau serveur de réplication configuré dans le nouveau sous-réseau intermédiaire. Note Lorsque le nouveau EnterpriseOne serveur JD Edwards est enregistré en tant que serveur source, vous pouvez voir deux serveurs sources apparaître dans la console Elastic Disaster Recovery : un serveur créé à partir de l' EC2 instance principale et le nouveau serveur créé à partir de l'instance de restauration. Nous vous recommandons de baliser correctement les serveurs pour éviter toute confusion et d'ajouter de préférence le nouveau serveur au modèle de lancement. Pour redémarrer la réplication DR depuis la région principale, dissociez l'instance de restauration lancée de la console Elastic Disaster Recovery dans la région DR et enregistrez l'hôte en tant que serveur source dans la région principale. Pour plus d'informations, consultez la section Réalisation d'un retour arrière dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Démarrez les EnterpriseOne composants JD Edwards.	Démarrez la EnterpriseOne base de données JD Edwards en vous connectant au serveur de base de données. Lorsque la base de données est en cours d'exécution, démarrez les serveurs EnterpriseOne logiques et de traitement par lots de JD Edwards. Commencez WebLogic sur les serveurs Web, puis démarrez une instance JAS sur les serveurs JAS. Commencez WebLogic sur le serveur de provisionnement et sur le serveur de la console SM. Démarrez SM Agent sur les serveurs. Vérifiez que la connexion à JD Edwards EnterpriseOne fonctionne correctement. Vous devrez intégrer les modifications dans Route 53 et Application Load Balancer pour que le EnterpriseOne lien JD Edwards fonctionne. Vous pouvez automatiser ces étapes à l'aide de Lambda, Step Functions et Systems Manager (Run Command). Note Elastic Disaster Recovery effectue une réplication au niveau des blocs des volumes EBS de l' EC2 instance source qui hébergent le système d'exploitation et les systèmes de fichiers. Les systèmes de fichiers partagés créés à l'aide d'Amazon EFS ne font pas partie de cette réplication. Vous pouvez répliquer des systèmes de fichiers partagés dans la région DR à l'aide d'AWS DataSync, comme indiqué dans le premier épisode, puis monter ces systèmes de fichiers répliqués dans le système DR.	J.D. Edwards EnterpriseOne CNC

Lancer le forage DR et le basculement

Tâche	Description	Compétences requises
Lancer un exercice	Sur la console Elastic Disaster Recovery, ouvrez la page Serveurs source et vérifiez que l'état du serveur source est Prêt. Sélectionnez tous les serveurs source pour lesquels vous souhaitez effectuer l'exercice DR. Dans le menu Initiate recovery job, choisissez Initiate drill et sélectionnez le point-in-time cliché approprié. Cela lance une tâche de restauration pour les serveurs source sélectionnés. Vous pouvez suivre l'état de la tâche dans l'onglet Historique des tâches de restauration. L'instance de forage lancée apparaît également sur la page Instances de restauration. Note Les modifications ultérieures apportées au serveur source seront synchronisées avec le serveur de réplication, et non avec l'instance de forage. Testez et vérifiez l'instance de forage DR. Sur la page Instances de restauration, sélectionnez l'instance de forage, puis choisissez Actions, Disconnect from AWS. Cela supprime l'agent de réplication AWS de l'instance de restauration et supprime toutes les ressources associées à l'instance de restauration d'Elastic Disaster Recovery. Choisissez Supprimer les instances de restauration. Cela supprime la représentation de l'instance de la console Elastic Disaster Recovery et dissocie complètement l'instance du service Elastic Disaster Recovery. Elle ne supprime pas l' EC2 instance sous-jacente. Mettez fin à l'instance DR Drill depuis la EC2 console Amazon. Pour plus d'informations, consultez la section Préparation au basculement dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Validez l'exercice.	À l'étape précédente, vous avez lancé de nouvelles instances cibles dans la région DR. Les instances cibles sont des répliques des serveurs sources basées sur le snapshot pris lorsque vous avez lancé le lancement. Dans cette procédure, vous vous connectez à vos machines EC2 cibles Amazon pour vérifier qu'elles fonctionnent comme prévu. Ouvrez la EC2 console Amazon. Choisissez Instances (en cours d'exécution). Sélectionnez l'instance cible et notez son IPv4 adresse privée. Assurez-vous que vous pouvez vous connecter à l' EC2 instance et que le JD Edwards EnterpriseOne et les composants associés sont répliqués comme prévu.
Lancez un basculement.	Un basculement est la redirection du trafic d'un système principal vers un système secondaire. Elastic Disaster Recovery vous aide à effectuer un basculement en lançant des instances de restauration sur AWS. Lorsque les instances de restauration ont été lancées, vous redirigez le trafic de vos systèmes principaux vers ces instances. Sur la console Elastic Disaster Recovery, ouvrez la page Serveurs source et vérifiez que la colonne Ready for recovery du serveur source indique Prêt et que la colonne État de réplication des données indique Healthy. Sélectionnez le serveur source. Dans le menu Initiate recovery job, sélectionnez Initiate recovery. Sélectionnez le point-in-time snapshot à partir duquel vous souhaitez lancer l'instance de restauration, puis choisissez Initiate recovery. Cela lance un travail de rétablissement. Vous pouvez surveiller l'état de la tâche sur la page Instances de restauration. Testez et vérifiez l'instance de restauration. Si nécessaire, ajustez la configuration DNS et connectez votre EnterpriseOne application JD Edwards à la base de données. Vous pouvez désormais déconnecter et mettre hors service le EnterpriseOne serveur JD Edwards source, car toutes les modifications ont été écrites dans la nouvelle instance de restauration. Enregistrez l'instance de restauration en tant que serveur source dans la région DR en suivant le processus décrit dans l'épique Installation de l'agent de réplication AWS. Pour plus d'informations, consultez la section Réalisation d'un basculement dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Lancez un retour en arrière.	Le processus de lancement d'un retour de secours est similaire au processus de lancement d'un basculement. Ouvrez la console Elastic Disaster Recovery dans la région principale. Accédez à la page Instances de restauration, sélectionnez l'instance de forage, puis choisissez Actions, Déconnexion d'AWS, Supprimer les instances de restauration. Ouvrez la console Elastic Disaster Recovery dans la région DR. Enregistrez votre nouveau EnterpriseOne serveur JD Edwards en tant que serveur source dans la région DR en installant l'agent de réplication AWS. Les données seront synchronisées avec un nouveau serveur de réplication configuré dans le nouveau sous-réseau intermédiaire. Note Lorsque le nouveau EnterpriseOne serveur JD Edwards est enregistré en tant que serveur source, vous pouvez voir deux serveurs sources apparaître dans la console Elastic Disaster Recovery : un serveur créé à partir de l' EC2 instance principale et le nouveau serveur créé à partir de l'instance de restauration. Nous vous recommandons de baliser correctement les serveurs pour éviter toute confusion et d'ajouter de préférence le nouveau serveur au modèle de lancement. Pour redémarrer la réplication DR depuis la région principale, dissociez l'instance de restauration lancée de la console Elastic Disaster Recovery dans la région DR et enregistrez l'hôte en tant que serveur source dans la région principale. Pour plus d'informations, consultez la section Réalisation d'un retour arrière dans la documentation d'Elastic Disaster Recovery.	Administrateur AWS
Démarrez les EnterpriseOne composants JD Edwards.	Démarrez la EnterpriseOne base de données JD Edwards en vous connectant au serveur de base de données. Lorsque la base de données est en cours d'exécution, démarrez les serveurs EnterpriseOne logiques et de traitement par lots de JD Edwards. Commencez WebLogic sur les serveurs Web, puis démarrez une instance JAS sur les serveurs JAS. Commencez WebLogic sur le serveur de provisionnement et sur le serveur de la console SM. Démarrez SM Agent sur les serveurs. Vérifiez que la connexion à JD Edwards EnterpriseOne fonctionne correctement. Vous devrez intégrer les modifications dans Route 53 et Application Load Balancer pour que le EnterpriseOne lien JD Edwards fonctionne. Vous pouvez automatiser ces étapes à l'aide de Lambda, Step Functions et Systems Manager (Run Command). Note Elastic Disaster Recovery effectue une réplication au niveau des blocs des volumes EBS de l' EC2 instance source qui hébergent le système d'exploitation et les systèmes de fichiers. Les systèmes de fichiers partagés créés à l'aide d'Amazon EFS ne font pas partie de cette réplication. Vous pouvez répliquer des systèmes de fichiers partagés dans la région DR à l'aide d'AWS DataSync, comme indiqué dans le premier épisode, puis monter ces systèmes de fichiers répliqués dans le système DR.	J.D. Edwards EnterpriseOne CNC

Résolution des problèmes

Problème	Solution
L'état de réplication des données du serveur source est bloqué et la réplication est retardée. Si vous vérifiez les détails, l'état de réplication des données indique que l'agent n'a pas été détecté.	Vérifiez que le serveur source bloqué fonctionne. Note En cas de panne du serveur source, le serveur de réplication est automatiquement arrêté. Pour plus d'informations sur les problèmes de retard, consultez la section Problèmes de retard de réplication dans la documentation d'Elastic Disaster Recovery.
L'installation d'AWS Replication Agent dans l' EC2 instance source échoue dans RHEL 8.2 après avoir scanné les disques. aws_replication_agent_installer.logrévèle que les en-têtes du noyau sont manquants.	Avant d'installer l'agent de réplication AWS sur RHEL 8, CentOS 8 ou Oracle Linux 8, exécutez : sudo yum install elfutils-libelf-devel Pour plus d'informations, consultez les exigences d'installation de Linux dans la documentation d'Elastic Disaster Recovery.
Sur la console Elastic Disaster Recovery, le serveur source indique que le serveur source est prêt avec un décalage et que l'état de réplication des données est bloqué. En fonction de la durée d'indisponibilité de l'agent de réplication AWS, le statut peut indiquer un retard important, mais le problème reste le même.	Utilisez une commande du système d'exploitation pour confirmer que l'agent de réplication AWS est en cours d'exécution dans l' EC2 instance source ou pour confirmer que l'instance est en cours d'exécution. Une fois les problèmes corrigés, Elastic Disaster Recovery reprendra l'analyse. Attendez que toutes les données soient synchronisées et que l'état de réplication soit sain avant de commencer un exercice de reprise après sinistre.
Réplication initiale avec un décalage élevé. Sur la console Elastic Disaster Recovery, vous pouvez constater que l'état de synchronisation initial est extrêmement lent pour un serveur source.	Vérifiez les problèmes de retard de réplication documentés dans la section Problèmes de retard de réplication de la documentation d'Elastic Disaster Recovery. Le serveur de réplication peut être incapable de gérer la charge en raison d'opérations de calcul intrinsèques. Dans ce cas, essayez de mettre à niveau le type d'instance après avoir consulté l'équipe du Support technique AWS.

Ressources connexes

• Guide de l'utilisateur d'AWS Elastic Disaster Recovery

• Création d'un plan de reprise après sinistre évolutif avec AWS Elastic Disaster Recovery (article de blog AWS)

• AWS Elastic Disaster Recovery : introduction technique (cours AWS Skill Builder ; connexion requise)

• Guide de démarrage rapide d'AWS Elastic Disaster Recovery