1 Montée en charge

Pour prévoir une évolution de la volumétrie, le SVC est conçu de manière à accueillir un appoint de serveurs de type SVC (serveur d’application) lui 
permettant d’assurer une montée en charge sur les années à venir. Ainsi le nombre de serveurs SVC sera-t-il augmenté pour pouvoir absorber une évolution 
croissante de la volumétrie des requêtes.

2. 7.2	Déport du référentiel du SVC
La conception initiale du SVC lui permet de déployer un référentiel de données commun pour plusieurs instances du service de validation. Ce référentiel, 
initialement prévu pour être partagé entre l’instance du SVC à Lyon et celle de Bordeaux, n’est pas mis en œuvre. En effet, les règles de sécurité et 
le fonctionnement des bases de données Oracle (avec le protocole de réplication notamment) ne permettent pas, dans l’immédiat, de fournir ce référentiel commun.
Rappel : ce référentiel permet de centraliser en un point unique l’ensemble des données communes au SVC. Il est composé du composant CRL2DB, qui permet de télécharger 
les CRL depuis la zone 1 (internet) et d’une base de données commune qui reçoit les CRL et les AC référencées. De plus, le service d’administration permet de gérer de manière 
centralisée les politiques de validation et les processus de contrôle effectués par les différentes instances du SVC.

7.2.1	Le nouveau déploiement envisagé
Un exemple de déploiement entre les sites de Bordeaux et de Lyon est proposé ci-après :
-	Les éléments CRL2DB, service d’administration et la base de référence seront déplacés de la zone 2 vers la zone 3 de sécurité. Ceci permettra d’obtenir 
une architecture centralisée pour la partie « récupération des CRL ».
-	Ensuite, le composant CRL2DB et le service d’administration alimentent le référentiel base de données positionné dans la zone 3. Cette base de données alimente 
ensuite les bases de données des différents sites de production (Bordeaux et Lyon) en zone 2.

7.2.2	Le principe de fonctionnement
7.2.2.1	La récupération des CRL : uniquement un Delta
Le composant CRL2DB, qui récupère les CRL de la zone 1, réalise une vérification du contenu de la base de données et ne dépose que le Delta par rapport au contenu des CRL d
éjà chargées. Ce mode de fonctionnement permet de considérer que la réplication de base de données n’est pas un élément critique et ne nécessite pas une sauvegarde en temps 
réel. Le niveau de restauration doit être en revanche réalisée dans un espace de temps restreint.
En cas de perte de la base de données référentielle, une restauration sera effectuée sur une machine dédiée. Le Delta entre les dernières CRL et ceux contenus dans la base de 
données sera mis à jour automatiquement par le composant CRL2DB. 

7.2.2.2	La réplication des bases de données
Les bases de données en zone 2 sont positionnées dans des DMZ des PAS. La base de données référentielle est pour sa part positionnée dans la zone 3. La charte de sécurité de la 
DGI ne permet pas d’initialiser des connexions allant de la zone 2 vers la zone 3. Il conviendra donc d’utiliser un processus de réplication, qui ne peut-être initié que depuis 
la zone 3. Le protocole du flux entre la zone 3 et la zone 2 sera de type http ou encapsulé en SSH.
Pour sécuriser les bases de données de la zone 2, deux serveurs par site seront en fonction simultanément. Les serveurs frontaux du SVC utiliseront un mécanisme de réparation 
de charges fourni par le « Listener » des bases de données pour appeler l’une ou l’autre base.





