Optimieren des Netzwerkuploads

Abgeschlossen

Jumbo Frames sind Ethernetframes, die die Standardgröße von 1.500 Byte überschreiten. Typische Jumbo Frames haben eine Größe von 9.000 Byte. Eine Erhöhung der Framegröße auf dem Quell-DB-Server, allen zwischengeschalteten Netzwerkgeräten wie z. B. Switches und den Intel R3load-Servern verringert den CPU-Verbrauch und erhöht den Netzwerkdurchsatz. Die Framegröße muss auf allen Geräten identisch sein, andernfalls erfolgt eine ressourcenintensive Konvertierung.

Zusätzliche Netzwerkfeatures wie die empfangsseitige Skalierung (Receive Side Scaling, RSS) können aktiviert oder konfiguriert werden, um die Netzwerkverarbeitung auf mehrere Prozessoren zu verteilen. Der Betrieb von R3load-Servern in VMware führt erfahrungsgemäß zu einer komplexeren Netzwerkoptimierung für Jumbo Frames und RSS. Diese Vorgehensweise wird daher nicht empfohlen, es sei denn, Sie sind sehr erfahren in diesem Bereich.

R3load exportiert Daten aus DBMS-Tabellen und komprimiert diese formatunabhängigen Rohdaten in Dumpdateien. Diese Dumpdateien müssen in Azure hochgeladen und in die SQL Server-Zieldatenbank importiert werden.

Die Leistung beim Kopieren und Hochladen dieser Dumpdateien nach Azure ist ein entscheidender Faktor im gesamten Migrationsprozess.

Es gibt zwei grundlegende Ansätze für das Hochladen von R3load-Dumpdateien:

Kopieren von lokalen R3load-Exportservern in Azure Blob Storage über das öffentliche Internet mit AzCopy

Führen Sie auf jedem R3load-Server eine Kopie von AzCopy mit der folgenden Befehlszeile aus:

Azcopy copy "C:\ExportServer_1\Dumpfiles" "https://[storage_account].blob.core.windows.net/ExportServer_1/Dumpfiles?[SAS_Token]" --recursive

Diagramm: Kopieren von lokalen R3load-Exportservern über das öffentliche Internet nach Azure Blob Storage mit A z Copy

Sie können den Durchsatz erhöhen, indem Sie die Umgebungsvariable AZCOPY_CONCURRENCY_VALUE festlegen. Diese Variable gibt die zulässige Anzahl gleichzeitiger Anforderungen an.

Wenn Ihr Computer über weniger als 5 CPUs verfügt, wird der Wert dieser Variablen auf 32 festgelegt. Andernfalls ist der Standardwert gleich 16, multipliziert mit der Anzahl der CPUs. Der maximale Standardwert dieser Variablen beträgt 300. Sie können diesen Wert jedoch manuell höher oder niedriger festlegen:

Betriebssystem Get-Help
Windows set AZCOPY_CONCURRENCY_VALUE=[value]
Linux export AZCOPY_CONCURRENCY_VALUE=[value]
macOS export AZCOPY_CONCURRENCY_VALUE=[value]

Verwenden Sie „azcopy env“, um den aktuellen Wert der Umgebungsvariablen AZCOPY_CONCURRENCY_VALUE zu überprüfen. Wenn der Wert leer ist, können Sie den verwendeten Wert ermitteln, indem Sie sich den Anfang einer AzCopy-Protokolldatei ansehen. Dort sind der ausgewählte Wert und der Grund aufgeführt, warum er ausgewählt wurde.

Bevor Sie den Parallelitätswert festlegen, führen Sie einen Benchmarktest aus. Im Benchmarktest wird der empfohlene Parallelitätswert angegeben. Wenn ihre Netzwerkbedingungen und Nutzdaten variieren, legen Sie diese Variable alternativ auf AUTO statt auf eine bestimmte Zahl fest. Der AUTO-Wert bewirkt, dass AzCopy immer denselben automatischen Optimierungsvorgang ausführt, der in Benchmarktests verwendet wird.

Wenn ein Kunde über einen leistungsfähigen Server und eine schnelle Internetverbindung verfügt, kann dieser Wert erhöht werden. Wird der Parallelitätswert zu hoch angesetzt, wird die Verbindung mit dem R3load-Exportserver aufgrund einer Netzwerkauslastung getrennt. Überwachen Sie den Netzwerkdurchsatz im Windows Task-Manager. Ein Kopierdurchsatz von über 1 Gigabit pro Sekunde und R3load-Exportserver kann problemlos erreicht werden. Der Kopierdurchsatz kann durch den Einsatz weiterer R3load-Server erhöht werden (im obigen Diagramm sind es vier).

Ein ähnliches Skript muss auf den R3load-Importservern in Azure ausgeführt werden, um die Dateien vom Blob in ein Dateisystem zu kopieren, auf das R3load zugreifen kann.

Kopieren von lokalen R3load-Exportservern auf eine Azure-VM oder einen Blobspeicher über eine dedizierte ExpressRoute-Verbindung mit AzCopy, Robocopy oder einem ähnlichen Tool

Robocopy C:\Export1\Dump1 \\az_imp1\Dump1 /MIR /XF *.SGN /R:20 /V /S /Z /J /MT:8 /MON:1 /TEE /UNILOG+:C:\Export1\Robo1.Log

Das folgende Blockdiagramm zeigt vier Intel R3load-Server, auf denen R3load ausgeführt wird. Im Hintergrund wird Robocopy zum Hochladen der Dumpdateien gestartet. Wenn alle aufgeteilten Tabellen und Pakete abgearbeitet sind, wird die SGN-Datei entweder manuell oder über ein Skript kopiert. Wenn die SGN-Datei für ein Paket auf dem R3load-Importserver eintrifft, wird der Import für dieses Paket automatisch ausgelöst.

Blockdiagramm: Vier Intel R3load-Server, auf denen R3load ausgeführt wird

Hinweis

Das Kopieren von Dateien über NFS- oder Windows SMB-Protokolle ist gegenüber Mechanismen wie AzCopy weniger schnell und stabil. Es wird empfohlen, die Leistung beider Verfahren für den Dateiupload zu testen. Darüber hinaus wird empfohlen, den Microsoft-Support über VLDB-Migrationsprojekte zu informieren, da Netzwerkvorgänge mit sehr hohem Durchsatz fälschlicherweise als Denial-of-Service-Angriffe identifiziert werden könnten.