ARM VPS vs 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 वर हे command चालवा.

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

ARM मशीनवर uname -m हे 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 field मिळते. त्यात hardware crypto aes pmull sha1 sha2 सारख्या flags द्वारे दिसते. हे ARMv8 Cryptographic Extensions आहेत. Intel आणि AMD processor मध्ये AES-NI जे काम करते, तेच हे करतात: TLS (transport layer security) आणि disk encryption hardware मध्ये जलद चालवतात. VPS वर AES hardware acceleration तपासणे या दोन्ही architectures वरील चाचणीचे वर्णन करते.

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

प्रत्येक Docker image manifest मध्ये ती image कोणत्या architecture साठी तयार केली आहे, याची नोंद असते. केवळ 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 कडून समर्थित नसलेला machine type नमूद केलेला असतो. कोणतीही 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 वर सुरू होणार नाही. 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

Build आणि test करण्यासाठी emulation वापरा. Network traffic serve करण्यासाठी ते वापरू नका. Docker च्या documentation नुसार QEMU सह emulation "native builds पेक्षा खूपच धीमे असू शकते, विशेषतः compilation आणि compression किंवा decompression सारख्या compute-heavy tasks साठी". त्यामुळे ARM instance वर emulated x86 service चालवल्यास, तुम्ही स्थलांतर करण्यामागील बचत पुन्हा कमी होते. 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) दिसत असल्यास, सक्षम केलेल्या कोणत्याही repository मध्ये या architecture साठी त्या पॅकेजची build प्रकाशित केलेली नाही. apt-get install -s install चे अनुकरण करते आणि काहीही लिहित नाही. त्याच परिस्थितीत ते E: Unable to locate package ने समाप्त होते.

त्यानंतर apt update चे output वाचा. ते न वाचता पुढे scroll करू नका. एखादी 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 आहे, पण या मशीनवर install करता येईल असे कोणतेही पॅकेज त्यात नाही. Source entry स्वतःही तपासा. [arch=amd64] ने pinned केलेली line arm64 host वर वगळली जाते. त्यामुळे पॅकेज missing असल्याचे दिसते, पण खरे कारण pin असते.

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

Interpreted आणि bytecode runtimes हे मुळातच 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 वरची नेहमीची कामे आहेत.

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

Hand-written x86 assembly किंवा SSE आणि AVX intrinsics असलेल्या libraries हे तुलनेने कमी स्पष्ट प्रकरण आहे. त्यांपैकी बहुतेकांकडे NEON path (NEON हा ARM चा vector instruction set आहे) किंवा plain C fallback असतो. त्यामुळे त्या compile होऊन चालतात. 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 instances मध्ये अजूनही कुठे फरक आहेत

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

Production मध्ये परिणाम करणारा मुख्य फरक 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 करण्यात आला आणि मोठा size आवश्यक असलेल्या workloads साठी स्वतंत्र kernel-64k package ठेवण्यात आला. अनेक लहान mappings असलेल्या process साठी 64 KiB page size मुळे आवश्यक memory floor वाढतो, कारण kernel देऊ शकणारा सर्वात लहान chunk सोळा पट मोठा असतो. Instance वर getconf PAGESIZE चालवून तो आकडा वाचा; अंदाजावर अवलंबून राहू नका.

काही लहान फरक जाणून घेणे उपयुक्त ठरते. 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 साठी package repositories आणि release lifecycle x86-64 edition प्रमाणेच आहेत. ती Debian 13.5, Linux 7.0, QEMU 11.0, LXC 7.0 आणि ZFS 2.4 वर आधारित आहे. काही मोजक्या architecture-specific बाबी वगळता तिची configuration आणि tooling x86-64 प्रमाणेच आहेत.

त्याच announcement मधील caveats वाचा. अधिकृतरीत्या समर्थित ARM server hardware अजूनही किती मर्यादित आहे, हे त्यातून स्पष्ट होते. 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-only single-board computers, जसे Raspberry Pi, समर्थित नाहीत. एखादा guest फक्त त्याच architecture असलेल्या node वर चालतो. Live migration फक्त समान architecture असलेल्या nodes दरम्यान कार्य करते. Mixed-architecture clusters अधिकृतरीत्या समर्थित नाहीत.

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

कमिट करण्यापूर्वी करायची तपासणी

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. getconf PAGESIZE चालवा आणि memory चे sizing करण्यापूर्वी मिळालेले उत्तर नोंदवा.
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 वापरा. त्यानंतर तुमचे मोजमापच अंतिम निर्णय ठरवू द्या.

FAQ

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

Stack मधील प्रत्येक 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 साठी image उपलब्ध होईल.

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

Kernel ने वेगळ्या machine type चे नाव असलेल्या ELF headerचा binary execute करण्याचा प्रयत्न केला आणि तो नाकारला. arm64 host वर याचा अर्थ जवळजवळ नेहमी x86-64 binary किंवा container image असा होतो. Docker आधी warning दाखवते आणि requested 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 report करते, तर 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 तुमच्या हार्डवेअरपेक्षा वेगळ्या हार्डवेअरवर मोजलेले असते. वेग विशिष्ट CPU model, तुम्हाला दिलेल्या cores ची संख्या, provider tenants मधील contention कसा हाताळतो आणि तुमचा workload vector instructions चा किती चांगला वापर करतो यावर अवलंबून असतो. तुम्ही प्रत्यक्ष निवडत असलेल्या दोन्ही plans चे benchmark करा. शक्य असल्यास तुमच्या स्वतःच्या workload सह benchmark करा आणि त्या numbers ची तुलना करा.

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