Unser Umzug nach Azure und Office 365 – Teil 1

Wie wir schon hier erwähnten, ist die Infrastruktur der ML Network seit einigen Wochen weitgehend in Azure und Office 365 abgebildet. In einer kleinen Reihe an Beiträgen möchten wir Ihnen gerne berichten, was es hierbei zu beachten gab und auch, was wir hierbei noch gelernt haben.

Die Entscheidung

Der erste Anstoß war – wie bei vielen anderen Unternehmen – der Lockdown in Deutschland als Maßnahme gegen COVID-19 im März diesen Jahres. Wir verlagerten uns ins Home Office und nutzten hierfür ein neues, kleines Setup mit VMware Horizon View und View Agents auf den Arbeitsrechnern der Kollegen. Viele laufende Projekte wurden auf Eis gelegt, andere – häufig auf das Thema „Home Office“ bezogene – rückten in den Vordergrund, und wir konnten die meiste unserer Arbeit remote erledigen – zum Glück ohne Personaleinsparungen oder Kurzarbeit.

Während also bei uns ein Umdenken stattfand, was die Standortunabhängigkeit unserer Arbeit betrifft, kamen auch die großen, wichtigen Fragen noch einmal hoch: was ist, wenn’s brennt? Wie schnell – und und vor allem wo – können wir unsere Umgebung mit dem Offsite-Backup neu aufbauen? Was passiert, wenn ein Bagger uns die DSL-Leitung kappt? Unsere Hardware stand zufällig auch zur Erneuerung, und wir beschäftigten uns intensiv mit der Frage, ob und wie wir ohne riesige Investitionen und Aufwand unsere IT-Infrastruktur möglichst geschickt neu gestalten können. Nicht in Hardware investiertes Geld kann ja z.B. in gute Mitarbeiter investiert werden ;-)

Wir liebäugelten mit verschiedenen Ideen, u.a. Colocation im Datacenter, letztlich entschieden wir uns aber dazu, unsere Infrastruktur komplett in Azure und Office 365 abzubilden.

Die Ausgangslage

Unsere Umgebung ist und war nicht hochkomplex: ein kleines Cluster mit VMware vSphere auf zwei Hosts, vCenter, zwei DCs, File- und Printserver, WSUS, Exchange 2016, eine Handvoll Linux-Maschinen für Web-Services, Sophos UTM als Spam-Schutz, pfSense Firewall, View Connection Server mit UAG, PKI – in Summe 18 VMs auf zwei Hosts, ein paar VLANs mit eigenen Firewall-Interfaces. Auf dem Backup-Server war Veeam Backup & Replication in Betrieb mit zwei Kopien on-site und einer Kopie auf USB-Festplatte off-site.

Zur Nutzung von Microsoft Teams hatten wir bereits Exchange Hybrid, AzureAD Sync und ADFS/ADFS Proxy in Betrieb.

Nichts kompliziertes – wir konzentrieren uns lieber auf unsere Kunden als auf unsere Infrastruktur.

Ein erster Überblick

Um eine ungefähre Schätzung der Kosten zu bekommen, welche durch die Nutzung von Azure entstehen, haben wir zunächst einmal das Azure Migrate Assessment Tool in unserer VMware-Umgebung installiert. Während das einige Tage lief und Daten sammelte, haben wir einmal durchgeplant, welche Maschinen wir im Ende in Azure abbilden und welche wir nicht mitnehmen – z.B. die Sophos UTM, unser ADFS-Setup, WSUS usw.

Nach der ersten Einschätzung haben wir uns mit dem Azure Pricing Calculator befasst, um einen Eindruck zu bekommen, wie sich das Sizing von VMs auf die Kosten auswirkt.

Unterstützt von einer Azure Sponsorship für Partner konnten wir mit einem Budget von etwa 16 USD pro Tag kalkulieren. Für Office 365 standen uns als Microsoft-Partner genügend IUR-Lizenzen (Internal Use Rights) zur Verfügung.

Sizing

Bevor wir an das Sizing gingen, mussten wir erst einmal wissen, was wir in Azure benötigen – am Ende blieben dabei 9 virtuelle Maschinen übrig:

• Zwei Domain Controller
• PKI
• Fileserver
• Management Server
• Remote Desktop Host (All-in-one Deployment)
• Ticketsystem
• SQL/IIS Anwendungs-Server
• Exchange 2016 für Hybrid Deployment

Was fiel hintenüber?

• Windows Updates: unsere Azure-Server werden über einen Automation Account automatisch am letzten Freitag des Monats gepatcht. Für die Clients haben wir auf normales Windows Update gesetzt und Delivery Optimiztion konfiguriert.
• Die Sophos UTM wird durch Exchange Online Protection ersetzt
• AzureAD Sync wird direkt auf den DCs in Azure ausgeführt
• Das ADFS-Setup konnten wir durch Umstellung auf Pass-Through Authentication um eine VM reduzieren
• Die verschiedenen Linux-Maschinen wurden durch eine einzelne ersetzt
• View Connection Server und UAG werden durch das Remote Desktop Deployment ersetzt
• Die pfSense wird in Kürze durch eine WatchGuard Firebox ersetzt

Wir haben uns als Baseline für VMs der B-Serie entschieden und es nicht bereut. Ausschlaggebend waren hier die Kosten gegenüber der D-Serie, aber wir haben in Hinsicht auf die Performance keine Klagen.

Für unsere Belange reichten bei den meisten VMs Standard HDD Disks. Nur unsere Applikationsserver haben Standard- oder Premium-SSDs erhalten.

Für die Verbindung zwischen unserem Standort und Azure haben wir eine einfach ein Azure VPN Gateway als Gen1 Basic SKU eingerichtet, da wir die weitergehenden Funktionen (mehr als 100 Mbps, BGP, Zonenredundanz) nicht benötigten.

Für unsere Backups haben wir ein Recovery Services Vault mit einigen einfachen Policies eingerichtet. Die meisten VMs beinhalten keine Daten, die nach mehr als einer Woche noch von Wert wären, so dass wir für diese nur 7 Restore Points vorhalten. Unser Fileserver erhält hingegen 7 tägliche Restore Points, 5 wöchentliche, 12 monatliche und 3 jährliche.

Weitere Kostenbegrenzung

Noch waren wir nicht bei unserem Ziel von 16 USD pro Tag angelangt… also haben wir zu Guter Letzt noch einen Automation Account mit zwei Runbooks eingerichtet, welche verschiedene VMs um Abend und zum Wochenende hin automatisch herunterfahren und wieder starten. Es hat ein bisschen gedauert, bis wir uns daran gewöhnt haben – wer fährt schon Server ohne Not herunter? Aber auf diese Weise konnten wir die Kosten auf 18 USD pro Tag unter der Woche und 10 USD pro Tag am Wochenende senken.

Wie geht es weiter?

Im nächsten Beitrag werden wir Ihnen berichten, wie wir den Einsatz von Office 365 geplant haben und wie wir die Installation in Azure angegangen sind.