כמה מילים על פרסום בעיתון

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

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

עיתון PCON, עיתון דיגיטלי שמפרסם כל מיני תחקירים ראיין אותי בעבר והכתבה יצאה פחות או יותר דברים שאמרתי, ואילו הפעם כשראיינו (מראיינת אחרת) אותי על נושא שיש לי בו אי אלו שנות נסיון והתמחות – הדברים יצאו הפוכים ממה שאמרתי ולמען האמת – אני מטיל ספק בידע המקצועי של אותה כתבת.

pconתחקיר מס' 1271 שיוצא היום למנויי PCON ("הוירטואליזציה פורצת ומתפשטת"), מכיל את הטקסט שבתמונה משמאל.

האם באמת חברות ישראליות שמרניות בתחום אימוץ וירטואליזציה? לא, ההיפך הגמור הוא נכון! ישראל היתה אחת המדינות הראשונות שאימצה בחדווה את תחום הוירטואליזציה וחברת VMWare מכרה בארץ כמות יפה ונכבדה של רשיונות ועד היום היא מוכרת כמות נאה לכל הדעות.

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

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

אבל מחוץ לאופיס 365 – אכן יש כאן בארץ שמרנות בכל הקשור לאימוץ שימוש בעננים ציבוריים. הדברים אינם נאמרים כסוג של ביקורת רעה, חס ושלום, אלא כמציאות. כמה בדיוק חברות ישראליות גדולות העבירו תשתית רצינית לאמזון, אז'ור או גוגל Cloud? קשה לי להאמין שתמצאו אחת.

מדוע? הסיבה מחולקת למספר נקודות:

  1. אף ספק ענן ציבורי עוד לא הקים "אזור" (Region) בישראל (ולמען האמת לא נראה לי שזה גם יקרה בקרוב – אנחנו פשוט קטנים מדי בשבילם) מה שאומר שהמיקום הכי קרוב גיאוגרפית לשרתים יהיה בבריטניה או באירופה (אמסטרדם, פרנקפורט) ובהתחשב ב-Latency הנודע לשמצה של הקווים מישראל לחו"ל, מדובר על תוספת LAG המוערכת בין 70-140 מילישניות. ספרו את זה למנמ"ר של Corporate ממוצע ותראו איך הוא מיד מבטל אפילו מחשבות על מעבר לענן ציבורי כזה.
  2. מחיר מטורף: אם ניקח Corporate ממוצע שיש בו כמה מאות VM וננסה איכשהו להעביר אותם כמו שהם לענן ציבורי, החשבונית הראשונה שתתקבל תגרום לצעקות היסטריות בחברה, ואת זה אני יכול להבטיח. שום ענן ציבורי אינו בנוי כעוד חברת Hosting שמוכרת לרוב שרתי VPS או משכירה שרתים. בשרותי ענן העניין הוא להשתמש בשרותים שאותו ספק ענן מציע – בין אם זה DNS, SQL, או עוד כמה מאות שרותים נוספים, וה-VM (או ה-Compute) הוא עוד אחד מהשירותים וכשמשתמשים בשרותים שהספק מציע, ואז אתה מגלה שבמקרים רבים אתה צריך VM יותר קטן או שאתה יכול לפזר בין כמה שרותי VM קטנים או שאתה יכול לוותר על חלק מה-VM, כך שבמציאות אי אפשר סתם כך להעביר כמה מאות VM ולמכור את השרתים הפיזיים שיש בחברה מבלי לשלם מחיר מאוד גבוה.
  3. פחדים ורגולציות: קשה מאוד לחברות לקבל שכל ה-DATA הקריטי (ובמקרים רבים כולל סודות מסחריים ותכנים שלא אמורים לצאת החוצה כמו מיילים, פרזנטציות, קוד וכו') יושב באיזה ענן ציבורי מעבר לים, כך שהם חוששים. בנוסף, מוסדות שונים אינם יכולים להוציא DATA מחוץ לישראל עקב הסכמים ואיסורים שונים, כך שמבחינתם כל עניין המעבר הוא No Go.

ישנה שמרנות ב-Corporate לאמץ טכנולוגיות שאינן בדיוק Mainstream. כך לדוגמא כמות החברות שאימצו את OpenStack בארץ אינה גדולה למרות שזו פלטפורמה שיכולה להיות "מתחרה" או משלימה עם פלטפורמת הוירטואליזציה שיש ב-Corporate. ל-OpenStack אין בעיה להציע שרות Compute לדוגמא משלו (KVM, XEN) אבל אין לו בעיה לעבוד עם VMWare או Hyper-V שנמצאים בחברה, הכל תלוי בתכנון ובמימוש שיעשה. אותו דבר בכל מה שקשור לרשתות התקשורת בחברה (עניין סופר רגיש ב-Corporate) – אפשר לשלב עם תשתית התקשורת ואפשר גם להתחיל לחשוב לעבור ל-NFV עם OpenStack.  (ואם חברה צריכה הפניות או יעוץ בנושא – אפשר ליצור קשר. יש לא מעט גורמים שנותנים שרותי יעוץ, הטמעה, תכנון וכו').

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

לסיכום: Corporates הם גופים שמרניים. תמיד היו, תמיד יהיו. אולם לפעמים כדאי לאותן חברות להיות טיפ-טיפ-טיפה פחות שמרנית ולהקציב תקציב זעיר לפיילוט לאיזו פלטפורמה או מוצר ששומעים עליו רבות. לא צריך מיד לאחר הפיילוט להפוך את תשתית ה-IT של החברה, אבל יכול בהחלט להיווצר מצב שבהמשך הדרך, אותו פיילוט יכול להיות פתרון במקום לשלם כמה מאות אלפי דולרים על חידוש רשיונות או על קניית טכנולוגיה יקרה מאוד, ולמי שלא מאמין – תזכרו את התחיל Linux כשהמתחרים הציעו פתרונות שהיו יקרים באלפי אחוזים – ומי כיום שולט בשוק היוניקס.

עבודה כ-Devops

לעיתים יוצא לי לשוחח עם אנשים שעבדו במחשבים (או שעשו הסבה למחשבים) ורובם שואלים פחות או יותר לגבי נושא אחד: האם כדאי להשקיע בקורסים ולימוד לתחום סיסטם? (לינוקס, ווינדוז), האם יש עבודה בתחום, ואם לא – מה כדאי ללמוד?

אז נתחיל בעניין הסיסטם: בעבר, תחום הסיסטם היה מאוד פופולרי. אנשים היו לומדים MCSE (אם זה היה לגבי Windows) או RHCE או בחינה אחרת (לגבי לינוקס) והיו מתחילים לחפש עבודה בתחום. המשכורות אינם גבוהות אם אין לך נסיון – אבל היה אפשר למצוא עבודה.

כיום עדיין כמובן ניתן למצוא עבודה כאיש סיסטם מיקרוסופט או לינוקס, אולם יותר ויותר חברות פחות מחפשות אנשי סיסטם (במיוחד לא סטארטאפים וחברות שהשרותים שלהם באינטרנט) אלא יותר Devops.

שני הדברים שהכי קובעים בקבלת מועמד לעבודה הם ידע ונסיון. כשאדם לומד מ-ספר או קורס, יהיה עדיין חסר לו בין 50-90% מהידע שחברה צריכה. כך לדוגמא מבחינת Troubleshooting – רוב הקורסים בקושי נוגעים בנושא (וברוב עבודות הסיסטם הזמן שנשרף הוא על תקלות, בין אם זה AD שעושה צרות, SQL שעובד לאט, תקשורת איטית, תקלות ב-1001 שרותים ואפליקציות וכו' – ובלינוקס זה יכול להיות תקלות של ביצועי שרותים, שרת שלא עולה, הרשאות לא נכונות, Segfault של אפליקציות ועוד המון המון סוגי תקלות). בקורסים אולי מלמדים אותך איך להקים מערכות ושירותים – אבל בקושי נוגעים ב-Troubleshooting, ולכן חשוב לבדוק כמה שנות נסיון אמיתיות יש למועמד.

בתחום הסיסטם תמיד כדאי שיהיה לך נסיון בשפת סקריפטים כלשהי. בעולם המיקרוסופט כדאי מאוד שיהיה לך נסיון ב-Powershell וגם ב-Batch. בלינוקס – כדאי מאוד שיהיה לך נסיון לפחות ב-BASH ועדיף גם נסיון ב-Python או PHP, כלומר ידע ונסיון בשפת סקריפטים – חובה. ידע בשפת תכנות אחרות – זה פלוס.

בעולם ה-Devops לעומת זאת, אם יש לך נסיון בסיסטם (בין אם שנתיים או 5) – הידע הזה הוא פחות מהבסיס שצריך לאיש Devops. איש Devops צריך להכיר את הדברים בצורה הרבה יותר רחבה.

כמה רחבה? בניגוד לאיש סיסטם, איש Devops הוא בעצם ה"מכתיב" בכל התחומים שקשורים החל משרתים ועד לפיתוח. כך לדוגמא אם איש סיסטם הכיר Puppet לאוטומציה, איש Devops טוב יצטרך להכיר גם Chef וגם Ansible. הוא לא חייב להכיר אותם עד רמת הבורג, אבל צריך שיהיה לו ידע בהרמה לדוגמא של 2 שרתים, "חיבור" למערכת אוטומציה והתקנת שרות כלשהו, לדוגמא. עניין אחר הוא בשינוי מתודת פיתוח אפליקציות של החברה (במיוחד של חברות שנותנות שרותי SaaS לדוגמא) – בעבר חברות היו מפתחות גירסה 1 ואחר כך היו מתחילים לעבוד על גירסה 1.1 או 2. כיום חברות רבות עוברות לשיטה שבה הפיתוח הוא מתמשך ו"נזרק" מיד לפרודקשן לאחר שהוא מתקמפל ועובר סט בדיקות אוטומטי (מה שנקרא CI או Continuous Integration) ובשביל זה קיימים כלים כמו Jenkins. מי שצריך להרים מערכת CI, לכתוב לה סקריפטים, לכתוב בדיקות וכו' – הוא איש ה-Devops.

עדכון: להלן כמה דברים שאנשי Devops כותבים לגבי הנושא:

יבגני זיסלס כותב: "בוא נתחיל מזה שדבאופס, כפי שהגו האנשים שהכניסו לנו את המושג, זה בכלל לא קשור לכלי כזה או אחר. וזה גם לא ״בן אדם״, ז״א אין דבר כזה ״מהנדס דבאופס״ או ״צוות דבאופס״. אבל כמו כשציינתי, ככה מסתכלים על זה האנשים שהגו את המושג. היום יש גם את כל החברות והציידי ראשים והמחפשי עבודה שכמובן רואים את זה אחרת לגמרי, אבל אני קופץ קדימה מדי.
דבאופס לפי ההגדרה הראשונית, זה עניין של תרבות חברה. וכל הכנסים והפרסומים שמבטיחים שדבאופס יתן כל מני אחוזים ענקיים בשיפור העסק, כל זה מסתמך על השוואה של חברות שיש בהן תרבות דבאופס, לבין אלו שאין. אני מזמין אותך לקרוא את סקר ה-״דבאופס״ שחברת פאפטלאבס הכינו ב-2015 ו-2014, וכאשר אתה קורא את התוצאות שים לב שמדובר בתרבות, לא כלים.
אבל בוא נחזור אל מחפש העבודה הממוצע שחושב לעשות תיקון קריירה ולקרוא לעצמו ״דבאופס״. תתחיל בזה שכנראה הוא, והחברה שרוצה לגייס אותו, לא יועץ או פרילנסר. לכן לא באמת יש סיבה למישהו שעובד בחברה שעושה שימוש בשף, שיהיה לו ידע בסיסי בדברים אחרים. וכמובן גם חברה שמחפשת אנשים עם ידע בשף, לא צריכה את אלה שלא מכירים אותו.
עניין הנסיון הוא באמת משחק תפקיד די גדול אצל מישהו כזה שקורא לעצמו ״דבאופס״, אחרי הכל הכלים שאותו אדם טוען לדעת לא טריוויאליים, ולרוב לא היו בשימוש בעבר בשום מקצוע אחר (לא סיסטם ולא מתכנת ולא הלפדסק ולא בדיקות). אז יש כלי חדש, צריך תווית חדשה, ולמזלנו בדיוק הגיע ה״דבאופס״ הזה, אז למה לא. אבל נסיון בשימוש בכלי הוא שום דבר ליד נסיון בהבנה של מערכות, ויותר חשוב, בהבנה של מערכות של אנשים.
אתה בטח מכיר ארגונים שבהם הפוליטיקה שולטת, אז דמיין בן אדם בארגון כזה שיודע להשיג דברים שהוא רוצה שיקרו כאילו אין שום פוליטיקה … זה מיומנות, גם כאן יש אנשים עם נסיון בזה וכאלה בלי נסיון, וגם זה דוגמא לכלי, לא פחות חשוב משף או ג'נקינס.
קיצור, העליתי כמה נקודות, אבל המאמר בא לחזק בדיוק את הדברים שאנשים בעולם ה״דבאופס״ מנסים להעלים." (יבגני גם ממליץ לקרוא את ה-Agile Manifesto וגם את הקישור הבא)

עמוס שפירא כותב: "…בכלל מזה "איש DevOps"? הרי DevOps זה צורת מבט על כל תהליך הפיתוח (Dev) והרצת שרתים (Ops) כשלבים מאד קשורים אחד לשני, לעומת המודלים הקודמים שבהם אנשי הפיתוח לא יודעים כלום ולא מעניין אותם איך הקוד שלהם רץ בשטח והתפקיד שלהם נגמר כשהם " זורקים את הקוד מעבר לגדר" ("chuck over the fence").
מבחינת אנשי סיסטם (ואני לא בטוח כמה זה קשור ספציפית ל-Devops), איש סיסטם עדכני צריך להבין את החלק שלו בכל התהליך מהגדרת המוצר וכתיבת התוכנה (ששם הוא יכול לתרום בהסבר מראש מה הוא צריך כדי לעשות את החלק שלו) וכן לממש "infrastructure as code", אוטומציה של תהליכים, תמיכה בשרשרת הבניה והבדיקות של התוכנה וכו'." (למעוניינים, ישנו שרשור של אנשי Devops המתייחסים לפוסט זה ואנשי Devops מסבירים מה הוא המקצוע)

איש ה-Devops ברמת המאקרו צריך להכיר המון טכנולוגיות חדשות ועדיף שיהיה לו מבחינת שפות ידע ב-Python, JAVA ואם אפשר – גם RUBY (ולאחרונה מה שנהיה פופולרי – שפת Go של גוגל), אך כאן זה לא נעצר – איש Devops חייב להמשיך להכיר טכנולוגיות חדשות בזמן  העבודה או מחוץ לעבודה. מכיר קונטיינרים? אם לא – תכיר. אתה צריך להרים מכונות VM בצורה אוטומטית? תכיר את Vagrant והרשימה ארוכה ומתארכת כמעט כל יום או כל שבוע. כך לדוגמא בעבר אם היה לך נסיון ב-RDBMS כלשהו (החל מ-MySQL או SQL server של מיקרוסופט או Oracle DB) – כיום חברות רבות מחפשות ידע בשרותי DB שמבוססים NoSQL (כמו MongoDB ואחרים).

ואחד הנושאים הכי חשובים שאיש Devops צריך להכיר ברמה מעולה – הם העננים הציבוריים. פחות ESXI/Xen ויותר אמזון AWS, מיקרוסופט Azure, או גוגל Cloud Computing. כל אחד מהעננים הציבוריים מציע עשרות (ובמקרה של אמזון מאות) שרותים שונים ורוב מוחלט של חברות שמציעים שרותים באינטרנט – מארחות בענן ואותם שרותים שמציעים העננים הציבוריים נגישים דרך API או SDK (ומי ש"בונה" על ממשק GUI של ספק הענן – שיקח בחשבון שבמקרים רבים ה-GUI מספק פונקציונאליות פחותה מה-API) ובשביל להשתמש ב-API או SDK – יש צורך בידע בשפות כמו Python או JAVA ובמקרים מסויימים Javascript וידע ב-JSON לדוגמא.

לסיכום: המקצוע של איש Devops שונה מתפקיד של איש System. הוא כולל את התפקיד של איש סיסטם ולוקח אותו כמה צעדים (די הרבה, למען האמת) קדימה. איש Devops להישאר במצב של לימוד X והלימודים הבאים שלו יהיו שנה הבאה אם בכלל. הוא חייב להשקיע המון בלימודים של דברים חדשים. אלו שהתרגלו לעולם של מיקרוסופט יצטרכו לבצע לעצמם הסבה ללינוקס (מה לעשות, אמזון שולטת בשוק הענן הציבורי), הכרת VI (או emacs, לא nano), הכרת רשת על לינוקס, שרותים, סקריפטים ועוד ועוד.

ולאלו שמתעניינים במיוחד בשורה התחתונה של "כמה מקבלים" – באופן עקרוני, איש Devops מקבל יותר מאיש סיסטם, אבל שוב – תלוי כמה נסיון יש. אפשר להגיע ל-30K+ אם יש לך נסיון עשיר ב-Devops, Linux ונסיון טוב עם שרותי ענן של אמזון לדוגמא.

(גילוי נאות: כותב שרות אלו מציע שרותי Devops כפרילאנסר)

הבעיה עם MySQL והפתרון של אמזון

כמעט כל אתר קטן שרץ על לינוקס וצריך DB (ואיזה אתר לא צריך?) -אתרים רבים התחיל את דרכם עם MySQL. השפה עצמה יחסית קלה, התוכנה חינמית, יש תיעוד מכאן ועד הודעה חדשה לכל פונקציה ולכל בעיה והוא עושה את העבודה בצורה לא רעה. יש כמובן יותר טובים ממנו כמו PostgreSQL שגם הוא מבוסס קוד פתוח, אבל אם תשאלו כמעט כל סטארט אפ שהתחיל והשתמש ב-RDBMS, סביר להניח שההתחלה היתה על MySQL.

יחסית, MySQL יודע להסתדר די טוב עם כל חומרה שתזרקו לו, החל מ-512 מגהבייט של זכרון ודיסק SATA מכני פשוט ועד מעבדי Xeon E7 עם ליבות מרובים, מאות ג'יגהבייטים של זכרון ודיסקים SSD מבוססים NVMe. תצטרכו כמובן להגדיר דברים מסויימים בקובץ my.cnf, אבל בד"כ איש סיסטם טוב ידע להסתדר עם זה.

הבעיות מתחילות כשאנחנו צריכים להתרחב מבחינת כמות שרתים מעבר לשרת יחיד. מכאן אנחנו עוברים לשיטות כמו Master/Slave, אנחנו יכולים להשתמש ב-Sharding ויש עוד כמה שיטות. לכשזה עובד – הדברים עובדים בצורה טובה… עד שקורה Crash, צריך להשתמש ב-mysqlbinlog והסיפור לוקח זמן. בעיות אחרות יכולות לקרות אם הסינכרון נופל היכן שהוא. שורת הקללות שאיש הסיסטם (או ה-DBA) יפלוט – תהיה ארוכה.

חברות שונות כשגודלות מחליטות מסיבות שונות לעבור לפתרונות מבוססים NoSQL, בין אם זה DynamoDB, או MongoDB ופתרונות אחרים ששם עניין ה-Scalability נבנה בצורה אחרת והוא יכול להתפרס על פני מאות Nodes ויותר ב-Data Centers שונים בעולם. אם תסתכלו כאן לדוגמא, תראו שחברות גדולות מאוד ומפורסמות משתמשות ב-MongoDB והן מרוצות, מאוד.

אבל מה לעשות, חברות רבות לא רוצות או לא יכולות לעבור מפלטפורמת DB אחת לאחרת שהיא שונה מהותית. חלק מאותן חברות לדוגמא, משתמשות בוורדפרס כמערכת עיקרית שעליה הם כותבים את האפליקציות שלהם. חברות אחרות השקיעו עשרות אלפי שעות אדם בכתיבת אפליקציות שעובדות מול MySQL ושכתוב חלק גדול ל-NoSQL אינו בא בחשבון, כך שבסופו של יום – יש לא מעט חברות וארגונים שבשבילם MySQL הוא דבר חיוני מאוד, והם לא מעוניינים לעבור למשהו אחר שונה.

באמזון, חברת הענן הציבורי הגדול בעולם, החליטו בהתחלה להציע את שרות ה-RDS ואחת האופציות העיקריות שם היא MySQL מנוהל. אתה מגדיר בהתחלה אם אתה מעוניין ב-Instance יחיד קטן או שאתה מעוניין בשימוש מספר Availability Zones (כך שתהיה רפליקציה של ה-DATA באזורים שונים ב-Data Center), אתה מחליט על גודל מכונה, כמות אחסון וכמות IOPS (חישוב שאני אישית שונא) ואתה מקבל Instance של MySQL שאמזון מנהלים עבורך. מבחינת חברות שכבר שמות את האפליקציה שלהן בענן – זה פתרון טוב יותר מאשר סתם לשכור מספר Instances ולהתחיל לעשות את כל עבודת ה-MySQL ידנית, אבל עדיין, מבחינת השוואת ביצועים – Instance שאתה תרים על מכונה חזקה מאוד – יהיה יותר מהיר מ-RDS (אם כי כמובן אתה תפסיד הרבה מהפונקציונאליות של RDS ואתה תצטרך לבצע הרבה דברים ש-RDS מבצע לבד).

נעזוב לרגע עניינים טכניים ונקפוץ לתחרות בין ספקי ענן. אורקל, זה לא סוד – מתחילים להציע שרותי ענן וגם מיקרוסופט מציעים לחברות שונות לאחסן את האפליקציות ושאר חלקים בענן שלהן. קרדיטים מחולקים בחינם, הבטחות לתמיכה ו-Uptime רציני וכמובן סיוע בהעברת הקוד/אפליקציות/שרותים אליהן. צריכים DB רציני שיתן לכם מענה למאות אלפי, מיליוני ועשרות מילוני גולשים? למיקרוסופט ואורקל יש פתרונות שיעלו לכם ממש בזול (כל עוד תתארחו בענן שלהן כמובן). וכמובן שהן נותנות תמיכה מלאה בלינוקס ואין שום בעיה שמה שאתה מריץ אצל המתחרים לא ירוץ אצלן.

אמזון מצאה את עצמה בבעיה: בניגוד למיקרוסופט ואורקל, אמזון לא יכולה לבצע "בעל הבית השתגע" ולחתוך מחירי DB מכאן עד הודעה חדשה. אורקל יכולה להנמיך את המחיר לסנטים פר שעה על ה-DB שלה וגם מיקרוסופט יכולה, אבל אמזון (שמציעה גם SQL של מיקרוסופט וגם של אורקל) צריכה לשלם לחברות האחרות על הרשיונות ובכלל – פתרון ה-RDS דרך MySQL לא בדיוק מלהיב חברות גדולות.

לכן באמזון בנו מוצר חדש שנקרא Aurora שבא בעצם לתת פתרונות לכמה דברים:

  • הוא בנוי מהרגע הראשון ל-High Availability. צריך Instance יחיד לבלוג שלך או שה-? חזור ל-RDS עם MySQL.
  • אין יותר הגדרות של Storage וה-Storage הוא אינו חלק מהמכונה. מעתה ה-Storage מנוהל ע"י אמזון והוא גודל דינמית לפי הצרכים של ה-DB שלך עד לגודל מפלצתי של 64TB!
  • היא מהיר הרבה יותר מ-MySQL – פי 3-5.
  • אתה יכול לבצע מיליוני טרנזאקציות בדקה מ-Instance ואם אתה צריך עוד רפליקות, אתה יכול להוסיף עד 15 רפליקות.
  • ה-DB נופל ברפליקה מסויימת? שכח מזה, Aurora מטפל ומנטר לבד הכל.
  • ה-DATA שלך שמור בלא פחות מ-3 עותקים ב-AZ, כך שאם יש לך Crash, השחזור הוא מיידי.
  • יש לך Snapshots ואתה יכול לבחור Snapshot ולהשתמש בה כ-DB עיקרי מיידית.
  • אין לך צורך לנהל כמעט שום דבר, גם עדכוני תוכנה מבוצעים מיידית בזמן שתגדיר במערכת
  • מכונות גדולות – אתה יכול להרים מכונה עם עד 244 ג'יגהבייט זכרון ו-32 ליבות.
  • אפשר תוך מספר קליקים לעבור מ-RDS עם MySQL ל-Aurora

ומה שהכי חשוב: Aurora תואם MySQL 5.6 בתצורת On the wire, כלומר האפליקציה שלך לכשתתחבר אל ה-Instance, תחשוב שמדובר ב-MySQL לכל דבר ועניין.

לכן, הפתרון עם Aurora נותן מעלה טוב מאוד לכל אותן חברות שרוצות להמשיך עם MySQL אבל רוצות לתת פתרון שיכול לעמוד בקצבים גבוהים ובגידול מאסיבי בתוך זמן קצר מאוד (פיקים לדוגמא) וכל זאת מבלי לשבור את הראש על קלאסטרים, Sharding, Master/Slave ועוד הגדרות רבות.

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

יש גם חסרונות:

  • אם גודל ה-Datasize שלך הוא די קטן (כמה אלפים) – Instance שתרים משלך עם 3000 IOPS ירוץ יותר מהר מ-Aurora (אם תשתמש ב-DB חלופי ותואם כמו Percona)
  • ה-Aurora עדיין לא מהיר ברוב המקרים בהשוואה ל-Percona גם ב-Datasize גדול (אתם מוזמנים לקרוא את המאמר שלהם כאן).
  • אם יש לך איש סיסטם בחברה, הוא יכול לבנות פתרון יותר טוב מ-Aurora  בין אם בשימוש Percona או גם MariaDB, עם אחסון בעל IOPS גבוה ובניית שרידות שמורכבת מ-AZ, כך שבשביל חברות כאלו – Aurora לא יתן הרבה.

הדבר היחיד שחסר בזה – איזה Free Tier לשחק איתו 🙂

סוגי מחשוב ענן

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

לדוגמא – כאן בישראל ישנן מספר חברות שתוקעות את המושג "ענן" על שרותים שכל חברה יכולה להריץ במשרד שלה כאשר בתכל'ס מציעים לך VM או מספר מכונות VM, והם מציעים עוד שרותים שרצים על שרת 2012 כמו "VDI", תיבות מייל וכו'. לא בדיוק מה ש-Corporate צריכים אבל עסקים קטנים כן צריכים ועסקים גדולים יכולים אולי להשתמש בזה כמכונות חרום שיושבות בחוץ או כמכונות מופרדות מהתשתית להצגת אתר החברה וכו'.

חברות ענן נוספות מוכרות שרות מסוים וזה בעצם המוצר שלהן, הן לא מנסות למכור לך 1001 שרותים אלא אך ורק שרותים במסגרת קטגוריה מסויימת. כך לדוגמא חברת Deserve-IT מציעה שרות DR בתצורה מעניינת: לא חשוב מה ה-Hypervisor שאתם מריצים ב-Corporate שלכם, בין אם זה vSphere או Hyper-V – השרות שלהם יוכל לסייע לך להפעיל במקרה חרום את המכונות שלך מחוץ לתשתית המקומית שלך. (נכון לזמן כתיבת שורות אלו, הם תומכים ב-ESX ו-Hyper-V ובקרוב תהיה תמיכה מול OpenStack).

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

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

עננים: מעבר לענן ושרידות מאוד גבוהה

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

כשזה מגיע למעבר מ-VM/VPS, עוד בשלב הבדיקה אנשים רבים נכנסים ל"הלם": המחירים שאמנם נראים בהתחלה נמוכים (כי הם מחושבים לפי שעה) מהר מאוד מתבררים כגבוהים, יש צורך לשלם על תעבורה יוצאת עוד מהג'יגהבייט הראשון, ובמקרים מסויימים – דיסקים מקומיים אינם מיועדים לשמור את התוכן של המכונה שלך (הם נמחקים). לכן חשוב לזכור – אם יש לכם אתר גדול שרץ כרגע על שרת VM יחיד והוא מתארח אצל ספק VPS כלשהו בארץ או בעולם – העברת האתר שלכם לענן לא תחסוך כספים ובכל מקרה ספק ענן ציבורי רציני לא ינסה להתחרות עליכם. יש לכם בעיות ביצועים? אפשר לבדוק ואפשר לראות מה ניתן לעשות, אבל מעבר לענן לא יעשה שום "הוקוס פוקוס" לביצועים..

מכאן נעבור לחברות שרוצות להעביר את התשתית שלהן לענן: חברות הענן אינן מנסות למכור לכם VM גדולים בזול. הן תמיד תהיינה יותר יקרות מכל ספק אחר שאינו ענן. מה שכן הן מנסות – זה למכור לכם את השירותים שהן מציעות במקום שתרים אותם על השרתים שלך אצל אותו ענן. לדוגמא: צריך SQL כלשהו? (לא חשוב אם זה MySQL או מיקרוסופט SQL או DB של אורקל) כמובן! אז במקום שתרים אחד כזה, אמזון מציעה לך שרות RDS (כן, גם ל-SQL Server וגם לאורקל), וישנם המון סוגי שרותים אחרים שהיתרון שלהם הוא מחיר (יחסית) זול, ושאתה לא צריך לתחזק כלום (ובין כה הם עושים שרות תחזוקה הרבה יותר מקצועי ממה שרבים עושים). אתה תשלם רק על הדברים שתגדיר ותשתמש, אין תשלום מינימום ואין תשלום מראש.

לכן, עם שרותים אלו, כמות ה-VM שתצטרך תצטמצם משמעותית. יכול להיות כמובן שתצטרך VM חזק בשביל שרת אפליקציות שלך, אבל לא תצטרך שרת בכלל עבור DB. יש לך מספר משתמשים גדול? אתה לא צריך קופסאות Load Balancing, אתה פשוט משתמש בשרותים של אותו ספק ענן לביצוע איזון עומסים. מתעקש על חומת אש מה-Brand האהוב עליך? יש לך VM מוכן יחד איתו, בחר, תקים ותשתמש, תשלם פר שעה עליו, ומה שהכי חשוב – אין יותר צורך בתחזוקת חומרה, סוויצ'ים, וכו'. הכל כבר מטופל ולבחירתך מגוון מסלולי תמיכה, כך שגם אם יש תקלות ביום כיפור – יש מי שיענה לך.

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

  • איזו מערכת הפעלה רצה על ה-VM אצלך שאתה רוצה להעביר? כל ספקי הענן הגדולים טוענים כי הם תומכים בכל מערכות ההפעלה. זה נכון בצורה חלקית. רשמית מה שהם מצהירים הוא נכון אולם בתכל'ס אם רוב ה-VM שלך מבוססים לינוקס, אין לך מה לעשות בענן של מיקרוסופט. לך לגוגל או אמזון. אישית, צמחו לי מספיק שערות לבנות מהתמיכת לינוקס של מיקרוסופט.
  • מי נותן לך קרדיט ראשוני (וכמה)? ספקי ענן שונים נותנים קרדיט ראשוני שנע בין כמה מאות דולדרים לכמה אלפי (או עשרות אלפי) דולרים. כמה ספק הענן מוכן לתת לך כדי להתחיל לעבור?
  • ניהול, תחזוקה, הגירה, הגדרות וכו' של השרותים וה-VM אצל ספקי ענן לא מבוצעים בד"כ דרך ממשק GUI אלא דרך כתיבת סקריפטים או אפליקציות תוך שימוש ב-API של ספק הענן. האם הספק תומך בשפות שאנשי ה-IT שלך מכירים או שהם רק יודעים PowerShell והספק מצריך ידע ב-Python/PERL? נכון, ספקי הענן ברוב המקרים נותנים תמיכה גם וגם, אולם ישנם לא מעט עניינים של פתרונות תקלות המצריכות שימוש בשפות ש"חביבים" אצל ספק הענן.
  • מעבר לענן מצריך שינויים מאסיביים בכל תכנון התשתית כולל דברים כמו Storage, Networking ועוד. פה יש לך NetApp/EMC שעליו אתם זורקים הכל, בענן אם תנסה לבצע את אותו טריק, תקבל חשבונית חודשית מבהילה! יש צורך בהפרדה של תכנים סטטיים ודינמיים, אפליקציות ו-VM שצריכים IOPS גבוה וכאלו שיכולים להסתדר עם כל דבר שתזרוק עליהם – לכן חובה לקחת בחישוב השכרת יעוץ/פרילאנסרים שיסייעו לך בתכנון המעבר ולאחר מכן ביישומו.
  • האם לספק הענן יש נציגות טכנית מקומית שנציגיה יכולים להגיע למשרדכם? טלפון/מייל זה טוב, אבל לפעמים פגישה פרונטלית יכולה לסגור קצוות רבים בפגישה אחת.

מכאן נעבור לשרידות: אצל ספק ענן אתה יכול לקבל שרידות גבוהה יותר ממה שאתה מקבל אצל ספק VM/VPS כלשהו. אפשר להשתמש בשרותים שונים כדי להרים VM מוכנים במקרה ויש עומסים פתאומיים (ולשרשר אותם מיידית ל-Load Balancer), והשרתים מתוחזקים בצורה כזו שגם אם VM נופל, הוא מיד קם על מכונה אחרת מיידית ללא צורך בהתערבות ידנית. ככלל, כל ספקי הענן נותנים לך תיעוד איך להקים את האפליקציה שלך/שרות שלך כ-Fault Tolerance.

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

לשם כך מומלץ לחשוב על אחד מהפתרונות הבאים:

  • כל ספק ענן מכובד (במיוחד השלישיה) מציע את השרותים במספר אזורים שונים בעולם. מה שאתם יכולים לעשות הוא להקים את התשתית שלכם בתצורה המינימלית בעוד אזור (Region) עם סינכרון דו כיווני (או רב כיווני, בהתאם לתשתית שלכם) בין האזורים וכל מה שצריך הוא מכונת VM קטנה מאוד שתדגום את האזורים כל הזמן. היה ואזור עיקרי לא מגיב, ה-VM הקטן ישנה את ה-DNS ושאר פרמטרים כדי שלקוחותיכם יקבלו שרות מהאזור המשני שהקמתם. (האזורים מופרדים מבחינת מערכות כך שנפילה באזור 1 אינה משפיעה על אזור 2)
  • ישנן מספר ספריות שונות (כולן בקוד פתוח) המאפשרות לך לעבוד דרכן ולהקים את השרותים שלך אצל יותר מספק ענן יחיד, כך שתוכל לקבל שרידות יוצאת מן הכלל. החסרונות בשיטה זו:
    • אתה צריך לשלם על התעבורת סנכרון בין ספקי הענן
    • ספריות אלו לא תמיד מעודכנות ולעומת זאת ספקי הענן משנים API במקרים רבים כך שהספריה לא כל כך תעזור.
    • יש הרבה יותר עבודה לעשות בהקמה/הגדרות וגם תחזוקה.

לסיכום: ענן זה לא לכל אחד. מחפש VM/VPS זול בשביל האתר שלך? תציץ ל-Digital Ocean לדוגמא (והם מאוד יציבים, מנסיון). אם לעומת זאת יש לך אתר/שרות מאוד גדול, כדי לעבור על הנקודות והדברים שציינתי לעיל לפני שתחליט לעבור ולפני שתזרוק כספים על הפרויקט/אנשים/תכנון/יעוץ וכו'. אם האתר שלך בעל תעבורה רבה והוא מקור הרווח שלך, כדאי לחשוב ברצינות על שרידות תוך שימוש באזורים.

חג שמח 🙂

הערה קטנה: אני מחפש עבודת 50% משרה קבועה (תשלום כפרילאנס) בתחומי לינוקס/וירטואליזציה/סטורג' מבוסס תוכנה. אם אתם מכירים משהו, אשמח אם תיצרו עימי קשר.

האם VSAN יכול לשמש כתחליף ל-Storage יעודי?

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

השאלה פשוטה: האם VSAN יכול להחליף פתרון Storage יעודי?

אסביר: במקרים רבים לחברות יש Storage יעודי שנקנה לפני מס' שנים ועלות חידוש חוזה תמיכה/תחזוקה גורמת להרהורים לגבי פתרון חלופי. יש מקרים שה-Storage מגיע ל-End Of Life ויש גם מקרים שמוצאים שמי שהחליט לרכוש Storage החליט להקשיב יותר לנציג השיווק מאשר לבדוק מספרים טכנית לגבי מה ה-Storage יכול להנפיק והתוצאות כרגע לא מספקות.

אם תקשיבו לתשובה מנציגי המכירות של VMWare (או ריסלרים שלהם) אז במקרים רבים התשובה תהיה ש"כן", בוודאי ש-VSAN יכול להחליף קופסת Storage.

החלק שהם לא כל כך ישימו עליו דגש – זה המחיר שצריך לשלם כדי להגיע לביצועים של Storage רציני מודרני מהשנתיים האחרונות. אם לדוגמא יש לך 10 ברזלים ואתה מחפש מקסימום IOPS, תצטרך למלא כל תושבת PCI וכל כניסת SAS ב-SSD מבוססי PCIe או SAS (מה-12 ג'יגהביט) מהקצה העליון כלומר שכל SSD כזה עולה לך כמה אלפי דולרים טובים. כך תקבל באמת מקסימום Performance ומיליוני IOPS אבל אתה כבר מדבר על עשרות אלפי דולרים ומעלה, ובמקרים כאלו, לעיתים הכדאיות הכלכלית נוטה לכיוון הארכת חוזה על ה-Storage הקיים ושדרוגו. אחרי הכל, קל יותר לדחוף מגש SSD, לשדרג/להוסיף SP (כל זה אם האפשרויות קיימות) מאשר להתחיל מאפס.

גם במקרים בהם ה-CEO וה-CTO מחייכים ומוכנים לממן VSAN עם כל הציוד שתיארתי בלינק ועם מילוי כל חור ב-SSD מהקצה הגבוה – ישנה בעיה מהותית אחת.

כפי שאנו יודעים, ב-Corporate טיפוסי במקרים רבים הוירטואליזציה אינה אחידה. פה הכניסו Hyper-V שנשאר כ"ירושה" מה-CTO הקודם שהחליט לעבור לפתרונות מבוססי מיקרוסופט בלבד, שם החבר'ה שמפתחים בלינוקס הכניסו Docker, ובל נשכח כל מיני שרתי ESXi ישנים שקיימים פה ושם כי מישהו הנחית הוראה מגבוה לא לשדרג כי אין יותר דרייברים חדשים לכרטיסים שבתוך ה-ESXi והמערכת עובדת ו"נא לא לנגוע" (כן, ראיתי גם מקרים כאלו). במקרים של Storage רגיל – אין בעיה, לכאן אתה מוציא SMB, לכאן אתה מוציא NFS ולשם אתה מכין כמה LUNs ומייצא כ-iSCSI ונגמרה הבעיה.

אבל VSAN לא יודע לעבוד כך. VSAN מכין Datastore ענק שהוא מיועד עבור ה-VM שרצים ב-hosts שמשתתפים ב-VSAN. יש לך ערימת שרתי ESXi שלא משתתפים ב-VSAN או שהם עם וירטואליזציה אחרת? הפתרון היחיד שיש לך הוא הקמה של VM באשכול השרתים שמשתתפים ב-VSAN ומשם לייצא החוצה CIFS/NFS/iSCSI. כמה זה מהיר וטוב? זה מאוד תלוי מה רץ על ה-VM שמייצא את השרותים הללו החוצה, אבל בכל מקרה אני מהמר שמול Storage מודרני מול VM כזה, ה-Storage המודרני ינצח עם יד קשורה מאחור מכיוון שיש לו הרבה יותר פונקציונאליות ממה ש-VSAN בתוספת ה-VM שמייצא – נותנים. בל נשכח של-VM עם VSAN אין גישה ישירות לבקר או לדיסקים, את זה יש רק ל-VSAN כך שאין לך דברים כמו dedup, tiering וכו'.

היתרון הגדול של VSAN הוא רק כשאתה מריץ ESXi וכל השרתים משתתפים ב-VSAN (אגב, לא חובה "לפוצץ" את כל הברזלים ב-VSAN, אפשר למלא את רובם ולחבר עוד כמה ללא SSD/דיסקים מכניים ואותם שרתים ישמשו כ-Compute Only). אז באותם מקרים אפשר לקבל שרידות מעולה ואין מקרים של "Storage נופל וכל ה-VMs למטה". גם אם שרת פיזי יקרוס אז המכונות VM שרצו עליו יעשו reboot בשרתי ESXi האחרים ואפשר גם להגדיר ש-2-3 שרתים נופלים, אז ה-VM החשוב יעלה במכונה תקינה (מה שנקרא FTT ולזה כמובן יש מחיר מבחינת כמות נמוכה יותר של Free space בדיסקים).

כל מה שתיארתי לעיל מדבר על גירסת VSAN הנוכחית (6.0). ב-VMWare החליטו שעם כל הכבוד לחברה האחות (EMC) – הם יתחרו בשוק ה-Software Defined Storage ואין לי ספק שהם יוסיפו הרבה מאוד פונקציונאליות ל-VSAN כדי לפתור גם את הבעיות שתיארתי לעיל, כך שכדאי לעקוב. כנס VMWorld יתחיל ביום שלישי כך שסביר להניח שביום שני והלאה יצאו הכרזות מצד VMWare ושותפים לגבי גרסאות חדשות למוצרים. אני אפרסם את ההודעות החשובות בפורום VMWare בפייסבוק ואתם מוזמנים להצטרף.

גילוי נאות: הח"מ מספק שרותי הטמעה גם ל-VSAN 🙂

פתרונות קוד פתוח כתחליף ל-Hypervisor מסחרי

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

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

האם קוד פתוח יכול לתת פתרון הולם כתחליף לדברים כמו ESXI?

ישנן לא מעט חברות שחושבות על פתרון כמו Open Stack כתחליף ל-ESXI. הרעיון עצמו על פניו נשמע הגיוני, אחרי הכל Open Stack מאפשר לך גם Network, גם Compute וגם Storage, אבל כשבודקים בפונקציות ההכרחיות שצריכים מה ESXI נותן ומה Open Stack נותן, התוצאות לעיתים מעודדות ולעיתים לא.

אך הבעיה המרכזית של Open Stack היא כמות הידע הנדרש על מנת להפעיל ולתחזק אותו. טכנית, ניתן להרים מערכת Open Stack שלמה תוך דקות ספורות (אם יש לך את המשאבים) מכל מיני חברות, אך ברגע שמשהו לא עובד – תצטרך או תמיכה מסחרית של חברה, או מישהו שיודע ממש ממש טוב לינוקס ורשתות, ולהסתפק בתמיכה של Mailing list או אולי IRC. איש סיסטם עם ידע בהפצת לינוקס כלשהי במקרים רבים פשוט לא יספק מכיוון שמדובר במערכת מאוד מורכבת ומסובכת (וכמובן תלוי בכל מיני קומפוננטות אם הן צד ג' קוד פתוח או מוצרים סגורים).

בנוסף – Open Stack עדיין מתאים לחברות ממש גדולות והוא לא ממש מתאים לחברה שיש לה מספר קטן של שרתים פיזיים.

פתרון אחר הוא Xen שמוכרות חברות שונות כמו Citrix או Oracle או להריץ את הגירסה הפתוחה ב-Xen Project ולחבר לזה את ה-Client של Citrix דרך Windows או להשתמש בכלים אחרים. אם יש לך כמות VM קטנה יחסית, הפתרון הזה יכול לעבוד לא רע בכלל. הפתרון של Citrix דווקא נותן "פייט" לא רע לפתרון של ESXi אבל אם אתה צריך תמיכה – תצטרך לרכוש את המוצר המסחרי.

עוד פתרון שחלק חושבים שיכול לסייע להם (אך הוא לא) הוא KVM. בעקרון KVM הוא בעצם "מנוע" וירטואליזציה, הוא זה שבסופו של דבר גורם ל-VM לפעול. הוא לא יודע ליצור דיסק ל-VM, הוא לא יודע להגדיר שום דבר ל-VM, אתם צריכים להזין לו את כל הדברים ידנית (או דרך סקריפט) ולכן KVM בד"כ לא מומלץ לשימוש "ידני", אלא מומלץ לשימוש בשילוב כלים, לדוגמא virsh שנותן command line לנהל את כל ה-VM או libvirt שזו ספריה שתומכת ב-binding בשפות רבות כך שניתן בשפה החביבה עליך להרים מכונות מבוססות KVM, לכבות, לעשות מיגרציה, ופעולות רבות אחרות.

אבל כמו שרובינו יודעים, אנשי IT אוהבים GUI, תן להם GUI גרפי, והם מחייכים, ואם אפשר שאת אותו GUI לממשק אותו דרך API לשפה החביבה על אנשי הלינוקס בחברה -אז כולם יכולים לחייך.

פה נכנס כלי שרד-האט מפתחת שנקרא oVirt. הכלי הזה יודע לנהל יפה שרתים שמריצים את Ovirt Node (שזו גירסת לינוקס מאוד מקוצצת שמותקנת "על הברזל") ומאפשרת פונקציות רבות שקיימות במערכות vSphere. למי שרוצה, יש גם גירסת LIVE שלא מצריכה התקנה, רק להוריד ISO, לעשות Boot ולשחק עם זה (רק כדאי שיהיה מחשב נוסף שישמש כ-Node). גם כאן, אם אתם צריכים תמיכה, תצטרכו את זה מ-רד-האט בתשלום לפי תושבת, או דרך ה-Mailing list / IRC אם אתם בוחרים באופציית החינם. שימו לב ש-oVirt הוא כלי שמצריך השקעה בלימוד.

עוד אופציה שיש בקוד פתוח היא מערכת שנקראת  ProxMox, ודרכה אתה יכול להרים VM, ולבצע ניהול ודברים נוספים. היתרון של Proxmox על פני פתרונות אחרים הוא קלות השימוש בכלי. הוא לא מציע פונקציות רבות כמו oVirt אולם אם יש לכם מספר שרתים קטן והרשת הולכת להיות די פשוטה, Proxmox יכול להוות פתרון לא רע.

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

ולבסוף – הנה קישור שאני מציע לכולם לראות – טבלה המשווה בין הוירטואליזציות השונות.

תחום האחסון בעוד 5 שנים

אני רוצה שנחזור אחורה בזמן (לותיקים מאיתנו) בערך 20 שנה אחורה, לתחילת שנות ה-90. אם היית צריך שרת "עצבני" – היו לך מספר פתרונות, כולם קנייניים – בין אם זה HP-UX, או IBM AIX, או כמובן Solaris של Sun. אם רצית להריץ UNIX טוב על מערכת מבוססת X86, הפתרון המסחרי שהיה לך הוא של SCO ואם חיפשת לחסוך בכך שתלך ל-X86, היית מוצא מהר מאוד שטעות בידך – SCO דרשה בזמנו סכום של בערך $4500 דולר עבור רשיון ל.. TCP/IP, וזה פר שרת. היית יכול כמובן לנסות את גרסאות ה-BSD או את המערכת הצעירה שנקראת Linux, אבל אם היית מראה את זה ב-Corporate, היית מסתכן בצרות. אם היית שואל חברות אחרות על Linux, הן היו אומרות לך שזו מערכת "נחמדה" אבל לא יציבה ולא חזקה ולא תומכת בהרבה דברים וכדאי שתשכח ממנה ותתרכז בפתרון הקנייני שישאר איתך "לשנים רבות" ורק ישתפר.

נחזור חזרה ל-2015, וכיום אם אתה מרים מערכת שאינה Windows, סביר מאוד להניח שהיא תהיה Linux. איפה SCO? נעלמה. איפה AIX או HP-UX? נמצאים במקומות בודדים מסויימים, ושאר מערכות ה-UNIX המסחריות למיניהן מתו. נשארו הגרסאות בקוד פתוח כמו BSD לסוגיו וכמובן הפצות הלינוקס. כיום ב-Corporate (לפחות הבינלאומי, הרבה פחות בישראל) אינו נראה כדבר נורא וחברות למדו לאמץ את מערכת ההפעלה, במיוחד שחברה כמו Red Hat נותנת להם שקט לעשור שנים פר גירסה, והיצרנים מקבלים את ה"הכשר" של Red Hat שה-Corporate מאוד רוצה לראות. יש גם תמיכה 24/7 וגם הגנה נגד תביעות של פטנטים. כיום אם תרצה להכניס Solaris במקום Linux, זה יהיה לך הרבה יותר קשה, כמו שלפני 2 עשורים מאוד היה קשה להכניס Linux.

גם תחום הוירטואליזציה עבר פחות או יותר את אותו מסלול אם כי בפחות זמן. ל-IBM היו פתרונות "וירטואליזציה" עוד משנות ה-70 (DISCO) ולחברות אחרות היו גם פתרונות של "וירטואליזציה" (אתם יכולים לראות רשימה מלאה, אם כי לא עדכנית – המסמך נכתב ב-2004 כאן) כך שחברות שהריצו מערכות MainFrame יכלו להריץ עוד עותקים של אותה מערכת הפעלה כתהליך (Process) עצמאי (פחות או יותר) וב-2004 חברת Sun הציגה את Solaris Container, שנתן פחות או יותר את מה ש-IBM נתנו 30 שנים לפני כן. בערך באותו זמן החלה חברה צעירה בשם VMWare להציע פתרון וירטואליזציה מעניין – בהתחלה בדסקטופ ואחר כך לאט לאט בשרתים – את ה-ESX (שנהפך במשך הזמן למשפחה ענקית [ולפעמים ענקית מדי] של מוצרים).

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

אז עברנו בשנים האחרונות מ-UNIX ל-Linux, ומשרתים פיזיים שמריצים מערכת הפעלה יחידה לשרתים שמריצים מערכת וירטואליזציה ועליהם רצים עשרות או מאות שרתים וירטואליים.

אנחנו נמצאים עכשיו בתקופת מעבר מעט שונה שאני מאמין שתחל להיות מיושמת בשנה שנתיים הקרובות וביתר שאר ב-4-5 שנים הקרובות, והיא – מעבר ל-Storage שאינו "ארון".

אם נסתכל היום על Storage ממוצע, נמצא שהוא מורכב מהרבה "מדפים" (Shelves), אולי מתג לסיב אופטי, (Storage Processor(s (שעושים בעצם את כל העבודה) ואולי עוד כמה מודולים, בהתאם ליצרן ה-Storage, דגם וכו'.

נסו לדמיין את ה-Storage שיש לכם ב-Corporate. ה"מפלצת" הזו, עתירת הטרהבייטים שנותנת שרותי קבצים, NFS, iSCSI ואולי עוד שרותים – היא היא ה"לב" של ה-Data Center והיא מאחסנת את המידע החשוב שלכם. את הדבר הזה אתם צריכים שיהיה הכי יציב שיש. אם זה נופל – שרותים רבים לא יהיה זמינים למשתמשים שלכם. אם יפול לכם מתג (Switch) בחברה, תוכלו להתגבר בכך שתנתבו חלק מהכניסות למתגים אחרים. אם שרת פיזי יפסיק לפעול, אתם תבצעו העברה/הפעלה של המכונות הוירטואליות במכונה פיזית אחרת, אבל אם כל השרתים מקבלים שרותי Storage מאותה קופסא ענקית והיא מושבתת – אף VM לא יעלה.

הותיקים מבינינו יקבלו אולי תחושת Deja-Vu קלה – ככה בדיוק מכרו ל-Corporate שרתים של Sun וחברות גדולות אחרות לפני 20 שנה. מפלצת גדולה, חייבת להיות יציבה ואם היא מפסיקה לתת שרותים – הצרות יגיעו (כולל כמה מאות טלפונים  ו-SMS בהולים).

כיום – שרתי ה-Solaris הגדולים של SUN נזרקו מרוב החברות ואותם שרתים הוחלפו במכונות Linux שמאוחר יותר עברו P2V להיות VM, וכיום יש לנו מספיק פתרונות טכנולוגיים לתת שרידות ל-VM כדי שגם אם יפול מתג, או Storage או שרת פיזי – ה-VM ימשיך לעבוד. אחרי הכל, להכין FT או HA ב-ESXI זה לא בדיוק מסובך כמו להטיס חלליות…

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

האם אתם יודעים על איזה שרת אתם רצים? (מבחינת Brand), האם אתם יודעים איזה דיסקים יש בפנים? האם יש דיסקים בשרת הפיזי או שזה מחובר לארון שמריץ שרותים שנותן שרותי דיסק ב-LAN עם דברים כמו LUN/iSCSI? התשובה לכל השאלות האלו היא פשוטה והיא: לא, אתם לא יודעים. אם תתהו מה יש מאחורי הקלעים, אמזון יאמרו לכם שהם עושים כל מיני דברים סודיים שלא אמורים לשנות לכם כלום – מבחינתם, הם צריכים לתת לך VM עם תכונות X,Y,Z שרצית וזהו. לא אמזון, לא גוגל ולא מיקרוסופט – אף אחד מהם לא מפרט לעומק מה ה"נוסחה" שהם בונים את התשתית שנותנת את ה-VM שאנחנו מקבלים בסוף. יש לנו רמזים על חלקים מסויימים (אמזון משתמשת ב-Xen, גוגל ב-KVM ומיקרוסופט ב-Hyper-V), אבל לא על הדיסקים, לא על הרשת, ולא על רפליקציות וכו'.

אם נסתכל על הפופולריות של ספקי ענן והשימוש ע"י ה-Corporate נמצא שחברות רבות מוכנות להשתמש בשמחה בנוסחה הזו וכל עוד ספק הענן מקיים את מה שהוא מבטיח – שני הצדדים מרוצים. (פה בישראל אתם יכולים להסתכל לדוגמא את ההגירה ההמונית משרתי Exchange מקומיים לשרתים של מיקרוסופט שיושבים אי שם..)

נחזור ל-Data Center שיש ב-Corporate ונדמיין לעצמנו שאנחנו לוקחים מברג ומחליטים לפתוח את אותו פתרון Storage קנייני גדול (טיפ: לא לנסות בחברה, מתכון בטוח לפיטורים מהירים) ולראות מהו אותו "קסם" שהם עושים בפנים. מבלי להיכנס ליותר מדי פרטים טכניים, אנחנו נמצא שישנה מערכת הפעלה קניינית של היצרן, מעבדים, זכרונות ועוד כמה חלקים, כך שה-Storage עצמו בנוי בצורה שלא ממש רחוקה משרת ממוצע שיש לנו (כמובן שאין שם מעבדי X86). אם נסתכל ונכיר קצת יותר את ה-Storage Processor ונשווה אותו למעבדים גנריים אחרים, אולי נופתע מכך שהמעבד עצמו הוא חלש בהשוואה לאחרים. כמה חלש? מעבד Xeon ישן מאוד שיש לך בשרת ישן – הרבה יותר חזק מה-SP עצמו ומסוגל לעשות את אותם פעולות מבלי להתאמץ ממש (כן, גם אם ניתן לו לעשות את החישובים של דחיסה, RAID וכו' במקביל).

זו בדיוק הנקודה שספקי הענן הפופולריים הבינו מזמן. אתה ממש לא צריך את הפתרון הקנייני המפלצתי כדי לבנות משהו שיתן שרותי בלוק/קבצים בצורה מהירה מאוד ובדרך גם לנהל מאות דיסקים, וכן – אתה יכול גם לקנות דיסקים איטיים (ואפילו SATA – וכן, אמזון קונים SATA בערימות) וגם SSD מהירים מאוד ובעזרת הפתרון שהם בונים, הם משלבים את הדיסקים כך שאחד לא "יחנוק" את השני. כך לדוגמא אם אתה עושה רפליקציה כל כמה שעות בין 2 ארונות, אפשר להכניס בארון שמקבל את הרפליקציה מספר דיסקים SSD גדולים שמשמשים רק כ-Cache ל-Write ולאחר שהם מקבלים את ה-DATA יש תהליך איטי של כתיבה מה-SSD לדיסקים SATA (לא יכול לאמר מי ספק הענן שעושה זאת, אבל אחד מהם בהחלט עושה זאת כך).

כאן מגיע דבר שנקרא במקומות רבים SDS ר"ת של Software Defined Storage. ב-SDS אתה הוא מי שבעצם מתכנן ובונה את ה-Storage ואתה יכול להקים עליו איזו תוכנה שתרצה כדי לנהל את ה-Storage וכאן יש לך מגוון של תוכנות, החל מקוד פתוח ועד פתרונות סמי-קוד-פתוח כמו של EMC ScaleIO  ופתרונות קוד סגור אחרים. גם מבחינת גדילה אתה יכול להתחיל במסלול של Scale UP ולחבר JBOD או יותר ועד למצב של Scale Out עם 3 שרתים ומעלה (ומומלץ רשת של 10 ג'יגה בין אותם שרתי Storage). אפשרות נוספת שיש לך היא בעצם להשתמש במשהו שכבר קיים אצלך, כך לדוגמא אם כל השרתים הפיזיים שלך מריצים ESXI, אתה יכול להשתמש ב-VSAN ולהכניס דיסקים מגנטיים ו-SSD לכל אחד מהשרתים ולבנות בעצם Storage מתוך אותם משאבים (בין כה VSAN לעולם לא עובר את קו ה-10% שימוש במשאבי מעבד/זכרון כך שהוא לא יחנוק לך את השרתים).

היתרונות שיש לפתרונות כאלו ברורים: מחיר מופחת, החברה יכולה לגדול לפי צורך (ולא לפי תכנון שלעיתים רבות יוצא שגוי כבר בחודשים הראשונים לאחר התכנון), אפשר לקנות ציוד מיצרנים שונים, אפשר להשתמש בטכנולוגיה הכי חדשה, ובמקרים רבים – אפשר לעבור בין תוכנת SDS אחת לשניה.

האם ב-Corporate יעברו לפתרון כזה? כשחשבתי על כך בעבר, תשובתי היתה "לא", אולם כיום כשחברות מוצאות את עצמן צריכות לשלם על הארכת חוזה תמיכה סכומים רציניים מאוד, ומאות אחוזים נוספים על דיסקים, נראה לי שחברות יהיו מוכנות יותר לשמוע על הרעיון. לא לעבור אליו מחר, אבל עצם הרעיון נשמע להם "מעניין". אני מאמין שבמהלך ה-5 השנים הקרובות נראה יותר ויותר חברות עוברות ל-SBS. אם מסתכלים על הדוחות הפיננסיים של חברות יצרני Storage כבר כיום רואים חברות כמו EMC שלא מראות ממש צמיחה והם מתכננים קיצוץ כ"א, וכנ"ל ב-NetApp כך שנראה שחברות פחות ופחות רוצות לקנות את הקופסאות הענקיות הללו.

כמה נקודות חשובות לגבי תכנון הטמעת VMWare VSAN 6

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

אחלק זאת למספר חלקים:

דיסקים
בגירסה 6 של VSAN ישנה תמיכה של All Flash, כלומר גם הדיסקים שאמורים לשמש כתכולה (Capacity) וגם הדיסקים שמשמשים לביצועים (Performance) יכולים להיות SSD. זה מעולה, אבל המחיר של דיסקים SSD מבוססי SAS (שלא לדבר על NVME) מאוד יקרים, ולכן VMWare ממליצה שתבחרו בסקאלה בין דיסקים שיכולים להכיל טרהבייטים של מידע אך אינם מהירים לבין דיסקים מגנטיים מהירים אך שאינם יכולים להכיל הרבה מידע.

האמת היא שהדיסקים המהירות במהירות 15000 RPM לא יסייעו לכם הרבה מכמה סיבות:

  • כל דיסק SSD הכי פשוט (כל עוד הוא מבוסס SAS) יתן לכם IOPS הרבה יותר גבוה מדיסק של 15000 RPM.
  • הכתיבה לדיסקים האלו בין כה נעשית ברקע וגם דיסקים NL-SAS במהירות 7200 RPM יתנו תוצאות שנמוכות באחוזים בודדים מדיסקים במהירות 15000 RPM
  • בדיסק מבוסס NL-SAS תוכל להכניס הרבה יותר מידע, חשוב לזכור – מידע של VM נשמר במספר שרתים במקביל כך שבכל מקרה לא תקבל 4 טרהבייט אם הכנסת 4 דיסקים של 1 טרהבייט (לדוגמא)

נקודה נוספת שמאוד חשובה בתכנון – VSAN אינו תומך בשום RAID וגם כמות הדיסקים שהוא תומך כקבוצות (קבוצה = דיסק SSD + לפחות דיסק מגנטי אחד) היא קטנה, עד 7 דיסקים מגנטיים בקבוצה, כך שאינך יכול לבוא ולחבר JBOD עם 20-60 דיסקים לדוגמא. תצטרך לכל קבוצת דיסקים להוסיף דיסק SSD (בחברות – SAS או NVME או PCIe, ב-LAB גם SATA יספיק), כך שאם לדוגמא אתה מתכנן להכניס 24 דיסקים של 1.2 טרהבייט מבוססים SAS, תצטרך לפחות 4 דיסקים SSD. נקודה חשובה נוספת – גודל ה-SSD המומלץ הוא לפחות 10% מגודל הדיסקים בקבוצה (כלומר אם הקבוצה מכילה 4 דיסקים של 1 טרה, תצטרך SSD בגודל של לפחות 400GB).

עוד נקודה ש-VMWare מאוד ממליצה עליה היא חלוקה קטנה של דיסקים, כלומר אם יש לך 4 דיסקים, חלק אותם ל-2 קבוצות כאשר לכל קבוצה יהיו 2 דיסקים ודיסק SSD. עוד המלצה של VMWare (שבחלק מהמקרים היא פרקטית ובחלק לא, תלוי בגודל השרת) – היא שכל קבוצת דיסקים יהיה בקר דיסקים יעודי (אגב, אם אתם קונים שרתים מוכנים ל-VSAN, מה שנקרא Node Ready, ברוב המקרים לא תמצאו 2 בקרי דיסקים אלא רק אחד). כמובן שקבוצות קטנות נותנות יותר ביצועים – אבל הכל תלוי בתקציב שלך.

רשת ב-VSAN
כשזה מגיע לרשת, לא מומלץ לעבוד במהירות של 1 ג'יגהביט (ו-LAG בין כה לא יעזור הרבה, מנסיון..) ומומלץ לעבוד עם חיבורי 10 ג'יגהביט בזוגות, כאשר ההמלצה האישית שלי היא להשתמש בסה"כ ב-6 פורטים לפי הפירוט הבא:

  • זוג 10 ג'יגהביט לתעבורת VSAN – אין מה לעשות, VSAN מעביר המון מידע נון סטופ (ואגב, לידיעת מנהלי הסוויצ'ים, הוא משתמש ב-Multicast כדי "להכריז" על שרתים) בין השרתים. את הזוג מומלץ להגדיר כ-Fail Over.
  • זוג 10 ג'יגהביט לתעבורת VM – חובה אם אתם חושבים להשתמש ב-SAN בשילוב Horizon לשם VDI. גם כאן – Fail Over.
  • זוג 1 ג'יגהביט – ל-Management. גם כאן – תצורת Fail Over.

שימוש ב-vCenter
לא מומלץ להקים את תשתית ה-vCenter על תשתית ה-VSAN, מכיוון שאם השרתים יפלו (יותר מ-1) – לא יהיה לך vCenter, ולכן מומלץ להשתמש ב-vCenter שרץ על ESXI שלא קשורים למערך VSAN. לחוצים במקום ובמשאבים? תקימו ESXI קטן ועליו vCenter Appliance לינוקסי כ-VM, זה יספיק.

הוספת ESXI כ-Compute Only
אם אתם רוצים להוסיף שרתי ESXI שישמשו כ-Compute Only (ללא דיסקים בתוכם) זה בהחלט אפשרי, אבל לא מומלץ להקים VSAN Cluster עם 3 שרתים שכוללים דיסקים ועוד 4 שרתים שלא כי אז העומס יזרק על כל השלישיה הראשונה. מומלץ להוסיף קבוצות דיסקים קטנות לשרתים שאתם מייעדים ל-Compute Only אם כמות השרתים הנ"ל תהיה גדולה, כך שהעומס יתפזר.

שימוש מאסיבי ב-Storage Profiles
בעקרון VSAN מאפשר לכם להגדיר כל מיני פרופילי Storage עם מאפיינים שונים כמו כמות שכפולים (Replications), או FTT (ר"ת failures to tolerate – כמה ה-VM ישאר חי אם X שרתים פיזיים נופלים) ועוד, אבל כדאי לתכנן זאת בחוכמה, ככל שתגדילו את ה-FTT וכמות הרפליקציות, כך ישאר לכם פחות מקום בדיסקים וכל מערכת הדיסקים תעבוד הרבה יותר אגרסיבי. אז כן, אם הרמתם VM שמריץ DB פרודקשן של אורקל או של מיקרוסופט, כדאי להגדיר לו FTT של 2 (לדוגמא), אבל אם אתם מריצים VDI ויש לכם 20 VM של Windows 7, במקרה ושרת ימות וה-VM יפלו – לא יפול העולם.

צורך ב-DEDUP וכו'.
ישנן מספר חברות שמוכרות Appliance VM שנותנים שרותים כמו File Server, DeDup, דחיסה ועוד. לגבי File Server, אם אין לכם רשיון 2012 פנוי, תמיד אתם יכולים להרים לינוקס עם SAMBA, לחבר אותו ל-AD שלכם ולתת שרותים כאו. לגבי שאר הפונקציונאליות – חכו להכרזות בסוף חודש הבא 🙂

רכישת SSD מאוד יקרים
ישנם כרטיסי SSD PCIe מאוד יקרים שנותנים יותר מ-100K IOPS בכתיבה וקריאה. הם מעולים, אבל הם לא נתמכים רשמית ב-6 VSAN, כך שלא מומלץ לבצע השקעה כזו.

כרטיסי בקר
אם אתם מסבים שרת קיים לשימוש ב-VSAN, ודאו שיש לבקר Queue Depth כמה שיותר גבוה (256 זה לא רע בתור התחלה, כמה שיותר – יותר טוב). כרטיסים פשוטים כמו LSI 9211 ומעלה נותנים Queue Depth של 640 וכרטיסים יותר מעודכנים נותנים 1024. בדקו את הבקר אם הוא ב-HCL כאן.

לסיכום: זה מאוד מאכזב לבנות מערכת VSAN, להרים עליה כמה עשרות VM בתור התחלה ואז לראות שהיא בקושי "סוחבת". הסיבה לכך בד"כ היא תכנון לא נכון מבחינת דיסקים (או שימוש ברשת של 1 ג'יגה). הכל תלוי מה ה-VMs שהולכים לרוץ עליה. VM של דסקטופים מצריכים קבוצות קטנות של דיסקים עם SSD מהירים (מומלץ PCIe או NVME) מכיוון שמדובר בד"כ בהרבה יותר כתיבה מאשר קריאה, בשעה ש-VM של שרתים בד"כ מצריך הרבה יותר קריאה מאשר כתיבה, ולכן חשוב לתכנן מראש לפני שקונים ציוד. מתחילים בקטן (3 שרתים מינימום) ומשם גודלים.

איך לרכוש את המוצרים של VMWare בזול

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

המצב כיום ב-2015 שונה מהמצב ב-2005. יותר ויותר חברות גדולות מחפשות מומחה לוירטואליזציה שזו תהיה העבודה העיקרית שלו (אפשר לראות בנקל אם מדובר בחברות גדולות או קטנות – אם הם מחפשים מישהו עם ידע בוירטואליזציה, אבל בדרך שידע גם סטורג', Windows, Linux, והטסת חלליות..). כיום מנהלים רבים או שמשתמשים ברשיון שהם "השיגו" מעבודה או דרך חבר שלקח מהעבודה או שבדרך הידועה של הורדת טורנט ושימוש באיזה keygen/keymaker..

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

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

אבל מה עם המוצרים האחרים? נניח ואתה רוצה להשתמש ב-VSAN בבית שלך, או שאתה מעוניין להשתמש ב-VMWare Horizon, או להכיר מה זה לכל הרוחות ה-vRealize, למה משמש vCloud? טכנית אתה יכול לקבל 30-60 יום רשיון Evaluation, אבל אחרי זה המערכת לא תתן לך להיכנס (אלא אם תתקין אותה מחדש). חושבים שטורנטים יעזרו לכם כאן? כי סביר להניח שלא תמצאו שום keygen שיוצר לזה מפתחות.

ב-VMWare החליטו לתת לזה פתרון.

הפתרון נקרא VMUG Advantage. מדובר בעצם בקבוצות (User Groups) שמדברות ונפגשות בכל העולם ומשוחחות על מוצרי VMWare וב-VMWare מעוניינים לצ'פר את המצטרפים. לשם כך יש לשלם סכום של 200$ לשנה.

ומה נותן לך המנוי הזה? טוב ששאלת 🙂

המנוי הזה נותן לך דבר שנקרא EVALExperience ועם EVALExperience אתה מקבל רשיון ל-365 יום למגוון מוצרים:

vmug

(שימו לב – כל המוצרים הם הגרסאות האחרונות – כך שאין vSphere 5.5 וגם אם תורידו מאתר VMWare, המפתח לצערי לא ממש יעבוד)

בנוסף, המנוי מעניק לך מספר דברים מעניינים נוספים כמו:

  1. 20% הנחה על קורסים (Online או offline)
  2. 20% הנחה על עלות הבחינות
  3. 50% הנחה על VMWare Fusion או VMWare Workstation האחרון
  4. נוסע לכנס של VMWorld? יש לך $100 הנחה לכנס
  5. גישה בחינם לתכנים מ-VMWorld 2015 (ללא VMUG Advantage המחיר הוא $699)
  6. 35% הנחה על VMWare Lab Connect (בשביל לנסות א הארכיטקטורה שאתם מתכננים)
  7. וכמובן הזמנות לכנסים של VMWare בישראל (מתי שהם יקיימו אותם…)

שווה $200? לדעתי כן

כל זה כמובן מגיע עם הגבלות די פשוטות:

  1. אין להשתמש ברשיון למטרות פרודקשן. רוצה להקים LAB בבית? בכיף. למטרת טסטים? אהלן וסהלן. פרודקשן? VMWare אוסרים על כך.
  2. אתה לא זכאי לקבל תמיכה, לא טלפונית ולא דרך מערכת הטיקטים שלהם. יש לך בעיה? תעבור דרך הפורומים השונים.
  3. אין אפשרות לקבל גרסאות מוצרים קודמות או מפתחות למוצרים ישנים. (בעסה!)
  4. כמות ה-Hosts מוגבלת ל-3 שרתים (עד 2 מעבדים פר שרת).

ויש גם הנחה שמתאימה ל-Corporates: אם החברה שלכם מחליטה ככה ברגע שהיא חטפה מצב רוח של נתינה – לקנות מספר מנויים ל-VMUG, אז אפשר לקבל הנחות כמו 2 משתמשים – המחיר יורד ל-180$, 3 משתמשים זה יורד ל-170$, אז אולי כדאי לדבר עם הבוס…

רוצים להצטרף? אחלה. גשו לאתר כאן ותעברו תהליך של Join. אחרי זה כנסו ללינק כאן ותרכשו מנוי. אחרי שתרכשו, תצטרכו להמתין בין 24-48 שעות לקבלת אישור (אני המתנתי 24 שעות) ואז יגיעו לכם כמה מיילים נוספים כדי לרשום אתכם לחנות שמשרתת את ה-VMUG ומנפיקה מפתחות, וגם לרישום ל-MY VMWare כדי שתוכלו להנות מההנחות, השיעורים וכו'.

משהו אחד לסיום: לא, אני לא מקבל שקל מכל הפוסט הזה ומההפניה הזו, כך שאני לא מרוויח מזה כלום. תהנו 🙂