CSA : Serveurs d'applications, clusters, messagerie de multidiffusion et équilibreurs de charge (Sur site uniquement)

ccppmop159
Configurez la messagerie de multidiffusion, les équilibreurs de charge et la persistance des sessions (sessions permanentes). La fonctionnalité CSA permet également de réaliser une mise à l'échelle, de partager des disques, de distribuer des fichiers aux serveurs ou encore de gérer plusieurs applications ou instances de services d'arrière-plan. Vous pouvez également configurer des bases de données de rapports dédiées, procéder à la mise en cluster de la base de données Oracle et régler les ordinateurs virtuels Java Sun HotSpot.
2
Mise à l'échelle de
PPM classique
La
mise à l'échelle
constitue une activité complexe d'identification des services devant être exécutés et des ordinateurs à utiliser pour cette opération. La mise à l'échelle en amont ou en aval requiert l'équilibrage fiable des performances. Les installations de
PPM classique
, y compris les plus simples, incluent plusieurs ordinateurs. Par exemple, une installation présente généralement la configuration suivante :
  • Un serveur pour la base de données et un autre pour le reste des composants ou
  • Un ordinateur pour l'installation de
    PPM classique
    , qui se connecte à un centre de données appartenant à un groupe chargé de la gestion en externe de la base de données.
Les installations de taille moyenne à grande de
PPM classique
, selon les exigences de performance et de fiabilité, englobent habituellement des services redondants qui s'exécutent sur plusieurs ordinateurs dédiés.
Messagerie de multidiffusion
PPM classique
fait un usage intensif du serveur de messagerie de multidiffusion dans un cluster. Le service de balises est un service d'amorçage qui s'exécute sur tous les ordinateurs gérés dans un cluster. Il est utilisé pour la gestion et la surveillance des services
PPM classique
sur chaque zone. Le service de balises sert également à appliquer les patchs et les mises à niveau livrés à partir du serveur d'applications
PPM classique
.
Les services de Balise emploient un mécanisme de détection dynamique à l'aide de la multidiffusion. Chaque service de balises envoie un message de détection toutes les 5 secondes pour signaler sa présence à tous les serveurs qui écoutent dans le cluster. L'outil d'administration système
PPM classique
écoute ces messages de détection de Balise, en les utilisant pour enregistrer les noeuds de cluster actifs. Lorsqu'il reçoit un message de détection en provenance du service de balises, l'outil d'administration du système de
PPM classique
vérifie le mot de passe du service de balises par rapport à son propre mot de passe. Si la vérification réussit, l'outil d'administration du système de
PPM classique
ajoute le serveur à sa liste de serveurs.
L'outil d'administration du système de
PPM classique
envoie également une commande ping à chaque service de balises de façon directe et à un intervalle de dix (10) secondes afin de déterminer si la balise est active. Cette commande ping est un message TCP (monodiffusion) ; un message par service de balises enregistré est donc envoyé sur le réseau. La multidiffusion offre l'avantage suivant : il permet d'envoyer un unique message de multidiffusion sur le réseau à plusieurs parties intéressées. Ce message étant de type UDP (et non TCP), il est plus léger. Le message de monodiffusion doit être envoyé sur le réseau une fois pour chaque partie intéressée. La multidiffusion est donc parfaite pour les applications de détection et de surveillance dynamiques comme le service de balises.
Le service de balises n'est pas le seul à utiliser la multidiffusion. En effet, les services de gestion du cache disponibles sur les serveurs d'applications et d'arrière-plan diffusent leurs propres messages dans le but de maintenir la cohérence du cache. Ces messages ne contiennent pas de données réelles. Ils informent uniquement les serveurs distants lorsque les données résidentes sont caduques et doivent être rechargées à partir de la base de données. Ce processus est appelé "vidage du cache". Chaque fois qu'un cache est vidé sur un serveur donné dans un cluster, un message est envoyé sur le réseau. Tous les autres services app et bg reçoivent le message qui les informe qu'ils doivent vider les données dans leur propre cache.
PPM classique
utilise un thread de surveillance de session pour empêcher les sessions sur des serveurs différents d'expirer prématurément. Toutes les 5 minutes, ce thread diffuse un message plus long contenant des ID de session actifs. Lorsqu'une session n'est plus active sur un serveur, elle est vidée à partir de tous les serveurs. Lorsqu'une session reste active, elle est marquée comme telle sur tous les autres serveurs pour les empêcher de déconnecter l'utilisateur.
Les serveurs d'un cluster
PPM classique
doivent pouvoir envoyer et recevoir des messages de multidiffusion. Dans un sous-réseau standard, ces opérations sont autorisées par défaut.
Nous vous recommandons de placer tous les serveurs dans le même sous-réseau. Si vous êtes obligé d'utiliser des serveurs à des emplacements différents avec des sous-réseaux différents, créez un pont de multidiffusion entre eux.
Cette pratique ressemble à l'ajout de trafic UDP supplémentaire. Toutefois, lorsque vous comparez le volume de données acheminé entre la base de données, le serveur de rapports, les serveurs d'applications et les clients, la messagerie du cluster est moindre. Le trafic supplémentaire représente un faible pourcentage du trafic réseau global. Souvent, les personnes qui entendent parler de diffusion pensent que leurs réseaux sont surchargés. Le fait est que tout le trafic réseau est diffusé. A l'instar des messages UDP (multidiffusion), tous les messages TCP (monodiffusion) sur un sous-réseau concernent tous les noeuds dans le sous-réseau. La différence réside dans le fait que les messages TCP sont deux à trois fois plus volumineux que les messages UDP. La remise des messages TCP requiert plusieurs établissements d'une liaison par paquet, c'est pourquoi les messages TCP sont plus volumineux. En outre, ces messages de multidiffusion dans
PPM classique
sont minuscules comparés à la demande de base de données moyenne. Avec plusieurs serveurs d'application, d'arrière-plan et de génération de rapports sur un système haute performance, des centaines de demandes de base de données sont réalisées par seconde. Les petits messages UDP qui se déclenchent par serveur toutes les 5 secondes ne sont rien en comparaison.
Clarity
a introduit JGroups dans l'architecture pour contrôler la messagerie de multidiffusion au niveau application. Vous pouviez auparavant exécuter le niveau application sans la multidiffusion, mais elle est désormais beaucoup plus sollicitée par le moteur de processus en arrière-plan. Ces deux services ne s'exécuteraient probablement pas comme attendu.
Clarity
14.x et les versions plus récentes requièrent généralement la multidiffusion pour être actives au niveau du routeur et permettre aux services de cluster
Clarity
de communiquer correctement.
Equilibreurs de charge et persistance de session (sessions permanentes)
PPM classique
prend en charge les équilibreurs de charge matériels ou logiciels.
PPM classique
est véritablement sans état et conçu pour fonctionner avec un tourniquet et d'autres modèles de distribution. Toutefois, il est plus efficace en termes de performances et de mémoire avec les sessions d'utilisateur qui restent sur un seul serveur. L'ajout de serveurs d'applications supplémentaires améliore les performances.
La persistance de session est requise dans un environnement avec équilibrage de charge. Cette fonctionnalité est obligatoire, quel que soit l'algorithme utilisé ou le nombre de ressources présentes sur le serveur.
Pour illustrer ce processus, imaginons qu'un algorithme d'équilibrage de charge étend les requêtes individuelles pour une session d'utilisateur unique sur cinq serveurs d'applications. Dans ce cas, chaque serveur charge les données de cette session d'utilisateur et les met en cache. Le volume de mémoire nécessaire est cinq fois plus élevé qu'en activant la fonctionnalité de persistance de session afin que la session d'utilisateur reste dans un seul serveur.
Nous vous recommandons d'activer l'option Persistance de session sur l'équilibreur de charge.
Configurez l'équilibreur de charge de façon à ce qu'il utilise la fonction optionnelle de persistance de session. La persistance de session optionnelle envoie des demandes à partir de la même session d'utilisateur et vers le même serveur. Si ce serveur est surchargé ou si un autre serveur est inactif, il déplace l'adhérence du serveur surchargé au serveur inactif. Du fait qu'il est sans état, le logiciel
PPM classique
prend entièrement en charge ce processus. De plus, si un serveur surchargé tombe en panne, ces sessions ne sont pas perdues. En supposant que l'équilibreur de charge détecte correctement le serveur tombé en panne et redirige les demandes vers un autre serveur, ces sessions d'utilisateur sont entièrement disponibles sur le nouveau serveur.
Partage des disques
Dans un cluster
PPM classique
, plusieurs services app et bg doivent utiliser le même disque pour l'indexation de recherche. Sauf si les fichiers sont stockés dans la base de données, les services doivent également utiliser le même disque pour stockage de documents. Dans l'outil d'administration du système de
PPM classique
, assurez-vous que chaque serveur comportant des services d'applications ou d'arrière-plan pointe la propriété Répertoire d'index de recherche vers le même disque partagé. La propriété Répertoire de stockage des fichiers doit aussi pointer vers le même disque partagé, sauf si vous stockez les fichiers dans la base de données.
Vous pouvez partager plus efficacement des disques à l'aide d'une solution SAN (Storage Area Network) ou NAS (Network Attached Storage). Le partage de fichiers Unix NFS ou Windows est également acceptable.
Distribuer des fichiers aux serveurs dans un cluster
Permet de distribuer les fichiers mis à jour sur tous les serveurs inclus dans le cluster. Parmi les fichiers mis à jour figurent les fichiers présents sur le serveur d'applications qui sont mis à jour via la personnalisation des thèmes de l'interface utilisateur ou l'installation d'un correctif, d'un patch ou d'une mise à niveau.
Vous pouvez également cliquer sur Journaux NSA et choisir nsa-ca.log pour afficher le statut de la distribution. Lorsque la vérification est terminée, la fenêtre de statut se ferme et la page parente s'affiche. La page de distribution indique la dernière date et version distribuée.
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système de
    PPM classique
    .
  2. Ouvrez Distribution et cliquez sur Tout distribuer.
    Cette option distribue tous les fichiers mis à jour sous le répertoire d'accueil de
    PPM classique
    .
  3. Sélectionnez un ou plusieurs serveurs et cliquez sur Distribuer.
Plusieurs instances du service Application ou Arrière-plan
Si vous utilisez des ordinateurs big-iron dotés de grandes quantités de mémoire physique disponible, exécutez plusieurs instances des services app et bg sur ces ordinateurs. Du point de vue de
PPM classique
, cette opération équivaut à exécuter des services sur deux ordinateurs différents. Vous pouvez utiliser l'alimentation maximum d'un ordinateur, tout en profitant de l'amélioration des performances et de la fiabilité rendue possible grâce à l'utilisation de plusieurs services.
L'outil CSA facilite l'exécution de plusieurs instances grâce à une action de clonage. Cette action crée une copie du service app ou bg souhaité avec des ports et des noms de service disponibles incrémentés afin d'éviter les conflits.
Après avoir cloné un service, vous pouvez démarrer, arrêter, ou gérer la nouvelle instance de service de la même façon que si vous utilisiez le service d'origine.
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système.
  2. Ouvrez la page d'accueil et cliquez sur Tous les services.
  3. Activez la case à cocher pour le type de service que vous souhaitez cloner et cliquez sur Cloner.
  4. Le cas échéant, accédez au serveur sur lequel vous avez créé un service et modifiez les paramètres clonés.
Configuration d’une source de données externe dédiée
Vous pouvez configurer
PPM classique
pour utiliser une base de données secondaire pour exécuter des rapports. Assurez-vous que la base de données secondaire est synchronisée avec votre base de données
PPM classique
de production. Des problèmes peuvent survenir lorsque la base de données de génération de rapports est trop éloignée de la base de données de production. Par exemple, les utilisateurs ou les données d'instance à inclure dans le rapport n'existent pas dans la base de données de génération de rapports.
Lorsqu'un rapport est configuré comme spécifié dans la procédure ci-dessous, il est exécuté uniquement pour la base de données de génération de rapports. Toutes les tables requises par le rapport, y compris les tables d'utilisateur et de sécurité, doivent être synchronisées. Si vous synchronisez un sous-ensemble de tables de base de données de production, sélectionnez les tables adéquates pour la prise en charge des rapports.
Procédez comme suit :
  1. Connectez-vous à l'outil d'administration du système. Dans la page d'accueil, cliquez sur Serveurs.
  2. Cliquez sur l'icône Propriétés du serveur à configurer.
  3. Cliquez sur le sous-onglet Base de données.
  4. Dans la section Connexion interne : Niku, cliquez sur Nouvelle connexion externe.
  5. Complétez les propriétés appropriées pour votre base de données de génération de rapports :
    • ID
      Définit l'ID utilisée pour identifier ultérieurement cette connexion.
    • Nom du service
      Fait référence à une entrée TNS valide (Oracle) ou à une entrée ODBC (MS SQL Server) sur le serveur de génération de rapports.
  6. Enregistrez les modifications.
  7. Cliquez sur le sous-onglet Rapports.
  8. Remplissez le champ suivant :
    • ID de la base de données
      ID de la base de données
      PPM classique
      utilisé pour récupérer les informations sur la base de données lors de l'exécution de rapports. Cet ID correspond aux ID des connexions de base de données définis sur la page de base de données
      Serveur : Propriétés
      .
      Valeurs
      : Niku et System
      Valeur par défaut
      : Niku
      Obligatoire
      : Non
  9. Enregistrez les modifications.
  10. Répétez les étapes précédentes pour tous les serveurs présents dans votre cluster
    PPM classique
    .
  11. Redémarrez tous les services d'applications (app)
    PPM classique
    et d'arrière-plan (bg)
    PPM classique
    inclus dans votre cluster.
  12. Sur chaque serveur de génération de rapports dans votre cluster :
    1. Créez une entrée TNS (Oracle) ou une entrée ODBC (SQL Server) avec les propriétés de connexion appropriées pointant vers votre serveur de base de données de génération de rapports dédié.
    2. Assurez-vous que le nom que vous choisissez correspond au nom de service pour votre connexion externe dans l'outil d'administration du système de
      PPM classique
      .
  13. Installez les rapports.
Dans la version 14.4 ou antérieure, vous pouviez utiliser ces étapes pour installer les rapports, l'univers
PPM classique
et d'autres contenus de rapport sur le serveur de rapports BusinessObjects Enterprise. Dans la version 15.1 et les versions ultérieures, vous pouvez utiliser ces étapes pour configurer une base de données transactionnelle parallèle pour exécuter des rapports au lieu ou en plus d'utiliser le schéma d’entrepôt de données. Utilisez cette procédure pour ajouter une source de données supplémentaire dans les versions sur site de
Clarity
. Par exemple, ajoutez un schéma de transaction répliqué, un entrepôt de données externe ou un schéma d’application tiers qui se trouve dans une base de données Oracle ou MS-SQL.
Mise en cluster de la base de données Oracle
PPM classique
prend en charge l'utilisation d'un cluster Oracle pour fournir le plus de modularité, de redondance et de basculement possible à un serveur Oracle unique.
Procédez comme suit :
  1. Le cas échéant, exportez votre base de données Oracle de serveur unique existante à partir de l'instance de noeud unique et importez-la dans le cluster.
  2. Connectez-vous à l'outil d'administration du système.
  3. Ouvrez la page d'accueil et cliquez sur Serveurs.
  4. Cliquez sur l'icône Propriétés du serveur pour lequel vous souhaitez modifier les propriétés.
  5. Sélectionnez le sous-onglet Base de données.
  6. Modifiez les propriétés suivantes pour la connexion de la base de données :
    • Spécifier l'URL
      Sélection.
    • URL JDBC
      URL JDBC complète de cluster Oracle. Cette URL est un préfixe jdbc suivi de la spécification TNS complète.
      L'URL JDBC doit contenir le paramètre ServiceName faisant référence à une entrée TNS sur l'hôte Oracle spécifié avec la configuration RAC souhaitée.
      Par exemple :
      jdbc:clarity:oracle://server:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      Autres exemples :
      Intégrez les serveurs RAC dans l'URL même avec la syntaxe DataDirect suivante :
      jdbc:clarity:oracle://server1:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(server2:1521;server3:1521);LoadBalancing=true
      Serveurs RAC Oracle avec l'écouteur d'analyse :
      jdbc:clarity:oracle://oracscan:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(oracscan:1521);FailoverMode=Select;ConnectionRetryCount=20;ConnectionRetryDelay=15;LoadBalancing=true"
      Oracle DataGuard :
      jdbc:clarity:oracle://PRIMARY_SERVER:1521;ServiceName=CLARITY_RW;AlternateServers=(PHYSICAL_STANDBY_SERVER:1521);ConnectionRetryCount=20;ConnectionRetryDelay=15;;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      Pour plus d'informations, consultez les ressources ci-dessous.
      Documentation Oracle concernant la configuration des solutions RAC, DataGuard, SCAN et des services.
      Site Web dédié à DataDirect. Rechercher les informations relatives à l'utilisation de DataDirect Connect for JDBC avec Oracle Real Application Clusters (RAC).
  7. Enregistrez les modifications.
  8. Pour valider les paramètres de la base de données, exécutez un rapport d'intégrité système pour chaque serveur. Reportez-vous à la section Exécution d'un rapport d'intégrité.
  9. Sur les serveurs d'applications Apache Tomcat, redémarrez tous les services dans l'outil d'administration du système de
    PPM classique
    .
Régler les ordinateurs virtuels Java Sun HotSpot
Ces informations s'appliquent uniquement aux environnements comprenant des machines virtuelles Java Sun HotSpot.
Il est important d'ajuster correctement la machine virtuelle Java Sun HotSpot lors de la configuration et de la gestion de
PPM classique
. Bien que ce réglage soit important pour le service d'arrière-plan, il est encore plus important pour tout service d'application s'exécutant dans le cluster. Cet article est axé sur l'application.
Consultez la documentation relative à ces paramètres sur le site Web d'Oracle. Vous pouvez également consulter les partenaires de Broadcom Service pour obtenir de l'aide en matière de dimensionnement du segment de mémoire de la machine virtuelle Java d'après l'implémentation.
De nombreuses options sont disponibles pour le réglage d'une machine virtuelle Java HotSpot.
Recommandation
: utilisez les valeurs ci-dessous ou des valeurs supérieures.
  • Segment de mémoire maximum
    -Xmx<size>m
    Le paramètre de segment de mémoire maximum détermine le plus grand espace de mémoire que le système d'exploitation local donne à la machine virtuelle Java. Le système d'exploitation local n'alloue pas ce grand espace de mémoire immédiatement au démarrage, mais il peut le faire lorsque le processus s'exécute. Il est recommandé de définir ce paramètre sur une valeur inférieure à 2048m (2 Go), y compris pour les installations de petite envergure. Pour améliorer les performances et obtenir moins d'erreurs de mémoire insuffisante, définissez cette valeur sur 4 Go ou sur 8 Go pour les ensembles de données plus volumineux, au minimum. Par exemple,-Xms1024m-Xmx4096m.
  • Segment de mémoire minimum
    -Xms<size>m
    Le paramètre de segment de mémoire minimum est important pour éviter un gaspillage d'efforts par la machine virtuelle lors de l'extension du segment de mémoire puisque l'application est accélérée. Spécifiez le segment de mémoire minimum le plus près possible de la réalité. Si l’application utilise généralement 1,2 Go de RAM, définissez le paramètre de segment de mémoire minimum sur 1200m. Vous pouvez définir les tailles de segment de mémoire minimum et maximum comme étant égales. Cela aboutit à une tâche plus simple pour le garbage collector de la machine virtuelle. Avec ces paramètres le processus de la machine virtuelle Java alloue également le segment de mémoire maximum complet à partir du système d'exploitation au démarrage, ce qui est plus cohérent. Ce processus nécessite que vous évaluiez la configuration requise d'allocation de vraie mémoire sur votre serveur.
  • Utilitaire de nettoyage de mémoire simultané
    -XX:+UseParallelGC
    L'utilitaire de nettoyage de mémoire simultané est recommandé pour tout serveur comportant au moins deux UC. L'utilitaire de nettoyage de mémoire simultané est défini en toute sécurité sur tous les serveurs. Tout serveur comportant moins de deux UC ignore ce paramètre.
  • Nouveau rapport
    -XX:NewRatio=<size>
    La machine virtuelle HotSpot sépare les objets en Nouveaux et Anciens espaces en fonction des âges des objets dans la mémoire. Les objets de courte durée tendent à rester dans le nouvel espace (ou Eden) et sont collectés avant d'être déplacés. Les objets qui ont vécu plus longtemps sont migrés vers l'ancien espace (ou Tenured). En fait, le paramètre Nouveau rapport ne définit pas la taille explicite du Nouvel Espace, mais plutôt un rapport entre l'ancien et le nouveau. Un paramètre de -XX:NewRatio=3 traduit en un rapport de 1 à 3, où la Nouvelle génération est de 1/3 la taille de l'Ancienne génération. Les applications qui créent et éliminent rapidement de nombreux objets temporaires de courte durée (comme une application
    PPM classique
    côté serveur) requièrent un nouvel espace plus grand que la moyenne. Dans le cas contraire, le Nouvel espace déborde tandis que l'Ancien espace est sous-peuplé. La valeur par défaut du nouveau rapport varie selon la plate-forme. Pour éviter tout problème dans
    PPM classique
    , indépendamment de la plate-forme que vous utilisez, définissez la valeur Nouveau rapport sur 2, soit
    XX:NewRatio=2
    .
  • Taille permanente maximum
    -XX:MaxPermSize=<size>m
    Hormis le nouvel et l'ancien espace, un troisième espace appelé Espace permanent a été créé. Dans cet espace résident des objets permanents, essentiellement les définitions de classe Java. Cet espace augmente non pas par rapport à l'utilisation de l'application, mais par rapport à sa taille. Plus il y a de classes chargées dans l'application, plus la taille permanente est grande. Le paramètre par défaut de 64 m s'est révélé trop petit. Dans Apache Tomcat, le paramètre
    PPM classique
    par défaut de cet espace est de 256 m.