Mise à niveau du Data Repository

Mettez d'abord à niveau le Data Repository. Si le script dr_validate.sh détecte un problème que vous devez résoudre avant la mise à niveau, vous pouvez redémarrer votre système pendant la résolution du problème.
capm360
Mettez d'abord à niveau le Data Repository. Si le script dr_validate.sh détecte un problème que vous devez résoudre avant la mise à niveau, vous pouvez redémarrer votre système pendant la résolution du problème.
La version 9.1 de Vertica est identique pour
DX Performance Management
3.7 et 20.2. Par conséquent, la mise à niveau du Data Repository n'est pas nécessaire de la version 3.7 à la version 20.2.
Pour mettre à niveau Data Repository, procédez comme suit :
2
Vérification des conditions préalables
Passez en revue les conditions préalables suivantes avant de mettre à niveau Data Repository :
Pour plus d'informations sur les versions précédentes, reportez-vous à la documentation précédente. Pour savoir où localiser les versions 3.1 et antérieures, contactez votre représentant du support.
  • Si votre Data Repository actuel exécute le logiciel Vertica 7.2.3 (version utilisée dans
    DX Performance Management
    3.0/3.1), vous devez effectuer une mise à niveau intermédiaire vers Vertica 8.1.
    • Vérifiez la version exécutée en démarrant les outils d'administration en tant qu'administrateur de bases de données :
      /opt/vertica/bin/admintools -t list_allnodes
    • Utilisez le fichier 3.5_installDR.bin fourni sur le support de la version 3.6 pour procéder à la mise à niveau vers Vertica 8.1.
    • Reportez-vous aux procédures de mise à niveau de Data Repository 3.5.
    • Une fois le Data Repository exécuté sous Vertica 8.1, procédez à la mise à niveau du Data Repository de
      DX Performance Management
      3.6.
  • Si votre Data Repository actuel exécute le logiciel Vertica 7.1.2 (version utilisée dans
    DX Performance Management
    2.7/2.8), vous devez effectuer une mise à niveau intermédiaire vers Vertica 7.2.3.
    • Vérifiez la version exécutée en démarrant les outils d'administration en tant qu'administrateur de bases de données :
      /opt/vertica/bin/admintools -t list_allnodes
    • Mise à niveau vers Vertica 7.2.3 à l'aide du fichier 3.1_installDR.bin fourni sur le support de la version 3.5
    • Reportez-vous aux procédures de mise à niveau de Data Repository 3.1.
    • Une fois le Data Repository exécuté sous Vertica 7.2.3, procédez à la mise à niveau du Data Repository de
      DX Performance Management
      3.5.
  • Vérifiez que les package dialog, chrony, zip et unzip sont installés sur chaque hôte Data Repository :
    Le package chrony est requis uniquement pour RHEL 7.x et OL 7.x.
    rpm -qa | grep ^dialog
    rpm -qa | grep ^chrony
    rpm -qa | grep ^zip
    rpm -qa | grep ^unzip
    Si un package requis pour votre système d'exploitation est manquant, installez-le :
    Si vous n'êtes pas l'utilisateur root, utilisez le préfixe sudo.
    yum -y install dialog
    yum -y install chrony
    yum -y install zip
    yum -y install unzip
    SLES :
    zypper install dialog -y
    zypper install zip -y
    zypper install unzip -y
    Si ce package n’est pas installé, les scripts de validation et d’installation échoueront.
  • Vérifiez que l'hôte de Data Repository dispose d'au moins 2 Go d'espace d'échange.
  • Vérifiez que les hôtes Data Repository utilisent le système de fichiers ext4 pour les répertoires de données et de catalogues. Si ce n'est pas le cas, recréez le système de fichiers au format ext4.
    Le système de fichiers par défaut pour RHEL 7.x et OL 7.x est le système de fichiers XFS. Le système de fichiers par défaut pour SLES est btrfs. Vertica ne prend pas en charge XFS ou btrfs. La base de données prend en charge uniquement le système de fichiers ext4.
  • Vérifiez que vous n'utilisez pas le gestionnaire de volumes logiques pour les répertoires de données et de catalogues.
Vérification des performances du matériel et du réseau
capm360
Vertica offre plusieurs utilitaires qui permettent de tester les performances de votre matériel au niveau du Data Repository. Pour vérifier que l'environnement est adapté à la base de données, exécutez les tests suivants avant de mettre à niveau le Data Repository.
3
3
Si vous avez déjà installé le Data Repository, vous pouvez effectuer ces tests à tout moment afin de vérifier les performances. Les utilitaires sont disponibles sur chaque noeud sous
/opt/vertica/bin
.
Si les résultats des tests ne correspondent pas aux recommandations, résolvez les problèmes avant de poursuivre la mise à niveau.
vcpuperf
Cet utilitaire mesure la vitesse de traitement de l'UC de l'hôte et la compare aux valeurs de référence des UC de serveur commun. L'utilitaire mesure la durée dont le serveur a besoin pour effectuer le test et détermine si la limitation d'UC est activée.
Procédez comme suit :
  1. Exécutez la commande suivante sur
    chaque
    noeud Data Repository :
    ./vcpuperf > /tmp/vcpuperf.out
  2. Vérifiez que les performances respectent les conditions suivantes :
    • Le temps d'UC est cohérent avec les valeurs de référence dans la sortie.
    • La différence entre la durée de chargement faible et la durée de chargement élevée doit être inférieure à 10 microsecondes. Lorsque la différence entre ces deux valeurs est supérieure à 50 microsecondes, vous pouvez activer la limitation d'UC sur votre système. Or, cette fonction ne doit pas être activée.
Exemple :
L'exemple ci-dessous illustre les données renvoyées par cet utilitaire :
$ /opt/vertica/bin/vcpuperf
Compiled with: 4.1.2 20080704 (Red Hat 4.1.2-52)
Expected time on Core 2, 2.53GHz: ~9.5s
Expected time on Nehalem, 2.67GHz: ~9.0s
Expected time on Xeon 5670, 2.93GHz: ~8.0s
This machine's time:
CPU Time: 7.740000s
Real Time:7.740000s
Some machines automatically throttle the CPU to save power.
This test can be done in <100 microseconds (60-70 on Xeon 5670, 2.93GHz).
Low load times much larger than 100-200us or much larger than the corresponding high load time
indicate low-load throttling, which can adversely affect small query / concurrent performance.
This machine's high load time: 67 microseconds.
This machine's low load time: 64 microseconds.
Ce test a été effectué sur un système équipé de processeurs 2.67 GHz, c'est pourquoi les données en temps réel sont acceptables. La différence entre la durée de chargement élevée et la durée de chargement faible est comprise dans la marge attendue.
Pour plus d'informations sur cet utilitaire, reportez-vous à la documentation de Vertica.
vioperf
Cet utilitaire teste les performances de l'entrée et de la sortie (E/S) de disque. Il effectue toute une série d'opération de lecture et d'écriture.
Pour mesurer la vitesse de lecture/écriture lorsque vous utilisez le même SAN/NAS pour le disque ou le disque de machine virtuelle, vous devez exécuter vioperf sur tous les noeuds du cluster en même temps pour le répertoire de données ou de catalogues.
Procédez comme suit :
  1. Exécutez les commandes suivantes sur chaque
    noeud
    Data Repository :
    ./vioperf /
    data
    > /tmp/vioperf.out --duration=60sec
    /data
    est le chemin d'accès complet au répertoire de données.
    ./vioperf /
    catalog
    > /tmp/vioperf.out --duration=60sec
    /catalog
    est le chemin d'accès complet du répertoire de catalogue.
  2. Vérifiez que le compteur d'écritures et de lectures indique une valeur égale ou supérieure à 40 Mo/s par coeur.
    La valeur d'E/S recommandée est de 40 Mo/s par coeur physique sur chaque noeud. Par exemple, le taux d'E/S recommandé pour un noeud doté de 2 UC de six noyaux multithreads (12 noyaux physiques) est 480 Mo/s.
    Si la colonne
    thread count
    (Nombre de threads) indique la valeur 1, cela signifie que l'utilitaire ne peut pas déterminer le nombre de noyaux. Ajoutez l'argument suivant à la commande pour exécuter l'utilitaire :
    --thread-count=
    CORES
    Cores
    définit le nombre de noyaux dans le système en tant qu'un entier fixe.
Exemple :
L'exemple ci-dessous illustre les données renvoyées par cet utilitaire pour le répertoire de données :
The minimum required I/O is 20 MB/s read and write per physical processor core on each node, in full duplex i.e. reading and writing at this rate simultaneously, concurrently on all nodes of the cluster. The recommended I/O is 40 MB/s per physical core on each node. For example, the I/O rate for a server node with 2 hyper-threaded six-core CPUs is 240 MB/s required minimum, 480 MB/s recommended.
Using direct io (buffer size=1048576, alignment=512) for directory "/drdata"
test | directory | counter name | counter value | counter value (10 sec avg) | counter value/core | counter value/core (10 sec avg) |
thread count
| %CPU | %IO Wait | elapsed time (s)| remaining time (s)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Write
| /drdata | MB/s | 873 | 873 |
54.5625
| 54.5625 | 16 | 29 | 40 | 10 | 5
Write
| /drdata | MB/s | 868 | 865 |
54.25
| 54.0625 | 16 | 28 | 30 | 15 | 0
ReWrite | /drdata | (MB-read+MB-write)/s| 275+275 | 275+275 | 17.1875+17.1875 | 17.1875+17.1875 | 16 | 13 | 21 | 10 | 5
ReWrite | /drdata | (MB-read+MB-write)/s| 242+242 | 178+178 | 15.125+15.125 | 11.125+11.125 | 16 | 7 | 17 | 15 | 0
Read
| /drdata | MB/s | 735 | 735 |
45.9375
| 45.9375 | 16 | 11 | 23 | 10 | 5
Read
| /drdata | MB/s | 786 | 786 |
49.125
| 49.125 | 16 | 26 | 25 | 15 | 0
SkipRead | /drdata | seeks/s | 4511 | 4511 | 281.938 | 281.938 | 16 | 14 | 19 | 10 | 5
SkipRead | /drdata | seeks/s | 4477 | 4407 | 279.812 | 275.438 | 16 | 3 | 15 | 15 | 0
Ce serveur inclut 16 coeurs. Les valeurs de compteur de lectures/écritures indiquent que la valeur d'E/S est supérieure à 40 Mo/s par coeur.
Pour plus d'informations sur cet utilitaire, reportez-vous à la documentation de Vertica.
vnetperf
Cet utilitaire permet de tester les performances réseau des hôtes Data Repository. Il mesure la latence réseau et le débit pour les protocoles TCP et UDP.
Cet utilitaire entraîne une charge réseau élevée et réduit les performances de la base de données. Veillez à ne pas l'exécuter lorsque la base de données est en cours d'exécution.
Procédez comme suit :
  1. Connectez-vous en tant qu'utilisateur disposant d'une connexion ssh mot de passe entre les noeuds.
  2. Exécutez la commande suivante sur l'
    un
    des noeuds Data Repository :
    ./vnetperf --hosts
    DAhost
    ,
    DRhost1
    ,
    DRhost2
    ,
    DRhost3
    > /tmp/vnetperf.out
    Spécifiez le nom ou l'adresse IP de l'hôte Data Aggregator et de chaque hôte Data Repository.
  3. Vérifiez que les performances du réseau remplissent les conditions suivantes :
    • Latence de temps d'aller-retour égale ou inférieure à 200 microsecondes
    • Variation d'horloge inférieure à 1 seconde
    • Débit égal ou supérieur à 800 Mo/s
      L'utilitaire exécute plusieurs tests limités. Vérifiez le débit correspondant au test de calcul de la vitesse la plus élevée.
Pour plus d'informations sur cet utilitaire, reportez-vous à la documentation de Vertica.
Vérification de la limite du nombre de fichiers ouverts
Vérifiez que la valeur minimum de 65536 fichiers ouverts est définie pour l'utilisateur qui installe Data Repository. Définissez cette valeur de façon permanente. Effectuez cette procédure pour chaque noeud du cluster Data Repository.
Procédez comme suit :
  1. En tant qu'utilisateur root ou sudo, connectez-vous au noeud de l'hôte de Data Repository.
  2. Exécutez la commande suivante :
    su dradmin
  3. Vérifiez le nombre de fichiers ouverts :
    ulimit -n
    La commande renvoie la valeur ulimit. Cette valeur doit être égale ou supérieure à 65536.
    Le nombre doit être le même sur tous les noeuds du cluster.
  4. Si ce n'est pas le cas, procédez comme suit :
    1. Définissez la valeur ulimit de limite des fichiers ouverts sur 65536 :
      ulimit -n 65536
    2. Ouvrez le fichier /etc/security/limits.conf sur chaque noeud Data Repository et ajoutez les lignes suivantes :
      # Added by Vertica
      * soft nofile 65536
      # Added by Vertica
      * hard nofile 65536
      # Added by Vertica
      * soft fsize unlimited
      # Added by Vertica
      * hard fsize unlimited
    3. Redémarrez le service sshd sur chaque noeud Data Repository :
      service sshd restart
      Pour RHEL 7.x et OL 7.x,
      service
      appelle
      systemctl
      . Vous pouvez utiliser
      systemctl
      à la place.
      Si vous ne disposez pas de l'argument restart, arrêtez et démarrez sshd :
      service sshd stop
      service sshd start
    4. Vérifiez que le nombre de fichiers ouverts est défini correctement :
      ulimit -n
      La commande renvoie le nombre ulimit que vous avez spécifié.
Désactivation de la récupération automatique des processus Data Aggregator
Le processus de récupération redémarre le Data Aggregator. Désactivez la récupération automatique avant de procéder à la mise à niveau. Pour un environnement à tolérance aux pannes, placez le Data Aggregator inactif, puis le Data Aggregator actif en mode Maintenance.
Procédez comme suit :
  1. Connectez-vous à l'hôte de Data Aggregator en tant qu'utilisateur root.
  2. Ouvrez une console et entrez la commande suivante :
    crontab -e
    Une session vi s'ouvre.
  3. Si la ligne suivante existe, ajoutez un caractère # au début de la ligne à commenter :
    #
    * * * * * /etc/init.d/dadaemon start > /dev/null
    La récupération automatique est désactivée.
(Environnement à tolérance aux pannes) Activation du mode Maintenance
Si vous mettez à niveau les Data Aggregators dans un environnement à tolérance aux pannes existant, vous devez préalablement les placer en mode Maintenance.
Placez le Data Aggregator inactif en mode Maintenance. Placez le Data Aggregator actif en mode Maintenance.
Pour plus d'informations, consultez la section Tolérance aux pannes.
Procédez comme suit :
  1. Connectez-vous à l'hôte de Data Aggregator en tant qu'utilisateur root ou qu'utilisateur sudo.
  2. Exécutez l'une des commandes suivantes pour arrêter le Data Aggregator inactif et pour l'empêcher de redémarrer tant que la mise à niveau n'est pas terminée :
    • RHEL 6.x :
      service dadaemon maintenance
    • RHEL 7.x, SLES ou OL :
      DA_Install_Directory
      /scripts/dadaemon maintenance
Mise à niveau du Data Repository
Vous pouvez lancer l'installation de Data Repository à partir de l'un des hôtes du cluster. Les composants logiciels requis sont envoyés aux autres noeuds pendant l'installation.
Procédez comme suit :
  1. Connectez-vous à l'un des noeuds Data Repository en tant qu'utilisateur root.
  2. Déterminez les hôtes sur lesquels la base de données Vertica est en cours d'exécution :
    1. En tant qu'administrateur de la base de données, ouvrez les outils d'administration Vertica :
      /opt/vertica/bin/adminTools
    2. Sélectionnez l'option 6 (Configuration Menu).
    3. Sélectionnez l'option 3 (View Database).
    4. Sélectionnez la base de données.
    5. Notez les adresses IP et le nom de la base de données pour une utilisation ultérieure dans cette procédure.
    6. Fermez l'utilitaire adminTools et reconnectez-vous en tant qu'utilisateur root ou sudo.
  3. Copiez le fichier installDR.bin dans le dossier /tmp.
  4. Remplacez le répertoire par l'emplacement du fichier installDR.bin :
    cd /tmp
  5. Modifiez les autorisations du fichier exécutable :
    chmod u+x installDR.bin
  6. Extrayez les fichiers d'installation :
    ./installDR.bin
  7. Suivez les instructions de la console.
    Ce script permet d'extraire les scripts d'installation suivants :
    • dr_validate.sh
      vérifie que le système remplit les conditions requises pour la mise à niveau du Data Repository.
    • dr_install.sh
      met à niveau la base de données Vertica.
  8. Si le fichier drinstall.properties est disponible dans le Data Repository disposant de l'ancienne version de Vertica, copiez-le dans le répertoire suivant :
    /opt/CA/IMDataRepository_vertica
    Version
    Il
    s'agit de l'emplacement par défaut.
  9. Modifiez les répertoires vers l'emplacement où vous avez extrait les scripts d'installation :
    cd /opt/CA/IMDataRepository_vertica
    Version
    Il s'agit de l'emplacement par défaut.
  10. Vérifiez que tous les paramètres du fichier drinstaller.properties sont corrects. Vérifiez les paramètres suivants :
    • DbAdminLinuxUser :
      utilisateur Linux créé pour remplir la fonction d'administrateur de la base de données Vertica.
      Valeur par défaut
      : dradmin
    • DbAdminLinuxUserHome :
      répertoire de base d'administrateur de la base de données Vertica Linux
      Valeur par défaut :
      /export/dradmin
    • DbDataDir :
      emplacement du répertoire de données
      Valeur par défaut :
      /data
      Pour vérifier le répertoire de données ou le répertoire de catalogues, procédez comme suit :
      1. Ouvrez le fichier /opt/vertica/config/admintools.conf.
      2. Faites défiler le texte jusqu'à la section [Nodes].
      3. Localisez l'une des lignes commençant par v_
        dbnam
        e_node
        ####
        .
        Cette ligne contient l'adresse IP du noeud, l'emplacement du répertoire de catalogues et l'emplacement du répertoire de données.
        Exemple :
        v_drdata_node0001 = 10.42.1.1,/catalog,/data
    • DbCatalogDir :
      emplacement du répertoire de catalogues
      Valeur par défaut :
      /catalog
    • DbHostNames :
      liste de noms d'hôte séparés par des virgules pour Data Repository
      Valeur par défaut :
      yourhostname1,yourhostname2,yourhostname3
    • DbName :
      nom de la base de données
      Valeur par défaut :
      drdata
      Ce paramètre est sensible à la casse.
    • DbPwd :
      mot de passe de base de données
      Valeur par défaut :
      dbpass
      Vous pouvez utiliser des caractères spéciaux (à l'exception des guillemets simples) dans les mots de passe. Si la propriété
      DbPwd
      est introuvable ou vide, le script vous invite à spécifier ces informations lors de l'exécution.
    L'attribut InstallDestination n'est plus utilisé et peut être supprimé en toute sécurité.
  11. Vérifiez que le Data Repository est en cours d'exécution.
  12. Sur l'hôte Data Aggregator, ouvrez une invite de commande. Effectuez l'une des opérations suivantes :
    • Arrêtez le service Data Aggregator :
      service dadaemon stop
    • (Environnement à tolérance aux pannes) Si le Data Aggregator local est en cours d'exécution, exécutez l'une des commandes suivantes pour l'arrêter et pour empêcher son redémarrage pendant l'exécution d'opérations de maintenance :
      • RHEL 6.x :
        service dadaemon maintenance
      • RHEL 7.x, SLES ou OL :
        DA_Install_Directory
        /scripts/dadaemon maintenance
  13. Exécutez le script de validation :
    ./dr_validate.sh -p drinstall.properties
    Vous pouvez utiliser l'indicateur
    -l
    pour autoriser l'utilisation de la valeur
    localhost
    pour la propriété
    DbHostNames
    . Vous pouvez utiliser l'indicateur
    -n pour ignorer les vérifications de connectivité de la base de données.
    Le script valide les paramètres du système. Examinez et corrigez les erreurs ou les avertissements. Vous pouvez exécuter ce script plusieurs fois pour vérifier que toutes les options de configuration du système ont été définies correctement. L'exécution du script de validation peut requérir le redémarrage de l'ordinateur.
  14. Utilisez Vertica adminTools pour arrêter le Data Repository :
    1. Passez au rôle d'administrateur de la base de données.
    2. Ouvrez adminTools :
      /opt/vertica/bin/adminTools
    3. Sélectionnez (4) Stop Database (Arrêter la base de données).
    4. Sélectionnez la base de données, confirmez la sélection et entrez le mot de passe.
    5. Fermez l'utilitaire adminTools et reconnectez-vous en tant qu'utilisateur root ou sudo.
  15. Exécutez le script d'installation :
    ./dr_install.sh -p drinstall.properties
    Le script d'installation met à niveau Data Repository et désactive les processus Vertica inutiles. Vous serez peut-être invité à saisir le mot de passe d'administrateur de la base de données Vertica Linux.
    Si aucune connexion SSH n'est configurée, le script vous demande de saisir le mot de passe de configuration.
    Si le script d'installation renvoie un message d'avertissement concernant le gestionnaire de volumes logiques sur les répertoires non utilisés par la base de données Vertica, contactez le service de support de CA.
  16. Vérifiez que Data Repository est installé correctement :
    1. En tant qu'administrateur de la base de données, ouvrez les outils d'administration Vertica :
      /opt/vertica/bin/adminTools
    2. Vérifiez que le haut de la bannière affiche la version de base de données 9.1.1-5.
  17. Dans le menu principal de la boîte de dialogue Administration Tools (Outil d'administration), sélectionnez l'option 3 (Start Database, Lancer la base de données) pour redémarrer le Data Repository.
    Si vous arrêtez la base de données pour la première fois depuis le bond d'une seconde qui a eu lieu le 30 juin 2015, le démarrage de la base de données Vertica peut échouer. Pour plus d'informations, reportez-vous à la section Echec du démarrage de la base de données Vertica.
    Le Data Repository redémarre.
Mise à jour de la sauvegarde
Cette version inclut de nouvelles fonctionnalités pour la sauvegarde de Data Repository. Les sauvegardes précédentes et les fichiers de configuration de la sauvegarde ne sont pas compatibles avec cette version. Configurez une nouvelle version de la sauvegarde. Pour plus d'informations, reportez-vous à la section Sauvegarde du Data Repository.