Unser Umzug nach Azure und Office 365 – Teil 2

Ein guter Grund zur Aufteilung in verschiedene Ressourcengruppen ist auch die rollenbasierte Zugriffssteuerung in Azure (RBAC). Möglicherweise haben Sie verschiedene Administratoren, die unterschiedliche Server und die zugehörigen Ressourcen verwalten sollen – beispielsweise in der Anwendungsadministration.

In unserem Fall ergab sich kein Bedarf an mehr als einer Ressourcengruppe. 

Bei der Erstellung einer Ressourcengruppe muss eine Azure Region angegeben werden. Die Wahl der Region sollte ebenfalls mit Bedacht geschehen – in unserem Fall lag die Wahl einer deutschen Region nahe. 

Bei der Benennung unserer Ressourcen haben wir uns übrigens an die empfohlenen Namenskonventionen von Microsoft gehalten – tun Sie sich den Gefallen auch.

Netzwerk

Ein wichtiger Bestandteil der Azure-Umgebung und die erste Ressource, die wir erstellt haben, war das VNet. Vereinfacht kann das VNet als ein LAN verstanden werden, das verschiedene Subnetze enthalten kann, ein VPN-Gateway, und Network Security Groups, welche die Funktion von Firewalls übernehmen. 
Die Adressbereiche und die Subnetze eines VNets wollen gut durchdacht sein. Die ersten drei IP-Adressen eines Subnetzes sind reserviert und können nicht vergeben werden. Wählen sie auch sinnvolle Größen der Subnetze für den Anwendungszweck. Für unsere 9 VMs haben wir z.B. kein /8 verwendet… ;-)

Damit wir unser lokales Netzwerk mit dem Netz in Azure verbinden können, haben wir ein VPN-Gateway erstellt und einen IPSec-Tunnel zu unserer lokalen Firewall konfiguriert. Eine Basic SKU hat in diesem Fall gereicht – wir brauchten keine der Funktionen der höheren SKUs. 

Mittels einer Network Security Group haben wir das Server-Netz abgesichert. Die NSG wird mit Subnetzen verbunden und kann sowohl auf Subnetz- als auch auf Netzwerkkarten-Ebene konfiguriert werden. 

Eine unerfreuliche Feststellung haben wir dann aber auch gemacht: in VNets mit einem VPN-Gateway können keine IPv6-Adressbereiche konfiguriert werden. Das hat uns doch enttäuscht, zumal wir gerade vorletztes Jahr bei uns alles sehr schick mit IPv6 umgebaut hatten, aber abbrechen wollten wir deshalb auch nicht. 

Nun waren wir soweit für die ersten VMs…

Virtuelle Maschinen

Wie bereits im ersten Beitrag erwähnt, haben wir als Basis für unsere VMs die B-Serie gewählt. Im Allgemeinen sollte man VMs zuerst kleiner wählen und bei Bedarf aufstocken. Auch kann der Azure Advisor verwendet werden, der Verbesserungsvorschläge hinsichtlich des VM-Sizings geben kann. Die Änderung des VM-Typ geht problemlos jederzeit und benötigt lediglich einen Neustart der VM.
Unsere VMs sind fast alle vom Typ B2s mit 2 CPUs und 4GB RAM. Der RDS-Host und der Management-Server sind als B2ms ausgeführt mit 2 CPUs und 8GB RAM, der Exchange-Server hatte zunächst auch dieses Sizing, wurde dann aber auf B4ms verdoppelt. Wir können also bestätigen, dass das problemlos geht.

Die meisten der VMs verwenden Standard-HDDs – auch der File-Server. In unserem Fall wäre das Bottleneck viel eher als IOPS die Internetanbindung mit 50/10 Mbps. Wir können hier aber keinerlei Performance-Probleme feststellen.

Wir haben zwei Web-Server: eine Linux-Maschine für Ticketsystem und interne Wiki und ein Windows Server mit IIS und SQL-Datenbank für unsere Stundenerfassung. Es hätte sich bei letzterem möglicherweise angeboten, auf die Angebote zu PaaS (Platform-as-a-Service) von Microsoft zu setzen: Azure Web Apps, Azure SQL, Application Gateway für Load Balancing. Statt also VMs aufzusetzen, können diese Dienste direkt als Ressourcen verwendet werden, ohne das Betriebssystem darunter administrieren zu müssen. Wenn Sie umfangreiche, geschäftskritische Anwendungen betreiben, können wir Ihnen diese Angebote sehr ans Herz legen. In unserem Fall mussten wir realistisch feststellen, dass sie sich für unsere Kleinstanwendung (auf SQL Express) schlicht nicht rechnen.

Übrigens: In unseren Fall haben wir die VMs manuell erstellt. Für größere Installationen empfehlen sich natürlich Ressourcenvorlagen!

Die Migration

In den folgenden Tagen haben wir unsere lokalen Services nach und nach auf die Azure-VMs migriert. Große Teile hiervon waren eine ganz normale Servermigration, wie wir sie regelmäßig machen: Domain Controller, PKI, File-Server, DFS, SQL, IIS, die Linux-Webserver – nicht der Rede wert. Einige Aspekte mussten aber auch grundsätzlich anders geregelt werden.

• Unsere lokalen Domain Controller waren auch DHCP-Server – den haben wir auf die Firewall geholt
• Windows Updates für die Clients kamen vom lokalen WSUS – wir haben die GPOs angepasst, damit die Clients die Updates aus dem Internet laden und untereinander Delivery Optimization nutzen
• Unsere Warenwirtschaftslösung verwendet dateibasierte Datenbanken. Mit Zugriff auf einen lokalen Fileserver lief diese bislang direkt auf den Clients – die Variante erwies sich als unbenutzbar über den VPN-Tunnel. Daher haben wir die Anwendung als RemoteApp aus Azure bereitgestellt, was sehr gut funktioniert. 

Innerhalb weniger Tage war das meiste dann bereits migriert, getestet und für gut befunden. 

Und Exchange?
Eines der interessantesten Arbeitspakete war die Migration zu Exchange Online – das ist uns einen eigenen Artikel wert. Wir berichten im nächsten Beitrag von Office 365, Exchange Online mit Hybridstellung und was es hier im Zusammenhang mit Azure zu beachten gibt.