Migration du Data Repository

Pour migrer Data Repository, installez Vertica sur le nouveau cluster et migrez les données. La migration peut être requise dans les conditions suivantes :
capm370
Pour migrer Data Repository, installez Vertica sur le nouveau cluster et migrez les données. La migration peut être requise dans les conditions suivantes :
  • Vous migrez vers de nouveaux hôtes pour réaliser une mise à niveau majeure du système d'exploitation (par exemple, de RHEL 6.9 à RHEL 7.3).
  • Le matériel de la base de données actuel ne répond plus aux exigences applicables au dimensionnement.
  • Vous remplacez des ordinateurs virtuels par du matériel physique pour la base de données.
Vous devez mettre à niveau le système existant vers la version du produit vers laquelle vous migrez avant d'effectuer la migration.
Pour plus d’informations sur la copie de la base de données vers un autre cluster, consultez la documentation Vertica.
2
Selon la quantité de données, la migration du Data Repository peut prendre un certain temps.
Pour réduire les temps d’arrêt, effectuez des sauvegardes incrémentielles après la sauvegarde initiale.
Préparation de l'installation de Data Repository de destination
Avant d’installer Vertica sur le nouveau cluster, préparez l’environnement pour l’installation. Pour plus d'informations sur la préparation du cluster de destination, reportez-vous à la section Préparation de l'installation de Data Repository.
Le cluster cible doit inclure les éléments suivants :
  • Le même nombre de noeuds que le cluster source
  • Une base de données portant le même nom que la base de données source
    La base de données cible peut être vide.
  • Les mêmes noms de noeud que le cluster source
    Les noms de noeuds répertoriés dans les tables système NODES sur les clusters doivent correspondre. Pour modifier les noms de noeud après l'installation sur le nouveau système pour correspondre à ceux existants, contactez le support.
  • Accessibilité à partir du cluster source
  • Le même compte d’administrateur de base de données et tous les noeuds doivent permettre à un administrateur de base de données du cluster source de se connecter via SSH sans mot de passe.
    L'accès sans mot de passe au sein du cluster n'équivaut pas à un accès sans mot de passe entre clusters. L’ID SSH du compte d’administrateur sur le cluster source et le cluster cible ne sont probablement pas le même. Vous devez configurer chaque hôte dans le cluster cible de sorte qu'ils acceptent l’authentification SSH du cluster source.
  • Garantissez l'espace disque suffisant pour l'exécution de la commande
    vbr --task copycluster
    .
Installation de Vertica sur le nouveau cluster
Le processus d'installation est identique à une installation ordinaire de Data Repository. Pour plus d'informations, reportez-vous à la section Installation du Data Repository.
Utilisez la même configuration pour le nouveau cluster que pour le cluster source. Par exemple, la version de Vertica, le nombre de noeuds, le nom de la base de données, l'administrateur, l'utilisateur, le répertoire de catalogues et le répertoire de données doivent être identiques à ceux du Data Repository d'origine.
Migration du cluster
Après avoir installé la base de données sur le nouveau cluster, migrez les données existantes. Le processus de migration utilise la commande Copy Cluster, qui permet de sauvegarder la base de données existante et de restaurer les données vers le nouveau cluster simultanément. Le cluster à copie unique est configuré, puis démarré et exécuté sur le système source pour pointer vers le nouveau système. Vous pouvez exécuter le cluster à copie unique sur un noeud unique sur le système source et il se copie sur tous les noeuds du nouveau système. Copy cluster copie toutes les données dans le Data Repository avant que vous exécutiez la commande. Le processus requiert plusieurs exécutions de la commande Copy Cluster, car
DX NetOps Performance Management
continue à collecter des données pendant la migration.
3
Création d'un fichier de configuration pour la commande Copy Cluster
Avant de configurer le cluster cible, vous devez connaître les noms exacts fournis par
à tous les noeuds de la base de données source.
Pour afficher les noms de noeud, exécutez une requête semblable à la requête suivante :
VMart=> select node_name from nodes;
node_name
------------------
v_vmart_node0001
v_vmart_node0002
v_vmart_node0003
(3 rows)
La commande Copy Cluster requiert un fichier de configuration qui inclut les informations nécessaires. Vous pouvez créer le fichier dans n'importe quel emplacement sur le système source et lui attribuer un nom avec une extension
.ini
. Dans le fichier de configuration, spécifiez les noms des noeuds du cluster cible en tant qu'hôtes de sauvegarde. Spécifier les noeuds dans une section
[Mapping]
, comme dans l’exemple suivant. Spécifiez le nom de noeud complet, pas le nom court (par exemple,
v_vmart_node0001
et non
node0001
).
Exemple :
L'exemple de fichier de configuration suivant est configuré pour copier une base de données sur un cluster à trois noeuds (
v_vmart_node0001
,
v_vmart_node0002
et
v_vmart_node0003
) vers un autre cluster de noeuds (test-host01, test-host02 et test-host03).
Le paramètre dbName est sensible à la casse.
[Misc]
snapshotName = CopyVmart
restorePointLimit = 5
objectRestoreMode = createOrReplace
tempDir = /tmp/vbr
retryCount = 5
retryDelay = 1
[Database]
dbName =
vmart
dbUser =
dradmin
dbPassword =
password
dbPromptForPassword = False
[Transmission]
encrypt = False
checksum = False
port_rsync = 50000
[Mapping]
; backupDir is not used for cluster copy
v_vmart_node0001= test-host01
v_vmart_node0002= test-host02
v_vmart_node0003= test-host03
Assurez-vous que le répertoire
/home/dradmin/backup
existe sur votre ordinateur. Vérifiez que le répertoire
/tmp/vbr
dispose d'autorisations de lecture et d'écriture.
Arrêt de la base de données cible
Avant de lancer la migration, arrêtez la base de données sur le cluster cible.
Procédez comme suit :
  1. Connectez-vous au cluster de base de données cible en tant qu’administrateur de la base de données.
  2. Ouvrez les outils d'administration Vertica :
    /opt/vertica/bin/adminTools
  3. Sélectionnez (4) Stop Database (Arrêter la base de données). Patientez jusqu'à l’arrêt complet avant d’exécuter la commande Copy Cluster.
Copie des données historiques
Après avoir installé la base de données sur le nouveau cluster, copiez les données à partir de la base de données existante. La commande Copy Cluster copie toutes les informations avant que vous lanciez la commande. Des nouvelles données continuent d'être transmises lors de l’exécution de la commande, mais la commande ne copie pas ces données. Le cluster cible doit être arrêté avant d’appeler la commande copy cluster.
Procédez comme suit :
  1. Connectez-vous au cluster source avec le compte d’administrateur de la base de données.
  2. Vérifiez que la connexion SSH est activée pour le compte d'administrateur de bases de données. Dans une installation en cluster, assurez-vous que les clés SSH sans mot de passe sont configurées pour
    chaque
    hôte inclus dans le cluster.
    ssh
    hostname
    ls
    hostname :
    indique le nom de l'hôte sur lequel le Data Repository est installé.
    Si la clé SSH sans mot de passe est configurée, vous n'êtes
    pas
    invité à saisir de mot de passe. Si vous êtes invité à saisir un mot de passe, configurez une connexion SSH sans mot de passe :
    1. Appuyez sur Ctrl + C.
    2. Configurez le compte d'utilisateur Linux de l'administrateur de la base de données avec une clé SSH sans mot de passe :
      ssh-keygen -N "" -t rsa -f ~/.ssh/id_rsa
      cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys2
      chmod 644 ~/.ssh/authorized_keys2
    3. Copiez les informations d'identification SSH au niveau des autres hôtes dans le cluster :
      ssh-copy-id -i
      dradmin
      @
      other-hostname-in-the-cluster
    4. Confirmez que vous n'êtes
      pas
      invité à saisir un mot de passe :
      ssh hostname ls
  3. Exécutez la commande copy cluster :
    vbr.py --task copycluster --config-file
    CopyClusterConfigurationFile
    .ini
    La commande copie les données historiques pour la base de données et affiche le message suivant :
    > vbr.py --config-file CopyVmart.ini --task copycluster
    Preparing...
    Copying...
    1871652633 out of 1871652633, 100%
    All child processes terminated successfully.
    copycluster done!
    Si la commande
    copycluster
    échoue, vérifiez que la connexion SSH est activée pour le compte d'administrateur de bases de données.
Vérification de la copie des données historiques
Une fois le processus de la commande copy cluster terminé, vérifiez l’intégrité de vos données.
Procédez comme suit :
  1. Connectez-vous au cluster de base de données cible en tant qu’administrateur de la base de données.
  2. Ouvrez les outils d'administration Vertica :
    /opt/vertica/bin/adminTools
  3. Démarrez la base de données.
  4. A partir d'un noeud du cluster, ouvrez l’invite Vertica SQL :
    /opt/vertica/bin/vsql -U dauser
  5. Exécutez les requêtes suivantes pour vérifier l’horodatage de ces tables de base de données clés :
    SELECT to_timestamp(max(tstamp)) from dauser.reach_rate;
    SELECT to_timestamp(max(tstamp)) from dauser.ifstats_rate;
    La date et l’heure doivent correspondre au moment du début de la copie.
  6. Ouvrez les outils d'administration et arrêtez la base de données.
Arrêt de Data Aggregator
Pour préserver l’intégrité de vos données, arrêtez Data Aggregator avant la copie finale de Data Repository. L’interrogation se poursuit sur le Data Collector s’il est exécuté et réalise une interrogation lorsque Data Aggregator est arrêté. Data Collector met en file d'attente les données interrogées pour les transmettre ultérieurement à Data Aggregator.
Procédez comme suit :
  1. Connectez-vous à l'hôte de Data Aggregator en tant qu'utilisateur root ou qu'utilisateur sudo.
    Si vous avez installé le Data Aggregator en tant qu'utilisateur sudo, vous avez configuré un alias sudo pour la commande service dadaemon. Utilisez les commandes sudo.
  2. Utilisez les règles de pare-feu pour bloquer le trafic provenant de tous les Data Collectors. Exécutez la commande suivante pour chaque Data Collector :
    iptables -A INPUT -s
    DC_IP
    -j DROP
    DC_IP
    spécifie l’adresse IP du Data Collector.
  3. Effectuez l'une des opérations suivantes :
    • Arrêtez le service Data Aggregator :
      service dadaemon stop
      Pour RHEL 7.x ou OL,
      service
      appelle
      systemctl
      . Vous pouvez utiliser
      systemctl
      à la place.
    • (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
    Le Data Aggregator s'arrête.
Copie des données récentes
Une fois Data Aggregator arrêté, exécutez la commande copy cluster pour copier les données récentes. Le Data Repository permet de copier uniquement les nouvelles données transmises après la copie initiale.
Procédez comme suit :
  1. Connectez-vous au cluster source avec le compte d’administrateur de la base de données.
  2. Exécutez la commande copy cluster :
    vbr.py --task copycluster --config-file
    CopyConfigurationFile
    .ini
    La commande copie les données récentes.
Vérification de la copie des données récentes
Pour garantir leur intégrité, vérifiez vos données.
Procédez comme suit :
  1. Connectez-vous au cluster de base de données cible en tant qu’administrateur de la base de données.
  2. Ouvrez les outils d'administration Vertica :
    /opt/vertica/bin/adminTools
  3. Démarrez la base de données.
  4. A partir d'un noeud du cluster, ouvrez l’invite Vertica SQL :
    /opt/vertica/bin/vsql -U dauser
  5. Exécutez les requêtes suivantes pour vérifier l’horodatage de ces tables de base de données clés :
    SELECT to_timestamp(max(tstamp)) from dauser.reach_rate;
    SELECT to_timestamp(max(tstamp)) from dauser.ifstats_rate;
    La date et l’heure doivent correspondre au moment du début de la copie.
Mise à jour des informations de connexion à la base de données
Si vous ne migrez pas le Data Aggregator, pour activer la communication entre le Data Aggregator et le nouveau cluster Data Repository, mettez à jour les informations de connexion à la base de données.
Procédez comme suit :
  1. Connectez-vous à l'hôte de Data Aggregator.
  2. Ouvrez le fichier suivant :
    vi /opt/IMDataAggregator/apache-karaf-
    version
    /etc/dbconnection.cfg
  3. Mettez à jour le paramètre suivant avec les noms d’hôtes du nouveau cluster Data Repository :
    dbHostNames=
    hostname1,hostname2,hostname3
Redémarrage du Data Aggregator
Une fois la migration terminée, redémarrez le Data Aggregator.
Procédez comme suit :
  1. Connectez-vous à l'hôte de Data Aggregator en tant qu'utilisateur root ou qu'utilisateur sudo.
    Si vous avez installé le Data Aggregator en tant qu'utilisateur sudo, vous avez configuré un alias sudo pour la commande service dadaemon. Utilisez les commandes sudo.
  2. Effectuez l'une des opérations suivantes :
    • Démarrez le service Data Aggregator :
      service dadaemon start
    • (Environnement à tolérance aux pannes) Exécutez l'une des commandes suivantes pour activer le Data Aggregator à tolérance aux pannes afin qu'il puisse démarrer lorsque cela est nécessaire :
      • RHEL 6.x :
        service dadaemon activate
      • RHEL 7.x, SLES ou OL :
        DA_Install_Directory
        /scripts/dadaemon activate
    Le Data Aggregator démarre et se synchronise avec CA
    NetOps Portal
    et le Data Repository. Lorsque les entrées iptables sont supprimées, les données interrogées et placées en file d’attente sur les Data Collectors sont envoyées au Data Aggregator. Les données les plus anciennes sont rejetées si les données placées en file d’attente dépassent une limite d’espace disque configurée sur le système du Data Collector. Par conséquent, il existe un écart dans les données de génération de rapports interrogées.
  3. Surveillez le processus de redémarage du Data Aggregator :
    1. Connectez-vous à l’hôte de Data Aggregator et accédez au répertoire suivant :
      /opt/IMDataAggregator/performance-spool
    2. Patientez quelques minutes après le démarrage du service Data Aggregator. Vérifiez qu’aucun fichier DTO de taille supérieure à zéro n’existe.
    3. Activez le trafic provenant du Data Collector SNMP avec un nombre supérieur d’éléments interrogés :
      iptables -D INPUT -s
      DC_IP
      -j DROP
      Le Data Aggregator lance la validation de schéma et le traitement des nouvelles données interrogées et mises en cache à partir de ce Data Collector.
    4. Une fois que l’utilisation du système Data Aggregator diminue, activez le trafic provenant des autres Data Collectors SNMP.
    5. Une fois que l’utilisation du système du Data Aggregator diminue, activez le trafic provenant des Data Collectors CAMM.
Vérification de la migration
A l'issue du démarrage du Data Aggregator, connectez-vous à CA
NetOps Portal
et vérifiez les indicateurs suivants :
  • Le statut du système est correct et la source de données du Data Aggregator est disponible.
  • Vérifiez la date et l'heure de la dernière interrogation des données.
  • Accédez à la liste Data Collector et vérifiez que tous les Data Collectors sont activés et collectent des données.
  • Ouvrez le tableau de bord présentation de l’infrastructure et vérifiez que les données sont disponibles pour les plages horaires suivantes :
    • Dernière heure
    • 7 derniers jours