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

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

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

רוב ה-stacks המודרניים עוברים את הבדיקה הזו ללא צורך בעבודה נוספת. הכשלים מתרכזים בשני מקומות: תמונות (images) של מכולות שנבנו עבור ארכיטקטורה אחת בלבד, ותוכנות בקוד סגור שאין עבורן הורדה ל-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 בחרו שמות שונים עבור אותה ארכיטקטורת פקודות, לכן 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 (transport layer security) ואת הצפנת הדיסק. בדיקת האצת חומרה מסוג AES ב-VPS מכסה את הבדיקה בשתי הארכיטקטורות.

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

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

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

docker buildx imagetools inspect nginx:1.27

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

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

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

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

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

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

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

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

שאלו את apt ישירות, מתוך מופע ה-ARM:

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

דיווח של Candidate: (none) על ידי apt-cache policy משמעו שאף מאגר פעיל אינו מפרסם גרסה של אותה חבילה עבור ארכיטקטורה זו. הפקודה 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. גרסאות ישנות ומקובעות הן הסיכון האמיתי. סקריפט פריסה שמתקין גרסת runtime מלפני כמה שנים צריך להיבדק מול הערות השחרור של אותה גרסה בנוגע לתמיכה ב־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 מעלה את רף צריכת הזיכרון המינימלי עבור תהליך עם מיפויים קטנים רבים, כיוון שהיחידה הקטנה ביותר שהליבה יכולה להקצות גדולה פי 16. הריצו את getconf PAGESIZE על ה-instance וקראו את המספר המוצג במקום להניח הנחות.

כדאי להכיר כמה הבדלים קטנים נוספים. אין חבילת 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 שלכם וודאו שמופיעה שורת פלט של פלטפורמה 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 עוסק בהיבט התמחור של ההשוואה. אחסון הוא החלטה נפרדת מארכיטקטורת המעבד, ו-כיצד 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 כדי ש-tag אחד יתמוך בשתי הארכיטקטורות.

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

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

האם arm64 זהה ל-aarch64?

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

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

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

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

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