ARM VPS বনাম x86 VPS: আসলে কী পরিবর্তন হয়

ARM VPS-এ স্থানান্তর করলে কী পরিবর্তন হয়

একটি ARM VPS-এ x86 VPS-এর মতো একই Linux এবং একই Nginx চলে। প্রতি core-এর খরচও সাধারণত কম হয়। তবে স্থানান্তরের প্রধান ঝুঁকি হলো compatibility। x86-64-এর জন্য compile করা কোনো program arm64-এ একেবারেই চলবে না। তাই আপনার stack-এর প্রতিটি software-এর জন্য arm64 build থাকতে হবে, অথবা সেটি নিজে rebuild করার উপযোগী হতে হবে।

বেশিরভাগ আধুনিক stack কোনো অতিরিক্ত কাজ ছাড়াই এই পরীক্ষায় উত্তীর্ণ হয়। সমস্যা সাধারণত দুটি জায়গায় দেখা দেয়: যেসব container image কখনও একটির বেশি architecture-এর জন্য build করা হয়নি, এবং যেসব closed source software-এর কোনো arm64 download নেই। instance-এর জন্য অর্থ দেওয়ার আগে নিচের command-গুলো আপনার নিজের 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 line থাকে না। এর পরিবর্তে সেখানে Features field থাকে। hardware crypto সেখানে aes pmull sha1 sha2-এর মতো flags হিসেবে দেখা যায়। এগুলো ARMv8 Cryptographic Extensions। Intel এবং AMD প্রসেসরে AES-NI যে কাজ করে, এগুলোও সেই কাজ করে: TLS (transport layer security) এবং disk encryption hardware-এ দ্রুত সম্পন্ন করে। VPS-এ AES hardware acceleration পরীক্ষা করা নিবন্ধে উভয় architecture-এ এই পরীক্ষা করার পদ্ধতি দেওয়া আছে।

কেন container প্রথমে ভেঙে যায় এবং error কেমন দেখায়

প্রতিটি Docker image manifest-এ সেটি কোন architecture-এর জন্য তৈরি হয়েছে তা লেখা থাকে। শুধু amd64 manifest থাকা কোনো image arm64 host-এ pull করলে pull সফল হয়। প্রথম process start হওয়ার সময় failure দেখা দেয়:

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 দিয়ে এটি ঠিক করা যায় না। এই instruction-গুলো 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-এর documentation অনুযায়ী docker manifest একটি experimental command, যার আচরণ release-ভেদে পরিবর্তিত হতে পারে। তাই imagetools ব্যবহার করুন।

নিজে build করা image-এর জন্য একই command-এ উভয় architecture 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

Build এবং test করার সময় emulation ব্যবহার করুন। Network traffic serve করার জন্য এটি ব্যবহার করবেন না। Docker-এর documentation অনুযায়ী QEMU দিয়ে emulation "can be much slower than native builds, especially for compute-heavy tasks like compilation and compression or decompression" হতে পারে। তাই ARM instance-এ emulated x86 service চালালে migration-এর মাধ্যমে যে সাশ্রয় পাওয়ার কথা ছিল, তা আবার কমে যায়। Native case-এর জন্য host setup উভয় architecture-এই একই: VPS-এ Docker চালানো অংশে এটি ব্যাখ্যা করা হয়েছে। কোনো Compose file-এর প্রতিটি image-এ arm64 manifest থাকলে existing Compose file অপরিবর্তিতভাবেই কাজ করবে।

arm64-এর জন্য আমার প্রয়োজনীয় প্যাকেজ কি পাওয়া যাবে?

Ubuntu এবং Debian arm64-এর জন্য প্রায় পুরো archive-ই build করে। তাই apt install nginx postgresql redis-server উভয় architecture-এই একইভাবে কাজ করে। সাধারণত তৃতীয় পক্ষের repository-তেই ঘাটতি থাকে।

ARM instance-এ সরাসরি apt-কে জিজ্ঞাসা করুন:

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

apt-cache policy-এ Candidate: (none) দেখালে এর অর্থ হলো, কোনো enabled repository এই architecture-এর জন্য ওই package-এর build প্রকাশ করে না। apt-get install -s install প্রক্রিয়াটি অনুকরণ করে এবং কোনো কিছু লেখে না। একই পরিস্থিতিতে এটি 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 যে package install করতে পারে, সেখানে তেমন কিছু নেই। Source entry-টিও পরীক্ষা করুন। [arch=amd64] দিয়ে pinned কোনো line arm64 host-এ বাদ দেওয়া হয়। ফলে package-টি missing মনে হয়, যদিও প্রকৃত কারণ হলো pin।

কোন workload নিরাপদ, আর কোনটির জন্য আগে পরীক্ষা প্রয়োজন

Interpreted এবং bytecode runtime মূলত portable হওয়ার জন্য তৈরি। PHP, Python, Ruby এবং Node.js—সবগুলোরই প্রধান distribution-গুলোতে arm64 package রয়েছে। একটি target সেট করলেই Go এবং Rust arm64-এর জন্য cross-compile হয়। LEMP stack, Node API, Nginx-এর পেছনে চলা Go binary অথবা Postgres database—arm64-এ এগুলো সাধারণ কাজ।

Just in time (JIT) compiler program চলার সময় machine code তৈরি করে। তাই target architecture-এর জন্য code generator প্রয়োজন। বর্তমান version-গুলোতে এটি রয়েছে: OpenJDK, .NET, Node.js-এর ভেতরের V8 engine এবং PyPy—সবই Linux-এ arm64 support করে। আসল ঝুঁকি হলো নির্দিষ্ট করে ব্যবহার করা পুরোনো version। কয়েক বছর আগের runtime release install করে এমন deploy script থাকলে সেটি কাজ করবে ধরে না নিয়ে ওই release-এর notes-এ aarch64 support পরীক্ষা করুন।

নিজে লেখা x86 assembly অথবা SSE এবং AVX intrinsic থাকা library-গুলো তুলনামূলকভাবে কম দৃশ্যমান সমস্যা তৈরি করে। বেশির ভাগ library-তেই NEON path থাকে (NEON হলো ARM vector instruction set), অথবা plain C fallback থাকে। তাই সেগুলো compile ও run করে। x86 build-এর তুলনায় performance দুই দিকেই ভিন্ন হতে পারে। কোনো article দেখে অনুমান না করে আপনার instance-এ তা মাপুন।

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 পরীক্ষা করুন।

Kernel এবং page size: যেখানে ARM instance-গুলোর পার্থক্য এখনও আছে

x86-64 server প্রায় একইভাবে ব্যবহার করা যায়। ARM server-গুলো ততটা একরকম নয়, এবং এই পার্থক্য আপনার application-এর নিচের স্তরে থাকে।

Production-এ সবচেয়ে বেশি প্রভাব ফেলে page size। অধিকাংশ arm64 kernel 4 KiB page ব্যবহার করে, যা x86-64-এর মতোই। কিছু kernel 64 KiB page ব্যবহার করে। Red Hat Enterprise Linux 8 for aarch64 ডিফল্টভাবে 64 KiB page kernel সরবরাহ করত, আর RHEL 9 ডিফল্ট 4 KiB-এ ফিরিয়ে এনে বড় page size প্রয়োজন এমন workload-এর জন্য আলাদা kernel-64k package রেখেছে। অনেক ছোট mapping থাকা কোনো process-এর ক্ষেত্রে 64 KiB page size memory floor বাড়ায়, কারণ kernel যে ক্ষুদ্রতম chunk বরাদ্দ করতে পারে, সেটি 16 গুণ বড়। Instance-এ getconf PAGESIZE চালিয়ে সংখ্যাটি দেখুন; অনুমান করবেন না। Page size-ই একমাত্র kernel সিদ্ধান্ত নয় যা আপনার environment-এ প্রভাব ফেলে। Provider যে version সরবরাহ করে, সেটিও core-গুলোর মধ্যে কাজ কীভাবে schedule হবে তা নিয়ন্ত্রণ করে। একইভাবে Linux 7.2-এ যোগ হওয়া cache-aware scheduling arm64 এবং x86-64 উভয় ক্ষেত্রেই প্রযোজ্য।

আরও কয়েকটি ছোট পার্থক্য জানা দরকার। arm64-এ operating system CPU microcode package নেই। তাই firmware update আসে provider-এর কাছ থেকে, apt থেকে নয়। ARM server UEFI (unified extensible firmware interface)-এর মাধ্যমে boot করে এবং ACPI (advanced configuration and power interface)-এর মাধ্যমে hardware বর্ণনা করে। কিছু x86 feature-এর ARM-এ কোনো counterpart নেই। এর মধ্যে AMD SEV memory encryption এবং Intel GVT-g mediated GPU অন্তর্ভুক্ত।

ARM সার্ভার প্ল্যাটফর্ম কি পরিণত হয়েছে?

সফটওয়্যারের দিক থেকে উত্তরটি হ্যাঁ। Debian, Ubuntu, Fedora এবং RHEL—সবগুলোই first-class arm64 build প্রকাশ করে। Docker Hub-এর official image-গুলোও সাধারণত multi-arch।

সাম্প্রতিক সবচেয়ে স্পষ্ট প্রমাণ হলো Proxmox। 5 August 2026-এ Proxmox Proxmox Virtual Environment-এর প্রথম officially supported arm64 edition, version 9.2, ঘোষণা করে। এই edition x86-64 edition-এর সঙ্গে package repository এবং release lifecycle ভাগ করে। এটি Debian 13.5, Linux 7.0, QEMU 11.0, LXC 7.0 এবং ZFS 2.4-এর ওপর তৈরি। অল্প কিছু architecture-specific বিষয় বাদ দিলে configuration এবং tooling x86-64 সংস্করণের মতোই।

একই announcement-এ দেওয়া সীমাবদ্ধতাগুলো পড়ুন। এগুলো দেখায় যে officially supported ARM server hardware এখনো কত সীমিত। Proxmox প্রথম দিন থেকেই NVIDIA Grace এবং NVIDIA Vera system validate করেছে। এর আগে NVIDIA এবং Supermicro-এর সঙ্গে Grace Hopper hardware নিয়ে যৌথ testing করা হয়েছিল। অন্যান্য UEFI-based ARMv8-A এবং ARMv9-A hardware best-effort support পায়। Device tree-নির্ভর single-board computer, যেমন Raspberry Pi, supported নয়। কোনো guest শুধু নিজের architecture-এর node-এ চলে। Live migration শুধু একই architecture-এর nodeগুলোর মধ্যে কাজ করে। Mixed-architecture cluster officially supported নয়।

August 2026 পর্যন্ত বাস্তব অবস্থা এটাই। কোনো hypervisor vendor যখন x86-64-এর একই lifecycle-এ arm64 প্রকাশ করে, তখন সেটি platformটির জন্য বাস্তব অগ্রগতি। তবে প্রথম দিন থেকেই supported hardware-এর তালিকায় মাত্র দুইটি CPU family রয়েছে।

কমিট করার আগে চালানোর চেকলিস্ট

1. একটি পরীক্ষামূলক instance-এ uname -m চালিয়ে নিশ্চিত করুন যে এটি aarch64 প্রিন্ট করে।
2. আপনার Compose file-এর প্রতিটি image-এ docker buildx imagetools inspect চালিয়ে প্রতিটির জন্য একটি linux/arm64 platform line আছে কি না নিশ্চিত করুন।
3. ARM instance-এ apt update চালিয়ে এটি প্রিন্ট করা প্রতিটি Skipping acquire warning পড়ুন।
4. আপনি যে প্রতিটি closed source agent-এর ওপর নির্ভর করেন, তার download page খুলে নামের মধ্যে arm64 বা aarch64 build খুঁজুন।
5. memory নির্ধারণের আগে getconf PAGESIZE চালিয়ে ফলাফলটি লিখে রাখুন।
6. যে ARM plan এবং x86 plan-এর মধ্যে বেছে নিচ্ছেন, দুটিতেই নিজস্ব benchmark চালান।

এই পোস্টে যা দাবি করা হচ্ছে না

ARM এবং x86-এর জন্য price-to-performance ratio আমরা নির্ধারণ করে দিচ্ছি না। প্রতি-core-এর দাম provider ও plan অনুযায়ী পরিবর্তিত হয়, এবং অন্য কারও hardware-এ মাপা একটি সংখ্যা আপনার hardware-এর কর্মক্ষমতা পূর্বাভাস দেয় না। তাই নিজেই মাপুন। VPS benchmark করার আমাদের guide-এ পুনরাবৃত্তি করা যায় এমন একটি পদ্ধতিতে sysbench ও fio ব্যবহারের বিষয়টি দেখানো হয়েছে, এবং একটি VPS-এর প্রকৃত খরচ তুলনার pricing দিকটি ব্যাখ্যা করে। Storage, CPU architecture থেকে আলাদা একটি সিদ্ধান্ত; VPS-এ NVMe কীভাবে SATA SSD-এর সঙ্গে তুলনীয়-এ সেই অংশটি আলোচনা করা হয়েছে। উভয় plan-এ একই test চালান। যেখানে সম্ভব, নিজের workload ব্যবহার করুন। তারপর আপনার মাপা ফলাফল অনুযায়ী সিদ্ধান্ত নিন।

FAQ

আমার Docker container-গুলো কি ARM VPS-এ চলবে?

Stack-এর প্রতিটি image-এর manifest-এ linux/arm64 entry থাকলে সেগুলো চলবে। docker buildx imagetools inspect <image> দিয়ে প্রতিটি image পরীক্ষা করুন এবং Platform: linux/arm64 line খুঁজুন। Docker Hub-এর official image সাধারণত multi-arch হয়। ছোট vendor-এর image এবং x86 machine-এ নিজের তৈরি image প্রায়ই multi-arch হয় না। নিজের image-এর জন্য docker buildx build --platform linux/amd64,linux/arm64 ... --push দিয়ে rebuild করুন, যাতে একটি tag উভয় architecture-এ কাজ করে।

ARM server-এ exec format error বলতে কী বোঝায়?

Kernel এমন একটি binary চালানোর চেষ্টা করেছে, যার ELF header-এ ভিন্ন machine type উল্লেখ আছে, তাই এটি তা প্রত্যাখ্যান করেছে। arm64 host-এ এর অর্থ প্রায় সব ক্ষেত্রেই x86-64 binary বা container image। Docker প্রথমে একটি warning দেখায়। সেখানে বলা থাকে, অনুরোধ করা image platform linux/amd64 শনাক্ত করা host platform linux/arm64/v8-এর সঙ্গে মেলে না। সঠিক architecture-এর জন্য build করাই সমাধান। কোনো configuration পরিবর্তন করলে x86-64 binary ARM-এ native ভাবে চলবে না।

arm64 কি aarch64-এরই সমান?

হ্যাঁ। 64-bit ARM instruction set বোঝাতে এটি দুটি নাম। Kernel uname -m-এর মাধ্যমে aarch64 report করে, আর Debian ও Ubuntu packaging এবং Docker platform string-এ arm64 ব্যবহার করা হয়। অন্য দিকেও একই বিভাজন আছে। সেখানে uname -m হলো x86_64, আর packaging-এ amd64 বলা হয়। কোনো download page-এ শুধু aarch64 file থাকলে, dpkg --print-architecture যে machine-কে arm64 বলে, সেই machine-এর জন্য সেগুলোই সঠিক file।

ARM VPS কি x86 VPS-এর চেয়ে দ্রুত?

এর কোনো সাধারণ উত্তর নেই। আপনি যে একক ratio পড়েছেন, সেটি এমন hardware-এ মাপা হয়েছে যা আপনার hardware নয়। গতি নির্ভর করে নির্দিষ্ট CPU model, আপনাকে দেওয়া core-এর সংখ্যা, provider tenant-গুলোর মধ্যে contention কীভাবে পরিচালনা করে, এবং আপনার workload vector instruction কতটা ভালোভাবে ব্যবহার করে তার ওপর। আপনি যে দুটি plan-এর মধ্যে বেছে নিচ্ছেন, সেগুলো আপনার নিজের workload দিয়ে benchmark করুন, সম্ভব হলে। এরপর সেই ফলাফল তুলনা করুন।

Production server arm64-এ সরানোর আগে কী পরীক্ষা করা উচিত?

এই ক্রমে চারটি পরীক্ষা করুন। প্রতিটি container image-এর arm64 manifest আছে কি না নিশ্চিত করুন। প্রতিটি third-party apt repository binary-arm64 publish করে কি না নিশ্চিত করুন। প্রতিটি closed-source agent-এর aarch64 download আছে কি না নিশ্চিত করুন। এরপর target instance-এ getconf PAGESIZE চালান, কারণ 64 KiB page kernel-এ অনেক ছোট mapping থাকা process-এর memory footprint পরিবর্তিত হয়। এই চারটি পরীক্ষার যেকোনো একটিতে ব্যর্থতা হলে সংশ্লিষ্ট server-টি x86-এ রাখার কারণ রয়েছে।