Azure File Sync

Azure File Sync

 

Bisher waren viele Hybrid-Cloud-Szenarien ein Abwägen von Nachteilen und die optimalste Lösung bestenfalls akzeptabel. Mit Azure File Sync stellt Microsoft nun einen Meilenstein vor, der File Services den Weg in die Welt der Hybrid Cloud bereitet. Lesezeit: Minuten 12.


 

Unter File Sync spielt Cloud-Speicher in hybriden Architekturen nicht die Rolle einer weiteren Storage-Komponente. File Sync erlaubt es Cloud-Ressourcen nahtlos in die bestehende Infrastruktur zu integrieren. Ohne den Geschäftsbetrieb zu unterbrechen, ohne hohe Anschaffungskosten in Kauf zu nehmen und ohne den Nutzer einem völlig neuen Ökosystem auszusetzen.

Wir hatten die Möglichkeit uns im Rahmen eines Proof of Concept mit File Sync zu beschäftigen und gemeinsam mit unserem Kunden zu testen. Selbstverständlich sind wir dabei um einige Erfahrungen reicher geworden, die wir hier gerne teilen möchten.

Da wir in den ersten Absätzen zunächst eine Situationsbeschreibung machen, um zu schauen, wo die IT gerade mit File Services steht, sind diese für einige Leser weniger interessant. Wer nach Informationen giert, ist daher dazu eingeladen ab dem Absatz “Here comes Azure File Sync!” einzusteigen. Dort finden Sie die Hard Facts.

 

Woran hybride Lösungen scheitern

Die Entwicklung des File Service

Eine der wohl klassischsten Aufgaben des heimischen Rechenzentrum ist der des File Services. Historisch gesehen, bedeutet das die Bereitstellung einer Infrastruktur, um Daten strukturiert zu speichern. Diese Definition umfasst aber nur das “bare minimum” dessen, was File Services heutzutage leisten und leisten müssen.

Die Anforderungen wurden im Laufe der Zeit stetig erweitert. So verlangt der Unternehmensalltag vor allem großer Konzerne, dass den Mitarbeitern sehr unterschiedliche und granulare Berechtigungen im digitalen Datenarchiv gegeben werden können. Das ist übrigens der Punkt, an dem OneDrive und SharePoint als valide business-fähige Optionen aussteigen. Denn dort können komplexe Berechtigungsstrukturen nicht abgebildet oder importiert werden.

Ein File Service muss es den Nutzern außerdem ermöglichen Daten auszutauschen und gemeinsam zu verarbeiten. Und eine Komponente die immer wichtiger wird, ist der Schutz der Files vor Desastern.

Ein Problem zeichnet sich ab

So weit so gut. Doch es ergeben sich zunehmend Probleme bei der Datenpflege in den eigenen vier Wänden. So haben bereits kleine Unternehmen einen riesigen Speicherbedarf. Insbesondere dann, wenn ungenutzte Files nicht einfach gelöscht werden können, sondern aus rechtlichen Gründen für mehrere Jahre archiviert werden müssen. Aber nicht nur ist der Bedarf groß, sondern der Zufluss unermesslich. Das führt dazu, dass IT-Verantwortliche krude Schätzungen über das zukünftigen Datenvolumen abgeben müssen, was in Wachstumsbranchen schamanischen Zauberkünste erfordert. Überprovision oder Mangelerscheinungen sind vorprogrammiert.

Wer seine Daten in heimischen Gefilden unterbringt, holt sich auch die Wartung der Hardware ins Haus. Dass heißt entweder muss geschultes Fachpersonal angestellt oder externe Hilfe ersucht werden. Beide Alternativen gibt es nicht umsonst und sie beanspruchen Ressourcen, die anderweitig sinnvoller eingesetzt werden. Beispielsweise, wenn sie dem eigentlichen Geschäftszweck zugeführt werden.

Niemand löscht Daten

Wer die Daten seiner Mitarbeiter in SharePoint oder OneDrive verlagern möchte wird überrascht sein, dass die Daten insgesamt sprunghaft wachsen. Kein User löscht seine Files, sie werden kopiert. Und das ist eine sehr natürliche Reaktion. Und auch nicht dumm. Denn schaut man sich die SLAs von OneDrive oder SharePoint online an, so kann man lesen, dass die Daten, die man gelöscht hat automatisch nach 90 Tagen endgültig gelöscht werden. Durch die natürliche Vorsicht der Nutzer kann das Unternehmen das große Ziel von Hardware-Einsparungen nicht einfach erreichen. Im Gegenteil. Das Unternehmen zahlt doppelt.

Wie muss eine gute Lösung aussehen?

Die Hybrid Cloud verbindet die Vorzüge einer On-premises-Infrastruktur mit den Vorteilen der Cloud. Vertrauliche und stark frequentierte Daten werden vor Ort behalten. Unbenutzte oder archivierte Files oder solche die einem breiteren Publikum, zum Beispiel Mitarbeitern in anderen Offices, bereitgestellt werden sollen, werden hingegen in die Cloud migriert.

Das angesprochene Szenario wird IT-Verantwortliche in Verzückung versetzten. Doch wer sich mit der technischen Umsetzung beschäftigt, wird oft mit unüberwindbaren Hürden konfrontiert. Wird ein bestehendes Rechenzentrum um Cloud-Speicher erweitert, sollen die vorhandenen Berechtigungsstrukturen in die hybride Lösung übernommen werden. Leichter gesagt als getan.

Etwas, das ebenfalls vielen Hybrid-Lösungen Kopfzerbrechen beschert, ist die Anbindung der Cloud-Infrastruktur. Oftmals ist es wünschenswert, den Cloud-Speicher harmonisch in das bestehende System einzuarbeiten, als Speichererweiterung. Doch in der Realität kommt es dazu, dass in der Cloud angelegte Daten zunächst wieder ins heimische Rechenzentrum zurückgeholt und aufbereitet werden müssen, um sie nutzbar zu machen (siehe StorSimple).

Des Weiteren muss eine gute Transition unterbrechungsfrei ablaufen. Der Nutzer soll die gleiche grafische Oberfläche mit dem gleichen “Look and Feel” haben wie zuvor. Das erspart Schulungsmaßnahmen und damit Zeit und Geld.

 

Here comes Azure File Sync!

Die grundlegende Idee von Azure File Sync ist es mehreren Servern (in der File-Sync-Nomenklatur Server-Endpoint genannt) zu ermöglichen sich mit File Shares (in der File-Sync-Nomenklatur Cloud-Endpoints genannt) zu synchronisieren. Die Gesamtheit von Server- und Cloud-Endpoints heißt Sync Group.

Doch wie wird die Synchronisation nun im Detail umgesetzt? Welche Datensätze werden lokal vorbehalten, welche in den File Share migriert? Welche Administrations- und Automatisierungsoptionen gibt es? Werden die NTFS-Berechtigungen, die auf den lokalen Servern definiert sind, beibehalten?

Das sind die Fragen, die uns in den Sinn gekommen sind, als wir erstmals von File Sync gehört haben. Die passenden Antworten zu finden, war nicht immer leicht, aber mit der Zeit hat der neue Service von Azure sich zu einem Bild zusammengefügt. In den folgenden Absätzen möchten wir Ihnen dieses Bild gerne vermitteln.

Zuvor aber noch ein kurzer Einschub zur Installation: File Sync wird in Form eines Agent auf Windows Servern platziert. Der Agent übernimmt die Verbindung und Authentifizierung des Servers mit Azure. Der File Sync Agent läuft unter Windows 2012 R2 und 2016. Zukünftig sollen auch Linux Server mit der neuen Software bestückt werden können.

Die namensgebende Komponente: Synchronisation

Grundsätzlich kann die Synchronisation zwischen mehreren Server-Endpoints (in der Public Preview auf 50 beschränkt, ab General Availability im Frühjahr 2018 wird dieses Limit angehoben) und mehreren Cloud-Endpoints (momentan lediglich einer, wird in Zukunft ebenfalls angehoben) stattfinden. Exemplarisch werden wir uns zunächst auf einen Server-Endpoint und einen Cloud-Endpoint beschränken, um uns mit diesem Wissen ausgerüstet an komplexere Multi-Sync-Szenarien heranzuwagen.

Möchte ein Anwender einen lokalen Windows File Server mit einem File Share synchronisieren, so muss der Anwender zu Beginn diejenigen Volumes und Folder auswählen, die Teil der File-Sync-Topologie werden sollen. Diese werden nun in den File Share repliziert. Sensible Daten, die Sie nicht in der Cloud haben möchten, können so aus der Architektur ausgeschlossen werden.
Im nächsten Schritt kann der minimale Speicherplatz definiert werden, der mindestens auf den lokalen Speichermedien freigehalten werden soll. Wird diese Grenze unterschritten, beginnt File Sync die ältesten Daten auszusortieren. Diese werden dann nur noch im File Share aufbewahrt. Kurzum: Im File Share befinden sich sämtliche für die Synchronisation ausgewählte Datensätze; lokal nur die Menge an aktuellsten Files, die innerhalb der gegebenen Grenze sind. Dieses Prinzip “heiße” Files lokal zu cachen und “kalte” Files in die Cloud zu verfrachten, bezeichnet Microsoft als Cloud Tiering.

Das gerade beschriebene Szenario ist allerdings nur ein Vorgeschmack. In Zukunft werden weitere Tiering Features zum Skillset hinzugefügt. User werden die Möglichkeit haben Ordner zu pinnen. Solche gepinnten Ordner werden dauerhaft lokal gespeichert sein. Dies kann genutzt werden, um Anwendungen gerecht zu werden, die keine hohen Latenzen tolerieren können.
Schließlich soll es möglich sein Kriterien anzugeben (beispielsweise Ordnerzugehörigkeit, Dateityp und weitere), nach denen Daten bereits früher, nämlich nach Ablauf einer benutzerdefinierten Zeitspanne, aussortiert werden. Log-Dateien, die selten eingesehen werden, aber dennoch geführt werden müssen, können so sofort den lokalen Speicherplatz verlassen.

Nehmen wir nun weitere Server-Endpoints in unser Modell auf. Während der ursprüngliche Server im primären Rechenzentrum in Köln steht, möchten Sie Datenaustausch mit einer US-amerikanischen Außenstelle ermöglichen. Also fügen Sie einen Server in Seattle als Server-Endpoint der Sync Group hinzu. Bearbeiten Ihre Kollegen in Seattle Daten, wird diese Veränderung an den File Share weitergegeben und letztlich auch in Köln realisiert. So kann ein ganzes Synchronisationsnetzwerk aufgebaut werden, in dem alle Daten (mit kurzen, latenzbedingen Verzögerungen) auf dem gleichen Stand sind.

Da multiple Cloud-Endpoints Disaster-Recovery-Capabilities mit sich bringen, diskutieren wir dieses Szenario unter dem Punkt Disaster Recovery built-in.

Zwei File Sync Agenten mit gleichem File Share sychronisiert

 

Rund um den Zugriff

NTFS-Berechtigungen

Wer sich genauer mit Azure auskennt, weiß, dass File Storage grundsätzlich nicht mit NTFS-Berechtigungen umgehen kann. Zugang wird stattdessen über Shared Access Signatures (SAS) verliehen. Das sind URIs, die sich aus der URI der Storage Ressource und einem SAS Token zusammensetzten. Letzteres regelt, welche Berechtigungen der Nutzer bekommt und führt die Authentifizierung aus.

Dieses Schema ist für die komplexen Berechtigungsstrukturen moderner Unternehmen natürlich nicht praktikabel. Zusätzlich ist es für große Firmen, zum Beispiel unseren Kunden, der mehrere tausend Mitarbeiter hat, schlicht und ergreifend nicht möglich von heute auf morgen ein neues Berechtigungssystem einzuführen. Ein erheblicher Mangel, der Cloud-Projekten im Weg stehen kann. Hier hat mit File Sync ein Umdenken stattgefunden. File Sync übernimmt bei der Migration die bestehenden NTFS-Berechtigungsstrukturen in den File Share. Greifen User über den Agent auf Files im Share zu, sind sie also den gleichen Berechtigungen unterworfen, die auch lokal gelten. Somit bestehen perfekte Voraussetzungen Cloud-Komponenten in eine bestehende IT-Infrastruktur zu integrieren.

Hier sei nochmal hervorgehoben, dass der Zugriff über File Sync geschehen muss. Für direkten “Cloud-Zugriff” braucht es weiterhin SAS oder Azure-Adminrechte. Da natürlich viele Unternehmen ihren Mitarbeitern gerne direkten Zugriff auf File Shares geben würden, ohne den File Sync Workaround zu gehen, entwickelt Microsoft in dieser Richtung. Cloud-native-Access soll Mitte des nächsten Jahres (2018) möglich sein

Partial Up- and Download

Doch wie greife ich auf Daten zu, die gar nicht mehr auf meinem lokalen Server abgespeichert sind, sondern nur in der Cloud existieren? Simpler geht es kaum: Diese Files werden weiterhin (leicht ausgegraut) im lokalen Namespace angezeigt.

Benutze ich Daten, die lokal nicht mehr vorhanden sind, werden lediglich die Elemente heruntergeladen, die für die Verarbeitung notwendig sind. Schaue ich mir beispielsweise ein Video an, werden nur die Minuten gestreamt, die ich tatsächlich schaue.

Analoges gilt für den Daten-Upload: Arbeite ich an einem Excel-File, ändere aber lediglich einen Eintrag, so vermittelt File Sync auch lediglich die Änderung dieses Eintrages an den synchronisierten File Share und alle weiteren angebundenen File Server.

Conflict Resolution

Reden wir über File Sync, so reden wir über Collaboration. Während Sie im Kölner Hauptsitz ein Excel-Dokument bearbeiten (um nochmal auf das vorangegangene Beispiel zurückzukommen), kann zeitgleich auch ein Mitarbeiter in Seattle darauf zugreifen. Es kommt unweigerlich zu Konflikten.

Der momentan verwendete Conflict-Resolution-Mechanismus ist aus OneNote bekannt. Wird ein File von mehreren Usern gleichzeitig editiert, wird ein “Winner file” ausgewählt, der fortan die neueste Version darstellt. Das kollidierende Dokument wird mit einem Appendix versehen am gleichen Speicherort untergebracht. Nun muss manuell entschieden werden, was mit den existierenden Versionen geschieht.

Bei dieser Lösung wird es allerdings nicht bleiben. Ein Team befasst sich gerade damit File Locking zu implementieren. Ist ein File in Benutzung, so muss eine zweite Partei warten bis die Datei wieder freigegeben wird. Wie das im Detail aussehen wird, ist noch nicht bekannt.

Keine Abstriche bei der Sicherheit

Disaster Recovery built-in

Für einen der größten “Ah”-Effekte haben bei uns die nativen Disaster-Recovery-Fähigkeiten durch File Sync gesorgt. Eine File-Sync-Architektur bietet sowohl rechenzentrumsseitige- als auch Azure-seitige Disaster-Recovery-Optionen. Gehen wir beide Möglichkeiten durch:
Fällt der lokale Server aus, kann der Agent auf einem funktionstüchtigen Server installiert. Dieser Ersatz-Server versorgt sich zunächst mit Metadaten, um den Betrieb als File Service schnellstmöglich wieder aufnehmen zu können. Daten werden dann bereits wieder im Namespace angezeigt und angefragte Files werden sofort gestreamt. Danach werden sukzessive die übrigen offline vorbehaltenen Files heruntergeladen.

Was aber, wenn Ihr gesamtes Rechenzentrum nicht zur Verfügung steht? Nutzen Sie die Cloud! Zum jetzigen Zeitpunkt bedeutet das eine Azure VM zu starten. Dann können Sie entweder über SMB den File Share als Netzlaufwerk zuordnen oder den File Sync Agenten auf der VM platzieren. Et voilà!

Aber diesen Workaround möchten die Entwickler langfristig eliminieren. Dann können Nutzer in der Cloud direkt auf File Shares zugreifen: nicht über SASs, sondern die üblichen NTFS-Berechtigungen. Hier eröffnet sich ein Cloud-native-Szenario: Besitzt Ihr Unternehmen Außenstellen, die ohne lokalen Server auskommen sollen oder müssen, werden Ihre Mitarbeiter in der Lage sein ohne den Umweg eines lokalen Servers einen File Share (mitsamt NTFS-Berechtigungen) zu benutzen.

Zuvor hatten wir kurz angeschnitten, dass in Zukunft auch Cloud-to-Cloud-Sync, sprich mehrere Cloud-Endpoints, realisiert werden können. Das birgt gleich mehrere Vorteile. Um diese etwas bildlicher vor Augen zu führen, kehren wir zu Ihrer Kölner Hauptsitz und der amerikanischen Außenstelle zurück.

Betreiben Sie den File Share in Germany Central, werden die amerikanischen Kollegen sich (vielleicht) über die “lange Leitung” beschweren. Also erstellen Sie einfach einen weiteren File Share in US West, der sich mit dem bestehenden Cloud-Endpoint in Germany Central synchronisiert. Diese Synchronisations-Relation weitet sich auf Ihr Rechenzentrum in Köln aus. Sie haben nun eine konsistente Sync Group, die zwei Server-Endpoints (Köln, Seattle) und zwei Cloud-Endpoints (Germany Central, US West) umfasst.

Angenommen, es kommt zu einem Brand im europäischen Rechenzentrum. Der File Share kann nicht länger angefunkt werden – die darunterliegende Physik ist verschmort. Der File Sync Agent auf dem Kölner File Server erkennt das Konnektivitätsproblem und verbindet sich stattdessen mit dem nächstgelegen Cloud-Endpoint, der die relevanten Daten enthält. In unserem Beispiel ist das – fehlenden Alternativen geschuldet – US West. Gäbe es jedoch einen weiteren Cloud-Endpoint in, sagen wir, US South, so würde der Kölner Server diesen aufgrund der geographischen (und damit einhergehenden netzwerkbezogenen) Nähe bevorzugen.

Natürlich ist es in all dem wichtig darauf zu achten, dass die gegebenen Gesetze und Richtlinien eingehalten werden. Es ist unter Umständen nicht ohne Weiteres erlaubt Daten über Ländergrenzen hinweg zu synchronisieren.

Failover (Disaster Recovery) einer Außenstelle

 

Backup

Einer der Kernpunkte unseres Projektes ist es, die lokale Infrastruktur zu reduzieren und Stück für Stück in die Hände eines Cloud Vendors zu geben. Ein großes Einsparungspotential lokaler Physik entsteht durch Verlagerung des Backup-Vorganges in die Cloud.

Mit Azure File Sync entfällt die Notwendigkeit einer lokalen Backup-Lösung. Der Server vor Ort wird nicht mehr in regelmäßigen Intervallen verlangsamt, weil ein Backup erstellt und in einen sekundären Speicherort verfrachtet werden muss. Stattdessen kann mit Azure Backup Vault ein inkrementeller Snapshot des File Shares gemacht werden, der in kilometerweiter Entfernung, gar auf einem anderen Kontinent, eingelagert werden kann. Und das ohne den lokalen Betrieb zu stören.

Dabei können Sie die Frequenz und Retention definieren; einzelne Files oder einen ganzen File Share zu einem beliebigen Point-in-time wiederherstellen.

Encryption

Wenn so viele Daten verschifft werden, ohne dass der Anwender die einzelnen Transfers abnickt, kommen selbstverständlich Fragen nach der Sicherheit auf. Während der Übertragung sind Files mit einer 265 Bit SSL-Verschlüsselung geschützt. Der File Share selbst ist durch Microsoft-verwaltete Keys gesichert. Auch hier genehmigen wir uns einen Ausblick in die Zukunft: Nutzerverwaltete Key werden kommen.

Der Migrationsprozess

Obwohl Azure File Sync wie zuvor beschrieben ohne On-premises-Infrastruktur genutzt werden kann, wird der primäre Use Case ein hybrides Szenario sein. Steckt Ihr Rechenzentrum nicht in den Kinderschuhen, werden Sie daher aller Wahrscheinlichkeit nach nicht ohne Datenmigration auskommen.

Bei den heute üblichen riesigen Datenmengen wird in einigen Fällen nicht einmal eine MPLS Verbindung mit einem Azure Data Center ausreichen, um alle Files zügig in die Cloud zu migrieren. Microsoft stellt dafür einen Import Service bereit. Sie schicken Ihre Datenträger zu einem Azure Data Center, dort werden die Daten in Cloud Storage kopiert.
Eine Liste mit Hardware-Voraussetzungen und weiteren Informationen können Sie hier entnehmen.

Natürlich geht auch diese Migration nicht augenblicklich über die Bühne und einige Daten werden die User zwischenzeitlich verändert haben. Insbesondere weil Microsoft lediglich verspricht die Daten innerhalb von sieben bis zehn Tagen im eigenen Rechenzentrum hochzuladen. Wie wird das resultierende Delta ausgeglichen? Diese Problematik ist eine der größten Hürden, mit der wir in unserem Projekt zu kämpfen haben. Denn die Daten des Windows Server, den wir in eine Sync Group aufnehmen möchten, werden dauerhaft benutzt und verändert.

Microsoft feilt gerade an einer Lösung dieses Problems: Beim initialen Sync des File Share mit dem lokalen Server, soll File Sync erkennen, wo Änderungen aufgetreten sind. Die hochgeladenen, unveränderten Files werden mit einem Tag versehen, dass diese als veraltet kennzeichnet. Die aktuellen Dateien, die zwischenzeitlich lokal von Nutzern verändert wurden, werden zusätzlich in den File Share migriert. Der Anwender kann nun, beispielsweise mit Hilfe eines PowerShell Scripts, bestimmen, was mit den veralteten Datensätzen passiert. Dies wird durch die Tags, die es erlauben simultan alle veralteten Files anzusprechen, enorm vereinfacht.

Im Rahmen unseres PoC hatten wir das Glück in einem ansonsten von NetApp beherrschten Unternehmen in einer Außenstelle einen “legacy” Windows File Server vorzufinden. Denn abgesehen davon, dass der File Sync Agent nur mit Windows Server kompatibel ist (wie bereits erwähnt später auch mit Linux), erschweren die Protokolle einiger Speicherlösungen den Synchronisationsprozess. Beispielsweise gibt ein NAS-Speichergerät dem File Sync Agent keine Benachrichtigung, wenn Files verändert werden. Somit muss der Agent dies regelmäßig und manuell überprüfen, was die allgemeine Performance des Speichermediums schwächt.

Wenn Microsoft mit File Sync ein breites Kundenspektrum ansprechen möchte, werden individuelle Lösungen nötig sein.

Auch interessant

Mehr zum Thema Cloud erfahren? Hier sind einige unserer Lesetipps:

Hier erfahren Sie mehr zu Ihrer Roadmap in die Cloud.

Wer sind die Big Player im Cloudbusiness? Mehr dazu hier.

Irgendwann wird immer über Geld gesprochen. Hilfereiche Tipps rund ums Thema Cloud Budget

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.