SharePoint CDN

Ein Content Delivery Netzwerk soll ihren eigentlichen Webserver mit den Daten von der Auslieferung statischer Informationen entlasten und durch geografische Bereitstellung sogar schneller ausliefern. Dazu müssen aber diese Informationen dezentral in einem Cache vorgehalten und die Links entsprechend aktualisiert werden.

SharePoint und CDN

Eigentlich ist SharePoint Online ein fast idealer Kandidat für diesen Ansatz, denn es gibt sicher einige Apps, Bilder etc., die keine Nutzdaten und kaum veränderlich sind aber sehr oft nachgeladen werden. Selbst größere Inhalte wie Videos könnten viel besser einmal weltweit verteilt werden, so dass die Abrufe der Anwender vor Ort bedient werden.

Denn bei SharePoint liegen alle Informationen erst einmal in der Geo-Region der Firma. Selbst Firmen, die einen Multi Geo Tenant betreiben, haben nur pro Geo-Region eine eigene URL pro Region. Das bedeutet aber immer noch, dass eine Information erst einmal in einer Region liegt und alle anderen Mitarbeiter auf den anderen Kontinenten über lange Wege darauf zugreifen.

Hier kommt das CDN zum Einsatz, welches Sie aber manuell konfigurieren müssen. Sie können dann in SharePoint hinterlegen, welche Teile der Sharepoint Library über ein CDN bereitgestellt werden:


Quelle: https://docs.microsoft.com/en-us/microsoft-365/enterprise/use-microsoft-365-cdn-with-spo

Diese Funktion ist in SharePoint Online ohne Zusatzkosten enthalten aber per Default nicht aktiviert.

Konfiguration

Wenn Sie also Benutzer haben, die in der Welt verteilt unterwegs sind, könnte der Einsatz des CDN einen Vorteil bringen, da Sie dann nur noch die eigentlichen Inhalte von den SharePoint-Servern ihres Tenant laden und speichern aber das "Drumherum" von einem näher stehenden System erhalten sollen, dann müssen Sie aus Datenschutzfragen festlegen, welche Inhalte über das CDN bereitgestellt werden dürfen um dann die Konfiguration entsprechend anzugehen.

Hinweis:
Auch Microsoft Teams greift im Hintergrund natürlich auch SharePoint-Daten zu und profitiert dann auch von dieser Optimieren.

Für die eigentliche Konfiguration verweise ich auf die Microsoft Quellen.

Unterbau GeoDNS

Aus der Sicht des Netzwerks und der Verbindungen habe ich aber schon ein Interesse, der bereitgestellten Funktion etwas auf die Finger zu schauen. Zuerst habe ich ir die URLs aus der Konfigurationsanleitung etwas genauer angeschaut:

https://msxfaq.sharepoint.com/sites/site/library/asset.png
https://publiccdn.sharepointonline.com/msxfaq.sharepoint.com/sites/site/library/asset.png
https://privatecdn.sharepointonline.com/msxfaq.sharepoint.com/sites/site1/library1/folder1/image1.jpg

Die erste URL ist meine originäre SharePoint-URL, die zu den Servern verweist, die in der jeweiligen Data Region meine Daten bereitstellen. Davon abgeleitet gibt es dann aber die beiden Hostnamen für das "publiccdn" und das "privatecnd". Eine einfache erste DNS-Anfrage hat schon interessante Daten geliefert:

C:\>nslookup publiccdn.sharepointonline.com
Server:  fritz.box
Address:  fd00::2e91:abff:fe49:d7c9

Nicht autorisierende Antwort:
Name:    e1780.dscb.akamaiedge.net
Addresses:  2a02:26f0:10c:4aa::6f4
          2a02:26f0:10c:490::6f4
          104.96.7.136
Aliases:  publiccdn.sharepointonline.com
          publiccdn.sharepointonline.com.edgekey.net


C:\Users\fcarius>nslookup publiccdn.sharepointonline.com 114.114.114.114
Server:  public1.114dns.com
Address:  114.114.114.114

Nicht autorisierende Antwort:
Name:    e1780.dscb.akamaiedge.net
Addresses:  2600:1405:4000:38d::6f4
          2600:1405:4000:38c::6f4
          23.51.197.162
Aliases:  publiccdn.sharepointonline.com
          publiccdn.sharepointonline.com.edgekey.net

Je nach angefragtem DNS-Server habe ich unterschiedliche Antworten bekommen. Mein eigener DNS-Server lieferte einen Akamai-Services aber auch die Anfrage im asiatischen Raum (114.114.114.114) liefert Akamai als Betreiber.

Andere CDN-Anbieter habe ich bei meinem Tests noch nicht gesehen aber ich möchte nicht ausschließen, dass Microsoft auch andere Anbieter wie z.B. Cloudflare etc. nutzt.

Wie "relevant" eine richtige DNS-Auflösung ist, können Sie über einen Abruf der Default-Seite per HTTPS ermitteln. Es ist dabei unwichtig, ob der Server tatsächlich eine gültige Information liefert. Mir reicht für eine Latenzzeitmessung allein die Dauer zur Verbindungsaufnahme, TLS-Handshake und HTTP-Antwort.

(measure-command {Invoke-WebRequest https://104.96.7.136 -SkipCertificateCheck}).TotalMilliseconds
80,5324

(measure-command {Invoke-WebRequest https://23.51.197.162 -SkipCertificateCheck}).TotalMilliseconds
501,8121

Sie können hier gut sehen, dass der Zugriff auf die 23.51.197.162 deutlich länger braucht. Auch der Traceroute bestätigt die "Entfernung":

C:\>tracert 23.51.197.162

Routenverfolgung zu a23-51-197-162.deploy.static.akamaitechnologies.com [23.51.197.162] über maximal 30 Hops:

  1     2 ms     2 ms     1 ms  fritz.box [192.168.178.1]
  2     9 ms     8 ms     9 ms  100.124.1.57
  3     6 ms     4 ms     5 ms  100.127.1.133
  4     9 ms     9 ms     5 ms  100.127.1.131
  5    10 ms     8 ms    11 ms  185.22.46.129
  6     9 ms     8 ms    10 ms  et-1-0-18.edge6.Dusseldorf1.Level3.net [212.162.11.77]
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8    11 ms    12 ms    12 ms  ae0.mpr1.fra4.de.zip.zayo.com [64.125.12.125]
  9   123 ms     *        *     ae12.cs1.fra6.de.eth.zayo.com [64.125.26.172]
 10   110 ms   111 ms     *     ae2.cs1.ams17.nl.eth.zayo.com [64.125.29.59]
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16   123 ms   122 ms   119 ms  ae7.mpr2.msp1.us.zip.zayo.com [64.125.30.63]
 17   115 ms   109 ms   111 ms  208.184.33.42.IPYX-073920-001-ZYO.above.net [208.184.33.42]
 18   121 ms   121 ms   121 ms  a23-51-197-162.deploy.static.akamaitechnologies.com [23.51.197.162]

Zuerst geht es wieder über mein Carrier Grade NAT (100.64.0.0/10 Subnetz) aber dann über Düsseldorf, Frankfurt, Amsterdam und eine lange Strecke in die USA. Hier scheint also Microsoft in China selbst keinen CDN-Service anzubieten oder der DNS-Server 114.114.114.114 steht doch nicht in Asien.

Das bedeutet aber für Sie im Netzwerk, dass es auch hier wichtig ist, den Zugriff auf das CDN möglichst zu optimieren, damit es funktioniert. Im Grund bedeutet das wieder:

  • Lokaler Breakout/SplitVPN
    Sie sollten ihre Pakete nicht über ein VPN zur Firma senden oder innerhalb der Firma zur Zentrale, sondern möglichst den kurzen Weg zum CDN erlauben. Beachten Sie, dass die meisten IPv4-basierten Tunnel-VPNs durchaus IPV6 vorbei lassen. Nicht jeder Tunnel ist hier ein echter Tunnel.
  • Lokale DNS-Auflösung/SplitDNS
    Dann müssen Sie natürlich auch sicherstellen, dass die Namensauflösung den gleichen Weg geht. Die IP-Pakete lokal zum ISP zu routen ist nicht optimal, wenn der Client den Firmen-DNS-Server mit einem anderen ISP fragt.
  • Proxy Bypass (Office 365 und Proxy Server)
    Wenn Sie eine HTTP-Proxy im LAN oder auch einen Cloud-Proxy wie Zscaler nutzen, dann sollten Sie diese "Ehrenrunde" vielleicht umgehen.

Diese drei wesentlichen Punkte sind aber sowieso Grundprinzipien einer Cloud-Nutzung und sollten Sie daher nicht besonders überraschen.

Sie können meine Kollegen und mich gerne für ein Netzwerk Assessment konsultieren.

Leider hat Microsoft keine IP-Range veröffentlicht und aufgrund der 3rd Party DNS ist auch nicht garantiert, dass die IP-Adressen exklusiv für publiccdn" und "privatecnd" reserviert sind. Die meisten Desktop-Firewalls und Regeln erlauben nur das Routing anhand IP-Bereichen und nicht der aufgelösten Namen.

Weitere Links