CA Technologies

Fichier Readme de CA Performance Management Data Aggregator Data Aggregator 2.4


1.0 Bienvenue

2.0 Accès à la documentation du produit

3.0 Remarques concernant les mises à niveau

3.1 Echec de la mise à niveau du Data Repository en raison de l'utilisation du gestionnaire de volumes logiques (LVM)

3.1.1 Data Repository - nœud unique

3.1.2 Data Repository - Cluster

3.2 Restriction connue au niveau de CA Mediation Manager après la mise à niveau

3.3 Segmentation des tables de base de données

3.4 Changement de la taille du stockage optimisé pour l'écriture sur Data Repository

3.5 Remarques concernant la prise en charge et la mise à niveau de CA Spectrum

4.0 Conditions préalables pour l'exportation de données

5.0 Limitation du temps d'exécution de la mise à niveau du DC CAMM

6.0 Problèmes connus

6.1 L'installation ou la mise à niveau du Data Repository ne détecte pas correctement le gestionnaire de volumes logiques (LVM) et échoue

6.2 Le nom d'utilisateur du Data Repository et le nom de l'administrateur du Data Repository ne peuvent pas être identiques

6.3 Octets multiples et famille prête à l'emploi de mesures d'interface

7.0 Contacter CA Technologies


1.0 Bienvenue

Bienvenue dans le fichier Readme de Data Aggregator. Ce fichier Readme contient la liste complète des problèmes connus liés à cette version ainsi que des informations sur les fonctionnalités et les améliorations de cette version.


2.0 Accès à la documentation du produit

Ce fichier Readme contient la liste la plus récente des problèmes connus et de leurs solutions. La documentation du produit supplémentaire est disponible dans la bibliothèque de Data Aggregator, accessible à partir du menu d'aide de l'interface utilisateur de CA Performance Center. Vous pouvez également télécharger la bibliothèque sur le site du support de CA. La bibliothèque contient les Notes de parution (ainsi que la configuration système requise), l'aide en ligne et les manuels aux formats PDF et HTML.

Pour afficher l'aide en ligne contextuelle des pages et des vues, cliquez sur le bouton Aide (?) ou sélectionnez Aide pour cette page dans le menu Aide.


3.0 Remarques concernant les mises à niveau

Les mises à niveau du logiciel CA Performance Management à partir de versions antérieures sont prises en charge et sont incrémentielles. Pour plus d'informations sur les séquences de mise à niveau, consultez les Notes de parution de Data Aggregator.


3.1 Echec de la mise à niveau du Data Repository en raison de l'utilisation du gestionnaire de volumes logiques (LVM)

Les procédures suivantes décrivent comment effectuer la transition d'un Data Repository exécutant Vertica 6.0.2 avec un gestionnaire de volumes logiques (Logical Volume Manager, LVM) pour les répertoires de données et de catalogue vers un système exécutant Vertica 6.0.2 sans LVM. La base de données Vertica supporte le Data Repository, mais Vertica ne prend pas en charge l'exécution de sa base de données sur des volumes LVM. Vertica n'a jamais pris en charge l'exécution de sa base de données sur des volumes LVM. A partir de Vertica 7.0.1-2 (les versions 2.3.4 et Version 2.4 du Data Aggregator requièrent Vertica 7.0.1-2), le programme d'installation de Vertica applique cette condition en refusant l'exécution de Vertica sur des volumes LVM.

La procédure de migration des répertoires de base de données qui résident sur des partitions LVM vers des partitions non-LVM est décrite aussi bien pour des déploiements du Data Repository à nœud unique que pour des déploiements du Data Repository en cluster. Si le Data Repository utilise des volumes gérés par le gestionnaire de volumes logiques, vous ne pourrez pas installer les versions 2.3.4 et Version 2.4 du Data Aggregator.


3.1.1 Data Repository - nœud unique

Important : Sauvegardez le Data Repository avant de poursuivre. Assurez-vous qu'aucune sauvegarde planifiée ne s'exécutera pendant l'opération.

Important : Vous devez disposer d'une partition locale ou en réseau contenant suffisamment d'espace disponible pour stocker le contenu de la base de données le temps de la conversion de la partition LVM.

Hypothèses :

Pour effectuer la migration, procédez comme suit :

  1. Arrêtez chaque instance du Data Collector :
    1. ssh nom_hôte_Data_Collector -l root
    2. /etc/init.d/dcmd stop
    3. /etc/init.d/dcmd status
  2. Arrêtez le Data Aggregator.
    1. ssh nom_hôte_Data_Aggregator -l root
    2. /etc/init.d/dadaemon stop
    3. /etc/init.d/dadaemon status
  3. En tant qu'utilisateur dradmin, arrêtez la base de données :
    1. ssh nom_hôte_Data_Repository -l dradmin
    2. Arrêtez la base de données à l'aide de /opt/vertica/bin/adminTools.

Important : Sauf mention contraire, effectuez les actions suivantes en tant qu'utilisateur root.

  1. Créez un répertoire temporaire /tmp_data pour stocker le contenu du répertoire de données temporairement. Assurez-vous que le répertoire est situé sur une partition disposant de suffisamment d'espace pour accueillir une copie complète du dossier /data/drdata. Il s'agit d'un emplacement de stockage temporaire. Les données seront retirées de cet emplacement par la suite.
    1. mkdir /tmp_data
    2. Vérifiez que /tmp_data est monté sur la partition temporaire :

      mount partition_données /tmp_data

    3. Notez la taille du répertoire /data pour référence à l'étape 7 :

      du -ch /data | grep -i total

    4. Déterminez la quantité d'espace disque libre sur la partition de destination :

      df -h /tmp_data

    5. Vérifiez qu'il y a assez d'espace disque libre sur la partition de destination (la partition pour /tmp_data) pour accueillir une copie complète du répertoire /data.
  2. Changez les autorisations du dossier /tmp_data :

    chown dradmin:verticadba /tmp_data

  3. Déplacez la base de données dans le nouveau répertoire.

    mv /data/drdata /tmp_data

  4. Assurez que la taille de fichier correspond à la taille notée lors de l'étape 4.c. :

    du -ch /tmp_data | grep -i total

  5. Créez un répertoire temporaire /tmp_catalog pour stocker le répertoire de catalogue. Assurez-vous que le répertoire est situé sur une partition disposant de suffisamment d'espace pour accueillir une copie complète du dossier /catalog/drdata. Il s'agit d'un emplacement de stockage temporaire. Les données seront retirées de cet emplacement par la suite.
    1. mkdir /tmp_catalog
    2. Vérifiez que /tmp_catalog est monté sur la partition temporaire :

      mount partition_données /tmp_catalog

    3. Notez la taille du répertoire /catalog pour référence à l'étape 11 :

      du -ch /catalog | grep -i total

    4. Déterminez la quantité d'espace disque libre sur la partition de destination :

      df -h /tmp_catalog

    5. Vérifiez qu'il y a assez d'espace disque libre sur la partition de destination (la partition pour /tmp_catalog) pour accueillir une copie complète du répertoire /catalog.
  6. Changez les autorisations du dossier /tmp_catalog :

    chown dradmin:verticadba /tmp_catalog

  7. Déplacez le catalogue dans le nouveau répertoire.

    mv /catalog/drdata /tmp_catalog

  8. Assurez que la taille de fichier correspond à la taille notée lors de l'étape 8.c. :

    du -ch /tmp_catalog | grep -i total

  9. Notez les points de montage LVM en enregistrant le résultat du montage :

    mount

  10. Démontez /data et /catalog :

    umount /data

    umount /catalog

    Remarque : Si vous obtenez une erreur de type "Occupé", assurez-vous qu'aucune fenêtre ou application n'accède à ces répertoires.

  11. Rétablissez le volume non-LVM sur /data et /catalog. Trois options sont possibles :

    ou

    ou

  12. Remontez tous les systèmes de fichiers :

    mount -a

  13. Déplacez les données des répertoires temporaires vers les répertoires /data et /catalog que Vertica connaît :
    1. mv /tmp_data/drdata /data
    2. mv /tmp_catalog/drdata /catalog
  14. Assurez-vous que la taille du répertoire /data correspond à la taille signalée à l'étape 4.c. :

    du -ch /data | grep -i total

  15. Assurez-vous que la taille du répertoire /catalog correspond à la taille signalée à l'étape 8.c. :

    du -ch /catalog | grep -i total

  16. Redémarrez la base de données :
    1. su – dradmin
    2. /opt/vertica/bin/adminTools

    Remarque : Cette opération peut prendre plusieurs minutes.

  17. Vérifiez que la base de données est en cours d'exécution :
    1. su - dradmin
    2. /opt/vertica/bin/adminTools
    3. Sélectionnez l'option View Database Cluster State (Afficher l'état du cluster de base de données) et vérifiez que l'état de la base de données est UP (Actif).
  18. Redémarrez le Data Aggregator :
    1. ssh nom_hôte_Data_Aggregator -l root
    2. /etc/init.d/dadaemon start
    3. /etc/init.d/dadaemon status
  19. Démarrez chaque instance du Data Collector :
    1. ssh nom_hôte_Data_Collector -l root
    2. /etc/init.d/dcmd start
    3. /etc/init.d/dcmd status

3.1.2 Data Repository - Cluster

Important : Sauvegardez le Data Repository avant de poursuivre. Assurez-vous qu'aucune sauvegarde planifiée ne s'exécutera pendant l'opération.

Hypothèses :

Pour effectuer la migration, procédez comme suit :

  1. Arrêtez chaque instance du Data Collector :
    1. ssh nom_hôte_Data_Collector -l root
    2. /etc/init.d/dcmd stop
    3. /etc/init.d/dcmd status
  2. Arrêtez le Data Aggregator.
    1. ssh nom_hôte_Data_Aggregator -l root
    2. /etc/init.d/dadaemon stop
    3. /etc/init.d/dadaemon status

Procédure de migration d'un nœud dans un cluster

Important : Sauf mention contraire, effectuez les étapes suivantes en tant qu'utilisateur root.

Exécutez cette procédure pour chaque nœud du cluster. Suivez toutes les étapes (1 à 15) pour un nœud à la fois.

Important : Utilisez adminTools pour vérifier que la base de données est en cours d'exécution.

  1. Prenez note de l'adresse IP du nœud actuel :

    ifconfig

  2. En tant qu'utilisateur dradmin, accédez à adminTools :
    1. su - dradmin
    2. /opt/vertica/bin/adminTools
  3. Arrêtez Vertica sur l'hôte :
    1. Accédez au menu des outils avancés. Appuyez sur Entrée.
    2. Accédez à l'option Stop Vertica on Host (Arrêter Vertica sur l'hôte). Appuyez sur Entrée.
    3. Sélectionnez l'adresse IP hôte appropriée comme indiquée à l'étape 1 de la section Procédure de migration d'un nœud dans un cluster. Appuyez sur Entrée.
    4. Accédez au menu principal. Appuyez sur Entrée.
    5. Accédez à l'option Quitter. Appuyez sur Entrée.
  4. Revenez à l'utilisateur root :

    fermeture

  5. Vérifiez que la commande suivante renvoie la valeur root :

    whoami

  6. Supprimez les fichiers du répertoire /data :

    rm -rf /data/drdata

  7. Supprimez les fichiers du répertoire /catalog :

    rm -rf /catalog/drdata

  8. Enregistrez le résultat des commandes suivantes à des fins de débogage :
    1. mount
    2. cat /etc/fstab
  9. Démontez le répertoire LVM /data :

    umount /data

  10. Démontez le répertoire LVM /catalog :

    umount /catalog

  11. Rétablissez le volume non-LVM sur /data et /catalog. Trois options sont possibles :

    ou

  12. Remontez tous les systèmes de fichiers :

    mount -a

  13. Créez le dossier drdata avec les autorisations appropriées dans les répertoires /data et /catalog :
    1. mkdir -p /data/drdata
    2. mkdir -p /catalog/drdata
    3. chown -R dradmin:verticadba /data
    4. chown -R dradmin:verticadba /catalog
  14. Redémarrez Vertica sur l'hôte :
    1. su - dradmin
    2. /opt/vertica/bin/adminTools
    3. Utilisez la touche de flèche vers le bas pour accéder à l'option Restart Vertica on host (Redémarrer Vertica sur l'hôte). Appuyez sur Entrée.
  15. Continuez de surveiller adminTools. Le statut du nœud actuel reste Recovering (Récupération) pendant la reconstruction des données. Attendez que la base de données ait à nouveau l'état UP (Actif) pour poursuivre. Cela peut nécessiter un certain temps.
    1. Sélectionnez l'option View Database Cluster State (Afficher l'état du cluster de base de données). Appuyez sur Entrée.
    2. Appuyez sur Entrée pour revenir au menu principal.

    Une fois la base de données sauvegardée, répétez les étapes 1 à 15 de la section Procédure de migration d'un nœud dans un cluster pour le nœud suivant. Répétez ces étapes jusqu'à ce que tous les nœuds du Data Repository soient migrés en dehors du gestionnaire de volumes logiques.

Une fois que vous avez terminé les étapes de la section Procédure de migration d'un nœud dans un cluster pour tous les nœuds du Data Repository, procédez comme suit :

  1. Connectez-vous à un nœud du Data Repository :

    su - dradmin

    /opt/vertica/bin/vsql -U dradmin –w drpass

  2. Exécutez les commandes vsql suivantes pour rétablir les paramètres d'application personnalisés :
    1. SELECT set_config_parameter('MaxClientSessions',1024);
    2. SELECT set_config_parameter('StandardConformingStrings','0');
  3. Démarrez le Data Aggregator :
    1. ssh nom_hôte_Data_Aggregator -l root
    2. /etc/init.d/dadaemon start
    3. /etc/init.d/dadaemon status
  4. Démarrez toutes les instances du Data Collector :
    1. ssh nom_hôte_Data_Collector -l root
    2. /etc/init.d/dcmd start
    3. /etc/init.d/dcmd status

3.2 Restriction connue au niveau de CA Mediation Manager après la mise à niveau

L'architecture de l'intégration à CA Mediation Manager a été considérablement améliorée. La version 2.2.6 ou une version ultérieure de CA Mediation Manager est requise pour son exécution avec CA Performance Management 2.3.4 ou une version ultérieure. Toutefois, cette version de l'intégration ne prend pas en charge l'utilitaire Générateur de packs d'unités.

Les versions futures de CA Mediation Manager prendront en charge une version améliorée de cet utilitaire. Pour le moment, vous ne pouvez pas créer de packs d'unités personnalisés avec cet utilitaire.

Important : CA Mediation Manager 2.2.6 n'est pas complètement rétrocompatible avec les versions précédentes de CA Performance Management. Pour traiter les données brutes, vous devez mettre à niveau Data Collector vers Version 2.4. Assurez-vous de migrer vos packs d'unités avant de mettre à niveau CA Performance Management. Pour plus informations, reportez-vous au scénario Procédure de migration des packs d'unités, dans la bibliothèque de documentation de CA Performance Management Data Aggregator.


3.3 Segmentation des tables de base de données

Si vous mettez à niveau CA Performance Management Data Aggregator et si Data Repository est installé dans un environnement de cluster, vérifiez que les tables de base de données sont segmentées une fois que vous avez mis à niveau le composant Data Repository et avant de mettre à niveau le composant Data Aggregator.

Remarque : Pour plus d'informations sur le contrôle de la segmentation des tables de base de données, consultez le manuel de mise à niveau de CA Performance Management Data Aggregator.


3.4 Changement de la taille du stockage optimisé pour l'écriture sur Data Repository

Si vous gérez plus d'un million d'éléments interrogés, modifiez la taille du stockage optimisé pour l'écriture (WOS) sur Data Repository. Remplacez la valeur par défaut de 2 Go par 4 Go. Cette opération requiert l'arrêt de Data Aggregator, c'est pourquoi nous vous recommandons d'effectuer les étapes suivantes avant de procéder à la mise à niveau de Data Aggregator.

  1. Connectez-vous au serveur d'installation de Data Aggregator. Pour redémarrer Data Aggregator, ouvrez une invite de commande et saisissez la commande suivante :

    service dadaemon stop

  2. SSH vers un noeud de Data Repository.
  3. Pour déplacer toutes les données comprises dans le stockage optimisé pour l'écriture (WOS) vers le stockage optimisé pour la lecture (ROS), saisissez la commande suivante :

    /opt/vertica/bin/vsql -U administrateur_BdD -w mot_passe_administrateur_BdD -c "select do_tm_task('moveout')";

  4. Pour vérifier qu'aucune donnée ne reste dans le stockage WOS, saisissez la commande suivante :

    /opt/vertica/bin/vsql -U administrateur_BdD -w mot_passe_administrateur_BdD -c "select sum( region_in_use_size_kb ) as wos_usage_kb from wos_container_storage";

    Si cette commande ne renvoie pas la valeur 0, patientez 5 minutes , puis envoyez à nouveau la commande. Si après 5 minutes la valeur qui est renvoyée est toujours supérieure à 0, ressaisissez la commande à l'étape 3 , puis envoyez à nouveau la commande lors de cette étape.

  5. Pour augmenter la taille du stockage WOS et la définir sur 4 Go, saisissez la commande suivante :

    /opt/vertica/bin/vsql -U administrateur_BdD -w mot_passe_administrateur_BdD -c "alter resource pool wosdata maxMemorySize '4G'";


3.5 Remarques concernant la prise en charge et la mise à niveau de CA Spectrum

Si vous prévoyez d'enregistrer une source de données CA Spectrum avec CA Performance Management Version 2.4, il est recommandé de procéder à la mise à niveau vers la version 9.4 de CA Spectrum. Les versions antérieures de CA Spectrum ne prennent pas entièrement en charge les nouvelles fonctionnalités suivantes :

Remarque : Pour plus d'informations sur la mise à niveau de CA Spectrum vers la version 9.4, consultez la documentation relative à la CA Spectrum version 9.4.


4.0 Conditions préalables pour l'exportation de données

La configuration requise au niveau de l'UC, de la mémoire, du réseau d'E/S pour Data Aggregator n'ont pas changé lors de l'activation de la fonctionnalité d'exportation de données. Toutefois, une deuxième partition distincte de stockage d'espace disque est requise pour l'exportation de données. La taille de la partition doit être de 50 Go pour un déploiement de taille moyenne. La taille 50 Go permet la conservation d'une heure de données avant le déplacement des fichiers vers un autre système de fichiers par le job de traitement.


5.0 Limitation du temps d'exécution de la mise à niveau du DC CAMM

Si CAMM est installé sur un Data Collector, la mise à niveau peut prendre plus d'une heure en raison d'une restriction d'InstallAnywhere. La solution à ce problème est disponible dans l'article de base de connaissances suivant : https://communities.ca.com/thread/241693769.


6.0 Problèmes connus


6.1 L'installation ou la mise à niveau du Data Repository ne détecte pas correctement le gestionnaire de volumes logiques (LVM) et échoue

Vous ne pouvez pas installer le Data Repository si le gestionnaire de volumes logiques (LVM) est utilisé pour gérer des volumes employés par le Data Repository.

La base de données Vertica supporte le Data Repository, mais Vertica ne prend pas en charge l'exécution de sa base de données sur des volumes LVM. Vertica n'a jamais pris en charge l'exécution de sa base de données sur des volumes LVM. Depuis Vertica 7 (la version 2.3.4 du Data Aggregator requiert Vertica 7), le programme d'installation de Vertica applique cette exigence en refusant l'exécution de Vertica sur des volumes LVM.

Il existe un problème connu avec le programme d'installation de Vertica 7.0.1-2. Si le gestionnaire de volumes logiques est détecté sur tout volume (pas seulement les volumes utilisés par Vertica) dans le cluster, le programme d'installation génère un message d'avertissement qui se présente comme suit :

WARN (S0170): https://my.vertica.com/docs/7,0.x/HTML/index.htm#cshid=S0170

lvscan (LVM utility) indicates some active volumes.

Si vous rencontrez ce message lors de l'exécution de dr_install.sh alors que vous avez vérifié que les répertoires de catalogue et de données que Vertica utilise ne sont pas gérés par le gestionnaire de volumes logiques, effectuez les étapes suivantes pour garantir la réussite de l'installation ou de la mise à niveau de Vertica.

Remarque : Si les répertoires de catalogue et de données utilisés par Vertica sont gérés par le gestionnaire de volumes logiques, reportez-vous à la section Remarques sur la mise à niveau.

Important : Effectuez les étapes suivantes uniquement après avoir vérifié que le script install.sh n'a pas généré d'autre message d'avertissement ou d'erreur supplémentaire non liés au gestionnaire de volumes logiques.

Procédez comme suit :

  1. Recherchez dans le script dr_install.sh la ligne qui commence par /opt/vertica/sbin/install_vertica. La ligne doit ressembler à la suivante :

    /opt/vertica/sbin/install_vertica -s $DB_HOST_NAMES -u $DB_ADMIN_LINUX_USER -l $DB_ADMIN_LINUX_USER_HOME -d $DB_DATA_DIR -L ./resources/$VLICENSE -Y -r ./resources/$VERTICA_RPM_FILE $POINT_TO_POINT_SPREAD_OPTION 2>&1 | tee -a $LOG_FILE

  2. Après l'entrée-d $DB_DATA_DIR de la ligne, ajoutez la nouvelle entrée suivante, avec un espace avant et après :

    --failure-threshold FAIL

    La ligne doit à présent ressembler à la suivante :

    /opt/vertica/sbin/install_vertica -s $DB_HOST_NAMES -u $DB_ADMIN_LINUX_USER -l $DB_ADMIN_LINUX_USER_HOME -d $DB_DATA_DIR --failure-threshold FAIL -L ./resources/$VLICENSE -Y -r ./resources/$VERTICA_RPM_FILE $POINT_TO_POINT_SPREAD_OPTION 2>&1 | tee -a $LOG_FILE

    Grâce à l'ajout de cette entrée, l'installation échouera uniquement si un ou plusieurs messages d'échec sont rencontrés pendant l'installation. L'installation ignore le message d'avertissement LVM et l'installation se termine correctement.

  3. Pour installer ou mettre à niveau Vertica, réexécutez le script dr_install.sh. Le message d'avertissement spécifique au gestionnaire de volumes logiques est ignoré.

    Lorsque vous réexécutez dr_install.sh, vous obtenez le message d'avertissement LVM suivant :

    WARN (S0170): https://my.vertica.com/docs/7,0.x/HTML/index.htm#cshid=S0170

    lvscan (LVM utility) indicates some active volumes.

    Toutefois, ce message ne bloque plus l'installation ou la mise à niveau de Vertica 7.


6.2 Le nom d'utilisateur du Data Repository et le nom de l'administrateur du Data Repository ne peuvent pas être identiques

Lorsque vous installez le composant Data Aggregator et êtes invité à fournir les informations d'identification du Data Repository, n'utilisez pas la même valeur pour le nom d'utilisateur du Data Repository et le nom de l'administrateur du Data Repository. Le Data Aggregator exige que ces noms d'utilisateur soient différents lors d'une nouvelle installation.


6.3 Octets multiples et famille prête à l'emploi de mesures d'interface

Lorsque vous créez une certification personnalisée pour des composants d'interface ou de port et si l'index de la table de la base de données MIB inclut plusieurs octets (par exemple, 23.4.5.12), vous ne pouvez pas utiliser la famille prête à l'emploi de mesures d'interface pour votre certification. En effet, cette opération entraîne des problèmes au niveau de la synchronisation dans CA Performance Center.

Solution :

Utilisez une autre famille de mesures d'interface ou créez votre propre famille de mesures personnalisée. Cette action provoque l'affichage de vos éléments d'interface ou de port sous les composants d'unité, or ce résultat n'est pas idéal.


7.0 Contacter CA Technologies

Pour une assistance technique en ligne et une liste complète des sites, horaires d'ouverture et numéros de téléphone, contactez le support technique à l'adresse http://www.ca.com/worldwide.