L’équipe de validation EMC a d’abord installé et validé l’environnement sans aucun schéma de protection de continuité d’activité ou de haute disponibilité.
Nous avons ensuite transformé l’environnement en la solution de continuité d’activité critique décrite dans le présent livre blanc. Nous avons effectué les tests suivants pour valider la solution et prouver l’élimination de tous les points de défaillance uniques de l’environnement :
• défaillance du processus du service de mise en file d’attente SAP ;
• défaillance de la machine virtuelle de l’instance SAP ASCS ;
• défaillance d’un nœud Oracle RAC ;
• panne de site ;
• isolement de cluster VPLEX.
Scénario de test
Ce scénario de test confirme que, si le processus du service de mise en file d’attente est défaillant, le cluster SUSE Linux Enterprise High Availability Extension promeut l’instance SAP ERS en une instance ASCS entièrement fonctionnelle et prend le relais de la table de verrouillage sans interruption pour l’utilisateur.
Pour tester ce scénario de panne, nous avons mis fin au processus de mise en file d’attente sur le nœud ASCS actif à l’aide de la commande kill :
kill -9 <process id>
Comportement du système
Le système répond à la défaillance du processus de service de mise en file d’attente comme suit :
1. L’agent de ressources SAPInstance détecte et rapporte la défaillance, comme l’illustre la Figure 54.
Figure 54. L’agent de ressources SAPInstance détecte et rapporte la défaillance Introduction
Défaillance du processus du service de mise en file d’attente SAP
2. L’agent de ressources maître/esclave promeut le nœud esclave précédent (SAPASCS1) en nœud maître, qui héberge les services ASCS, et démarre ERS en tant qu’esclave sur l’autre nœud (SAPASCS2) lorsqu’il réintègre le cluster (voir Figure 55).
Figure 55. L’agent de ressources maître/esclave bascule les nœuds maître et esclave
3. La table de verrouillage répliquée est restaurée, comme l’illustre la Figure 56.
Figure 56. Table de verrouillage répliquée restaurée Résultat
L’utilisateur ne remarque pas la défaillance du processus de mise en file d’attente, sauf si une opération de mise en file d’attente est en cours. Dans ce cas,
l’utilisateur rencontre des temps de réponse des transactions plus longs pendant le switchover. Les nouveaux utilisateurs peuvent se connecter au système
immédiatement après le switchover du serveur de messages. Aucune intervention de l’administrateur n’est requise.
EMC Mission-Critical Business Continuity for SAP 64 Scénario de test
Ce scénario de test confirme que, en cas de panne inattendue d’un serveur VMware ESXi (équivalente à une panne de machine virtuelle), le cluster High Availability Extension promeut l’instance SAP ERS en une instance ASCS entièrement fonctionnelle et prend le relais de la table de verrouillage, sans interruption pour l’utilisateur.
Pour tester ce scénario de panne, nous avons mis hors tension (via DRAC) le serveur VMware ESXi qui héberge la machine virtuelle de l’instance SAP ASCS.
Nous avons ensuite redémarré le serveur sans passer en mode Maintenance.
Comportement du système
Le système répond à la défaillance de la machine virtuelle comme suit :
1. SAPASCS2 n’est plus accessible à partir du client vSphere (voir Figure 57).
Figure 57. La machine virtuelle rencontre une panne
2. L’agent de ressources SAPInstance détecte et rapporte la défaillance (voir Figure 58).
Figure 58. L’agent de ressources SAPInstance détecte et rapporte la défaillance Défaillance de la
machine virtuelle de l’instance SAP ASCS
3. VMHA redémarre la machine virtuelle défaillante (SAPASCS2) sur l’hôte VMware ESXi resté actif (voir Figure 59).
Figure 59. VMHA redémarre la machine virtuelle défaillante
4. L’agent de ressources maître/esclave promeut le nœud esclave précédent (SAPASCS1) en nœud maître, qui héberge les services ASCS, et démarre ERS en tant qu’esclave sur l’autre nœud (SAPASCS2) lorsqu’il réintègre le cluster (voir Figure 60).
Figure 60. L’agent de ressources maître/esclave bascule les nœuds maître et esclave
EMC Mission-Critical Business Continuity for SAP 66 5. La table de verrouillage répliquée est restaurée (voir Figure 61).
Figure 61. Table de verrouillage répliquée restaurée Résultat
L’utilisateur ne remarque pas la défaillance du processus de mise en file d’attente, sauf si une opération de mise en file d’attente est en cours. Dans ce cas,
l’utilisateur rencontre des temps de réponse des transactions plus longs pendant le switchover. Les nouveaux utilisateurs peuvent se connecter au système
immédiatement après le switchover du serveur de messages. Aucune intervention de l’administrateur n’est requise.
Scénario de test
Ce scénario de test confirme que, en cas de défaillance inattendue d’un nœud Oracle RAC, les instances SAP se connectent automatiquement aux autres nœuds RAC. Les utilisateurs peuvent continuer leurs transactions sans interruption, sauf si les transactions qui ne sont pas écrites (au niveau de la base de données) sont exécutées sur le nœud RAC en échec.
Pour tester ce scénario de défaillance, nous avons redémarré le serveur afin de provoquer une défaillance du nœud Oracle.
Comportement du système
Le système répond à la défaillance du nœud RAC comme suit :
1. Le nœud RAC se déconnecte, et l’instance VSE003 n’est plus disponible, comme l’illustre la Figure 62.
oracle@sse-ea-erac-n01:~> srvctl status database -d VSE Instance VSE001 is running on node sse-ea-erac-n01 Instance VSE002 is running on node sse-ea-erac-n02 Instance VSE004 is running on node sse-ea-erac-n03 Instance VSE003 is not running on node sse-ea-erac-n04 Figure 62. Déconnexion du nœud RAC
Défaillance d’un nœud Oracle RAC
2. Le processus de travail de l’instance SAP se connecte à une autre instance RAC comme le montre la Figure 63.
.
Figure 63. L’instance SAP se connecte à un autre nœud RAC Résultat
L’utilisateur rencontre des temps de réponse des transactions plus longs lorsque le processus de travail de l’instance de dialogue se reconnecte à un autre nœud RAC. Les transactions qui n’ont pas été écrites sont restaurées au niveau de la base de données pour garantir la cohérence des données. L’utilisateur reçoit un message d’erreur système (vidage partiel) et doit redémarrer la transaction.
Aucune intervention de l’administrateur n’est requise.
Scénario de test
Ce scénario de test confirme que, en cas de panne du site entier, les nœuds RAC restés actifs préservent les opérations de bases de données.
Pour tester ce scénario de panne, nous avons simulé une panne complète du site A, y compris des composants du cluster VPLEX, du serveur VMware ESXi, du réseau et du nœud Oracle RAC. VPLEX Witness est resté disponible sur le site C.
Sur le site B, le cluster-2 VPLEX est resté en communication avec VPLEX Witness.
La Figure 64 présente l’état de l’environnement avant la panne du site.
Panne de site
EMC Mission-Critical Business Continuity for SAP 68 Figure 64. État de l’environnement avant la panne du site A
Comportement du système
Le système répond à la panne du site comme suit :
• Lors d’une panne du site A, VPLEX Witness garantit que la règle de déconnexion du groupe de cohérence, qui définit le cluster-1 comme le cluster favori, est remplacée et que le stockage accessible par le cluster-2 VPLEX sur le site B reste disponible.
• Les nœuds RAC sse-ea-erac-n03 et sse-ea-erac-n04 sur le site B restent disponibles.
• Lors d’une panne des serveurs VMware ESXi sur le site A, VMHA redémarre SAPASCS1 et SAPDI1 sur le site B. SAPASCS1 est redémarré sur un hôte VMware ESXi différent de SAPASCS2, comme le recommande la règle d’affinité VM-VM définie.
• SUSE Linux Enterprise High Availability Extension détecte la panne du nœud de cluster SAPASCS1. Étant donné qu’ERS était en cours d’exécution sur ce nœud, le cluster ne prend aucune mesure, sauf redémarrer ERS lorsque SAPASCS1 réintègre le cluster. La table de verrouillage est conservée et opérationnelle à tout moment.
• Les utilisateurs sur SAPDI1 perdent leurs sessions suite à la panne du serveur VMware ESXi. Au cours du processus de redémarrage, les nouveaux utilisateurs sont dirigés vers SAPDI2. Lorsque SAPDI1 redémarre sur le site B, les utilisateurs peuvent à nouveau se connecter à SAPDI1.
La Figure 64 présente l’état de l’environnement après la panne du site.
Figure 65. État de l’environnement après la panne du site A Résultat
Le Tableau 15 illustre les comportements attendus et constatés du système lors d’une panne du site A.
Tableau 15. Comportements attendus et constatés
Système État avant le
test
Comportement attendu
Comportement constaté Nœuds Oracle
RAC (base de données VSE)
sse-ea-erac-n01 (Site A) sse-ea-erac-n02 (Site A) sse-ea-erac-n03 (Site B) sse-ea-erac-n04 (Site B)
Disponible Disponible Disponible Disponible
Éjecté Éjecté Disponible Disponible
Éjecté Éjecté Disponible Disponible Serveur VMware
ESXi Machine virtuelle
sse-ea-r710a (Site A) SAPASCS1
sse-ea-r710b (Site A) SAPDI1
sse-ea-r710c (Site B) SAPDI2
sse-ea-r710d (Site B) SAPASCS2
Disponible Disponible Disponible Disponible Disponible Disponible Disponible Disponible
Non disponible VMHA redémarre le site B
Non disponible VMHA redémarre le site B
Disponible Disponible Disponible Disponible
Non disponible VMHA redémarre le site B
Non disponible VMHA redémarre le site B
Disponible Disponible Disponible Disponible Cluster VPLEX VPLEX1 – Site A – cluster-1
VPLEX2 – Site B – cluster-2
Disponible Disponible
Non disponible Disponible
Non disponible Disponible
EMC Mission-Critical Business Continuity for SAP 70
Système État avant le
test
Comportement attendu
Comportement constaté Services SAP Enqueue Replication Server
Serveur de mise en file d’attente/de messages
Disponible
Disponible
Non disponible SLE HAE redémarre après un
redémarrage sur le site B
Disponible
Non disponible SLE HAE redémarre après un
redémarrage sur le site B
Disponible
Scénario de test
Ce scénario de test confirme que, en cas d’isolement d’un cluster VPLEX, la base de données et les applications SAP continuent à fonctionner sur le site resté actif sans aucune interruption.
Pour tester ce scénario de panne, nous avons simulé l’isolement du cluster favori sur le site A, avec partition du réseau IP de gestion externe et du réseau de communication VPLEX WAN. Le réseau LAG reste disponible. VPLEX Witness reste disponible sur le site C. Sur le site B, le cluster-2 VPLEX reste en communication avec VPLEX Witness.
Comportement du système
Le système répond à l’isolement de cluster VPLEX comme suit :
• Lorsque le VPLEX est isolé sur le site A, VPLEX Witness garantit que la règle de déconnexion du groupe de cohérence, qui définit le cluster-1 comme le cluster favori, est remplacée et que le stockage accessible par le cluster-2 de VPLEX sur le site B reste disponible.
• Les nœuds RAC sse-ea-erac-n03 et sse-ea-erac-n04 du site B restent
disponibles, et les nœuds RAC sse-ea-erac-n01 et sse-ea-erac-n02 du site A sont éjectés.
• Les serveurs VMware ESXi du site A restent disponibles et les machines virtuelles SAPASCS1 et SAPDI1 restent actives grâce à l’utilisation de la connexion entre clusters haute disponibilité VPLEX Metro.
La Figure 64 présente l’état de l’environnement après l’isolement de VPLEX sur le site A.
Isolement de cluster VPLEX
Figure 66. État de l’environnement après l’isolement de VPLEX sur le site A Résultat
Le Tableau 16 présente les comportements attendus et constatés du système lorsque le VPLEX du site A est isolé.
Tableau 16. Comportements attendus et constatés
Système État avant le
test
Comportement attendu
Comportement constaté Nœuds Oracle
RAC (base de données VSE)
sse-ea-erac-n01 (Site A) sse-ea-erac-n02 (Site A) sse-ea-erac-n03 (Site B) sse-ea-erac-n04 (Site B)
Disponible Disponible Disponible Disponible
Éjecté Éjecté Disponible Disponible
Éjecté Éjecté Disponible Disponible Serveur VMware
ESXi Machine virtuelle
sse-ea-r710a (Site A) SAPASCS1
sse-ea-r710b (Site A) SAPDI1
sse-ea-r710c (Site B) SAPDI2
sse-ea-r710d (Site B) SAPASCS2
Disponible Disponible Disponible Disponible Disponible Disponible Disponible Disponible
Disponible Disponible Disponible Disponible Disponible Disponible Disponible Disponible
Disponible Disponible Disponible Disponible Disponible Disponible Disponible Disponible
EMC Mission-Critical Business Continuity for SAP 72
Système État avant le
test
Comportement attendu
Comportement constaté Cluster VPLEX VPLEX1 – Site A – cluster-1
VPLEX2 – Site B – cluster-2
Disponible Disponible
Non disponible Disponible
Non disponible Disponible Services SAP Enqueue Replication
Server
Serveur de mise en file d’attente/de messages
Disponible Disponible
Disponible Disponible
Disponible Disponible