ARM VPS आणि x86 VPS: प्रत्यक्षात काय बदलते

ARM VPS वर स्थलांतर केल्यावर काय बदलते

ARM VPS वर x86 VPS प्रमाणेच Linux आणि Nginx चालतात. प्रत्येक core साठीची किंमत सहसा कमी असते. मात्र बदल करताना compatibility हा मुख्य धोका असतो. x86-64 साठी compile केलेला प्रोग्राम arm64 वर मुळीच चालत नाही. त्यामुळे तुमच्या stack मधील प्रत्येक software साठी arm64 build उपलब्ध असणे किंवा ते पुन्हा build करता येणे आवश्यक आहे.

बहुतेक आधुनिक stack मध्ये यासाठी अतिरिक्त काम लागत नाही. समस्या प्रामुख्याने दोन ठिकाणी येतात: फक्त एका architecture साठी build केलेल्या container images आणि arm64 download उपलब्ध नसलेले closed-source software. Instance साठी पैसे देण्यापूर्वी तुमच्या stack संदर्भात या दोन्ही प्रश्नांची उत्तरे खालील commands देतात. तुम्हाला अजून कोणत्या प्रकारचा server आवश्यक आहे हे ठरवत असाल, तर आधी VPS म्हणजे काय आणि तो shared hosting पेक्षा कसा वेगळा आहे हे वाचा.

arm64, aarch64, amd64: कोणते नाव कशासाठी आहे

इतर कोणतीही कृती करण्यापूर्वी कोणत्याही instance वर हे commands चालवा.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

ARM machine वर uname -m चे output aarch64 येते, तर Intel किंवा AMD machine वर x86_64 येते. त्याच दोन machine साठी 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 processor वर AES-NI जे काम करते, तेच या extensions करतात: TLS (transport layer security) आणि disk encryption ही कामे hardware मध्ये जलद करतात. VPS वर AES hardware acceleration तपासणे या दोन्ही architectures वरील चाचणीचे वर्णन करते.

कंटेनर सर्वप्रथम का बिघडतात आणि त्रुटी कशी दिसते

प्रत्येक Docker image manifest मध्ये ती कोणत्या architecture साठी build केली आहे, याची नोंद असते. केवळ amd64 manifest असलेली image arm64 host वर pull केली तरी pull यशस्वी होते. पहिली process सुरू करताना अपयश येते:

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 मध्ये या CPU ने implement न केलेला machine type नमूद केलेला असतो. कोणतीही setting हे दुरुस्त करू शकत नाही. ही instructions CPU च्या 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 वर सुरू होणार नाही. docker manifest inspect --verbose nginx:1.27 हीच माहिती दाखवते. मात्र Docker च्या documentation नुसार 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 नोंदणीकृत असणे आवश्यक आहे:

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 दोन्ही architectures वर समान असते: VPS वर Docker चालवणे यात त्याची माहिती आहे. तसेच, त्यातील प्रत्येक image ला arm64 manifest उपलब्ध असल्यास, विद्यमान Compose file मध्ये कोणताही बदल न करता ती कार्य करते.

arm64 साठी आवश्यक पॅकेज उपलब्ध असतील का?

Ubuntu आणि Debian हे arm64 साठी जवळजवळ संपूर्ण archive 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 मध्ये 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 वर install करता येईल असे कोणतेही package त्यात नाही. Source entry स्वतःही तपासा. [arch=amd64] ने pinned केलेली line arm64 host वर वगळली जाते. त्यामुळे package missing असल्यासारखे दिसते, पण खरे कारण pin असते.

कोणते workload सुरक्षित आहेत आणि कोणत्यांसाठी आधी तपासणी आवश्यक आहे

Interpreted आणि bytecode runtime हे मुळातच portable असतात. PHP, Python, Ruby आणि Node.js या सर्वांसाठी मुख्य distributions मध्ये arm64 packages उपलब्ध आहेत. एक target सेट करून Go आणि Rust arm64 साठी cross-compile करता येतात. LEMP stack, Node API, Nginx मागे चालणारा Go binary किंवा Postgres database हे arm64 वर नेहमीचे workload आहेत.

Just in time (JIT) compiler प्रोग्राम चालू असताना machine code तयार करतो. त्यामुळे target architecture साठी त्याला code generator आवश्यक असतो. सध्याच्या versions मध्ये तो उपलब्ध आहे: OpenJDK, .NET, Node.js मधील V8 engine आणि PyPy हे सर्व Linux वर arm64 support करतात. खरा धोका जुन्या, ठरावीक versions मध्ये असतो. अनेक वर्षांपूर्वीचा runtime release install करणारी deploy script असल्यास, ती चालेल असे गृहीत धरू नका. त्याऐवजी त्या release च्या notes मध्ये aarch64 support तपासा.

स्वतः लिहिलेल्या x86 assembly किंवा SSE आणि AVX intrinsics असलेल्या libraries हे तुलनेने कमी स्पष्ट प्रकरण आहे. त्यांपैकी बहुतेक libraries मध्ये 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 alternatives येथून सुरुवात करा. प्रत्येक alternative चे architecture support याच पद्धतीने तपासा.

कर्नल आणि page size: ARM instances अजूनही कुठे वेगळे आहेत

x86-64 servers जवळजवळ परस्परविनिमय करण्याजोगे असतात. ARM servers मध्ये एकसारखेपणा कमी असतो आणि हे फरक तुमच्या application च्या खालच्या स्तरावर असतात.

Production environment वर परिणाम करणारा मुख्य फरक page size हा आहे. बहुतेक arm64 kernels 4 KiB pages वापरतात, जे x86-64 प्रमाणेच आहे. काही kernels 64 KiB pages वापरतात. Red Hat Enterprise Linux 8 for aarch64 मध्ये default म्हणून 64 KiB page kernel release करण्यात आला होता. RHEL 9 मध्ये default पुन्हा 4 KiB करण्यात आला, परंतु मोठ्या page size ची गरज असलेल्या workloads साठी स्वतंत्र kernel-64k package ठेवण्यात आले. 64 KiB page size मुळे अनेक small mappings असलेल्या process साठी आवश्यक किमान memory वाढते, कारण kernel देऊ शकणारा सर्वात लहान chunk सोळा पट मोठा असतो. Instance वर getconf PAGESIZE चालवून ही संख्या वाचा; अंदाजावर अवलंबून राहू नका. Page size हा तुमच्यापर्यंत पोहोचणारा एकमेव kernel निर्णय नाही. Provider कडून release केलेली kernel version cores वर work कसे schedule केले जाते हे देखील ठरवते. तसेच Linux 7.2 मध्ये जोडलेले cache-aware scheduling arm64 आणि x86-64 दोन्हींवर लागू होते.

काही लहान फरक जाणून घेणे उपयुक्त ठरते. arm64 वर operating system CPU microcode package नसते. त्यामुळे firmware updates apt कडून नव्हे, तर तुमच्या provider कडून येतात. ARM servers UEFI (unified extensible firmware interface) द्वारे boot होतात आणि त्यांचे hardware ACPI (advanced configuration and power interface) द्वारे वर्णन केले जाते. काही x86 features साठी ARM वर कोणताही counterpart नाही. यामध्ये AMD SEV memory encryption आणि Intel GVT-g mediated GPUs यांचा समावेश होतो.

ARM सर्व्हर प्लॅटफॉर्म परिपक्व झाला आहे का?

सॉफ्टवेअरच्या बाबतीत, होय. Debian, Ubuntu, Fedora आणि RHEL हे सर्व प्रथम-श्रेणीचे arm64 builds रिलीज करतात. Docker Hub वरील अधिकृत images सामान्यतः multi-arch असतात.

याचे अलीकडील सर्वात स्पष्ट उदाहरण Proxmox आहे. 5 August 2026 रोजी Proxmox ने Proxmox Virtual Environment ची पहिली अधिकृतपणे समर्थित arm64 edition, version 9.2, जाहीर केली. ही edition x86-64 edition सोबत package repositories आणि release lifecycle सामायिक करते. ती Debian 13.5, Linux 7.0, QEMU 11.0, LXC 7.0 आणि ZFS 2.4 वर आधारित आहे. काही मोजक्या architecture-specific बाबी वगळता configuration आणि tooling x86-64 प्रमाणेच आहेत.

त्याच announcement मधील मर्यादा वाचा. अधिकृतपणे समर्थित ARM सर्व्हर हार्डवेअरची व्याप्ती अजूनही किती मर्यादित आहे, हे त्यातून स्पष्ट होते. Proxmox ने पहिल्याच दिवशी NVIDIA Grace आणि NVIDIA Vera systems validate केले. यासाठी NVIDIA आणि Supermicro सोबत Grace Hopper hardware वर संयुक्त testing करण्यात आली. इतर UEFI-based ARMv8-A आणि ARMv9-A hardware साठी best-effort support मिळतो. फक्त device tree वापरणारे Raspberry Pi सारखे single-board computers समर्थित नाहीत. Guest फक्त त्याच architecture असलेल्या node वर चालतो. Live migration फक्त समान architecture असलेल्या nodes दरम्यान कार्य करते. Mixed-architecture clusters अधिकृतपणे समर्थित नाहीत.

August 2026 पर्यंतची वास्तविक स्थिती हीच आहे. x86-64 प्रमाणेच समान lifecycle अंतर्गत arm64 रिलीज करणारा hypervisor vendor हा प्लॅटफॉर्मसाठीचा वास्तविक progress आहे. पहिल्या दिवसापासून समर्थित hardware ची यादी मात्र दोन CPU families पुरती मर्यादित आहे.

तुम्ही commit करण्यापूर्वी करायची तपासणीसूची

1. Trial 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 आम्ही देणार नाही. प्रत्येक provider आणि plan नुसार प्रति-core किंमती बदलतात. तसेच इतरांच्या hardware वर मोजलेला एखादा आकडा तुमच्या hardware च्या कामगिरीचा अंदाज देत नाही. त्याऐवजी स्वतः मोजमाप करा. VPS चे benchmarking करण्यासाठी आमचे मार्गदर्शक यामध्ये sysbench आणि fio वापरून पुन्हा करता येईल अशी पद्धत दिली आहे. VPS ची वास्तविक किंमत किती असते या लेखात तुलना करण्याचा pricing भाग स्पष्ट केला आहे. Storage हा CPU architecture पेक्षा स्वतंत्र निर्णय आहे. VPS वर NVMe ची SATA SSD शी तुलना कशी होते यामध्ये त्या विषयाचा आढावा घेतला आहे. दोन्ही plan वर समान test चालवा. शक्य असल्यास तुमचा स्वतःचा workload वापरा. त्यानंतर तुमचे मोजमाप अंतिम निर्णय घेऊ द्या.

FAQ

माझे Docker containers ARM VPS वर चालतील का?

स्टॅकमधील प्रत्येक image च्या manifest मध्ये linux/arm64 entry असल्यास ते चालतील. प्रत्येक image साठी docker buildx imagetools inspect <image> चालवून Platform: linux/arm64 line शोधा. Docker Hub वरील अधिकृत images सहसा multi-arch असतात. लहान vendors कडील images आणि x86 मशीनवर तुम्ही स्वतः build केलेले images अनेकदा multi-arch नसतात. तुमच्या स्वतःच्या images साठी docker buildx build --platform linux/amd64,linux/arm64 ... --push वापरून पुन्हा build करा, म्हणजे एकाच tag मधून दोन्ही architectures पुरवता येतील.

ARM server वर exec format error याचा अर्थ काय?

Kernel ने वेगळ्या machine type चे ELF header असलेला binary चालवण्याचा प्रयत्न केला आणि तो नाकारला. arm64 host वर याचा अर्थ जवळजवळ नेहमी x86-64 binary किंवा container image असा होतो. Docker प्रथम warning दाखवते. त्यात मागितलेल्या image platform linux/amd64 चा detected host platform linux/arm64/v8 शी मेळ नाही असे सांगितलेले असते. योग्य architecture साठी build करणे हा उपाय आहे. Configuration मध्ये बदल करून x86-64 binary ARM वर native पद्धतीने चालवता येत नाही.

arm64 आणि aarch64 एकच आहेत का?

होय. 64-bit ARM instruction set साठी ही दोन नावे आहेत. Kernel uname -m द्वारे aarch64 अहवालित करतो, तर Debian आणि Ubuntu packaging तसेच Docker platform strings मध्ये arm64 वापरले जाते. दुसऱ्या बाजूलाही अशीच विभागणी आहे. तेथे uname -m म्हणजे x86_64, तर packaging मध्ये amd64 वापरले जाते. Download page वर फक्त aarch64 files उपलब्ध असल्यास, dpkg --print-architecture मध्ये arm64 असे दर्शवणाऱ्या मशीनसाठी त्या योग्य files आहेत.

ARM VPS x86 VPS पेक्षा जलद असतो का?

या प्रश्नाचे सर्वसाधारण उत्तर नाही. तुम्ही वाचलेला कोणताही एक ratio तुमच्या hardware पेक्षा वेगळ्या hardware वर मोजलेला असतो. वेग विशिष्ट CPU model, तुम्हाला दिलेल्या cores ची संख्या, provider tenants मधील contention कसा हाताळतो आणि तुमचे workload vector instructions चा किती चांगला वापर करते यावर अवलंबून असतो. तुम्ही प्रत्यक्ष निवडत असलेल्या दोन plans चा benchmark करा. शक्य असल्यास तुमच्या स्वतःच्या workload सह तो करा आणि मिळालेल्या numbers ची तुलना करा.

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 मुळे अनेक लहान mappings असलेल्या processes चा memory footprint बदलतो. या चारपैकी कोणत्याही तपासणीत अपयश आल्यास तो विशिष्ट server x86 वरच ठेवण्याचे ते कारण आहे.