Hosting VPS we Frankfurcie: czy warto wybrać tę

Dla kogo jest hosting VPS we Frankfurcie

Hosting VPS we Frankfurcie jest odpowiedni dla projektów, których użytkownicy znajdują się w Niemczech, na szerszym rynku niemieckojęzycznym lub na terenie całej Unii Europejskiej. Frankfurt jest jednym z głównych punktów styku europejskich sieci, w których ruch jest przekazywany bezpośrednio między operatorami. Dzięki temu serwer zlokalizowany w tym miejscu osiąga większość kontynentu w czasie kilkudziesięciu milisekund. Jeśli użytkownicy znajdują się głównie w Ameryce Północnej, serwer europejski będzie dla nich odczuwalnie wolny, niezależnie od wydajności samej maszyny. Dystans wyznacza minimalne opóźnienie, którego nie da się wyeliminować poprzez optymalizację.

O wyborze lokalizacji decydują dwie odrębne kwestie, a ich mylenie prowadzi do błędnych decyzji. Pierwszą jest lokalizacja użytkowników, co wiąże się z dystansem i czasem odpowiedzi (round-trip time). Drugą jest miejsce, w którym dane mogą być przechowywane, co stanowi kwestię prawną i kontraktową. Frankfurt stanowi solidne rozwiązanie pierwszej kwestii w przypadku odbiorców europejskich. W odniesieniu do drugiej kwestii, lokalizacja ta rozwiązuje jeden konkretny problem, nie przesądzając o pozostałych aspektach prawnych.

Dlaczego Frankfurt jest tak dobrze skomunikowany?

Frankfurt jest siedzibą DE-CIX (Deutsche Commercial Internet Exchange), czyli punktu wymiany ruchu (IXP – internet exchange point), który pod względem szczytowego natężenia ruchu oraz liczby podłączonych sieci należy do największych na świecie. IXP to współdzielona infrastruktura przełączająca wewnątrz centrum danych, gdzie niezależne sieci łączą się ze sobą bezpośrednio, zamiast płacić większym operatorom za przesyłanie ruchu między nimi. DE-CIX publikuje aktualne statystyki ruchu na swojej stronie internetowej, a ponieważ liczby te ulegają zmianom, należy sprawdzać je bezpośrednio u źródła, zamiast polegać na danych skopiowanych do artykułu.

Praktyczny skutek dotyczy ścieżek, a nie sumarycznych wartości. Gdy sieć Twojego dostawcy oraz ISP (internet service provider) użytkownika łączą się w tym samym punkcie wymiany, ruch między nimi pokonuje tylko jeden przeskok (hop) w tym punkcie. Gdy sieci nie wymieniają ruchu lokalnie, dane muszą dotrzeć do trzeciej sieci, która łączy obie strony, a najbliższy punkt przekazania może znajdować się w innym kraju. Dwie niemieckie sieci wymieniające ruch przez Amsterdam lub Londyn płacą za dodatkowy dystans dwukrotnie, w każdym kierunku. Inżynierowie sieciowi nazywają to zjawisko "tromboningiem" i jest to najczęstsza przyczyna, dla której serwer znajdujący się w pobliżu wykazuje duże opóźnienia.

Można to zweryfikować, zamiast zakładać. Uruchom mtr w kierunku swojego serwera z sieci, która Cię interesuje, i odczytaj nazwy przeskoków w odwrotnym DNS. Nazwy hostów routerów zazwyczaj zawierają kody lotnisk IATA, więc fra w nazwie przeskoku oznacza Frankfurt, ams oznacza Amsterdam, a lhr oznacza Londyn. Ścieżka z niemieckiego łącza konsumenckiego do niemieckiego serwera, która w środku wykazuje lhr, wskazuje dokładnie, gdzie zniknęły dodatkowe milisekundy.

Jak daleko od użytkowników znajduje się Frankfurt?

Światło w światłowodzie porusza się z prędkością wynoszącą około dwie trzecie prędkości w próżni, czyli blisko 200 000 kilometrów na sekundę. Pełny cykl komunikacji (round trip) obejmuje tę drogę dwukrotnie, zatem najkrótszy możliwy czas dla dystansu d kilometrów wynosi d/100 milisekund. Jest to wartość graniczna, przydatna, ponieważ nic nie może jej przekroczyć.

[
  {
    "label": "Zurich",
    "distance_km": 304,
    "min_rtt_ms": 3.0
  },
  {
    "label": "Amsterdam",
    "distance_km": 365,
    "min_rtt_ms": 3.7
  },
  {
    "label": "Berlin",
    "distance_km": 424,
    "min_rtt_ms": 4.2
  },
  {
    "label": "Paris",
    "distance_km": 479,
    "min_rtt_ms": 4.8
  },
  {
    "label": "Milan",
    "distance_km": 519,
    "min_rtt_ms": 5.2
  },
  {
    "label": "Vienna",
    "distance_km": 600,
    "min_rtt_ms": 6.0
  },
  {
    "label": "London",
    "distance_km": 640,
    "min_rtt_ms": 6.4
  },
  {
    "label": "Warsaw",
    "distance_km": 903,
    "min_rtt_ms": 9.0
  },
  {
    "label": "Stockholm",
    "distance_km": "1,197",
    "min_rtt_ms": 12.0
  },
  {
    "label": "Madrid",
    "distance_km": "1,419",
    "min_rtt_ms": 14.2
  },
  {
    "label": "New York",
    "distance_km": "6,206",
    "min_rtt_ms": 62.1
  }
]

Wartości te obliczono na podstawie odległości w linii prostej, a nie pomiarów. Ostatnią kolumnę należy traktować jako najlepszy możliwy wynik dopuszczalny przez prawa fizyki. Rzeczywiste pomiary zazwyczaj mieszczą się w przedziale od 1,5 do 2 razy powyżej tej granicy, ponieważ światłowody biegną wzdłuż dróg i dolin rzek, a nie po łukach wielkich kół, a każdy router na trasie dodaje niewielkie opóźnienie związane z przekazywaniem i kolejkowaniem pakietów.

Berlin znajduje się w odległości 424 km od Frankfurtu, co daje granicę 4.2 ms. Madryt jest oddalony o 1,419 km, co daje granicę 14.2 ms i stanowi najdalszy zakątek UE z tej lokalizacji. Nowy Jork znajduje się w odległości 6,206 km z granicą 62.1 ms, dlatego obsługa odbiorców transatlantyckich jest decyzją dotyczącą lokalizacji, a nie problemem optymalizacji.

Jaki jest koszt powolnego czasu obiegu (RTT) dla ładowania strony?

Jeden obieg (round trip) rzadko oznacza faktycznie jeden obieg. Nawiązanie połączenia HTTPS kosztuje jeden obieg na uzgodnienie TCP (transmission control protocol) oraz kolejny na uzgodnienie TLS (transport layer security) 1.3. Żądanie generuje trzeci obieg, zanim dotrze pierwszy bajt odpowiedzi. TLS 1.2 dodaje czwarty. Wyszukanie DNS (domain name system), które nie znajduje się w pamięci podręcznej, dodaje co najmniej jeden kolejny obieg do innego serwera.

[
  {
    "label": "User in Frankfurt",
    "rtt_ms": 5,
    "first_byte_ms": 15
  },
  {
    "label": "User in Warsaw",
    "rtt_ms": 20,
    "first_byte_ms": 60
  },
  {
    "label": "User in Madrid",
    "rtt_ms": 30,
    "first_byte_ms": 90
  },
  {
    "label": "User in New York",
    "rtt_ms": 90,
    "first_byte_ms": 270
  },
  {
    "label": "User in Singapore",
    "rtt_ms": 170,
    "first_byte_ms": 510
  }
]

Kolumna z czasem obiegu stanowi założenie dotyczące prawdopodobnej ścieżki do serwera we Frankfurcie, a druga kolumna przedstawia wynik obliczeń: trzy obiegi przed otrzymaniem pierwszego bajtu. Użytkownik we Frankfurcie czeka 15 ms. Użytkownik w Singapurze, przy czasie obiegu wynoszącym 170 ms, czeka 510 ms na tę samą odpowiedź, zanim przeglądarka cokolwiek wyrenderuje.

Kluczowy jest mnożnik. Każda dodatkowa milisekunda RTT (round-trip time) kosztuje około trzech milisekund przed otrzymaniem pierwszego bajtu, a koszty te narastają. Kod HTML wskazuje arkusz stylów, arkusz stylów wskazuje czcionkę, a każde z tych odkryć to kolejny obieg w ramach tego samego połączenia. Dodanie kilkuset milisekund dystansu sprawia, że strona, która wydawała się błyskawiczna, zaczyna działać wolno, mimo że serwer wykonuje dokładnie tę samą pracę w tym samym czasie.

Wyznacza to również granice możliwości CDN (content delivery network). Pliki statyczne serwowane z pamięci podręcznej blisko użytkownika omijają długą ścieżkę. Zalogowany pulpit nawigacyjny, który musi odpytać bazę danych, nie korzysta z tego: takie żądanie nadal dwukrotnie pokonuje cały dystans. Umieszczenie serwera źródłowego (origin) blisko użytkowników, którzy się logują, jest elementem, którego żadna pamięć podręczna nie zrealizuje automatycznie.

Jak zmierzyć te parametry z lokalizacji użytkowników?

Uruchom poniższe polecenia z maszyny znajdującej się w sieci, która Cię interesuje – najlepiej z łącza domowego lub biurowego w kraju, który obsługujesz. Pomiary z innego serwera w innym centrum danych informują o ścieżkach między centrami danych, a nie o doświadczeniach użytkowników. Poniższe polecenia to przykłady do samodzielnego wykonania: jedyne wartości opóźnień, na podstawie których warto podejmować działania, to te, które zmierzysz samodzielnie.

ping -c 20 your-server.example.com

Wiersz podsumowania zawiera rtt min/avg/max/mdev = .... Odczytaj avg dla typowego przypadku oraz mdev dla jittera, czyli zmienności czasu dostarczenia pakietów. Normalny wynik avg przy wysokim mdev oznacza, że ścieżka jest niestabilna, co bardziej szkodzi pracy interaktywnej, takiej jak SSH czy komunikacja głosowa, niż nieco wyższa średnia wartość opóźnienia.

sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com

-r generuje raport zamiast wyświetlania danych w czasie rzeczywistym, -w zachowuje pełne nazwy hostów, -z pokazuje numer AS (autonomicznego systemu) dla każdego przeskoku, a -c 50 wysyła pięćdziesiąt cykli. Utrata pakietów widoczna na jednym środkowym przeskoku, przy braku utraty na ostatnim, jest zjawiskiem normalnym i nie stanowi błędu: wiele routerów ogranicza szybkość odpowiedzi ICMP generowanych dla własnych potrzeb, podczas gdy prawidłowo przekazuje pozostały ruch. Utrata, która zaczyna się na danym przeskoku i utrzymuje się na wszystkich kolejnych, jest rzeczywistą utratą pakietów.

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/

Każde pole to skumulowana liczba sekund od rozpoczęcia żądania, dlatego należy je odczytywać poprzez odejmowanie. time_namelookup to czas DNS. time_connect pomniejszone o tę wartość to czas uzgadniania TCP, zbliżony do jednego pełnego cyklu (round trip). time_appconnect minus time_connect to czas uzgadniania TLS. time_starttransfer minus time_appconnect to czas przetwarzania przez aplikację powiększony o jeszcze jeden cykl. Jeśli różnice są niewielkie, a total nadal jest duże, problem leży w kodzie aplikacji, a nie w lokalizacji geograficznej.

Aby zmierzyć przepustowość zamiast opóźnień, uruchom iperf3 -s na serwerze VPS, otwórz odpowiedni port na firewallu i uruchom iperf3 -c your-server.example.com -R po stronie klienta, aby przetestować kierunek pobierania. Aby dokonać pomiarów z miejsc, w których nie masz dostępu do maszyny, skorzystaj z RIPE Atlas, który udostępnia sondy na terenie całej Europy. Porównując dwa serwery zamiast dwóch sieci, stosuj stałą metodologię zamiast jednorazowych pomiarów; do tego celu służy powtarzalny benchmark VPS.

Czy serwer we Frankfurcie zapewnia zgodność projektu z RODO?

Nie, a powód warto sformułować precyzyjnie. RODO (Ogólne rozporządzenie o ochronie danych) ma zastosowanie w oparciu o to, czyje dane osobowe są przetwarzane oraz gdzie zarejestrowana jest organizacja, a nie o kraj, w którym znajduje się sprzęt. Przeniesienie serwera do Frankfurtu nie zapewnia zgodności, a korzystanie z serwera poza UE nie powoduje jej automatycznego naruszenia. Lokalizacja jest tylko jednym z wielu czynników.

Hostowanie wewnątrz UE lub szerzej w EOG (Europejskim Obszarze Gospodarczym) eliminuje kwestię transferu międzynarodowego. Rozporządzenie zawiera cały rozdział dotyczący przesyłania danych osobowych poza EOG, co wymaga instrumentu prawnego, takiego jak decyzja stwierdzająca odpowiedni stopień ochrony lub standardowe klauzule umowne. Dane pozostające we Frankfurcie nie są transferowane, więc ten rozdział nie ma zastosowania do tego etapu. Jest to rzeczywiste uproszczenie i stanowi jedyną realną korzyść.

Cała reszta pozostaje po stronie administratora. Nadal wymagana jest podstawa prawna dla każdego celu przetwarzania, zapewnienie osobom z bazy danych prawa dostępu i usunięcia danych, limit retencji, który jest faktycznie egzekwowany, środki bezpieczeństwa adekwatne do ryzyka oraz zgłoszenie do organu nadzorczego w ciągu 72 godzin od wykrycia naruszenia ochrony danych osobowych. Niezbędna jest również umowa powierzenia przetwarzania danych z dostawcą hostingu, w Niemczech znana jako Auftragsverarbeitungsvertrag lub AVV. Należy również pamiętać, że serwer we Frankfurcie może nadal wiązać się z transferem, jeśli personel wsparcia technicznego spoza EOG ma do niego dostęp, dlatego należy sprawdzić, kto posiada klucze dostępowe.

Niemcy dodają własną warstwę przepisów: federalna ustawa BDSG (Bundesdatenschutzgesetz) uzupełnia rozporządzenie o przepisy krajowe, a dane pracowników są obszarem, który najczęściej zaskakuje. Ta sekcja stanowi ogólne tło, a nie poradę prawną. Europejska Rada Ochrony Danych publikuje oficjalne wytyczne pod adresem edpb.europa.eu, a każda sprawa niosąca realne konsekwencje wymaga konsultacji z wykwalifikowanym doradcą, a nie korzystania z samouczka.

Co należy zmienić bezpośrednio na serwerze?

Utrzymuj czas systemowy w formacie UTC (Coordinated Universal Time) i formatuj znaczniki czasu wewnątrz aplikacji. W Niemczech obowiązuje czas letni, więc czas lokalny zmienia się o godzinę dwa razy w roku, a jedna godzina pod koniec października powtarza się. Dzienniki zapisane w czasie lokalnym zawierają dwa wpisy o godzinie 02:30 tej nocy, co czyni korelację zdarzeń między regionami zgadywaniem. Jeśli mimo to wymagany jest czas lokalny na serwerze, ustaw go jawnie i zweryfikuj:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Wynik powinien wskazywać Time zone: Europe/Berlin (CEST, +0200) latem oraz +0100 zimą.

Tekst w języku niemieckim sortuje się nieprawidłowo przy domyślnym ustawieniu locale C, ponieważ sortowanie C porównuje surowe bajty. Wygeneruj locale i sprawdź różnicę:

sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort

Pierwsze sortowanie umieszcza Äpfel po Zebra, ponieważ jego pierwszy bajt w kodowaniu UTF-8 ma wyższą wartość niż jakakolwiek litera ASCII. Drugie sortowanie umieszcza go obok Apfel, zgodnie z oczekiwaniami użytkownika języka niemieckiego. Ma to większe znaczenie, niż się wydaje, ponieważ PostgreSQL i MySQL ustalają kolację (collation) w momencie tworzenia bazy danych, a jej późniejsza zmiana wymaga przebudowania indeksów. Decyzję należy podjąć przed załadowaniem danych.

Niemieckie serwery lustrzane (mirrory) pakietów skracają czas apt. W systemie Ubuntu 24.04 źródła znajdują się w /etc/apt/sources.list.d/ubuntu.sources w formacie deb822, dlatego należy zmienić linię URIs: na http://de.archive.ubuntu.com/ubuntu/, zamiast dodawać drugi plik. Dodanie kolejnego pliku spowoduje Target Packages ... is configured multiple times, co prowadzi do błędu duplikacji źródeł deb822 i wstrzymuje aktualizacje do czasu rozwiązania problemu.

Opublikuj rekord AAAA. Niektórzy niemieccy dostawcy usług internetowych (ISP) oferują klientom indywidualnym połączenia typu DS-Lite (Dual-Stack Lite), w których klient nie posiada publicznego adresu IPv4, a jego ruch IPv4 przechodzi przez bramę translacyjną operatora. Brama ta zwiększa opóźnienia i ulega przeciążeniom w godzinach szczytu, podczas gdy ruch IPv6 jest przesyłany bezpośrednio. Sprawdź obie ścieżki po ustawieniu rekordu:

dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/

Wynik 200 z drugiego polecenia oznacza, że IPv6 działa poprawnie w modelu end-to-end. Could not resolve host lub błąd połączenia oznacza brak rekordu lub brak nasłuchiwania na porcie, co powoduje, że użytkownicy DS-Lite korzystają z wolniejszego połączenia.

Kiedy Frankfurt jest niewłaściwym wyborem

• Użytkownicy znajdują się w Stanach Zjednoczonych. Należy obsługiwać ich z tego regionu: VPS w Dallas znajduje się blisko centrum kraju, a hosting VPS w Nowym Jorku zapewnia krótszą ścieżkę dla wschodniego wybrzeża oraz ruchu transatlantyckiego.
• Użytkownicy znajdują się w Ameryce Łacińskiej. Frankfurt jest położony dalej od São Paulo niż Nowy Jork, dlatego VPS w Brazylii jest właściwym rozwiązaniem dla tej grupy odbiorców.
• Dane muszą pozostać w konkretnym kraju poza UE. Częstym przypadkiem jest praca dla sektora publicznego w Kanadzie, a artykuł co jest istotne przy hostingu VPS w Kanadzie omawia kwestie rezydencji danych.
• Uruchamiany jest serwer gier. Gracze odczuwają każdą milisekundę czasu odpowiedzi (RTT), dlatego bliskość serwera jest ważniejsza niż jakakolwiek inna specyfikacja: wybór VPS pod serwery gier szczegółowo to wyjaśnia.

Dla europejskich odbiorców rozproszonych w wielu krajach Frankfurt jest bezpiecznym, uniwersalnym wyborem. Pozostaje on optymalny wraz ze wzrostem skali, ponieważ niezbędne sieci są już dostępne w punkcie wymiany ruchu. Przed migracją i po niej należy wykonać pomiary z lokalizacji użytkowników i zachować oba zestawy danych.

FAQ

Czy jeden VPS we Frankfurcie wystarczy dla całej Europy?

Dla większości projektów tak. Odległość w linii prostej wyznacza dolną granicę 12.0 ms dla Sztokholmu i 14.2 ms dla Madrytu, a rzeczywiste trasy są zazwyczaj od 1,5 do 2 razy dłuższe, więc niemal cała UE pozostaje w zasięgu kilkudziesięciu milisekund od jednego serwera we Frankfurcie. Drugą lokalizację warto dodać dopiero po odnotowaniu rzeczywistych skarg z konkretnego kraju lub w przypadku potrzeby zapewnienia wysokiej dostępności (failover), a nie tylko szybkości.

Czy hosting we Frankfurcie zapewnia zgodność mojego projektu z RODO?

Nie. RODO ma zastosowanie w zależności od tego, czyje dane osobowe przetwarzasz i gdzie masz siedzibę, a nie od lokalizacji serwera. Hosting w UE eliminuje kwestię transferu międzynarodowego dla tego konkretnego przeskoku, co stanowi realne uproszczenie i jedyną korzyść. Nadal wymagana jest podstawa prawna, obsługa praw osób, których dane dotyczą, ograniczenie przechowywania, środki bezpieczeństwa, zgłaszanie naruszeń w ciągu 72 godzin oraz umowa powierzenia przetwarzania danych z dostawcą (w Niemczech znana jako AVV). Jest to informacja ogólna, a nie porada prawna.

Jakich opóźnień należy się spodziewać między Frankfurtem a Berlinem?

Oba miasta dzieli 424 km, co wyznacza sztywną dolną granicę 4.2 ms czasu podróży w obie strony (RTT). Dobrze połączona trasa zazwyczaj osiąga od 1,5 do 2 razy tę wartość. Potwierdź to za pomocą ping -c 20 your-server.example.com z połączenia w Berlinie i odczytaj wartość avg w linii rtt min/avg/max/mdev. Wynik znacznie wyższy od tego zakresu zazwyczaj oznacza, że ruch opuścił Niemcy i wrócił, co mtr -rwzc 50 pokaże w nazwach przeskoków.

Czy powinienem ustawić strefę czasową serwera we Frankfurcie na Europe/Berlin?

Zazwyczaj nie. Utrzymuj system w czasie UTC, aby logi pozostały porównywalne, a znaczniki czasu nie były niejednoznaczne. Niemcy przechodzą na czas letni (CEST) wiosną i wracają do czasu zimowego (CET) jesienią; w noc jesienną jedna godzina lokalna występuje dwukrotnie, więc dwa różne zdarzenia mogą otrzymać ten sam lokalny znacznik czasu. Formatuj czas w strefie lokalnej wewnątrz aplikacji, gdzie masz odpowiedni kontekst, aby zrobić to poprawnie. Jeśli mimo to chcesz ustawić czas lokalny dla całego systemu, wykonaj sudo timedatectl set-timezone Europe/Berlin i zweryfikuj za pomocą timedatectl.

Czy serwer obsługujący tylko IPv4 będzie problemem dla niemieckich użytkowników?

Będzie działał, ale dla części z nich będzie wolniejszy. Wielu niemieckich dostawców usług internetowych (ISP) oferuje połączenia konsumenckie w trybie DS-Lite bez publicznego adresu IPv4, więc klienci ci docierają do serwera IPv4 przez bramę translacyjną operatora, co zwiększa opóźnienia i powoduje zatory w godzinach szczytu. Opublikowanie rekordu AAAA i nasłuchiwanie na IPv6 zapewnia im bezpośrednią ścieżkę. Przetestuj to za pomocą dig AAAA your-server.example.com +short oraz żądania curl -6 i oczekuj odpowiedzi HTTP 200 dla obu rodzin adresów.