SSD Nodes Learn 🎉 VPS $5.50/মাস থেকে
নির্দেশিকা Matt Connorদ্বারা Matt Connor

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

ARM VPS-এ প্রতি core-এর খরচ কম হতে পারে, কিন্তু arm64 compatibility জরুরি। আপনার stack-এর software ও container image চলে কি না, তা commands দিয়ে যাচাই করুন।

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-এর জন্য অর্থ দেওয়ার আগে নিচের commands আপনার নিজের 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 থাকে। সেখানে aes pmull sha1 sha2-এর মতো flags হিসেবে hardware crypto দেখা যায়। এগুলো ARMv8 Cryptographic Extensions। Intel ও AMD processor-এ AES-NI যে কাজ করে, এগুলোও একই কাজ করে: TLS (transport layer security) এবং disk encryption হার্ডওয়্যারে দ্রুত সম্পন্ন করে। VPS-এ AES hardware acceleration পরীক্ষা করা উভয় architecture-এ এই পরীক্ষা দেখায়।

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

প্রতিটি Docker image manifest-এ এটি কোন architecture-এর জন্য তৈরি হয়েছে তা উল্লেখ থাকে। শুধু amd64 manifest থাকা কোনো image arm64 host-এ pull করলে 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 দিয়ে এটি ঠিক করা যায় না। প্রয়োজনীয় 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 ব্যবহারের জন্য host setup উভয় architecture-এই একই: VPS-এ Docker চালানো অংশে এটি ব্যাখ্যা করা হয়েছে। Compose file-এ থাকা প্রতিটি image-এ arm64 manifest থাকলে বিদ্যমান Compose file কোনো পরিবর্তন ছাড়াই কাজ করবে।

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

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

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

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

apt-cache policy-এর output-এ 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] দিয়ে pin করা কোনো line arm64 host-এ বাদ পড়ে। তাই package অনুপস্থিত মনে হয়, যদিও প্রকৃত কারণ হলো pin।

কোন workloads নিরাপদ, আর কোনগুলোর জন্য আগে যাচাই দরকার

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 সমর্থন করে। প্রকৃত ঝুঁকি হলো নির্দিষ্ট করে রাখা পুরোনো version। কয়েক বছর আগের কোনো runtime release ইনস্টল করা deploy script থাকলে, সেটি কাজ করবে ধরে না নিয়ে ওই release-এর notes-এ aarch64 support যাচাই করুন।

নিজে লেখা x86 assembly অথবা SSE ও AVX intrinsic ব্যবহার করা library-গুলো তুলনামূলক কম স্পষ্ট ক্ষেত্র। বেশির ভাগ library-তেই NEON path (NEON হলো ARM-এর vector instruction set) অথবা সাধারণ 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 একইভাবে যাচাই করুন।

কার্নেল ও 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 রেখেছে। 64 KiB page size-এ অনেক ছোট mapping থাকা process-এর memory floor বেড়ে যায়, কারণ kernel যে সবচেয়ে ছোট chunk বরাদ্দ করতে পারে, সেটি ষোলো গুণ বড়। Instance-এ getconf PAGESIZE চালিয়ে সংখ্যাটি দেখুন; অনুমান করবেন না।

আরও কয়েকটি ছোট পার্থক্য জানা দরকার। 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 server platform কি পরিণত হয়েছে?

Software-এর দিক থেকে, হ্যাঁ। 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 edition-এর মতোই।

একই announcement-এ দেওয়া caveat-গুলো পড়ুন। এগুলো দেখায়, 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 রয়েছে।

Commit করার আগে চালানোর জন্য একটি checklist

  1. একটি trial 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. getconf PAGESIZE চালান এবং memory নির্ধারণের আগে পাওয়া উত্তরটি নোট করুন।
  6. যে ARM plan এবং x86 plan-এর মধ্যে বেছে নিচ্ছেন, উভয় 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 থাকলে সেগুলো চলবে। প্রতিটি image-এর ক্ষেত্রে docker buildx imagetools inspect <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 execute করার চেষ্টা করেছে, যার ELF header-এ ভিন্ন machine type উল্লেখ আছে, তাই kernel সেটি প্রত্যাখ্যান করেছে। 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 ব্যবহার করা হয়। অন্য architecture-এর ক্ষেত্রেও একই বিভাজন আছে। সেখানে uname -m হলো x86_64, আর packaging-এ amd64 লেখা থাকে। কোনো download page-এ শুধু aarch64 file থাকলে, dpkg --print-architecture যাকে arm64 বলে, সেই machine-এর জন্য এগুলোই সঠিক file।

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

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

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

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

#arm64#cpu-architecture#vps#docker#performance