 |
|
|
| |
| Questions-réponses |
| Réplication
de bases: entre continuité de service et disponibilité |
| Du simple backup au "zéro faute" absolu, les besoins de la réplication sont larges. Tour d'horizon introductif en cinq questions. (Lundi 27 janvier 2003) |
 |
>
La réplication, pour quoi faire ?
Confrontées à des risques constants menaçant
la continuité et la rapidité d'accès
à leurs données, les entreprises mettent
en place des systèmes assurant la sauvegarde et
la duplication de leurs bases à travers le monde,
en temps réel ou en décalé.
Prenons l'exemple d'une banque internationale. Elle doit
pouvoir retrouver une copie conforme de sa base de données
à l'instant même où un problème
quelconque survient sur une partie de son système
informatique. C'est l'aspect continuité de service.
Par ailleurs, ses différents établissements,
éparpillés sur les cinq continents, ne peuvent
se connecter à une et une seule base de données,
en raison principalement de trop longs temps d'accès.
Il faut donc que chaque entité géographique
dispose d'une copie de la base.
>
Synchrone ou asynchrone ?
Avant toute chose, il faut préciser que, contrairement
aux techniques traditionnelles de sauvegarde (backup),
la réplication permet au système informatique
de continuer à fonctionner alors même que
la base est répliquée.
Vient ensuite la distinction entre "synchrone"
et "asynchrone". Une réplication synchrone
signifie que, comme pour notre banque internationale,
la copie des informations se fait en temps réel.
En d'autres termes, elle a lieu au niveau de l'application
elle-même.
Ce sont les transactions
en tant que telles qui sont diffusées auprès
de systèmes distribués, d'un serveur primaire
(ou master) vers un ou plusieurs serveurs secondaires.
Cela implique que chaque transaction soit dupliquée
avant que toute autre transaction soit enregistrée,
ce qui peut engendrer des délais de réponse
en cas d'éloignement des serveurs.
L'autre
type de réplication, asynchrone, se fait en décalé
et concerne le stockage à prorement parler des
données : c'est toute la base de données
qui est copiée d'un endroit à un autre.
> Quelles applications concrètes
pour la réplication asynchrone ?
Dans le cas par exemple d'une société disposant
d'un réseau de vendeurs consultant la base de données
clients sur leur ordinateur portable, la réplication
asynchrone convient parfaitement. Périodiquement,
ces derniers rafraîchissent (synchronisent) leur
base de données afin de récupérer
les dernières mises à jour.
Un tel système est également approprié
pour une équipe de développeurs travaillant
à distance sur une application ou encore pour des
spécialistes du datamining.
> ... et pour la réplication
synchrone ?
En revanche, pour des sociétés
telles que les compagnies aériennes, les banques,
les sociétés de bourse... le caractère
synchrone de la réplication est impératif.
Aucune donnée ne peut être perdue, aucune
interruption n'est tolérée et les performances
doivent être optimales quoi qu'il arrive. La réplication
touche d'ailleurs parfois de près aux questions
de "load balancing" (transfert de charge). En
cas de surcharge d'un serveur, on peut être amené
à dérouter certains utilisateurs vers des
serveurs secondaires dont la base aura été
répliquée...
Il est bien évident
que la réplication synchrone nécessite des
moyens beaucoup plus coûteux que l'asynchrone, en
raison principalement de la bande passante nécessaire
pour assurer un échange parfait entre les différents
serveurs d'un réseau. Les solutions asynchrones
sont donc privilégiées par les entreprises
dont l'exigence en "temps réel" et en
continuité de service est réduite.
> Quelles sont les solutions
(ou prestataires) du marché ?
Parmi les principaux acteurs du marché,
on peut citer IBM (IBM Replication Solutions), Veritas
Software (Veritas Storage Replicator), EMC (EMC Replication
Manager) et Hewlett Packard (Data Replication Manager).
|
|
|
|
|
|
|
[