ARM VPS أم x86: ما الذي يتغير فعليًا؟

ما الذي يتغير عند الانتقال إلى VPS يعمل بمعمارية ARM

يشغّل VPS بمعمارية ARM نظام Linux نفسه وNginx نفسه اللذين يشغلهما VPS بمعمارية x86، وعادةً ما تكون تكلفته أقل لكل نواة. يكمن خطر الانتقال في التوافق. لا يمكن لبرنامج مُجمَّع لمعمارية x86-64 أن يعمل على arm64 إطلاقاً، لذلك يجب أن يتوفر لكل مكوّن في حزمة البرامج لديك إصدار مبني لمعمارية arm64، أو أن يكون قابلاً لإعادة البناء.

تجتاز معظم حزم البرامج الحديثة هذا الاختبار دون أي عمل إضافي. تتركز حالات الفشل في موضعين: صور الحاويات التي بُنيت أصلاً لمعمارية واحدة فقط، والبرامج مغلقة المصدر التي لا يتوفر لها تنزيل لمعمارية arm64. تجيب الأوامر أدناه عن السؤالين المتعلقين بحزمة برامجك قبل أن تدفع مقابل مثيل. إذا كنت لا تزال تحدد نوع الخادم الذي تحتاج إليه، فابدأ بقراءة ما هو VPS وكيف يختلف عن الاستضافة المشتركة.

arm64 وaarch64 وamd64: ماذا يعني كل اسم؟

نفِّذ الأوامر التالية على أي instance قبل أي شيء آخر.

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 kernel ونظام حزم Debian اسمين مختلفين لمجموعة التعليمات نفسها، ولذلك يشير aarch64 وarm64 إلى معنى واحد، بينما يشير x86_64 وamd64 إلى المعنى الآخر. يستخدم Docker أسماء أسلوب Debian، ولهذا تقرأ منصة الصورة linux/arm64.

في arm64 لا يوجد سطر model name في /proc/cpuinfo. بدلاً من ذلك، تحصل على حقل Features، وتظهر فيه إمكانات التشفير العتادية على شكل flags مثل aes pmull sha1 sha2. هذه هي Cryptographic Extensions الخاصة بـ ARMv8، وتؤدي الوظيفة التي تؤديها AES-NI في معالجات Intel وAMD: فهي تجعل TLS (أمن طبقة النقل) وتشفير الأقراص سريعين باستخدام العتاد. يشرح التحقق من تسريع AES العتادي على VPS كيفية إجراء الاختبار على كلتا البنيتين.

لماذا تتعطل الحاويات أولاً، وكيف يظهر الخطأ

يسجّل كل Docker image manifest المعمارية التي بُني لها. إذا سحبت image لا تحتوي إلا على manifest للمعمارية 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، أي تنسيق الملف التنفيذي والقابل للربط، يحدد نوع آلة لا تنفذه وحدة المعالجة المركزية هذه. لا يمكن إصلاح ذلك بأي إعداد. فالتعليمات غير موجودة في العتاد.

تحقق من manifest قبل النشر:

docker buildx imagetools inspect nginx:1.27

يعرض الخرج سطراً واحداً من Platform: لكل image في قائمة manifest، مثل linux/amd64 وlinux/arm64. إذا كان linux/arm64 مفقوداً، فلن يبدأ ذلك الوسم على VPS يعمل بمعمارية ARM. يعرض docker manifest inspect --verbose nginx:1.27 المعلومات نفسها، لكن توثّق Docker أن docker manifest أمر تجريبي قد يتغير سلوكه بين الإصدارات، لذلك استخدم imagetools بدلاً منه.

بالنسبة إلى images التي تبنيها بنفسك، ابنِ المعماريتين بأمر واحد وادفع قائمة manifest:

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

استخدم المحاكاة للبناء والاختبار. لا تستخدمها لتقديم network traffic. يذكر توثيق Docker نفسه أن المحاكاة باستخدام QEMU «قد تكون أبطأ بكثير من عمليات البناء الأصلية، خصوصاً في المهام كثيفة الحساب مثل التجميع والضغط أو فك الضغط». لذلك فإن تشغيل خدمة x86 بمحاكاة على instance بمعمارية ARM يلغي التوفير الذي دفعك إلى الانتقال. إعداد المضيف في الحالة الأصلية متطابق في المعماريتين: يشرح تشغيل Docker على VPS ذلك، ويعمل ملف Compose موجود من دون تعديل بعد أن يحتوي كل image فيه على manifest للمعمارية 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، لذلك تبدو الحزمة مفقودة بينما يكون السبب الفعلي هو هذا التقييد.

ما أحمال العمل الآمنة، وما الذي يحتاج إلى تحقق أولاً

صُمِّمت بيئات التشغيل المفسَّرة وبيئات bytecode لتكون قابلة للنقل. تتوفر لـPHP وPython وRuby وNode.js حزم arm64 في التوزيعات الرئيسية. ويمكن لـGo وRust إجراء cross-compilation إلى arm64 بتعيين target واحد. ويُعد تشغيل مكدس LEMP أو واجهة API بـNode أو ملف Go ثنائي خلف Nginx أو قاعدة بيانات Postgres عملاً اعتيادياً على arm64.

ينتج مترجم just in time ‏(JIT) machine code أثناء تشغيل البرنامج، لذلك يحتاج إلى code generator للمعمارية المستهدفة. وتحتوي الإصدارات الحالية على هذا المكوّن: يدعم OpenJDK و.NET ومحرك V8 داخل Node.js وPyPy معمارية arm64 على Linux. أما الخطر الفعلي فيكمن في الإصدارات القديمة المثبّتة. يجب التحقق من ملاحظات الإصدار الخاصة بـruntime الذي يثبّته deploy script منذ عدة سنوات للتأكد من دعمه لـaarch64، بدلاً من افتراض أنه سيعمل.

أما المكتبات التي تحتوي على x86 assembly مكتوب يدوياً، أو على SSE وAVX intrinsics، فهي حالة أقل وضوحاً. يحتوي معظمها أيضاً على مسار NEON ‏(NEON هو مجموعة تعليمات ARM للمتجهات) أو مسار احتياطي بلغة C العادية، ولذلك يمكن تجميعها وتشغيلها. وقد يختلف الأداء عن إصدار x86 في أي من الاتجاهين. قِس الأداء على instance لديك بدلاً من التنبؤ به استناداً إلى مقال.

البرامج المغلقة المصدر هي العائق الحقيقي. يصل monitoring agent من مورّد، أو database driver مرخّص، أو control panel تجاري، أو daemon لمكافحة الفيروسات على هيئة binary مُجمَّع. وعندما لا ينشر المورّد إصداراً لـarm64، لا يمكنك فعل شيء حيال ذلك. وتُعد cPanel وWHM أوضح حالة في مجال الاستضافة: تذكر متطلبات النظام الخاصة بهما x86_64 ولا تسرد ARM، لذلك يبقى خادم control panel على x86 (تم التحقق في August 2026، ويستحسن إعادة قراءة ذلك في صفحة المتطلبات الخاصة بالمورّد). إذا كان هذا هو الشيء الوحيد الذي يمنعك، فابدأ من بدائل cPanel التي تستحق التشغيل على VPS، وتحقق من دعم كل بديل للمعمارية بالطريقة نفسها.

النواة وحجم الصفحات: ما الذي لا يزال يختلف في مثيلات ARM

خوادم x86-64 متشابهة تقريباً ويمكن استبدال بعضها ببعض. أما خوادم ARM فأقل توحيداً، وتقع اختلافاتها تحت مستوى تطبيقك.

حجم الصفحة هو الاختلاف الذي يصل إلى بيئة الإنتاج. تستخدم معظم نوى arm64 صفحات بحجم 4 KiB، مثل x86-64. ويستخدم بعضها صفحات بحجم 64 KiB. كان Red Hat Enterprise Linux 8 for aarch64 يوفّر نواة بحجم صفحة 64 KiB افتراضياً، ثم أعاد RHEL 9 الإعداد الافتراضي إلى 4 KiB مع الإبقاء على حزمة منفصلة kernel-64k لأحمال العمل التي تحتاج إلى الحجم الأكبر. يرفع حجم الصفحة البالغ 64 KiB الحد الأدنى للذاكرة الذي تحتاج إليه عملية تحتوي على العديد من التعيينات الصغيرة، لأن أصغر كتلة يمكن للنواة تخصيصها تصبح أكبر بمقدار 16 مرة. شغّل getconf PAGESIZE على المثيل واقرأ الرقم بدلاً من افتراضه. حجم الصفحة ليس قرار النواة الوحيد الذي يؤثر فيك، لأن الإصدار الذي يوفّره مزودك يتحكم أيضاً في كيفية جدولة العمل على الأنوية، كما أن الجدولة الواعية بذاكرة التخزين المؤقت المضافة في Linux 7.2 تصل إلى arm64 وx86-64 على حد سواء.

توجد اختلافات أصغر أخرى من المفيد معرفتها. لا توجد في arm64 حزمة microcode للمعالج على مستوى نظام التشغيل، لذلك تأتي تحديثات البرنامج الثابت من مزودك وليس من apt. تقلع خوادم ARM عبر UEFI (واجهة البرنامج الثابت الموسعة الموحدة)، وتصف أجهزتها عبر ACPI (واجهة الإعداد المتقدم وإدارة الطاقة). لا يوجد مقابل ARM لبعض ميزات x86، ومنها تشفير الذاكرة 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 على دعم وفق أفضل جهد. أما الحواسيب أحادية اللوحة التي تعتمد على device tree فقط، مثل Raspberry Pi، فلا تحظى بالدعم. لا يعمل الضيف إلا على عقدة من معماريته نفسها، ولا تعمل الترحيلات الحية إلا بين عقد من المعمارية نفسها، كما أن العناقيد ذات المعماريات المختلطة غير مدعومة رسمياً.

هذا هو التقييم الواقعي حتى August 2026. إن إصدار مورّد hypervisor لنظام arm64 وفق دورة الحياة نفسها لإصدار x86-64 يمثل تقدماً حقيقياً للمنصة. لكن قائمة العتاد المدعوم منذ اليوم الأول تقتصر على عائلتين من المعالجات.

قائمة تحقق تُجريها قبل الالتزام

1. شغّل uname -m على نسخة تجريبية، وتأكد من أنه يطبع aarch64.
2. شغّل docker buildx imagetools inspect على كل صورة في ملف Compose، وتأكد من وجود سطر منصة linux/arm64 لكل صورة.
3. شغّل apt update على نسخة ARM، واقرأ كل تحذير Skipping acquire يطبعه.
4. افتح صفحة التنزيل لكل agent مغلق المصدر تعتمد عليه، وابحث بالاسم عن إصدار arm64 أو aarch64.
5. شغّل getconf PAGESIZE وسجّل الإجابة قبل تحديد حجم الذاكرة.
6. أجرِ اختبار أداء خاصاً بك على كل من خطة ARM وخطة x86 اللتين تختار بينهما.

ما لا تدّعيه هذه المقالة

لن نقدّم لك نسبة أداء إلى سعر لمقارنة ARM بـ x86. تختلف أسعار النواة الواحدة باختلاف المزوّد والخطة، كما أن الرقم المقاس على عتاد شخص آخر لا يتنبأ بأدائك. أجرِ القياس بنفسك بدلاً من ذلك. يشرح دليلنا لقياس أداء VPS استخدام sysbench وfio وفق منهج يمكنك تكراره، بينما يتناول التكلفة الفعلية لـVPS جانب الأسعار في المقارنة. التخزين قرار منفصل عن معمارية CPU، ويتناول مقارنة NVMe بـ SATA SSD على VPS هذا الجانب. أجرِ الاختبار نفسه على كلتا الخطتين، باستخدام عبء العمل الخاص بك حيثما أمكن، ودع أرقامك تحدد النتيجة.

FAQ

هل ستعمل حاويات Docker لديّ على VPS بمعمارية ARM؟

ستعمل إذا احتوت كل صورة في المكدس على إدخال 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؟

نعم. هما اسمان لمجموعة تعليمات ARM ذات 64 بت. تعرض النواة aarch64 عبر uname -m، بينما تستخدم حزم Debian وUbuntu، وسلاسل منصات Docker، arm64. ويوجد الفصل نفسه في الجانب الآخر، حيث يشير uname -m إلى x86_64، بينما تستخدم الحزم amd64. إذا عرضت صفحة التنزيل ملفات aarch64 فقط، فهي الملفات الصحيحة لجهاز تسميه dpkg --print-architecture باسم arm64.

هل VPS بمعمارية ARM أسرع من VPS بمعمارية x86؟

لا توجد إجابة عامة عن هذا السؤال، وأي نسبة واحدة تقرؤها قيسَت على عتاد ليس عتادك. تعتمد السرعة على طراز وحدة المعالجة المركزية المحدد، وعدد الأنوية المخصصة لك، وطريقة تعامل المزوّد مع التنافس بين المستأجرين، ومدى استفادة حملك من التعليمات المتجهية. اختبر الخطتين اللتين تختار بينهما فعلياً باستخدام حملك الخاص إن أمكن، ثم قارن النتائج.

ما الذي ينبغي أن أتحقق منه قبل نقل خادم إنتاج إلى arm64؟

أجرِ أربعة فحوصات بهذا الترتيب. تأكد من أن كل صورة حاوية تحتوي على بيان arm64. تأكد من أن كل مستودع apt تابع لجهة خارجية ينشر binary-arm64. تأكد من أن كل وكيل مغلق المصدر يوفّر تنزيل aarch64. ثم شغّل getconf PAGESIZE على المثيل الهدف، لأن نواة تستخدم صفحات بحجم 64 KiB تغيّر البصمة الذاكرية للعمليات التي تحتوي على العديد من التعيينات الصغيرة. أي عنصر يفشل في أحد هذه الفحوصات الأربعة يُعد سبباً للإبقاء على ذلك الخادم تحديداً على x86.