הקמת קלאסטר Proxmox לזמינות גבוהה

שגיאה בהקמת קלאסטר Proxmox עלולה לעלות לכם בנתונים. תרחיש טיפוסי: שני צמתים, ללא אחסון משותף מוגדר, הקלאסטר מאבד קוורום כל הזמן, מכונות וירטואליות קורסות כל שבוע. אנחנו יודעים איך לתקן את זה. במשך פרויקטים רבים לחברות בגדלים שונים — מסטארטאפים ועד ארגונים גדולים — המטרה שלנו היא שמכונות וירטואליות יועברו אוטומטית במקרה של כשל בצומת, וזמן ההשבתה יימדד בדקות, לא בשעות.

איך להקים קלאסטר Proxmox לזמינות גבוהה?

אנחנו חולקים תצורות מעשיות שנבדקו בסביבת ייצור. מאמר זה מכסה החלטות ארכיטקטוניות מרכזיות: מבחירת אחסון ועד הגדרת fencing. העלות מחושבת באופן אישי, אך בדרך כלל נמוכה ב-20–30% מחלופות VMware.

בעיות שאנחנו פותרים

מספר מינימלי של צמתים: 3

קוורום (רוב קולות) נדרש להחלטות קלאסטר. עם 2 צמתים, בעת אובדן תקשורת כל אחד מחשיב את עצמו כשורד היחיד — נוצר מצב של split-brain, ושניהם מנסים להפעיל את אותן מכונות וירטואליות, מה שמוביל לשחיתות נתונים. 3 צמתים מבטיחים שכל כשל בודד משאיר רוב. לפי תיעוד Proxmox, קוורום הוא קריטי לשלמות הקלאסטר.

איך להימנע ממלכודות רשת נפוצות?

הבעיה השכיחה ביותר היא שאחסון משותף לא מוגדר או מוגדר בצורה שגויה. HA ב-Proxmox דורש אחסון משותף: המכונה הווירטואלית חייבת להיות נגישה מכל צומת. אם דיסק המכונה הווירטואלית נמצא על ZFS המקומי של המארח, במקרה של כשל המכונה לא יכולה לעבור — הנתונים לא זמינים.

הבעיה השנייה היא ממשק רשת יחיד לכל התעבורה. רשת קלאסטר (corosync), רשת העברה, ותעבורת מכונות וירטואליות על כרטיס רשת אחד: בעומס גבוה, corosync מאבד חבילות, הקלאסטר מחשיב את המארח כמת ומתחיל fencing — מכבה אותו בכוח דרך IPMI. במציאות המארח חי, רק עמוס. התוצאה — העברה מיותרת וזמן השבתה.

ארכיטקטורת רשת: מה ולמה

תכנית מומלצת ל-3 צמתים:

Corosync על ממשק ייעודי הוא חובה. אם אין כרטיס רשת פיזי נפרד, השתמשו ב-VLAN עם עדיפות QoS.

איך לבחור אחסון משותף ל-Proxmox HA?

בחירת האחסון המשותף קובעת את סובלנות התקלות והתקציב. השוו את האפשרויות העיקריות.

השוואת אפשרויות אחסון משותף

Ceph — מובנה ב-Proxmox, אחסון מבוזר ישירות על דיסקי הצמתים. כל צומת תורם דיסקים ל-pool של Ceph, נתונים משוכפלים על פני 3 צמתים אוטומטית. חסרון: Ceph צורך כ-2–4 GB RAM לכל OSD.

NFS/iSCSI — מערך אחסון חיצוני. קל יותר לניהול, אבל נקודת כשל יחידה אם המערך עצמו אינו HA.

ZFS משותף דרך iSCSI — ZFS על שרת אחסון ייעודי, מיוצא כ-LUN של iSCSI ומורכב על כל הצמתים.

יצירת הקלאסטר

# На первом узле — создаём кластер
pvecm create pve-cluster --link0 address=10.10.1.1 --link1 address=10.10.2.1
# На втором и третьем узлах — присоединяемся
pvecm add 10.10.1.1 --link0 address=10.10.1.2 --link1 address=10.10.2.2
pvecm add 10.10.1.1 --link0 address=10.10.1.3 --link1 address=10.10.2.3
# Проверяем статус кластера
pvecm status

# На первом узле — создаём кластер pvecm create pve-cluster --link0 address=10.10.1.1 --link1 address=10.10.2.1 # На втором и третьем узлах — присоединяемся pvecm add 10.10.1.1 --link0 address=10.10.1.2 --link1 address=10.10.2.2 pvecm add 10.10.1.1 --link0 address=10.10.1.3 --link1 address=10.10.2.3 # Проверяем статус кластера pvecm status ו---link0 — 2 נתיבי corosync בלתי תלויים. בעת אובדן של אחד, הקלאסטר ממשיך דרך השני. זהו פרוטוקול הטבעת המבוזרת, קריטי ליציבות.

הגדרת מנהל ה-HA

לאחר הגדרת אחסון משותף, הפעילו HA עבור מכונות וירטואליות ספציפיות:

# Добавление ВМ в HA группу
ha-manager add vm:101 --state started --max_restart 3 --max_relocate 2

# Создание HA группы с приоритетами узлов
ha-manager groupadd production-group --nodes pve1:3,pve2:2,pve3:1 --restricted 1
ha-manager add vm:101 --group production-group

max_restart — כמה פעמים HA מפעיל מחדש את המכונה הווירטואלית על הצומת הנוכחי לפני פינוי. max_relocate — כמה פעמים הוא מעביר לצומת אחר. restricted — המכונה הווירטואלית מופעלת רק על צמתים בקבוצה.

למה Fencing הוא קריטי?

Fencing הוא רכיב חובה ב-HA. Proxmox חייב להיות מסוגל לכבות בכוח את הצומת הבעייתי לפני הפעלת המכונות הווירטואליות שלו על מארח אחר. ללא fencing, עלולה להתרחש שחיתות נתונים: שני מארחים כותבים לאותו דיסק בו-זמנית. הגדירו דרך IPMI/iDRAC/iLO:

# Настройка IPMI fencing для узла pve1
pvesh set /nodes/pve1/config --wakeonlan 0

# В /etc/pve/corosync.conf добавляем fence agent конфигурацию

totem {
  ring0_addr: 10.10.1.1
  ring1_addr: 10.10.2.1
}
quorum {
  provider: corosync_votequorum
}
nodelist {
  node {
    name: pve1
    nodeid: 1
  }
}
logging {
  to_syslog: yes
}

העברה חיה ועומס

Proxmox תומך בהעברה חיה (מקביל ל-vMotion) למכונות וירטואליות ללא כיבוי. לפעולה תקינה: מעבדים זהים או תואמים על כל הצמתים (דגל # Добавление ВМ в HA группу ha-manager add vm:101 --state started --max_restart 3 --max_relocate 2 # Создание HA группы с приоритетами узлов ha-manager groupadd production-group --nodes pve1:3,pve2:2,pve3:1 --restricted 1 ha-manager add vm:101 --group production-group מגביל העברה — השתמשו ב-# Настройка IPMI fencing для узла pve1 pvesh set /nodes/pve1/config --wakeonlan 0 # В /etc/pve/corosync.conf добавляем fence agent конфигурацию לתאימות), אחסון משותף, רשת העברה על ממשק נפרד.

# Ручная live migration ВМ 101 на узел pve2 qm migrate 101 pve2 --live 1 --migration_network 10.10.3.0/24 

מה כלול בעבודה

1. תיעוד מלא של תצורת הקלאסטר, הרשת והאחסון
2. גישה ל-Proxmox, IPMI, ניטור עבור המנהל שלכם
3. הדרכת הצוות שלכם בפעולות בסיסיות (3–4 שעות)
4. אחריות לתפקוד תצורת ה-HA למשך 30 יום
5. תמיכה לאחר השקה: 3 חודשים של ייעוץ טלפוני/דוא"ל
6. העברת נתונים מהתשתית הקיימת (במידת הצורך)
7. סקריפטים לשחזור אוטומטי לכשלים טיפוסיים

קבלו ייעוץ ממהנדס לפני התחלה — נבחר את הארכיטקטורה האופטימלית לתקציב ולעומס שלכם. הזמינו הקמה מסודרת וקבלו קלאסטר מוכן לייצור. חיסכון בסובלנות תקלות יכול להגיע עד 40% בהשוואה לפתרונות מסורתיים. צרו קשר להערכת הפרויקט שלכם.

לוחות זמנים

הקמת קלאסטר של 3 צמתים עם Ceph: 3–5 ימים. עם אחסון חיצוני (NFS/iSCSI): 2–3 ימים. מאפס, כולל התקנת מערכת הפעלה על המארחים: הוסיפו 1–2 ימים.