Nouvelles fonctionnalités › CA Process Automation version 04.2.00 › Améliorations apportées à la communication

Améliorations apportées à la communication

Le récapitulatif suivant porte sur les améliorations apportées à la communication.

• Communications d'agent simplifiées.
  • Auparavant, les connexions entre les orchestrateurs et les agents étaient initialisées de manière bidirectionnelle à l'aide de ports Internet non standard (7001, 7003, 8080, 8443). Cela était problématique pour les agents résidant derrière des pare-feu, des proxys et des routeurs NAT. Ce type de communication est appelé communication désapprouvée. La communication simplifiée n'était alors pas disponible.
  • La nouvelle communication simplifiée initialise les connexions de l'agent vers l'orchestrateur uniquement à l'aide de ports Internet standard (80, 443). Un orchestrateur envoie des messages à un agent à l'aide d'une connexion de socket Web persistante. Cette connexion est établie à partir de l'agent à l'aide de ports Internet standard.

    Remarque : Vous pouvez remplacer la méthode de communication désapprouvée (valeur par défaut) par la méthode de communication simplifiée pour les agents existants. Pour plus de détails sur la configuration d'agents, consultez le Manuel de l'administrateur de contenu. Configurez un équilibreur de charge qui prend en charge des connexions de socket Web. Pour plus d'informations, consultez le Manuel d'installation.

• Prise en charge de l'équilibreur de charge NGINX
  • Auparavant, Apache était l'équilibreur de charge logicielle recommandé et utilisé pour les orchestrateurs mis en cluster. Toutefois, Apache ne prend pas en charge la communication simplifiée d'agents.
  • Désormais, CA Technologies recommande d'utiliser l'équilibreur de charge logicielle NGINX, qui prend en charge la communication simplifiée. Pour consulter les avertissements, reportez-vous à la section suivante : Nouvelles recommandations relatives aux équilibreurs de charge. Le média d'installation inclut un exemple de fichier de configuration pour cet équilibreur de charge. Pour des informations sur la configuration de NGINX, reportez-vous au Manuel d'installation.

    Remarque : Vous pouvez également utiliser un autre équilibreur de charge qui prend en charge les connexions de socket Web persistantes.

• Nouvelles recommandations relatives aux équilibreurs de charge

  Les recommandations suivantes pour CA Process Automation 4.2 sont répertoriées par ordre de préférence :

  • (Préféré) Utilisez un équilibreur de charge matérielle. Par exemple, F5.
  • Utilisez un équilibreur de charge logicielle sous Linux. Par exemple, NGINX.
  • Si vous devez exécuter un équilibreur de charge logicielle sous Windows, utilisez NGINX, mais tenez compte du fait que le nombre d'agents pouvant fonctionner à l'aide de la communication simplifiée est limité à 300 environ.
• Changements apportés aux modèles Apache : avant de procéder à la mise à niveau, vous devez mettre à jour la configuration d'Apache avec les modèles mis à jour fournis sur le média d'installation.

  Remarque : A l'issue de la mise à niveau de CA Process Automation et après vérification du fonctionnement, vous pouvez installer et configurer NGINX et basculer des équilibreurs de charge. Les agents reconfigurés et redémarrés peuvent alors utiliser la communication simplifiée.

• Changements apportés à définition mise à jour d'iRule pour F5
  • Auparavant, il existait un seul pool PAMSRVR avec le port 8080 (non sécurisé) ou le port 8443 (sécurisé).
  • Il existe désormais un pool supplémentaire (PAMJETTYPOOL) qui prend en charge la communication simplifiée avec le port 80 ou 443. Si vous procédez à une mise à niveau, ajoutez le nouveau pool ; si vous effectuez la première configuration de F5, créez deux pools et ajoutez des membres avec différents ports.
• Changements apportés à l'équilibreur de charge F5 lors de la configuration de la communication sécurisée
  • Auparavant, vous pouviez utiliser un certificat autosigné et un fichier de clé pour activer la communication SSL.
  • Pour utiliser la nouvelle communication simplifiée r4.2, vous devez charger le fichier de certificat SSL à partir du magasin de clés CA Process Automation et créer des profils client et serveur qui lient ces certificats.

Améliorations apportées à la mise en cluster

Le récapitulatif suivant porte sur les améliorations apportées à la mise en cluster.

• Suppression de la dépendance du noeud principal dans l'orchestrateur de domaine mis en cluster
  • Auparavant, les dépendances sur le noeud principal (premier noeud installé) représentaient un potentiel point d'échec unique. En d'autres termes, si le noeud principal tombait en panne, ses activités n'étaient pas reprises par un autre noeud dans le cluster. Cela empêchait la haute disponibilité attendue de l'orchestrateur de domaine. Les activités qui dépendaient d'un noeud principal de l'orchestrateur de domaine actif incluaient : 1) mise en miroir de fichiers .jar nouvellement déployés, 2) installation d'agents ou d'autres noeuds de l'orchestrateur de domaine et 3) déploiement de fichiers chargés comme ressources d'utilisateur ou rapports.
  • Désormais, les dépendances ne sont plus associées au noeud principal dans un orchestrateur de domaine mis en cluster. Un orchestrateur de domaine mis en cluster fonctionne maintenant avec la haute disponibilité.
• Conséquences de la suppression de la dépendance du noeud principal sur l'iRule F5
  • Auparavant, l'iRule comprenait les variables MyPool, PrimaryIP et PrimaryPort. PrimaryIP et le PrimaryPort renvoyait au noeud principal de l'orchestrateur de domaine.
  • Désormais, MyPool est la seule variable d'iRule.
• Possibilité de configuration d'un nouveau domaine avec des paramètres de domaine et des certificats existants
  • Auparavant, le fichier Domain.xml et les certificats étaient uniquement présents sur le système de fichiers. Aussi, lorsque le domaine tombait en panne, la configuration et les certificats étaient perdus.
  • Désormais, le fichier Domain.xml et les certificats sont déplacés vers une base de données centrale. Ainsi, le point d'échec unique est supprimé si l'orchestrateur de domaine tombe en panne. Cela permet également d'améliorer les performances lors de l'accès à des données d'agent à partir de l'interface utilisateur.