Bereitstellen eines Azure Storage Mover-Agents
Der Azure Storage Mover-Dienst verwendet Agents, um die im Dienst konfigurierten Migrationsaufträge auszuführen. Ein Agent ist eine VM-basierte Migrations-Appliance, die auf einem Virtualisierungshost ausgeführt wird. Idealerweise befindet sich der Virtualisierungshost so nah wie möglich am zu migrierenden Quellspeicher. Storage Mover kann mehrere Agents unterstützen.
Da ein Agent im Wesentlichen eine Migrationsanwendung ist, interagieren Sie über eine Agent-lokale Verwaltungsshell mit dem Agent. Die Shell beschränkt die Vorgänge, die Sie auf dem Computer ausführen können, wobei Netzwerkkonfigurations- und Problembehandlungsaufgaben verfügbar bleiben.
Die Verwendung des Agents bei Migrationen wird über Azure verwaltet. Sowohl Azure PowerShell als auch CLI werden unterstützt. Die grafische Interaktion ist innerhalb des Azure-Portals verfügbar. Der Agent wird als Datenträgerimage verfügbar gemacht, das entweder mit neuen virtuellen Windows Hyper-V- oder VMware-VMs kompatibel ist.
Dieser Artikel führt Sie durch die erforderlichen Schritte für die erfolgreiche Bereitstellung von Storage Mover-Agent-VMs.
Voraussetzungen
- Ein Windows Hyper-V- oder VMware-Host, auf dem die Agent-VM ausgeführt werden soll.
Weitere Informationen zu Anforderungen der Agent-VM finden Sie im Abschnitt Empfohlene Compute- und Speicherressourcen in diesem Artikel.
Hinweis
Gegenwärtig sind Windows Hyper-V und VMware die einzigen unterstützten Virtualisierungsumgebungen für Ihre Agent-VM. Andere Virtualisierungsumgebungen wurden nicht getestet und werden nicht unterstützt.
Ermitteln der für den virtuellen Computer erforderlichen Ressourcen
Wie jeder virtuelle Computer benötigt der Agent verfügbare Compute-, Speicher, Netzwerk- und Speicherplatzressourcen auf dem Host. Obwohl sich die Gesamtdatengröße auf die für die Migration erforderliche Zeit auswirken kann, hängen die Ressourcenanforderungen im Allgemeinen maßgeblich von der Anzahl der Dateien und Ordner ab.
Netzwerkressourcen
Der Agent erfordert eine uneingeschränkte Internetkonnektivität.
Obwohl es keine einzige Netzwerkkonfigurationsoption gibt, die für alle Umgebungen funktioniert, umfasst die einfachste Konfiguration die Bereitstellung eines externen virtuellen Switches. Der Typ des externen Switches ist mit einem physischen Adapter verbunden und ermöglicht es Ihrem Hostbetriebssystem (Betriebssystem), die Verbindung mit allen virtuellen Computern (VMs) zu teilen. Dieser Switch ermöglicht die Kommunikation zwischen Ihrem physischen Netzwerk, dem Verwaltungsbetriebssystem und den virtuellen Adaptern auf Ihren virtuellen Computern. Dieser Ansatz kann für eine Testumgebung akzeptabel sein, ist für einen Produktionsserver jedoch nicht ausreichend.
Stellen Sie nach dem Erstellen des Switches sicher, dass sich sowohl die Verwaltungs- als auch die Agent-VMs auf demselben Switch befinden. Auf der WAN-Link-Firewall muss der ausgehende TCP-Port 443 geöffnet sein. Denken Sie daran, dass beim Änderen von Netzwerkkonfigurationen mit Verbindungsunterbrechungen zu rechnen ist.
Hilfe zum Erstellen eines virtuellen Switches für virtuelle Hyper-V-Computer finden Sie in der Windows Server-Dokumentation. Detaillierte Anleitungen zum Erstellen eines virtuellen Switchs für VMware-gehostete VMs finden Sie auf der VMware-Supportwebsite.
Empfohlene Compute- und Speicherressourcen
| Migrationsumfang* | Arbeitsspeicher (RAM) | Anzahl virtueller Prozessorkerne (bei min. 2 GHz.) |
|---|---|---|
| 1 Million Objekte | 8 GiB | 4 virtuelle Kerne |
| 10 Millionen Objekte | 8 GiB | 4 virtuelle Kerne |
| 30 Millionen Objekte | 12 GiB | 6 virtuelle Kerne |
| 50 Millionen Objekte | 16 GiB | 8 virtuelle Kerne |
| 100 Millionen Objekte | 16 GiB | 8 virtuelle Kerne |
Anzahl der Objekte bezieht sich auf die Gesamtanzahl der Dateien und Ordner in der Quelle.
Wichtig
Agent-VMs unterhalb der minimalen Spezifikationen können zwar möglicherweise für Ihre Migration verwendet werden, funktionieren eventuell jedoch nicht optimal und werden nicht unterstützt.
Der Artikel Leistungsziele enthält Testergebnisse zu verschiedenen Quell-Namespaces und VM-Ressourcen.
Lokale Speicherkapazität
Das Agent-Image erfordert mindestens 20 GiB lokalen Speicher. Die erforderliche Speichermenge kann höher sein, wenn während einer Migration eine große Anzahl kleiner Dateien zwischengespeichert wird.
Herunterladen des VM-Images des Agents
Images für Agent-VMs stehen im Microsoft Download Center als ZIP-Datei zur Verfügung. Laden Sie die Datei unter https://aka.ms/StorageMover/agent herunter und extrahieren Sie das Virtuelle Datenträgerimage (VHD) des Agents auf Ihren Virtualisierungshost.
Erstellen der Agent-VM
Die folgenden Schritte beschreiben den Prozess zum Erstellen eines virtuellen Computers mit Microsoft Hyper-V. Detaillierte Anleitungen zum Erstellen einer VMware-basierten VM finden Sie auf der VMware-Supportwebsite.
Erstellen eines neuen virtuellen Computers, um den Agent zu hosten. Öffnen Sie den Hyper-V-Manager. Wählen Sie im Bereich Aktionen Neu und Virtueller Computer... aus, um den Assistenten „Neuer virtueller Computer“ zu starten.
Geben Sie im Bereich Name und Speicherort angeben Werte für die Felder Name und Speicherort des Agents an. Der Speicherort sollte nach Möglichkeit dem Ordner entsprechen, in dem die VHD gespeichert ist. Wählen Sie Weiter aus.
Wählen Sie im Bereich Generation angeben die Option 1. Generation aus.
Wichtig
Es werden nur VMs der 1. Generation unterstützt. Dieses Linux-Image kann nicht als VM der 2. Generation gestartet werden.
Sofern noch nicht geschehen, bestimmen Sie die Menge des für Ihren virtuellen Computer erforderlichen Arbeitsspeichers. Geben Sie diesen Wert im Bereich Speicher zuweisen ein, beachten Sie, dass Sie den Wert in MiB eingeben müssen. 1 GiB = 1024 MiB. Die Verwendung der Funktion „Dynamischer Speicher“ ist möglich.
Wählen Sie im Bereich Netzwerk konfigurieren die Dropdown-Option Verbindung aus. Wählen Sie in der Liste den virtuellen Switch aus, über den der Agent die Internetverbindung erhält, und wählen Sie Weiter aus. Weitere Informationen finden Sie in der Dokumentation zu virtuellen Hyper-V-Netzwerken.
Klicken Sie im Bereich Virtuelle Festplatte verbinden auf die Option Vorhandene virtuelle Festplatte verwenden. Wählen Sie im Feld Speicherort die Option Durchsuchen aus, und navigieren Sie zu der VHD-Datei, die in den vorherigen Schritten extrahiert wurde. Wählen Sie Weiter aus.
Wählen Sie im Bereich Zusammenfassung die Option Fertig stellen aus, um den Virtuellen Agent zu erstellen.
Nachdem der neue Agent erstellt wurde, wird er im Bereich Virtuelle Computer des Hyper-V-Managers angezeigt.
Ändern des Standardkennworts
Der Agent wird mit einem Standardbenutzerkonto und -Kennwort bereitgestellt. Stellen Sie eine Verbindung mit dem neu erstellten Agent her, und ändern Sie das Standardkennwort unmittelbar nach der Bereitstellung und dem Start des Agents.
Führen Sie auf einem Computer im gleichen Subnetz wie der Agent einen ssh-Befehl aus:
ssh <AgentIpAddress> -l admin
Wichtig
Ein neu bereitgestellter Storage Mover-Agent verfügt über ein Standardkennwort:
Lokaler Benutzer: Administrator
Standardkennwort: Administrator
Es wird empfohlen, das Standardkennwort sofort nach dem ersten Verbindungsaufbau mit einem neu bereitgestellten Agent zu ändern. Notieren Sie das neue Kennwort, es gibt keine Möglichkeit zur Wiederherstellung. Wenn Sie Ihr Kennwort verlieren, werden Sie aus der Verwaltungsshell ausgesperrt. Für die Cloudverwaltung ist dieses lokale Administratorkennwort nicht erforderlich. Wenn der Agent zuvor registriert wurde, können Sie es weiterhin für Migrationsaufträge verwenden. Agents sind entbehrlich. Ihr Nutzen ist auf den aktuellen Migrationsauftrag beschränkt. Sie können stets neue Agents bereitstellen und diese stattdessen für den nächsten Migrationsauftrag verwenden.
Bandbreiteneinschränkung
Nehmen Sie sich Zeit, um die Bandbreite zu berücksichtigen, die ein neuer Computer verwendet, bevor Sie ihn in Ihrem Netzwerk bereitstellen. Ein Azure Storage Mover-Agent kommuniziert mit einer Quellfreigabe über das lokale Netzwerk und mit dem Azure Storage-Dienst über die WAN-Verbindung (Wide Area Network). In beiden Fällen ist der Agent so konzipiert, dass die Bandbreite des Netzwerks standardmäßig vollständig genutzt wird. Sie können jedoch jetzt Zeitpläne für die Bandbreitenverwaltung für Ihre Storage Mover-Agents festlegen.
Alternativ können Sie ein lokales virtuelles Netzwerk mit einer Internetverbindung erstellen und QoS-Einstellungen (Quality of Service) konfigurieren. Mit diesem Ansatz können Sie den Agent über das virtuelle Netzwerk verfügbar machen und bei Bedarf einen nicht authentifizierten Netzwerkproxyserver auf dem Agent konfigurieren.
Außerbetriebsetzung eines Agents
Wenn Sie einen bestimmten Storage Mover-Agent nicht mehr benötigen, können Sie ihn deaktivieren. Die Außerbetriebsetzung erfolgt in zwei Schritten:
- Aufheben der Registrierung des Agent aus der Storage Mover-Ressource.
- Beenden der Agent-VM auf Ihrem Virtualisierungshost und anschließendes Löschen.
Die Außerbetriebsetzung eines Agents beginnt mit der Aufhebung der Registrierung des Agents. Es gibt drei Optionen, die Aufhebung der Registrierung zu starten:
Sie können die Registrierung eines Agents mithilfe der Verwaltungsshell der Agent-VM aufheben. Der Agent muss mit dem Dienst verbunden sein und lokal wie auch über das Azure-Portal und entweder Azure PowerShell oder Azure CLI als „online“ angezeigt werden.
Führen Sie auf einem Computer im gleichen Subnetz wie der Agent einen ssh-Befehl aus:
ssh <AgentIpAddress> -l admin
Wichtig
Ein neu bereitgestellter Storage Mover-Agent verfügt über ein Standardkennwort:
Lokaler Benutzer: Administrator
Standardkennwort: Administrator
Es wird empfohlen, das Standardkennwort sofort nach dem ersten Verbindungsaufbau mit einem neu bereitgestellten Agent zu ändern. Notieren Sie das neue Kennwort, es gibt keine Möglichkeit zur Wiederherstellung. Wenn Sie Ihr Kennwort verlieren, werden Sie aus der Verwaltungsshell ausgesperrt. Für die Cloudverwaltung ist dieses lokale Administratorkennwort nicht erforderlich. Wenn der Agent zuvor registriert wurde, können Sie es weiterhin für Migrationsaufträge verwenden. Agents sind entbehrlich. Ihr Nutzen ist auf den aktuellen Migrationsauftrag beschränkt. Sie können stets neue Agents bereitstellen und diese stattdessen für den nächsten Migrationsauftrag verwenden.
1) System configuration
2) Network configuration
3) Service and job status
4) Unregister
5) Collect support bundle
6) Restart agent
7) Disk Cleanup
8) Exit
xdmsh> 4
Wählen Sie die Option 4) Registrierung aufheben. Sie werden aufgefordert, diesen Schritt zu bestätigen.
Warnung
Die Aufhebung der Registrierung beendet alle ausgeführten Migrationsaufträge des Agents und entfernt den Agent endgültig aus dem Pool der verfügbaren Migrations-Agents. Die erneute Registrierung einer zuvor registrierten Agent-VM wird nicht unterstützt. Wenn Sie einen neuen Agent benötigen, sollten Sie eine neue, zuvor nicht registrierte Agent-VM registrieren. Verwenden Sie keine Agent-VM, deren Registrierung zuvor aufgehoben wurde.
Während der Aufhebung der Registrierung geschehen mehrere Dinge:
Der Agent wird aus der Storage Mover-Ressource entfernt. Der Agent wird nicht mehr auf der Registerkarte Registrierte Agents im Portal angezeigt und kann nicht für neue Migrationsaufträge ausgewählt werden.
Der Agent wird ebenfalls aus dem Azure ARC-Dienst entfernt. Wird er entfernt, werden auch die Hybrid-Compute-Ressourcen des Typs Server – Azure Arc gelöscht, die den Agent im Azure ARC-Dienst in derselben Ressourcengruppe wie Ihre Storage Mover-Ressource darstellten.
Die Aufhebung der Registrierung entfernt die verwaltete Identität des Agents aus Microsoft Entra ID. Der zugeordnete Dienstprinzipal wird automatisch entfernt, wodurch die Berechtigungen, die dieser Agent möglicherweise auf anderen Azure-Ressourcen hatte, ungültig werden. Wenn Sie die Rollenzuweisungen der rollenbasierten Zugriffssteuerung (RBAC) prüfen, z. B. für einen Zielspeichercontainer, für den der Agent zuvor über Berechtigungen verfügte, wird der Dienstprinzipal des Agents nicht mehr angezeigt, da er gelöscht wurde. Die Zuordnung selbst ist weiterhin als „Unbekannter Dienstprinzipal“ sichtbar, diese Zuordnung kann jedoch keine Verbindung mit einer Identität mehr herstellen und kann nie erneut verbunden werden. Dies ist lediglich ein Hinweis auf eine ehemalige Rollenzuweisung eines Dienstprinzipals, der nicht mehr vorhanden ist.
Dieses Verhalten ist normal und nicht spezifisch für den Azure Storage Mover. Das Gleiche geschieht, wenn Sie einen anderen Dienstprinzipal von Microsoft Entra ID entfernen und dann eine frühere Rollenzuweisung prüfen.
Warnung
Die Aufhebung der Registrierung eines Offline-Agents wird unterstützt, wobei die Azure ARC-Ressource des Agents jedoch nicht automatisch gelöscht wird. Stattdessen müssen Sie die Ressource manuell löschen, nachdem Sie die Registrierung eines Offline-Agents aufgehoben haben. Der Lebenszyklus der verwalteten Identität des Agents ist an den Lebenszyklus dieser Ressource gebunden. Wird sie entfernt, werden, wie zuvor beschrieben, auch die Verwaltete Identität und der Dienstprinzipal entfernt.
Sie können nachvollziehen, dass die Registrierung vollkommen aufgehoben wurde, sobald der Agent aus dem Azure-Portal und entweder Azure PowerShell oder Azure CLI verschwindet. Sie müssen zudem sicher stellen, dass die Hybrid-Compute-Ressource vom Typ Server – Azure Arc aus der Ressourcengruppe entfernt wurde.
Sie können auch die Verwaltungsshell des Agent verwenden, um zu überprüfen, ob die Registrierung des Agents aufgehoben wurde. Um die Aufhebung der Registrierung zu überprüfen, navigieren Sie zu einem beliebigen Untermenü und kehren Sie dann zum obersten Menü zurück. Wenn die Registrierung erfolgreich aufgehoben wurde, ändert sich die Menüoption Registrierung aufheben zu Registrieren. Wie zuvor erwähnt wird eine erneute Registrierung nicht unterstützt.
Sie können die Agent-VM auf Ihrem Virtualisierungshost beenden, nachdem die Registrierung aufgehoben wurde. Sie sollten das Agent-VM-Image löschen, da es bereits registriert wurde, einige Status beibehält und nicht erneut verwendet werden darf. Wenn Sie einen neuen Agent benötigen, stellen Sie eine neue VM mit einem neuen Agent-Image bereit, das noch nie registriert wurde.
Nächste Schritte
Nachdem Sie Ihren Agent bereitgestellt, gestartet und das Standardkennwort des lokalen Kontos geändert haben:
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für