« Architecture Azure » : différence entre les versions

De Wiki1000
Ligne 7 : Ligne 7 :
(1) : Le répartiteur Azure est state-less, c'est à dire qu'il ne tient pas compte de la session qui est propre à une instance de service. Le nom de l'hôte sur lequel la session a été ouverte est transmis à chaque requête : si un service reçoit une requête qui ne lui est pas destinée, il la fait suivre au bon destinataire. Pour cela il utilise un port http qui peut être paramétré ici : [[Fichier_de_configuration_(server)|HTTP Private Port]].
(1) : Le répartiteur Azure est state-less, c'est à dire qu'il ne tient pas compte de la session qui est propre à une instance de service. Le nom de l'hôte sur lequel la session a été ouverte est transmis à chaque requête : si un service reçoit une requête qui ne lui est pas destinée, il la fait suivre au bon destinataire. Pour cela il utilise un port http qui peut être paramétré ici : [[Fichier_de_configuration_(server)|HTTP Private Port]].


(2) :  
(2) : Le répartiteur transmet les requêtes aux services selon un algorithme qui lui est propre. Le service doit être paramétré en https.


(3) :
(3) : Le contrôleur maître stocke dans un blob la configuration et les exécutables afin que toutes les VM soient identiques.


===Gestion de l'élasticité===
===Gestion de l'élasticité===

Version du 29 avril 2014 à 14:13

Vision globale de l'architecture


(1) : Le répartiteur Azure est state-less, c'est à dire qu'il ne tient pas compte de la session qui est propre à une instance de service. Le nom de l'hôte sur lequel la session a été ouverte est transmis à chaque requête : si un service reçoit une requête qui ne lui est pas destinée, il la fait suivre au bon destinataire. Pour cela il utilise un port http qui peut être paramétré ici : HTTP Private Port.

(2) : Le répartiteur transmet les requêtes aux services selon un algorithme qui lui est propre. Le service doit être paramétré en https.

(3) : Le contrôleur maître stocke dans un blob la configuration et les exécutables afin que toutes les VM soient identiques.

Gestion de l'élasticité

La gestion de l'élasticité dans Azure s'appuie sur la notion de VM maître et esclave.

Définitions

  • VM maître : machine virtuelle sur laquelle le contrôleur 1000 est exécuté avec le rôle "maître"
  • VM esclave : machine virtuelle sur laquelle le contrôleur 1000 est exécuté avec le rôle "esclave". Le contrôleur n'est pas visible dans l'administration des services, il est piloté par le contrôleur maître.
  • blob Azure : blob lié au compte Azure et utilisé par Sage 1000 pour la gestion de l'élasticité. La configuration et les exécutables y sont stockés.

Principe général

Une VM maître est en relation avec plusieurs VM esclave.

Les fichiers de configurations (server.ini, controller.ini) des VM esclaves sont automatiquement copiés depuis la VM maître, il ne faut pas les modifier manuellement.

Propagation du paramétrage

Les mises à jours sont effectuée sur la VM maître.

Lorsque un contrôleur d'une VM maître modifie le fichier server.ini il le stocke dans le blob Azure . (c'est pourquoi il ne faut pas le modifier manuellement).

La modification est propagée aux VM esclaves.

Tip : Cas d'une VM non démarrée lors de la mise à jour :

Lorsque, sur une VM esclave, le contrôleur démarre un service il vérifie la date du server.ini et le déploie le cas échéant.


Propagation des mises à jour

Les mises à jours sont effectuée sur la VM maître.

Lorsque un contrôleur maître effectue une mise à jour du serveur (patch outil), il stocke la mise à jour dans le blob Azure.

L'ordre de mise à jour est propagé aux VM esclaves qui utilisent la version dans le blob Azure.

Tip : Cas d'une VM non démarrée lors de la mise à jour :

Lorsque, sur une VM esclave, le contrôleur démarre un service il vérifie la date du fichier Sage1000Server.zip dans le blob Azure et le déploie le cas échéant.

Scheduler Azure

Le Planificateur Azure permet d'automatiser le démarrage et l'arrêt de VM esclaves (par exemple la nuit).

L'agent de synchronisation

Cet agent permet d'écrire et de lire dans une file d'attente dans un blob de votre compte Azure, permettant ainsi l'échange de données entre Azure et votre SI. Un automate 1000 peut ainsi consommer des données dans Azure issues de votre SI.