Université IBM i 2019 - 22 mai IBM Client Center Paris S07 -Technologies de réplication sur IBM i - Université ...
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Université IBM i 2019 22 mai IBM Client Center Paris S07 -Technologies de réplication sur IBM i Benoît MASSIET du BIEST ACMI bmassiet@acmi.fr
Agenda Les solutions se valent-
elles ?
Quelles sont les réelles
differences ?
• Le concept de résilience
• Les différences techniques entre réplication matérielle Que faire pour
être certain
et réplication fondée sur la journalisation Sur Site ou dans le d’être protégé ?
Cloud ?
• Les différences pratiques Comment choisir ?
• Considération concernant les topologies possibles
(Cloud ?)
• Questions à se poser ?
Objectifs de reprise (RTO and RPO)
Arrêt
Jours Heures Mns Secs Mns Heures Jours Semaine
Past Present Future
Recovery Point Objective Recovery Time Objective
Sauvegarde
Journalisation
Réplication
données
Restauration
Journal Reprise
Apply manuelle des
Clusters transactions
Objectifs de la Haute Disponibilité ?
• Couvrir les risques identifiables :
• Panne matérielle
• Panne logicielle
• Erreurs Humaines, malveillances, grèves
• Alimentation électrique, Télécom, Réseau,
• Risques naturels, ou risques sur le bâtiment / Datacenter
• Garantir un temps de reprise (RTO)
• Garantir un point de reprise (RPO) et l’intégrité des données
• Couvrir les arrêts planifiés et les opérations de maintenance
• Permettre d’accroitre le temps de service IT (disponibilité)
Réplication matérielle
ou réplication logicielle ?
Le Power i : un serveur pas comme les autres.
Single Level Store :
l’espace adressable unique
IBM i
Address Espace adresse
Mémoire
Single Level Storage
Les données sont tenues en
Stockage mémoire le plus longtemps
possible pour augmenter la
performance.
Les adresses des données sur
disques sont tenues à jour par
le système et ne sont pas
visibles pour l’utilisateur
System i : Performance et
écritures disques
IBM i MEMORY
Disk Array Les données sont
tenues en mémoire le
plus longtemps
possible pour
augmenter la
performance
= changed data
IBM i Journalisation IBM i
System A System B
System System
Memory Memory
Data
Data change
to journal first
Database Database
Local Journal Remote Journal
Local Journal Remote Journal
Receiver ReceiverFonctions de protection
et résilience sur IBM i
• Les protections disques : Mirroring, Raid 5, 6, 10
• La journalisation *Both, le commitment control
• La journalisation distante (V4R2, 1999)
• smapp : System managed access-path protection
• Le journal minimum data, la compression OS
• Le journal caching (Option 42)
• La journalisation implicite
• Les iASP et les “clustering administratives domains”
• Et son application avec l’option 41 : XSM Power HA
• La fonction Quiesce (V6R1)
• Les API cluster
• Et ... en 2019 : Db2 Mirror for i (5770-DBM)Considérations Technologiques
Comment peser les 1. Les architectures
options possibles 2. Réplication temps réel et point de reprise
3. Consommation de bande passante
4. Secours actif ou Off-line
5. Exigences des applications et des données
6. Intégrité des objets / objets corrompus ou
endommagés
7. Flexibilité des topologie possibleNiveaux de réplication
DB2 Mirror* V7R4
Logiciel réplication
Geographic Mirror
Global MirrorArchitecture sous jacente
Réplication du stockage Réplication logicielle
SAN SAN
Server Server
• Mécanismes de mirroring integrés de SAN à SAN. • Réplication par envoi en temps réel des postes de
• Réplication par secteurs de LUN ou blocs journaux (fichiers) et des entrées dans l’audit
journal (objets).
• iASP
• Les deux serveurs sont en miroir
• Les données cible ne sont pas accessibles
• Indépendants actifs, les données sont accessibles.
• Basculement = Vary on + Récupération des
données par ce serveur de secours et IPL selon les • Supporte toutes les architectures matérielles
cas • Le basculement consiste à activer le réseau et les
utilisateurs sur le serveur cible, pas d’IPLDilemne : Intégrité des transactions
Quand la donnée est-elle écrite sur disque?
Espace adresse
1. Le storage manager libère la
mémoire selon un algorithme
interne
Memoire 2. La donnée est maintenue en
Pagination mémoire pour augmenter les
performances
3. La journalisation copie les données
modifies sur disque
4. Fermer un fichier force son
Stockage écriture sur disque
5. Le parameter de force write ration
Réplication peut forcer l’écriture sur disque
San
La protection commence lorsque la page est écrite sur disqueRéplication et point de reprise
Réplication du stockage Réplication logicielle
• L’OS utilise la mémoire comme une partie de l’espace • La journalisation élimine les problèmes liés aux
de données
• Les données sont soit en mémoire soit sur disque écritures disques ou mémoire
• Seules les données/objets sur disque sont protégées, • Le poste de journal est répliqué en temps réel
• Les données restant en mémoire sont perdues avant l’écriture dans la base de données source
• Le RPO est imprévisible • Le réplication synchrone ou asynchrone
• La journalisation est requise pour récupérer les garantissent un RPO proche de zéro
données perdues.
• Les mécanismes de récupération rendent le RTO • Pas de mécanisme de récupération, le RTO est
imprévisible rapide.
No memory to memory
Server Journal Entries Server
Server transfer
Server
Disk sectors Storage Storage
Storage StorageBesoin en bande passante
Serveur Production Serveur Secours
SAN SAN
IASP IASP
Copie du
journal
DB DB
Secteurs modifiés
Journal journal
Local copié
IASP IASP
Le besoin en bande passante est au minimum doubléBesoin en bande passante
Réplication du stockage Réplication logicielle
Sector Replication Logical Replication
Server Server objects Server
Server
data
journals
SAN SAN
• La bande passante nécessaire minimum x2 • La journalisation réplique uniquement les
• Réplication par blocs de Luns + copie des entrées changement sur les données ou les objets
des journaux eventuels • La bande passante peut être encore réduite par
filtrage des données non nécessaires, ou par le
• La synchronisation initiale et les processus de JRNMINDTA (Option 42 – Performance Journal
resynchronisation réclament également beaucoup HA) ou une compression OS (LZ 9, 10 ou 12)
de bande passanteServeur cible Online ou Offline
Réplication du stockage Réplication logicielle
• Pas d’accès aux données de l’IASP distant • Le serveur cible est toujours à jour et actif
• Basculement = vary on de l’IASP distant • Le serveur cible utile pour :
• Flashcopy possible mais : Reporting,
• Seules les données écrites sur disques sauf si DW, BI,
Quiesce Sauvegardes en temps masqué
• Vary on nécessaire sur l’espace flashcopié Base de données de test/ pre-prod.
Server
Server SAN SAN Server ServerContraintes sur les
applications et les données
Réplication du stockage Réplication logicielle
• Les applications doivent s’exécuter dans un IASP • Aucun changement applicatif n’est requis
pour être protégées • Tous les objets et toutes les données sont
• La conversion des données et des applications protégées
peut s’avérer longue et fastidieuse • Compatible avec une organisation SYSBAS +
• Seules les données stockées dans l’IASP sont IASP
répliquées • Compatible avec tous types de stockage
• Le Sysbas doit être protégé par une autre • Toutes les applications connues sont
méthode supportées (par exemple banques, commerce
• Nota: le domaine administré ne protège pas de détail, logistique, santé, etc..)
entièrement le SYSBASObjets endommagés
Réplication du stockage Réplication logicielle
• Objets endommagés propagés • La réplication fondée sur le journal ne peut pas
propager des objets endommagés de la source
• L’absence de protection de l’espace adresse unique, vers la cible
peut entrainer un corruption des données
• Les éventuels objets endommagés sont détectés
• Les logiques ne sont pas mise à jour en temps réel et réparés et font l’objet d’alertes
• les logiques sont mis à jour en permanence sur la
• En cas de basculement non planifié, les outils de cible
récupération impactent fortement le RPO et le RTOReconstruction des chemins
d’accès (logiques)
Réplication du stockage Réplication logicielle
• Un basculement non planifié entraine une • Les chemins d’accès (index) sont mis à jour en
reconstruction des chemins d’accès parallèle sur chaque serveur
• Pas de reconstruction nécessaire
• Le temps de reconstruction dépend du stockage,
du serveur, et de la taille des chemins d’accès • La réplication peut valider en temps réel leur
intégrité et leur synchronisation
• Ce temps n’est pas prévisible • Les chemins d’accès invalides ne peuvent être
répliqués
• Le temps de basculement est réduit de 5 à 15
minutesTopologies possibles
Réplication du stockage Réplication logicielle
• Avec une réplication SAN à SAN, les matériels • La réplication supporte tout type de stockage,
source et cible doivent être similaires, SAN ou disques internes, toute organisation
compatibles
• Supporte toute distance (mode asynchrone)
• Limité à une réplication 1>1
• Permet des montées de versions OS décalées
• Les tailles de Lun identiques (2 releases d’écart supportées)
• Les versions, releases microcodes, alignés • Autorise les topologies 1>1, 1>N, N>1, A>B>C
• La distance peut être limitée selon la nature de la • Parfaitement adaptée pour les solutions Cloud
réplication (synchrone ou asynchrone)
• Pas compatible avec les solutions Cloud ou
mutualiséesConsidérations pratiques
Comportement de la solution
1. Synchronisation initiale
Bien choisir selon 2. Basculement non planifié (sinistre)
l’usage
3. Basculement planifié (maintenance)
4. Contrôle d’intégrité
5. Reprise en cas de problème réseau
6. Maj du système d’exploitation
7. Mise à niveau stockage
8. Evénement sur stockage
9. Répartition de la charge de travailSynchronisation initiale
Réplication du stockage Réplication logicielle
• Synchronisation initiale indispensable • Options possibles :
• Tous les secteurs / blocs sont envoyés via le • Save / restore
réseau • Copie du stockage
• Risques sur les volumes ( 10 To = 23 heures si • Puis resynchronisation via audits
1Gb/s à 100%) • Réduit l’impact sur le réseau
All storage Selected objects
SAN SAN
Tape
IASP Sectors IASP
Objects audited over time
SYSBAS SYSBAS
Initial object replicationBasculement imprévu
Réplication du stockage Réplication logicielle
• La baie cible doit passer par un vary-on • Le système cible est actif et son espace adressable
• Puis un contrôle d’intégrité (semblable à un IPL cohérent
anormal) • Pas besoin d’IPL
• 34 étapes de recovery dont la durée est • Les données sont intègres, et leur synchronisation
imprévisible controlée
• Certaines étapes peuvent conduire à : • Les chemins d’accès sont tenus à jour en temps
• Objets endommagés réel
• Chemin d’accès invalide • Le basculement des différents flux est
parallélisable
• Nécessite une intervention manuelle
• L’environnement système est inclus
A considérer : le SYSBAS est répliqué par une autre
méthode (OS ou Logiciel) • Pas de contrôle nécessaire
RPO incertain, RTO indéterminé RTO et RPO garantisChronogramme d’un basculement imprévu
Réplication du stockage Réplication logicielle
1. Waiting for devices - none present
2. Cluster vary job submission Sinistre Sinistre
3. Waiting for devices - not all present
4.
5.
DASD checker
Storage management recovery
Temps de décision Fin des applys
6. Synchronization of mirrored data
7. Synchronization of mirrored data-2 Basculement Basculement
8. Scanning DASD pages
9. Directory recovery - perm directory
10. Authority recovery
11. Context rebuild Démarrage
12. Journal recovery Ce temps
13. Database recovery
de recou- Application
14. Journal synchronization
vrement
Time
15. Commit recovery
est impré- Vary On
contrôle
16. Database initialization
17. Journal cleanup
visible (“IPL” de l’IASP)
s
18. Commit initialization
19. User profile creation
20. Database, journal, commit-1
21. Identifying interrupted DDL ops
22.
23.
Recovering system managed jrnls
POSIX directory recovery
La réplication logicielle
24. Database, journal, commit-2
25.
26.
Commit recovery - 2
Cleaning up journal receivers permet un temps de
27. Cleaning up cross-reference files
Post Vary On
28.
29.
30.
UID/GID mismatch correction
Database access path recovery
Database cross-reference file merge
basculement controlé et
31.
32.
SPOOL initialization
Image catalog synchronization réduit
33.
34.
Command analyzer recovery
Catalog validation
Démarrage
application
• Damaged object recovery
• Access path rebuildBasculement planifié
Réplication du stockage Réplication logicielle
• Quiesce et/ou Vary off sur la baie de stockage • Le serveur cible est actif
coté production Pas de vary on
• 34 étapes de recovery Pas de contrôle au moment du basculement
• Et Vary on de la baie coté secours • Les scripts de basculement sont fournis
A considérer : le SYSBAS est répliqué par une autre Les différents environnements peuvent
méthode (Os ou Logiciel) basculer en parallèle
Le processus de basculement est controlable à
chaque étape
RPO proche de zéro, RTO imprévisible RPO proche de zéro, RTO prévisibleChronogramme : basculement planifié
Réplication du stockage Réplication logicielle
Arrêt application
1. Waiting for devices - none present
Arrêt application
2. Cluster vary job submission
3. Waiting for devices - not all present
Vary Off
4.
5.
DASD checker
Storage management recovery
Basculement
6. Synchronization of mirrored data
7. Synchronization of mirrored data-2 Basculement
8.
9.
Scanning DASD pages
Directory recovery - perm directory
Redémarrage
10. Authority recovery
Application
Time
11. Context rebuild
12. Journal recovery
13. Database recovery
14. Journal synchronization
15. Commit recovery
16. Database initialization Vary On
17. Journal cleanup
18.
19.
20.
Commit initialization
User profile creation
Database, journal, commit-1
(“IPL” de l’IASP) La réplication logicielle
21.
22.
23.
Identifying interrupted DDL ops
Recovering system managed jrnls
POSIX directory recovery
permet un temps de
24.
25.
26.
Database, journal, commit-2
Commit recovery - 2
Cleaning up journal receivers
basculement controlé et
27.
28.
29.
Cleaning up cross-reference files
UID/GID mismatch correction
Database access path recovery
Redémarrage
réduit
30. Database cross-reference file merge
31.
32.
SPOOL initialization
Image catalog synchronization
Application
33. Command analyzer recovery
34. Catalog validationReporting et requêtes
Réplication du stockage Réplication logicielle
• Les données sur le SAN cible ne sont pas • Les rapports, queries , extraction et tous travaux
read-only peuvent être effectués à tout moment
accessibles
• Une réplication multiple (Y et plus) permet de
• Il faut activer des “flashcopy” et remonter les répartir les données
données dans une autre partition pour y accéder
Server Server
sectors
Primary Remote
DR Server
SAN SAN
HA Server Reporting
ServerValidation de l’intégrité
des données
Réplication du stockage Réplication logicielle
• Les données de la cible San ne peuvent pas être • Différentes méthodes de contrôle d’intégrité
contrôlées peuvent être utilisées (jusqu’à 8)
• En cas de problème une resynchronisation • Des fonctions de basculements virtuels
partielle et totale peut être nécessaire permettent de tester une reprise sans gêner les
utilisateurs
• Les corruptions fichiers sont indétectables avant • Des fonctions du “Remote Journaling”
le basculement permettent de contrôler les problèmes réseau
SAN SAN
Audits
IASP No audits of target SAN IASP Object comparison
SYSBAS SYSBASReprise après une rupture réseau
Réplication du stockage Réplication logicielle
• Selon l’ampleur de la panne, une synchronisation • En cas d’’arrêt temporaire du réseau, la réplication
partielle ou totale des secteurs stockées peut rattrape le retard avec les écritures lues dans le
être nécessaire journal
• SAN n’est pas protégé qu’à l’issue de la • Le remote journal package les écritures pour les
resynchronisation transférer plus rapidement
• La protection est assurée dès la fin de ce transfert
SAN SAN
IASP Sectors IASP Journal entries
SYSBAS SYSBASMAJ de l’operating System
Réplication du stockage Réplication logicielle
• Une fois que vous basculez vers le serveur cible, • La réplication logicielle supporte des écarts en
vous ne pouvez revenir en arrière qu’après avoir release et version de l’OS
mise à jour également le serveur de production • Upgrade , Test et Bascule permettent de réduire le
• Pas de retour arrière possible hormis un save / risque et le temps d’arrêt
restore • Un 3ème serveur peut assurer tout risque pendant
la migration
SAN SAN 1. Upgrade the production 1) Upgrade the target server to
1. Upgrade original Upgrade the target server to the new OS the new OS version and
production server to IASP IASP server to the new OS version. Switch back to validate. Switch to the target
the same level as the version and validate. the production server. server.
target. Switch back.
SYSBAS SYSBAS
Production Target
Production Target
Server Server
Server Server
1. Replication to a secondary
1. Switch to the target server. The IASP target is recommended to
image will be upgraded as part of protect against outages
Vary On. This is non-reversible and during the upgrade.
must complete successfully.
Secondary
TargetEvénement sur le stockage
Réplication du stockage Réplication logicielle
• Les SAN source et cible sont étroitement couplés • Indépendante des types de stockages
• Un arrêt du SAN source ou cible peut nécessiter • Les événements sur un disque ou une baie
un arrêt de production peuvent nécessiter un basculement avec un très
• Par exemple un Reclaim Storage (RCLSTG) faible impact sur la production
provoque un arrêt de la protection • Par ex : Reclaim Storage (RCLSTG ) nécessite un
basculement et une suspension de la protection
Server Server
SAN SANRépartition de charge
Réplication du stockage Réplication logicielle
• La cible SAN est verrouillée pendant la • Les topologies de réplication possibles sont 1-vers-
réplication, il n’y a pas de répartition de charge 1, 1 vers N, A->B->C, ou bidirectionnel)
possible • Les données sur le serveur cible sont mises à jour
• Pour utiliser les données cible , il faut utiliser les en temps réel, accessibles et protégées contre
technologies de flashcopy / snapshot l’écriture
• Une réplication bi directionnelle par clé permet de
bâtir des solutions active/ active
SAN SAN
Write: ACTIVE Write: No Write: ACTIVE Write: No
Read: ACTIVE Read: ACTIVE Read: ACTIVE
IASP IASP
Read: No
Bi-Directional or
Replication
Write: ACTIVE
SYSBAS SYSBAS Read: ACTIVE
Application Application
Data DataRésumé : SLA et contraintes
Besoin Architecture
Solutions RTO RPO Distance Cloud ready Nombre de nœuds
Débit réseau nécessaire
~0,
Réplication Limitée si Fort Espace disque et serveurs
2 à 4h Incertain sur Non 1 vers 1 Ou cascade
HW IBM i
synchrone 10 Mb/s à 100 Mb/s doublés à l’équivalent
Très fort Espace disque et serveurs
Db2 Mirror ~0 ~0Résumé : Les usages
Surveillance
Accès aux Sélection Support
Solutions RTO RPO CDP Basculement /Charge
data / cible périmètre /hotline
Gestion
Basculement SAN
Réplication Imprévisible incertain
non Non Non Basculement Sysbas Oui/Faible Selon solution
SAN ordre 2 à 4 h sur IBM i
Oui idem
DB2 Mirror ~0 ~0 Non Non Pas de basculement faible IBM
source
Réplication De 15mn à Sous contrôle opérateur
±0 Ok Oui Oui Oui/Normale ACMI
Logicielle 30 mn rapideCas concret
Client IBM i : deux serveurs à 200 km avec 48 partitions, dont 13 de production 48 processeurs actifs, 2
baies DS 8800 , env 200 To de capacité disque
Installation Power HA Global Mirror avec groupe de cohérence.
La réplication du Sysbas par le logiciel Quick-EDH
Power HA
SAN SAN
IBM i IBM i
Quick - EDH
SYSBAS SYSBAS
Production Secours
IASP copy
Metro Mirror copy
Avec GC
Installé POWER HA GM en 2013
• Un seul test réalisé sur une partition : basculement 40 mn
• mais 2h à 7h de recovery dont la reconstruction des chemins d’accès
• Pas d’accès aux données coté cible : d’où un ensemble de partition pour Flashcopy
POC Mimix en Juillet 2018
• après installation & basculement : 3 jours
• Résultat : RPOQuestions à se poser
• Quels sont mes objectifs de RTO / RPO ? How much bandwidth is
• Quelle distance et quel réseau entre les serveurs ? required?
• Quels avantages en terme de service (sauvegarde/ répartition de charge,
maintenance facilitée) ?
How do I validate
• Comment puis je garantir l’intégrité des données ? my switch
What RTO are
• Quelle flexibilité sur les architectures (local, distant , plusieurs serveurs) customers like me
readiness?
achieving?
• Puis je rencontrer des clients installés pour leur expérience de
basculements ?
• Comment s’effectue la synchronisation initiale et quelle bande passante est
nécessaire ?
• Quelle bande passante est nécessaire pour la réplication de l’état
d’équilibre ?
• Quel RTO/RPO serai-je en mesure de réaliser ?
• Puis-je tester sans impacter la production ?
• Ce que je peux avoir des nœuds pour HA, DR et rapports ?
• De quels usages quotidiens pourrais je bénéficier ?
• Quel est le coût total de tous les composants matériels et logiciels requis ?QUELQUES RÉFÉRENCES
ACMI avec MiMiX
Traitement des flux bourse Euronext
Hautement Critique :24/7 RTO 15 min , constaté RTO ~3 mn
7x2 partitions IBM i en Cluster sur 2x IBM Power P7+ 20 cpu
Flash System V9000 100 To
Industrie et distribution
2 partitions IBM Power 7+, 25 cpu, FS900 att.Direct 500 To
RTO 15 min
Distribution Matériel Electrique
2 serveurs IBM Power 880 36 Cpu – 6 Partitions
2x DS 8870 100 To
41 Copyright ACMI 2019
RTO < 1 hQUELQUES RÉFÉRENCES SYNCSORT
En Europe
KNAUF Allemagne 2 x880 50 CPU with SAP, disk IBM FS900 with 250TB, RTOMerci pour votre attention !
Benoît MASSIET du BIEST
bmassiet@acmi.fr
43 Copyright ACMI 2019Vous pouvez aussi lire
