Architecture applicative web dans un cloud

Avec l'arrivée des offres « Private cloud » bon marché, il devient intéressant de virtualiser entièrement ses serveurs et son architecture web. Avec des systèmes de virtualisation comme VMWare et vSphère, il est très facile pour le même prix de créer un grand nombre de machines virtuelles et ainsi de découper au mieux son architecture web pour isoler chaque composante, et apporter robustesse aux différentes instances de services. L'objectif de cet article est donc de faire un retour d'expérience afin de fournir un exemple d'architecture type dans la mise en place et l'exploitation d'une application web.

Présupposé sur la configuration

Dans cet article, nous présupposerons les éléments suivants:

• L'ensemble des machines virtuelles est dans un même sous réseau isolé d'internet.
• L'accès au cloud se fera par une seule adresse IP publique
• On utilisera indifféremment le terme serveur physique pour parler de serveur virtuel ou machine virtuelle. Ces notions réfèrent donc à un système d'exploitation windows ou à une distribution linux 
  

Première question à se poser: Quelles sont les applications que nous souhaitons héberger?

Dans la majorité des cas, les applications web sont : soit développées en langage scripté PHPLangage de programmation s’exécutant côté serveur et permettant la création dynamique de pages web ou d'APIs. / Perl / Python ; soit en langage semi compilé tel que les technologies JEEJava Entreprise Edition / .NET. Il est même souvent possible que tout ou une partie de la plateforme web soit composée de différentes technologies.

Historiquement, l'évolution des technologies pousse les architectures web à devenir de plus en plus hétérogène. Le mixité des technologies et souvent des équipes et/ou prestataires qui ont réalisés les différents composants de l'architectures rend la réalisation d'une architecture applicative de plus en plus complexe. L'arrivée des solutions cloud avec machines virtualisées permet de mieux segmenter les différents blocs de la plateforme et ainsi de mieux gérer la sécurité et la performance applicative.

Par exemple, si vous possédez une application front développée en PHP et un backoffice en JEE, il est pertinent de créer deux serveurs logiques (en l'occurrence, imaginons un apache HTTPD pour le PHP et un jboss pour le JEE). Grâce à la virtualisation, la création de deux machines virtuelles devient accessible à tous. Séparer les deux instances de serveur logique en deux serveurs « physique » permet de mieux isoler les applications et améliorer la sécurité. Tout serait pour le mieux dans le meilleur des mondes si de nouveaux problèmes ne se posaient pas. Par exemple, comment distribuer les requêtes entre ces deux machines? ou bien comment utiliser une base de données commune pour ces applications ?

Comment réaliser la mise en place d'un proxy http ?

Dans la question précédente, nous avons vu que séparer les deux serveurs devenait accessible à tous, mais qui dit deux serveurs dit deux « adresses IP » et donc le besoin de créer un reverse proxy devant permettant de répartir les requêtes en fonction de la ressource demandée. On pourrait utiliser le APACHE déjà utilisé pour servir le front PHP pour réaliser un proxy qui distribuerait les requêtes vers son propre serveur, et vers le serveur JBOSS, mais nous créerions un SPOF sur ce serveur.

Pour éviter ce problème, le plus simple est de créer un autre serveur VM (nous avons vu que la création de nouveaux serveur n'était plus un problème avec la virtualisation) en amont de ces deux machines et de créer un reverse proxy. Dans le monde de l'open source, deux proxy sont disponibles:

• Apache: Classique, performance et très configurable
• NGINX: Le nouveau venu, beaucoup plus simple, plus performant, et moins attaqué

Dans cet exemple, nous nous sommes basé sur NGINX qui offre l'avantage d'être très simple à utiliser et très performant. Imaginons donc que vous faites pointer votre DNS vers le NGINX. Maintenant, il ne vous reste plus qu'a configurer votre PROXY pour qu'il redirige vers l'une ou l'autre des machines (front PHP, ou backoffice JEE). La plus simple est souvent de faire la redirection par un sous domaine, ou bien par un context path de l'url. Votre serveur NGINX devient alors l'unique point d'entrée des requêtes vers les serveurs JBOSS et PHP, permettant alors par la même occasion, de les sécuriser. En effet, ceux-ci n'auront plus aucune interface directe avec l'internet.

Si vous accéder à votre serveur par le front NGINX, vous êtes correctement redirigé vers la bonne application. A ce moment là, nous sommes toujours dans le même situation qu'un serveur proxy installé sur le serveur PHP, et nous avons toujours un SPOF (Single Point Of Failure) au niveau du proxy, même si celui ci est maintenant isolé sur son serveur. En effet, si votre proxy NGINX tombe, vous n'avez plus accès aux deux serveurs Pour ce faire, vmWare propose une option « magique » qui permet de palier à une partie du problème. Cette option permet de passer votre machine virtuelle en Fault Tolerance HA.

De manière pratique, votre vmWare va dupliquer de manière permanente la machine virtuelle sur plusieurs hosts et en garder toujours une active et l'autre passive. En cas de défaillance du premier host, le second host prendra instantanément le relais.

Cette fonctionnalité est magique et répond à de nombreux besoin de robustesse, alors pourquoi ne pas faire ça sur toutes les machines? Essentielement car vous consommez le double de ressource systématiquement. Il faut donc limiter ce genre de pratique aux endroits ou vous en avez le plus besoin, sur des machines virtuelles très légères, ce qui est le cas d'un proxy. Il faut également se souvenir que le HA est simplement un mode de fault tolerance actif-passif, et ne permet en aucun cas de faire du load balancing entre les proxy!

Comment gérer la sécurité applicative sans firewall physique?

Autre question qui se pose rapidement, dans une architecture virtualisée, on n'a pas toujours accès à un firewall physique pour sécuriser son domaine. Comment faire? L'une des solutions les plus simple et rapide à mettre en place est d'installer sur une VM, un firewall logiciel. Une distribution très efficace et simple d'accès est la solution pfSense. pfSense permet rapidement de:

• Créer une passerelle réseau
• Firewall
• VPN ipSec
• Routage NAT
• Filtre complexe d'adressage ip (pour se protéger des attaques)

Pour plus d'information sur la configuration du firewall dans un environnement virtualisé, lire l'article suivant ainsi que celui-ci

De même, si vous mettez une machine firewall en front de votre réseau, il est nécessaire de mettre cette machine en HA (high availability) car comme le proxy vu précédemment, c'est le seul point d'entrée des requêtes sur votre réseau et donc un SPOF.

Comment partager la base de données entre les deux applications?

Si vous souhaitez garder une seule base de données entre les deux applications, deux solutions s'offrent à vous:

• Héberger la base de données sur l'une des VM applicative, et l'exposer à l'autre VM

Cette solution est à éviter car elle surcharge la machine virtuelle hébergeant déjà une application. Elle rend sensible la base de données à tout plantage du serveur du au serveur applicatif et vice versa créant un nouveau SPOF.

• Créer une nouvelle machine virtuelle pour héberger uniquement la base de données

C'est solution est évidement celle que nous allons utiliser (une machine virtuelle ne coute rien !). Elle permet de ne pas surcharger les serveurs applicatifs et de préserver l'accès à la base de données en cas de plantage d'un des serveurs applicatifs. Cette solution permet également de maitriser les performances de la base de données, qui peut demander énormément de ressources CPU.

pour l'utilisation de HAPROXY.