Presentation Geoplex PRA Air france

Guide CICS du 03 Avril 2008
Mise en œuvre Geoplex dans le cadre d’un PRA Actif/Actif
Jerome VIGUIER
1
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
2
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
3
Applications principales sur Tls
 Régulation des vols
CICS DB2
Pas d’arrêt non planifié supérieur à 1H
 Fidélisation
CICS DB2
4
Applications principales sur Vilgénis
 Plan de vols
 Maintenance
IMS
CICS/Adabas
Pas d’arrêt non planifié supérieur à 1H
5
Configuration actuelle Tls
Tls1
Tls2
CBU
CBU
ICB
CF1
mqC*
mqA*
CicsA*
CicsC*
DB2A*
DB2C*
PROA
PROC
CF2
mqD*
mqB*
CicsB*
DB2B*
PROB
CicsD*
DB2D*
PROD
Activité transactionnelle en équilibrage de charge sur 4 partitions
de même pour batch léger
Back Up synchrone local pour les disques
6
Configuration actuelle Vilgénis
Vlg1
Vlg2
CBU
CBU
CF1
Production
IMS
ISC
CF2
Production Production
CICS
Batch
Adabas
Activité CICS limitée à une partition , Passage d’IMS en DataSharing en cours
7
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
8
Objectif de RTO
 1 heure pour les applications critiques
 Le RTO dépendra du type de sinistre
 Panne disque avec HYPERWSAP = 0
 Perte de site ?
9
Objectif de RPO
Objectif RPO = 0
 De base, la réplication synchrone des données n’est pas une protection totale contre la perte
de données
 Dans le cas de perte partielle de liens, au début d’un « sinistre » impliquant la perte de la baie
primaire, on peut avoir des problème de cohérence sur la copie secondaire
 Certaines données qui résident dans les structures CF ne sont pas répliquées sur DASD
(MQ Shared Queues)
 Elles sont actuellement protégées par SMSD entre les deux Machines
10
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
11
Comment minimiser le RTO
 RTO
Garder l’architecture workload en actif/actif sur les 2 Machines en Full DataSharing
Protection contre les pannes de Machines, et les interruptions planifiées sur les Systèmes et les
Machines
HyperSwap
Protection contre les pannes des Disk subsystems et les interruptions planifiées
Protection des Lock Structure
Utilisation de SMSD si possible (limitation par la distance entre les deux CFs)
Ou évaluer l’utilisation de CF externes (pour se protéger de panne Machine)
- Gain sur RTO, en évitant un Global Restart de DB2
Protection des données dans les Structures CF
MQ - par SMSD si possible (Le Logging a un effet sur le RTO, temps de Recovery)
DB2 - GBPs par User Managed Duplexing (peu d’impact du à la distance) pour éviter GRECP
Automatisation et tests des Procédures de Recovery
Impact direct sur le RTO - Réduction des interventions opérateurs au minimum
L’éducation des opérateurs sur ces procédures est fondamental
Optimisation des Processus de Recovery
En priorisant les applications critiques dans le processus de recovery
12
Comment minimiser le RPO
 RPO
 Automatisation du « Freeze » en cas de panne des éléments de la réplication
 CGROUP FREEZE
 Pour avoir toujours une copie secondaire cohérente
 Protection des données dans les structures CF
 MQ par SMSD ou logging
 GBPs DB2 par User Managed Duplexing
 Les données sur bande sont écrites en double
 Mais il y a un risque de perte de données.
 Donc, les données vitales ne doivent pas être écrites sur Tape ou VSM
13
Configurations possibles
 OBJECTIF :
« Architecture des travaux en mode actif/actif sur deux 2 Machines en Full
DataSharing »
 Multi Sites Workload
 Single Site Workload
14
Multi Site Workload
Actif – Actif éloigné avec réplication synchrone
> Configuration cible nominale :
 Sysplex :
•
TLSPLEX
TLSDEVL
SYSPLEXA
•
•
•
•
Configuration similaire à actuellement (sauf
liaisons inter sites : ISC, Timers, FICON, FC,
ESCON)
Connectique symétrique (Hyperswap)
Impact de la distance : voir étude CF plus
loin
Un des sysplex doit représenter plus de 50%
de la consommation zOS totale de chaque
serveur (règles d’agrégation)
System Managed Structure Duplexing
 GDPS
•
•
GDPS/HM minimum pour cohérence
GDPS Complet si RTO < 2 heures et support
« CF Hint => voir plus loin)
• Hyperswap activé pour RPO = 0
 Disques
•
Disques modernes avec TR < 5 ms
supportant Hyperswap (Tagmastore ou
DS8000)
• Espaces de travail pour sauvegardes
symétriques
• Impact de la distance à déterminer avec
fournisseur (modélisation)
Impact de la distance sur les requêtes CF et PPRC
15
Single Site Workload
Actif – actif local + site passif, avec réplication synchrone
> Configuration cible nominale :
 Sysplex :
TLSPLEX
TLSDEVL
SYSPLEXA
•
•
•
Connectique symétrique (Hyperswap)
Impact de la distance : faible pour les CF
Un des sysplex doit représenter plus de 50%
de la consommation z/OS totale de chaque
serveur (règles d’agrégation)
• System Managed Structure Duplexing
CBU
SYSPLEXA
 GDPS
•
•
•
GDPS / HM minimum pour cohérence
GDPS Complet si RTO < 2 heures
Hyper swap activé pour RPO = 0
 Disques
•
Disques modernes avec TR < 5 ms
supportant Hyperswap (Tagmastore ou
DS8000)
• Espaces de travail pour sauvegardes
symétriques
• Impact de la distance à déterminer avec
fournisseur
Impact de la distance sur les requêtes PPRC uniquement
16
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
17
Choix de la solution
La solution « Multi Site Workload » est la plus économique et la plus proche de nos objectifs de RTO
 L’impact de la distance pour les requêtes Sysplex doit être testé
Le temps de réponse SYNC (local) est de 20 µs
L’effet de la distance ajoute 200µs ( donc X11)
Il y a peu de références de Multi Site Workload à 10 km
 L’impact de la distance pour les requêtes PPRC ne sera pas testé
Le temps de réponse DASD est de 4 ms
L’effet de la distance ajoute 200µs (+5%)
Il y a beaucoup de références en PPRC à10km
 Modélisation benchmark ou test sur site?
Les liens entre applications sur des plate formes et sites différents, rendent impossible l’extraction d’une partie du
SI représentative de l’activité.
De même la variété de l’activité rend impossible sa modélisation
4 ISC sont disponibles sur nos machines pour le rajout de bobines (coexistence possible auprès des 4 ICBs
existants)
 Décision : Test sur site
18
Test Bobine(1)
 Dernier Trimestre 2006
 Bobines de 10 kilomètres installées entre les deux Machines
 Les liens 10 kilomètres ont été utilisés le le Sysplex de Production, dans la même CU sur les 4 liens ICB
existants
4 liens ICB UC« actuels »
Machine1
Machine2
DWDM
Bobine
10km
DWDM
 Pour les tests, les liens ICBs sont configurés OFFLINE
 Pendant les tests, en cas d’impact sur le temps de réponse de l’applicatif, les liens ICBs sont configurés
ONLINE (1 minute)
 Cette méthode rend le test possible en production pour en toute sécurité pour l’exploitation
19
Test Bobine(2)
 Définition de périodes de tests représentatives de l’activité
Pour le transactionnel et le batch
 Établissement d’un référentiel 0km
Définition des métriques
Temps de réponse & écart type
 Mise en action des bobines pendant ces périodes sous forte surveillance
Surveillance en direct
Appels utilisateurs, & outils de monitoring
Analyse à posteriori via la métrologie de la dégradation
 Actions prises au cours du test
- Augmentation des tailles de structure
- Rajout de liens ISCs
Sur dégradation (Path Busy conditions)
- Test d’ajout de processeur de coupling
Impact du traitement en // des requêtes de coupling
- Duplexing des structures de Lock
IMS (sur nuit batch) DB2
Au début strict respect des périodes, puis devant le faible impact, bobines actives 24/24
20
Test Bobine(3)
 Conclusion:
 L’impact sur les applications est acceptable:
 +15% sur les temps de réponse des transactions CICS
 Impact sur les BATCH critiques acceptable aussi
L’architecture « Multi Sites workload » peut être mise en oeuvre
Recommandations d’IBM sur la taille de certaines structures CF, nombre de liens ISC et nombre de moteurs dans les CF
21
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
22
GDPS
 Les Bénéfices de GDPS
 HyperSwap
Bascule dynamique du Primary disk subsystem vers le Secondary disk subsystem.
 Freeze automation
Quand un problème de réplication est détecté, une commande “CGROUP FREEZE” est passée sur la
configuration PPRC
Ceci permet d’
cohérente
d’avoir une copie toujours cohé
 Automatisation des Procédures de Recovery
Basées sur un « Scripting language »
Activation des CBU
Reconfiguration des Ssysplex Policies et Couple Dataset
Reconfiguration des IPL Parms
Etc….
 L’automatisation des Procé
Procédures de Recovery est la meilleure garantie pour avoir un RTO MINIMUM
 Elle doivent être testé
testées
23
AGENDA
 PRESENTATION DE LA CONFIGURATION ACTUELLE
 OBJECTIFS DE RTO ET RPO POUR AIR FRANCE
 SOLUTIONS ENVISAGEES
 SOLUTION CHOISIE
 GDPS
 CONFIGURATION CIBLE
24
Projet de configuration Cible
Tls1
Production GDPS
STP
STP
PRO3
PRO2
M0TR
M0TP
MQ sq DB2 GBP
Lock
SMSD
Tls3
DEV1
M0TF
SMSD?
Test GDPS
Tls2
Lock
MQ sq DB2 GBP
STP
UMD
25
Projet de configuration Cible
 Workload multi site
 1 Machine sur chaque site
 1 CF Externe sur le site primaire
 Séparation totale des données entre le GDPS Test et le GDPS Production
 Lock structure dans le CF externe
 GBP en User Managed Duplexed
 Les MQ Shared Queues en SMSD à 10 km
La question est: quel est le mieux dans notre utilisation entre le Duplexing et le Logging?
Messages Asynchrones
Coexistence des 2 modes?
 2 Licences GDPS (Full Option)
Production
Test
Développement, Système
Utilisé pour les opérations régulières d’entraînement
26