Introduction
C’est un produits EMC² permettant de répliquer les données entre plusieurs sites, et ne fonctionne donc a priori que sur des baies EMC². C’est mécanisme hardware, qui ne se préoccupe pas de la nature des informations qui sont stockées sur les disques.
Il est possible de faire du SRDF synchrone sur des cluster geospan (surcouche applicative windows) entre des sites distants de 10-15 km. Pour des sites plus distants on utilise le SRDF asynchrone, ce qui permet de faire de la sauvegarde a J-1. On pourrait faire des fréquences plsu rapprochées mais généralement cete solution n’est utilisée que pour des sauvegardes de la veille.
Les BCV
Phase 1 : Un serveur voit un disque (le STD, standard). Pour lancer le procesus de réplication, à ce jour on gèle les IO, soit par surcouche applicative, soit généralement on fait un arrêt applicatif. Une fois cela fait, on génère un ordre de ‘establish BCV’. Cet establish compare le STD et le BCV (jeu de disque dédié pour etre miroir du STD) pour connaître les différences (en terme de piste physique). Il recopie ces différences du STD vers le BCV.
Le BCV (sur le site primaire) peut être appelé R1 (premier réplicat).
Il faut noter que le gel des IO n’est pas obligatoire, cependant il permet à la synchronisation du BCV de se faire beaucoup plus rapidement.
Phase 2 : le split : On doit figer l’image BCV lorsqu’elle est complètement conforme a la source. A ce moment du process, le gel IO est obligatoire (souvent obtenu par un arrêt applicatif).
Phase 3 : Entrée en jeu de SRDF : Une fois que le BCV est cohérent avec le STD, on utilise le même mécanisme distant. Le R1 est recopié sur le R2 (image disque sur le site distant), par un establish (réplication des pistes modifiée) puis un split quand les deux volumes sont équivalents.
Il est toujours possible de rajouter un BCV au R2, afin d’être plus secure dans le cas de PRA. En effet lorsque ,sur le site 1, la baie pète lors de l’establish R1-R2, il est toujours possible d’avoir un R2 incohérent.
Le process le plus sur pour etre couvert dans tous les cas est donc le suivant :
1 - establish R2-BCV du R2
2 - gel des IO prod
3 - establish prod
4 - split BCV R1
5 - relance des IO prod
6 - lancement establish SRDF R1-R2
7 - split image SRDF R1-R2
Ce cycle permet de s’assurer dans tous les cas qu’on aura soit R2 ok soit BCV R2 ok : on a toujours une image qui permettra de répartir.
Généralement du fait des problématiques de budget le BCV de R2 est rarement fait.
Si on fait du fil de l’eau sur le SRDF R1 R2, on augmente le risque d’avoir un R2 incohérent.
En cas de problème sur le site principal
On peut utiliser l’image BCV pour autant qu’on ne se trouve pasdans la phase 3. On peut alors réattacher les BCV sur le serveur primaire, afin de pouvoir les accéder en lecture. On peut également utiliser un autre serveur pour y atacher les BCV (ce qui permet soit de relancer l’appli soit de faire les sauvegardes), ou (au pire) ecraser les STD avec le R1.
Il faut prévoir des le départ le R1 le STD et le R2 , car ce paramétrage prend beaucoup de temps et implique nécessairement une intervention de la part d’EMC².
Il existe d’autre mécanismes qui font que ce sont les baies qui gèrent ces réplication et plus les serveurs comme c’est le cas aujoud’hui
