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

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

في arm64 لا يوجد سطر model name في /proc/cpuinfo. بدلاً من ذلك، يظهر حقل Features، وتظهر فيه إمكانات التشفير العتادي كأعلام مثل aes pmull sha1 sha2. هذه هي ARMv8 Cryptographic Extensions، وتؤدي الوظيفة نفسها التي تؤديها 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 رفض kernel تشغيل الملف، لأن ترويسة ELF (التنسيق القابل للتنفيذ والربط) تحدد نوع آلة لا تنفذه وحدة المعالجة المركزية هذه. لا يصلح أي إعداد ذلك. فهذه التعليمات غير موجودة في العتاد.

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

docker buildx imagetools inspect nginx:1.27

يعرض الناتج سطراً واحداً من Platform: لكل image في قائمة manifest، مثل linux/amd64 وlinux/arm64. إذا كان linux/arm64 غير موجود، فلن تبدأ تلك العلامة على ARM VPS. يعرض 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 في kernel:

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

استخدم المحاكاة للبناء والاختبار. لا تستخدمها لتقديم network traffic. توضح وثائق Docker نفسها أن المحاكاة عبر QEMU «قد تكون أبطأ بكثير من عمليات البناء الأصلية، ولا سيما في المهام كثيفة الحساب مثل الترجمة والضغط أو فك الضغط»، لذلك فإن تشغيل خدمة x86 محاكاة على مثيل 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 عبر ضبط هدف واحد. ويُعد تشغيل مكدس LEMP أو واجهة API مبنية على Node أو ملف Go ثنائي خلف Nginx أو قاعدة بيانات Postgres أمراً اعتيادياً على arm64.

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

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

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

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

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

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

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

هذا هو الوضع الفعلي حتى 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. افتح صفحة التنزيل لكل 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. تأكد من أن لكل agent مغلق المصدر تنزيلاً بمعمارية aarch64. ثم شغّل getconf PAGESIZE على المثيل الهدف، لأن نواة تستخدم صفحات بحجم 64 KiB تغيّر البصمة الذاكرية للعمليات التي تحتوي على العديد من التعيينات الصغيرة. أي عنصر يفشل في أحد هذه الفحوصات الأربعة يبرر إبقاء ذلك الخادم تحديداً على x86.