Hosting VPS w Kanadzie: czy lokalizacja ma znaczenie?

Czy VPS musi znajdować się w Kanadzie?

Hosting VPS w Kanadzie warto wybrać, gdy prawo lub umowa wymagają przechowywania danych na terytorium Kanady. Jest to jedyny twardy powód. Czas odpowiedzi (RTT) z domowego łącza w Toronto do centrum danych w Nowym Jorku wynosi około 18 ms, w porównaniu do około 3 ms w przypadku serwera w Toronto, a niemal żadna aplikacja internetowa nie jest w stanie odczuć tej różnicy.

Trzy czynniki skłaniają użytkowników ku serwerom kanadyjskim. Rezydencja danych jest obowiązkiem prawnym, więc kwestia ta rozstrzyga się sama. Opóźnienie jest mierzalne i zazwyczaj mniejsze, niż oczekują użytkownicy. Rozliczenia w dolarach kanadyjskich stanowią udogodnienie dla księgowości. Przed podjęciem decyzji o zakupie należy ustalić, czy pierwszy z wymienionych punktów dotyczy Twojej sytuacji.

Niniejszy wpis wyjaśnia ogólne zasady działania. Nie stanowi on porady prawnej. Jeśli Twoją organizację wiążą przepisy o ochronie prywatności, wiążącej odpowiedzi udzieli Twój radca prawny.

Rezydencja danych: jedyny twardy wymóg

PIPEDA (Personal Information Protection and Electronic Documents Act) to kanadyjska federalna ustawa o ochronie prywatności w sektorze prywatnym, która nie wymaga przechowywania danych osobowych na terenie kraju. Przekazanie danych podmiotowi przetwarzającemu za granicą traktowane jest jako transfer w celu przetwarzania: organizacja zachowuje odpowiedzialność za dane, podmiot przetwarzający musi zapewnić porównywalny poziom ochrony, a użytkownicy muszą zostać poinformowani o takim fakcie. Urząd Komisarza ds. Prywatności (Office of the Privacy Commissioner) konsultował zaostrzenie tych przepisów w 2019 roku, po czym utrzymał dotychczasowe stanowisko. Powszechne twierdzenie, że PIPEDA wymusza przechowywanie danych w Kanadzie, jest zatem błędne, mimo że często powielają je materiały marketingowe dostawców hostingu.

Rzeczywiste zasady dotyczące rezydencji danych istnieją, lecz dotyczą węższego zakresu przypadków.

• Ustawa 25 (Law 25) w Quebecu wymaga przeprowadzenia oceny przed wysłaniem danych osobowych poza prowincję oraz zapewnienia im odpowiedniej ochrony w miejscu docelowym. Przepis ten obowiązuje od września 2023 roku. Jest to wymóg formalny i decyzja, którą należy umieć uzasadnić, a nie całkowity zakaz.
• Przepisy sektora publicznego wiążą organy publiczne oraz obsługujące je firmy. Ustawa PIIDPA w Nowej Szkocji ogranicza przechowywanie danych osobowych poza Kanadą. Ustawa FIPPA w Kolumbii Brytyjskiej zawierała podobny zapis do czasu nowelizacji w 2021 roku, która po przeprowadzeniu oceny dopuściła przechowywanie danych za granicą.
• Prace na rzecz rządu federalnego podlegają wytycznym Government of Canada dotyczącym chmury, które wymagają, aby dane o poziomie ochrony Protected B i wyższym pozostawały w Kanadzie.
• Prowincjonalne przepisy o ochronie prywatności w służbie zdrowia nakładają własne warunki dotyczące lokalizacji dokumentacji medycznej i różnią się one w zależności od prowincji.
• Umowy z klientami oraz przetargi publiczne są w praktyce najczęstszym czynnikiem wymuszającym lokalizację danych. Kwestionariusz bezpieczeństwa zawierający zapis o przechowywaniu danych w Kanadzie wiąże organizację równie silnie jak ustawa, ponieważ został podpisany.

Test praktyczny jest prosty. Czy można wskazać konkretną klauzulę? Jeśli nikt w organizacji nie potrafi wskazać ustawy lub umowy wymagającej przechowywania danych w Kanadzie, wybór lokalizacji opiera się wyłącznie na opóźnieniach sieciowych (latency) i cenie.

Czy kanadyjskie centrum danych znajduje się poza zasięgiem amerykańskiego prawa?

Nie samo z siebie. Amerykańska ustawa CLOUD Act (Clarifying Lawful Overseas Use of Data Act) obejmuje dane znajdujące się w posiadaniu, pod opieką lub pod kontrolą amerykańskiego dostawcy, niezależnie od fizycznej lokalizacji sprzętu. Zatem region w Toronto obsługiwany przez amerykańską firmę znajduje się w jej zasięgu. Jeśli rzeczywistym wymogiem jest uniknięcie zagranicznych procedur prawnych, a nie kwestia geografii, kluczowe jest to, kto obsługuje usługę i kto posiada klucze szyfrujące. Kanadyjski adres budynku sam w sobie nie rozwiązuje tego problemu.

Drugim zaskoczeniem jest routing. Ruch między dwoma kanadyjskimi miastami często przechodzi przez Stany Zjednoczone, ponieważ to tam historycznie znajdowały się tanie punkty wymiany ruchu (peering). Badacze nazywają to routingiem typu bumerang. Uruchom traceroute, zanim zapewnisz kogokolwiek, że Twoje pakiety nigdy nie opuszczają kraju.

traceroute vps.example.com

Nazwy przeskoków zawierają kody miast, takie jak nyc, chi lub ash. Nazwy te są jedynie wskazówkami i mogą być nieaktualne, więc traktuj je jako powód do zapytania dostawcy, a nie jako dowód. W przypadku danych w tranzycie wiarygodnym rozwiązaniem jest szyfrowanie, które kontrolujesz, a nie mapa. Jeśli potrzebujesz prywatnej ścieżki między własnymi maszynami, samodzielnie hostowany WireGuard VPN zapewnia połączenie, dla którego nie ma znaczenia, przez który kraj przebiega światłowód.

Opóźnienie: należy je mierzyć, a nie zakładać

Światło w światłowodzie pokonuje około 200 km w ciągu jednej milisekundy, więc każde 100 km dystansu oznacza około 1 ms czasu odpowiedzi (RTT) przed uwzględnieniem jakiegokolwiek sprzętu. Odległość z Toronto do Vancouver w linii prostej wynosi około 3400 km, a w rzeczywistości, ze względu na przebieg kabli, jest jeszcze większa, co ustala dolną granicę opóźnienia na poziomie około 40 ms. Rzeczywiste trasy wykazują wyższe wartości.

[
  {
    "label": "Toronto",
    "rtt_ms": 3
  },
  {
    "label": "Montreal",
    "rtt_ms": 12
  },
  {
    "label": "New York",
    "rtt_ms": 18
  },
  {
    "label": "Chicago",
    "rtt_ms": 24
  },
  {
    "label": "Northern Virginia",
    "rtt_ms": 26
  },
  {
    "label": "Dallas",
    "rtt_ms": 42
  },
  {
    "label": "Vancouver",
    "rtt_ms": 62
  },
  {
    "label": "London",
    "rtt_ms": 88
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 98
  }
]

Są to typowe, publikowane dane dla dobrze połączonego łącza konsumenckiego w Toronto. Stanowią one punkt wyjścia, a nie gwarancję. Własne wyniki zależą od sieci dostępowej oraz polityki peeringowej dostawcy i zmieniają się w zależności od pory dnia.

Dwa wiersze warto przeanalizować szczególnie uważnie. Połączenie Toronto – Montreal to około 12 ms; miasta te są na tyle blisko, że w większości zastosowań funkcjonują jako jeden region. Połączenie Toronto – Vancouver to około 62 ms, co stanowi większy dystans niż Toronto – Północna Wirginia, gdzie opóźnienie wynosi 26 ms. Lokalizacja w Kanadzie nie jest równoznaczna z bliskością względem użytkowników.

Ostatnia mila zazwyczaj i tak ma decydujące znaczenie. Światłowód domowy dodaje kilka milisekund. Łącza kablowe dodają więcej, gdy sieć jest obciążona. Połączenie mobilne samo w sobie dodaje dziesiątki milisekund. Użytkownik telefonu w Toronto może odnotować 50 ms do serwera w Toronto, a przeniesienie tego serwera do Nowego Jorku zmienia jakość połączenia jedynie o kilka procent.

Jak testować opóźnienia z lokalizacji użytkowników

Najpierw ustal, gdzie faktycznie znajdują się użytkownicy. Twoje narzędzia analityczne dzielą sesje według miast lub regionów. Korzystaj z tych danych zamiast zgadywać na podstawie lokalizacji biura.

Następnie przeprowadź pomiary z tych miejsc. Nie da się przetestować opóźnień dla Vancouver, siedząc przy biurku w Ottawie. Wynajmij na dwadzieścia minut VPS w docelowym mieście i usuń go po zakończeniu testów. Poproś współpracownika lub klienta o wykonanie jednego polecenia. Możesz również skorzystać z darmowej sieci pomiarowej RIPE Atlas pod adresem https://atlas.ripe.net, która posiada sondy w kanadyjskich miastach i umożliwia wykonywanie z nich poleceń ping.

sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com

Odczytaj dwie ostatnie linie.

20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 ms

avg to główna wartość. mdev to jitter, czyli rozrzut czasu między pakietami. Każda utrata pakietów na krótkiej trasie jest błędem wymagającym analizy. Wysoki jitter bardziej szkodzi komunikacji głosowej i grom niż nieco wyższa średnia opóźnienia, ponieważ odbiornik musi buforować dane pod kątem najgorszego pakietu, a nie typowego.

mtr --report --report-cycles 50 vps.example.com

mtr wyświetla utratę dla każdego przeskoku. Jeśli polecenie kończy się błędem uprawnień, uruchom je z sudo. Środkowe przeskoki często wykazują utratę, która nie jest rzeczywista, ponieważ routery nadają generowanym przez siebie odpowiedziom ICMP najniższy priorytet. Tylko utrata, która utrzymuje się aż do ostatniej linii, jest utratą, której doświadcza Twój ruch. Czytaj najpierw dolny wiersz, a następnie analizuj kolejne w górę.

Gdy ruch ICMP jest blokowany lub ograniczany, mierz czas rzeczywistego protokołu.

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

Każde pole to skumulowana liczba sekund od rozpoczęcia żądania. connect minus dns to jeden czas obiegu TCP (RTT). tls minus connect to czas nawiązywania połączenia (handshake). ttfb minus tls to kolejny czas obiegu plus czas, jakiego aplikacja potrzebowała na odpowiedź. Ta ostatnia różnica to miejsce, w którym większość wolnych witryn traci najwięcej czasu. ttfb na poziomie 0.8 s na krótkiej trasie oznacza problem z aplikacją, a przeniesienie serwera do innego miasta go nie rozwiąże.

Aby sprawdzić przepustowość, uruchom serwer na VPS, a klienta po stronie użytkownika. iperf3 nasłuchuje na porcie TCP 5201, więc otwórz port za pomocą ufw na czas testu i zamknij go po zakończeniu.

iperf3 -s

iperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8

-R odwraca kierunek, dzięki czemu mierzysz zarówno pobieranie, jak i wysyłanie. -P 8 otwiera osiem równoległych strumieni. Jeśli osiem strumieni jest znacznie szybszych niż jeden, ograniczeniem jest okno TCP na długiej trasie, a nie samo łącze, ponieważ pojedynczy strumień może przenieść tylko jedno okno na czas obiegu. To samo okno na trasie do Vancouver przesyła mniej więcej jedną trzecią danych na sekundę w porównaniu z trasą do Nowego Jorku. Kopie zapasowe przesyłane na duże odległości zachowują się tak samo, dlatego kopie zapasowe poza siedzibą z użyciem restic wydają się wolne przy odległym celu, nawet na szybkim łączu.

Uruchom ping w drugim terminalu podczas pracy iperf3. Jeśli czas obiegu wzrośnie z 20 ms do 300 ms w trakcie transferu, oznacza to zjawisko bufferbloat w Twoim sprzęcie dostępowym, którego nie naprawi żadna zmiana lokalizacji centrum danych.

Wykonuj pomiary wielokrotnie i przeprowadzaj je wieczorem. Zatory o godzinie 21:00 to rzeczywistość Twoich użytkowników. Wynik z godziny 4:00 rano to ten, który chętniej prezentuje się w materiałach sprzedażowych.

Co czas podróży w obie strony (RTT) oznacza dla obciążenia

Zimne ładowanie strony wymaga czterech cykli podróży w obie strony, zanim przeglądarka będzie mogła wyrenderować jakikolwiek element.

[
  {
    "label": "DNS lookup",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TCP handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "TLS 1.3 handshake",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "Request and first byte",
    "toronto_to_new_york_ms": 18,
    "toronto_to_vancouver_ms": 62
  },
  {
    "label": "All four round trips",
    "toronto_to_new_york_ms": 72,
    "toronto_to_vancouver_ms": 248
  }
]

Wyszukiwanie DNS trafia do resolvera, a nie bezpośrednio do serwera, i zazwyczaj jest buforowane, więc ciepła wizyta pomija ten krok. Licząc od początku do końca, zimne ładowanie zaczyna się z opóźnieniem 72 ms na ścieżce do Nowego Jorku oraz 248 ms na ścieżce do Vancouver. Obie wartości stają się nieistotne w porównaniu z pojedynczym zapytaniem do bazy danych trwającym 400 ms. Gdy połączenie jest otwarte, HTTP/2 oraz HTTP/3 przesyłają wiele żądań jednocześnie, więc koszt ten jest ponoszony raz, a nie dla każdego pliku z osobna. Umieszczenie zasobów statycznych w sieci CDN (content delivery network) sprawia, że lokalizacja serwera źródłowego przestaje mieć dla nich znaczenie, dlatego użytkownik z Europy, dla którego czas do Toronto wynosi 98 ms, nadal może uzyskać szybkie ładowanie strony.

Gry wieloosobowe czasu rzeczywistego to przypadek odwrotny, ponieważ czas podróży w obie strony stanowi o jakości doświadczenia. Wartość poniżej około 50 ms jest odczuwalna jako natychmiastowa w szybkich grach akcji, przy 80 ms gracze zaczynają zauważać opóźnienia, a powyżej 120 ms wina przypisywana jest serwerowi. W tym przypadku region faktycznie decyduje o tym, czy produkt jest dobry. Serwery gier o wolniejszym tempie są znacznie bardziej wyrozumiałe, dlatego uruchomienie serwera Minecraft na VPS pozwala na pracę przy dystansach, które zrujnowałyby strzelankę.

Bazy danych to obszar, w którym wybór regionu powoduje realne straty. Nigdy nie należy umieszczać aplikacji w jednym regionie, a bazy danych w innym. Każde zapytanie to podróż w obie strony. Strona wykonująca 40 zapytań płaci za każde z nich: przy 18 ms na zapytanie jest to większość sekundy, a przy 62 ms na zapytanie czas ten przekracza dwie sekundy, podczas gdy profilowanie strony z bazą danych na tym samym serwerze wykazało 30 ms. Asynchroniczna replikacja do innego regionu jest dopuszczalna w przypadku replik odczytu i odzyskiwania danych po awarii. Synchroniczny commit na długiej ścieżce dodaje czas tej ścieżki do każdego pojedynczego zapisu.

Sesje interaktywne znajdują się pomiędzy tymi skrajnościami. SSH pozostaje komfortowe do około 100 ms, a powyżej tej wartości staje się odczuwalnie opóźnione, ponieważ każde naciśnięcie klawisza czeka na powrót echa. mosh przewiduje znaki lokalnie i ukrywa większość tego opóźnienia. Webhooki oraz wewnętrzne API powinny zawsze znajdować się w tym samym regionie, co usługa, którą wywołują.

Rozliczenia, waluta i podatki

Płatność w dolarach kanadyjskich pozwala uniknąć prowizji za przewalutowanie, którą pobiera wystawca karty, wynoszącej zazwyczaj około 2,5% według stanu na sierpień 2026 roku, a także ułatwia prowadzenie księgowości w jednej walucie. Kanadyjski dostawca wystawia faktury z podatkiem GST lub HST, który zarejestrowany podmiot gospodarczy może odliczyć jako podatek naliczony. Jest to kwestia finansowa z finansową odpowiedzią i nie powinna ona decydować o tym, gdzie kierowany jest ruch sieciowy. Aby dowiedzieć się, ile faktycznie kosztuje serwer i jak porównywać plany bez ryzyka zaskoczenia cenami odnowienia, przeczytaj ile faktycznie kosztuje VPS miesięcznie.

Koszty mniejszego rynku

Kanada jest niewielkim rynkiem hostingowym w porównaniu do Stanów Zjednoczonych, dlatego uczciwa analiza wymaga wskazania ograniczeń, z którymi należy się liczyć.

• Mniejsza liczba dostawców konkurujących o klienta sprawia, że cena za gigabajt pamięci RAM lub dysku jest zazwyczaj wyższa w przypadku maszyn tej samej klasy.
• Zasoby koncentrują się w Toronto i Montrealu, przy mniejszej dostępności w Vancouver i Calgary. Drugi kanadyjski region na potrzeby failover często oznacza długą ścieżkę sieciową lub konieczność wyjścia poza granice kraju.
• Niewielki regionalny dostawca może korzystać z jednego budynku i jednego lub dwóch operatorów szkieletowych. Należy pytać o liczbę operatorów oraz o procedury na wypadek awarii jednego z nich.
• Oferta sprzętowa jest węższa. Duże instancje oraz maszyny z GPU są łatwiej dostępne w regionach USA, dlatego GPU VPS o pożądanych parametrach może nie być dostępny w wybranym mieście.
• Dostępność wsparcia technicznego u małego dostawcy jest kwestią realną, a nie marketingową. Należy ustalić godziny pracy personelu.

Montreal stanowi wyjątek pod względem cen. Tania energia hydroelektryczna w Quebecu oraz zimy obniżające koszty chłodzenia sprawiają, że okolice Montrealu oferują dużą przepustowość w cenach konkurencyjnych wobec regionów USA. Jeśli wymogiem jest Kanada, a nie konkretne miasto, warto rozpocząć poszukiwania właśnie tam.

Jeśli kanadyjskie plany VPS wydają się zbyt małe dla danego obciążenia, przed podjęciem decyzji o zmianie kraju warto porównać VPS z serwerem dedykowanym.

Kiedy hosting VPS w Kanadzie jest właściwym wyborem

1. Ustawa, umowa lub polityka sektora publicznego wskazują Kanadę. Hostuj w Kanadzie. Żaden inny punkt tego wpisu nie ma zastosowania, a zobowiązanie dotyczące rezydencji danych należy uzyskać od dostawcy na piśmie.
2. Użytkownicy znajdują się w jednym kanadyjskim obszarze metropolitalnym, a obciążenie jest ograniczone opóźnieniami: gry wieloosobowe, komunikacja głosowa, zdalne pulpity lub handel elektroniczny. Hostuj w najbliższym mieście i zmierz obie opcje przed podpisaniem jakiejkolwiek umowy.
3. Użytkownicy są rozproszeni po całym kraju. Toronto lub Montreal obejmują największą część populacji, a CDN przed zasobami statycznymi przyniesie użytkownikowi z Vancouver więcej korzyści niż przeniesienie źródła (origin).
4. Wszystkie pozostałe przypadki, czyli większość sytuacji. Wybieraj na podstawie ceny oraz faktycznie otrzymanego sprzętu, a następnie sprawdź, jak wygląda wsparcie o godzinie 2:00 w nocy. Najpierw przetestuj kandydata, ponieważ dwa plany o tej samej specyfikacji nie oferują tej samej wydajności: jak poprawnie wykonać benchmark VPS.

Niezależnie od wyboru, zapisz uzasadnienie obok decyzji. Kolejna osoba, która zapyta, czy usługa powinna znajdować się w Kanadzie, zasługuje na coś więcej niż domysły, a jeśli powodem była klauzula umowna, ktoś będzie musiał ją ponownie odnaleźć. Gdy serwer już istnieje, pierwsze dziesięć minut na nowym VPS ma większe znaczenie dla bezpieczeństwa niż jego lokalizacja.

FAQ

Czy PIPEDA wymaga, aby dane były przechowywane w Kanadzie?

Nie. Ustawa PIPEDA (Personal Information Protection and Electronic Documents Act) nie zawiera wymogu lokalizacji danych dla sektora prywatnego. Przesłanie danych osobowych do podmiotu przetwarzającego w innym kraju jest traktowane jako transfer w celu przetwarzania: organizacja zachowuje odpowiedzialność za dane, podmiot przetwarzający musi zapewnić porównywalny poziom ochrony, a użytkownicy muszą zostać poinformowani o takim fakcie. Urząd Komisarza ds. Prywatności (Office of the Privacy Commissioner) konsultował zmianę tego stanowiska w 2019 roku, lecz ostatecznie je utrzymał. Wymogi dotyczące lokalizacji danych wynikają z innych przepisów: oceny skutków zgodnie z ustawą Law 25 w Quebecu, ustaw dotyczących sektora publicznego, takich jak PIIDPA w Nowej Szkocji, wytycznych rządu Kanady dotyczących chmury obliczeniowej lub zapisów w umowie z klientem.

Czy kanadyjscy użytkownicy odczują różnicę, jeśli serwer znajduje się w Stanach Zjednoczonych?

W przypadku typowej aplikacji internetowej – nie. Czas podróży pakietu (round trip) z Toronto do Nowego Jorku wynosi około 18 ms, a do północnej Wirginii około 26 ms; oba te wyniki są lepsze niż połączenie Toronto z Vancouver, które zajmuje 62 ms. Użytkownicy zauważą czas odpowiedzi serwera i wagę strony znacznie wcześniej, niż odczują 20 ms opóźnienia sieciowego. Różnica jest zauważalna jedynie w grach czasu rzeczywistego, połączeniach głosowych oraz w sytuacjach, w których jedna osoba reaguje na działania drugiej.

Czy kanadyjskie centrum danych jest poza zasięgiem prawa USA?

Nie automatycznie. Amerykańska ustawa CLOUD Act obejmuje dane znajdujące się w posiadaniu, pod nadzorem lub pod kontrolą amerykańskiego dostawcy, niezależnie od fizycznej lokalizacji serwera. Kanadyjski region obsługiwany przez amerykańską firmę nadal podlega tym przepisom. Jeśli głównym zmartwieniem jest zagraniczna procedura prawna, należy zwrócić uwagę na to, kto zarządza usługą i kto posiada klucze szyfrujące, a nie na adres budynku. Szyfrowanie przy użyciu kluczy przechowywanych samodzielnie zmienia zakres danych, które dostawca jest w stanie przekazać.

Jak zmierzyć opóźnienie z miasta, w którym nie mieszkam?

Należy wynająć godzinowy VPS w danym mieście, uruchomić ping -c 20 oraz mtr --report --report-cycles 50 w kierunku własnego serwera, a następnie usunąć instancję. Sieć RIPE Atlas stanowi darmową alternatywę, oferującą sondy w kanadyjskich miastach. Jeśli ruch ICMP jest blokowany, należy zmierzyć czas rzeczywistego żądania za pomocą curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/, co pozwoli uzyskać czas pełnego cyklu TCP (round trip) oraz czas do otrzymania pierwszego bajtu danych.