Lorsque vous effectuez une restauration sur un hôte différent, vous devez effectuer des modifications de configuration sur le cluster VMware Aria Operations for Logs.

La modification directe des fichiers de configuration à partir de la console du dispositif n'est pas officiellement prise en charge dans VMware Aria Operations for Logs 3.0 et les versions ultérieures. Consultez l'article 2123058 de la base de connaissances pour plus d'informations sur la modification de ces fichiers à l'aide de l'interface utilisateur Web.

Ces modifications de configuration sont spécifiques aux builds VMware Aria Operations for Logs et peuvent être utilisées avec n'importe quel outil de récupération de sauvegarde.

La récupération sur un hôte différent nécessite des modifications de configuration manuelles sur le cluster VMware Aria Operations for Logs. Vous pouvez supposer que les nœuds VMware Aria Operations for Logs restaurés ont des adresses IP et des noms de domaine complets différents de ceux de leurs contreparties sources utilisées pour la sauvegarde.

Conditions préalables

Consulter des informations importantes concernant Planification et préparation.

Procédure

  1. Répertoriez toutes les nouvelles adresses IP et nouveaux noms de domaine complets qui ont été attribués à chaque nœud VMware Aria Operations for Logs.
  2. Apportez les modifications de configuration suivantes sur le nœud principal en suivant la procédure décrite dans l'article 2123058 de la base de connaissances.
    1. Dans la section de configuration de VMware Aria Operations for Logs, recherchez les lignes qui sont semblables aux lignes suivantes. 
      <distributed overwrite-children="true">
  <daemon host="prod-es-vrli1.domain.com" port="16520" token="c4c4c6a7-f85c-4f28-a48f-43aeea27cd0e">
    <service-group name="standalone" />
  </daemon>
  <daemon host="192.168.1.73" port="16520" token="a5c65b52-aff5-43ea-8a6d-38807ebc6167">
    <service-group name="workernode" />
  </daemon>
  <daemon host="192.168.1.74" port="16520" token="a2b57cb5-a6ac-48ee-8e10-17134e1e462e">
    <service-group name="workernode" />
  </daemon>
</distributed>

      Le code affiche trois nœuds. Le premier est le nœud principal, qui affiche <service-group name=standalone>, et les deux autres sont des nœuds travailleurs, qui affichent <service-group name="workernode">

    2. Pour le nœud principal, vérifiez dans l'environnement récemment détecté que vous pouvez réutiliser l'entrée DNS qui a été utilisée dans l'environnement de récupération préalable.
      • Le cas échéant, mettez uniquement à jour l'entrée DNS pour qu'elle pointe vers la nouvelle adresse IP du nœud principal.
      • Si vous ne pouvez pas réutiliser l'entrée DNS, remplacez l'entrée du nœud principal par un nouveau nom DNS (pointant vers la nouvelle adresse IP).
      • Si le nom DNS ne peut pas être attribué, comme dernière option, mettez à jour l'entrée de configuration avec la nouvelle adresse IP.
    3. Mettez également à jour les adresses IP du nœud travailleur pour refléter les nouvelles adresses IP.
    4. Dans le même fichier de configuration, vérifiez qu'il existe des entrées qui représentent les sections NTP, SMTP, database et appenders. 
      <ntp>
  <ntp-servers value="ntp1.domain.com, ntp2.domain.com" />
</ntp>
 
<smtp>
  <server value="smtp.domain.com" />
  <default-sender value="[email protected]" />
</smtp>
 
<database>
  <password value="xserttt" />
  <host value="vrli-node1.domain.com" />
  <port value="12543" />
</database>
      • Si les valeurs de serveur NTP configurées ne sont plus valides dans le nouvel environnement, mettez-les à jour dans la section <ntp>…</ntp>.
      • Si les valeurs de serveur SMTP configurées ne sont plus valides dans le nouvel environnement, mettez-les à jour dans la section <smtp>...</smtp>.
      • Modifiez éventuellement la valeur default-sender dans la section SMTP. Vous pouvez utiliser n'importe quelle valeur, mais il est recommandé de représenter la source à partir de l'emplacement depuis lequel l'e-mail est envoyé.
      • Dans la section <database>..</database>, modifiez la valeur hôte pour qu'elle pointe vers le nom de domaine complet ou l'adresse IP du nœud principal.
    5. Dans le même fichier de configuration, mettez à jour la section de configuration de l'ILB VMware Aria Operations for Logs. 
      <load-balancer> 
<leadership-lease-renewal-secs value="5" /> 
<high-availability-enabled value="true" /> 
<high-availability-ip value="10.158.128.165" />  
<high-availability-fqdn value="LB-FQDN.eng.vmware.com" />  
<layer4-enabled value="true" />  
<ui-balancing-enabled value="true" /> 
</load-balancer>
    6. Sous la section <load-balancer>...</load-balancer>, mettez à jour la valeur high-availability-ip si elle est différente du paramètre actuel.
    7. Veillez également à mettre à jour le nom de domaine complet de l'équilibrage de charge.
    8. Redémarrez à partir de l'interface utilisateur Web via le sous-onglet Cluster de l'onglet Administration. Pour chaque nœud répertorié, sélectionnez son nom d'hôte ou son adresse IP pour ouvrir le panneau de détail, puis cliquez sur Redémarrer Operations for Logs.
      Les modifications de configuration sont automatiquement appliquées à tous les nœuds de cluster.
    9. Patientez deux minutes après le démarrage du service VMware Aria Operations for Logs pour permettre au service Cassandra de démarrer avant d'appeler d'autres nœuds travailleurs en ligne.

Que faire ensuite

Vérifiez que les nœuds VMware Aria Operations for Logs restaurés se sont vus attribuer des adresses IP et des noms de domaine complets différents de ceux attribués à leurs contreparties sources utilisées pour la sauvegarde.