ARM VPS чи x86 VPS: що насправді змінюється

Що змінюється під час переходу на ARM VPS

ARM VPS використовує ту саму Linux і той самий Nginx, що й x86 VPS, і зазвичай коштує дешевше в розрахунку на ядро. Основний ризик переходу — сумісність. Програма, скомпільована для x86-64, взагалі не може працювати на arm64, тому кожен компонент вашого стека має постачатися у версії для arm64 або підтримувати повторне складання.

Більшість сучасних стеків проходить цю перевірку без додаткових дій. Проблеми найчастіше виникають у двох випадках: коли container images створено лише для однієї архітектури та коли закрите програмне забезпечення не має версії для arm64, доступної для завантаження. Наведені нижче команди допоможуть перевірити обидва випадки у вашому стеку до оренди інстансу. Якщо ви ще визначаєтеся, який тип сервера вам потрібен, почніть із матеріалу що таке VPS і чим він відрізняється від shared hosting.

arm64, aarch64, amd64: що означають ці назви

Виконайте ці команди на будь-якому інстансі перед усім іншим.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m виводить aarch64 на ARM-машині та x86_64 на машині з Intel або AMD. dpkg --print-architecture виводить arm64 і amd64 для тих самих двох машин. Обидві відповіді правильні. Ядро Linux і система пакування Debian використовують різні назви для того самого набору інструкцій, тому aarch64 і arm64 означають одне, а x86_64 і amd64 — інше. Docker використовує назви у стилі Debian, тому платформа образу має вигляд linux/arm64.

На arm64 у /proc/cpuinfo немає рядка model name. Замість нього виводиться поле Features, а апаратна криптографія позначається там прапорцями на кшталт aes pmull sha1 sha2. Це Cryptographic Extensions в ARMv8. Вони виконують ту саму функцію, що й AES-NI у процесорах Intel та AMD: прискорюють TLS (захист транспортного рівня) і шифрування диска апаратними засобами. У матеріалі Перевірка апаратного прискорення AES на VPS описано перевірку для обох архітектур.

Чому контейнери виходять з ладу першими і який вигляд має помилка

Маніфест кожного Docker image містить архітектуру, для якої його зібрано. Якщо завантажити image, який має лише маніфест amd64, на хост arm64, завантаження завершиться успішно. Помилка виникне під час першого запуску процесу:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error — це відмова ядра запустити файл, оскільки його заголовок ELF (executable and linkable format) містить тип машини, який цей CPU не підтримує. Жодне налаштування не усуне проблему. У наборі мікросхеми немає потрібних інструкцій.

Перевірте маніфест перед розгортанням:

docker buildx imagetools inspect nginx:1.27

У виведенні буде один рядок Platform: для кожного image у списку маніфестів, наприклад linux/amd64 і linux/arm64. Якщо linux/arm64 відсутній, цей tag не запуститься на ARM VPS. docker manifest inspect --verbose nginx:1.27 показує ті самі відомості, але Docker позначає docker manifest як експериментальну команду, поведінка якої може змінюватися між релізами, тому використовуйте imagetools.

Для image, які ви створюєте самостійно, зберіть обидві архітектури однією командою та передайте список маніфестів у registry:

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

Для складання під іншу архітектуру на одному хості потрібна емуляція користувацького режиму QEMU, зареєстрована в обробнику binfmt_misc ядра:

docker run --privileged --rm tonistiigi/binfmt --install all

Використовуйте емуляцію для складання та тестування. Не використовуйте її для обслуговування мережевого трафіку. У власній документації Docker зазначено, що емуляція з QEMU «може бути значно повільнішою за нативне складання, особливо для ресурсомістких завдань, таких як компіляція та стиснення або розпакування», тому емуляція x86-сервісу на ARM-інстансі нівелює економію, заради якої ви виконали міграцію. Налаштування хоста для нативного запуску однакове для обох архітектур: у матеріалі про запуск Docker на VPS описано цей процес, а наявний Compose file працює без змін, якщо кожен image у ньому має маніфест arm64.

Чи доступні потрібні мені пакети для arm64?

Ubuntu і Debian збирають для arm64 майже весь архів, тому apt install nginx postgresql redis-server працює однаково на обох архітектурах. Проблеми найчастіше виникають зі сторонніми репозиторіями.

Виконайте прямий запит до apt на ARM-інстансі:

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

Повідомлення apt-cache policy із результатом Candidate: (none) означає, що жоден увімкнений репозиторій не публікує збірку цього пакета для цієї архітектури. apt-get install -s імітує встановлення та нічого не записує, а в такому самому випадку завершується з E: Unable to locate package.

Потім перегляньте вивід apt update, а не пропускайте його під час прокручування. Репозиторій постачальника, доступний лише для amd64, явно повідомляє про це:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

Репозиторій налаштований і доступний, але в ньому немає пакетів, які ця машина може встановити. Також перевірте сам запис джерела. Рядок із параметром [arch=amd64] пропускається на хості arm64, тому пакет виглядає відсутнім, хоча справжня причина полягає в цьому параметрі.

Які робочі навантаження безпечні, а які спочатку потрібно перевірити

Інтерпретовані середовища виконання та середовища виконання байткоду за задумом є портативними. PHP, Python, Ruby і Node.js мають пакети для arm64 в основних дистрибутивах. Go і Rust компілюють код для arm64 крос-компіляцією після вибору однієї цільової платформи. Стек LEMP, API на Node, бінарний файл Go за Nginx або база даних Postgres — звичайні робочі навантаження на arm64.

JIT-компілятор створює машинний код під час виконання програми, тому йому потрібен генератор коду для цільової архітектури. У сучасних версіях він є: OpenJDK, .NET, рушій V8 усередині Node.js і PyPy підтримують arm64 у Linux. Справжню небезпеку становлять зафіксовані старі версії. Скрипт розгортання, який встановлює версію середовища виконання, випущену кілька років тому, потрібно перевірити за примітками до цієї версії щодо підтримки aarch64, а не вважати, що вона працюватиме.

Бібліотеки з власноруч написаним кодом x86 assembly або інструкціями SSE та AVX — менш очевидний випадок. Більшість із них також мають гілку для NEON (NEON — це набір векторних інструкцій ARM) або резервну реалізацію на звичайному C, тому вони компілюються та працюють. Продуктивність порівняно зі збіркою для x86 може бути як вищою, так і нижчою. Вимірюйте її на своєму екземплярі, а не прогнозуйте за статтею.

Пропрієтарне програмне забезпечення є справжнім блокувальним фактором. Агент моніторингу від постачальника, ліцензований драйвер бази даних, комерційна панель керування або демон антивіруса постачаються як скомпільований бінарний файл. Якщо постачальник не публікує збірку для arm64, нічого зробити не можна. cPanel і WHM — найочевидніший приклад у хостингу: у системних вимогах зазначено x86_64 і не вказано ARM, тому сервер із панеллю керування потрібно залишити на x86 (перевірено в August 2026; вимоги варто повторно перевірити на сторінці вимог самого постачальника). Якщо саме це вас стримує, почніть зі альтернатив cPanel, які варто запустити на VPS, і так само перевірте підтримку архітектури для кожної з них.

Ядра та розмір сторінки: у чому ARM-інстанси досі відрізняються

Сервери x86-64 майже взаємозамінні. Сервери ARM менш уніфіковані, і ці відмінності працюють на рівні, нижчому за ваш застосунок.

Розмір сторінки — це відмінність, яка впливає на production. У більшості ядер arm64 використовуються сторінки розміром 4 KiB, як і в x86-64. Деякі ядра використовують 64 KiB. Red Hat Enterprise Linux 8 для aarch64 постачався з ядром із розміром сторінки 64 KiB за замовчуванням, а RHEL 9 повернув типовий розмір до 4 KiB, зберігши окремий пакет kernel-64k для навантажень, яким потрібен більший розмір. Розмір сторінки 64 KiB підвищує мінімальний обсяг пам’яті для процесу з великою кількістю невеликих відображень, оскільки найменший блок, який ядро може виділити, у шістнадцять разів більший. Виконайте getconf PAGESIZE на інстансі та перевірте це значення, а не робіть припущень. Розмір сторінки — не єдине рішення ядра, яке впливає на вашу систему, оскільки версія, яку постачає провайдер, також визначає розподіл навантаження між ядрами, а планування з урахуванням кешу, додане в Linux 7.2 працює і на arm64, і на x86-64.

Варто знати ще кілька менших відмінностей. В arm64 немає пакета мікрокоду CPU для операційної системи, тому оновлення firmware надходять від провайдера, а не з apt. Сервери ARM завантажуються через UEFI (уніфікований розширюваний інтерфейс firmware) і описують своє обладнання через ACPI (розширений інтерфейс конфігурації та керування живленням). Деякі функції x86 взагалі не мають аналога в ARM, зокрема шифрування пам’яті AMD SEV і віртуальні GPU Intel GVT-g.

Чи досягла зрілості серверна платформа ARM?

Щодо програмного забезпечення — так. Debian, Ubuntu, Fedora і RHEL постачають повноцінні збірки для arm64, а офіційні образи на Docker Hub зазвичай мають підтримку кількох архітектур.

Найпереконливіший недавній приклад — Proxmox. 5 August 2026 Proxmox оголосив про першу офіційно підтримувану arm64-редакцію Proxmox Virtual Environment — версію 9.2. Вона використовує ті самі репозиторії пакетів і цикл випусків, що й редакція для x86-64. Редакцію побудовано на Debian 13.5 з Linux 7.0, QEMU 11.0, LXC 7.0 і ZFS 2.4. Конфігурація та інструменти відповідають x86-64, за винятком невеликого набору архітектурно специфічних компонентів.

Прочитайте застереження в тому самому оголошенні. Вони показують, наскільки вузьким досі є перелік офіційно підтримуваного серверного обладнання ARM. Proxmox перевірив системи NVIDIA Grace і NVIDIA Vera в перший день, виконавши спільне тестування з NVIDIA та Supermicro на обладнанні Grace Hopper. Інше обладнання на базі UEFI з ARMv8-A та ARMv9-A отримує підтримку за принципом best effort. Одноплатні комп’ютери, що використовують лише device tree, наприклад Raspberry Pi, не підтримуються. Гостьова система працює лише на вузлі з такою самою архітектурою. Live migration працює лише між вузлами з однаковою архітектурою. Кластери зі змішаними архітектурами офіційно не підтримуються.

Станом на August 2026 це чесна оцінка ситуації. Те, що виробник hypervisor випускає arm64 у тому самому циклі підтримки, що й x86-64, є реальним прогресом для платформи. На момент запуску перелік підтримуваного обладнання охоплює дві сім’ї CPU.

Контрольний список перед прийняттям рішення

1. Виконайте uname -m на тестовому інстансі та переконайтеся, що команда виводить aarch64.
2. Виконайте docker buildx imagetools inspect для кожного образу у вашому Compose-файлі та переконайтеся, що для кожного образу є рядок платформи linux/arm64.
3. Виконайте apt update на ARM-інстансі та прочитайте всі попередження Skipping acquire, які він виводить.
4. Відкрийте сторінку завантаження кожного агента із закритим вихідним кодом, від якого ви залежите, і знайдіть збірку arm64 або aarch64 за назвою.
5. Виконайте getconf PAGESIZE і зафіксуйте отриману відповідь, перш ніж визначати обсяг пам’яті.
6. Виконайте власний бенчмарк на ARM-плані та x86-плані, між якими ви обираєте.

Чого цей матеріал не стверджує

Ми не будемо наводити співвідношення ціни та продуктивності ARM і x86. Ціна одного ядра залежить від провайдера та тарифного плану, а результат, отриманий на чужому обладнанні, не дає змоги спрогнозувати показники на вашому. Натомість виміряйте їх самостійно. Наш посібник із бенчмаркінгу VPS охоплює sysbench і fio та описує методику, яку можна повторити, а в матеріалі скільки насправді коштує VPS розглянуто ціновий аспект порівняння. Сховище — окреме рішення, не пов’язане з архітектурою CPU, а в матеріалі як NVMe порівнюється із SATA SSD на VPS розглянуто цю частину питання. Виконайте однаковий тест на обох тарифних планах, за можливості використовуючи власне робоче навантаження, і приймайте рішення за власними результатами.

FAQ

Чи працюватимуть мої Docker-контейнери на ARM VPS?

Вони працюватимуть, якщо кожен образ у стеку має запис linux/arm64 у своєму маніфесті. Перевірте кожен образ за допомогою docker buildx imagetools inspect <image> і знайдіть рядок Platform: linux/arm64. Офіційні образи на Docker Hub зазвичай підтримують кілька архітектур. Образи від невеликих постачальників і образи, які ви самостійно створили на машині з x86, часто такої підтримки не мають. Для власних образів виконайте повторне складання за допомогою docker buildx build --platform linux/amd64,linux/arm64 ... --push, щоб один тег працював в обох архітектурах.

Що означає exec format error на ARM-сервері?

Ядро спробувало виконати бінарний файл, у заголовку ELF якого вказано інший тип машини, і відмовилося це робити. На хості arm64 це майже завжди означає бінарний файл або образ контейнера x86-64. Спочатку Docker виводить попередження про те, що запитана платформа образу linux/amd64 не відповідає визначеній платформі хоста linux/arm64/v8. Рішення — зібрати файл для правильної архітектури. Жодна зміна конфігурації не дасть змоги нативно запускати бінарний файл x86-64 на ARM.

Чи arm64 — це те саме, що aarch64?

Так. Це дві назви 64-бітного набору інструкцій ARM. Ядро повідомляє aarch64 через uname -m, тоді як пакети Debian і Ubuntu та рядки платформ Docker використовують arm64. Аналогічний поділ є і з іншого боку: uname -m означає x86_64, а в пакуванні використовується amd64. Якщо на сторінці завантаження доступні лише файли aarch64, саме вони потрібні для машини, яку dpkg --print-architecture називає arm64.

Чи ARM VPS швидший за x86 VPS?

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

Що перевірити перед перенесенням production-сервера на arm64?

Виконайте 4 перевірки в такому порядку. Переконайтеся, що кожен образ контейнера має маніфест arm64. Переконайтеся, що кожен сторонній apt-репозиторій публікує binary-arm64. Переконайтеся, що для кожного агента із закритим вихідним кодом доступний дистрибутив для aarch64. Потім виконайте getconf PAGESIZE на цільовому інстансі, оскільки ядро зі сторінками розміром 64 KiB змінює обсяг пам’яті, який використовують процеси з великою кількістю невеликих відображень. Будь-яка помилка під час однієї з цих 4 перевірок є підставою залишити саме цей сервер на x86.