ARM VPS بمقابلہ x86 VPS: اصل فرق کیا ہے؟

ARM VPS پر منتقل ہونے سے کیا تبدیل ہوتا ہے

ARM VPS پر وہی Linux اور وہی Nginx چلتا ہے جو x86 VPS پر چلتا ہے، اور عموماً فی core لاگت کم ہوتی ہے۔ منتقلی کا بنیادی خطرہ compatibility ہے۔ x86-64 کے لیے compiled پروگرام arm64 پر بالکل نہیں چل سکتا، اس لیے آپ کے stack کے ہر software کے لیے arm64 build دستیاب ہونا چاہیے یا اسے دوبارہ build کرنا ممکن ہونا چاہیے۔

زیادہ تر جدید stacks بغیر کسی اضافی کام کے یہ شرط پوری کر لیتے ہیں۔ مسائل عموماً دو جگہوں پر سامنے آتے ہیں: وہ container images جو صرف ایک architecture کے لیے بنائی گئی ہوں، اور closed source software جس کا arm64 download دستیاب نہ ہو۔ ذیل کے commands آپ کو instance کے لیے ادائیگی کرنے سے پہلے اپنے stack کے بارے میں دونوں سوالات کے جواب دیتے ہیں۔ اگر آپ ابھی یہ طے کر رہے ہیں کہ آپ کو کس قسم کا server چاہیے، تو پہلے VPS کیا ہے اور یہ shared hosting سے کیسے مختلف ہے پڑھیں۔

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 دکھاتا ہے۔ دونوں نتائج درست ہیں۔ Linux kernel اور Debian packaging system نے ایک ہی instruction set کے لیے مختلف نام منتخب کیے ہیں۔ اس لیے aarch64 اور arm64 ایک ہی چیز کا نام ہیں، جبکہ x86_64 اور amd64 دوسری چیز کا نام ہیں۔ Docker، Debian کے طرز کے نام استعمال کرتا ہے، اسی لیے image platform یوں ظاہر ہوتا ہے: linux/arm64۔

arm64 میں /proc/cpuinfo کے اندر model name کی سطر موجود نہیں ہوتی۔ اس کے بجائے Features فیلڈ ملتا ہے، جس میں hardware crypto، aes pmull sha1 sha2 جیسی flags کے طور پر ظاہر ہوتا ہے۔ یہ ARMv8 Cryptographic Extensions ہیں۔ یہ Intel اور AMD processors میں AES-NI جیسا کام کرتی ہیں: TLS (transport layer security) اور disk encryption کو hardware پر تیز بناتی ہیں۔ VPS پر AES hardware acceleration کی جانچ میں دونوں architectures پر یہ test کرنے کا طریقہ بتایا گیا ہے۔

کنٹینرز سب سے پہلے کیوں خراب ہوتے ہیں، اور error کیسی دکھائی دیتی ہے

ہر Docker image manifest اس architecture کو record کرتا ہے جس کے لیے image build کی گئی ہو۔ ایسی image کو arm64 host پر pull کریں جس میں صرف amd64 manifest ہو، تو pull کامیاب ہو جاتی ہے۔ خرابی پہلے process کے start ہوتے وقت سامنے آتی ہے:

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 کا file چلانے سے انکار ہے کہ اس کے ELF (executable and linkable format) header میں ایسے machine type کا نام ہوتا ہے جسے یہ CPU implement نہیں کرتا۔ کوئی setting اسے درست نہیں کر سکتی۔ یہ instructions silicon میں موجود نہیں ہوتیں۔

Deploy کرنے سے پہلے manifest چیک کریں:

docker buildx imagetools inspect nginx:1.27

Output میں manifest list میں موجود ہر image کے لیے ایک Platform: line شامل ہوتی ہے، مثلاً linux/amd64 اور linux/arm64۔ اگر linux/arm64 موجود نہ ہو تو یہ tag ARM VPS پر start نہیں ہوگا۔ docker manifest inspect --verbose nginx:1.27 یہی معلومات دکھاتا ہے، لیکن Docker، docker manifest کو experimental command قرار دیتا ہے جس کا behaviour releases کے درمیان تبدیل ہو سکتا ہے، اس لیے imagetools کو ترجیح دیں۔

اپنی build کی ہوئی images کے لیے ایک ہی command میں دونوں architectures کے لیے build کریں اور manifest list push کریں:

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

ایک ہی host پر foreign architecture کے لیے build کرنے کے لیے kernel کے binfmt_misc handler کے ساتھ QEMU user mode emulation register ہونا ضروری ہے:

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

Emulation کو build اور test کے لیے استعمال کریں۔ اسے network traffic serve کرنے کے لیے استعمال نہ کریں۔ Docker کی اپنی documentation کے مطابق QEMU کے ساتھ emulation "native builds کے مقابلے میں بہت سست ہو سکتی ہے، خاص طور پر compilation اور compression یا decompression جیسے compute-heavy tasks میں"، اس لیے ARM instance پر emulated x86 service وہ saving ختم کر دیتی ہے جس کے لیے آپ نے migration کی تھی۔ Native case کے لیے host setup دونوں architectures پر یکساں ہے: VPS پر Docker چلانا میں اس کی تفصیل موجود ہے، اور جب ہر image میں arm64 manifest موجود ہو تو موجودہ Compose file بغیر تبدیلی کے کام کرتی ہے۔

کیا میرے مطلوبہ packages arm64 کے لیے دستیاب ہوں گے؟

Ubuntu اور Debian اپنے تقریباً پورے archive کو arm64 کے لیے build کرتے ہیں، اس لیے apt install nginx postgresql redis-server دونوں architectures پر یکساں کام کرتا ہے۔ اصل کمی عموماً third-party repositories میں ہوتی ہے۔

ARM instance پر براہِ راست apt سے پوچھیں:

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

apt-cache policy کی reporting میں Candidate: (none) کا مطلب ہے کہ کوئی enabled repository اس architecture کے لیے اس package کی build شائع نہیں کرتی۔ apt-get install -s installation کو simulate کرتا ہے اور کوئی تبدیلی نہیں کرتا۔ اسی صورت میں یہ E: Unable to locate package پر ختم ہوتا ہے۔

اس کے بعد apt update کا output پڑھیں، اسے نظرانداز کر کے آگے نہ بڑھیں۔ اگر vendor repository صرف 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'

repository configured اور reachable ہے، لیکن اس میں ایسی کوئی چیز موجود نہیں جسے یہ machine install کر سکے۔ source entry خود بھی چیک کریں۔ [arch=amd64] کے ساتھ pinned line arm64 host پر skip کر دی جاتی ہے۔ اس لیے package missing نظر آتا ہے، حالانکہ اصل وجہ pin ہوتی ہے۔

کون سے workloads محفوظ ہیں، اور کن کے لیے پہلے جانچ ضروری ہے

Interpreted اور bytecode runtimes بنیادی طور پر portable ہوتے ہیں۔ PHP، Python، Ruby اور Node.js سبھی اہم distributions میں arm64 packages فراہم کرتے ہیں۔ Go اور Rust میں ایک target set کر کے arm64 کے لیے cross-compile کیا جا سکتا ہے۔ LEMP stack، Node API، Nginx کے پیچھے Go binary، یا Postgres database arm64 پر معمول کے workloads ہیں۔

just in time (JIT) compiler پروگرام کے چلنے کے دوران machine code تیار کرتا ہے، اس لیے اسے target architecture کے لیے code generator درکار ہوتا ہے۔ موجودہ versions میں یہ سہولت موجود ہے: OpenJDK، .NET، Node.js کے اندر موجود V8 engine، اور PyPy سبھی Linux پر arm64 کو support کرتے ہیں۔ اصل خطرہ pinned پرانے versions ہیں۔ اگر deploy script کئی سال پرانا runtime release install کرتی ہے تو اسے کام کرنے والا فرض نہ کریں۔ اس release کی notes میں aarch64 support کی جانچ کریں۔

وہ libraries جن میں hand written x86 assembly، یا SSE اور AVX intrinsics شامل ہوں، نسبتاً کم واضح معاملہ ہیں۔ ان میں سے زیادہ تر میں NEON path بھی ہوتا ہے (NEON، ARM کا vector instruction set ہے)، یا plain C fallback موجود ہوتا ہے۔ اس لیے یہ compile اور run ہو جاتی ہیں۔ x86 build کے مقابلے میں performance کسی بھی سمت میں مختلف ہو سکتی ہے۔ اس کا اندازہ کسی article کی بنیاد پر نہ لگائیں؛ اپنی instance پر measurement کریں۔

Closed source software حقیقی رکاوٹ ہے۔ Vendor monitoring agent، licensed database driver، commercial control panel، یا anti-virus daemon compiled binary کی صورت میں آتا ہے۔ اگر vendor arm64 build شائع نہ کرے تو آپ اس کے بارے میں کچھ نہیں کر سکتے۔ Hosting میں cPanel اور WHM اس کی واضح مثال ہے۔ اس کے system requirements میں x86_64 درج ہے اور ARM شامل نہیں ہے، اس لیے control panel server کو x86 پر رکھنا چاہیے (August 2026 میں جانچا گیا؛ پھر بھی vendor کے اپنے requirements page کو دوبارہ پڑھنا مفید ہے)۔ اگر صرف یہی چیز آپ کو روک رہی ہے تو VPS پر چلانے کے قابل cPanel متبادل سے شروع کریں، اور ہر متبادل کی architecture support اسی طریقے سے جانچیں۔

Kernels اور page size: جہاں ARM instances اب بھی مختلف ہیں

x86-64 servers تقریباً ایک دوسرے کے متبادل ہوتے ہیں۔ ARM servers زیادہ یکساں نہیں ہوتے، اور یہ فرق آپ کی application سے نچلی سطح پر موجود ہوتے ہیں۔

Page size وہ فرق ہے جو production تک پہنچتا ہے۔ زیادہ تر arm64 kernels 4 KiB pages استعمال کرتے ہیں، جو x86-64 کے برابر ہے۔ کچھ kernels 64 KiB pages استعمال کرتے ہیں۔ Red Hat Enterprise Linux 8 for aarch64 میں default طور پر 64 KiB page kernel جاری کیا گیا تھا، جبکہ RHEL 9 میں default دوبارہ 4 KiB کر دیا گیا اور بڑے size کے خواہش مند workloads کے لیے الگ kernel-64k package برقرار رکھا گیا۔ 64 KiB page size ایسے process کے لیے memory floor بڑھا دیتا ہے جس میں بہت سی چھوٹی mappings ہوں، کیونکہ kernel کی طرف سے مختص کیا جانے والا سب سے چھوٹا chunk سولہ گنا بڑا ہوتا ہے۔ instance پر getconf PAGESIZE چلائیں اور مفروضہ قائم کرنے کے بجائے number پڑھیں۔

چند دیگر چھوٹے فرق جاننا بھی مفید ہے۔ arm64 پر operating system CPU microcode package موجود نہیں ہوتا، اس لیے firmware updates آپ کے provider کی طرف سے آتی ہیں، apt سے نہیں۔ ARM servers UEFI (unified extensible firmware interface) کے ذریعے boot ہوتے ہیں اور اپنے hardware کی وضاحت ACPI (advanced configuration and power interface) کے ذریعے کرتے ہیں۔ x86 کی کچھ features کا ARM میں کوئی متبادل موجود نہیں، جن میں AMD SEV memory encryption اور Intel GVT-g mediated GPUs شامل ہیں۔

کیا ARM سرور پلیٹ فارم پختہ ہو چکا ہے؟

سافٹ ویئر کے لحاظ سے جواب ہاں ہے۔ Debian، Ubuntu، Fedora اور RHEL سبھی first-class arm64 builds جاری کرتے ہیں، اور Docker Hub پر موجود official images معمول کے مطابق multi-arch ہوتی ہیں۔

حالیہ واضح ثبوت Proxmox ہے۔ 5 August 2026 کو Proxmox نے Proxmox Virtual Environment کے پہلے officially supported arm64 edition، version 9.2، کا اعلان کیا۔ یہ edition package repositories اور release lifecycle کو x86-64 edition کے ساتھ مشترک رکھتی ہے۔ یہ Debian 13.5، Linux 7.0، QEMU 11.0، LXC 7.0 اور ZFS 2.4 پر مبنی ہے۔ Configuration اور tooling x86-64 سے مطابقت رکھتے ہیں، سوائے architecture-specific items کے ایک مختصر مجموعے کے۔

اسی announcement میں دی گئی caveats ضرور پڑھیں، کیونکہ ان سے ظاہر ہوتا ہے کہ officially supported ARM server hardware اب بھی کتنا محدود ہے۔ Proxmox نے پہلے دن NVIDIA Grace اور NVIDIA Vera systems کی validation کی، جس کے لیے NVIDIA اور Supermicro کے ساتھ Grace Hopper hardware پر مشترکہ testing کی گئی۔ دیگر UEFI-based ARMv8-A اور ARMv9-A hardware کو best-effort support ملتا ہے۔ صرف device tree استعمال کرنے والے single-board computers، جیسے Raspberry Pi، supported نہیں ہیں۔ کوئی guest صرف اپنی architecture کے node پر چلتا ہے۔ Live migration صرف ایک ہی architecture کے nodes کے درمیان کام کرتی ہے۔ Mixed-architecture clusters officially supported نہیں ہیں۔

August 2026 تک یہی دیانت دارانہ صورت حال ہے۔ کسی hypervisor vendor کا x86-64 کے برابر lifecycle کے ساتھ arm64 جاری کرنا اس platform کے لیے حقیقی پیش رفت ہے۔ پہلے دن supported hardware کی فہرست میں صرف دو CPU families شامل ہیں۔

فیصلہ کرنے سے پہلے چلائی جانے والی checklist

1. آزمائشی instance پر uname -m چلائیں اور تصدیق کریں کہ یہ aarch64 پرنٹ کرتا ہے۔
2. اپنی Compose file میں موجود ہر image پر docker buildx imagetools inspect چلائیں اور تصدیق کریں کہ ہر image کے لیے linux/arm64 platform line موجود ہے۔
3. ARM instance پر apt update چلائیں اور اس کے ظاہر کردہ ہر Skipping acquire warning کو پڑھیں۔
4. ہر closed source agent کے download page کو کھولیں جس پر آپ انحصار کرتے ہیں، اور نام کے لحاظ سے arm64 یا aarch64 build تلاش کریں۔
5. getconf PAGESIZE چلائیں اور memory کا سائز طے کرنے سے پہلے اس کا جواب نوٹ کریں۔
6. زیر غور ARM plan اور x86 plan، دونوں پر اپنا benchmark چلائیں۔

یہ مضمون کیا دعویٰ نہیں کرتا

ہم ARM اور x86 کے لیے price-to-performance ratio فراہم نہیں کریں گے۔ فی core قیمتیں provider اور plan کے لحاظ سے مختلف ہوتی ہیں، اور کسی دوسرے کے hardware پر حاصل کیا گیا عدد آپ کے hardware کی کارکردگی کی پیش گوئی نہیں کرتا۔ اس کے بجائے خود پیمائش کریں۔ VPS benchmarking کے لیے ہماری رہنما میں sysbench اور fio کو ایسے طریقے کے ساتھ شامل کیا گیا ہے جسے آپ دوبارہ استعمال کر سکتے ہیں، جبکہ VPS کی اصل لاگت تقابل کے pricing پہلو کا احاطہ کرتی ہے۔ Storage، CPU architecture سے الگ فیصلہ ہے، اور VPS پر NVMe کا SATA SSD سے تقابل اس پہلو کی وضاحت کرتا ہے۔ دونوں plans پر ایک ہی test چلائیں، اور جہاں ممکن ہو اپنا workload استعمال کریں، پھر اپنے numbers کی بنیاد پر فیصلہ کریں۔

FAQ

کیا میرے Docker containers کسی ARM VPS پر چلیں گے؟

وہ اسی وقت چلیں گے جب stack کی ہر image کے manifest میں linux/arm64 entry موجود ہو۔ ہر image کو docker buildx imagetools inspect <image> سے چیک کریں اور Platform: linux/arm64 line تلاش کریں۔ Docker Hub پر موجود official images عموماً multi-arch ہوتی ہیں۔ چھوٹے vendors کی images، اور وہ images جو آپ نے خود x86 machine پر build کی ہوں، اکثر multi-arch نہیں ہوتیں۔ اپنی images کے لیے docker buildx build --platform linux/amd64,linux/arm64 ... --push کے ساتھ rebuild کریں، تاکہ ایک ہی tag دونوں architectures کے لیے کام کرے۔

ARM server پر exec format error کا کیا مطلب ہے؟

Kernel نے ایسی binary کو execute کرنے کی کوشش کی جس کے ELF header میں مختلف machine type درج تھا، اس لیے اس نے execution سے انکار کر دیا۔ arm64 host پر اس کا تقریباً ہمیشہ مطلب x86-64 binary یا container image ہوتا ہے۔ Docker پہلے warning دکھاتا ہے کہ requested image platform linux/amd64، detected host platform linux/arm64/v8 سے مطابقت نہیں رکھتا۔ حل یہ ہے کہ درست architecture کے لیے build کی جائے۔ کوئی configuration change x86-64 binary کو ARM پر native طور پر نہیں چلا سکتی۔

کیا arm64 اور aarch64 ایک ہی چیز ہیں؟

ہاں۔ یہ 64-bit ARM instruction set کے دو نام ہیں۔ Kernel uname -m کے ذریعے aarch64 report کرتا ہے، جبکہ Debian اور Ubuntu packaging، اور Docker platform strings، arm64 استعمال کرتے ہیں۔ دوسری جانب بھی یہی تقسیم موجود ہے، جہاں uname -m، x86_64 کہتا ہے اور packaging میں amd64 لکھا ہوتا ہے۔ اگر کسی download page پر صرف aarch64 files موجود ہوں، تو وہ اس machine کے لیے درست files ہیں جسے dpkg --print-architecture، arm64 کہتا ہے۔

کیا ARM VPS، x86 VPS سے زیادہ تیز ہوتا ہے؟

اس سوال کا عمومی جواب نہیں ہے، اور جو بھی واحد ratio آپ پڑھتے ہیں، وہ ایسے hardware پر ناپا گیا تھا جو آپ کا hardware نہیں ہے۔ رفتار کا انحصار مخصوص CPU model، آپ کو دیے گئے cores کی تعداد، tenants کے درمیان contention کو provider کے handle کرنے کے طریقے، اور اس بات پر ہوتا ہے کہ آپ کا workload vector instructions کو کتنی اچھی طرح استعمال کرتا ہے۔ جن دو plans میں سے آپ واقعی انتخاب کر رہے ہیں، ان کا benchmark کریں۔ اگر ممکن ہو تو اپنا workload استعمال کریں اور ان اعداد کا موازنہ کریں۔

Production server کو arm64 پر منتقل کرنے سے پہلے مجھے کیا چیک کرنا چاہیے؟

چار checks کریں، اسی ترتیب سے۔ تصدیق کریں کہ ہر container image میں arm64 manifest موجود ہے۔ تصدیق کریں کہ ہر third-party apt repository binary-arm64 publish کرتی ہے۔ تصدیق کریں کہ ہر closed-source agent کے لیے aarch64 download دستیاب ہے۔ پھر target instance پر getconf PAGESIZE چلائیں، کیونکہ 64 KiB page والا kernel بہت سی چھوٹی mappings والے processes کے memory footprint کو تبدیل کر دیتا ہے۔ جو چیز ان چار checks میں سے کسی ایک میں ناکام ہو، وہ اس مخصوص server کو x86 پر برقرار رکھنے کی وجہ ہے۔