.. _cluster_tutorial: ################################## Fonctionnement en grappe (cluster) ################################## Depuis sa version 0.4, Waarp Transfer est capable de fonctionner en grappe. Cela implique de diviser une même instance de *Waarp Transfer* en plusieurs sous-instances (appelées "noeuds" ou *"nodes"* en anglais) permettant de répartir la charge de transfert entre plusieurs machines, tout en continuant d'apparaitre comme une seule instance de l'extérieur. L'avantage d'un tel fonctionnement est qu'il permet non-seulement de meilleures performances quand la charge de transferts devient très importante, mais il permet également d'éviter d'éventuelles interruptions de service dans le cas où une des instances viendrait à tomber. Limitations =========== Il est cependant important de noter que, dans son implémentation actuelle, le fonctionnement en grappe de Waarp Transfer est soumis à plusieurs limitations et contraintes, et que celles-ci doivent être prises en compte lors de la décision d'installer Waarp Transfer en grappe. Ces limitations sont : 1) Tous les *nodes* doivent **impérativement** partager le même système de fichiers, sans quoi la reprise de transfert en cas d'avarie sera impossible. 2) Pour la même raison, les *nodes* doivent **impérativement** partager la même base de données. Cela assure également que les *nodes* seront bien identiques entre elles. 3) Le fonctionnement est grappe **nécessite** la présence d'un répartiteur de charge en amont des *nodes*. Ce répartiteur est nécessaire pour que les *nodes* apparaissent comme une seule instance d'un point de vue extérieur. À l'heure actuelle, *Waarp* ne fournit pas ce répartiteur de charge, une solution tierce devra donc être utilisée. 4) Bien que le fonctionnement en grappe permette d'éviter d'éventuelles interruptions de service, il est cependant impossible d'effectuer une mise-à-jour de Waarp Transfer sans interruption de service. Cela est dû au fait que, comme précisé au point n°2, les *nodes* doivent partager la même base de données, et doivent donc avoir la même version du schéma de la base de données. Installation ============ L'installation en grappe est similaire au processus d'installation de plusieurs instances classiques, à la différence près que les *nodes* partagent toutes le même fichier de configuration, la même base de données, et le même système de fichiers. Pour notre exemple, reprenons l'instance décrite précédemment dans ce guide de démarrage. Nous souhaitons maintenant dupliquer cette instance en 3 noeuds afin de pouvoir assurer un meilleur service. Nous appellerons respectivement ces noeuds *node1*, *node2* et *node3*. Dans notre exemple, les 3 noeuds tournent sur la même machine, mais la procédure est identique dans le cas où les noeuds ne sont pas sur la même machine. Configuration ============= Waarp Transfer -------------- Dans le dossier où se trouve le fichier de configuration principal de notre instance de Waarp Transfer, il nous faudra créer un fichier d'*override* de configuration pour chacun des 3 noeuds. Ces fichiers d'*override* permettent à chaque noeud d'écraser une partie de la configuration globale de l'instance avec des valeurs qui seront spécifiques à chacun des 3 noeuds. Dans notre cas, il nous faut remplacer l'adresse du serveur R66, ainsi que l'adresse du serveur REST d'administration. Pour rappel dans notre guide, le serveur R66 de Waarp Transfer avait pour adresse *127.0.0.1:6666*, et le serveur REST d'administration avait pour adresse *127.0.0.1:8080*. Nous allons donc créer 3 fichiers d'*override* dans le même dossier où se trouve le fichier de configuration principal. Ces fichiers doivent être au format *.ini*, et doivent impérativement porter le même nom que leur *node* respectif. Par conséquent, nous appelleront donc nos fichiers respectivement *node1.ini*, *node2.ini* et *node3.ini*. Pour *node1*, nous souhaitons que le serveur R66 utilise l'adresse 127.0.0.1:6661, et que le serveur REST utilise l'adresse 127.0.0.1:8081. Le fichier *node1.ini* ressemblera donc à ceci : .. code-block:: ini [Address Indirection] IndirectAddress = 127.0.0.1:6666 -> 127.0.0.1:6661 IndirectAddress = 127.0.0.1:8080 -> 127.0.0.1:8081 Pour *node2*, nous souhaitons que le serveur R66 utilise l'adresse 127.0.0.1:6662, et que le serveur REST utilise l'adresse 127.0.0.1:8082. Le fichier *node2.ini* ressemblera donc à ceci : .. code-block:: ini [Address Indirection] IndirectAddress = 127.0.0.1:6666 -> 127.0.0.1:6662 IndirectAddress = 127.0.0.1:8080 -> 127.0.0.1:8082 En enfin, pour *node3*, nous souhaitons que le serveur R66 utilise l'adresse 127.0.0.1:6663, et que le serveur REST utilise l'adresse 127.0.0.1:8083. Nous auront donc le fichier *node3.ini* suivant : .. code-block:: ini [Address Indirection] IndirectAddress = 127.0.0.1:6666 -> 127.0.0.1:6663 IndirectAddress = 127.0.0.1:8080 -> 127.0.0.1:8083 Proxy ----- Une fois les indirections d'adresse configurées sur les 3 noeuds, il ne reste plus qu'à configurer le répartiteur de charge. La marche à suivre pour cela dépendra du répartiteur choisi. *Waarp* ne fournit pas ce répartiteur de charge, une solution tierce devra donc être utilisée (telle que Nginx, ou Apache). Quelle que soit la solution choisie, celui-ci devra donc être configurer pour rediriger les connexions R66 entrantes sur 127.0.0.1:6666 vers les 3 adresses R66 de nos 3 noeuds (respectivement 127.0.0.1:6661, 127.0.0.1:6662 et 127.0.0.1:6663). De même, les connexions REST entrantes sur 127.0.0.1:8080 devront être redirigées vers les adresses REST de nos 3 noeuds (respectivement 127.0.0.1:8081, 127.0.0.1:8082 et 127.0.0.1:8083). Une fois la configuration du proxy terminée, celui-ci peut être démarré. Lancement ========= La commande pour lancer un noeud est la même que pour lancer une instance classique. Il suffit simplement d'y ajouter l'option `-i` ou ``--instance`` suivie du nom du *node*. Dans notre exemple, il faudra donc lancer la commande 3 fois avec le nom de chacun des 3 noeuds : .. code-block:: shell-session systemctl start waarp-transferd -i node1 systemctl start waarp-transferd -i node2 systemctl start waarp-transferd -i node3 Nous devrions donc avoir maintenant 3 services waarp-transferd en cours d'exécution qui écoutent chacun sur leurs ports respectifs. Pour se connecter en R66 vers la grappe, il suffit donc simplement de se connecter à l'adresse R66 du répartiteur de charge (127.0.0.1:6666). Cette connexion sera ensuite redirigée vers un des 3 noeuds de la grappe pour être traitée. De même, pour se connecter au serveur REST d'administration, il suffit simplement de se connecter à l'adresse 127.0.0.1:8080. Nous avons donc bien 3 instances de Waarp Transfer qui, de l'extérieur, apparaissent comme une seule instance de Waarp Transfer.