Der heutige Beitrag ist ein Interview mit Siddharth Deekshit, Program Manager für Microsoft Azure Site Recovery Engineering, und Quentin Drion, IT Director of Infrastructure and Operations, MSC. MSC ist ein internationales Reederei- und Logistikunternehmen. Daher wollten wir mehr über die Journey von MSC mit Azure Site Recovery (ASR) wissen. Weitere Informationen zu Resilienz in Azure finden Sie in diesem Whitepaper.

Zunächst würde ich gern mehr über die Veränderungen erfahren, die MSC durchläuft, einschließlich der Konsolidierung von Azure. Können Sie uns erzählen, wie Azure Ihnen heute den Geschäftsbetrieb erleichtert?

Wir sind eine Reederei, d. h., wir befördern weltweit Container. Im Laufe der Jahre haben wir eine eigene Software entwickelt, mit der wir unser Kerngeschäft verwalten. Wir haben unterschiedliche Software für kleine, mittlere und große Entitäten, die lokal ausgeführt wird. Deshalb mussten wir immer viele lokale Ressourcen bereitstellen, um all diese Geschäftsanwendungen zu unterstützen. Vor einigen Jahren fiel dann die Entscheidung, alle diese Unternehmensworkloads in Azure zu konsolidieren, unabhängig von der Größe der Entität. Bei der Migration werden zuerst die entsprechenden lokalen Ressourcen deaktiviert, dann wird die in Azure gehostete Software in Betrieb genommen und als Dienst für unsere Niederlassungen bereitgestellt. Diese neue Architektur wird an einem Ort von unserem internen IT-Team verwaltet.

Großartig! Konsolidierung ist ein großer Vorteil von Azure. Welche weiteren Vorteile sehen Sie bei einer Migration zu Azure?

Für uns war vor allem die Automatisierung eine bedeutende Verbesserung. Dank der Möglichkeiten, die uns die Azure-API für die Integration und Automatisierung bietet, können wir Umgebungen in wenigen Stunden bereitstellen. Früher mussten wir zuerst die Hardware bestellen, sie einrichten und dann konfigurieren. Das war viel zeitaufwendiger. Heute müssen wir uns weder um die Einrichtung noch um den Hardwaresupport oder Garantien Gedanken machen. Die Umgebung ist vollständig virtualisiert, und wir können natürlich dieselbe Recovery Point Objective (RPO) und Recovery Time Objective (RTO) sowie dasselbe Maß an Sicherheit für alle unsere weltweiten Entitäten bereitstellen.

Ap­ro­pos RTO und RPO: Lassen Sie uns über Site Recovery sprechen. Wie lief der Geschäftsbetrieb, bevor Sie den Dienst eingeführt haben?

Als wir mit der Migration von Workloads begonnen haben, haben wir primäre Produktionsworkloads in einer Azure-Region ausgeführt und dafür eine komplette Infrastruktur für die Notfallwiederherstellung (Disaster Recovery, DR) in einer anderen Region eingerichtet. Unsere Herangehensweise an die Notfallwiederherstellung in Azure bestand also im Grunde genommen aus dem Ansatz eines herkömmlichen lokalen Rechenzentrums. Dann haben wir uns die Zeit genommen, um die Vorteile von Site Recovery zu prüfen. Aufgrund der Ergebnisse und einiger durchgeführter Tests haben wir beschlossen, die Implementierung zu ändern, die vor zwei oder drei Jahren eingerichtet wurde, und zu Site Recovery zu wechseln. Damit konnten wir letztendlich unsere Kosten erheblich senken, da unsere Azure-VMs für die Notfallwiederherstellung nicht mehr in einer anderen Region ausgeführt werden müssen. Auch die Verwaltung ist einfacher mit Site Recovery. Bei herkömmlichen Workloads haben wir eine bessere RPO und RTO als bei unserem vorherigen Ansatz. Wir haben also in allen Bereichen von dem Dienst profitiert.

Das ist gut zu wissen. Woran hatten Sie in Bezug auf Site Recovery die meisten Zweifel? Sie haben z. B. erwähnt, dass Ihr Team Tests durchgeführt hat. Was hat Sie überzeugt, dass Site Recovery die richtige Wahl ist?

Das waren tatsächlich unsere Tests. Früher mussten wir den Wechsel zur DR-Region manuell durchführen und manuell sicherstellen, dass die Einstellungen des Domain Name System (DNS) und andere Netzwerkeinstellungen angemessen waren. Es gab also viele Einschränkungen. Als wir Site Recovery im Vergleich zu diesen manuellen Verfahren getestet haben, waren wir einfach begeistert. Dass die primäre Region ausfallen konnte und wir trotzdem kaum etwas tun mussten, war unglaublich. Unsere Anwendungen konnten in der DR-Region neu starten, und wir mussten nur die äußerste App-Schicht verwalten, um sicherzustellen, dass der Start ordnungsgemäß verläuft. Beim Neustart der App waren wir vorsichtig – nicht wegen der VMs, denn wir waren sicher, dass Site Recovery funktioniert, sondern wegen unserer Datenbank-Engine. Wir waren positiv überrascht, wie gut Site Recovery funktioniert. Alle unsere Teams waren sehr zufrieden mit der Lösung, denn sie haben verstanden, welche Vorteile eine Umstellung auf diese Art von Technologie für sie als operative Teams hat. Auch wir in der Führungsebene waren überzeugt, weil durch die Reduzierung der ungenutzten VMs Kosten eingespart werden konnten.

Können Sie mir etwas über das Onboarding mit Site Recovery erzählen?

Ich glaube, wir hatten zu der Zeit sechs oder sieben wichtige intern entwickelte Anwendungen in Azure. Eine davon haben wir als Testkandidaten ausgewählt, und der Test war erfolgreich. Anschließend haben wir weitere Produktionsanwendungen auf Site Recovery umgestellt. Auch hier gab es keine größeren Probleme. Die einzigen Schwierigkeiten traten im Zusammenhang mit einigen großen Datenträgern auf. Anfänglich wurden einige davon nicht unterstützt. Das wurde jedoch schnell behoben, und seitdem funktioniert alles wirklich reibungslos. Nach dem Erfolg unserer Tests haben wir alle unsere Anwendungen auf der Plattform zwecks Notfallwiederherstellung auf Site Recovery umgestellt.

Welche Workloads führen Sie heute auf Ihren Azure-VMs aus? Wie viele Personen nutzen die Anwendungen, die auf diesen VMs ausgeführt werden, für Ihre tägliche Arbeit?

Wir nutzen Azure vor allem für wichtige Geschäftsanwendungen. Es gibt natürlich eine zugrunde liegende Hauptinfrastruktur, aber was wir eigentlich bereitstellen, sind intern geschriebene Geschäftsanwendungen in einem Citrix-Front-End in Azure. Diese Anwendungen führen Containerbuchungen, Kundenregistrierungen und vieles mehr aus. Zu dem gesamten Lieferungsprozess gehören natürlich viele verschiedene Workloads. Einige unserer Anwendungen werden von mehr als 5.000 Personen verwendet. Diese Apps werden für diese Benutzer mehr und mehr zur wichtigsten Anwendung im Berufsalltag.

Das sind wirklich viele Anwendungsfälle, und ich freue mich, dass Site Recovery Ihren Anforderungen für die Notfallwiederherstellung entspricht. Können Sie uns etwas mehr über die Architektur dieser Workloads erzählen?

Bei den meisten handelt es sich um Windows-basierte Workloads. Die Software, die weltweit am häufigsten verwendet wird, ist eine Anwendung mit drei Ebenen. Wir verfügen über eine SQL-Datenbank-Instanz, einen Server auf mittlerer Ebene, einen Anwendungsserver sowie einige Web-Front-End-Server. Die neue Architektur, die wir entwickelt haben, basiert jedoch auf Microservices. Es gibt auch einige Linux-Server, die für bestimmte Zwecke verwendet werden.

Wie waren Ihre Erfahrungen mit Linux?

Site Recovery funktioniert einwandfrei mit Linux-Workloads. Am Anfang gab es nur ein paar wenige Fehler, die jedoch von uns verursacht wurden. Wir wollten ein Red Hat-Produkt namens Satellite für Updates verwenden, wussten aber nicht, dass wir dann nicht selbst festlegen konnten, wie die VMs verwaltet werden sollen. Der Verwaltungstyp muss am Anfang definiert werden, sonst ist es zu spät. Abgesehen davon funktioniert das Bring-Your-Own-License-Modell sehr gut, besonders mit Site Recovery.

Ich freue mich, dass bei Ihnen alles so unkompliziert geklappt hat. Gab es einen anderen Aspekt an Site Recovery, der Sie beeindruckt hat, oder von dem andere Organisationen wissen sollten?

Ein wesentlicher Vorteil ist für mich, dass sich Tests so einfach durchführen lassen. Bei dem herkömmlichen Ansatz war jeder umfassende Test der Notfallwiederherstellung aufgrund der Vorbereitung immer zeit- und ressourcenaufwendig. Vor einigen Wochen haben wir mit Site Recovery die vollständige Umgebung getestet, und die Vorbereitung war sehr unkompliziert. Der Wechsel zur DR-Region ging schnell, und genauso einfach war es, die Workload in die primäre Region zurückzuholen. Das triftigste Argument ist für mich heute, dass Site Recovery so unglaublich benutzerfreundlich ist.

Wenn Sie Site Recovery heute noch einmal einführen müssten, was würden Sie anders machen?

Ich würde Site Recovery früher implementieren. Wenn wir nicht erst den herkömmlichen Aktiv-Passiv-Ansatz verwendet hätten, hätten wir dem Unternehmen Zeit und Geld gespart, glaube ich. Andererseits waren wir aufgrund dessen sehr zuversichtlich bei der Site Recovery-Journey. Abgesehen davon würden wir nicht viel anders machen, denke ich. Unser nächstes Ziel ist jetzt, uns mit den Azure Site Recovery-Diensten zu beschäftigen, damit wir Workloads replizieren können, die auf lokalen VMs in Hyper-V ausgeführt werden. Für alle Anwendungen, die bisher noch nicht zu Azure migriert wurden, möchten wir zumindest eine richtige Notfallwiederherstellung sicherstellen. Außerdem möchten wir die VMware-VMs replizieren, die wir seit der Migration zu Hyper-V noch haben. Das sind unsere nächsten Ziele.

Haben Sie irgendwelche Ratschläge für Interessenten oder andere aktuelle Kunden von Site Recovery?

Meine Empfehlung wäre, Site Recovery früher und, falls erforderlich, in einem kleineren Umfang einzuführen. Site Recovery lohnt sich bereits bei einer kleinen App. Sie werden den Mehrwert sofort erkennen. Dann können Sie die operativen Teams von den Vorteilen und davon überzeugen, dass sie den Site Recovery-Diensten vertrauen können, anstatt alles selbst zu erledigen.

Ein wirklich guter Rat. Das waren alle meine Fragen, Quentin. Vielen Dank, dass Sie Ihre Erfahrungen mit uns geteilt haben.

Weitere Informationen zum Thema Resilienz mit Azure