VPN zwischen Microsoft Azure Regionen

Initiiert durch eine Prüfungsfrage hat mich das Thema Azure Inter-Datacenter Kommunikation schon länger interessiert. Wie funktioniert es also, wenn ich VMs in zwei unterschiedlichen Regionen miteinander kommunizieren lassen will? Technisch könnte ich zwar Endpunkte der VMs veröffentlichen und die externe IP des anderen Cloud Service ansprechen, aber diese Lösung ist aufwändig, nicht secure und nicht skalierbar. Viel besser, ich konfiguriere ein exklusiv für mich bereitgestelltes Site to Site VPN Netzwerk. Dafür benötige ich VMs, einen Cloud-Dienst und ein virtuelles Netzwerk in jeder der beiden Azure Regionen. An das virtuelle Netzwerk wird je ein Gateway angeschlossen und als Site-to-Site VPN konfiguriert. Nochmal alle Schritte im Überblick.

  1. virtuelles Netz 1 in Region 1 erstellen
  2. virtuelles Netz 2 in Region 2 erstellen
  3. Gateway am virtuellen Netzwerk Region 1 erstellen
  4. Gateway am virtuellen Netzwerk Region 2 erstellen
  5. Verbindung konfigurieren
  6. Verbindung aufbauen
  7. Cloud-Dienst 1 und VM 1 im virtuelles Netz 1 erstellen
  8. Cloud-Dienst 2 und VM 2 im virtuelles Netz 2 erstellen

Nun alle Schritte im Detail. In dieser Konfiguration verwendete ich folgende virtuelle Netzwerke.

 Name VNet-Westeuropa VNet-Nordeuropa
Speicherort Westeuropa Nordeuropa
Adressraum 192.168.0.0/23 192.168.2.0/23
Subnetz für VMs 192.168.0.0/24 192.168.2.0/24
Subnetz für Gateway 192.168.1.0/24 192.168.3.0/24
Zugelassenes Remote Subnetz 192.168.2.0/24 192.168.0.0/24

Im ersten Schritt erstelle ich ein virtuelles Netzwerk im Speicherort Westeuropa.

48

Dabei klicke ich zusätzlich den Site-To-Site-VPN Hacken an.

49

Anschließend vergebe ich einen Namen für das Remote Netzwerk und den Adressraum der anderen VPN Site. Die öffentliche IP-Adresse des VPN-Gerätes kann erstmal frei gewählt werden. Diese muss ich später nochmal ändern, da die öffentlichen IP-Adressen der späteren Gateways ja noch unbekannt sind.

50

Nun wird der eigene Adressraum des virtuellen Netzwerkes konfiguriert. Er besteht aus der Netzadresse + CIDR, welche alle Teile der Subnetze umfasst. Darunter können die eigentlichen Subnetze angelegt werden. In meinem Fall benötige ich ein Subnetz für die VMs selbst und das Gatewaysubnetz, was dem Routing dient.

51

Gleiche Schritte muss ich nun noch einmal für das virtuelle Netzwerk im Speicherort Nordeuropa durchführen. Hier habe ich dann die Subnetze der oberen Tabelle verwendet.

68

Für eine Azure to Azure Verbindung wird ein Gateway vom Typ Dynamisches Routing benötigt. Diesen erstelle ich je im virtuellen Netzwerk durch das untere Aktionsfeld. Das Erstellen  dauert bis zu 30 Minuten.

56

Nun sind auch die öffentlichen Gateway-Adressen festgelegt und bekannt. Diese muss ich in das vorhin definierte Remotenetz (lokales Netzwerke) eintragen. Die Gateway-IP-Adresse von vnet-nordeuropa wird in das lokale Netzwerk Nordeuropa eingetragen und die Gateway-IP-Adresse von vnet-westeuropa wird in das lokale Netzwerk Westeuropa eingetragen. Etwas verwirrend, aber das lokale Netzwerk Nordeuropa ist ja ein Teil der Konfiguration von Westeuropa. Das Gateway Westeuropa muss wissen über welche IP-Adresse es das Netz Nordeuropa erreichen kann.

57

59

69

In einer Azure to Azure Verbindung müssen die Schlüssel natürlich gleich sein. Derzeit verwendet jedes Gateway seinen eigenen Schlüssel. Dieser Schritt kann nur über die Microsoft Azure Powershell durchgeführt werden.

Set-AzureVNetGatewayKey -VNetName VNet-Nordeuropa -LocalNetworkSiteName Westeuropa -SharedKey <neuer Key>

Set-AzureVNetGatewayKey -VNetName VNet-Westeuropa -LocalNetworkSiteName Nordeuropa -SharedKey <neuer Key>

60

Nun kann die Verbindung von einer der beiden Seiten im Aktionsfeld des virtuellen Netzwerks aufgebaut werden. Das Resultat sieht dann so aus:

61

62

Abschließend erstelle ich noch in jedem virtuellen Netzwerk eine VM. Dabei achte ich darauf, dass ich in der Region / Affinitätsgruppe / virtuelles Netzwerk das zuvor erstellte virtuelle Netzwerk  VNet-Nordeuropa und VNet-Westeuropa auswähle.

VM Westeuropa VM Nordeuropa
Cloud-Dienst Westeuropa Nordeuropa
Region / Affinitätsgruppe / virtuelles Netzwerk VNet-Westeuropa VNet-Nordeuropa
Automatisch zugeordnete IP-Adresse 192.168.0.4 192.168.2.4

63

64

Abschließend öffne ich in der Firewall die ICMP Regel und teste die Verbindung.

66

Derzeit ist die Bandbreite auf max. 100 Mbit/s begrenzt. Bei einer Messung schwanken die Werte und ich erreiche im mittel ca. 80 Mbit/s.

67

Im Design sollte man berücksichtigen, dass neben den Kosten der Gateways selbst, ausgehender Datenverkehr normal berechnet wird. Nur eingehender Datenverkehr ist frei.

Cloud Computing Testumgebung 2.0

Nach langer Pause mal wieder ein Beitrag zu meinem neuen Testsystem. Im konkreten Fall ging es um eine möglichst flexible Testumgebung für virtualisierte Infrastrukturen. Der Fokus lag dabei nicht auf der Nachbildung eines Failover Clusters, sondern auf möglichst viel Performance. Nicht immer ergibt sich die Möglichkeit remote auf entfernte Infrastrukturen zuzugreifen und auch jedes Notebook hat irgendwo seine Leistungsgrenzen. Der eine oder andere möchte sich vielleicht auch unabhängig dem Arbeitgeber in den eigenen Wänden weiterentwickeln und testen. Derartig viel Leistung, auch wenn gleich nur die Laufzeit berechnet wird bspw. in Microsoft Azure zu hosten ist für eine Privatperson auch nicht erschwinglich. Ein gebrauchter Server fällt durch die schlechte Energiebilanz, aber vor allem wegen der Lautstärke ebenfalls raus. Ich habe im Vorfeld Referenzsysteme gesucht, bin aber nicht wirklich fündig geworden. Also habe ich selbst etwas recherchiert und zusammengestellt.

Folgende Anforderungen waren gestellt

  • 24 GHz Rechenleistung
  • 64 – 128 GB Ram
  • 1 TB mit 25.000 IOPS, 600 MB/s seq. Read / 400 MB seq. Write
  • 1 TB mit 200 IOPS, 120 MB/s seq. Read / Write
  • transportierbar
  • geräuscharm
  • energieeffizient
  • keine laufenden Kosten Hostingkosten
  • 2000 EUR Investitionskosten
  • Consumer Hardware ausreichend
  • Windows Server 2012R2 kompatibel

Hauptproblem war es, ein Mainboard für diese Speichermenge zu finden. Intel als CPU Hersteller sprengt leider den Preisrahmen. Einige Komponenten, besonders im Serverbereich, sind für preiswertes Geld auch gebraucht zu erwerben. Das Mainboard liefert durch den SATA2 Controller im Raid 0 mit den SSDs nur einen Durchsatz von ca. 400 MB/s. Durch die PCIe ASUS SATA3 Karte kann der Durchsatz auf immerhin 650 MB/s gesteigert werden.

Mit diesem System sollten die nächsten Tests und Blogartikel kein Problem sein. Im Dauerbetrieb seit 4 Wochen kam es zu keinem Absturz.

Komponente Neupreis in EUR Brutto Preis gebraucht in EUR Brutto
Supermicro H8SGL 250,00 100,00
Opteron 12-Core Prozessor 300,00 150,00
8 x 16 GB DDR3-1333regECC DIMM 1000,00 600,00
CPU Lüfter Sockel G34 50,00
4 x 256 GB SSD (Crucial, Sandisk, Samsung) 360,00
1 x 1 TB (WD, Seagate) 50,00
2x ASUS U3S6 SATA 3 PCIe 70,00
Gehäuse mit Netzteil 50,00
3x Netzwerkkarten 15,00
Summe 2145,00 1445,00

Der maximale Wattbedarf unter Volllast sollte bei ca. 300 Watt liegen. Sobald ich ein Messgerät zur Hand habe werde ich das prüfen und nachliefern.

—————————————————————-

Update

Standby: 1,8 Watt

Idle: 120 Watt

Volllast: 210 Watt

—————————————————————-

Das Mainboard unterstützt bis zu 256 GB Ram. Wer sich auch mit 64 GB zufriedengibt, kann die o.g. Konfiguration etwas abwandeln und dadurch auch gut sparen. Durch den SATA 3 Onboard Controller dieser Konfiguration werden auch deutlich mehr Festplatten IOPS möglich sein.

Komponente Neupreis in EUR Brutto
ASRock 990FX Extreme3 90,00
AMD FX-8350 150,00
4 x 16 GB DDR3-1333regECC DIMM 560,00
CPU Lüfter 50,00
4 x 256 GB SSD (Crucial, Sandisk, Samsung) 360,00
1 x 1 TB (WD, Seagate) 50,00
Grafikkarte 30,00
Gehäuse mit Netzteil 50,00
3x Netzwerkkarten 15,00
Summe 1355,00

37 35

 

 

 

 

 

 

Cloud Computing Testumgebung für 1300 EUR

Wer kennt das nicht, früher am Anfang der Virtualisierungsspielerei war noch ein einziges Gerät ausreichend. Auf diesem hat man seinen Hypervisor zum Laufen gebracht und war glücklich nun einige VMs betreiben zu können. Demnächst folgt noch ein Blogbeitrag zum Thema Testumgebung auf dem Notebook, denn im Projektgeschäft kann ich darauf nicht ganz verzichten.

Nachdem ich in der Vergangenheit in der Firma stets Jäger alter Hardware war, befand ich mich irgendwann in einer Ressourceneinbahnstraße. Ich überlegte mir, wie viel Geld man wohl in die Hand nehmen müsste, um eine Testumgebung aufzubauen, mit der nahezu alle Funktionen einer modernen Privat Cloud Umgebung mit Microsoft Cloud OS aufzubauen. Der Fokus lag dabei ganz klar auf maximalen Ressourcen, aber die Infrastruktur sollte überall (auch zu Hause) betrieben werden können. Damit fallen i.d.R. gebrauchte Server heraus. Zwar gibt es diese schon für moderates Geld, aber Stromverbrauch und Lautstärke sind wohl weniger was fürs Arbeitszimmer. Also was brauchen wir für eine private Cloud? Zum einen zwei möglichst identische Hostserver die später im Cluster laufen werden, zum anderen ein zentrales Storage, einen Switch und einen Router, paar Netzwerkkabel. That’s it. Meine Testumgebung ist bereits 1,5 Jahre alt, deswegen könnten einzelne Komponenten mittlerweile nicht mehr verfügbar sein. Nachfolger zu finden sollte aber kein Problem sein. Die Preise sind Nettopreise.

Hostserver

Was gehört in den Hostserver? Eine kleine SSD und viel RAM und viele Netzwerkkarten. Ich habe bei der Auswahl auf einen Prozessor mit APU geachtet, um auch RemoteFX zu testen. Das Mainboard sollte über onboard Grafik verfügen und 5x Netzwerkkarten (bevorzugt PCIe) aufnehmen können.

Mainboard – 60 EUR

AMD APU – 70 EUR

4x DIMM 8 GB DDR3 – 200 EUR

60 GB SATA3 SSD – 40 EUR

5x NIC 1 GBit PCIe – 40 EUR

Gehäuse mit Netzteil – 40 EUR

Zentrales Storage System

Im ersten Aufbau wurde eine kleine 4 Bay QNAP beschafft. Allerdings waren die Lese- und Schreibwerte im Testaufbau sogar noch deutlich schlechter als auf dem Datenblatt vermerkt. Als ich mich mit dem Thema SMI-S Integration in VMM beschäftige, musste ich mich endgültig von der QNAP verabschieden. An dieser Stelle sei vermerkt, nur neue QNAP Modelle unterstützen SMI-S Integration siehe http://eu1.qnap.com/Storage/Manual/QNAP_SMIS_Provider_ENG.pdf

Die Alternative war schnell gefunden: einen Windows Storage Server. Dazu kam noch eine SSD um den Write Back Cache und Tiered-Storage zu nutzen. Das Ergebnis WOW. Demnächst folgt noch ein Blog der sich um das Thema Performance von Windows Storage Server dreht. Bei dem Storage gehe ich einfach mal davon aus, jeder hat irgendwo noch einen PC herumstehen der folgende Spezifikationen mindestens erfüllt:

Dual Core 64 Bit CPU

4 GB RAM

1 GBit onboard LAN

2 freie PCIe Slots

insgesamt 6 SATA Ports (alternativ einen zusätzlichen SATA Controller für 15 EUR)

Das Gehäuse sollte über gute Belüftung verfügen. Alternativ sollte aufgrund der Festplatten ein zusätzlicher Gehäuselüfter installiert werden. Den PC erweitern wir um:

60 GB SATA3 SSD – 40 EUR

2x NIC 1 GBit PCIe- 16 EUR

4x 2 TB SATA3 HDD – 240 EUR

Netzwerk

Normalerweise steht an Netzwerktechnik auch immer etwas „herum“. Zumindest ein Router mit anständigem Router OS sollte vorhanden sein. Bei einer Neuanschaffung würde ich eine Leistungsstarke CPU und 2x GBit/s Anschlüsse wählen, da ein Teil des Netzwerkverkehrs später über den Router transportiert wird. Der Switch sollte über 16-24 GBit/s Ports verfügen, verwaltbar sein und VLAN, QoS oder LACP sollten für das Gerät keine Fremdwörter sein.

16 GBit Switch – 100 EUR

In der Summe erhaltet Ihr für rund 1300 EUR oder etwas mehr, wenn gar keine Technik vorhanden ist, eine Testumgebung mit der viele Szenarien des Cloud Computings evaluiert werden können. Nahezu alle technischen Artikel in diesem Blog sind mit dieser Testumgebung nachgestellt worden. Viel Spaß beim Nachauen.

Testnetzwerk Netzwerkplan

Testnetzwerk Aufbau