[z/OS]

Routage syxplex des demandes de travail

Le produit utilise le serveur de noms de domaine (DNS) pour acheminer les demandes de travail à l'intérieur d'une cellule. Vous pouvez utiliser ce dernier à la place d'un distributeur sysplex pour distribuer la charge de travail et équilibrer les demandes destinées à un même nom d'hôte sur plusieurs adresses IP (une par démon).

Le serveur DNS accepte un nom d'hôte générique du client et mappe le nom vers un système spécifique. Il utilise la fonction de gestion de la charge de travail (WLM) pour sélectionner le système disponible le mieux adapté. Cette fonction analyse l'état en cours de la cellule et prend en compte plusieurs facteurs, tels que l'unité centrale, la mémoire et l'utilisation des E/S, pour identifier le système le mieux à même de traiter du travail supplémentaire. Le serveur DNS achemine ensuite la demande du client vers ce système. L'utilisation de la fonction de gestion de la charge de travail et du serveur DNS est facultative. Elle permet cependant d'éliminer un point unique de défaillance.

WebSphere Application Server for z/OS, serveur DNS (domain name server) et gestion de la charge de travail

Chaque système contenu dans une cellule comporte le module d'exécution du produit. Tous les systèmes contiennent un démon du service de localisation, un agent de noeud et des serveurs d'applications métier. Un système fait office de gestionnaire de déploiement pour la cellule. Le client utilise le protocole CORBA GIOP (General Inter-ORB Protocol) pour envoyer des demandes au produit. Le démon du service de localisation agit en tant qu'agent du service de localisation. Il accepte des demandes de localisation contenant des clés d'objet. Le démon du service de localisation extrait le nom du cluster de serveurs de la clé d'objet, puis fournit le nom du serveur à la fonction de gestion de la charge de travail. Cette dernière choisit dans la cellule le serveur le mieux à même de traiter la demande. Le démon du service de localisation fusionne les informations IOR (Interoperable Object Reference) spécifiques liées au serveur choisi avec les informations de clé d'objet stockées dans l'identificateur IOR d'origine. A la suite de cette fusion, l'identificateur IOR direct est renvoyé au client. L'ORB du client utilise cette référence renvoyée pour établir la connexion IOR au serveur qui détient l'objet recherché.

Le mécanisme de transport utilisé parle produit varie selon que le client est local ou distant. Un client qui ne s'exécute pas sur le même système z/OS que le serveur d'applications est un client distant qui nécessite un transport TCP/IP. Si le client est local, le transport s'effectue par le biais d'un appel de programme. Le transport local est plus rapide car il ne demande pas de déplacement physique sur le réseau, il évite les transformations de données, simplifie la conversion de paramètres des demandes et utilise les fonctions RACF (Resource Access Control Facility) optimisées plutôt d'avoir à appeler Kerberos ou SSL (Secure Sockets Layer).


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_sysreq
Nom du fichier : crun_sysreq.html