ORS, ORS everywhere…

Oui bon je sais, je devais continuer mes tutos sur SIP Server. Mais « nécessité fait loi », alors on va se faire une petite installation d’ORS, et ceci en mode cluster.

Pour rappel, le gros intérêt du mode cluster est que si vos besoins de traitement augmentent, vous pouvez très facilement rajouter un nouveau noeud et ainsi répartir la charge sur N+1 serveurs.

Bon, c’est pas le tout de papoter mais : let’s go !

PS : je pars du principe que vous partez d’un socle Genesys existant avec couches framework et management OK.

On commence par une installation classique

Bon tout d’abord, on rappelle la bible : https://docs.genesys.com/Documentation/OS/8.1.4/Deployment/General#Configuring_an_ORS_Cluster cette section de la doc est dédiée spécifiquement aux déploiements d’ORS en mode cluster et je dois dire que pour une fois, elle m’a semblé claire même si il faut bien faire attention aux petites lignes.De manière classique, on va commencer par récupérer le package d’installation correspondant à votre OS, récupérer les templates et créer le modèle d’application dans CME/GA/GAX.

Une fois celui-ci crée, on attaque la création de l’application elle-même. Dans le cas qui nous intéresse, je vais l’appeler ORS_N11_Pr. Petit point nomenclature, je vais le nommer comme ceci pour :

• ORS_ : bon bah ça je pense que c’est clair
• 1 car il s’agit du premier cluster ORS que je mets en place
• 1 car il s’agit du premier noeud de ce cluster
• _Pr pour indiquer que c’est le primaire. En effet, au sein de ce cluster, rien ne nous empêchera ensuite de mettre chaque noeud en primaire/backup. Overkill certes mais quand il faut…

Lors de la déclaration de l’application elle-même, pas de piège particulier. Juste bien penser dans les connexions à mettre URS, ainsi que les T-Server/SIP Server/Interaction Server pour lesquels votre ORS devra jouer des stratégies.

Ci-desssous, un exemple d’application configurée suite à son installation :

Un petit aparté durant l’installation, il vous sera demandé si vous souhaitez utiliser l' »Enhanced Orchestration Cluster Configuration ». Nous allons répondre « yes », puis donner un nom de transaction list (ici « Cluster_ORS_1 »), notons le bien.

On attaque la partie Cluster

Afin de préparer le fonctionnement en cluster, nous allons en effet créer une transaction list au nom de « Cluster_ORS_1 » dans GAX. Dans les options de cette liste, nous créons une section au nom de « cluster » et qui contiendra des ensembles clé-valeur où la clé est le nom de votre application ORS membre du cluster, et la valeur le nom du datacenter où est localisé cette application. Si vous en avez un seul datacenter, vous pouvez laisser la valeur vide ou mettre un nom générique, comme « DC1 » ci-dessous.

Dans cet exemple, j’ai donc un cluster constitué de 2 noeuds, mes applications ORS_11_Pr et ORS_12_Pr

N.B. : seuls les ORS primaires sont à indiquer dans la transaction list, pas les applications de backup.

Les plus attentifs auront noté l’application ORS_12_Pr indiqué dans le cluster, mais non créé. Et bien allons-y pour créer le nouvel objet ORS_12_Pr, le paramétrer et l’installer.

Ses paramètres étant très proches, le clonage est votre ami 😉

Une fois installé, démarrez vos 2 ORS et vous serez l’heureux « propriétaire » d’un joli cluster d’ORS 🙂

Quelques notes sur cette installation

Le but de ce tutorial était de faire une présentation rapide de l’installation d’un cluster ORS. Quelques notes additionnelles :
– Si dans les logs de votre ORS vous avez le message « Configuration error. Class [Cluster] : This node is not operational – it is not part of ORS Cluster« , il s’agit probablement d’une erreur de frappe dans votre transaction list. Partez à la chasse aux coquilles !
– Si vous avez besoin de plus de noeuds pour tenir la charge, cela n’est pas plus compliqué que d’installer un 3ème noeud puis d’indiquer celui-ci dans votre transaction list. Elle est pas belle la vie ?
– Cette transaction list vous permet également de stocker les options « autres » liées à vos ORS. Ces options prendront le pas sur celles configurées au niveau de chaque application. Pratique pour ne modifier qu’une seule fois les options, et non dans chaque application.
– En parlant des options, je n’ai pas configuré le persistent storage, qui utilise Cassandra. Pas forcément utile pour des flux froids, il peut être important pour la gestion de la persistence de session sur la voix. Mais cela sera pour un autre tuto 😉
– A l’inverse, si vous avez besoin d’ORS gérant des flux froids/tièdes, quelques options sont à modifier dans ORS (ou sa transaction list ;)) :

* orchestration\mcr-pull-by-this-node = true

* orchestration\switch-multi-links-enabled = true (si vous avez plusieurs Interaction Server gérant le même switch)
– Enfin, pour qu’URS utilise bien ORS, il est nécessaire d’ajouter à la configuration de celui-ci :
* default\Strategy = ORS