Die Hostnamen der an der Sicherung beteiligten Computer müssen in die IPv4-Adresse aufgelöst werden können. Grundsätzlich müssen die Hostnamen aller an der Sicherung beteiligten Clientknoten auf eine IP-Adresse vom Befehlsserver aufgelöst werden können, da sonst Sicherungen und Konnektivitätstests nicht ordnungsgemäß funktionieren. Diese Anforderung besteht unabhängig davon, ob der Knoten ein Basisclientknoten oder ein Clientknoten ist, der als Sicherungsserver aktiviert ist. Diese Anforderung war in früheren Versionen des DataCenter-Produkts nicht vorhanden. Sie wurde in Version 8 gestartet. Dies gilt für alle Clientknoten, die Sie dem Bereich Knotenverwaltung der Befehlsserver-GUI hinzugefügt haben, wobei die Eigenschaft Standardadresse des Knotens lautet zugewiesen durch IP-Adresse. Dies kann daran liegen, dass der Hostname auf einem vom Command Server-Computer verwendeten DNS-Server nicht vorhanden ist, möglicherweise daran, dass sich diese Knoten an einem Remotestandort befinden und ursprünglich per IP hinzugefügt wurden (welche früheren Versionen von DataCenter funktionieren konnten), oder Ein Linux-Computer, der häufig nicht nach Hostnamen aufgelöst werden kann und nur über IP verbunden werden kann. Um dies zu testen, gehen Sie zur Knotenverwaltung, um die Knotenliste anzuzeigen, und notieren Sie sich die Werte in der Spalte "Standardadresse". Wenn der Wert der "Standardadresse" für einen Knoten das IP-Adressformat verwendet, müssen diese Knoten für alle verwendet werden bearbeitet werden, damit ihre Standardadresse ihrem Hostnamen entspricht. Um dies auf dem Command Server-Computer für jeden Knoten zu testen, der eine IP-Adresse für seine 'Standardadresse' verwendet, pingen Sie bitte den Wert in der Eigenschaft 'Hostname' jedes Knotens an, um festzustellen, ob er den Hostnamen auflösen kann die richtige IP-Adresse. Wenn der Befehlsserver nicht in der Lage ist, den Hostnamen jedes Knotens in die richtige IP-Adresse aufzulösen, müssen für diese Knoteneinträge zwei Schritte ausgeführt werden: Fügen Sie sie entweder Ihrem DNS-Server in der lokalen Umgebung hinzu, die der Befehlsserver als DNS-Server verwendet oder fügen Sie sie direkt zur Windows-Hosts-Datei auf dem Command Server-Computer hinzu, damit sie nach Hostnamen aufgelöst werden können, um die IP-Adresse zu korrigieren (Anweisungen finden Sie weiter unten in diesem Artikel). Als letztes müssen Sie die Eigenschaften dieses Knotens bearbeiten, indem Sie in der Knotenverwaltung mit der rechten Maustaste auf diesen Knoten klicken und eine Funktion 'Knoten bearbeiten'> Adresse konfigurieren> Adressen verwalten ausführen, um die 'Standardadresse' so zu ändern, dass sie dem Hostnamen entspricht. Kopieren Sie den Wert aus dem Feld "Hostname" und fügen Sie ihn in das Feld "Standardadresse" ein. Fügen Sie dann denselben Wert für den Hostnamen in das Feld "Anzeigename" ein, wenn er derzeit eine IP-Adresse enthält.
Wir sehen häufig Fälle, in denen Versionen von DataCenter, die älter als DataCenter 8 sind, eine Mischung von Knoten enthalten. In der Regel sind einige Knoten vorhanden, die sich an Remotestandorten befinden, und die Knoten, die sich an Remotestandorten befanden, wurden basierend auf ihrer IP-Adresse und nicht auf dem Hostnamen hinzugefügt (DNS-Name). Diese Remote-Knoten wurden dem Befehlsserver unter Verwendung einer IP-Adresse für die Eigenschaft 'Standardadresse' des Knotens hinzugefügt. Dies ist das primäre Beispiel, bei dem diese Knoten keine Sicherungen oder Konnektivitätstests durchführen können, nur weil die Eigenschaft Standardadresse basiert auf der IP-Adresse und NICHT auf dem Hostnamen. Normalerweise gibt es kein Problem beim Aktualisieren dieser Legacy-Knoten (bei DataCenter 8 ist ein Legacy-Knoten einfach ein Knoten, auf dem Version 8 noch nicht ausgeführt wird), sodass der DataCenter 8-Befehlsserver das Upgrade normalerweise über die Funktion "Knoten aktualisieren" durchführen kann Damit dieser Legacy-Client auf 8 aktualisiert wird, kann er die Knotenaktualisierung abschließen. Selbst wenn der Knoten auf DataCenter 8 aktualisiert wird, muss der Hostname basierend auf der Eigenschaft 'Standardadresse' aufgelöst werden. Wenn dies nicht geändert wird, schlagen Sicherungen und Konnektivitätstests fehl.
Auf dem Command Server-Computer müssen Sie in der Lage sein, den Hostnamen aller Clients zu pingen und ihn in die IP-Adresse aufzulösen, die als Eigenschaft "Standardadresse" des Knotens angegeben ist. Dies unterscheidet sich von DataCenter-Versionen vor Version 8, in denen keine Hostnamenauflösung für an der Sicherung beteiligte Knoten erforderlich war. Sie müssen entweder für jeden Clientknoten einen DNS-Eintrag "Host A" auf Ihren DNS-Servern hinzufügen, der den Hostnamen und die IP-Adresse enthält, auf die die Standardadresseigenschaft beim Anzeigen der Knoteneigenschaften festgelegt ist, oder Sie können einfach einen Hosts-Dateieintrag hinzufügen, um einen Hostnamen nur einer IP-Adresse in der Windows-Hosts-Datei auf dem Command Server-Computer zuzuordnen.
Dies gilt für jeden Clientknoten, bei dem die Eigenschaft Standardadresse für den Knoten eine IP-Adresse verwendet. Alternativ kann die Windows-Hosts-Datei auf dem Befehlsserver für die Zuordnung von Hostnamen verwendet werden. Dies funktioniert auch. Die Notwendigkeit, dies zu tun, scheint weniger problematisch zu sein, wenn das Windows-Betriebssystem moderner ist (zu diesem Zeitpunkt wird der Hostname des Clientknotens über NetBIOS vom Befehlsserver ordnungsgemäß gelesen und aufgelöst). Wenn Sie ein Problem mit dem Konnektivitätstest haben oder ein Sicherungsprotokoll mit dem Hinweis "Fehler: Fehler" für den Inhalt, in dem der Data Mover-Prozess zum Sichern ausgewählter Dateien ausgeführt wird, wird eine .SV-Datei (Sicherungsdatei) erstellt Zieldatenträgerpool, aber am Ende ist kein Wiederherstellungseintrag für diese fehlgeschlagene Sicherung vorhanden. Überprüfen Sie auf dem Befehlsserver, ob Sie den Hostnamen (DNS-Namen) über "Ping-Hostname" auflösen können. Wenn der Hostname nicht in die IP-Adresse aufgelöst werden kann, die in der Eigenschaft Standardadresse des Clientknotens angegeben wurde, tritt dieser Fehler wahrscheinlich auf. Auf dem Command Server-Computer können Sie versuchen, über eine Admin-Eingabeaufforderung "ipconfig / flushdns" und dann "ipconfig / registerdns" auszuführen, und dann denselben Ping-Befehl erneut versuchen. Der Hostname muss in die IP-Adresse aufgelöst werden, die als Standardadresse verwendet wurde, wenn dort eine IP-Adresse (und keine DNS-Adresse) verwendet wird.
Auf den Clientknotencomputern sollte nichts geändert werden müssen. Zur Bestätigung sollten Sie jedoch versuchen, den Hostnamen des Befehlsservers von jedem Ihrer Clientknoten aufzulösen, um sicherzustellen, dass jeder Clientknoten mit dem Befehlsserver kommunizieren kann Weg der DNS-Adresse des Befehlsservers. Dies wäre wichtiger, wenn sich der Windows-Computer in einer WORKGROUP befindet oder ein Linux-Computer, der NetBIOS nicht für die Übersetzung von Hostnamen verwendet (in diesem Fall könnte ein Host-Eintrag in der Datei / etc / hosts unter Linux erstellt werden, um den Befehl zuzuordnen IP-zu-DNS-Adresse des Servers, das Format des Hosts-Dateieintrags ist unabhängig von Windows oder Linux gleich. Beispiel: 'Ping-Befehlsserver', wobei der Befehlsserver der Hostname des Befehlsservers ist. Das muss eine gültige IP-Adresse und Ping-Antwort auflösen und anzeigen, die mit dem Befehlsserver korreliert.
Beispielknoteneigenschaften für unseren Linux-Knoten, wie sie beim erstmaligen Hinzufügen des Knotens über die Knotenverwaltung angezeigt werden. Der Linux-Knoten wird oben nach der IP-Adresse gesucht, nachdem Sie auf die Schaltfläche "Abrufen" geklickt haben. In diesem Fall ändern wir nichts an den Knoteninformationen nachdem es beim Hinzufügen des Knotens abgerufen wurde:
Beispielknoteneigenschaften für unseren Linux-Knoten, wie beim Bearbeiten des Knotens nur zum Anzeigen der Adresseneigenschaften in "Adresse konfigurieren" über die Knotenverwaltung angezeigt, wobei oben die Eigenschaft "Standardadresse" angezeigt wird, die die IP-Adresse des Linux-Clientknotens enthält:
Beispiel für einen Ping-Befehl vom Beispiel-Linux-Knoten:
novastor @ jf-ubuntu2004lts: ~ $ ping-Befehlsserver
PING-Befehle server.sv.novastor.local (192.168.0.123) 56 (84) Datenbytes.
64 Bytes von commandserver.sv.novastor.local (192.168.0.123): icmp_seq = 1 ttl = 128 time = 0.318 ms
64 Bytes von commandserver.sv.novastor.local (192.168.0.123): icmp_seq = 2 ttl = 128 time = 0.303 ms
Die Clientknoten sollten alle in der Lage sein, den Hostnamen des Command Server-Computers aufzulösen. Wenn dies nicht möglich ist, stimmt entweder etwas im DNS oder in anderen Methoden der Namensauflösung nicht, und entweder muss der DNS-Eintrag auf dem DNS-Server korrigiert werden, oder es muss ein Hosts-Dateieintrag zur jeweiligen Hosts-Datei auf jedem Client-Knoten hinzugefügt werden Maschine. Sowohl Windows als auch Linux können eine lokale Hosts-Datei verwenden. Weitere Informationen hierzu finden Sie hier.
Anleitungen / Schritte:
Sie müssen einen DNS-Eintrag "Host A" auf dem primären DNS-Server erstellen, den Ihr Befehlsserver und Ihre Clientknoten als DNS-Server verwenden. Alternativ können Sie eine Windows-Hosts-Datei auf dem Befehlsserver selbst erstellen und für jeden Clientknoten einen Eintrag hinzufügen, um den Hostnamen der IP-Adresse zuzuordnen (die dort angegebene IP-Adresse ist in der Eigenschaft Standardadresse für den Knoten angegeben ) des Knotens, und das wird auch funktionieren. Wie das geht, erfahren Sie weiter unten.
Sichern Sie auf Ihrem Windows Command Server-Computer die Datei C: \ WINDOWS \ System32 \ Drivers \ etc \ hosts als hosts_backup. Bearbeiten Sie dann C: \ WINDOWS \ System32 \ Drivers \ etc \ hosts im Editor oder in NotePad ++ (besser) und fügen Sie dann einen statischen Hosteintrag pro Clientknoten hinzu. Bei einem Linux Command Server-Computer lautet die Hosts-Datei / etc / hosts. Das Format ist für Windows und Linux für die Hosts-Datei gleich. Hinweis: Stellen Sie sicher, dass die Datei nach dem Vornehmen Ihrer Änderungen tatsächlich gespeichert wird. Bearbeiten Sie sie daher zweimal, das zweite Mal, um den Inhalt zu überprüfen. Wenn sie gespeichert ist, können Sie sie testen, indem Sie den Hostnamen jetzt vom Befehlsserver aus anpingen, um sie anzuzeigen das wirkt sich sofort aus. Einige gute Tutorials von Drittanbietern zum Verständnis und zur Verwendung der Hosts-Datei finden Sie hier und hier. Eine Beispiel-Hosts-Datei, die einige in diesem Artikel beschriebene Host-Einträge enthält, finden Sie hier:
# Die Auflösung des localhost-Namens erfolgt innerhalb von DNS.
# 127.0.0.1 localhost
# :: 1 localhost
192.168.0.111 vm1-srv2019
192.168.0.112 vm2-srv2019
192.168.0.126 jf-ubuntu2004lts
Der erste Teil des Windows-Hosteintrags ist die IPv4-Adresse des Clientknotens. Dies ist die bevorzugte IP-Adresse für die Kommunikation mit dem Knoten, wie im Abschnitt Standardadresse des Knotens in Knotenverwaltung: Knoten bearbeiten konfiguriert. Der zweite Teil ist der Computername, der in der Knotenverwaltung: Knoten bearbeiten als Wert für "Hostname" angezeigt wird. Der Hostname ist der Name des Computers, ohne dass das DNS-Suffix hinzugefügt wurde. Fügen Sie jeden Clientknoten, mit dem Sie diese Technik verwenden (wobei die Standardadresse = eine IP-Adresse und keine DNS-Adresse ist), als statischen Windows-Hosts-Dateieintrag auf dem betreffenden Befehlsserver hinzu.
Nachdem Sie den Hosts-Dateieintrag in der Windows-Hosts-Datei gespeichert haben, kehren Sie zur Admin-Eingabeaufforderungssitzung auf dem Befehlsserver zurück und führen Sie über eine Admin-Eingabeaufforderung eine "ipconfig / flushdns" und anschließend "ipconfig / registerdns" aus. Versuchen Sie nun erneut, die Hostnamen des Clientknotens über den Befehl 'ping hostname' aufzulösen, also 'ping vm1-srv2019' und 'ping vm2-srv2019'. Wenn nicht, gehen Sie zurück und überprüfen Sie den Inhalt dieses Hosteintrags entweder im DNS-Eintrag auf dem DNS-Server, auf dem er vorhanden ist, oder in der Windows-Hostsdatei auf dem Befehlsserver. Sie sollten jetzt bereit sein, einen Konnektivitätstest durchzuführen und den Sicherungsjob auszuführen. Hier ist ein Beispiel für eine schrittweise Operation, die auf dem Command Server-Computer über eine Admin-Eingabeaufforderung ausgeführt wird. In diesem Fall haben wir auf keinem unserer lokalen DNS-Server einen DNS-Eintrag für den Beispiel-Linux-Clientknoten, um ihn nach dem Hostnamen vom Befehlsserver pingen zu können. Daher schlägt dies beim ersten Mal fehl:
In diesem Beispiel führen wir die Befehle 'ipconfig / flush' und 'ipconfig / registerdns' aus, pingen dann den Hostnamen des Linux-Clientknotens, der nicht aufgelöst werden kann, und fügen dann den Eintrag der Windows-Hostsdatei auf dem Befehlsserver hinzu Wir pingen noch einmal und der Hostname wird jetzt für den Linux-Clientknoten aufgelöst. Wenn der Befehlsserver nicht ordnungsgemäß mit dem Clientknoten kommunizieren kann, kann er Sicherungen nicht ordnungsgemäß durchführen, obwohl möglicherweise Data Mover-Funktionen Dateien während der Sicherung verarbeiten und die Sicherungs-SV-Datei möglicherweise gespeichert wird. Das Protokoll zeigt möglicherweise Fehler und Diese Sicherung verfügt möglicherweise nicht über einen Eintrag, um sie wiederherstellen zu können.
Hinweis: In früheren Versionen wurde bei der Erstinstallation von DataCenter Command Server 7.3.8 gefragt, welche Methode zur Adressierung des Command Servers verwendet werden soll. Standardmäßig wird die DNS-Methode zum Zuweisen der Hostnamenadresse und alternativ von Ihnen verwendet kann es anweisen, während dieses Setups die IP-Adressmethode zu verwenden. Sie haben während der Installation keine Möglichkeit mehr, die DNS- oder IP-Methode anzugeben. Wenn die IP-Methode zuvor vorhanden war und der Command Server auf Version 8.x aktualisiert wurde, wird die vorherige IP-Zuweisungsmethode in die DNS-Methode für die Version 8 konvertiert Befehlsserverknoten.
Hinweis: Dieser Artikel wurde mit Google Translate vom Englischen ins Deutsche übersetzt.