Wenn Sie auf einem anderen Host wiederherstellen, müssen Sie auf dem vRealize Log Insight-Cluster Konfigurationsänderungen vornehmen.

Ab vRealize Log Insight 3.0 und höheren Versionen wird das direkte Ändern der Konfigurationsdateien von der Appliance-Konsole aus nicht offiziell unterstützt. Informationen zum Ändern dieser Dateien mithilfe der Web-Benutzeroberfläche finden Sie im Knowledgebase-Artikel 2123058.

Dies sind spezielle Konfigurationsänderungen für vRealize Log Insight-Builds, die für jedes Sicherungs- und Wiederherstellungs-Tool verwendet werden können.

Für das Wiederherstellen auf einem anderen Host sind manuelle Konfigurationsänderungen auf dem vRealize Log Insight-Cluster erforderlich. Sie können davon ausgehen, dass die wiederhergestellten vRealize Log Insight-Knoten über andere IP-Adressen und FQDNs als die entsprechenden Quellknoten verfügen, die gesichert wurden.

Voraussetzungen

Lesen Sie wichtige Informationen zu Planung und Vorbereitung.

Prozedur

  1. Listen Sie alle neuen IP-Adressen und FQDNs auf, die jedem vRealize Log Insight-Knoten zugewiesen wurden.
  2. Führen Sie die im Folgenden aufgeführten Konfigurationsänderungen auf dem primären Knoten mithilfe der im Knowledgebase-Artikel 2123058 beschriebenen Schritte durch.
    1. Suchen Sie im Abschnitt „config“ von vRealize Log Insight nach Zeilen, die den im Folgenden aufgeführten Zeilen ähneln.
      <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>

      Der Code zeigt drei Knoten an. Der erste Knoten ist der primäre Knoten, der <service-group name=standalone> zeigt, und die anderen beiden Knoten sind Worker-Knoten, die <service-group name="workernode"> zeigen

    2. Prüfen Sie in der neu wiederhergestellten Umgebung für den primären Knoten, ob der in der Umgebung vor der Wiederherstellung verwendete DNS-Eintrag wiederverwendet werden kann.
      • Falls der DNS-Eintrag wiederverwendet werden kann, aktualisieren Sie nur den DNS-Eintrag, so dass er auf die neue IP-Adresse des primären Knotens verweist.
      • Kann der DNS-Eintrag nicht wiederverwendet werden, ersetzen Sie den Eintrag für den primären Knoten durch einen neuen DNS-Namen (der auf die neue IP-Adresse verweist).
      • Falls der DNS-Name nicht zugewiesen werden kann, aktualisieren Sie als letzte Option den Konfigurationseintrag mit der neuen IP-Adresse.
    3. Aktualisieren Sie zudem die IP-Adressen der Worker-Knoten entsprechend den neuen IP-Adressen.
    4. Stellen Sie in derselben Konfigurationsdatei sicher, dass diese über Einträge verfügt, die NTP-, SMTP- sowie Datenbank- und „appender“-Abschnitte darstellen.
      <ntp>
        <ntp-servers value="ntp1.domain.com, ntp2.domain.com" />
      </ntp>
       
      <smtp>
        <server value="smtp.domain.com" />
        <default-sender value="source.domain.com@domain.com" />
      </smtp>
       
      <database>
        <password value="xserttt" />
        <host value="vrli-node1.domain.com" />
        <port value="12543" />
      </database>
       
      
      • Wenn in der neuen Umgebung die konfigurierten Werte des NTP-Servers nicht mehr gültig sind, passen Sie diese im Abschnitt <ntp>...</ntp> an.
      • Wenn in der neuen Umgebung die konfigurierten Werte des SMTP-Servers nicht mehr gültig sind, passen Sie diese im Abschnitt <smtp>...</smtp> an.
      • Optional können Sie auch den Wert für default-sender im SMTP-Abschnitt ändern. Es kann sich dabei um einen beliebigen Wert handeln, es wird jedoch empfohlen, einen Wert anzugeben, der die Quelle angibt, von wo aus die E-Mail gesendet wird.
      • Ändern Sie im Abschnitt <database>..</database> den Wert für den Host, so dass er auf den FQDN oder die IP-Adresse des primären Knotens verweist.
    5. Aktualisieren Sie in derselben Konfigurationsdatei den vRealize Log Insight ILB-Konfigurationsabschnitt.
      <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. Aktualisieren Sie im Abschnitt <load-balancer>...</load-balancer> den Wert high-availability-ip, wenn er sich von der aktuellen Einstellung unterscheidet.
    7. Stellen Sie sicher, dass auch der FQDN des Lastausgleichsdienstes angepasst wird.
    8. Führen Sie den Neustart über die Web-Benutzeroberfläche anhand der Unterregisterkarte Cluster auf der Registerkarte Administration durch. Wählen Sie für jeden aufgeführten Knoten dessen Hostnamen oder IP-Adresse aus, um den Detailbereich zu öffnen, und klicken Sie auf Log Insight neu starten.
      Die Konfigurationsänderungen werden automatisch auf alle Clusterknoten angewendet.
    9. Warten Sie 2 Minuten nach dem Start des Dienstes vRealize Log Insight, damit für den Start des Cassandra-Dienstes ausreichend Zeit zur Verfügung steht, bevor andere Worker-Knoten online gestellt werden.

Nächste Maßnahme

Stellen Sie sicher, dass den wiederhergestellten vRealize Log Insight-Knoten andere IP-Adressen und FQDNs als den entsprechenden Quellknoten zugewiesen wurden, die gesichert wurden.