Performances du système informatique Aster en Côte d'Ivoire

Depuis le 1er janvier 2002, Aster a démarré en Côte d'Ivoire, et à l'heure de sortir une première balance générale, les efforts se sont décuplés pour l'alimenter de données comptables à jour. Ces efforts ont dus être suivis par l'équipe d'exploitation et la cellule d'assistance qui ont été sollicités pour décrypter, interpréter et analyser quantité d'informations en provenance des utilisateurs d'Aster. Aujourd'hui, après sept mois d'exploitation, il est temps de faire le point afin de préciser et distinguer, sur le plan des systèmes et des réseaux, ce qui marche, ce qui est perfectible, et ce qui bloque.

Les réseaux

Le réseau servant de support à Aster, est géré par la sous-direction informatique de la Direction Générale de la Comptabilité Publique et du Trésor Ivoirienne. Il s'étend pour le moment uniquement à la ville d'ABIDJAN, et il est scindé, pour des raisons de performances et de logique d'administration, en plusieurs sous-réseaux reliés entre eux par des faisceaux hertziens (FIG. 1)

Chaque sous-réseau est entièrement commuté, c'est à dire, pour simplifier, que chaque poste informatique possède sa propre ligne de connexion qu'il ne partage avec aucun autre. Il n'existe, pour ainsi dire, aucun domaine de collisions entre les communications, ce qui confère au débit, la propriété de ne pas s'effondrer à mesure que le trafic augmente. Le débit théorique est de 100Mb/s au sein de chaque sous-réseaux, et il convient très largement aux transports des données, de clients à serveurs Aster.

CITFI

Le sous-réseau de la cité financière est le plus important de tous. Il abrite : ­ les deux serveurs Unix qui exécutent le système d'information central d'Aster, ­ les contrôleurs de domaine qui authentifient les connexions aux ressources informatiques, et résolvent les noms de ressources en adresses réseau, ­ les deux serveurs Windows NT 4 de la Direction Générale des Douanes et de la Direction Générale des Impôts, en attendant leur redéploiement dans leurs réseaux respectifs.

DGTCP

Le sous-réseau de la Direction Générale de la Comptabilité Publique et du Trésor est relié au sousréseau CITFI, et donc aux serveurs centraux Aster, par deux paires d'émetteurs/récepteurs radios. Il abrite un serveur de données applicatives Aster, servant aussi de contrôleur de secours en cas de rupture de connexion avec CITFI.

SCIAM

Le sous-réseau de l'immeuble SCIAM est composé essentiellement par des postes clients et un serveur de données applicatives Aster utilisé pour limiter le trafic radio aux requêtes Aster.

Trafic réseau

Le trafic entre les sous-réseaux est borné, de part les caractéristiques techniques des émetteurs radios utilisés, à 11 Mbits/s. La vitesse théorique entre les sous-réseaux est donc dix fois moins importante qu'au sein d'un même sous-réseau. Cependant, dans la pratique, cette limite suffit amplement aux échanges de données entre client et serveur, puisque le trafic pendant les heures pleines, ne dépasse jamais les 4% en entrée et en sortie des antennes (FIG .2). Le trafic inhérent au fonctionnement propre des antennes étant fixé à 2,5% du débit maximal théorique, Aster ne vient augmenter ce trafic que de 1% !

Un autre point de mesure sur la sollicitation du réseau par l'application Aster se trouve en sortie du serveur central. L'analyse du trafic sur l'interface réseau de tresor01 (FIG. 3), fait apparaître des pics aux alentours de 35% pendant les sauvegardes, et aux alentours de 5% en exploitation pendant les heures de pointe. La moyenne se situant vers a 1,15%.

Les systèmes

Unix

Les serveurs Unix IBM RS/6000 sont exploités sous le système Unix d'IBM AIX 4. Ils font tourner en permanence un ou plusieurs moteurs de base de données Oracle8, et servent les données applicatives aux clients via le protocole de réseau local SMB. Pour le serveur principal, tresor01, nous disposons de quatre bases Aster en version 2.1, dont au moins trois tournent en permanence : 1. la base de paramétrage, 2. la base de production, 3. une base de test, 4. une base de formation. Le nombre de processus relevé en exploitation courante est le suivant :

Le serveur secondaire, tresor02, initialement prévu pour seconder tresor01 en cas de panne, et reprendre l'exécution des SGBD, abrite aujourd'hui deux bases de données Aster2.2:

1. la base de paramétrage,
2. la base de production,

devant servir a tester et valider la dernière version d'Aster avant basculement. Le nombre de processus relevé en exploitation est le suivant :

Windows NT 4

Les serveurs de la douane et des impôts sont les premiers représentants de bases Aster autonomes échangeant des données avec le serveur principal. Il n'y a qu'une base de données par serveur, et ils n'offrent pas d'autres services au sein de leur sous-réseau respectif, qui n'est d'ailleurs composé, pour l'instant, que par eux-même.

Charge système

L'hétérogénéité des systèmes observés nous permet de nous faire une bonne idée sur la sollicitation d'un système par un SI Aster. Avec ces quatres bases, le serveur tresor01 est le plus chargé de tous (FIG .4).

La charge système moyenne de 9,41 sur 24 heures, mesure le nombre de processus demandeurs de la totalité de la puissance de calcul du serveur. Cette charge ne diminue jamais ; le serveur est constamment occupé. Le serveur tresor02, qui n'a pourtant que une ou deux connexions utilisateur, a une charge de 1,14 dès que l'unique base Aster est lancée. La charge monte et descend brutalement (FIG. 5) après le démarrage et l'arrêt de la base et du scrutateur.

Même remarque au niveau d'un système NT, ou la charge, mesurée ici en pourcentage d'occupation du processeur, est étroitement liée au lancement du scrutateur (FIG. 6).

On note (FIG. 6) :

1. l'arrêt de la base vers 23h pour la sauvegarde,
2. la relance aux alentours de 9h,
3. le lancement et l'arrêt manuel en fin de matinée.

Les problèmes rencontrés et rapportés par les utilisateurs à la cellule d'assistance, concernent en général des lenteurs constatées au niveau de l'interface utilisateur, et des temps de traitements anormaux sur les clôtures de journées.

Concernant le réseau

Les problèmes de réseaux concernent à 99% les ruptures de liaisons inter-bâtiments. Un utilisateur perd sa connexion au serveur, et un message d'erreur apparaît sur son poste l'empêchant de poursuivre son travail. Le taux de disponibilité des serveurs centraux est mesuré en testant l'accessibilité des éléments actifs d'un sous-réseau donné, à partir des serveurs Aster, et ce, par intervalle de 5 minutes, 24 heures sur 24 et 7 jours sur 7. Le taux mesuré pour le mois de juin et pour le sous-réseau DGTCP est de 87%, ce qui représente, en regroupant toutes les pannes, plus de 3 jours d'indisponibilité dans le mois, et explique en partie, le mécontentement des comptables de la TRAN. Le sous-réseau CITFI, non soumis aux ruptures de liaisons radios, a atteint le score de disponibilité de 99,9%, pour le même mois de juin.

Concernant les systèmes et l'exploitation

Souvent associés, à tord, à des problèmes de réseau, ces problèmes peuvent s'expliquer principalement par des temps de traitements élevés au niveau des serveurs. Parmi les demandes de traitements que l'on trouve dans Aster, il y a :

• celles qui sont prises en compte immédiatement et de manière synchrone. L'utilisateur est obligé d'en attendre le résultat avant de pouvoir continuer, et son interface est en général figée pendant ce temps. La comptabilisation de bordereaux rentre, par exemple, dans cette catégorie,
• et celles qui nécessitent un traitement plus lourd. Ces demandes consistent a alimenter une file d'attente de traitements qui s'exécutent en général le soir sur le serveur, dans le cadre des tâches d'exploitation. L'utilisateur peut poursuivre sont travail après prise en compte de la demande. Il s'attend en général a constater le résultat de son traitement le lendemain. On trouve dans cette catégorie, les demandes de clôtures de journée comptables.

Concernant le réseau

Le passage à la fibre optique ne va changer que très peu de choses au niveau de la réactivité de l'interface d'un utilisateur situé à l'immeuble DGTCP, tant nous venons de voir que le réseau actuel était sous-exploité (2.1.4). Le gain devrait concerner la disponibilité globale du réseau. Le taux minimal acceptable de disponibilité a été estimé à 97% sur l'ensemble du réseau. C'est l'objectif a atteindre avec ou sans fibre, et la technologie des antennes radios permet aisément d'atteindre cet objectif, sachant que :

1. les distances inter-bâtiments sont très inférieures à ce que les émetteurs installés permettent atteindre, et
2. que les mesures d'interférences radios, ou des taux d'erreurs de transmission/réception n'ont rien mesuré de gênant (FIG. 7).

Il devient alors difficile d'expliquer les problèmes de dysfonctionnement du réseau actuel par d'improbables perturbations atmosphériques. La technologie se doit d'être maîtrisée, et c'est un argument en faveur de la fibre optique, dont la mise en oeuvre est peut-être plus simple, même si en cas de panne, la recherche du point de rupture peut s'avérer plus complexe.

Toute liaison critique se doit d'être doublée pour conserver un accès de secours en cas de rupture de la liaison principale, et ce principe n'a pas été appliqué pour les liaisons radios. Avec la fibre optique, les faisceaux hertziens serviraient de liaisons secondaires, ce qui permettrait très certainement d'atteindre facilement nos objectifs en terme de disponibilité.

Concernant les systèmes et l'exploitation

Du côté de la SDI, les optimisations classiques au niveau Oracle ont été effectués (nettoyage, réindexation), sans constater d'améliorations sensibles. Le problème de la charge système élevée (2.2.3) peut trouver son origine dans :

• un choix inadapté pour les paramètres des bases concernant les tailles de cache, d'index ou des tables temporaires. Ces paramètres ont été choisis par SEMA et placés dans les scripts de création de la base Aster,
• une puissance de calcul réellement insuffisante de tresor01 pour exécuter trois ou quatre bases Aster,
• la consommation excessive des ressources par le scrutateur, qui peut ralentir les autres processus si on ne lui attribue pas une priorité inférieure. Pour le premier problème, une collaboration avec les DBA de la SDI peut être envisageable de manière a recalculer la valeur des paramètres conformément aux volumes des bases à ABIDJAN.

Le deuxième problème est un peu plus délicat, dans la mesure ou il nécessite la délocalisation de plusieurs bases sur d'autres serveurs. L'utilisation de tresor02 à cette effet représenterait probablement la fin de l'utilisation d'HACMP, et donc imposerait un changement d'architecture et la réattribution des disques partagés à chacun des serveurs. Le problème du scrutateur se contourne en ne le lancant qu'au besoin ; ce qui va à l'encontre du concept de scrutateur qui reste normalement à l'écoute. Deux mesures complémentaires sont applicables dans l'immédiat :

1. l'arrêt des bases pendant la procédure de sauvegarde provoque du même coup l'arrêt des traitements d'exploitation. Il n'y a pas de reprise possible des traitements, ou autrement dit, un traitement interrompu doit être repris depuis le début. Compte tenu de la charge du serveur principal, celui-ci n'est pas en mesure de rattraper le temps perdu en cas d'interruption ; il accumule les travaux en attente. Des méthodes de sauvegardes n'imposant pas l'arrêt des bases existent et doivent être mises en place de toute urgence par la partie DBA. Cette mesure permettrait a défaut de rattraper le temps perdu, de ne plus en perdre,
2. discipliner les comptables pour qu'ils segmentent le plus possible leur demandes de traitements, dans la mesure ou l'arrêt d'un traitement sur un lot nécessite la reprise de tous les traitements du lot. Deux autres mesures nécessitent une étude plus poussée :
   1. reprogrammer le scrutateur en mode événementiel. Des évènements au sein de la base (la demande d'un traitement), déclenchent l'appel système au scrutateur, qui n'a plus besoin de scruter, et soulage du même coup le système du poids de sa surveillance,
   2. analyser la complexité des traitements comptables sur le plan algorithmique, et vérifier que dans le pire des cas cette complexité reste bien linéaire aux volumes de données a traiter, puisque le cas d'une complexité polynomiale est, dans bien des cas, catastrophique.