Utilisez les recommandations relatives aux ressources VMware comme point de départ pour la planification du déploiement de vRealize Automation.

Après les tests initiaux et le déploiement en production, continuez à surveiller les performances et allouez des ressources supplémentaires si nécessaire, de la manière décrite dans Évolutivité de vRealize Automation.

Authentification

Lors de la configuration de vRealize Automation, vous pouvez utiliser le connecteur de gestion d'annuaires par défaut pour l'authentification des utilisateurs ou vous pouvez spécifier un fournisseur d'identité SAML préexistant pour prendre en charge une expérience d'authentication unique.

Si une authentification à deux facteurs est requise, vRealize Automation prend en charge l'intégration avec RSASecurID. Lorsque ce point d'intégration est configuré, les utilisateurs sont invités à entrer leur ID et leur code secret.

Éléments à prendre en compte pour l'équilibrage de charge

Utiliser la méthode LRT (Least Response Time) ou Round-Robin pour équilibrer le trafic sur les dispositifs vRealize Automation et les serveurs Web de l'infrastructure. Activez l'affinité de session ou la fonctionnalité de session sticky pour diriger les demandes suivantes de chaque session unique vers le même serveur Web dans le pool d'équilibrage de charge.

Vous pouvez utiliser un équilibrage de charge pour gérer le basculement pour le service de gestionnaire, mais n'utilisez pas d'algorithme d'équilibrage de charge, car seulement un service de gestionnaire est actif à la fois. En outre, n'utilisez pas l'affinité de session lors de la gestion du basculement avec un équilibrage de charge.

Utiliser les ports 443 et 8444 lors de l'équilibrage de charge du dispositif vRealize Automation. Pour le site Web d'infrastructure et le service de gestionnaire d'infrastructure, seul le port 443 doit faire l'objet d'un équilibrage de charge.

Bien que vous puissiez utiliser d'autres équilibrages de charge, NSX, le matériel F5 BIG-IP et F5 BIG-IP Virtual Edition sont testés et leur utilisation est recommandée.

Reportez-vous à la documentation de vRealize Automation pour plus d'informations sur la configuration des équilibrages de charge.

Déploiement d'une base de données

Dans la version 7.0 et les versions ultérieures, vRealize Automation met automatiquement la base de données de dispositifs en clusters. Tous les nouveaux déploiements de la version 7.0 et des versions ultérieures doivent utiliser la base de données de dispositifs interne. Les instances de vRealize Automation mises à niveau vers la version 7.1 ou version ultérieure doivent fusionner leurs bases de données externes dans la base de données du dispositif. Reportez-vous à la documentation du produit vRealize Automation 7.2 pour plus d'informations sur le processus de mise à niveau.

Pour des déploiements de production des composants d'infrastructure, utilisez un serveur de base de données dédié pour héberger les bases de données Microsoft SQL Server (MSSQL). vRealize Automation impose que les machines qui communiquent avec le serveur de base de données soient configurées pour utiliser Microsoft Distributed Transaction Coordinator (MSDTC). Par défaut, MSDTC a besoin du port 135 et des ports 1024 à 65535.

Pour plus d'informations concernant la modification des ports MSDTC par défaut, consultez l'article de la base de connaissances Microsoft Configuration de Microsoft DTC (Distributed Transaction Coordinator) pour fonctionner avec un pare-feu disponible à l'adresse https://support.microsoft.com/fr-fr/kb/250367

vRealize Automation prend en charge les groupes SQL AlwaysON uniquement avec Microsoft SQL Server 2016. Lors de l'installation de SQL Server 2016, la base de données doit être créée en mode 100. Si vous utilisez une ancienne version de Microsoft SQL Server, utilisez une instance de cluster de basculement avec des disques partagés. Pour plus d'informations sur la configuration des groupes SQL AlwaysOn avec MSDTC, reportez-vous à https://msdn.microsoft.com/fr-fr/library/ms366279.aspx.

Configuration de la collecte de données

Les paramètres de collecte de données par défaut fournissent un bon point de départ pour la plupart des implémentations. Après le déploiement en production, continuez à surveiller les performances de la collecte des données pour déterminer si vous devez procéder à des ajustements.

agents proxy

Pour garantir des performances optimales, déployez les agents dans le même centre de données que le point de terminaison auquel ils sont associés. Vous pouvez installer des agents supplémentaires pour augmenter le débit et la simultanéité du système. Les déploiements distribués peuvent avoir plusieurs serveurs d'agents répartis à travers le monde.

Lorsque des agents sont installés dans le même centre de données que leur point de terminaison associé, vous pouvez constater une augmentation des performances de collecte des données de 200 pour cent en moyenne. La durée de collecte mesurée inclut uniquement le temps consacré au transfert des données entre l'agent proxy et le service de gestionnaire. Elle n'inclut pas le temps requis par le service de gestionnaire pour traiter les données.

Par exemple, vous déployez actuellement le produit sur un centre de données de Palo Alto et vous avez des points de terminaison vSphere à Palo Alto, Boston et Londres. Dans cette configuration, les agents proxy de vSphere sont déployés à Palo Alto, Boston et Londres pour leurs points de terminaison respectifs. Par contre, si les agents sont déployés uniquement à Palo Alto, il se peut que vous notiez une augmentation de 200 pour cent de la durée de collecte des données pour Boston et Londres.

Configuration de Distributed Execution Manager

En général, placez les DEM (Distributed Execution Manager) le plus près possible de l'hôte du gestionnaire de modèles. L'orchestrateur DEM doit disposer en tout temps d'une forte connectivité réseau au gestionnaire de modèles. Créez deux instances de l'orchestrateur DEM, un pour le basculement, et deux instances de DEM Worker dans votre centre de données principal.

Si une instance de DEM Worker doit exécuter un workflow spécifique à un emplacement, installez l'instance à cet emplacement.

Attribuez des compétences aux workflows et aux DEM appropriés afin que ces workflows soient toujours exécutés par des DEM du même emplacement. Pour plus d'informations sur l'affectation de compétences aux workflows et aux DEM en utilisant la console du concepteur vRealize Automation, reportez-vous à la documentation sur l'extensibilité de vRealize Automation. Comme cette fonction est avancée, vous devez concevoir votre solution de façon qu'une communication WAN ne soit pas requise entre le DEM opérationnel et les services distants, par exemple vRealize Orchestrator.

Pour obtenir des performances optimales, installez les DEM et les agents sur des machines distinctes. Pour plus d'informations sur l'installation d'agents vRealize Automation, reportez-vous à la documentation de vRealize Automation Installation de vRealize Automation 7.2.

vRealize Orchestrator

Utilisez l'instance interne de vRealize Orchestrator pour tous les nouveaux déploiements. Si nécessaire, les déploiements hérités peuvent continuer à utiliser une instance externe de vRealize Orchestrator. Reportez-vous à https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147109 pour la procédure d'augmentation de la mémoire allouée à l'instance interne de vRealize Orchestrator.

Pour optimiser les performances du produit, consultez et appliquez les directives de configuration décrite dans le document vRealize Automation Coding Design Guide avant d'importer du contenu vRealize Orchestrator dans des déploiements de production.