Hallo Azure Community,
heute habe ich einmal wieder einen kleinen Bericht aus meiner Azure ExpressRoute Praxis für euch. Aktuell ist es für Microsoft Kunden etwas schwer. sich mit der Microsoft ExpressRoute Edge Site Berlin zu verbinden und damit eine Verbindung mit niedriger Latenz nach Magdeburg/Biere aufzubauen.
Hierfür gibt es zwei einfache Gründe. Der erste Grund ist, dass nur zwei Internet Service Provider direkte Verbindungen aufbauen können. Hierbei handelt es sich um die Telekom und die Colt. Bei dem zweiten Grund handelt es sich um die generelle Praxis der anderen Internet Service Provider. Viele kleinere Internet Service Provider gehen bevorzugt über Interconnect Knoten der Equinix. Die Equinix ist allerdings nur in Frankfurt vertreten und somit stellen viele ihre Verbindungen also über Frankfurt her.
Nun denken sich jetzt einige „ist doch egal“. Da kann ich euch aber sagen, nein das ist es nicht.
Gerade wenn der Standort der angebunden werden soll, nördlich oder östlicher als Magdeburg liegt. Wenn man hier den Leitungsweg über Frankfurt zu Microsoft Cloud Deutschland Northeast sucht, sind die Latenzen unheimlich hoch.
Stellt euch einmal folgendes vor:
Ihr habt einen Standort in Hamburg. Euer Paket geht erst nach Frankfurt, dann nach Magdeburg, zurück nach Frankfurt und dann endlich nach Hamburg.
Noch schlimmer wird dieses Beispiel natürlich für Berlin, an dem sich die Microsoft Edge Site befindet.
Anbei mal das Beispiel als Bild:
Wenn man jetzt berechnet, dass bei modernen Glasfasernetzen eine Ausbreitungsgeschwindigkeit von grob 200.000 km/s möglich ist, beträgt die reine Leitungslatenz pro 200 km also 1ms.
Da in Deutschland Glasfaserkabel meistens an Autobahnen verlegt werden, nehmen wir diese Kilometer mal als Streckenvorlage. Erfahrungsgemäß kommt man damit weitestgehend hin. Die genauen Strecken bekommt man in Europa leider nur mit einem Antrag zur Leitungsoffenlegung. Dies Gestaltet sich aber für nicht Internet Service Provider als etwas schwierig.
Also rechnen wir mal etwas:
Richtung |
Von – Nach |
Ca. Kilometer |
Ca. Latenz |
User zu Azure |
Berlin – Frankfurt am Main |
545 km |
2,7 ms |
User zu Azure |
Frankfurt am Main – Magdeburg/Biere |
413 km |
2,1 ms |
Azure zu User |
Magdeburg/Biere – Frankfurt am Main |
413 km |
2,1 ms |
Azure zu User |
Frankfurt am Main – Berlin |
545 km |
2,7 ms |
|
Gesamt: |
1.916 km |
9,6 ms |
Das macht eine reine Roundtrip Time und Latenz, von eurer Firewall bis zum Microsoft Gateway, in Höhe von mindestens 9,6 ms . Dazu kommt dann noch die Latenz in eurer und in der Microsoft Infrastruktur. Nach meinen persönlichen Messungen, sind wir am Ende bei einer Roundtrip Time von 18 – 22 ms
Nehmen wir jetzt mal die Strecke zwischen Berlin und Magdeburg zum Vergleich. Zu erst wieder optisch.
Rechnerisch sieht das dann so aus:
Richtung |
Von – Nach |
Ca. Kilometer |
Ca. Latenz |
User zu Azure |
Berlin – Magdeburg/Biere |
180 km |
1 ms |
Azure zu User |
Magdeburg/Biere – Berlin |
180 km |
1 ms |
|
Gesamt: |
360 km |
2 ms |
Das macht jetzt eine reine Roundtrip Time und Latenz in Höhe von zirka 2 ms, natürlich plus der Latenz in eurer und in der Microsoft Infrastruktur. Nach meinen persönlichen Messungen, haben wir jetzt eine Roundtrip Time von 8 – 10 ms.
Das macht also eine Reduzierung der Latenz um das Drei- bis Fünffache.
Wer mehr zu Thema Latenz lesen möchte, hier ein kleiner Artikel dazu: http://www.ip-insider.de/latenz-dominanter-leistungsfaktor-moderner-netze-a-296269/
Ich denke mal, dass macht es etwas anschaulicher warum es uncool ist als „Nordlicht“ über Frankfurt nach Magdeburg zu gehen, obwohl es der nächste Standort ist.
So wie bekommt man jetzt die latenzgünstigere Strecke geschaltet? Ein Weg wäre z.B. ein MPLS oder eine Verbindung bei Colt oder dem rosa Riesen zu kaufen oder man muss den Internet Service Provider der Wahl ermuntern in Berlin eine Verbindung aufzubauen.
Letzteres habe ich bereits erfolgreich mit der Interoute durchgeführt und entsprechende Erfahrungswerte sammeln dürfen.
Was müsst ihr also mit dem Internet Service Provider euer Wahl tun. Euer Internet Service Provider muss sich einen der zwei Interconnect Provider in Berlin aussuchen. Zum einen ist das Colt über den ECIX und e-Shelter über den BCIX.
Die Entscheidung welcher Interconnect Provider genommen wird, hängt meistens an den vorhandenen Anbindungen zu den jeweiligen Internet Exchange Knoten der Internet Service Provider.
Eine Liste der verfügbaren Provider pro Knoten und Point of Presence (Standort) bekommt man unter anderem von den Webseiten des BCIX und des ECIX.
Mit Interoute habe ich mich für e-Shelter entschieden, da Interoute im e-Shelter Rechenzentrum anliegt und die Wege entsprechend sehr kurz sind. Zudem kenne ich beide Parteien und ihre Infrastrukturen seit einigen Jahren sehr genau und kann dementsprechend bei der Umsetzung unterstützen.
Im Fall der Anbindung über einen Interconnect Provider übernimmt der Internet Service Provider die Verbindung nach Berlin in den Standort des Interconnect Providers und der Interconnect Provider stellt dann den Interconnect zu Microsoft her. Microsoft übernimmt dann die Übertragung nach Magdeburg/Biere.
Die Grafik zeigt euch mein Beispiel mit Interoute und e-Shelter.
So ich hoffe dieser kleine Abriss hilft euch in der Praxis weiter und bringt etwas Licht in den WAN Dschungel und viel wichtiger, hilft euch eine günstige und performante WAN Infrastruktur aufzubauen ohne euch von irgendwelchen rosa Elefanten übers Ohr hauen zu lassen.
Wer hierzu noch Fragen hat oder Beratung benötigt, kann sich wie immer gerne bei mir melden.
Beste Grüße
Flo