comment Add Comment
Posted on Last updated

Solution technique : mise en place et configuration de geOrchestra – Partie IV

Dimensionnement et architecture du serveur de production

La question du dimensionnement et de l’architecture du/des serveur(s) est très importante dans ce genre de projet. De nombreuses questions doivent être posées pour définir la meilleure solution, celle qui sera capable de répondre aux différentes requêtes des utilisateurs. Cette réflexion est menée conjointement avec la DSI. La première question à se poser est l’hébergement : Où sera hébergée notre plateforme ? Nous avons choisis l’hébergement en interne. En effet le matériel informatique déjà présent à l’agglomération est suffisant pour notre plateforme, aucun surcoût matériel n’est donc engagé.

De plus, le parc disponible possède les ressources nécessaires pour permettre une éventuelle évolution de la plateforme. La question de la bande passante sera aussi évoquée puisque c’est souvent le facteur limitant des applications en réseau. Je présenterais d’abord l’architecture logicielle que nous avons retenue et ensuite l’architecture physique et le dimensionnement qui en découlent.

Architecture de la solution

Pour choisir la bonne architecture, une multitude de questions ont été posées. Je vais commencer par présenter l’architecture que nous avons retenue (Figure 5) et succinctement le fonctionnement lors d’une requête émise par le client (Figure 6). Ensuite, j’expliquerais ses qualités et pourquoi elle a été choisie. L’objectif est d’obtenir une architecture dite HA (High availability). On pourra trouver en Annexe 1 l’évolution de l’architecture au fil du stage.

Tomcat est un serveur d’applications, il permet donc de faire fonctionner des applications web (abrégées webapps) sur un serveur. Celles-ci génèrent des réponses aux requêtes du client.

Figure 5 : Architecture finale retenue

 

Figure 6 : Fonctionnement de la solution

 

  • Une répartition sur deux serveurs et 3 instances.

Pour augmenter la stabilité de l’application et répartir la charge, il est souvent conseillé de répartir les différentes applications qui composent geOrchestra sur plusieurs « instances » de Tomcat. Ceci a aussi l’avantage de favoriser le débogage puisqu’on isole les applications. Les instances peuvent être réparties selon deux concepts expliqués dans l’encadré ci-dessous [LANGLET, 2008] :

Les deux concepts de répartition des instances de Tomcat :

  • Répartition verticale: Toutes les instances sont sur le même serveur. On isole ainsi les applications sujettes aux défaillances dans leur machine virtuelle Java (chaque instance fait tourner sa propre machine virtuelle Java). Si cette application perturbe la machine virtuelle Java, les autres applications ne sont pas impactées. En revanche cette technique ne permet pas de se prémunir des pannes de serveur.
  • Répartition horizontale: Les instances sont réparties sur plusieurs serveurs. On se prémunit ici de la panne matérielle en revanche comme les instances sont réparties sur plusieurs serveurs, les échanges entre instances dépendent du réseau.

Nous avons donc ici utilisé ces deux types de répartition, en utilisant plusieurs instances sur plusieurs serveurs.

Nous avons isolé Geoserver du fait que c’est l’application la plus sensible et la plus consommatrice en ressource. Ainsi, si Geoserver perturbe la machine virtuelle Java de son instance Tomcat, il ne perturbe pas le fonctionnement du reste de l’application. Isoler Geoserver sur un serveur permet aussi de lui allouer plus de ressources.

Ensuite les webapps CAS (Système d’authentification) et ROOT (proxy interne) sont aussi isolés. Ces deux applications sont très stables et peu consommatrices de ressources. De plus, si la webapp ROOT ne fonctionne plus le reste de l’application ne peut plus fonctionner (plus de redirection d’URL). C’est ce qu’on appelle un SPOF (Single Point Of Failure). Pour éviter que des webapps, comme Mapfishapp ou Geonetwork, ne perturbent le fonctionnement du CAS et du ROOT, on isole ces deux webapps. On peut aussi se permettre de n’attribuer que très peu de ressources à l’instance de Tomcat qui les contient.