Nous avons déjà parlé du fonctionnement de JMS mais nous n'avons pas forcement traité la question de la haute disponibilité. Mais qu'est ce que la haute disponibilité?
La haute disponibilité [HD] est la capacité d'un système a fournir un service selon un taux de disponibilité pre-déterminer.
Cela semble un peu de la paraphrase mais cela se traduit par quelles solutions doivent ou peuvent être mises en oeuvre afin de garantir le rendu d'un service par un système?
Pour répondre a cette problématique, il existe une approche simple, la duplication. il suffit de fournir le service de manière répliquée de façon à palier à des éventuelles erreurs et crash.
Dans le cadre des systèmes a base de web-services, souvent la haute disponibilité est couplé a des systèmes de répartition de charge [weblogic-WS-LB]. Le flux http/https est adressé sur un load-balancer qui a pour charge de rediriger ces flux successivement sur les différents serveurs/containeurs d'un cluster construis pour rentre le service attendu.
Dans ce genre d'architecture, le principe du load balancing permet d'inclure le principe de haute disponibilité car l’interruption d'un serveur du cluster ne remet pas en question le rendu du service si le cluster contient d'autres serveurs actifs puisque même en cas de crash, le serveur consommateur du service pourra refaire sa demande.
Dans le cas de JMS, les choses ne sont pas équivalentes. En effet, si l'on se demander ce que signifie la haute-disponibilité, on peut facilement imaginé l'utilisation d'une file JMS accessible dans le broker par les serveurs d'un cluster. Ainsi, le premier libre de travailler sera le premier a se servir auprès du broker et on pourrait considérer que cela répond au problème.
Pourtant si ceci permet de simuler un mécanisme de load balancing, contrairement aux webservices ou la communication est synchrone, dans JMS qui lui est asynchrone, on ne peut considérer qu'un mécanisme de load balancing fournissent a lui seul la garantir de haute disponibilité.
Pourquoi? c'est simple, même face a une file JMS, comme le service est asynchrone, la réception d'un message ne peut être retenté par un émetteur dans le cas d'une interruption du serveur qui était sensé réceptionner le message.
Ainsi si un message est consommé par un serveur d'un cluster mais que celui ci crash avant d'avoir eut le temps de faire son traitement dessus, celui ci est perdu alors qu'il aurait pu être potentiellement traité par un autre serveur du cluster.
Comment faire face a ce problème? Et bien en réalisant au moment de la consommation du message un enregistrement de celui ci dans une base de données partagée par l'ensemble des serveurs du cluster offrant le service de traitement.
Avec ce mécanisme, si le serveur ayant réceptionné le message crash alors comme celui ci est stocké en base, il peut être rechargé par un autre serveur du cluster pour que son traitement soit quand même réalisé.
Comment mettre en oeuvre cela dans weblogic? En utilisant les quelques composants spécifiques oracle [oracle-JMS], [oracle-docs] suivant:
- un Server JMS [weblogic-jms],
- une file distribuée [UDF]
- un bridge (avec une source distante et une destination local)
Avec cette architecture, décrite dans le schéma précédent, c'est le bridge qui va récupérer les messages qui seront déposé dans la file distribuée et gérée par le Serveur JMS. Il va donc en profiter pour stoker le message dans la base de données dont il dispose (on préférera bien sur une vrai base et non une file store sinon ce n'est pas de la HD) et ensuite, selon la règle de loadbalancing configurée, il va déposé ce message dans une des files proxy associées a chaque serveur managé du cluster.
Alors bien sur, il est important de bien comprendre que haute disponibilité ne signifie pas haute vélocité (qui généralement se gère par la répartition de charge pour éviter les goulots d’étrangement) mais malgré la multiplicité des serveurs qui peuvent être présent dans le cluster, il faut bien comprendre que l'augmentation des intermédiaire et des accès aux bases ne peut que ralentir les temps de traitement des messages [WL-perf].
Références:
[HD] https://fr.wikipedia.org/wiki/Haute_disponibilit%C3%A9[oracle-JMS] https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/08-JMS--4468/jms.htm
[oracle-docs] https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/12_2_1/01-23-001-ConfigJMSResources/Create_JMS_Resources.html
[weblogic-jms] https://docs.oracle.com/cd/E24329_01/web.1211/e24387/fund.htm#JMSPG116
[weblogic-WS-LB] http://www.catgovind.com/weblogic/setting-up-weblogic-load-balancer-12c/
[WL-perf] http://blog.aliecom.com/jms-weblogic-concept-performance/
[UDF] http://middlewaremagic.com/weblogic/?p=3747
Aucun commentaire:
Enregistrer un commentaire