Etapes du projet

nous l’avons
d’abord programmée pour déterminer
au moment du démarrage quel serveur
exécuterait une fonction de reporting
particulière. Malheureusement, dans ce
scénario, si un serveur de reporting tombait
en panne une fois l’application lancée,
il fallair réacheminer les requêtes de
reporting pour les honorer. Et si l’emplacement
du serveur n’était pas défini pendant
le démarrage, le seul moyen de déterminer
correctement où réacheminer
les fonctions de reporting consistait à  redémarrer
l’application. Comme ce
n’était pas assez dynamique, nous avons
préféré placer une table de consultation
sur le serveur principal. Cette table
contient une liste des requêtes de reporting
et le nom du serveur sur lequel elles
s’exécutent. Désormais, quand un utilisateur
soumet un rapport, l’application
interroge la table de consultation et exécute
le rapport sur le serveur indiqué par
l’entrée dans la table de consultation.
Bien que l’accès à  une table de consultation
alourdisse la manoeuvre, les gains de
performances le compensent largement.

Le critère suivant a été l’évolutivité.
Nous avons divisé les fonctions de reporting
en trois catégories d’après leurs objectifs
de gestion, puis attribué chaque
catégorie à  un serveur correspondant.
Les catégories indiquent le degré d’activité
des données: en temps réel, presque en temps réel, ou d’un jour. Les
requêtes de reporting en temps réel doivent
se faire sur le serveur principal
parce que la nature des requêtes dépend
de l’état instantané de la base de données.
Les fonctions presque en temps
réel peuvent tolérer le délai de 8 secondes
inhérent à  la réplication, donc
nous avons attribué ce groupe à  un
deuxième serveur, représentant environ
20 % de la taille de la base de données
principale. Quant aux fonctions de reporting
d’un jour, elles concernent les
données à  long terme. Nous avons donc
décidé de garder une image des données
de la veille sur un troisième serveur.Cette reconception architecturale a réduit
la quantité de données qu’il nous fallait
répliquer et nous a fourni une grande
marge d’évolutivité en nous permettant
de répartir les fonctions sur de multiples
systèmes.

L’un des avantages de la reconception
est que tous les rapports qui accèdent
au serveur en presque temps réel
utilisent les mêmes données. Par conséquent,
nous pouvons répartir des rapports
multiples sur des abonnés multiples.
Bien que le serveur principal soit
un MSCS (Microsoft Cluster Server),
nous n’avons pas eu besoin de grouper
en clusters les serveurs de reporting. Si
un serveur de reporting tombe en panne
ou s’il se produit une erreur de réplication,
nous pouvons rapidement et facilement
modifier la table de consultation de
l’application pour permuter les abonnés
ou repointer vers le serveur principal
pour une courte période. Avant la reconception,
il nous fallait changer d’abonnés
ou envoyer les rapports au serveur principal
manuellement. L’utilisation d’abonnés
multiples pour les mêmes rapports
nous offre en plus la tolérance aux
pannes. Comme la réplication transactionnelle
applique la même charge au
publieur quel que soit le nombre d’abonnés,
nous pouvons mettre en oeuvre
deux serveurs de reporting pour un overhead
et un coût bien moindres qu’un
serveur de reporting en cluster.
L’application peut continuer à  fonctionner
même avec un serveur de reporting
défaillant. La figure 2 montre la reconception architecturale.

Modifier l’application. Comme nous avons développé et maintenu l’application
en interne, nous pouvions la
modifier. Toutefois, la modification restait
une tâche énorme parce que nous
devions analyser 180 rapports pour déterminer
à  quelle catégorie ils appartenaient:
temps réel, presque temps réel
ou un jour. L’application devait être capable
de déterminer le serveur sur lequel
chacune des fonctions répliquées
s’exécuterait, en lisant la table de consultation,
en se connectant au serveur approprié,
en déplaçant les données vers
ce serveur, puis en se déconnectant une
fois la requête de reporting terminée.
Nous continuons d’ailleurs à  améliorer
l’application et modifions la plupart des
requêtes de reporting pour utiliser cette
table de consultation, même si elles
pourraient encore pointer au début vers
le serveur principal. Cette table de
consultation assouplit l’acheminement
des requêtes, permet de les déplacer ultérieurement,
et élargit l’horizon pour
les besoins de reporting futurs.

Mettre en oeuvre la réplication
transactionnelle. Nous avons choisi la réplication transactionnelle pour ce projet,
pour plusieurs raisons. Comme les
requêtes de reporting étaient en lecture
seule, nous n’avons pas eu besoin d’implémenter
la réplication bidirectionnelle. De plus, la réplication transactionnelle
crée beaucoup moins d’overhead sur le
publieur que la réplication fusionnelle
(parce que la réplication fusionnelle est
basée sur des triggers, lesquels entraînent
un overhead important). Nous ne
voulions pas non plus infliger au DBA le
surcroît de charge qu’engendre la réplication
fusionnelle. En mettant en place la
réplication transactionnelle, nous avons
pris grand soin de coordonner la réplication
avec les modifications applicatives. Il
nous fallait particulièrement veiller à  ce
que toutes les tables et procédures stockées
nécessaires soient répliquées. Ce
travail demandait beaucoup de coordination
et une excellente communication
entre les groupes de développement et
DBA.

Initialement, nous avons mis en
oeuvre la réplication avant de modifier
l’application, afin de pouvoir tester la
performance et la configuration de la réplication.
La performance de la réplication
nous a semblé inacceptable. La valeur
par défaut de l’intervalle de polling
pour le Log Reader Agent et le
Distribution Agent était de 10 secondes
et donc une transaction pouvait mettre
jusqu’à  20 secondes pour aller du publieur
à  l’abonné. Ce délai de réplication
était inacceptable parce que les utilisateurs
étaient habitués à  des rapports en
temps réel ou en presque temps réel. En
modifiant les intervalles de polling pour
le Log Reader Agent et le Distribution
Agent à  2 secondes, nous avons
raccourci ce temps à  un maximum de
4 secondes, fort acceptable.

Pendant que nous incorporions la réplication
transactionnelle dans le processus
de contrôle du changement, nous
avons découvert un problème de
conception architecturale important. Par
défaut, nous mettions tous les objets répliqués
dans une publication. Bien que
cette technique ait facilité l’administration,
elle a aussi compliqué le contrôle
du changement. Les règles de gestion du
centre d’appel (et donc les rapports)
changent souvent. Il nous fallait donc
modifier les procédures stockées et les
schémas correspondants. Chaque fois
que nous apportions une modification qui affectait un objet répliqué, nous devions
casser et recréer la publication. La
solution était de faire de chaque objet
une publication séparée, de telle sorte
que, désormais, quand nous changeons
un objet, nous devons simplement modifier
une publication spécifique et environ
100 abonnements. Nous n’avons pas
à  créer un instantané pour tout le jeu de
publications, seulement pour les objets
affectés. Bien sûr nous avons davantage
de publications à  gérer, mais l’administration
est beaucoup plus facile à  long
terme.

Tester et ajuster la solution. Chaque fois que nous avons amené une
nouvelle requête de reporting sur les
serveurs répliqués, nous l’avons testée à 
fond. Comme un rapport pourrait accéder
à  10 à  20 tables et appeler plusieurs
procédures stockées, vous pourriez facilement
déplacer un rapport auquel
manque une table ou une procédure
stockée sous-jacente. Pour éviter ce
risque, nous avons conduit un test de régression
d’application complet (en testant
toutes les options de reporting disponibles)
chaque fois que nous avons
apporté une modification au modèle de
réplication. En outre, comme nous
n’exécutions que des requêtes de reporting
sur ces serveurs, nous avons ajusté
les index seulement pour les requêtes de
reporting et pas OLTP. En procédant
ainsi, nous avons pu retirer certains index
et en modifier d’autres pour améliorer
la performance. Nous utilisons
encore ce processus. Pour garder les
données et les index dans un état optimum,
nous exécutons aussi DBCC
CHECKDB et DBCC REINDEX chaque
semaine.

Maintenir le système distribué. Maintenir le système est devenu un peu
plus difficile au fur et à  mesure que nous
ajoutions des serveurs. Il nous fallait administrer
un distributeur et deux abonnés
ou plus, en plus du serveur principal.
Pour bien traiter les requêtes de changement
et surveiller l’état de santé et la disponibilité
des publications de reporting,
nous avons constaté qu’il fallait allouer
au moins 30 % du temps de deux DBA
senior pour administrer l’architecture de réplication. Une partie de leur temps est
consacrée à  surveiller les seuils de discordance.
Au moment où nous avons
mis en oeuvre la reconception, nous
avons établi des seuils de discordance
pour chaque publication de table.
Désormais, SQL Server compare les
comptages de lignes de la table abonné
aux comptages de lignes du serveur
principal, et quand le seuil de discordance
fixé est dépassé, SQL Server envoie
une notification urgente à  l’équipe
responsable de la base de données.
Pendant le test, nous avons décidé
qu’en raison des règles de gestion, nous
devions répliquer les comptes et les
mots de passe utilisateur sur les abonnés.
Comme la réplication transactionnelle
ne peut pas répliquer ce genre d’information
utilisateur, nous avons dû
créer notre propre méthode de réplication
en utilisant des packages DTS (Data
Transformation Services). Par l’intermédiaire
du SQL Server Agent, SQL Server
exécute les packages DTS pour mettre à 
jour l’information login et utilisateur
toutes les 5 minutes. Les changements
les plus courants de l’information utilisateur
sont les suivants: changer les mots
de passe, changer les rôles (une fonction
de sécurité applicative pour grouper les
utilisateurs en fonction des différents
types d’accès aux données) et ajouter ou
désactiver les utilisateurs.
Auparavant, nous avons décidé que
comme les rapports fonctionnant sur le
serveur d’un jour nécessitaient la totalité
des 40 Go de données du centre d’appel,
il n’était pas possible d’exécuter la réplication
d’instantané sur ce serveur, à 
cause du temps pendant lequel la
réplication d’instantané doit maintenir
un verrou sur la table répliquée. En
outre, en raison de problèmes de clé primaire,
la réplication transactionnelle
n’était pas non plus possible. Nous avons
donc décidé de maintenir le serveur
d’un jour par un mécanisme de sauvegarde
et de restauration. Ce mécanisme
offre plusieurs avantages au data center,
comme des performances supérieures à 
la réplication snapshot, et nous aurions
effectué une sauvegarde de toute
manière. Un autre avantage de ce mécanisme
est que nous validons les sauvegardes
immédiatement après les avoir
créées, en les restaurant.

Maintenir le serveur d’un jour est un
équilibre subtil entre tâches automatisées
et tâches manuelles. Avant tout, il
faut s’assurer que le serveur d’un jour est
actualisé jusqu’à  minuit du jour précédent.
L’objectif secondaire est d’effectuer
le processus de sauvegarde et de
restauration à  temps pour remettre le
système online après le prochain jour
d’activité. Le processus, qui demande
des opérateurs de nuit et des DBA de
permanence, est décrit ci-après: