A la demande d'une société utilisatrice de Control-M et dans le cadre de la refonte de son architecture, nous avons étudié la possibilité de faire communiquer un Control-M/Server sur deux réseaux locaux étanches.  L'architecture mise en œuvre et le niveau de sécurité des réseaux obligeait à ce que le Control-M/Server communique avec le Control-M/Enterprise Manager via le réseau d'administration  et avec les Control-M/Agents au travers du réseau de Production (comme le montre le schéma ci-dessous). Le serveur est donc équipé de 2 cartes réseau portant des numéros IP distincts. Pour ajouter à la complexité, le Control-M/Server est installé sur un cluster et se doit d'utiliser une adresse virtuelle pour définir ses 2 cartes réseau.

Cette architecture aurait été impossible il y a encore quelques mois. Mais en version 6.4.01.300, le Control-M/Server dispose de cette nouvelle fonctionnalité. Le Fix pack 3 de la version 6.4.01 du Control-M/Server fait apparaître un paramètre de configuration nommé OUTGOING_ADDR permettant d'obliger le Control-M/Server à communiquer avec ses agents en utilisant une carte réseau spécifique. La documentation associée à ce paramètre est à ce jour très succincte (Release Note du Fix pack 3) et ne permet pas de réaliser à elle seule la configuration souhaitée.

Cependant, en combinant ce paramétrage, l'utilisation de la "persistent connection" et le paramétrage cluster (OS_PRM_HOSTNAME),  on arrive à proposer cette architecture.

Le "Local IP Hostname" configuré avec la VIP A, permet d'assurer la communication en mode cluster du Control-M/Server avec le Control-M/Enterprise Manager.

Le mode "Persistent connection" activé et le paramètre OUTGOING_ADDR défini avec la VIP B, permet au Control-M/Server d'initié une communication routée par la carte du réseau de Production.

Le paramètre OS_PRM_HOSTNAME configuré avec la VIP A permet au Control-M/server de se présenter avec un nom "cluster" aux agents pour être reconnu. C'est d'ailleurs ce nom (VIP A) qui sera utilisé pour la configuration du Control-M/Agent (Primary Control-M/Server). On prendra la précaution sur une telle configuration d'empêcher le Control-M/Agent d'initier une communication en réglant le paramètre "ALLOW_COMM_INIT" à "N".

Avec cette architecture et ce paramétrage, l'utilisation du champ NODEID à blanc dans les définitions de jobs n'est plus possible. Un control-M/Agent ne peut plus être nommé que par un seul nom (variantes DNS impossible). Le premier nom créé dans le CCM, c'est à dire celui qui initie la connection.

De plus, les serveurs situés sur le réseau d'administration ne pourront être accédé par le Control-M/Server qu'en utilisant un AgentLess. En particulier l'agent installé sur le Control-M/Enterprise Manager où sont exécutées ses servitudes.

La version 6.4.01 de Control-M a été présentée récemment par BMC Software et elle présente de nombreuses évolutions comme l'utilisation de scripts embarqués ou le support de ProstGreSQL. Mais dans cette tribune, je vais m'attarder sur les aspects qui concernent plus directement l'intégration des traitements batchs dans les processus ITSM.

On notera donc comme nouveautés :

Homogénéité des bases statistiques utilisées par les 2 composants liés à l'ITSM que sont Batch Impact Manager et Control-M/forecast.

La possibilité de réaliser des prélèvements de statistiques sur des périodes données (soldes, fin d'année, vacances, …) afin de constituer des collections applicables soit aux calculs de  Batch Impact Manager, soit aux simulations de Control-M/Forecast.

La notion de gestion de versions permettant des comparaisons et facilitant les retours arrières est un plus dans la gestion des changements

Les outils d'audit du Control-M/EM ont accès à l'historique des changements, permettant ainsi de générer des rapports de changements. Les modifications apportées aux calendriers ou par exemple aux conditions globales sont historisées.

Control-M 6.4.01 supporte Remedy 7.0 pour toutes les opérations comme le DO REMEDY par exemple.