تفاوت VPS با معماری ARM و x86 چیست؟

تغییرات هنگام مهاجرت به یک VPS با معماری ARM

یک VPS با معماری ARM همان سیستم‌عامل Linux و همان Nginx را اجرا می‌کند که در یک VPS با معماری x86 وجود دارد و معمولاً هزینهٔ هر هستهٔ آن کمتر است. ریسک اصلی در این جابه‌جایی، سازگاری است. برنامه‌ای که برای x86-64 کامپایل شده باشد، به‌هیچ‌وجه روی arm64 اجرا نمی‌شود؛ بنابراین تمام نرم‌افزارهای موجود در stack شما باید دارای نسخهٔ arm64 باشند یا به‌گونه‌ای باشند که بتوانید آن‌ها را مجدداً build کنید.

بیشتر stackهای مدرن بدون هیچ مشکلی از این آزمون عبور می‌کنند. موارد شکست معمولاً در دو بخش متمرکز هستند: imageهای کانتینری که فقط برای یک معماری خاص ساخته شده‌اند و نرم‌افزارهای متن‌بسته (closed source) که نسخهٔ arm64 ندارند. دستورات زیر پیش از آنکه هزینه‌ای برای یک instance بپردازید، پاسخ هر دو پرسش را برای stack اختصاصی شما مشخص می‌کنند. اگر هنوز در حال بررسی این هستید که به چه نوع سروری نیاز دارید، با VPS چیست و چه تفاوتی با هاست اشتراکی دارد شروع کنید.

معماری‌های arm64، aarch64 و amd64: هر نام به چه معناست

پیش از انجام هر کاری، این دستورات را روی هر نمونه (instance) اجرا کنید.

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

uname -m در یک ماشین ARM خروجی aarch64 و در یک ماشین Intel یا AMD خروجی x86_64 را نمایش می‌دهد. دستور dpkg --print-architecture نیز برای همان دو ماشین، خروجی arm64 و amd64 را چاپ می‌کند. هر دو پاسخ صحیح هستند. هسته لینوکس و سیستم بسته‌بندی دبیان نام‌های متفاوتی را برای یک مجموعه دستورالعمل یکسان انتخاب کرده‌اند؛ بنابراین aarch64 و arm64 به یک معنا هستند و x86_64 و amd64 معنای دیگر را می‌رسانند. داکر از نام‌گذاری سبک دبیان استفاده می‌کند و به همین دلیل است که پلتفرم یک ایمیج به صورت linux/arm64 خوانده می‌شود.

در معماری arm64، هیچ خطی با عنوان model name در فایل /proc/cpuinfo وجود ندارد. در عوض، شما یک فیلد Features دریافت می‌کنید و قابلیت رمزنگاری سخت‌افزاری در آنجا به صورت فلگ‌هایی مانند aes pmull sha1 sha2 ظاهر می‌شود. این‌ها همان افزونه‌های رمزنگاری ARMv8 هستند که وظیفه‌ای مشابه AES-NI در قطعات Intel و AMD را انجام می‌دهند: آن‌ها رمزنگاری TLS (امنیت لایه انتقال) و رمزنگاری دیسک را در سطح سخت‌افزار سریع می‌کنند. مطلب بررسی شتاب‌دهنده سخت‌افزاری AES روی یک VPS، نحوه تست این موضوع را در هر دو معماری پوشش می‌دهد.

چرا کانتینرها ابتدا دچار مشکل می‌شوند و خطا چگونه به نظر می‌رسد

هر مانیفست ایمیج Docker، معماری‌ای را که برای آن ساخته شده است ثبت می‌کند. اگر ایمیجی را که فقط دارای مانیفست amd64 است روی یک میزبان arm64 دریافت (pull) کنید، عملیات دریافت با موفقیت انجام می‌شود. شکست در اولین تلاش برای اجرای پردازش رخ می‌دهد:

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 (فرمت اجرایی و قابل‌لینک) آن، نوع ماشینی را نام می‌برد که این CPU قادر به اجرای آن نیست. هیچ تنظیمی این مشکل را حل نمی‌کند؛ دستورالعمل‌ها در سخت‌افزار وجود ندارند.

پیش از استقرار، مانیفست را بررسی کنید:

docker buildx imagetools inspect nginx:1.27

خروجی به ازای هر ایمیج در لیست مانیفست، یک خط Platform: نمایش می‌دهد، مانند linux/amd64 و linux/arm64. اگر linux/arm64 وجود نداشته باشد، آن تگ روی یک VPS با معماری ARM اجرا نخواهد شد. docker manifest inspect --verbose nginx:1.27 همان اطلاعات را نشان می‌دهد، اما Docker مستند کرده است که docker manifest یک دستور آزمایشی است که رفتار آن ممکن است بین نسخه‌ها تغییر کند، بنابراین استفاده از imagetools را ترجیح دهید.

برای ایمیج‌هایی که خودتان می‌سازید، هر دو معماری را در یک دستور بسازید و یک لیست مانیفست را push کنید:

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 موجود، بدون تغییر کار می‌کند، به شرطی که هر ایمیج در آن دارای مانیفست arm64 باشد.

آیا بسته‌های مورد نیاز من برای arm64 موجود هستند؟

توزیع‌های Ubuntu و Debian تقریباً تمام آرشیو خود را برای معماری arm64 بیلد می‌کنند، بنابراین apt install nginx postgresql redis-server در هر دو معماری رفتار یکسانی دارد. شکاف‌های موجود معمولاً مربوط به مخازن (repositories) شخص ثالث است.

مستقیماً از طریق apt در instance با معماری ARM پرس‌وجو کنید:

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

گزارش Candidate: (none) توسط apt-cache policy به این معناست که هیچ مخزن فعالی، بیلد این بسته را برای این معماری منتشر نکرده است. دستور 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'

مخزن پیکربندی شده و در دسترس است، اما هیچ چیزی که این ماشین بتواند نصب کند در آن وجود ندارد. ورودی منبع (source entry) را نیز بررسی کنید. خطی که با [arch=amd64] محدود (pin) شده باشد، در یک میزبان arm64 نادیده گرفته می‌شود؛ بنابراین وقتی علت اصلی همان محدودیت (pin) است، بسته به نظر می‌رسد که وجود ندارد.

کدام بار کاری ایمن است و کدام نیاز به بررسی اولیه دارد

محیط‌های اجرای مفسری و بایت‌کد ذاتاً قابل‌حمل هستند. زبان‌های PHP، Python، Ruby و Node.js همگی بسته‌های arm64 را در توزیع‌های اصلی دارند. زبان‌های Go و Rust با تنظیم یک target، قابلیت cross-compile برای arm64 را دارند. پشته LEMP، یک API مبتنی بر Node، یک باینری Go پشت Nginx یا یک دیتابیس Postgres، کارهای عادی روی arm64 محسوب می‌شوند.

کامپایلر Just-in-time یا همان JIT، در حین اجرای برنامه کد ماشین تولید می‌کند، بنابراین به یک تولیدکننده کد برای معماری مقصد نیاز دارد. نسخه‌های فعلی از این قابلیت برخوردارند: OpenJDK، .NET، موتور V8 در داخل Node.js و PyPy همگی از arm64 روی Linux پشتیبانی می‌کنند. نسخه‌های قدیمی و ثابت‌شده (Pinned) خطر اصلی هستند. اسکریپت استقراری که یک نسخه از runtime را از چندین سال پیش نصب می‌کند، باید به‌جای فرضِ کارکرد، با یادداشت‌های انتشار آن نسخه برای پشتیبانی از aarch64 بررسی شود.

کتابخانه‌هایی که دارای کدهای اسمبلی دست‌نویس x86 یا دستورات داخلی SSE و AVX هستند، مورد خاموش‌تری محسوب می‌شوند. اکثر آن‌ها یک مسیر NEON (که مجموعه دستورات برداری ARM است) یا یک جایگزین ساده C دارند، بنابراین کامپایل و اجرا می‌شوند. عملکرد ممکن است در هر جهتی با بیلد x86 متفاوت باشد. به‌جای پیش‌بینی بر اساس یک مقاله، آن را روی instance خود اندازه‌گیری کنید.

نرم‌افزارهای متن‌بسته (Closed source) مانع واقعی هستند. یک عامل مانیتورینگ از فروشنده، یک درایور دیتابیس دارای لایسنس، یک کنترل پنل تجاری یا یک دیمون آنتی‌ویروس به‌صورت باینری کامپایل‌شده ارائه می‌شوند و وقتی فروشنده بیلد arm64 منتشر نمی‌کند، کاری از دست شما برنمی‌آید. cPanel و WHM واضح‌ترین مورد در میزبانی هستند: نیازمندی‌های سیستم آن x86_64 را ذکر کرده و ARM را لیست نمی‌کند، بنابراین سرور کنترل پنل روی x86 باقی می‌ماند (بررسی‌شده در آگوست 2026، و ارزش بازخوانی در صفحه نیازمندی‌های خودِ فروشنده را دارد). اگر این تنها موردی است که شما را عقب نگه داشته، جایگزین‌های cPanel که ارزش اجرا روی VPS را دارند نقطه شروع است و پشتیبانی معماری هر کدام را به همین روش بررسی کنید.

هسته‌ها و اندازه صفحه: تفاوت‌های باقی‌مانده در نمونه‌های ARM

سرورهای x86-64 تقریباً با یکدیگر قابل جایگزینی هستند. سرورهای ARM یکپارچگی کمتری دارند و تفاوت‌های آن‌ها در سطحی پایین‌تر از لایه اپلیکیشن شما قرار دارد.

اندازه صفحه (Page size) موردی است که در محیط 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 را روی نمونه اجرا کنید و به‌جای فرض کردن، عدد خروجی را بخوانید.

چند تفاوت جزئی دیگر نیز وجود دارد که دانستن آن‌ها مفید است. هیچ بسته microcode پردازنده در سطح سیستم‌عامل برای arm64 وجود ندارد، بنابراین به‌روزرسانی‌های فریم‌ور از طریق ارائه‌دهنده شما انجام می‌شود و نه از طریق apt. سرورهای ARM از طریق UEFI (رابط فریم‌ور توسعه‌پذیر یکپارچه) بوت می‌شوند و سخت‌افزار خود را از طریق ACPI (رابط پیشرفته پیکربندی و توان) معرفی می‌کنند. برخی از قابلیت‌های x86 هیچ معادل مستقیمی در ARM ندارند، از جمله رمزنگاری حافظه AMD SEV و پردازنده‌های گرافیکی واسط Intel GVT-g.

آیا پلتفرم سرور ARM به بلوغ رسیده است؟

از نظر نرم‌افزاری، بله. توزیع‌های Debian، Ubuntu، Fedora و RHEL همگی نسخه‌های arm64 درجه یک ارائه می‌دهند و ایمیج‌های رسمی در Docker Hub به‌طور پیش‌فرض چندمعماری (multi-arch) هستند.

واضح‌ترین گواه اخیر، Proxmox است. در تاریخ 5 August 2026، شرکت Proxmox اولین نسخه رسمی پشتیبانی‌شده از Proxmox Virtual Environment برای arm64، یعنی نسخه 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، پشتیبانی نمی‌شوند. یک guest فقط روی نودی با معماری مشابه خود اجرا می‌شود، مهاجرت زنده (live migration) فقط بین نودهایی با معماری یکسان کار می‌کند و خوشه‌های با معماری ترکیبی به‌طور رسمی پشتیبانی نمی‌شوند.

این موضع صادقانه تا تاریخ August 2026 است. اینکه یک فروشنده هایپروایزر، نسخه arm64 را با همان چرخه حیات x86-64 عرضه می‌کند، پیشرفت واقعی برای این پلتفرم محسوب می‌شود. لیست سخت‌افزارهای پشتیبانی‌شده در روز اول، شامل دو خانواده CPU است.

چک‌لیستی برای اجرا پیش از commit

1. دستور uname -m را روی یک نمونه آزمایشی اجرا کنید و تأیید کنید که خروجی آن aarch64 است.
2. دستور docker buildx imagetools inspect را روی تمام imageهای موجود در فایل Compose خود اجرا کنید و برای هر کدام، وجود یک خط platform با مقدار linux/arm64 را تأیید کنید.
3. دستور apt update را روی نمونه ARM اجرا کرده و تمام هشدارهای Skipping acquire که نمایش می‌دهد را مطالعه کنید.
4. صفحه دانلود مربوط به هر agent متن‌بسته (closed source) که به آن وابستگی دارید را باز کنید و به دنبال buildهایی با نام arm64 یا aarch64 بگردید.
5. دستور getconf PAGESIZE را اجرا کنید و پیش از تعیین میزان حافظه (memory sizing)، پاسخ آن را یادداشت کنید.
6. بنچ‌مارک اختصاصی خود را هم روی پلن ARM و هم روی پلن x86 که قصد انتخاب بین آن‌ها را دارید، اجرا کنید.

آنچه این مطلب ادعا نمی‌کند

ما قصد نداریم نسبت قیمت به کارایی ARM در برابر x86 را به شما ارائه دهیم. قیمت هر هسته بسته به ارائه‌دهنده و طرح انتخابی متفاوت است و عددی که روی سخت‌افزار شخص دیگری اندازه‌گیری شده، پیش‌بینی‌کننده عملکرد سخت‌افزار شما نیست. در عوض، خودتان آن را اندازه‌گیری کنید. راهنمای ما برای بنچمارک کردن یک VPS ابزارهای sysbench و fio را با روشی که می‌توانید تکرار کنید پوشش می‌دهد و هزینه واقعی یک VPS چقدر است جنبه‌های قیمتی این مقایسه را بررسی می‌کند. فضای ذخیره‌سازی تصمیمی جدا از معماری CPU است و مقایسه NVMe با SATA SSD در یک VPS به آن بخش می‌پردازد. تست یکسانی را روی هر دو طرح اجرا کنید، در صورت امکان با workload اختصاصی خودتان، و اجازه دهید اعداد تصمیم‌گیرنده باشند.

FAQ

آیا کانتینرهای Docker من روی یک VPS با معماری ARM اجرا می‌شوند؟

اگر هر ایمیج در stack شما دارای یک ورودی linux/arm64 در manifest خود باشد، اجرا خواهند شد. هر کدام را با docker buildx imagetools inspect <image> بررسی کنید و به دنبال خطی با عنوان Platform: linux/arm64 بگردید. ایمیج‌های رسمی در Docker Hub معمولاً multi-arch هستند. ایمیج‌های ارائه‌دهندگان کوچک‌تر و ایمیج‌هایی که خودتان روی یک ماشین x86 ساخته‌اید، اغلب این‌گونه نیستند. برای ایمیج‌های خودتان، با استفاده از docker buildx build --platform linux/amd64,linux/arm64 ... --push مجدداً build بگیرید تا یک تگ، هر دو معماری را پشتیبانی کند.

خطای exec format error روی سرور ARM به چه معناست؟

هسته سیستم‌عامل سعی کرده یک فایل باینری را اجرا کند که در header آن (ELF) نوع معماری متفاوتی ذکر شده و به همین دلیل از اجرای آن خودداری کرده است. روی یک میزبان arm64، این خطا تقریباً همیشه به معنای تلاش برای اجرای یک فایل باینری یا ایمیج کانتینر x86-64 است. Docker ابتدا هشداری نمایش می‌دهد که می‌گوید پلتفرم ایمیج درخواستی linux/amd64 با پلتفرم شناسایی‌شده میزبان linux/arm64/v8 مطابقت ندارد. راه‌حل، build گرفتن برای معماری صحیح است. هیچ تغییر پیکربندی نمی‌تواند باعث شود یک فایل باینری x86-64 به‌صورت بومی (natively) روی ARM اجرا شود.

آیا arm64 همان aarch64 است؟

بله. این‌ها دو نام برای مجموعه دستورات 64 بیتی ARM هستند. هسته سیستم‌عامل در دستور uname -m مقدار aarch64 را گزارش می‌کند، در حالی که بسته‌بندی‌های Debian و Ubuntu و همچنین رشته‌های پلتفرم در Docker از arm64 استفاده می‌کنند. همین تفاوت در سمت دیگر نیز وجود دارد، جایی که uname -m مقدار x86_64 را نشان می‌دهد و بسته‌بندی‌ها از amd64 استفاده می‌کنند. اگر یک صفحه دانلود فقط فایل‌های aarch64 را ارائه می‌دهد، این‌ها فایل‌های مناسب برای ماشینی هستند که dpkg --print-architecture آن را arm64 می‌نامد.

آیا یک VPS با معماری ARM سریع‌تر از یک VPS با معماری x86 است؟

این پرسش پاسخ کلی ندارد و هر نسبتی که می‌خوانید، روی سخت‌افزاری اندازه‌گیری شده که متعلق به شما نیست. سرعت به مدل دقیق CPU، تعداد هسته‌های اختصاص‌یافته، نحوه مدیریت تداخل بین کاربران توسط ارائه‌دهنده و میزان بهره‌وری workload شما از دستورات برداری (vector instructions) بستگی دارد. دو پلنی را که قصد انتخاب بین آن‌ها دارید با workload واقعی خودتان بنچمارک کنید و اعداد به‌دست‌آمده را مقایسه نمایید.

پیش از انتقال یک سرور عملیاتی (production) به arm64 چه مواردی را باید بررسی کنم؟

چهار بررسی به این ترتیب انجام دهید: تأیید کنید که هر ایمیج کانتینر دارای manifest برای arm64 باشد. تأیید کنید که تمام مخازن (repository) apt شخص ثالث، نسخه binary-arm64 را منتشر کرده باشند. تأیید کنید که تمام agentهای متن‌بسته (closed source) دارای فایل دانلود برای aarch64 باشند. سپس دستور getconf PAGESIZE را روی نمونه مقصد اجرا کنید، زیرا هسته‌ای با page size 64 کیلوبایتی، میزان مصرف حافظه فرآیندهایی که نگاشت‌های (mapping) کوچک زیادی دارند را تغییر می‌دهد. هر موردی که در یکی از این چهار بررسی شکست بخورد، دلیلی برای نگه داشتن آن سرور خاص روی x86 است.