Basculement et récupération de site

Un basculement de site est requis si votre infrastructure a subi un événement non planifié qui entraîne l'indisponibilité du site principal et l'inaccessibilité totale pendant une durée qui aura une incidence négative sur l'entreprise. Dans ce scénario, la base de secours prend le rôle de base principale.

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

Problèmes qui peuvent empêcher le démarrage des instances de base de données principale, tels qu'un média en échec ou fortement corrompu, ou une mise à niveau défectueuse du système d'exploitation ou du micrologiciel
Défaillance de l'infrastructure telle qu'une panne complète du système d'alimentation ou de refroidissement dans l'infrastructure de la région OCI
Défaillances de réseau complètes
Catastrophes naturelles comme les tremblements de terre, les incendies et les inondations

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

Effectuer un basculement de site

Comme un véritable 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 Oracle Real Application Clusters (Oracle RAC) de base de données sur l'instance principale.

Note :
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 mise en œuvre de test et toutes les étapes sont effectuées sur le site secondaire (nouveau primaire).

At the secondary site, log in to any one of the Oracle Exadata Database Service on Dedicated Infrastructure domUs, become the oracle OS user, and invoke the Data Guard Broker command-line interface.

Node: One 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 en cas de panne à l'aide de l'interface de ligne de commande d'Oracle Data Guard Broker.
- Node: One Oracle Exadata Database Service on Dedicated Infrastructure domU at the secondary site
- 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 "forcée" rsync du site principal en échec vers le site de récupération après sinistre.

L'application et les niveaux Web peuvent toujours être fonctionnels, mais les processus de l'application et du Répartiteur de traitements commenceront à échouer en essayant de se connecter à la base de données défaillante. Le script rsync cessera d'exécuter rsync.
- Noeud : Un niveau intermédiaire, site principal en échec
- Utilisateur : psadm2
1. Effectuez une opération 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 invite à continuer avec une valeur rsync forcée. Un rsync forcé ne consulte pas la base de données pour déterminer le rôle du site, puis effectue le rsync demandé.
  
  Note :
  Cette opération ne doit être effectuée que lors d'une actualisation finale lors d'un basculement de site. L'utilisation de l'option FORCE est enregistrée.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Par exemple,
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Surveillez le journal de processus rsync pour vérifier que le processus s'est terminé avec succès.
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é vos 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.
- Node: One Oracle Exadata Database Service on Dedicated Infrastructure domU at the secondary site
- Utilisateur : oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
Ce service doit être exécuté sur toutes les instances Oracle Real Application Clusters (Oracle RAC).

Note :
Ce service doit être démarré avant le démarrage du Répartiteur de traitements. Sinon, le répartiteur de traitements échouera au démarrage.
Vérifiez que les services de base de données basés sur les rôles sont actifs sur la nouvelle base principale.
- Site : Site 2
- Node: All Oracle Exadata Database Service on Dedicated Infrastructure domUs
- Utilisateur : oracle
Par exemple, exécutez la commande suivante sur chaque 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 s'exécuter sur toutes les instances Oracle RAC.

Démarrez le serveur d'applications et les domaines du Répartiteur de traitements.

Site : Site 2
Noeud : Instances de calcul du serveur du programmateur d'applications et de processus
Utilisateur : psadm2

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

Surveillez le démarrage.

Vous pouvez utiliser l'interrogation à partir des domaines d'application et de Répartiteur de traitements 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 eu de défaillance complète du site, comme décrit à l'étape 5, passez à l'étape suivante. Si vous avez subi une défaillance complète du site, vous devez réexécuter le script disable_psft_rsync.sh, car le script startPSTAPP.sh activera rsync.
Note :

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

Il est probable qu'il y aura des artefacts de système de fichiers manquants, de la sortie en cours d'écriture ou de transmission lorsque l'accès à la principale d'origine cessera. Utilisez la journalisation de rapport dans la base de données pour identifier les artefacts de système de fichiers créés près du moment de l'interruption, puis déterminez ce qui doit être fait, 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émarrerez 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. À 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 Réseau, puis Équilibreur de charge dans le menu principal.
3. Sélectionnez le compartiment approprié.
4. Cliquez sur Jeu dorsal, puis sur Serveurs dorsaux.
  Chaque serveur dorsal doit afficher OK. Cela peut prendre quelques minutes après le démarrage de chaque serveur Web PIA.

Rétablir la base principale en échec en tant que nouvelle base de secours

Vous voulez protéger votre nouvel environnement de production avec une base de secours. Idéalement, vous pourrez rétablir la base principale défaillante en tant que nouvelle base 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êchera l'ouverture de l'ancienne base de données principale lorsqu'elle sera de nouveau disponible après une défaillance du site principal. Toute tentative de démarrage normal de la base de données échoue, avec des messages écrits dans son journal d'alertes indiquant qu'une remise en service est requise. 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 secours.

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

Connectez-vous à l'un des 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)

Remettre en service la base de secours.
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
Note :
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.
Par 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 secours, protégeant la base principale et la base disponible pour la permutation et le basculement.

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

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

Remettre en service 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 échec vers la base de secours au moment de l'échec, puis inverser la direction des processus rsync de la même manière que lors d'une permutation.

L'application et les niveaux Web peuvent toujours être fonctionnels, mais les processus de l'application et du Répartiteur de traitements commenceront à échouer en essayant de se connecter à la base de données défaillante. Le script rsync cessera d'effectuer la synchronisation.
1. Si les niveaux intermédiaires principaux, y compris le système de fichiers partagé, sont toujours intacts, effectuez manuellement une synchronisation "forcée" du site principal en échec vers le site de récupération après sinistre.
  Si le script rsync est désactivé, le paramètre -f invite à continuer avec une valeur rsync forcée. Une synchronisation forcée ne consultera pas la base de données pour déterminer le rôle du site, puis effectuera la synchronisation demandée.
  
  Note :
  Cette opération ne doit être effectuée que lors d'une actualisation finale lors d'un basculement de site. L'utilisation de l'option FORCE sera enregistré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
```
  Par exemple,
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Surveillez le journal de processus rsync pour vérifier que le processus s'est terminé avec succès.
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 initiaux 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.