VPS מבוסס ARM לעומת x86: מה באמת משתנה?

מה משתנה במעבר ל-VPS מבוסס ARM

שרת VPS מבוסס ARM מריץ את אותה מערכת Linux ואת אותו Nginx כמו שרת x86, ובדרך כלל עלותו לליבה נמוכה יותר. הסיכון במעבר הוא תאימות. תוכנית שעברה קומפילציה עבור x86-64 אינה יכולה לרוץ כלל על arm64, לכן כל רכיב ב-stack שלכם חייב להציע גרסת arm64 או להיות כזה שניתן לבנות מחדש.

רוב ה-stacks המודרניים עוברים את הבדיקה הזו ללא צורך בשינויים. הכשלים מתרכזים בשני מקומות: אימג'ים של מכולות (containers) שנבנו עבור ארכיטקטורה אחת בלבד, ותוכנות בקוד סגור שאין עבורן הורדה ל-arm64. הפקודות להלן עונות על שתי השאלות הללו עבור ה-stack שלכם לפני שאתם משלמים על instance. אם אתם עדיין מבררים איזה סוג שרת אתם צריכים, התחילו ב-מהו VPS וכיצד הוא שונה מאחסון שיתופי.

arm64, aarch64, amd64: מה המשמעות של כל שם

הריצו פקודות אלו בכל instance לפני כל פעולה אחרת.

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

uname -m מדפיס aarch64 במכונת ARM ו-x86_64 במכונת Intel או AMD. dpkg --print-architecture מדפיס arm64 ו-amd64 עבור אותן שתי מכונות. שתי התשובות נכונות. ליבת ה-Linux ומערכת ה-packaging של Debian בחרו שמות שונים עבור אותה ערכת פקודות (instruction set), לכן aarch64 ו-arm64 מציינים דבר אחד, ו-x86_64 ו-amd64 מציינים את האחר. Docker משתמשת בשמות בסגנון Debian, וזו הסיבה שפלטפורמת ה-image נקראת linux/arm64.

ב-arm64 אין שורת model name בתוך /proc/cpuinfo. במקומה תקבלו שדה Features, והצפנת חומרה תופיע שם כ-flags כמו aes pmull sha1 sha2. אלו הן ה-ARMv8 Cryptographic Extensions, והן מבצעות את התפקיד ש-AES-NI מבצע בחלקי Intel ו-AMD: הן מאיצות את ה-TLS (אבטחת שכבת תעבורה) ואת הצפנת הדיסק ברמת החומרה. בדיקת האצת חומרה מסוג AES ב-VPS מכסה את הבדיקה בשתי הארכיטקטורות.

מדוע מכולות קורסות תחילה, וכיצד נראית השגיאה

כל מניפסט של Docker image מתעד את הארכיטקטורה עבורה הוא נבנה. משיכה (pull) של image הכולל מניפסט מסוג amd64 בלבד למארח (host) מסוג arm64 תסתיים בהצלחה. הכשל יתרחש ברגע ניסיון הפעלת התהליך הראשון:

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) שמסרבת להריץ את הקובץ, כיוון שראש ה-ELF (פורמט קובץ הרצה) שלו מציין סוג מכונה שה-CPU הנוכחי אינו תומך בו. שום הגדרה לא תתקן זאת. ההוראות פשוט אינן קיימות בחומרה.

בדקו את המניפסט לפני הפריסה:

docker buildx imagetools inspect nginx:1.27

הפלט מציג שורת Platform: אחת לכל image ברשימת המניפסטים, כגון linux/amd64 ו-linux/arm64. אם linux/arm64 חסר, התג (tag) הזה לא יפעל ב-VPS מבוסס ARM. הפקודה docker manifest inspect --verbose nginx:1.27 מציגה את אותו המידע, אך התיעוד של Docker מציין ש-docker manifest היא פקודה ניסיונית שהתנהגותה עשויה להשתנות בין גרסאות, לכן עדיף להשתמש ב-imagetools.

עבור images שאתם בונים בעצמכם, בנו את שתי הארכיטקטורות בפקודה אחת ודחפו (push) רשימת מניפסטים:

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

בנייה עבור ארכיטקטורה זרה על מארח יחיד דורשת אמולציה של QEMU במצב משתמש, הרשומה ב-handler של ה-kernel מסוג binfmt_misc:

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

השתמשו באמולציה לצורכי בנייה ובדיקה בלבד. אל תשתמשו בה להגשת תעבורה. התיעוד הרשמי של Docker מציין שאמולציה עם QEMU "יכולה להיות איטית משמעותית מבנייה טבעית (native), במיוחד עבור משימות עתירות חישוב כמו הידור (compilation) ודחיסה או פריסה", כך ששירות x86 מרוץ באמולציה על שרת ARM מבטל את החיסכון הכספי שבגללו עברתם אליו. הגדרת המארח עבור המקרה הטבעי זהה בשתי הארכיטקטורות: הרצת Docker על VPS מכסה זאת, וקובץ Compose קיים יעבוד ללא שינוי ברגע שלכל image בו יהיה מניפסט מסוג arm64.

האם החבילות שאני צריך יהיו קיימות ב-arm64?

Ubuntu ו-Debian בונות כמעט את כל הארכיון עבור arm64, לכן apt install nginx postgresql redis-server מתנהג אותו דבר בשתי הארכיטקטורות. הפערים נמצאים במאגרים של צד שלישי.

שאלו את apt ישירות, בתוך ה-instance של ה-ARM:

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

דיווח של apt-cache policy על Candidate: (none) אומר שאף מאגר פעיל לא מפרסם גרסה של החבילה הזו עבור ארכיטקטורה זו. הפקודה apt-get install -s מדמה את ההתקנה ולא כותבת דבר, ובמקרה כזה היא תסתיים עם E: Unable to locate package.

לאחר מכן, קראו את הפלט של apt update במקום לגלול מעבר אליו. מאגר של ספק שתומך ב-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'

המאגר מוגדר ונגיש, אך הוא לא מכיל דבר שהמכונה הזו יכולה להתקין. בדקו גם את רשומת המקור עצמה. שורה שמוגדרת עם [arch=amd64] תדלג על מארח arm64, לכן החבילה תיראה חסרה כאשר הסיבה האמיתית היא ה-pin.

אילו עומסי עבודה בטוחים, ואילו דורשים בדיקה מוקדמת

סביבות הרצה מפורשות (Interpreted) וסביבות bytecode הן ניידות מטבען. ל־PHP, Python, Ruby ו־Node.js יש חבילות arm64 בהפצות הראשיות. Go ו־Rust מבצעות הידור צולב (cross-compile) ל־arm64 באמצעות הגדרת target יחיד. מחסנית LEMP, ממשק API ב־Node, קובץ בינארי של Go מאחורי Nginx או מסד נתונים Postgres הם עבודה שגרתית ב־arm64.

מהדר Just-in-time (JIT) מייצר קוד מכונה בזמן ריצת התוכנית, לכן הוא זקוק למחולל קוד עבור ארכיטקטורת היעד. לגרסאות הנוכחיות יש כזה: OpenJDK, .NET, מנוע V8 בתוך Node.js ו־PyPy תומכים כולם ב־arm64 על Linux. גרסאות ישנות ונעולות הן הסיכון האמיתי. תסריט פריסה שמתקין גרסת סביבת הרצה מלפני כמה שנים צריך להיבדק מול הערות השחרור של אותה גרסה עבור תמיכה ב־aarch64, במקום להניח שהיא תעבוד.

ספריות המכילות קוד assembly שנכתב ידנית עבור x86, או פקודות SSE ו־AVX, הן המקרה השקט יותר. לרוב הספריות יש גם נתיב NEON (סט פקודות וקטוריות של ARM) או חלופת C פשוטה, כך שהן עוברות הידור ורצות. הביצועים עשויים להיות שונים מהגרסה ל־x86 לכאן או לכאן. מדדו זאת במופע שלכם במקום להסתמך על תחזיות ממאמרים.

תוכנה בקוד סגור היא החסם האמיתי. סוכן ניטור של ספק, דרייבר מסד נתונים ברישיון, לוח בקרה מסחרי או daemon של אנטי-וירוס מגיעים כקובץ בינארי מהודר, וכאשר הספק לא מפרסם גרסת arm64, אין מה לעשות בנידון. cPanel ו־WHM הם המקרה המובהק ביותר באירוח: דרישות המערכת שלהם מציינות x86_64 ואינן מפרטות ARM, לכן שרת לוח בקרה נשאר על x86 (נבדק באוגוסט 2026, וכדאי לקרוא שוב בדף הדרישות של הספק עצמו). אם זה הדבר היחיד שמעכב אתכם, חלופות cPanel שכדאי להריץ על VPS הן המקום להתחיל בו, ובדקו את התמיכה בארכיטקטורה של כל אחת מהן באותה הדרך.

ליבות וגודל דף: המקומות שבהם מופעי ARM עדיין נבדלים

שרתי x86-64 הם כמעט ברי-החלפה. שרתי ARM הם פחות אחידים, וההבדלים נמצאים מתחת לשכבת היישום שלכם.

גודל דף (page size) הוא אחד המשתנים שמגיעים עד לסביבת הייצור. רוב ליבות ה-arm64 משתמשות בדפים של 4 KiB, בדומה ל-x86-64. חלקן משתמשות ב-64 KiB. הגרסה Red Hat Enterprise Linux 8 עבור aarch64 הופצה כברירת מחדל עם ליבת 64 KiB, בעוד ש-RHEL 9 החזירה את ברירת המחדל ל-4 KiB, תוך שמירה על חבילת kernel-64k נפרדת עבור עומסי עבודה הזקוקים לגודל הגדול יותר. גודל דף של 64 KiB מעלה את רף צריכת הזיכרון המינימלי עבור תהליך עם מיפויים קטנים רבים, כיוון שהנתח הקטן ביותר שהליבה יכולה להקצות גדול פי שישה-עשר. הריצו את getconf PAGESIZE על המופע וקראו את המספר במקום להניח הנחות. גודל דף אינו ההחלטה היחידה של הליבה שמגיעה אליכם, שכן הגרסה שמספק ספק השירות שלכם קובעת גם כיצד משימות מתוזמנות על גבי הליבות, ו-תזמון מודע למטמון שנוסף ב-Linux 7.2 מגיע ל-arm64 ול-x86-64 במידה שווה.

כדאי להכיר כמה הבדלים קטנים נוספים. אין חבילת microcode של מעבד במערכת ההפעלה ב-arm64, לכן עדכוני קושחה מגיעים מהספק שלכם ולא מ-apt. שרתי ARM עולים דרך UEFI (ממשק קושחה מאוחד וניתן להרחבה) ומתארים את החומרה שלהם דרך ACPI (ממשק תצורה וניהול צריכת חשמל מתקדם). לחלק מתכונות ה-x86 אין מקבילה ב-ARM כלל, כולל הצפנת זיכרון AMD SEV ורכיבי GPU מתווכים מסוג Intel GVT-g.

האם פלטפורמת השרתים ARM הגיעה לבשלות?

בצד התוכנה, התשובה היא כן. ההפצות Debian, Ubuntu, Fedora ו־RHEL כוללות כולן גרסאות arm64 ברמה גבוהה, והתמונות הרשמיות ב־Docker Hub הן כסטנדרט מרובות ארכיטקטורות (multi-arch).

ההוכחה הברורה ביותר לכך לאחרונה היא Proxmox. ב־5 באוגוסט 2026 הכריזה Proxmox על המהדורה הראשונה הנתמכת רשמית של Proxmox Virtual Environment עבור arm64, גרסה 9.2, החולקת מאגרי חבילות ומחזור חיים של גרסאות עם מהדורת ה־x86-64. המערכת מבוססת על Debian 13.5 עם Linux 7.0, QEMU 11.0, LXC 7.0 ו־ZFS 2.4, כאשר התצורה והכלים זהים לאלו של x86-64, למעט קבוצה קטנה של פריטים ספציפיים לארכיטקטורה.

מומלץ לקרוא את ההסתייגויות באותה הכרזה, שכן הן ממחישות עד כמה מצומצם עדיין היצע חומרת השרתים מבוססת ARM הנתמכת רשמית. Proxmox אישרה את השימוש במערכות NVIDIA Grace ו־NVIDIA Vera כבר ביום הראשון, לאחר בדיקות משותפות עם NVIDIA ו־Supermicro על חומרת Grace Hopper. חומרה אחרת מבוססת UEFI מסוג ARMv8-A ו־ARMv9-A מקבלת תמיכה במאמץ מיטבי (best effort). מחשבים לוח יחיד (SBC) המבוססים על Device tree בלבד, כגון Raspberry Pi, אינם נתמכים. אורח (guest) רץ רק על צומת (node) בעל אותה ארכיטקטורה, הגירה חיה (live migration) עובדת רק בין צמתים בעלי אותה ארכיטקטורה, ואשכולות (clusters) בעלי ארכיטקטורה מעורבת אינם נתמכים רשמית.

זהו המצב העובדתי נכון לאוגוסט 2026. ספקית hypervisor שמפיצה גרסת arm64 באותו מחזור חיים של x86-64 מהווה התקדמות ממשית עבור הפלטפורמה. רשימת החומרה הנתמכת ביום הראשון כוללת שתי משפחות מעבדים בלבד.

רשימת תיוג לביצוע לפני ביצוע commit

1. הריצו את uname -m על מופע ניסיוני וודאו שהוא מדפיס aarch64.
2. הריצו את docker buildx imagetools inspect על כל image בקובץ ה-Compose שלכם וודאו שמופיעה שורת פלט של platform מסוג linux/arm64 עבור כל אחד מהם.
3. הריצו את apt update על מופע ה-ARM וקראו כל אזהרת Skipping acquire שהוא מדפיס.
4. פתחו את דף ההורדות עבור כל סוכן (agent) בקוד סגור שאתם מסתמכים עליו וחפשו גרסת arm64 או aarch64 לפי שם.
5. הריצו את getconf PAGESIZE ורשמו את התשובה לפני קביעת גודל הזיכרון.
6. הריצו benchmark משלכם גם על תוכנית ה-ARM וגם על תוכנית ה-x86 שביניהן אתם מתלבטים.

מה פוסט זה אינו מתיימר לקבוע

איננו מתכוונים לספק לכם יחס עלות-תועלת בין ARM לבין x86. המחירים לכל ליבה משתנים בין ספקיות ובין תוכניות שונות, ומדידה שבוצעה על חומרה של מישהו אחר אינה חוזה את התוצאות אצלכם. במקום זאת, בצעו מדידה בעצמכם. המדריך שלנו לביצוע benchmarking ל-VPS מכסה את sysbench ו-fio בשיטה שתוכלו לשחזר, ו-מה העלות האמיתית של VPS מכסה את הצד הכלכלי של ההשוואה. אחסון הוא החלטה נפרדת מארכיטקטורת ה-CPU, ו-כיצד NVMe בהשוואה ל-SATA SSD ב-VPS עוסק בחלק זה. הריצו את אותה בדיקה על שתי התוכניות, עם עומס העבודה שלכם במידת האפשר, ותנו למספרים שלכם להכריע.

FAQ

האם מכולות Docker שלי ירוצו על שרת VPS מבוסס ARM?

הן ירוצו אם לכל image ב־stack יש רשומה מסוג linux/arm64 ב־manifest שלו. בדקו כל אחד מהם בעזרת docker buildx imagetools inspect <image> וחפשו שורה מסוג Platform: linux/arm64. תמונות רשמיות ב־Docker Hub הן בדרך כלל multi-arch. תמונות מספקים קטנים יותר, ותמונות שבניתם בעצמכם על מכונת x86, לרוב אינן כאלו. עבור התמונות שלכם, בצעו בנייה מחדש עם docker buildx build --platform linux/amd64,linux/arm64 ... --push כדי שתג אחד יתמוך בשתי הארכיטקטורות.

מה המשמעות של exec format error בשרת ARM?

הליבה (kernel) ניסתה להריץ קובץ בינארי שראש ה־ELF שלו מציין סוג מכונה שונה, וסירבה. במארח arm64, המשמעות היא כמעט תמיד קובץ בינארי או תמונת מכולה מסוג x86-64. Docker מדפיס אזהרה מראש, המציינת שפלטפורמת התמונה המבוקשת linux/amd64 אינה תואמת לפלטפורמת המארח שזוהתה linux/arm64/v8. הפתרון הוא בנייה עבור הארכיטקטורה הנכונה. אין שינוי הגדרות שיגרום לקובץ בינארי של x86-64 לרוץ באופן טבעי על ARM.

האם arm64 זהה ל־aarch64?

כן. אלו שני שמות לאותה ערכת פקודות 64-bit של ARM. הליבה מדווחת על aarch64 דרך uname -m, בעוד שהחבילות של Debian ו־Ubuntu, ומחרוזות הפלטפורמה של Docker, משתמשות ב־arm64. אותו פיצול קיים בצד השני, שבו uname -m מדווח על x86_64 והחבילות משתמשות ב־amd64. אם דף הורדה מציע רק קובצי aarch64, אלו הקבצים הנכונים עבור מכונה ש־dpkg --print-architecture מזהה כ־arm64.

האם שרת VPS מבוסס ARM מהיר יותר משרת x86?

לשאלה זו אין תשובה כללית, וכל יחס מהירות שתקראו נמדד על חומרה שאינה שלכם. המהירות תלויה בדגם ה־CPU הספציפי, במספר הליבות שהוקצו לכם, באופן שבו הספק מנהל תחרות על משאבים בין לקוחות, ובמידת הניצול של פקודות וקטוריות על ידי העומס שלכם. בצעו Benchmark לשתי התוכניות שביניהן אתם בוחרים, עם העומס שלכם אם ניתן, והשוו את התוצאות.

מה עלי לבדוק לפני העברת שרת production ל־arm64?

ארבע בדיקות, לפי הסדר הזה. ודאו שלכל תמונת מכולה יש manifest מסוג arm64. ודאו שכל מאגר apt של צד שלישי מפרסם binary-arm64. ודאו שלכל סוכן (agent) בקוד סגור יש גרסת הורדה ל־aarch64. לאחר מכן הריצו getconf PAGESIZE על המופע (instance) המיועד, כיוון שליבת 64 KiB page משנה את טביעת הרגל בזיכרון של תהליכים עם הרבה מיפויים קטנים. כל דבר שנכשל באחת מארבע הבדיקות הללו הוא סיבה להשאיר את השרת הספציפי הזה על x86.