Was passiert wenn eine Standort-Abfrage per DNS nicht mehr funktioniert? Dieser Artikel zeigt die Lösung!.
Die Ausganssituation
Wer hat das Problem nicht schon gehabt. Mein Szenario verwendet zwei Standorte mit einem Exchange Server an jedem Standort, ein Internet Breakout an jedem Standort und damit auch zwei OWA Zugänge. Das Ganze sieht dann in etwa wie im Bild unten aus.
Damit sich ein User jetzt nicht zwei URLs merken muss, verwenden die meisten Kunden einfach DNS Round Robin um den Client auf einen von beiden Standorten zu schicken. Das funktioniert eigentlich auch sehr gut. Man hat halt eventuell den User Zugriff in London obwohl die Mailbox eigentlich aktiv in Wien liegt. Für die meisten nicht ‘schön’ aber technisch kein Hindernis.
Das Problem
Das einziges Problem ist: Was passiert wenn ein Standort nicht mehr funktioniert?
Ein Client wie Outlook ist intelligent genug die multiplen DNS Einträge zu bekommen und probiert einfach durch. Also funktioniert das durchaus auch. Eventuell gibt es etwas größere Verzögerungen als normal, aber es klappt. Aber ein Outlook Web Access wird vielleicht manchmal nicht mehr funktionieren, manchmal aber schon, je nachdem welcher DNS Eintrag grad daherkommt. Das ist jetzt unschön und das können wir besser oder?
Die Lösung
Für solche Probleme gibt es Möglichkeiten wie Global DNS Load Balancing, die man für viel Geld von unterschiedlichsten Herstellern kaufen kann. Kosten viel Geld, sind auch sicher ganz toll und lösen das Problem. Aber das geht auch leichter. Ich habe gemeinsam mit einem Kunden über das Problem nachgedacht und wir haben eine, meiner Meinung nach, simplen aber genialen und noch dazu billigen Lösung gefunden.
Die Cloud eilt zur Hilfe und ermöglicht uns gemeinsam mit Azure und einer Funktion genannt ‘Azure Traffic Manager’.
Ich werde jetzt kurz eine Konfiguration eines simplen Traffic Manager Profils durchgehen, die man selbst einfach nachbauen und jederzeit testen kann. Daher bitte einfach aufmerksam mitlesen.
Wir benötigen eine Azure Subscription, die jeder sowieso haben sollte. Einfach auf der Azure Portal Seite anmelden - und falls nicht vorhanden eine Subscription anlegen. Dort wird eine neue Resource Gruppe angelegt, die man als Basis für das anschließende Traffic Manager Profil benötigt.
Dem Kind einen Namen geben, die Subscription auswählen und noch eine Lokation wählen, in der die Resource Gruppe angelegt wird.
Danach wird es etwas haarig. Traffic Manager Profile kann man zwar über das Portal mit Klick, Klick anlegen. Dann ist es nur leider so, das man den Endpunkt der überwacht werden soll, keinen Pfad mitgeben kann. Nachdem wir aber normalerweise https://owa.contoso.com/owa/healthcheck.htmüberprüfen wollen und nicht nur https://owa.contoso.com müssen wir etwas kreativer werden und ein fertiges Template verwenden. Ich bin ein großer Fan der GitHub Azure Quickstart templates, die für alle erdenklichen Szenarien schon ein Sample haben. Als Basis verwende ich das Traffic Manager External Endpoint Sample und passe es für meine Anforderungen an.
Ein Template wird angelegt und dann ganz einfach über das Portal ein Custom Template ausgewählt.
Danach den untenstehenden Code copy & pasten.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
"contentVersion": "1.0.0.0",
"parameters": {
"uniqueDnsNameOWA": {
"defaultValue": "owacontoso",
"type": "string",
"metadata": {
"description": "Relative DNS name for the traffic manager profile, resulting FQDN will be <uniqueDnsName>.trafficmanager.net, must be globally unique."
}
}
},
"variables": {
"tmApiVersion": "2015-11-01"
},
"resources": [
{
"type": "Microsoft.Network/trafficManagerProfiles",
"name": "OWAGLobalLoadBalance",
"apiVersion": "[variables('tmApiVersion')]",
"location": "global",
"properties": {
"profileStatus": "Enabled",
"trafficRoutingMethod": "Performance",
"dnsConfig": {
"relativeName": "[parameters('uniqueDnsNameOWA')]",
"ttl": 30
},
"monitorConfig": {
"protocol": "HTTPS",
"port": 443,
"path": "/owa/healthcheck.htm"
},
"endpoints": [
{
"name": "owa-vienna",
"type": "Microsoft.Network/TrafficManagerProfiles/ExternalEndpoints",
"properties": {
"target": "owa-vienna.contoso.com",
"endpointStatus": "Enabled",
"endpointLocation": "westeurope"
}
},
{
"name": "owa-london",
"type": "Microsoft.Network/TrafficManagerProfiles/ExternalEndpoints",
"properties": {
"target": "owa-london.contoso.com",
"endpointStatus": "Enabled",
"endpointLocation": "northeurope"
}
}
]
}
}
]
}
Anzupassen ist nur die URL (das Target der Endpoints) damit folgende Situation entsteht:
Ein gemeinsamer Name des Kunden (owa.contoso.com) zeigt als CNAME auf den Traffic Manager. Dieser überprüft in gesetzten Zeiten die externen Endpoints. Hier heißen die Endpoints owa-vienna.contoso.com und owa-london.contoso.com. Es wird überprüft ob der Response an dieser Stelle ein HTTP Response Status 200 (OK) ist. Stimmt das, ist der Endpunkt online und funktionell. Stimmt das nicht, ist er offline und der Client bekommt bei einem DNS Query diesen nicht als Antwort.
Ebenfalls per Default wird auf ‘Performance’ geroutet. Das bedeutet, der Client bekommt bei seiner DNS Query immer den Endpunkt der ihm am nächsten liegt. bzw. am schnellsten für den Client antwortet.
Fazit
Die gezeigte Variante stellt eine sehr einfache Lösung dar, bei der die Cloud eine bestehende Infrastruktur On-Premises unterstützen kann. Der Vorteil aus beiden Welten.
Ach ja, ich hab ganz vergessen, wie sehen die Kosten aus? Wenn man sich den Azure Calculator zur Hand nimmt, findet man im Bereich Networking den Traffic Manager. Dieser wird einfach nach Anzahl an DNS Queries (eine Million Queries kosten 46 EuroCent.) sowie an Anzahl überwachter Endpunkte berechnet. Bei zwei externen und einer geschätzten Anzahl von einer Million Queries kostet das Ganze also lächerliche EUR 1.37 pro Monat.
Azure Traffic Manager kann so wirklich lange laufen, bevor sich ein Geo Load Balancer von einem anderen Hersteller rechnet.
Bis zum nächsten Mal!
LG Christoph