VPS у Франкфурті: кому підходить хостинг у DE

Для кого підходить VPS-хостинг у Франкфурті

VPS-хостинг у Франкфурті підходить для проєктів, користувачі яких перебувають у Німеччині, на ширшому німецькомовному ринку або в різних країнах Європейського Союзу. Франкфурт є одним із вузлів, де європейські мережі з’єднуються та безпосередньо обмінюються мережевим трафіком. Тому сервер у цьому місті досягає більшості країн континенту за кілька десятків мілісекунд. Якщо більшість користувачів перебуває в Північній Америці, європейський сервер працюватиме для них повільно, незалежно від швидкодії машини, оскільки відстань визначає мінімальну затримку, яку неможливо усунути оптимізацією.

Розташування визначають два окремі питання, і саме їх змішування призводить до неправильного вибору. Перше питання — де перебувають користувачі. Це питання відстані та часу кругового обміну. Друге — де дозволено зберігати дані. Це юридичне та договірне питання. Для європейської аудиторії Франкфурт дає сильну відповідь на перше питання. Щодо другого він усуває лише одну конкретну проблему, але не вирішує жодної іншої.

Чому Франкфурт має такі добрі мережеві підключення?

У Франкфурті розташований DE-CIX (Deutsche Commercial Internet Exchange) — IXP (точка обміну інтернет-трафіком), який є одним із найбільших у світі за піковим обсягом трафіку та кількістю підключених мереж. IXP — це спільна комутаційна інфраструктура в дата-центрі, де незалежні мережі підключаються одна до одної замість того, щоб платити більшій мережі за передавання трафіку між ними. DE-CIX публікує поточну статистику трафіку на власному сайті. Ці показники змінюються, тому переглядайте їх на сайті, а не покладайтеся на цифру, скопійовану зі статті.

Практичний ефект пов’язаний із маршрутами, а не із загальними обсягами. Якщо мережа вашого провайдера та ISP (інтернет-провайдер) відвідувача підключені до тієї самої точки обміну, трафік між ними проходить через один маршрутизований перехід у цій точці. Якщо вони не встановлюють локальний peering, трафік має дістатися до іншої мережі, яка передає дані для обох сторін, а найближча точка передавання цієї мережі може бути в іншій країні. Дві німецькі мережі, які обмінюються трафіком через Амстердам або Лондон, двічі оплачують додаткову відстань: по одному разу в кожному напрямку. Мережеві інженери називають це tromboning. Саме це зазвичай пояснює, чому сервер, розташований поруч, за вимірюваннями має велику відстань.

Це можна перевірити, а не припускати. Запустіть mtr до свого сервера з потрібної мережі та перегляньте назви переходів у reverse DNS. Імена хостів маршрутизаторів зазвичай містять коди аеропортів IATA, тому fra в імені переходу означає Франкфурт, ams — Амстердам, а lhr — Лондон. Якщо в маршруті від німецького споживчого підключення до німецького сервера посередині відображається lhr, це точно показує, де виникли додаткові мілісекунди.

Наскільки Франкфурт близький до ваших користувачів?

Світло в оптоволокні поширюється приблизно з двома третинами швидкості світла у вакуумі — близько 200,000 кілометрів за секунду. Зворотний шлях охоплює подвійну відстань, тому найменший можливий час проходження сигналу в обидва боки на відстань d кілометрів становить d/100 мілісекунд. Це теоретична нижня межа. Вона корисна, оскільки перевищити її неможливо.

[
  {
    "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
  }
]

Ці значення обчислено за прямолінійною відстанню, а не виміряно. Останній стовпець показує найкращий результат, який допускає фізика. Реальні вимірювання зазвичай у 1.5–2 рази перевищують цю нижню межу, оскільки оптоволоконні лінії прокладають уздовж доріг і долин річок, а не по дугах великих кіл. Крім того, кожен маршрутизатор на шляху додає невелику затримку пересилання та постановки в чергу.

Берлін розташований за 424 км від Франкфурта, а нижня межа становить 4.2 мс. Відстань до Мадрида — 1,419 км, а нижня межа становить 14.2 мс. Це найдальший від цього місця кут ЄС. Відстань до Нью-Йорка становить 6,206 км, а нижня межа — 62.1 мс. Саме тому аудиторія по той бік Атлантики — це питання вибору розташування, а не оптимізації.

Скільки часу завантаження сторінки коштує повільний round trip?

Один round trip рідко залишається одним round trip. Відкриття HTTPS-з’єднання потребує одного round trip для TCP (transmission control protocol) handshake і ще одного для TLS (transport layer security) 1.3 handshake. Потім запиту потрібен третій round trip, перш ніж повернеться перший байт відповіді. TLS 1.2 додає четвертий. Якщо пошук DNS (domain name system) ще не кешований, він додає щонайменше ще один round trip — знову до іншого сервера.

[
  {
    "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
  }
]

Стовпець round trip тут ґрунтується на припущенні про типовий маршрут до сервера у Франкфурті, а другий стовпець містить арифметичний результат для цього маршруту: три round trip до отримання першого байта. Користувач у Франкфурті чекає 15 мс. Користувач у Сінгапурі за 170 мс round-trip time чекає 510 мс на ту саму відповідь, перш ніж браузер щось намалює.

Саме множник має найбільше значення. Кожна додаткова мілісекунда RTT (round-trip time) коштує приблизно трьох мілісекунд до отримання першого байта, а потім продовжує впливати. HTML-файл указує на stylesheet, stylesheet указує на font, і кожне з цих виявлень створює ще один round trip через те саме з’єднання. Додаткові дві сотні мілісекунд через відстань перетворюють сторінку, яка здавалася миттєвою, на сторінку, що відчувається повільною, хоча сервер виконує ту саму роботу за той самий час.

Це також визначає межу того, що може виправити CDN (content delivery network). Static files, які обслуговуються з кешу поблизу користувача, не проходять довгим маршрутом. Dashboard для авторизованого користувача, якому потрібно виконати запит до вашої database, — ні: такий запит усе одно двічі долає всю відстань. Розмістити origin поблизу користувачів, які входять у систему, — це те, чого жоден кеш за вас не зробить.

Як виміряти це з місця, де перебувають мої користувачі?

Виконуйте ці команди з комп’ютера в потрібній вам мережі, бажано з домашнього або офісного підключення в країні, яку ви обслуговуєте. Вимірювання з іншого сервера в іншому дата-центрі показує характеристики маршрутів до дата-центру, а не користувацькі умови. Наведені нижче команди потрібно запускати самостійно: значення затримки, на які варто реагувати, — це лише результати ваших вимірювань.

ping -c 20 your-server.example.com

У підсумковому рядку зазначено rtt min/avg/max/mdev = .... Значення avg показує типовий випадок, а mdev — джиттер, тобто варіацію між пакетами. Нормальне значення avg за високого mdev означає нестабільний маршрут. Це сильніше впливає на інтерактивну роботу, наприклад SSH або голосовий зв’язок, ніж дещо вище середнє значення.

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

-r виводить звіт замість поточного відображення, -w зберігає повні імена хостів, -z показує номер AS (автономної системи) кожного переходу, а -c 50 виконує п’ятдесят циклів. Втрата пакетів на одному проміжному переході за відсутності втрат на кінцевому переході є нормальною і не свідчить про несправність: багато маршрутизаторів обмежують швидкість ICMP-відповідей, які генерують для власних адрес, але без проблем пересилають решту трафіку. Втрата, яка починається на певному переході та триває на всіх наступних переходах, є реальною втратою пакетів.

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/

Кожне поле містить накопичений час у секундах від початку запиту, тому його потрібно читати шляхом віднімання. time_namelookup — це DNS. Різниця між time_connect і цим значенням — TCP handshake, приблизно один round trip. Різниця між time_appconnect і time_connect — це TLS handshake. Різниця між time_starttransfer і time_appconnect — це час обробки запиту самим застосунком плюс ще один round trip. Якщо проміжки малі, а total усе ще велике, проблема у вашому коді, а не в місті.

Щоб виміряти пропускну здатність, а не затримку, запустіть iperf3 -s на VPS, відкрийте його порт у firewall і запустіть iperf3 -c your-server.example.com -R на клієнті, щоб перевірити напрямок завантаження. Щоб виміряти показники з місць, де у вас немає комп’ютера, RIPE Atlas надає probes по всій Європі. Порівнюючи два сервери, а не дві мережі, використовуйте фіксовану методику замість одноразових значень. Саме для цього призначено повторюване тестування VPS.

Чи робить сервер у Франкфурті мій проєкт таким, що відповідає GDPR?

Ні. Причину варто сформулювати точно. GDPR (General Data Protection Regulation) застосовується залежно від того, чиї персональні дані ви обробляєте та де зареєстрована ваша організація, а не від країни, у якій розташоване обладнання. Переміщення сервера до Франкфурта саме по собі не забезпечує відповідності вимогам, а розміщення сервера за межами ЄС автоматично не означає їх порушення. Місцезнаходження — лише один із кількох чинників.

Розміщення в ЄС або ширшій зоні ЄЕП (European Economic Area) усуває питання міжнародної передачі даних. У регламенті є окремий розділ про передавання персональних даних за межі ЄЕП. Для цього потрібен правовий механізм, наприклад рішення про адекватність або стандартні договірні положення. Дані, які залишаються у Франкфурті, не передаються за межі ЄЕП, тому цей розділ не застосовується до такого етапу обробки. Це справжнє спрощення, і саме таким є реальний масштаб переваги.

Усе інше залишається вашою відповідальністю. Вам потрібна правова підстава для кожної мети обробки, належна реалізація прав людей із вашої бази даних на доступ і видалення, фактично застосовуваний строк зберігання, заходи безпеки, пропорційні ризику, а також повідомлення наглядового органу протягом 72 годин після того, як ви дізналися про порушення безпеки персональних даних. Вам також потрібна угода з hosting provider про обробку даних, відома в Німеччині як Auftragsverarbeitungsvertrag або AVV. Зверніть увагу: сервер у Франкфурті все одно може бути пов’язаний із передаванням даних, якщо працівники служби підтримки за межами ЄЕП мають до нього доступ. Тому перевірте, хто має криптографічні ключі.

Німеччина додає власний рівень регулювання: федеральний BDSG (Bundesdatenschutzgesetz) доповнює регламент національними нормами, а дані працівників найчастіше стають несподіваною проблемою. Цей розділ містить загальну інформацію, а не юридичну консультацію. Європейська рада із захисту даних публікує офіційні настанови на edpb.europa.eu, а питання, що мають реальні наслідки, слід обговорювати з кваліфікованим консультантом, а не вирішувати за tutorial.

Що потрібно змінити безпосередньо на сервері?

Синхронізуйте системний годинник із UTC (координованим всесвітнім часом), а часові мітки форматуйте у своєму застосунку. У Німеччині діє літній час, тому місцевий час двічі на рік змінюється на одну годину, а наприкінці жовтня одна година повторюється. У журналах, записаних за місцевим часом, тієї ночі буде два записи з часом 02:30, і зіставлення цих записів між регіонами перетворюється на припущення. Якщо ви все ж хочете використовувати місцевий час на сервері, установіть його явно та перевірте:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

У виведенні має бути показано Time zone: Europe/Berlin (CEST, +0200) влітку та +0100 узимку.

Німецький текст неправильно сортується за локаллю C за замовчуванням, оскільки сортування в C порівнює необроблені байти. Згенеруйте локаль і перевірте різницю:

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

Під час першого сортування Äpfel розміщується після Zebra, оскільки його перший байт у UTF-8 має більше значення, ніж будь-яка ASCII-літера. Під час другого сортування воно розміщується поруч із Apfel, як і очікує німецькомовний читач. Це важливіше, ніж здається, оскільки PostgreSQL і MySQL фіксують правила зіставлення під час створення бази даних, а їхня подальша зміна потребує перебудови індексів. Визначте правила до завантаження даних.

Дзеркало пакетів у Німеччині скорочує тривалість apt. В Ubuntu 24.04 джерела зберігаються у /etc/apt/sources.list.d/ubuntu.sources у форматі deb822, тому змініть рядок URIs: на http://de.archive.ubuntu.com/ubuntu/, а не додавайте другий файл. Його додавання спричинить Target Packages ... is configured multiple times — помилку дубльованих джерел deb822, через яку оновлення припиняться, доки ви не усунете проблему.

Опублікуйте запис AAAA. Деякі німецькі ISP надають споживчим підключенням конфігурацію DS-Lite (полегшений dual-stack), за якої клієнт не має загальнодоступної IPv4-адреси, а його IPv4-трафік проходить через шлюз трансляції оператора. Такий шлюз збільшує затримку та перевантажується в години пікового навантаження, тоді як IPv6-трафік виходить безпосередньо. Після встановлення запису перевірте обидва маршрути:

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

200 у виведенні другої команди означає, що IPv6 працює наскрізно. Could not resolve host або помилка з’єднання означає, що відсутній запис або слухач, і відвідувачі через DS-Lite використовують повільний маршрут.

Коли Frankfurt є неправильним вибором

• Ваші користувачі перебувають у Сполучених Штатах. Розмістіть сервіс там: VPS у Dallas розташований поблизу центру країни, а VPS-хостинг у New York забезпечує коротший маршрут для східного узбережжя та трафіку, який у будь-якому разі перетинає Атлантику.
• Ваші користувачі перебувають у Латинській Америці. Frankfurt розташований далі від São Paulo, ніж від New York, тому VPS у Brazil є обґрунтованим вибором для цієї аудиторії.
• Дані мають зберігатися в певній країні за межами ЄС. Типовий приклад — робота з державним сектором Канади; у матеріалі що насправді важливо для VPS-хостингу в Canada розглянуто вимоги до розміщення даних у цій країні.
• Ви запускаєте ігровий сервер. Гравці відчувають кожну мілісекунду часу проходження сигналу туди й назад, тому близькість до них важливіша за будь-які інші характеристики: матеріал вибір VPS для ігрових серверів допоможе це врахувати.

Для європейської аудиторії, розподіленої між кількома країнами, Frankfurt є безпечним універсальним вибором і залишається таким у міру зростання системи, оскільки потрібні вам мережі вже підключені до точки обміну трафіком. Виміряйте показники з місця розташування користувачів до міграції та ще раз після неї, а потім збережіть обидва набори даних.

FAQ

Чи достатньо одного VPS у Франкфурті для всієї Європи?

Для більшості проєктів — так. Відстань по прямій задає мінімальну затримку на рівні 12.0 мс до Стокгольма та 14.2 мс до Мадрида, а реальні маршрути зазвичай мають затримку в 1.5–2 рази більшу за цей мінімум. Тому майже вся ЄС залишається в межах кількох десятків мілісекунд від одного сервера у Франкфурті. Додавайте другу локацію, коли виміряли реальну проблему для конкретної країни або коли потрібне резервне перемикання, а не вища швидкість.

Чи робить розміщення у Франкфурті мій проєкт сумісним із GDPR?

Ні. GDPR застосовується з огляду на те, чиї персональні дані ви обробляєте та де ви зареєстровані, а не на розташування сервера. Розміщення в ЄС усуває питання міжнародної передачі даних на цьому етапі. Це суттєве спрощення, але саме воно є основною перевагою. Вам усе одно потрібні законна підстава для обробки, механізми реалізації прав суб’єктів даних, строк зберігання, заходи безпеки, повідомлення про витік протягом 72 годин і угода з обробником даних із провайдером, яка в Німеччині називається AVV. Це загальна інформація, а не юридична консультація.

Якої затримки очікувати між Франкфуртом і Берліном?

Відстань між цими містами становить 424 км, що задає теоретичний мінімум 4.2 мс для часу проходження туди й назад. Для маршруту з якісним peering зазвичай вимірюється затримка в 1.5–2 рази більша за цей мінімум. Перевірте її за допомогою ping -c 20 your-server.example.com із підключення в Берліні та прочитайте значення avg у рядку rtt min/avg/max/mdev. Результат, який значно перевищує цей діапазон, зазвичай означає, що трафік вийшов за межі Німеччини й повернувся назад. Це буде видно за назвами вузлів у mtr -rwzc 50.

Чи потрібно встановлювати для сервера у Франкфурті часовий пояс Europe/Berlin?

Зазвичай ні. Залиште систему в UTC, щоб журнали можна було порівнювати й жодна позначка часу не була неоднозначною. У Німеччині навесні відбувається перехід на CEST, а восени — назад на CET. У ніч переходу на зимовий час одна місцева година повторюється, тому дві різні події можуть мати однакову місцеву позначку часу. Форматуйте час у локальному часовому поясі в застосунку, де є контекст для коректної обробки. Якщо потрібно перевести весь сервер на місцевий час, виконайте sudo timedatectl set-timezone Europe/Berlin і перевірте результат за допомогою timedatectl.

Чи буде проблемою сервер, який працює лише з IPv4, для відвідувачів із Німеччини?

Він працюватиме, але для частини користувачів буде повільнішим. Деякі німецькі ISP надають домашнім підключенням конфігурацію DS-Lite без публічної IPv4-адреси. Такі клієнти підключаються до сервера, доступного лише через IPv4, через шлюз трансляції оператора. Це збільшує затримку та спричиняє перевантаження в періоди високого навантаження. Публікація запису AAAA і прослуховування IPv6 дає їм прямий маршрут. Перевірте це за допомогою dig AAAA your-server.example.com +short і запиту curl -6 та очікуйте HTTP 200 з обох сімейств адрес.