Basculement de site et récupération

Un basculement de site est requis si votre infrastructure a subi un événement imprévu qui rend le site principal indisponible et complètement inaccessible pendant une durée qui aura un impact négatif sur l'entreprise. Dans ce scénario, la base de données de secours prend le rôle principal.

Un site principal peut devenir indisponible pour diverses raisons, y compris, mais sans s'y limiter, les suivantes :

Problèmes susceptibles de faire en sorte que les instances de la base de données principale ne démarrent pas, tels qu'un média défaillant ou fortement endommagé, ou une mise à niveau incorrecte du système d'exploitation ou du microprogramme
Défaillance de l'infrastructure, telle qu'une panne complète du système d'alimentation ou de refroidissement au sein de l'infrastructure de la région OCI
Echecs réseau complets
Catastrophes naturelles telles que tremblements de terre, incendies et inondations

Bien que les événements imprévus soient rares, ils peuvent et peuvent se produire.

Exécuter un basculement de site

Comme un vrai basculement est perturbateur et peut entraîner une petite perte de données, testez le basculement de votre site dans un environnement TEST.

L'exemple suivant utilise les noms de notre environnement de test pour la base de données principale dans Ashburn (CDBHCM_iad1dx) et la base de données de secours dans Phoenix (CDBHCM_phx5s).

Forcer l'arrêt de toutes les instances de base de données Oracle Real Application Clusters (Oracle RAC) sur la base de données principale.

Remarques :
N'effectuez pas ce test dans un environnement de production.
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
À partir de ce moment, notre primaire est supposé (simulé) être complètement indisponible. Nous ferons de notre région secondaire notre nouveau site principal.
Les étapes suivantes utilisent notre implémentation de test et toutes les étapes sont effectuées sur le site secondaire (nouveau site principal).

Sur le site secondaire, connectez-vous à l'un des services Oracle Exadata Database Service on Dedicated Infrastructure domUs, devenez l'utilisateur du système d'exploitation oracle et appelez l'interface de ligne de commande du broker Data Guard.

Noeud : un Oracle Exadata Database Service on Dedicated Infrastructure domU
Utilisateur : oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

Notez l'erreur.

Effectuez un basculement à l'aide de l'interface de ligne de commande d'Oracle Data Guard Broker.
- Noeud : un noeud Oracle Exadata Database Service on Dedicated Infrastructure domU sur le site secondaire
- Utilisateur : oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
Si les niveaux intermédiaires principaux (y compris le système de fichiers partagé) sont toujours intacts, effectuez manuellement une opération rsync "forcée" à partir du site principal défaillant vers le site de récupération après sinistre.

Les niveaux application et Web peuvent toujours être fonctionnels, mais les processus de l'application et de l'Ordonnanceur de traitements commenceront à échouer lors de la tentative de connexion à la base de données en échec. Le script rsync cesse alors d'exécuter rsync.
- Noeud : un niveau intermédiaire, site principal en échec
- Utilisateur : psadm2
1. Exécutez une commande rsync forcée. Un exemple de script rsync_psft.sh est disponible dans le répertoire des scripts.
  Si le script rsync est désactivé, le paramètre -f vous invite à poursuivre avec un fichier rsync forcé. Une commande rsync forcée ne consulte pas la base de données pour déterminer le rôle du site, puis exécute la commande rsync demandée.
  
  Remarques :
  Cela ne doit être fait que lorsque vous forcez une actualisation finale lors d'un basculement de site. L'utilisation de l'option FORCE est consignée.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Exemple :
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Surveillez le journal de processus rsync pour vérifier que le processus s'est terminé correctement.
Si l'échec du site est terminé et qu'un processus rsync final ne peut pas être exécuté, désactivez rsync au niveau de la nouvelle instance principale en exécutant le script disable_psft_rsync.sh.
- Noeud : un niveau intermédiaire, nouveau site principal
- Utilisateur : psadm2
```
disable_psft_rsync.sh
```
Si vous avez configuré la prise en charge d'Active Data Guard lorsque vous avez configuré les serveurs de base de données principale et de secours, assurez-vous que le service Active Data Guard pour PeopleSoft (PSQUERY) a démarré sur la nouvelle base de données principale.
- Noeud : un noeud Oracle Exadata Database Service on Dedicated Infrastructure domU sur le site secondaire
- Utilisateur : oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
Ce service doit être en cours d'exécution sur toutes les instances Oracle Real Application Clusters (Oracle RAC).

Remarques :
Ce service doit être démarré avant de démarrer l'Ordonnanceur de traitements. Sinon, l'ordonnanceur de traitements échouera au démarrage.
Vérifiez que les services de base de données basés sur les rôles fonctionnent sur la nouvelle base principale.
- Site : Site 2
- Noeud : tous les Oracle Exadata Database Service on Dedicated Infrastructure domUs
- Utilisateur : oracle
Par exemple, exécutez la commande suivante sur chaque instance domU hébergeant une instance de base de données Oracle RAC PeopleSoft :
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
Ce service doit être en cours d'exécution sur toutes les instances Oracle RAC.

Démarrez le serveur d'applications et les domaines de l'Ordonnanceur de traitements.

Site : Site 2
Noeud : instances de calcul du serveur de l'Ordonnanceur de traitements et de l'application
Utilisateur : psadm2

Connectez-vous aux instances de calcul hébergeant les serveurs d'applications et l'ordonnanceur de traitements PeopleSoft et devenez psadm2.
Utilisez le script startPSFTAPP.sh du répertoire Wrapper dans GitHub.
```
$ startPSFTAPP.sh
```

Surveillez le démarrage.

Vous pouvez utiliser la requête à partir des domaines d'application et de Process Scheduler PeopleSoft.

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

Si vous n'avez pas rencontré de défaillance complète du site comme décrit à l'étape 5, passez à l'étape suivante. En cas d'échec complet du site, vous devez réexécuter le script disable_psft_rsync.sh, car le script startPSTAPP.sh activera rsync.
Remarques :

En cas de panne réelle où le site principal est perdu ou devient inaccessible, vous devrez effectuer une évaluation de la portée et de l'impact. Voici quelques points à prendre en considération :
- Perte de données de base de données possible
- Artefacts de système de fichiers manquants (rapports, journaux, fichiers entrants et sortants, etc.)
Selon la panne, vous pouvez ou non récupérer toutes les transactions validées sur la base principale d'origine. Si possible, demandez aux utilisateurs de vérifier les toutes dernières transactions sur lesquelles ils travaillaient.

Il est probable qu'il manque des artefacts de système de fichiers, à partir de la sortie en cours d'écriture ou de transmission lorsque l'accès au principal d'origine cesse. Utilisez la journalisation des rapports dans la base de données pour identifier les artefacts de système de fichiers créés près du moment de la coupure, puis déterminez ce qui doit être fait, au cas par cas, pour les fichiers manquants ou incomplets.
Démarrez les services Web.
- Site : Site 2
- Noeud : toutes les instances de calcul de serveur Web PIA (Internet Architecture) PeopleSoft
- Utilisateur : psadm2
Si Coherence*Web est configuré, vous démarrez d'abord le cluster de cache sur toutes les instances de calcul qui hébergent les serveurs Web PIA, puis les serveurs Web PIA. Dans cet exemple, un script est utilisé pour démarrer les deux dans l'ordre approprié.
1. Connectez-vous aux serveurs Web PIA et devenez psadm2.
2. A l'aide du script de startPSFTAPP.sh, démarrez les serveurs Web.
```
$ startPSFTWEB.sh
```
Vérifiez l'équilibreur de charge.
- Site : Région Site 2
- Noeud : console OCI
- Utilisateur : administrateur de location
1. Connectez-vous à la console OCI et remplacez la région par votre nouvelle région principale.
2. Sélectionnez Fonctions de réseau, puis Equilibreur de charge dans le menu principal.
3. Sélectionnez le compartiment approprié.
4. Cliquez sur Ensemble de back-ends, puis sur Back-ends.
  Chaque back-end doit afficher OK. Cela peut prendre quelques minutes après le démarrage de chaque serveur Web PIA.

Rétablissement de la base de données principale en échec en tant que nouvelle base de données de secours

Vous devez protéger votre nouvel environnement de production avec une base de données de secours. Dans l'idéal, vous pourrez rétablir la base principale défaillante en tant que nouvelle base de données de secours en rétablissant à la fois la base de données et les systèmes de fichiers.

Rétablir l'ancienne base principale en tant que base de secours

Oracle Data Guard empêche l'ancienne base de données principale de s'ouvrir lorsqu'elle est à nouveau disponible après une panne de site principal. Toute tentative de démarrage normal de la base de données échouera, avec des messages écrits dans son journal d'alertes indiquant que le rétablissement est requis. Si Flashback Database a été activé sur cette base de données avant l'échec, vous pouvez rétablir l'ancienne base principale en tant que nouvelle base de données de secours.

Effectuez les opérations suivantes pour rétablir l'ancienne base principale en tant que base de données de secours de la production actuelle :

Connectez-vous à l'une des adresses domUs hébergeant l'ancienne base de données principale et démarrez la base de données :
```
$ srvctl start database -db CDBHCM_phx5s
```

Connectez-vous à l'interface de ligne de commande de Data Guard Broker dans la nouvelle région principale et affichez la configuration.

Notez l'erreur ORA-16661 en gras ci-dessous.

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

Rétablissez la base de données de secours.
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
Remarques :
Le processus de récupération de la base de données en échec et de démarrage d'une base de données de secours valide peut prendre un certain temps.
Utilisez l'interface de ligne de commande de Data Guard Broker pour vérifier le statut de votre environnement.
Exemple :
```
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)
```
La base de données rétablie sert désormais de base de données de secours, protégeant la base principale et disponible pour la permutation et le basculement.

Si vous avez configuré la prise en charge d'Active Data Guard lorsque vous avez configuré les serveurs de base de données principale et de secours, le service Active Data Guard pour PeopleSoft (PSQUERY) peut être transféré de la base de données principale vers la base de données de secours.

Rétablir les anciens niveaux intermédiaires principaux en tant que niveaux de secours

Rétablissez les anciens niveaux intermédiaires principaux en fonction de votre événement de basculement.

Si vos anciens serveurs de niveau intermédiaire principal sont restés disponibles pendant que l'événement de basculement de base de données s'est produit, vous auriez dû effectuer une opération rsync forcée finale du site principal en panne vers la base de données de secours au moment de la panne, puis inverser la direction des processus rsync de la même manière que lorsque vous effectuez une permutation.

Les niveaux application et Web peuvent toujours être fonctionnels, mais les processus de l'application et de l'Ordonnanceur de traitements commenceront à échouer lors de la tentative de connexion à la base de données en échec. Le script rsync cesse alors d'exécuter rsync.
1. Si les niveaux intermédiaires principaux, y compris le système de fichiers partagé, sont toujours intacts, effectuez manuellement une resynchronisation "forcée" entre le site principal défaillant et le site de récupération après sinistre.
  Si le script rsync est désactivé, le paramètre -f vous invite à poursuivre avec une commande rsync forcée. Une rsync forcée ne consultera pas la base de données pour déterminer le rôle du site, puis effectuera la rsync demandée.
  
  Remarques :
  Cela ne doit être fait que lorsque vous forcez une actualisation finale lors d'un basculement de site. L'utilisation de l'option FORCE sera consignée.
  
  Vous pouvez utiliser l'exemple de script dans le répertoire de scripts rsync_psft.sh, en tant qu'utilisateur psadm2 :
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Exemple :
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Surveillez le journal de processus rsync pour vérifier que le processus s'est terminé correctement.
Si l'ancien site principal est complètement inaccessible, même pour rsync, effectuez les opérations suivantes :
1. Désactivez les scripts rsync sur le nouveau site principal avec disable_psft_rsync.sh pour tous les systèmes de fichiers en cours de réplication.
2. Si vous pouvez reprendre l'activité sur les niveaux intermédiaires d'origine ultérieurement, réactivez les scripts rsync et laissez-les rattraper.
Si vous devez reconstruire les niveaux intermédiaires, suivez les processus décrits précédemment.