Tofauti kati ya ARM VPS na x86 VPS: Mwongozo wa Kujua

Mabadiliko yanayotokea unapohamia ARM VPS

ARM VPS huendesha Linux ileile na Nginx ileile kama x86 VPS, na kwa kawaida huwa na gharama nafuu kwa kila core. Hatari ya kuhama ni suala la utangamano (compatibility). Programu iliyokusanywa (compiled) kwa ajili ya x86-64 haiwezi kuendeshwa kwenye arm64 hata kidogo, 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 mtihani huo bila kazi yoyote ya ziada. Kushindwa huku hujitokeza katika maeneo mawili: picha za container (container images) zilizojengwa kwa ajili ya usanifu mmoja pekee, na programu za closed-source zisizo na upakuaji wa arm64. Amri zilizo hapa chini zinajibu maswali yote mawili kwa ajili ya stack yako 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 unapata 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 maunzi ya AES kwenye VPS inashughulikia jaribio hilo kwenye usanifu wote miwili.

Kwa nini container huvunjika kwanza, na jinsi error inavyoonekana

Kila manifest ya Docker image hurekodi usanifu (architecture) ambao iliundwa kwa ajili yake. Vuta image yenye manifest ya amd64 pekee kwenye host ya arm64 na 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 hilo, kwa sababu header yake ya ELF (executable and linkable format) inataja aina ya mashine ambayo CPU hii haitekelezi. Hakuna mpangilio unaoweza kurekebisha hili. Maelekezo 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 katika 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 unazojiundia mwenyewe, jenga usanifu wote miwili kwa amri moja na u-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 kujenga na kupima. Usiitumie kuhudumia traffic. Nyaraka za Docker zenyewe zinasema kuwa emulation na QEMU "inaweza kuwa polepole zaidi 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 inarudisha gharama uliyokuwa umeokoa kwa kuhama. Usanidi wa host kwa ajili ya hali ya asili ni sawa kwenye usanifu wote miwili: kuendesha Docker kwenye VPS inashughulikia hilo, na faili la Compose lililopo 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 sawa kwenye usanifu wote wawili. Mapungufu hutokea kwenye hazina (repositories) za watu wengine.

Uliza apt moja kwa moja, kwenye instance ya ARM:

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

apt-cache policy kuripoti Candidate: (none) inamaanisha kuwa 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 haraka. 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, lakini haina chochote ambacho mashine hii inaweza kusakinisha. Kagua pia ingizo la chanzo (source entry) lenyewe. Mstari uliowekewa pini na [arch=amd64] hurukwa kwenye host ya arm64, kwa hivyo kifurushi huonekana hakipo wakati sababu halisi ni ile pini.

Ni workloads zipi zilizo salama, na zipi zinahitaji ukaguzi kwanza

Runtime zinazotumia interpreted 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. Go na Rust zinaweza kufanya cross-compile kwenda arm64 kwa kuweka target moja. LEMP stack, Node API, binary ya Go inayokaa nyuma ya Nginx au database ya Postgres ni kazi ya kawaida kwenye arm64.

Compiler ya just in time (JIT) hutengeneza machine code wakati programu inapoendelea kufanya kazi, hivyo inahitaji code generator kwa ajili ya usanifu wa target. 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 yaliyofungiwa (pinned) ndiyo hatari halisi. Script ya deploy inayofunga 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) zinazobeba assembly ya x86 iliyoandikwa kwa mkono, au SSE na AVX intrinsics, ni kisa cha kimya zaidi. Nyingi pia zina njia ya NEON (NEON ni seti ya maelekezo ya vector ya ARM) au fallback ya C ya kawaida, hivyo zinakusanywa (compile) na kufanya kazi. Utendaji unaweza kutofautiana na ule wa build ya x86 katika mwelekeo wowote. Pima hilo kwenye instance yako badala ya kutabiri 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 huwasili kama binary iliyokusanywa, na wakati vendor hajachapisha build ya arm64 hakuna unachoweza kufanya kuhusu hilo. cPanel na WHM ndio kisa dhahiri zaidi katika hosting: mahitaji yake ya mfumo yanataja x86_64 na hayaorodheshi ARM, kwa hivyo seva ya control panel inabaki kwenye x86 (ilichunguzwa Agosti 2026, na inafaa kusoma tena kwenye 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 kwa urahisi. Seva za ARM hazifanani sana, na tofauti hizo zipo chini ya programu yako.

Ukubwa wa page (page size) ni jambo linaloathiri uzalishaji. Kernels nyingi za arm64 hutumia page za 4 KiB, sawa na x86-64. Nyingine hutumia 64 KiB. Red Hat Enterprise Linux 8 kwa aarch64 ilisafirisha 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 kwa mchakato wenye mappings nyingi ndogo, kwa sababu kipande kidogo zaidi ambacho kernel inaweza kutoa ni mara kumi na sita zaidi. Tekeleza getconf PAGESIZE kwenye instance na usome namba hiyo badala ya kudhani.

Kuna tofauti chache ndogo ambazo ni muhimu kuzijua. 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. Limejengwa kwenye 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 mahususi vya usanifu.

Soma tahadhari katika tangazo hilo hilo, kwa sababu zinaonyesha jinsi maunzi ya seva ya ARM yanayoungwa mkono rasmi bado yalivyo machache. Proxmox ilithibitisha mifumo ya NVIDIA Grace na NVIDIA Vera siku ya kwanza, baada ya majaribio ya pamoja na NVIDIA na Supermicro kwenye maunzi ya Grace Hopper. Maunzi mengine ya ARMv8-A na ARMv9-A yanayotumia UEFI yanapata usaidizi wa kiwango cha juu iwezekanavyo (best effort). Kompyuta za ubao mmoja (single board computers) zinazotumia Device tree pekee kama Raspberry Pi hazitumiki. Mgeni (guest) huendeshwa tu kwenye nodi ya usanifu wake, uhamiaji wa moja kwa moja (live migration) hufanya kazi tu kati ya nodi za usanifu uleule, na nguzo (clusters) zenye usanifu mchanganyiko hazitumiki rasmi.

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

Orodha ya ukaguzi kabla ya kufanya commit

1. Tekeleza uname -m kwenye mfano wa majaribio (trial instance) na uhakikishe inachapisha aarch64.
2. Tekeleza docker buildx imagetools inspect kwenye kila image iliyo kwenye faili yako ya Compose na uhakikishe 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 agent ya closed source unayotegemea na utafute build ya 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

Hatutakupa uwiano wa bei kwa utendaji (price to performance ratio) 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 kwenye stack ina entry ya linux/arm64 kwenye manifest yake. Hakiki 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 zile ulizojijengea mwenyewe kwenye mashine ya x86, mara nyingi si za aina hiyo. 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 kuendesha 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 configuration yanayoweza kufanya binary ya x86-64 iendeshe kiasili 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 strings za platform ya Docker, hutumia arm64. Mgawanyiko uleule upo upande wa pili, 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 maalum 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 ikiwezekana, na ulinganishe namba hizo.

Nini ninachopaswa kukagua kabla ya kuhamisha seva ya uzalishaji (production) kwenda arm64?

Kagua mambo manne, kwa mpangilio huu. Thibitisha kila container image ina manifest ya arm64. Thibitisha kila apt repository ya watu wengine inachapisha binary-arm64. Thibitisha kila wakala (agent) wa closed source ana download ya aarch64. Kisha endesha getconf PAGESIZE kwenye instance lengwa, kwa sababu kernel ya 64 KiB page hubadilisha matumizi ya kumbukumbu ya michakato (processes) yenye mappings nyingi ndogo. Chochote kinachofeli mojawapo ya ukaguzi huo manne ni sababu ya kuendelea kuweka seva hiyo mahususi kwenye x86.