ARM VPS vs x86: Je, inafaa kuhama?

Mabadiliko yanayotokea unapohamia ARM VPS

ARM VPS huendesha Linux ileile na Nginx ileile kama x86 VPS, na kwa kawaida huwa na gharama nafuu zaidi kwa kila core. Hatari ya kuhama inatokana na utangamano (compatibility). Programu iliyokusanywa (compiled) kwa ajili ya x86-64 haiwezi kuendesha kabisa kwenye arm64, kwa hivyo kila kipengele cha programu katika stack yako lazima kiwe na toleo la arm64 au kiwe kitu unachoweza kukijenga upya.

Stack nyingi za kisasa hufaulu jaribio hili bila kazi ya ziada. Kushindwa huku hujitokeza katika maeneo mawili: picha za container (container images) zilizojengwa kwa ajili ya usanifu mmoja tu, na programu za closed-source zisizo na upakuaji wa arm64. Amri zilizo hapa chini zinajibu maswali yote mawili kwa ajili ya stack yako mwenyewe kabla ya kulipia instance. Ikiwa bado unafanya maamuzi kuhusu aina ya seva unayohitaji, anza na nini maana ya VPS na jinsi inavyotofautiana na shared hosting.

arm64, aarch64, amd64: majina haya yanamaanisha nini

Tekeleza amri hizi kwenye seva yoyote kabla ya kitu kingine chochote.

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

uname -m huchapisha aarch64 kwenye mashine ya ARM na x86_64 kwenye mashine ya Intel au AMD. dpkg --print-architecture huchapisha arm64 na amd64 kwa mashine hizo mbili. Majibu yote mawili ni sahihi. Kernel ya Linux na mfumo wa vifurushi wa Debian vilichagua majina tofauti kwa seti moja ya maelekezo (instruction set), kwa hivyo aarch64 na arm64 yanamaanisha kitu kimoja, na x86_64 na amd64 yanamaanisha kingine. Docker hutumia majina ya mtindo wa Debian, ndiyo maana jukwaa la image husoma linux/arm64.

Kwenye arm64 hakuna mstari wa model name katika /proc/cpuinfo. Badala yake utapata sehemu ya Features, na crypto ya maunzi huonekana hapo kama flag kama aes pmull sha1 sha2. Hizo ni ARMv8 Cryptographic Extensions, na hufanya kazi ile ile ambayo AES-NI hufanya kwenye sehemu za Intel na AMD: hufanya TLS (transport layer security) na usimbaji wa diski kuwa wa haraka kupitia maunzi. Kuangalia kasi ya AES kwenye maunzi ya VPS inaelezea jaribio hilo kwa usanifu wote miwili.

Kwa nini container huvunjika kwanza, na error hiyo huonekanaje

Kila manifest ya Docker image hurekodi usanifu (architecture) ambao ilijengewa. Ukivuta image yenye manifest ya amd64 pekee kwenye host ya arm64, uvutaji utafanikiwa. Failure hutokea wakati wa kuanzisha mchakato wa kwanza:

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 ni kernel inayokataa kuendesha faili hiyo, kwa sababu header yake ya ELF (executable and linkable format) inataja aina ya mashine ambayo CPU hii haitekelezi. Hakuna mpangilio unaoweza kurekebisha hili. Maelekezo hayo hayapo kwenye silicon.

Kagua manifest kabla ya ku-deploy:

docker buildx imagetools inspect nginx:1.27

Matokeo huorodhesha mstari mmoja wa Platform: kwa kila image kwenye orodha ya manifest, kama vile linux/amd64 na linux/arm64. Ikiwa linux/arm64 haipo, tag hiyo haitaanza kwenye ARM VPS. docker manifest inspect --verbose nginx:1.27 huonyesha taarifa hiyo hiyo, lakini Docker huandika docker manifest kama amri ya majaribio ambayo tabia yake inaweza kubadilika kati ya releases, kwa hivyo pendelea imagetools.

Kwa images unazojijengea mwenyewe, jenga usanifu wote miwili kwa amri moja na usukume (push) orodha ya manifest:

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

Kujenga kwa ajili ya usanifu wa kigeni kwenye host moja kunahitaji QEMU user mode emulation iliyosajiliwa na handler ya binfmt_misc ya kernel:

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

Tumia emulation kwa ajili ya kujenga na kupima. Usiitumie kuhudumia traffic. Nyaraka za Docker zenyewe zinasema kuwa emulation na QEMU "inaweza kuwa polepole sana kuliko builds za asili, hasa kwa kazi nzito za kompyuta kama compilation na compression au decompression", kwa hivyo huduma ya x86 iliyoigizwa kwenye instance ya ARM hufuta akiba iliyokufanya uhame. Usanidi wa host kwa ajili ya hali ya asili ni sawa kwenye usanifu wote miwili: kuendesha Docker kwenye VPS inalishughulikia, na faili ya Compose iliyopo hufanya kazi bila kubadilishwa pindi kila image ndani yake inapokuwa na manifest ya arm64.

Je, vifurushi ninavyohitaji vitapatikana kwenye arm64?

Ubuntu na Debian hujenga karibu kumbukumbu nzima kwa ajili ya arm64, kwa hivyo apt install nginx postgresql redis-server hufanya kazi kwa njia ile ile kwenye usanifu wote miwili. Mapungufu hutokea kwenye hazina (repositories) za watu wengine.

Uliza apt moja kwa moja, kwenye mfano wa ARM:

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

apt-cache policy kuripoti Candidate: (none) inamaanisha hakuna hazina iliyowezeshwa inayochapisha toleo la kifurushi hicho kwa usanifu huu. apt-get install -s huiga usakinishaji na haiandiki chochote, na katika hali hiyo hiyo huishia na E: Unable to locate package.

Kisha soma matokeo ya apt update badala ya kuyapita kwa kusogeza skrini. Hazina ya muuzaji ambayo ni ya amd64 pekee husema hivyo:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

Hazina hiyo imesanidiwa na inafikika, na haina chochote ambacho mashine hii inaweza kusakinisha. Kagua pia ingizo la chanzo lenyewe. Mstari uliowekewa pini na [arch=amd64] hurukwa kwenye mwenyeji wa arm64, kwa hivyo kifurushi huonekana hakipo wakati sababu halisi ni ile pini.

Ni workloads zipi zilizo salama, na zipi zinahitaji ukaguzi kwanza

Runtime zinazotumia interpreter na bytecode zina uwezo wa kufanya kazi kwenye mifumo tofauti (portable). PHP, Python, Ruby na Node.js zote zina vifurushi vya arm64 katika usambazaji mkuu wa Linux. Go na Rust zinaweza kufanyiwa cross-compile kwenda arm64 kwa kuweka target moja tu. LEMP stack, Node API, binary ya Go inayokimbia nyuma ya Nginx, au database ya Postgres ni kazi za kawaida kwenye arm64.

Compiler ya just-in-time (JIT) hutengeneza machine code wakati programu inafanya kazi, hivyo inahitaji jenereta ya code kwa ajili ya usanifu (architecture) husika. Matoleo ya sasa yanayo: OpenJDK, .NET, injini ya V8 iliyo ndani ya Node.js, na PyPy zote zinaunga mkono arm64 kwenye Linux. Matoleo ya zamani yaliyofungwa (pinned) ndiyo hatari halisi. Script ya deploy inayopakua toleo la runtime la miaka kadhaa iliyopita inapaswa kukaguliwa dhidi ya maelezo ya toleo hilo kuhusu usaidizi wa aarch64 badala ya kudhani kuwa itafanya kazi.

Maktaba (libraries) zenye assembly ya x86 iliyoandikwa kwa mkono, au maelekezo ya SSE na AVX, ni kesi tulivu zaidi. Nyingi pia zina njia ya NEON (NEON ni seti ya maelekezo ya vector ya ARM) au njia mbadala ya C, hivyo huweza kukusanywa (compile) na kufanya kazi. Utendaji unaweza kutofautiana na ule wa x86 kwa njia yoyote ile. Pima utendaji huo kwenye instance yako badala ya kuutabiri kutoka kwenye makala.

Programu za closed-source ndizo kikwazo cha kweli. Wakala wa ufuatiliaji wa vendor, driver ya database yenye leseni, control panel ya kibiashara, au daemon ya anti-virus huja kama binary iliyokusanywa, na vendor asipotoa toleo la arm64, hakuna unachoweza kufanya. cPanel na WHM ndiyo mfano dhahiri zaidi katika hosting: mahitaji ya mfumo wake yanataja x86_64 na hayataji ARM, hivyo seva ya control panel inabaki kwenye x86 (ilithibitishwa Agosti 2026, na inafaa kusoma tena ukurasa wa mahitaji wa vendor mwenyewe). Ikiwa hilo ndilo jambo pekee linalokuzuia, njia mbadala za cPanel zinazofaa kuendeshwa kwenye VPS ndipo pa kuanzia, na kagua usaidizi wa usanifu wa kila moja kwa njia hiyo hiyo.

Kernels na ukubwa wa page: mahali ambapo ARM instances bado zinatofautiana

Seva za x86-64 zinaweza kubadilishana karibu bila matatizo. Seva za ARM hazifanani sana, na tofauti hizo zipo chini ya programu yako.

Ukubwa wa page (page size) ni jambo moja linaloathiri uzalishaji (production). Kernels nyingi za arm64 hutumia page za 4 KiB, sawa na x86-64. Nyingine hutumia 64 KiB. Red Hat Enterprise Linux 8 kwa aarch64 ilikuja na kernel ya 64 KiB page kama chaguo-msingi, na RHEL 9 ilirudisha chaguo-msingi kwenye 4 KiB huku ikihifadhi kifurushi tofauti cha kernel-64k kwa ajili ya workloads zinazohitaji ukubwa mkubwa zaidi. Ukubwa wa page wa 64 KiB huongeza kiwango cha chini cha kumbukumbu kinachohitajika kwa mchakato (process) wenye mappings nyingi ndogo, kwa sababu kipande kidogo zaidi ambacho kernel inaweza kutoa ni kikubwa mara kumi na sita. Endesha getconf PAGESIZE kwenye instance na usome namba hiyo badala ya kudhani. Ukubwa wa page si uamuzi pekee wa kernel unaokufikia, kwa sababu toleo ambalo mtoa huduma wako analitoa pia huongoza jinsi kazi inavyopangwa kwenye cores, na scheduling inayozingatia cache iliyoongezwa kwenye Linux 7.2 inafika kwenye arm64 na x86-64 vilevile.

Kuna tofauti chache ndogo zinazofaa kujulikana. Hakuna kifurushi cha CPU microcode cha mfumo wa uendeshaji kwenye arm64, kwa hivyo masasisho ya firmware hutoka kwa mtoa huduma wako na si kutoka apt. Seva za ARM huwaka kupitia UEFI (unified extensible firmware interface) na huelezea maunzi yao kupitia ACPI (advanced configuration and power interface). Baadhi ya vipengele vya x86 havina mbadala wowote kwenye ARM, ikiwemo AMD SEV memory encryption na Intel GVT-g mediated GPUs.

Je, jukwaa la seva la ARM limekomaa?

Kwa upande wa programu, ndiyo. Debian, Ubuntu, Fedora na RHEL zote hutoa matoleo ya arm64 ya kiwango cha juu, na picha rasmi kwenye Docker Hub ni za usanifu mwingi (multi-arch) kama kawaida.

Ushahidi wa wazi zaidi wa hivi karibuni ni Proxmox. Mnamo tarehe 5 Agosti 2026, Proxmox ilitangaza toleo la kwanza linaloungwa mkono rasmi la arm64 la Proxmox Virtual Environment, toleo la 9.2, likishiriki hazina za vifurushi (package repositories) na mzunguko wa maisha wa toleo (release lifecycle) na toleo la x86-64. Imejengwa juu ya Debian 13.5 ikiwa na Linux 7.0, QEMU 11.0, LXC 7.0 na ZFS 2.4, na usanidi pamoja na zana zinalingana na x86-64 isipokuwa kwa seti ndogo ya vipengele maalum vya usanifu.

Soma tahadhari katika tangazo hilo hilo, kwa sababu zinaonyesha jinsi vifaa vya seva vya ARM vinavyoungwa mkono rasmi bado ni vichache. Proxmox ilithibitisha mifumo ya NVIDIA Grace na NVIDIA Vera siku ya kwanza, baada ya majaribio ya pamoja na NVIDIA na Supermicro kwenye vifaa vya Grace Hopper. Vifaa vingine vya ARMv8-A na ARMv9-A vinavyotumia UEFI hupata usaidizi wa kadiri ya uwezo (best effort support). Kompyuta za ubao mmoja (single board computers) zinazotumia device tree pekee kama Raspberry Pi hazitumiki. Mgeni (guest) huendeshwa tu kwenye node ya usanifu wake, uhamiaji wa moja kwa moja (live migration) hufanya kazi tu kati ya node za usanifu uleule, na makundi (clusters) ya usanifu mchanganyiko hayatumiki rasmi.

Hiyo ndiyo hali ya kweli kufikia Agosti 2026. Muuzaji wa hypervisor anayetoa arm64 kwenye mzunguko wa maisha uleule na x86-64 ni maendeleo ya kweli kwa jukwaa hili. Orodha ya vifaa vinavyoungwa mkono siku ya kwanza ni familia mbili za CPU.

Orodha ya ukaguzi kabla ya kufanya commit

1. Tekeleza uname -m kwenye mfano wa majaribio na uhakikishe kuwa inachapisha aarch64.
2. Tekeleza docker buildx imagetools inspect kwenye kila image iliyo kwenye faili yako ya Compose na uhakikishe kuwa kuna mstari wa platform wa linux/arm64 kwa kila moja.
3. Tekeleza apt update kwenye mfano wa ARM na usome kila onyo la Skipping acquire linalochapishwa.
4. Fungua ukurasa wa kupakua kwa kila wakala (agent) wa closed source unaoutegemea na utafute toleo la arm64 au aarch64 kwa jina.
5. Tekeleza getconf PAGESIZE na uandike jibu kabla ya kupanga ukubwa wa kumbukumbu (memory).
6. Tekeleza benchmark yako mwenyewe kwenye mpango wa ARM na mpango wa x86 unaochagua kati ya hizo mbili.

Mambo ambayo chapisho hili halidai

Hatutakupatia uwiano wa bei kwa utendaji kati ya ARM na x86. Bei kwa kila core hutofautiana kulingana na mtoa huduma na mpango, na namba iliyopimwa kwenye maunzi ya mtu mwingine haitabiri matokeo yako. Badala yake, pima mwenyewe. Mwongozo wetu wa kufanya benchmarking ya VPS unashughulikia sysbench na fio kwa mbinu unayoweza kuirudia, na gharama halisi ya VPS inashughulikia upande wa bei wa ulinganisho huo. Hifadhi (storage) ni uamuzi tofauti na usanifu wa CPU, na jinsi NVMe inavyolinganishwa na SATA SSD kwenye VPS inashughulikia nusu hiyo. Fanya jaribio lilelile kwenye mipango yote miwili, ukitumia mzigo wako wa kazi (workload) pale inapowezekana, na acha namba zako ziamue.

FAQ

Je, Docker containers zangu zitaendesha kwenye ARM VPS?

Zitaendesha ikiwa kila image katika stack ina ingizo la linux/arm64 kwenye manifest yake. Kagua kila moja kwa kutumia docker buildx imagetools inspect <image> na utafute mstari wa Platform: linux/arm64. Images rasmi kwenye Docker Hub kwa kawaida huwa ni multi-arch. Images kutoka kwa watoa huduma wadogo, na images ulizojijengea mwenyewe kwenye mashine ya x86, mara nyingi huwa si hivyo. Kwa images zako mwenyewe, jenga upya kwa kutumia docker buildx build --platform linux/amd64,linux/arm64 ... --push ili tag moja ihudumie usanifu wote miwili.

exec format error inamaanisha nini kwenye seva ya ARM?

Kernel ilijaribu kutekeleza binary ambayo ELF header yake inataja aina tofauti ya mashine, na ikakataa. Kwenye host ya arm64 hii karibu kila mara inamaanisha binary ya x86-64 au container image. Docker huchapisha onyo kwanza, ikisema kuwa platform ya image iliyoombwa linux/amd64 hailingani na platform ya host iliyogunduliwa linux/arm64/v8. Suluhisho ni kujenga (build) kwa ajili ya usanifu sahihi. Hakuna mabadiliko ya usanidi yanayoweza kufanya binary ya x86-64 iendeshe kiasili (natively) kwenye ARM.

Je, arm64 ni kitu kimoja na aarch64?

Ndiyo. Hayo ni majina mawili ya seti ya maelekezo (instruction set) ya 64-bit ARM. Kernel huripoti aarch64 kupitia uname -m, wakati upakiaji wa Debian na Ubuntu, na kamba za platform za Docker, hutumia arm64. Mgawanyiko uleule upo upande mwingine, ambapo uname -m husema x86_64 na upakiaji husema amd64. Ikiwa ukurasa wa kupakua unatoa faili za aarch64 pekee, hizo ndizo faili sahihi kwa mashine ambayo dpkg --print-architecture huiita arm64.

Je, ARM VPS ni ya haraka kuliko x86 VPS?

Swali hilo halina jibu la jumla, na uwiano wowote unaosoma ulipimwa kwenye vifaa ambavyo si vyako. Kasi inategemea mfano mahususi wa CPU, idadi ya cores ulizopewa, jinsi mtoa huduma anavyoshughulikia ushindani kati ya wapangaji, na jinsi workload yako inavyotumia vector instructions. Fanya benchmark ya mipango miwili unayochagua, ukitumia workload yako mwenyewe ikiwa unaweza, na ulinganishe namba hizo.

Nipaswa kukagua nini kabla ya kuhamisha seva ya production kwenda arm64?

Ukaguzi nne, kwa mpangilio huu. Thibitisha kila container image ina manifest ya arm64. Thibitisha kila hazina (repository) ya apt ya wahusika wengine inachapisha binary-arm64. Thibitisha kila wakala (agent) wa chanzo kilichofungwa (closed source) una download ya aarch64. Kisha endesha getconf PAGESIZE kwenye instance lengwa, kwa sababu kernel ya 64 KiB page hubadilisha matumizi ya kumbukumbu ya michakato yenye mappings nyingi ndogo. Kitu chochote kinachofeli mojawapo ya ukaguzi huo minne ni sababu ya kuiweka seva hiyo mahususi kwenye x86.