תחליף ל-vSphere?

OVirt-logo-highresאם יש שאלה שאני מקבל בשיחות רבות בכל הקשור לוירטואליזציה, זו השאלה "איזה כלי יש כדי להחליף vSphere?". אחרי הכל, לא מעט חברות לא כל כך אוהבות את המחירים של VMWare, את עלויות התמיכה השנתיות (למרות שברוב המקרים לא משתמשים בזה כי האינטגרטור או בחברה יש ידע לטפל בבעיה ותמיד יש את גוגל) ולא מעט חברות מעוניינות לקחת את ההשקעה שהם השקיעו ולעבור לפתרון אחר, עדיף בכמה שפחות כסף.

אז לפני שאענה על השאלה, חשוב למקד את הנושא: vSphere זו משפחה של מוצרים, לא כולם מתחילים עם "vSphere": כך לדוגמא יש את vSan, Orchestrator, vCenter, vRealize ועוד מוצרים רבים שמתחברים אל תשתית ה-vSphere.

האם יש כלי קוד פתוח שיכול להחליף את אלו ואחרים כ-Drop In Replacement ללא צורך בעבודת הקמה? התשובה, לצערי, היא לא. לא OpenStack ולא שום כלי אחר יכול להחליף בצורה של לקחת ערימת ברזלים, להתקין, להריץ איזה שהוא Coverter שימיר את הכל לתשתית החדשה ולאחר כמה שעות תוכלו להפעיל את הכל מאיזה מוצר אחר.

מה שכן, המוצרים שכן קיימים כיום הוא RHEV של רד-האט (בגירסה המסחרית) ו-oVirt שהוא כלי קוד פתוח שעליו מתבסס בעצם RHEV. עם הכלי הזה – יש אפשרות להמיר מערכת כמו vSphere Essentials (ללא כל האוטומוציה של Orchestrator, בלי דברים כמו vCloud Air ואחרים) למערכת כמו oVirt/RHEV.

אבל לפני שאתם יוצרים קשר עם חברה או פרילאנסר לתאם פיילוט להעביר את התשתית ESXI שלכם ל-oVirt/RHEV, אני ממליץ לקרוא את הדברים הבאים..

מבחינת ESXI, ב-VMWare עשו את הכל על מנת שחברה לא תצטרך להחזיק איש לינוקס (או איש עם ידע של לינוקס) בחברה בשביל לתפעל את המערכת. גם כשנכנסים ב-SSH לשרת ESXI, הידע שצריך בלינוקס/יוניקס הוא די מינימלי ולחברה שרוב מוחלט של התשתיות שלה מבוססות מיקרוסופט, VMWare יצרו את PowerCLI שעובד עם Power Shell כך שאפשר לעשות כמעט הכל מבלי לדעת לינוקס. גם הקורסים של VMWare לא ממש מתמקדים על לינוקס אלא מתמקדים במוצרים של VMWare עם נגיעות בדברים חיצוניים כמו רשת, סטורג' בצורה כללית, כך שמי שרוצה לדוגמא להרים את NSX, עדיף שידע רשתות בצורה רצינית (CCNA ומעלה), כי מהקמה של NSX בלי ידע רציני בתקשורת – לא מגיעים רחוק.

בעולם ה-RHEV/oVirt לעומת זאת, הצורך באיש לינוקס להקמה של הדברים הוא קריטי. עם הכלים הללו לדוגמא אין כלי אוטומציה יעודי כמו שיש ל-VMWare, מכיוון שברד-האט (לדוגמא) מבינים שאם אתה רוצה אוטומציה, אתה עושה את זה עם כלי אוטומציה כמו Chef או Puppet או לדוגמא אם אתה עובד עם Ansible אז יש לך מודול ל-oVirt כדי להקים, לעצור, להפעיל מכונות וישנם מודולים אחרים שעוזרים בדברים אחרים הקשורים לוירטואליזציה. השוני הגדול בין רד-האט ל-VMWare הוא שבזמן ש-VMWare משלבים עוד ועוד כלים כחלק אינטגרלי מ-vSphere/vCenter, ברד-האט עובדים הפוך: אתה יכול לעשות עם הפתרון החלופי שלהם ל-vCenter (מה שנקרא אצלם: Hosted Engine) והשאר יכולים להיות כלים שונים עם ממשק RESTful וכאלו שיש להם Plugins אל ה-Hosted Engine, כמו במקרים של Neutron, Cinder וכו'. אתה יכול לעבוד עם ה-GUI או עם virsh או להשתמש בספריית libvirt ולעשות את הכל בעצמך באיזו שפה שתרצה.

אז לקחת עכשיו כמה ברזלים ולהרים את oVirt? זה תלוי. באופן עקרוני ההמלצה של רד-האט היא להקים Nodes ועליהם להקים את Hosted-Engine ב-Clusters. ישנם 2 גרסאות של oVirt Node שההבדל המהותי ביניהם זה שגירסה אחת משתמשת בממשק "קלאסי" ובגירסה השניה התקנת ה-Node היא כבר עם ממשק שיותר מזכיר התקנת CentOS/RHEL ויש כבר ממשק גרפי שמשתמש בכלי Cockpit כדי לתת כלים מבוססי Web הן כדי לנהל את ה-Node והן כדי לתת ממשק אחר ויותר מודרני (בהמשך) לניהול ה-Engine.

מי שחושב להוריד את ה-ISO ולהתחיל מיד לעבוד, צפוי לכמה "הפתעות" לא כל כך נעימות כרגע.

ovirt-node-oldovirt-node-newנסיון התקנה של ה-ISO בגירסה ה"קלאסית" על מכונה אמיתית נותן את התמונה משמאל (לחצו להגדלה) ואילו נסיון התקנה של הגירסה החדשה נותן את התמונה מימין (לחצו להגדלה).

ב-2 המקרים, ניתן לתקן את תקלות ההתקנה בשימוש Kickstart חיצוני או באמצעות הקמת ISO חדש תוך שימוש בהגדרות מהפצות Fedora אחרות, אבל שוב – אלו דברים שמצריכים איש לינוקס מקצועי שיודע לטפל בדברים האלו ולהגדיר את כל השרותים שצריך ל-oVirt ושאר החלקים ב-Hosted Engine. לאחר הקמה של הדברים וערימת ההגדרות (שבהמשך תהיה כבר אוטומטית) המערכת די יציבה ואפשר להתחבר ל-vCenter ושרתי ESXI כדי להמיר מכונות VM אל המערכת החדשה (בזמן ההמרה המערכת משנה את הגדרות הדרייברים, כך ש-VM שעובר, מוכן לשימוש לאחר ההמרה) ואפשר להתחיל לעבוד עם המערכת החדשה.

מבחינת oVirt/RHEV – העתיד הוא דווקא עתיד טוב. המערכת עוברת ממצב של שימוש ב-JAVA ל-Node.JS, היא תהיה הרבה יותר אינטרקטיבית, היא תדע להתמודד עם רשתות מאוד מורכבות, כבר כרגע היא יודעת להתחבר ל-iSCSI, NFS וגם Infiniband (אם כי יש כמה Gotchas בנוגע ל-Infiniband). היא תומכת כבר עכשיו ב-Clusters, עם Live Migration, עם HA וכו'. יחד עם זאת, כדאי לזכור שחלק מהמושגים שונים כי הטכנולוגיה לגמרי שונה מ-VMWare ולכן אם אתם מחליטים לעשות פיילוט, ודאו כי הפרויקט כולל הדרכה, כי הדברים שונים, אפילו ברמה של ISO ל-VM השונים (לא ממש מסכים עם השיטה שרד-האט בחרו, אבל זו החלטה שלהם). האם לחכות לגירסה העתידית? אין ממש צורך בכך, גם הגירסה הנוכחית עובדת, ועובדת טוב (עבדכם הנאמן בדיוק ממיר מערכת מ-ESXI-6 ל-oVirt עם 75 מכונות VM פה בבית), רק קחו בחשבון שהקמה של מערכת כזו אינה עניין של שעתיים שלוש ויכולה לקחת מספר ימים ואם אין לכם אנשי לינוקס, מומלץ לסגור על בנק שעות לתמיכה ואולי הדרכה לאנשיכם.

כמה מילים על הקשחת שרתי לינוקס

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

נתחיל בנהלים ובתפיסות שגויות. לא מעט ארגונים מעדיפים לבטל את SELinux ואת חומת האש המובנת בהפצת הלינוקס כי "יש חומת אש רצינית מלפני התשתית ובין כה אף אחד לא מגיע לשרת הזה מבחוץ, אין גישה אליו מהאינטרנט". אני בהחלט מבין את הטיעון הזה, אולם במקרים הטיעון הזה שגוי הואיל ולעיתים נותנים גישה לגורם חיצוני מבחוץ (בין אם דרך VPN, דרך Team Viewer או דרכים אחרות) ואין שום אפשרות לוודא כי מי שנכנס מבחוץ הוא אכן מי שמיועד להיכנס או מה הכישורים והכוונה של זה שנותן תמיכה (כלל ברזל באבטחת מידע: תחשוד לפני שתסמוך). סתם דוגמא: חברה גדולה בישראל שנותנת תמיכה למאות (ואולי יותר) ארגונים משאירה חיבור פתוח מבחוץ (תוך ידוע החברה) עם סיסמא שילד בן 10 יכול לנחש, וזה ללא VPN, עם כניסת מקלאס כתובות של אותה חברה. תארו לכם שנכנס מישהו "מאוד סקרן" לתוך המערכת ניצול העובדה שסמכתם על אותה חברה? אני יכול לדמיין כמה סיטואציות לא כל כך נעימות.

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

ההמלצה הכי טובה להקשחה, במידה והמכונות הן VM, היא לא להקשיח מכונה קיימת, אלא להתחיל מאפס, עם kickstart (מכונות מבוססות RedHat/CentOS/Fedora9) או Kickstart/Preseed/FAI (מכונות מבוססות Debian/Ubuntu ונגזרות שלהן). גם בהתקנות פשוטות של CentOS/RedHat לדוגמא יש ערימה של חבילות שאין בהן צורך והן יכולות להיות בעייתיות מבחינת אבטחת מידע (CUPS, YP, ועוד. NMAP הוא כלי מעולה כדי לגלות שרותים שרצים בתוך המכונה ושאינכם זקוקים להן) כך שכדאי לבנות את קובץ האוטומציה ולהתקין דרכו את ה-VM כך שהמכונה תהיה נקיה, קטנה ומאובטחת.

אחד הדברים שכדאי וצריך לעשות על מנת להקשיח את המכונות (ואפשר להכניס את זה לתוך ה-kickstart) הוא שימוש ב-CIS Benchmarks. ה-Benchmark (שקיים למערכות הפעלה ואפליקציות שונות) נותן הדרכה כללית כיצד להקשיח את מערכת ההפעלה שלכם. השימוש ב-CIS נפוץ מאוד בבנקים, מוסדות גדולים ואחרים וניתן ליישם אותו על מערכות חדשות (דרך kickstart) או דרך מערכות אוטומציה כמו Puppet, Chef, Ansible וכו'. אפשר כמובן להשתמש ב-CIS כדי ליישם על מערכות קיימות, ומומלץ לרכוש את CIS-CAT כדי לבחון את ההקשחות.

שילוב של SELinux, חוקי חומת אש ומימוש CIS Benchmark יכול לסייע רבות בהקשחת מכונות (אם כי מימוש שלושת הדברים אינו מבטיח הקשחה מלאה).

אפשרות נוספת וחדשה (אם כי עדיין לא נכנסה בחברות רבות) היא שימוש בקונטיינרים, כאשר המערכת הפעלה הראשית מוקשחת לחלוטין ומאוד מצומצמת שמריצה קונטיינרים שמריצים אפליקציה אחת (או רק מספר קטן מאוד של אפליקציות שצריך, בד"כ מרימים קונטיינר פר אפליקציה). תוך כדי הפניית פורט יחיד (או כמות מינימלית של פורטים) אל ה-Host. כך אם נפרץ קונטיינר, אפשר לסגור אותו מיידית מבלי שיגרם נזק לקונטיינרים אחרים (מומלץ גם לא לאפשר שיתוף קבצים אם אפשר – בין ה-host לקונטיינר – במערכות פרודקשן).

לסיכום: הקשחה אינה רק הרצה של מספר סקריפטים. היא מצריכה ידע ולימוד מה המערכת מריצה ובדיקה האם צריך את הדברים ומה ניתן לעשות כדי לצמצם פעילות לא רצויה במכונה (מומלת להיעזר ב-Permissive Mode של SELinux לשם כך) ולהשתמש ב-CIS כדי להקשיח את רוב הדברים והפונקציות שיש במערכת. במקביל, כדאי גם לחשוב על אופציות נוספות שיכולות לתת לנו מערכות מאוד קטנות (קונטיינרים) על מנת לצמצם מאוד את סיכויי החדירה.