تفاوت سرور مجازی ARM و x86 چیست؟

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

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

بیشتر 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 را نمایش می‌دهد. هر دو پاسخ صحیح هستند. هسته لینوکس و سیستم بسته‌بندی Debian نام‌های متفاوتی را برای یک مجموعه دستورالعمل (instruction set) انتخاب کرده‌اند؛ بنابراین aarch64 و arm64 به یک معنا هستند و x86_64 و amd64 معنای دیگر را می‌رسانند. داکر از نام‌گذاری سبک Debian استفاده می‌کند و به همین دلیل است که پلتفرم image به صورت linux/arm64 خوانده می‌شود.

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

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

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

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

docker buildx imagetools inspect nginx:1.27

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

برای imageهایی که خودتان می‌سازید، هر دو معماری را در یک دستور بسازید و یک لیست مانیفست را 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 «می‌تواند بسیار کندتر از ساخت بومی (native) باشد، به‌ویژه برای وظایف سنگین محاسباتی مانند کامپایل کردن و فشرده‌سازی یا استخراج»، بنابراین یک سرویس x86 شبیه‌سازی‌شده روی یک نمونه ARM، صرفه‌جویی هزینه‌ای که باعث مهاجرت شما شده است را از بین می‌برد. تنظیمات میزبان برای حالت بومی در هر دو معماری یکسان است: اجرای Docker روی یک VPS این موضوع را پوشش می‌دهد و یک فایل Compose موجود، بدون تغییر کار می‌کند، به شرطی که هر image موجود در آن دارای مانیفست arm64 باشد.

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

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

مستقیماً از apt روی نمونه 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] پین شده است، در یک میزبان arm64 نادیده گرفته می‌شود، بنابراین وقتی علت اصلی پین بودن است، بسته به نظر می‌رسد که وجود ندارد.

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

محیط‌های اجرایی (runtime) مفسری و بایت‌کد، ذاتاً قابل‌حمل هستند. 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 را دارند نقطه شروع است و پشتیبانی معماری هر کدام را به همین روش بررسی کنید.

کرنل‌ها و اندازه صفحه (page size): تفاوت‌های باقی‌مانده در نمونه‌های 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 را روی instance اجرا کنید و به‌جای فرض کردن، عدد خروجی را بخوانید. اندازه صفحه تنها تصمیم کرنل نیست که بر شما تأثیر می‌گذارد، زیرا نسخه‌ای که ارائه‌دهنده شما عرضه می‌کند، نحوه زمان‌بندی کارها روی هسته‌ها را نیز تعیین می‌کند و زمان‌بندی آگاه از کش که در Linux 7.2 اضافه شد، هم روی arm64 و هم روی x86-64 اعمال می‌شود.

چند تفاوت کوچک‌تر وجود دارد که دانستن آن‌ها ارزشمند است. هیچ بسته microcode پردازنده در سطح سیستم‌عامل برای arm64 وجود ندارد، بنابراین به‌روزرسانی‌های فریم‌ور از طریق ارائه‌دهنده شما انجام می‌شود و نه از طریق apt. سرورهای ARM از طریق UEFI (رابط فریم‌ور توسعه‌پذیر یکپارچه) بوت می‌شوند و سخت‌افزار خود را از طریق ACPI (رابط پیکربندی و توان پیشرفته) توصیف می‌کنند. برخی از قابلیت‌های x86 هیچ معادل ARM ندارند، از جمله رمزنگاری حافظه AMD SEV و پردازنده‌های گرافیکی واسط 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 با حداکثر تلاش پشتیبانی می‌شوند. کامپیوترهای تک‌بردی (SBC) که فقط از Device tree استفاده می‌کنند، مانند Raspberry Pi، پشتیبانی نمی‌شوند. یک ماشین مجازی (Guest) فقط روی گره‌ای با معماری مشابه خود اجرا می‌شود، مهاجرت زنده (Live migration) فقط بین گره‌های دارای معماری یکسان کار می‌کند و خوشه‌های (Clusters) با معماری ترکیبی به‌طور رسمی پشتیبانی نمی‌شوند.

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

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

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

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

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

FAQ

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

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

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

هسته (kernel) تلاش کرده است یک binary را اجرا کند که در header فایل ELF آن، نوع معماری متفاوتی ذکر شده است و به همین دلیل از اجرای آن خودداری کرده است. روی یک host با معماری arm64، این خطا تقریباً همیشه به معنای تلاش برای اجرای یک binary یا image کانتینر x86-64 است. Docker ابتدا یک هشدار چاپ می‌کند که می‌گوید پلتفرم image درخواستی یعنی linux/amd64 با پلتفرم شناسایی‌شدهٔ host یعنی linux/arm64/v8 مطابقت ندارد. راه‌حل، build کردن برای معماری صحیح است. هیچ تغییر پیکربندی‌ای باعث نمی‌شود یک binary معماری x86-64 به‌صورت بومی روی 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 چه مواردی را باید بررسی کنم؟

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