VPS in Amsterdam: Was bei der Wahl zählt

Warum VPS-Hosting in Amsterdam?

VPS-Hosting in Amsterdam ist zunächst eine Netzwerkentscheidung. Amsterdam ist einer der wichtigsten Zusammenschaltungspunkte Europas. Dort treffen viele unabhängige Netzwerke aufeinander und übergeben den Netzwerkverkehr direkt aneinander. Ein Server in dieser Metropolregion erreicht das Vereinigte Königreich, die nordischen Länder, Deutschland, Frankreich und die Benelux-Länder meist über kurze Pfade mit wenigen dazwischengeschalteten Netzwerken.

Das ist das zentrale Argument. Im restlichen Leitfaden prüfen Sie, ob es für Ihre Benutzer zutrifft. Denn das ist nicht bei allen Benutzern der Fall. Amsterdam ist eine gute Standardwahl für eine über Nordwesteuropa verteilte Kundengruppe. Die Wahl ist weniger geeignet, wenn der größte Teil Ihres Netzwerkverkehrs aus Warsaw, Istanbul, São Paulo oder Toronto kommt. Gutes Peering in den Niederlanden verkürzt die Entfernung zu diesen Orten nicht.

Was ein Internetknoten tatsächlich ist

Ein Internet Exchange Point, kurz IXP, ist eine gemeinsame Switching-Infrastruktur. Unabhängige Netzwerke mieten dort einen Port, schließen sich einmal an und können anschließend Datenverkehr direkt mit den anderen Mitgliedern austauschen. In Amsterdam ist AMS-IX, der Amsterdam Internet Exchange, der bekannteste Anbieter. Er ist nicht der einzige Internetknoten der Stadt, und die Anzahl dieser Knoten ist für Sie nicht entscheidend.

Um zu verstehen, warum ein Internetknoten die Latenz verändert, müssen Sie die beiden Wege kennen, auf denen ein Paket zwischen Netzwerken übertragen wird. Der erste ist Transit: Sie bezahlen ein größeres Netzwerk dafür, Ihren Datenverkehr in das restliche Internet weiterzuleiten. Der zweite ist Peering: Zwei Netzwerke vereinbaren, Datenverkehr direkt untereinander auszutauschen, üblicherweise ohne dass Geld in eine der beiden Richtungen fließt. Jedes Netzwerk ist hier ein autonomes System, kurz AS: ein Netzwerk mit einer eigenen Nummer und einer eigenen Routing-Richtlinie.

Transitpfade werden ebenso stark durch Geschäftsbeziehungen wie durch die geografische Lage bestimmt. Ein Paket von einem Server in einer europäischen Stadt zu einem Breitbandkunden in einer anderen Stadt kann durchaus in eine dritte Stadt weitergeleitet werden, dort das Netzwerk wechseln und zurück übertragen werden. Das bedeutet nicht, dass etwas fehlerhaft ist. Die Route ergibt sich einfach aus den Geschäftsbeziehungen und der Routing-Richtlinie. An einem Internetknoten können die beiden Netzwerke das Paket stattdessen lokal übergeben. Dadurch ist der Pfad kürzer, weniger Netzwerke sind beteiligt und es gibt weniger Stellen, an denen Überlastung auftreten kann.

Dieser Teil wird häufig ausgelassen. Ein Internetknoten in der Stadt bindet Ihren VPS nicht automatisch daran an. Entscheidend ist das Netzwerk Ihres Providers: von welchen Transitprovidern er Kapazität einkauft, welchen Internetknoten er beitritt, ob er Peering mit den Consumer- und Mobilfunknetzen betreibt, hinter denen Ihre Benutzer sitzen, und wie viel Kapazität zu jedem dieser Netzwerke vorhanden ist. Zwei Server im selben Gebäude können beim Verlassen des Gebäudes sehr unterschiedliche Pfade verwenden. Fragen Sie den Provider nach seiner AS-Nummer und suchen Sie diese anschließend in PeeringDB, wo Netzwerke die Rechenzentren und Internetknoten veröffentlichen, an denen sie vertreten sind. Sie können AS-Nummern auch direkt aus einem aktiven Pfad ablesen. Der folgende Abschnitt zur Messung zeigt, wie das funktioniert.

Amsterdam oder Frankfurt: Entscheiden Sie anhand Ihrer Nutzer, nicht anhand der Karte

Das ist die tatsächliche Wahl, vor der die meisten Leser stehen. Beide Städte sind wichtige Knotenpunkte für die Zusammenschaltung von Netzwerken. In Frankfurt befindet sich DE-CIX. Die Stadt ist daher meist die erste Wahl für Mittel-, Ost- und Südosteuropa sowie für Verbindungen in Richtung Wien, Warschau, Prag und Nahost. Amsterdam eignet sich gut für das Vereinigte Königreich, Irland, Skandinavien und die Benelux-Länder sowie für Datenverkehr über die Unterseekabel, die in Nordwesteuropa an Land führen. Betrachten Sie diese Einordnung als Tendenz, nicht als Messwert. Das Routing ändert sich, Provider wechseln ihre Upstreams, und das Peering Ihres Providers ist spezifischer als jede Verallgemeinerung auf Stadtebene.

Entscheiden Sie daher anhand Ihrer eigenen Daten.

1. Notieren Sie, wo sich Ihre Nutzer tatsächlich befinden. Ihre Webserver-Access-Logs, Ihre Analysedaten oder Ihre Kundenliste enthalten diese Informationen bereits.
2. Gewichten Sie diese Liste nach einer relevanten Größe, beispielsweise Umsatz oder aktiven Konten, statt nach reinen Zugriffszahlen, die durch Bots zu hoch ausfallen können.
3. Mieten Sie in jeder infrage kommenden Stadt einen Monat lang den kleinsten Tarif und messen Sie von echten Nutzerverbindungen zu beiden Standorten.
4. Vergleichen Sie die von Ihnen erfassten Werte, nicht die Angaben auf einer Marketingseite.

Ein ehrlicher Vorbehalt, bevor Sie dafür eine Woche aufwenden. Bei einer Nutzerbasis in Westeuropa ist der Unterschied zwischen zwei gut angebundenen europäischen Metropolregionen oft kleiner als die Latenz, die Ihre eigene Anwendung verursacht. Eine Seite, die zehn Datenbankabfragen nacheinander ausführt, verursacht die Round-Trip-Zeit zehnmal. Das Abfragemuster kann daher mehr kosten als die Wahl der Stadt. Messen Sie auch die Anwendung. Dieselben Fragen aus der anderen Perspektive behandelt der Leitfaden zur Auswahl eines VPS in Frankfurt. Ausschlaggebend ist oft etwas Unscheinbares, etwa welcher Standort die benötigte Tarifgröße und den benötigten Speicherplatz bietet.

Wie messen Sie die Latenz nach Amsterdam selbst?

Führen Sie diese Befehle über den Anschluss aus, den Ihre Benutzer verwenden, oder so nah wie möglich daran. Eine Glasfaserverbindung im Büro ist kein Ersatz für eine Mobilfunkverbindung in Manchester.

Installieren Sie die Tools unter Debian oder Ubuntu zuerst.

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

Beginnen Sie mit einer Messung der Round-Trip-Anzahl.

ping -c 20 ams.example.com

Die Zusammenfassung am Ende ist mit rtt min/avg/max/mdev gekennzeichnet. Der Wert avg ist die typische Round-Trip-Zeit in Millisekunden. mdev gibt an, wie stark dieser Wert schwankt. Das ist der Jitter. Lesen Sie den Prozentsatz für Paketverluste im selben Block ab. Paketverluste am Ziel sind ein echtes Problem. Paketverluste an einem mittleren Hop sind normalerweise unproblematisch, wenn alle nachfolgenden Hops saubere Werte liefern. Router behandeln Antworten auf Pakete, die an sie selbst adressiert sind, häufig mit niedriger Priorität.

Sehen Sie sich anschließend den Pfad selbst an.

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

Jede Zeile steht für einen Hop. --aslookup gibt die AS-Nummer aus. Dadurch sehen Sie, welche Netzwerke das Paket durchquert und an welcher Stelle es den Zuständigkeitsbereich Ihres Providers verlässt. Suchen Sie den Hop, an dem die Round-Trip-Zeit ansteigt und bei allen nachfolgenden Hops hoch bleibt. Dort wird die Verzögerung verursacht. Wenn mtr beendet wird, weil es keinen Raw Socket öffnen kann, führen Sie es mit sudo aus. Manche Netzwerke behandeln ICMP mit niedriger Priorität oder verwerfen ICMP-Pakete. Messen Sie deshalb auch die Verbindungsart Ihrer Benutzer, also TCP zum Port, den Sie bereitstellen.

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

Trennen Sie anschließend das Netzwerk vom Server.

curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://ams.example.com/

Jeder Wert gibt die seit dem Start der Anfrage verstrichenen Sekunden an. Sie lesen daher die Abstände zwischen den Werten ab. connect minus dns entspricht ungefähr einer Round-Trip-Zeit, also dem TCP-Handshake. tls minus connect ist der TLS-Handshake (Transport Layer Security). Dieser erfordert weitere Round-Trips und nimmt mit wachsender Entfernung schneller zu als jeder andere Wert in dieser Zeile. ttfb minus tls ist größtenteils die Verarbeitungszeit des Servers. Diese Aufteilung zeigt, warum curl für eine Kaufentscheidung besser geeignet ist als ping. Eine hohe Gesamtdauer mit einem kleinen Abstand ttfb bedeutet, dass der Server weit entfernt ist. Ein großer Abstand ttfb bei einer schnellen Verbindung bedeutet, dass der Server nahe ist und die Anwendung langsam reagiert.

Die Latenz ändert sich auch im Tagesverlauf, weil sich die Netzwerkauslastung ändert. Messen Sie über den ganzen Tag hinweg, statt einer einzelnen Messung zu vertrauen.

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

Das Netzwerk ist nur eine Hälfte der Kaufentscheidung. Datenträger und CPU bilden die andere Hälfte. Ein gut platzierter Server auf einem überlasteten Node reagiert trotzdem langsam. Führen Sie daher vor einer Vertragsbindung für ein Jahr einen aussagekräftigen VPS-Benchmark mit dem Testtarif durch.

EU-Datenresidenz in einfachen Worten

Datenresidenz bezeichnet den physischen Ort, an dem Daten gespeichert und verarbeitet werden. Die Niederlande gehören zur Europäischen Union und zum Europäischen Wirtschaftsraum. Ein Server in Amsterdam hält Ihre Daten daher auf einer EU-Infrastruktur. Damit ist eine Standortfrage geklärt. Der Standort ist jedoch nur ein Faktor bei der Bewertung der Compliance.

Die DSGVO (Datenschutz-Grundverordnung) verbietet nicht, dass personenbezogene Daten die EU verlassen. Sie legt Bedingungen für solche Übermittlungen fest. Diese Bedingungen gelten außerdem für andere Unternehmen, die Daten in Ihrem Auftrag verarbeiten. Die entscheidende Frage lautet daher nicht: „Steht der Server in der EU?“ Sie lautet: „Wo landet jede Kopie dieser Daten?“

An diesem Punkt scheitert eine Aussage zur Datenresidenz häufig. Der VPS steht in Amsterdam, und die Datenbank läuft darauf. Die Backups werden anschließend in einen Object Storage in einer anderen Region übertragen, die Anwendungslogs an einen gehosteten Suchdienst gestreamt, Fehlerdaten an einen Monitoring-Anbieter gesendet, Transaktions-E-Mails über einen Drittanbieter verschickt und BenutzertText zur Zusammenfassung an eine API übermittelt. Jede dieser Aktionen bewegt personenbezogene Daten an einen anderen Ort. Eine Standortanforderung gilt für alle diese Datenflüsse und nicht nur für die Maschine, die Sie bewusst ausgewählt haben.

Trennen Sie die beiden Beweggründe voneinander, da sie zu unterschiedlichen Designs führen. Wenn ein Vertrag, eine Aufsichtsbehörde oder ein Kunde eine EU-Infrastruktur verlangt, handelt es sich um eine Compliance-Anforderung. Sie ist dokumentiert und kann Sie dazu zwingen, innerhalb einer Region zu bleiben. Wenn Sie den Server nahe bei Ihren Benutzern betreiben möchten, damit Seiten schneller geladen werden, handelt es sich um eine Latenzanforderung. Sie kann dazu führen, dass Sie weitere Regionen hinzufügen. Compliance-Begriffe zur Begründung einer Performance-Entscheidung zu verwenden, erschwert später die Beantwortung beider Fragen.

Fragen Sie den Anbieter, wer auf die Maschine zugreifen kann, wo sich die Supportmitarbeiter befinden, welchem Recht das Unternehmen unterliegt und ob ein Unterauftragsverarbeiter außerhalb des EWR tätig ist. Lassen Sie sich die Antwort in einer Vereinbarung zur Auftragsverarbeitung geben. Ein unterzeichnetes Dokument verlangt ein Auditor, ein Support-Ticket reicht dafür nicht aus. Die vollständige Methode aus dem für kanadische Daten verfassten Residenz-Framework lässt sich direkt übertragen: Listen Sie die Daten auf, erfassen Sie jeden Verarbeiter, der damit in Berührung kommt, dokumentieren Sie die einzuhaltende Regel und wählen Sie den Standort erst zuletzt. Dies beschreibt die zu stellenden Fragen und stellt keine Rechtsberatung dar.

Was die Wahl von Amsterdam nicht behebt

• Die Entfernung zu allen anderen. Signale übertragen sich in Glasfasern mit ungefähr zwei Dritteln der Lichtgeschwindigkeit im Vakuum. Die Kabelroute ist immer länger als die direkte Strecke. Ein Benutzer in Singapur bezahlt daher unabhängig von der gewählten europäischen Stadt für die Entfernung.
• Eine chatty Anwendung. Jede Anfrage, die auf die vorherige wartet, verursacht erneut die Round-Trip-Zeit.
• Das Risiko einer einzelnen Region. Ein VPS in einer Stadt ist eine einzelne Fehlerdomäne. Gutes Peering schützt Sie nicht davor, versehentlich das falsche Volume zu löschen.
• Überbelegte Hardware. Ein ausgelasteter Node in einer gut angebundenen Stadt bleibt ein ausgelasteter Node.

Was ist, wenn sich meine Benutzer auf mehr als einem Kontinent befinden

Die Regel ist einfach: Platzieren Sie den Server an dem Point of Presence, der Ihren Benutzern am nächsten liegt. Wenn Ihre Benutzer auf mehrere Kontinente verteilt sind, führt ein Standort in der Mitte für beide Gruppen zu einer langsamen Nutzung, weil keine der beiden Gruppen in seiner Nähe ist.

Es gibt zwei praktikable Lösungen. Legen Sie alle cachebaren Inhalte hinter ein CDN (Content Delivery Network), sodass der Origin-Server in Amsterdam bleibt, während Bilder, Stylesheets, Skripte und gecachte Seiten von einem Node in der Nähe des jeweiligen Benutzers ausgeliefert werden. Oder betreiben Sie einen zweiten Server in der anderen Region und lösen Sie das Datenproblem gezielt, etwa mit Read Replicas oder mit einer Replikation, deren Verzögerung Sie gemessen und dokumentiert haben. Beide Lösungen kosten mehr als ein einzelner Server. Das ist der realistische Preis für eine verteilte Benutzergruppe.

Wenn ein großer Teil Ihres Datenverkehrs aus Nordamerika kommt, wird ein VPS in Toronto diese Benutzer besser bedienen als jede europäische Stadt. Für Benutzer in Südamerika vermeidet ein in Brasilien gehosteter VPS bei jeder Anfrage einen transatlantischen Round Trip. Amsterdam ist die richtige Wahl, wenn sich Ihre Benutzer in Europa befinden, vor allem in Nord- und Westeuropa. Das ist eine konkrete Aussage. Mit den obigen Befehlen können Sie sie anhand Ihres eigenen Datenverkehrs überprüfen.

FAQ

Ist ein VPS in Amsterdam schneller als einer in Frankfurt?

Für Ihre Benutzer möglicherweise. Beide Städte sind wichtige Internetknoten. Der Unterschied hängt daher davon ab, wo Ihre Benutzer sitzen und mit welchen Netzwerken die einzelnen Anbieter Peering-Verbindungen unterhalten, nicht vom Namen der Stadt. Amsterdam eignet sich tendenziell für das Vereinigte Königreich, Irland, Skandinavien und die Benelux-Staaten. Frankfurt eignet sich tendenziell für Mittel- und Osteuropa. Mieten Sie in beiden Städten den kleinsten Monatstarif. Führen Sie anschließend eine Woche lang von realen Benutzerverbindungen aus mtr --report --aslookup und einen curl -w-Lauf zur Zeitmessung durch, bevor Sie sich entscheiden.

Macht Hosting in Amsterdam meinen Dienst DSGVO-konform?

Nein. Dadurch liegen die Daten auf einer Infrastruktur in der EU. Damit ist eine von mehreren Fragen beantwortet. Die Compliance umfasst außerdem Ihre Rechtsgrundlage, Ihre Auftragsverarbeiter, Ihre Backups, Ihre Logs und jeden Drittanbieterdienst, an den Sie personenbezogene Daten übertragen. Ein Server in Amsterdam, der Fehlerprotokolle an einen Anbieter außerhalb des EWR überträgt, hat diese Daten trotzdem aus dem EWR heraus bewegt. Der Standort ist der einfache Teil. Dort hören viele jedoch auf.

Was ist AMS-IX, und wirkt sich das auf meinen VPS aus?

AMS-IX ist der Amsterdam Internet Exchange. Dabei handelt es sich um eine gemeinsam genutzte Switching-Infrastruktur, über die sich unabhängige Netzwerke verbinden und den Netzwerkverkehr direkt untereinander übertragen. Dadurch müssen sie keinen Transitprovider dafür bezahlen, den Verkehr zwischen ihnen zu übertragen. Ihren VPS erreicht der Austauschpunkt nur über Ihren Provider. Ein Internetknoten in der Stadt ist für Sie hilfreich, wenn Ihr Provider dort vertreten ist und Peering mit den Netzwerken unterhält, die Ihre Benutzer verwenden. Fragen Sie nach der AS-Nummer des Providers. Prüfen Sie anschließend auf PeeringDB, mit welchen Netzwerken diese Nummer Peering-Verbindungen unterhält.

Wie teste ich das Netzwerk zu einem VPS, bevor ich für ein Jahr bezahle?

Buchen Sie zunächst den kleinsten Monatstarif. Führen Sie ping -c 20 für Round-Trip-Zeit und Paketverlust aus. Verwenden Sie anschließend mtr --report --report-wide --aslookup --report-cycles 100, um zu sehen, welche Netzwerke der Pfad durchquert. Führen Sie danach einen curl -w-Lauf gegen eine echte Seite über HTTPS aus, um die Entfernung von der Servergeschwindigkeit zu unterscheiden. Wiederholen Sie den Test zu verschiedenen Uhrzeiten, da die Auslastung im Tagesverlauf variiert. Führen Sie ihn außerdem über die Verbindungen Ihrer Benutzer aus und nicht nur über die Verbindung Ihres Büros. Bewahren Sie das Log auf. So vergleichen Sie aufgezeichnete Werte statt eines bloßen Eindrucks.