Azure Blob Storage Zugriffsschlüssel

Der Azure Blob Storage ist ideal um größere Daten in der Cloud zu speichern. Mit dem Azure SDK von Microsoft ist es auch relativ einfach auf den Blob Storage zuzugreifen. Tutorials gibt’s dazu wie Sand am Meer. Für den Zugriff auf den BlobStorage benötigt man einen Connection String mit einem Zugriffsschlüssel. Im Azure Backend gibt es zwei dieser Zugriffsschlüssel für den Blob Storage. Für was zwei Zugriffsschlüssel? Folgendes Szenario lässt sich damit abbilden:

• Anwendung A Version 1 nutzt den primären Zugriffsschlüssel
• Anwendung A Version 2 nutzt den sekundären Zugriffsschlüssel
• Man generiert nun einen neuen primären Zugriffsschlüssel, damit wird die Version 1 unbrauchbar, doch die Version 2 läuft weiter
• Anwendung A Version 3 nutzt den neuen primären Zugriffsschlüssel
• …

Man hat praktisch immer zwei Zugriffe auf den Blob Storage und kann sozusagen ’sanft‘ wechseln.

Ähnlich wie bei Datenbankzugriffen bringen die Connection Strings auch ein Problem mit. Wenn ich den Connection String in meiner .NET Anwendung definiere, um auf den Blob Storage zuzugreifen, dann kann man diesen mit relativ einfachen Mitteln wieder auslesen. (Man kann den Connection String natürlich auch verschlüsselt speichern). Jeder der den Zugriffsschlüssel auf den Blob Storage hat, kann damit ‚alles‘ machen. Blobs anlegen, lesen und auch löschen.

Große Dateien übertragen

Hat man einen Azure Webservice, der für einen den Zugriff auf den Blob Storage kapselt, so muss man den Zugriffsschlüssel nicht an die Kunden ausrollen. Jedoch sollte man beachten, dass größere Dateien einige Zeit brauche und über das Internet übertragen zu werden. Daher muss beim Zugriff auf den Webservice der Timeout entsprechend hoch sein.

Testes man den Webservice auf dem lokalen PC kann es jedoch vorkommen, dass man dennoch einen Timeout bekommt. Ich war bei Tests ein wenig verwundert, da eine Datei mit 6 MB relativ schnell hochgeladen wurde, doch eine Datei mit 10 MB nach einigen Minuten einen Timeout bekam. Beim dritten Versuch habe ich mir mal den Netzwerktraffic auf meinem PC etwas genauer angesehen.

Bei genauer Betrachtung des Screeshots sieht es aus, als ob Daten über eine bestimmte Dauer hinweg übertragen wurden und diese Übertragung dann plötzlich abgebrochen ist. Sofort im Anschluss startet die Übertragung nochmal, bricht jedoch wieder ab. Es folgt eine kurze Pause, bevor die Übertragung wieder startet. Auch diese bricht ab und eine weitere, etwa doppelt so lange, Pause folgt. Erst nach dem vierten Versuch wird am Client eine Exception mit einem Timeout geworfen.

Dieser Algorithmus wird oft verwendet. Unter Linux konnte ich so etwas schon mal beobachten beim versenden von Mails. Sollte die Mail beim ersten Versuch nicht zugestellt werden können, wird es ein zweites Mal nach einer Sekunde Pause versucht. Schlägt der Versuch auch fehl folgt eine zwei Sekunden Pause; dann vier Sekunden; dann acht Sekunden, …
So ist es hier auch. Es wird sofort versucht die Datei nochmal zu übertragen. Nachdem der Versuch ebenfalls fehl schlägt, wird beim zweiten mal kurz gewartet, bevor der nächste Versuch unternommen wird. Erst nach vier Versuchen bekommt der Client den Fehler geliefert. (Daher auch die lange Zeitspanne zwischen dem Start des Uploads und der Fehlermeldung)

Stellte sich nur noch die Frage woher kommt der Timeout. Naja. Da ich den Webservice lokal gestartet habe, war der Webservice Aufruf mit der 10 MB Datei kein Problem, denn die Datei musste ja nicht über’s Internet übertragen werden. Doch um in den Blob Storage zu kommen muss sie noch hochgeladen werden. Und bei der Übertragung in den Blob Storage wurde der Timout ausgelöst. Der CloudBlobClient hat nämlich auch eine Timeout Property, die standardmäßig bei 90 Sekunden liegt – was leider ein paar Sekunden zu wenig war für meinen Upload.

Läuft der Webservice in der Azure Umgebung ist dieser Timeout eher wieder weniger relevant, da die Datei ja schon ‚im Azure ist‘ und nur noch in im Blob Storage gespeichert werden muss – und dafür sollten 90 Sekunden ja wohl ausreichen (bei so kleinen Dateien).li