Daten kopieren von lokal und zwischen den Clouds

(this article is also available in english)

Oft steht man vor dem Problem, Daten zwischen unterschiedlichen Storage-Plätzen kopieren zu müssen, zum Beispiel von lokal in die Cloud oder - mit Blick auf Azure Deutschland - zwischen verschiedenen Cloud Subscriptions. Hier soll einmal ein Kommandozeilentool vorgestellt werden, nämlich AzCopy.

AzCopy ist ein freies Tool, das über die Kommandozeile ein Kopieren von Daten in alle möglichen Richtungen erlaubt. Der Aufruf ist zwar etwas länglich, dafür funktioniert es aber klaglos auch mit neueren Umgebungen. Wer zum Beispiel das Azure SDK für Visual Studio installiert hat, der hat AzCopy auch schon verfügbar, meist unter %ProgramFiles(x86)%\Microsoft SDKs\Azure\AzCopy oder %ProgramFiles%\Microsoft SDKs\Azure\AzCopy. Oder man kann es natürlich auch direkt herunterladen.

AzCopy arbeitet mit URLs und StorageKeys, ein Login an Azure ist nicht notwendig. Was natürlich nicht ganz richtig ist. Das Login ist nicht nötig für das eigentliche Kopieren, wohl aber vorher, um die Informationen zusammen zu bekommen. Da stellt sich natürlich gleich die Frage: Wie komme ich an die URL oder an den Key?

URL und StorageKey

Informationen via Portal

Hier ist das recht einfach: Im neuen Portal anmelden, auf den Menüpunkt "Speicherkonten" und das gewünschte heraussuchen. In der Übersicht wird der Dienst "Blobs" angezeigt, draufklicken liefert die Liste der Container, und beim gewünschten Container steht auch die URL dabei, die wir brauchen. Wir können die auch fast erraten, sie setzt sich zusammen aus dem Namen des Speicherkontos, dem sog. Blob Storage Endpunkt, und dem Containernamen. In Azure Deutschland beispielsweise findet man den Container "test" im Speicherkonto "store1" also unter der URL: https://store1.blob.core.cloudapi.de/test.

Etwas weiter unten in der Menüleiste findet man im Bereich "Einstellungen" den Punkt "Zugriffsschlüssel". Ob man den primären oder sekundären nimmt, ist egal. Einfach rauskopieren (bei (1) klicken), damit haben wir erst mal alle Infos, die wir brauchen.

Informationen via PowerShell

Auch in PowerShell ist die Information einfach erreichbar. Nach dem Einloggen liefert

[code light="true"]
Get-AzureStorageAccount

eine Liste aller Speicherkonten, und mit der Eigenschaft "StorageAccountName" kommen wir an den Schlüssel:

[code light="true"]
Get-AzureStorageKey -StorageAccountName store1

Auch hier den primären oder sekundären kopieren. Die URL zu finden ist etwas komplizierter, entweder einfach selber zusammenbauen, oder den folgenden Skript (abspeichern und) ausführen, der zeigt alles praktisch an, indem man den Namen des Speicherkontos als Parameter übergibt, oder erst mal alle Speicherkonten, wenn man nichts angibt.

[code]
param(
[parameter(position=0,mandatory=$false)][string] $storagename
)

if (-not $storagename){
Get-AzureStorageAccount |select StorageAccountName,label, location
} else {
$key=(Get-AzureStorageKey -StorageAccountName $storagename |select -ExpandProperty Primary)
$context = New-AzureStorageContext -StorageAccountName $storagename -StorageAccountKey $key

Write-Host "Key: " $key

(Get-AzureStorageContainer -Context $context).CloudBlobContainer|select Name,Uri|fl
}

Jetzt wissen wir also, wie wir an die Infos kommen, um ein paar Tests mit AzCopy zu machen...

Upload nach Azure

AzCopy benötigt immer eine Quelle, ein Ziel und ein Pattern, also ein Muster, was kopiert werden soll. Im einfachsten Fall ist das ein Dateiname, es kann aber auch mit Wildcards gearbeitet werden. Im ersten Beispiel wollen wir die Datei c:\temp\test.txt nach Azure hochspielen in das Speicherkonto "store1" und dort in den Container "test". Mithilfe des Portals oder unseres Scripts finden wir die URL und den Key für das Speicherkonto und starten:

[code light="true"]
AzCopy.exe /source:c:\temp /dest:https://store1.blob.core.cloudapi.de/test /destkey:Dy8(...)oA== /pattern:test.txt

Den Key hab ich etwas verkürzt... AzCopy sollte uns jetzt anzeigen, dass es 1 Datei erfolgreich kopiert hat. So, und irgendjemand hat bestimmt bei /source nicht nur den Pfad, sondern auch die Datei mit angegeben, stimmt's? Das ist eine Umstellung, aber man gewöhnt sich dran. Bei source und dest steht immer nur das Verzeichnis, die Dateien stehe bei pattern. Daraus folgt aber auch, dass die kopierten Dateien im Ziel immer so heißen wie in der Quelle.

Gleich der umgekehrte Weg...

Download von Azure

Wir vertauschen einfach Quelle und Ziel und erhalten:

[code light="true"]
AzCopy.exe /dest:c:\temp /source:https://store1.blob.core.cloudapi.de/test /sourcekey:Dy(...)oA== /pattern:test.txt

Easy going... Und jetzt aber von Cloud zu Cloud...

Copy von Cloud zu Cloud

Hier gehen wir genauso vor, wir brauchen halt zwei Storageaccounts und zwei Keys. Die Accounts können innerhalb der gleichen Subscription, der gleichen Cloud oder in ganz unterschiedlichen Umgebungen liegen. Wir kopieren mal eine Datei aus Azure Deutschland nach Azure global, die Syntax ist dabei die gleiche wie besprochen:

[code light="true"]
AzCopy.exe /source:https://store1.blob.core.cloudapi.de/test /sourcekey:Dy(...)oA== /dest:https://store2.blob.core.windows.net/testglobal /destkey:M8(...)aM== /pattern:test.txt

Man sieht sehr schön, dass die Speicher-Endpunkte in Azure Deutschland (blob.core.cloudapi.de) verschieden sind von den Speicher-Endpunkten in Azure global (blob.core.windows.net). Je nach Größe der Datei kann das etwas dauern, in diesem speziellen Fall (ein Kopieren zwischen Azure Deutschland und Azure global) kommt noch hinzu, dass die Clouds nicht durch einen eigenen Backbone miteinander verbunden sind. Durch die Spezialität der Microsoft Cloud Deutschland, nämlich die Daten-Souveränität und die dadurch notwendige Abtrennung vom sonstigen Azure-Backbone, werden die Daten über das normale Internet übertragen (SSL-verschlüsselt, siehe URLs), und hierbei kann es schon mal zu schwankenden Bandbreiten kommen.

Ein häufiger Fehler passiert übrigens, wenn man virtuelle Server im laufenden Betrieb kopieren möchte. Die zugehörige .vhd-Datei ist dabei nämlich gesperrt und AzCopy meldet einen Fehler (leider ganz ohne Hinweis auf die Ursache). VM herunterfahren hilft...

Ausblick und Links

AzCopy hat noch viele weitere Funktionen, zum Beispiel unterstützt es nicht nur Blobs, sondern auch File und Table Speicher. Eine ausführlichere Dokumentation mit weiteren Beispielen ist natürlich verfügbar.