« Architecture Azure » : différence entre les versions

Dernière version du 19 mars 2019 à 09:07

Vision globale de l'architecture

Les composants :

Répartiteur Azure (Load balancer)
Point d'équilibrage de charge (Load balancer set)
Machine virtuelle Service ligne 1000 (Maitre)
Machine(s) virtuelle(s) Service ligne 1000 (Esclaves)
Compte de stockage Azure

Les flux:

Le flux entrant (https://mycloud1000.cloudapp.net/...) est routé par les DNS vers le répartiteur de charge Azure.
Le répartiteur Azure distribue les flux (https) sur chaque machine virtuelle du point d'équilibrage de charge, suivant un algorithme round-robin.
Les flux sont routés entre chaque machines virtuelles par le service 1000 en fonction des sessions (http), une session ouverte sur une machine reste servie par cette machine.
Les machines virtuelles mettent à jour leur configuration à partir d'un référentiel stocké dans un container Azure.

Gestion de la scalabilité

La scalabilité est obtenue en rajoutant des machines virtuelles dans la configuration.

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.

Container Azure

Container lié au compte Azure et utilisé par Sage 1000 comme référentiel de la configuration. La configuration et les exécutables y sont stockés en vu d'être déployé sur chaque machine virtuelle.

Principe général

Le rôle de la machine maître est de maintenir la configuration.

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 initial

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).

Voir aussi:

@@ Ligne 1 : / Ligne 1 : @@
-==Gestion de l'élasticité==
+===Vision globale de l'architecture===
-La gestion de l'élasticité dans Azure s'appuie sur la notion de VM maître et esclave.
+[[image:Architecture-load-balancer-azure.png]]
-===Définitions===
+Les composants :
+* Répartiteur Azure (Load balancer)
+* Point d'équilibrage de charge (Load balancer set)
+* Machine virtuelle Service ligne 1000 (Maitre)
+* Machine(s) virtuelle(s) Service ligne 1000 (Esclaves)
+* Compte de stockage Azure
-* VM maître : machine virtuelle sur laquelle le contrôleur 1000 est exécuté avec le rôle "maître"
+Les flux:
-* VM esclave : machine virtuelle sur laquelle le contrôleur 1000 est exécuté avec le rôle "esclave"
+# Le flux entrant (https://mycloud1000.cloudapp.net/...) est routé par les DNS vers le répartiteur de charge Azure.
+# Le répartiteur Azure distribue les flux (https) sur chaque machine virtuelle du point d'équilibrage de charge, suivant un algorithme round-robin.
+# Les flux sont routés entre chaque machines virtuelles par le service 1000 en fonction des sessions (http), une session ouverte sur une machine reste servie par cette machine.
+# Les machines virtuelles mettent à jour leur configuration à partir d'un référentiel stocké dans un container Azure.
-===Principe général===
+===Gestion de la scalabilité===
+La scalabilité est obtenue en rajoutant des machines virtuelles dans la configuration.
-Une VM maître est en relation avec plusieurs VM 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.
+* '''Container Azure'''
+: Container lié au compte Azure et utilisé par Sage 1000 comme référentiel de la configuration. La configuration et les exécutables y sont stockés en vu d'être déployé sur chaque machine virtuelle.
-Les fichiers de configurations (server.ini, controller.ini) des VM esclaves sont automatiquement copiés depuis la VM maître, il est inutile de les modifier donc.
+====Principe général====
+Le rôle de la machine maître est de maintenir la configuration.
-===Propagation du paramétrage===
+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.
-Lorsque un contrôleur maître modifie le fichier  server.ini il le stocke dans le blob . (c'est pourquoi il ne faut pas le modifier manuellement).La modification est propagée aux contrôlleurs esclaves.
+====Propagation du paramétrage initial====
+Les mises à jours sont effectuée sur la '''VM maître'''.
-Cas d'une VM non démarrée lors de la mise à jour :
+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).
-Lorsque un contrôleur esclave démarre un service il vérifie la date du server.ini et le déploie le cas échéant.
-===Propagation des mises à jour===
+La modification est propagée aux '''VM esclaves'''.
-Lorsque un contrôleur maître effectue une mise à jour du serveur (patch outil), il stocke la mise à jour dans le blob.
+{{tip|Cas d'une VM non démarrée lors de la mise à jour :
-La modification est propagée aux contrôlleurs esclaves.
-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.
-Lorsque un contrôleur esclave démarre un service il vérifie la date du patch outil et le déploie le cas échéant.
-===Scheduler Azure ===
+}}
-==Gestion des mises à jours==
+====Propagation des mises à jour====
-Les mises à jours sont effectuée sur la VM maître.
+Les mises à jours sont effectuée sur la '''VM maître'''.
-==L'agent de synchronisation==
+Lorsque un contrôleur maître effectue une mise à jour du serveur (patch outil), il stocke la mise à jour dans le '''blob Azure'''.
-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.
+L'ordre de mise à jour est propagé aux '''VM esclaves''' qui utilisent la version dans le '''blob Azure'''.
-Un automate 1000 peut ainsi consommer des données dans Azure issues de votre SI.
+{{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 [http://azure.microsoft.com/fr-fr/services/scheduler/ Planificateur Azure] permet d'automatiser le démarrage et l'arrêt de '''VM esclaves''' (par exemple la nuit).
+Voir aussi:
+* [[Configuration du Serveur HTTP derrière un répartiteur de charge]]
+* [[Nom_de_domaine_personnalisé_(azure)|Nom de domaine personnalisé]]
+[[Category:Version710]]
+[[category:Azure]]
+[[Category:Latest]]