תארו לעצמכם: אתם משדרגים את vCenter Server ל-8.0, ואחרי אתחול הוא לא עולה. HA לא עובד, DRS לא מאזן—כל הווירטואליזציה קופאת. זה מקרה אמיתי מהשטח: 20 מכונות וירטואליות על שלושה מארחים בלי vCenter—איך מנהלים? הגדרת vCenter נכונה מההתחלה מונעת תרחישים כאלה. הניסיון שלנו—10+ שנים בווירטואליזציה, 50+ פרויקטי הטמעה של VMware. אנחנו מגדירים vCenter turnkey: מעיצוב היררכיה ועד תיעוד והדרכה.
בעיות של vCenter לא מוגדר כראוי
סיפור טיפוסי: vCenter עצמו חי על אחד ממארחי ESXi בקלאסטר. המארח הזה נופל—vCenter הופך ללא זמין. DRS ו-HA לא יכולים לפנות מכונות וירטואליות בלי vCenter. התשתית "קופאת" עד להתערבות ידנית. פתרון: vCenter על מארח ייעודי מחוץ לקלאסטר הייצור, או vCenter HA מוגדר (שלושה צמתים: פעיל, פסיבי, witness).
בעיה נפוצה שנייה היא ש-vCenter HA לא מוגדר ואין גיבויים של VCSA. אחרי שדרוג או כשל בדיסק, התצורה אובדת: צריך להוסיף מחדש מארחים, ליצור מחדש portgroups, לשחזר מתגים מבוזרים. file-based backup דרך מתזמן VAMI המובנה לוקח 15 דקות להגדרה וחוסך ימים של מאמץ שחזור. לפי תיעוד VMware, HA דורש לפחות 2 datastores עם heartbeat, אחרת יכול להתרחש split-brain אם רשת הניהול אובדת.
איך להגדיר vCenter HA לסבילות תקלות?
vCenter HA מורכב משלושה צמתים וירטואליים: פעיל, פסיבי ו-witness. פעיל ופסיבי חייבים להיות ממוקמים על מארחים שונים בקלאסטר. Witness הוא צומת קל משקל שקובע איזה צומת פעיל. כשהצומת הפעיל נופל, הפסיבי משתלט על הניהול תוך 1–2 דקות. אנחנו גם תמיד מגדירים גיבוי מבוסס קבצים (יומי, שמירה ל-7 ימים) כדי למנוע אובדן תצורה במקרה של כשל קטסטרופלי של כל הצמתים. חיסכון בזמן במהלך שחזור—עד 80% בהשוואה ליצירה ידנית מחדש.
למה dvSwitch קריטי לביצועים?
Distributed Virtual Switch (dvSwitch) הוא מתג וירטואלי המנוהל מ-vCenter, לא ממארחי ESXi בודדים. יתרונות עיקריים: תצורה אחת חלה על כל המארחים בבת אחת, LACP לחיבור כרטיסי רשת פיזיים, Jumbo Frames (MTU 9000) ל-vMotion. אנחנו מגדירים עיצוב תעבורה (traffic shaping) ל-vMotion כך שהעברת מכונות וירטואליות לא מפילה תעבורת ייצור. בלי dvSwitch, לכל מארח יש תצורת רשת מבודדת—מקור לשגיאות במהלך סקיילינג.
בהשוואה ל-vSwitch רגיל: dvSwitch מספק תפוקת vMotion גבוהה פי שלושה בשימוש ב-LACP ו-Jumbo Frames, וזמן ההעברה מופחת ב-40%.
ארכיטקטורת קלאסטר ותצורה
VCSA הוא מכשיר וירטואלי המבוסס על Photon OS. מאז גרסה 7.0, PostgreSQL מוטמע החליף את Oracle החיצוני. הוא נפרס בשני מצבים: Embedded (vCenter + PSC במכונה אחת, מתאים לרוב) ו-External PSC (מיושן, לא בשימוש להתקנות חדשות). אנחנו ממליצים על Embedded—הוא מפחית את המורכבות בחצי.
היררכיית אובייקטים של vCenter:
vCenter Server
└── Datacenter: DC-Moscow
├── Cluster: Production
│ ├── Host: esxi01.company.ru
│ ├── Host: esxi02.company.ru
│ └── Host: esxi03.company.ru
├── Cluster: DMZ
│ └── Host: esxi-dmz01.company.ru
└── Datastore Cluster: DS-Production
├── Datastore: SAN-LUN01
└── Datastore: SAN-LUN02ההיררכיה חשובה—היא משפיעה על החלת מדיניות, הרשאות ו-Storage DRS.
הגדרת DRS ו-HA
DRS (Distributed Resource Scheduler) מאזן אוטומטית מכונות וירטואליות בין מארחים לפי CPU וזיכרון. שלושה מצבים: ידני (המלצות בלבד), אוטומטי חלקית (אוטומטי בהפעלת מכונה וירטואלית), אוטומטי מלא (איזון מתמשך). לייצור, אנחנו מגדירים אוטומטי מלא עם אגרסיביות 3 מתוך 5: פחות העברות, פחות תקורה של vMotion. כללי affinity קריטיים ל-HA: VM-VM Anti-Affinity מבטיח שמסדי נתונים ראשיים ומשניים לעולם לא יהיו על אותו מארח. VM-Host Affinity מבטיח שמכונות וירטואליות רגישות לרישוי יישארו על מארחים מוסמכים.
HA—כשמארח נופל, מכונות וירטואליות מופעלות מחדש על המארחים הנותרים. הגדרות מפתח:
- Admission Control—שמירת משאבים ל-failover. מדיניות
vCenter Server └── Datacenter: DC-Moscow ├── Cluster: Production │ ├── Host: esxi01.company.ru │ ├── Host: esxi02.company.ru │ └── Host: esxi03.company.ru ├── Cluster: DMZ │ └── Host: esxi-dmz01.company.ru └── Datastore Cluster: DS-Production ├── Datastore: SAN-LUN01 └── Datastore: SAN-LUN02: 25% CPU וזיכרון שמורים, מספיק לאובדן של אחד מתוך ארבעה מארחים. - VM Restart Priority—מכונות וירטואליות קריטיות (מסדי נתונים, בקרי AD) מקבלות עדיפות גבוהה, אחרות בינונית. אם המשאבים לא מספיקים אחרי failover, מכונות בעדיפות גבוהה מופעלות ראשונות.
- VM Monitoring—HA יכול להפעיל מחדש מכונות וירטואליות אם מערכת ההפעלה האורחת נתקעת (דרך VMware Tools heartbeat). הפעל לייצור.
- Heartbeat datastores—HA משתמש ב-datastore heartbeat כערוץ נוסף לבדיקת חיוניות המארח. הגדר לפחות 2 heartbeat datastores, אחרת split-brain אפשרי.
| מצב DRS | תיאור | מתי להשתמש |
|---|---|---|
| ידני | המלצות בלבד, המנהל מחליט | סביבות בדיקה, העברות |
| אוטומטי חלקית | אוטומטי בהפעלת מכונה וירטואלית | קלאסטרים גדולים עם שליטה ידנית |
| אוטומטי מלא | איזון מתמשך | ייצור, סביבות רגישות לעומס |
אנחנו מגדירים אוטומטי מלא ל-90% מהפרויקטים.
Distributed Virtual Switch
דוגמת תצורה:
dvSwitch: dvs-production
├── Uplinks: vmnic2, vmnic3 (LACP / активный-активный)
├── Portgroup: dvpg-management (VLAN 100)
├── Portgroup: dvpg-vmotion (VLAN 200)
├── Portgroup: dvpg-app-tier (VLAN 300)
└── Portgroup: dvpg-db-tier (VLAN 400)עבור dvpg-vmotion, הפעל Jumbo Frames (MTU 9000), הגדר עיצוב תעבורה עם רוחב פס מובטח ל-vMotion.
גיבוי ושדרוג VCSA
ל-VCSA יש גיבוי מובנה מבוסס קבצים דרך VAMI (Cluster Resource Percentage). אנחנו מגדירים גיבוי יומי ל-NFS או SFTP עם שמירה ל-7 ימים. הגיבוי כולל תצורה, inventory, מתגים מבוזרים—הכל הדרוש לשחזור למכונה וירטואלית חדשה.
איך לבצע גיבוי מבוסס קבצים של VCSA: 5 שלבים
- התחבר ל-VAMI (https://vcenter:5480) כ-root.
- עבור לקטע Backup ובחר Configure schedule.
- ציין פרוטוקול (SFTP או NFS), נתיב אחסון ופרטי התחברות.
- הגדר לוח זמנים: יומי ב-2:00 לפנות בוקר, שמירה של 7 עותקים.
- בדוק ידנית את הגיבוי הראשון—ודא שקובצי .tgz נוצרים כראוי.
הסבר על מונחים מרכזיים
- **VAMI** — ממשק ניהול אינטרנטי של VCSA בפורט 5480. - **גיבוי מבוסס קבצים** — גיבוי תצורת VCSA ללא סוכן. - **SFTP** — פרוטוקול העברת קבצים מאובטח מעל SSH.Update Manager (vLCM בגרסאות חדשות יותר) מנהל עדכוני מארחי ESXi: צור baseline עם הגרסה הרצויה, סרוק מארחים, החל דרך Remediate עם vMotion אוטומטי של מכונות וירטואליות פעילות לפני עדכון המארח.
מה כלול בעבודה
- עיצוב היררכיית vCenter (Datacenter, Clusters, Folders)
- פריסת VCSA (Embedded PSC, הגדרת SSO)
- הגדרת dvSwitch ו-portgroups (VLAN, LACP, Jumbo Frames)
- הוספת מארחי ESXi, הגדרת DRS ו-HA (Admission Control, Restart Priority)
- הגדרת אחסון (Datastores, Storage DRS)
- גיבוי מבוסס קבצים והגדרת vCenter HA
- ניטור והתראות (vCenter alarms, שילוב SIEM)
- תיעוד (דיאגרמת תשתית, runbook, סיסמאות)
- הדרכת צוות (שעתיים)
שלבים ולוחות זמנים
| שלב | תוכן |
|---|---|
| תכנון | עיצוב היררכיה, תוכנית רשת, sizing |
| פריסת VCSA | התקנה, תצורה ראשונית, SSO |
| הגדרת רשת | dvSwitch, portgroups, VLAN |
| קלאסטר ומארחים | הוספת ESXi, הגדרת DRS/HA |
| אחסון | Datastores, Storage DRS, vSAN (אם רלוונטי) |
| גיבוי וניטור | גיבוי מבוסס קבצים, vCenter alarms, שילוב SIEM |
| תיעוד | דיאגרמת תשתית, runbook |
לוחות זמנים: 3–5 ימים לקלאסטר עד 6 מארחים. עם vSAN או תצורת רשת מורכבת, עד 7–10 ימים.
קבלו ייעוץ
נעריך את הפרויקט שלכם ביום אחד ונציע את הפתרון האופטימלי. צרו קשר כדי לדון בפרטים. הזמינו הגדרת vCenter turnkey—והתשתית שלכם תהיה סובלנית לתקלות ובעלת ביצועים גבוהים.