הבלוג של חץ ביז

מדינת ישראל מציגה: הגנת סייבר מפגרת

Emblem of the State of Israel אתמול פורסמה כתבה על הכוונה של ממשלת ישראל לנתק את שרותי הדואר של הממשלה מתקשורת עם שרתי מייל מחו"ל.

הסיבה? כי ב-7/4 תהיה "התקפת סייבר" של OpIsrael – קבוצות של ילדים שמריצים סקריפטים (סקריפט קידיז) שמחפשים כל מיני פרצות באתרים (כדי לעשות Defacement בחלק מהמקרים, וכדי להשחית DB בחלק נדיר מהמקרים) ובמיוחד – התקפות DDoS על אתרים שונים שרובם מסתיימים ב- co.il או gov.il

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

אפשר להעביר את כל הטראפיק של האתרים הממשלתיים דרך שרות CDN כלשהו שנותן הגנת DDoS – החל מ-Cloudflare, incapsula ואחרים. כך אזרחי ישראל היו יכולים להמשיך לגלוש לאתרים ולקבל שרות.
בעניין שרתי מייל וכל מיני מרעין בישין שישלחו לעובדי ממשלה ומשרדים ממשלתיים, ישנם מספר פתרונות שיכולים להיות או קופסאות או VM שיושבים "לפני" שרתי הדואר הארגוני וניתן בעזרת אותם פתרונות לבחור איזו רמת הקשחה רוצים. לדוגמא: כל Attachment ינותק מהאימיילים וישב בשרת נפרד עד שמערכת סריקה חזקה כלשהי תעבור על ההצמדה לבדוק אם יש חורים. אפשר ממש להגזים ו"לגרד" מהמייל כל סימון HTML ולהעביר את הטקסט עם HTML בסיסי של יוניקוד והטקסט בלבד.

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

אז אתמול בלילה הלכתי לקרוא את ה-RFC שמדבר על SMTP, אתם יכולים לראות אותו כאן. (זהירות, קובץ טקסט ארוך, ולמי שלא מביא בנושא ושונא לקרא RFC – חומר שיכול להרדים אותך תוך דקות…). מצאתי כי בעמוד 75 תחת סעיף 4.5.4.1 ישנה התייחסות למשלוח חוזר במקרה ששרת המייל היעודי אינו עונה.

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

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

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

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

Google App Engine – הדור הבא

google-app-engine בפוסט הקודם שלי כתבתי על פלטפורמת ה-Google Cloud וספציפית על Google App Engine (בקיצור: GAE) והיתרונות הגדולים שלו לבעלי אתרים שהולכים וגדלים.

העניין הוא שמאז ש-GAE יצא לעולם מ-Beta ב-2011, קמו מתחרים רבים לו. לאמזון יש את BeanStalk, ל-רד-האט יש את OpenShift ויש עוד המון חברות שמציעות משהו דומה שנקרא PaaS (ר"ת Platform As a Service) עם אותו עקרון: כתוב את האפליקציה שלך עם הפלטפורמה שלנו, ואנחנו נארח אותה ונדאג לכל עניין הגדילה, אבטחה, משאבים וכו'.

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

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

עד היום הפתרון לדבר כזה היה לקחת שרת נוסף, שיעודי רק לכך. השרת הזה היה שונה לחלוטין מכל מה ש-PaaS נותן לי. זהו שרת שהייתי צריך להקים מ-אפס, להתקין עליו FFMPEG, לבנות תקשורת בינו לשרותי ה-PaaS, לתחזק אותו מבחינה אבטחה, עדכוני אבטחה ושאר דברים שהיו גוזלים את זמני. את השרת הייתי יכול לקחת משרות EC2 של אמזון או Cloud Compute של גוגל או אחרים. בקיצור – עכשיו עבודת התחזוקה של המערכת היתה יותר גדולה ואני גם אצטרך לשבור את הראש איך לעשות Scale אם הרבה גולשים ניצלו את היום שמש בחוץ וצילמו 500 קליפים וכולם מנסים להעלות אותם במקביל.

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

גוגל החליטו ליצור בתגובה משהו חדש: יש לנו מצד אחד את PaaS שמאפשר לגדול ולתת שרות מהיר ללקוחות, אבל הוא מוגבל מבחינת אפשרויות שימוש באפליקציות צד ג' או אפליקציות Native שכתובות בשפות כמו C או ++C. מצד שני יש לנו IaaS שזה בעצם ה-EC2 או Cloud Compute ואחרים שמאפשרים לנו להקים VM ולעשות את כל עבודת ההקמה/הגדרות/תחזוקה עליו ואנחנו צריכים לשבור את הראש כמעט על כל פיפס.

הפתרון של גוגל? מדוע שלא נשלב את שתי העולמות יחד? גוגל קוראים לזה: Managed VMs. (בשביל הפוסט אני אקרא לזה בקצרה MVMS)

מה ש-MVMS עושה הוא בעצם הרחבה ל-GAE. עד היום על מנת להקים סשן, היית צריך לבנות קובץ YAML. קובץ YAML אומר למערכת דברים די פשוטים: מהי השפה שבה האפליקציה שלך תרוץ, מה לעשות כשיש URL מסויים, סוגי קבצים שנכנסים ומי בעצם רץ כשמשתמש מגיע למקום מסוים או משתמש בסוג קובץ מסוים.

ב-MVMS ה-YAML הורחב. מעתה תוכל להגדיר ב-YAML שהסשן יהיה בעצם VM, תוכל לאמר אם אתה מעוניין שהגדילה תהיה ידנית או אוטומטית, תוכל להגדיר איזה סוג Image אתה רוצה ל-VM ומה שהכי חשוב: אתה יכול להוסיף בסוף ה-YAML שורות שאומרות למערכת אלו חבילות להתקין (ואת ההגדרות) בזמן שהיא מקימה עבורך את ה-VMs. ב-GAE יש לך 5 סוגי instances שעליהם רצה האפליקציה. ברגע שאתה מגדיר את הסשן כ-VM, האפשרויות שלך גודלות בהרבה לכל סוג VM שגוגל מציעה. צריך מכונה עם הרבה זכרון? הרבה ליבות? פשוט תציין את סוג המכונה ב-YAML.

ומה עם שאר הדברים כמו Load Balancing וכו'? מה עם SSH למכונה? אין צורך לדאוג, הכל אוטומטי. בזמן ההקמה הוא יחבר את המכונה ל-Load Balancer ותוכל להשתמש בשרות כמו memcache השיתופי (או אחד יעודי עבורך שעולה 6 סנט לשעה) ושאר שרותי GAE כאילו מדובר בסשן GAE רגיל.

היתרונות של שיטת MVMS ברורים:

אין צורך ברכישת מכונות רזרביות. בין אם אתה צריך מכונה אחת נוספת או 10,000, תוכל לבצע זאת מיידית.
לא צריך שרות נוסף של Load Balancing שעולה כסף.
אין צורך "לחמם" מכונות VM כדי שיהיו מוכנות להתחבר ל-Load Balancer.
אין צורך בלהקים שרתי Apache או nginx עם כל ההגדרות שישמשו Front End, אתה פשוט יכול להקים סשן GAE בשפה שאתה רוצה (PHP לדוגמא) ולהרים בו את אתר ה-Front End שלך.
לא צריך לשבור את הראש לגבי כתובות IP
אתה יכול להקים אצלך בעבודה את ה-IMAGE שלך עם הלינוקס שאתה אוהב, עם כל ההגדרות שאתה צריך ואתה יכול להעלות את ה-IMAGE ולהשתמש בו.
אתה יכול לבצע SSH ישירות לתוך כל מכונה מבלי להוסיף לה כתובת IP חיצונית ומבלי לזכור את כתובת ה-IP הזמנית שהמערכת מצמידה לה.
אתה תמיד יכול לשנות את ה-VM, לבצע Snapshot ואז להגדיר ב-YAML שכשהמערכת מקימה מכונה חדשה, היא תשתמש ב-IMAGE (שנוצר מה-snapshot).
אין יותר "ביצועים רנדומאליים". מכירים את זה שאתם מתחילים לעבוד על VM שרץ על ענן ופעם אותו VM רץ כמו שד ופעם אחרת זז כמו צב? פה אין את זה. גוגל מגדירים את השרתים לתת ביצועים באופן ליניארי, כך ש-VM אחד לא "חונק" VM שני.
כן – אפשר גם להשתמש במכונת Windows (כרגע 2008, עוד חודשיים בערך – גם 2012).

שימוש ב-MVMS נותן לך סוף סוף את החופש להשתמש באיזו אפליקציה שתרצה, עם הגדרות שתרצה, והמערכות של גוגל ידאגו לרוב הדברים. אתה לא צריך, בניגוד למצב שקיים כיום, להתחיל להגדיר את הכל מאפס, את שרתי ה-Web, את שרות ה-EMAIL, וכו'. אתה אפילו יכול לחבר בקלות מערכות ניהול תצורה כמו Puppet או CHEF בקלות לסשנים שלך, כך שבסוף היום העסק שלך יכול להתרכז יותר בפיתוח האתר/שרות מאשר לסבול מבעיות תחזוקה, הגדרות חוזרות, "רדיפה" אחרי שרת סורר וכו'.

שרות ה-Managed VMs עדיין לא זמין לציבור (אפשר להירשם בלינק לעיל) והוא יהיה זמין במהלך השבועות הקרובים.

(גילוי נאות: הח"מ נותן שרותי פרילאנס לשרותי הענן של גוגל).

על אתרים שגודלים ו-Google Cloud Platform

cloud-homepage-logo_short_900px

הנה סיטואציה שמוכרת לכל מי שיש לו אתר מצליח עם גולשים רבים, ושאותו אתר בנוי על פלטפורמה פתוחה וידועה כמו וורדפרס או ג'ומלה…

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

ככל שהאתר יותר פופולרי, האופטימיזציות שבעל האתר (או מי שהוא שוכר שיעשה עבורו את העבודה הטכנית) יצטרך לעשות הן יותר עמוקות, כמו שימוש בתוספי Cache, אופטימיזציות לבסיס הנתונים, שימוש ב-Cache ב-DB והמתקדמים ישתמשו בפתרונות כמו memcache או Varnish (או שילוב שלהם).

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

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

גוגל בשבוע שעבר הכריזה על מגוון שרותים חדשים במסגרת ה-Cloud Platform שלה, ובאותה הזדמנות הם גם חתכו מחירים בכל השרותי ה-Cloud שהם מספקים, וזו הזדמנות מצויינת לבעלי אתרים פופולריים להסתכל על ה-Google App Engine (ובקצרה: GAE)

שרות GAE קיבל לפני יותר משנה "הרחבה" של שפה פופולרית: PHP, כך שאפשר לארח דרך GAE אפליקציות PHP וכאלו – יש הרבה, הרבה יותר מכל שפת תכנות אחרת. יש ב-PHP אפליקציות על כל דבר שנחשוב, החל מניהול אתרי תוכן, ניהול בסיסי נתונים, ניהול תצורות ועוד דברים רבים אחרים.

השימוש ב-GAE מצריך "החלפת דיסקט" אצל בעל האתר. עד היום, כפי שתיארתי לעיל, כשהאתר היה יותר פופולרי, היה צריך לעבור לפלפטפורמה של שרת וירטואלי שאותו מגדילים כמה שצריך עד למצב שצריך מספר שרתים, Load Balancing ועוד.

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

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

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

עכשיו נגיע לחלק של עלויות.

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

אז כמה עולה התענוג? העלות מורכבת מכמה חלקים שנצטרך כדי להשתמש ב-GAE ומומלץ להשתמש בדף הזה כדי לחשב עלויות (לא לשכוח בכל סעיף שאני מזכיר להכניס מספר וללחוץ על Add to Estimate – התוצאה תהיה מימין למעלה):

אנחנו צריכים קודם כל מקום לאחסן את האתר, זה נקרא Google Cloud Storage והמחיר שם מצחיק – 100 ג'יגהבייט יעלו לכם 2.60$ לחודש.
אנחנו צריכים לחשב רוחב תעבורה החוצה (תעבורה פנימה היא בחינם). כאן מומלץ לכם להיכנס לאתר שמודד לכם את הטראפיק כדי לראות כמה ג'יגהבייט השתמשתם בממוצע בחודשים האחרונים. אם לדוגמא יש לכם 100 ג'יגהבייט של תעבורה החוצה, העלות תהיה 12$ לחודש. שימו לב: המחיר הזה כולל שרות CDN, כך שאם אתם משלמים כיום לספק CDN, תוכלו לחסוך את ההוצאה הזו.
אנחנו צריכים בסיס נתונים. מה גודל ה-DB שלכם וכמה השרת שלכם "מבלה" בעיבוד ה-DB? גוגל מציעים את Cloud SQL שהוא תואם MySQL. אתם יכולים לבקש מהאיש הטכני שלכם לאמר לכם מה גודל ה-DB או שאתם אתם יודעים להשתמש ב-MySQL שימוש פשוט, בצעו mysqldump ל-DB וראו מה גודל הקובץ. בדף החישוב, תבחרו Part Time. מבחינת גודל Instance תבחרו במשהו קטן (תיכף אסביר מדוע) והכניסו את גודל ה-DB שלכם (סביר להניח שהוא לא יותר מכמהה ג'יגה בודדים אם בכלל הוא מגיע לג'יגה. באתרי תוכן רוב הדברים הגדולים הם קבצי המדיה).
מה עם שרותי Cache? שרות memcache הוא בחינם. לא עולה לכם כלום 🙂
מה עם שרת מייל? אין צורך. ל-GAE יש משלו, כך שהוורדפרס יוציא מיילים בלי שום בעיה.
מה עם שרת WEB? יש ל-GAE שרת משל עצמו ואתם לא צריכים להגדיר אותו, כך שאין צורך בשרת Web משלכם.
מה עם תוספים לאפליקציות CMS שלכם? את זה אתם מתקינים כמו שאתם מתקינים כרגיל בתוך האפליקציה. אין שינוי.
שרותים כמו Compute Engine ו-Persistent Disk במקרה שלנו – אין לנו צורך בהם.
מה עם Load Balancing ושאר ירקות לאתרים גדולים? זה מבוצע אוטומטית ע"י ה-GAE ללא תשלום נוסף.

ויש עוד עלות נוספת – עלות ה-Instance. בכל זאת, האפליקציה צריכה לרוץ על משהו. כפי שאתם יכולים לראות כאן, ישנם 4 סוגי instance עם מחירים בין 5 סנט לשעה ל-30 סנט לשעה. עכשיו, לפני שאתם שולפים מחשבי כיס ונבהלים, צריך לזכור כי כבר יש memcache משותף לשרתים (instances) והוא לא נכלל ב-RAM של ה-instance, כך שאתם בעצם צריכים פחות זכרון ממצב רגיל שהייתם משתמשים ב-VM/VPS ובעברית פשוטה: נסו את F1 או F2 ותראו איך האפליקציה שלכם עובדת (וקראו את המסמך בלינק!) לפני שתבחרו את F4.

על מנת שלא תצא לנו חשבונית עם 4 או 5 ספרות ודולרים (והתקף לב בדרך), מומלץ שכשאנו מקימים את האפליקציה ב-GAE, שנשתמש ב-memcache. כך לדוגמא אנחנו נחסוך בפניות רבות ל-SQL ופניות אליו יתבצעו רק אם יש צורך בעדכון (אם מישהו הגיב, או אם אתם מעלים תוכן חדש שיכנס ל-DB).

הגענו לחלק המעניין – של ההתקנה.

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

רוצים להתקין וורדפרס או ג'ומלה? בכיף. כאן ההוראות איך להתקין וורדפרס, וכאן ההוראות איך להתקין Joomla. שימו לב: תצטרכו להתקין שרת MySQL אצלכם במכונה (בכלל הייתי ממליץ לבצע את ההוראות התקנה על מכונת VM אצלכם בבית), ורק לאחר שתריצו את פקודת ה-update והנתונים יעברו ל-GAE ול-Cloud SQL תוכלו להיפטר מהסביבה (אם כי יכול להיות שתרצו לעשות הכל מקומית ואחרי זה לעשות deploy ל-GAE – הכל תלוי בכם).

עוד משהו אחד: יש לכם ערימות של דומיינים? גוגל מציגה שרות חדש שנקרא Google Cloud DNS שנותן לכם להשתמש בתשתית DNS של גודל לנהל את כל הדומיינים שלכם בחינם. לא צריך יותר שרתים שלכם לכך, ולא צריך לדאוג אם שרת זה או אחר נפל או ששוב מישהו אצל רשם הדומיינים דפק רקורד (סבלתי מספיק מהדברים האלו, תודה לכם נטויז'ן!). עוד פרטים – כאן.

בהצלחה

(גילוי נאות: הח"מ נותן שרותי פרילאנס להעברת אתרים ל-GAE ול-Google Cloud).

טיפ בנושא: שדרוג מכונות RHEL

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

כשיש לכם שרת אחד או 2, או מספר קטן מאוד של תחנות RHEL, אז העדכון הוא עניין די פעוט (מבחינת udates, מבחינת upgrade עם אותם עדכונים זה משהו אחר), אבל מה עושים כשיש לך כמה עשרות ואולי מאות שרתים/תחנות עבודה? לתת לכל מכונה להוריד את העדכונים שלה זה נחמד אבל זה לוקח זמן, רוחב פס ודיסק בכל פעם. האם אי אפשר לסדר זאת בתצורה כזו שכל המכונות ישאבו משרת אחד?

לרד-האט יש פתרו שנקרא Red Hat Satellite המאפשר לא רק עדכונים אלא life-cycle שלם למכונות ושרתים שכולל שרותים כמו דיווחי באגים, תמיכה, קבלת תיקונים, בדיקות, יצירת ISO לצרכים שונים וכו'. הכלי הוא כלי גדול וגם עולה בהתאם (כמה אלפי דולרים מחיר התחלתי). אנחנו לעומת זאת צריכים רק את העדכונים, לאחסן אותם על שרת שלנו ואנחנו כבר נפיץ אותם בזמן שנקבע.

על מנת לבצע זאת, נצטרך קודם כל לברר אלו גרסאות RHEL אנחנו משתמשים בחברה. 5? 6? עבור כל אחת מהגרסאות העיקריות נצטרך VM עם המון דיסק פנוי (במינימום 40-50 ג'יגה) וכמובן רשיונות, רשיון פר גירסה Major כך שאם אנחנו משתמשים בחברה ב-RHEL-6 וגם RHEL-5 ולשתיהם אנחנו צריכים עדכונים, אנחנו צריכים 2 רשיונות (כמובן שצריך רשיונות לכל תחנת/שרת RHEL כדי לקבל תמיכה וכו') על מנת לבצע את הקמת ה-REPO החדש שלנו.

ראשית, יש להקים VM עם גירסת RHEL הרצויה. ההתקנה מספיק שתהיה בסיסית עם גישת רשת החוצה ב-HTTP. ויש לבצע register של אותה מכונה ל-RHN. לאחר ההתקנה יש ליצור תיקיה שאליה נאחסן את הקבצים. נקרא לה var/repo/

כעת יש לוודא שחבילת yum-utils וחבילת createrepo מותקנות. אם לא, אפשר להתקין אותם ישירות מה-ISO או בעזרת yum.

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

rhn-channel -l

אם הכל תקין, נקבל תשובה: rhel-x86_64-server-6 (במקרה שההתקנה היא 64 ביט גירסה 6).

כעת נתחיל לשאוב את העדכונים:

cd /var/repo
reposync -l --repoid=rhel-x86_64-server-6

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

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

createrepo -v --update rhel-x86_64-server-6/getPackage/

זהו. יש לנו repo עם כל ה-RPMS שיש ב-RHEL-6 כולל דברים ישנים וחדשים.

על מנת לאפשר גישה לקבצים שהורדנו, נקים שרות httpd. התקינו את חבילת httpd ובתוך etc/httpd/conf.d/ נקים קובץ בשם repo.conf שיאפשר גישה לקבצים. הנה דוגמא לקובץ:

<VirtualHost *:80>
ServerName rhelrepo
DocumentRoot /var/repo/rhel-x86_64-server-6
ErrorLog logs/repo-error_log
CustomLog logs/repo-access_log common
<Directory "/var/repo/rhel-x86_64-server-6/">
Options Indexes FollowSymLinks
</Directory>
</VirtualHost>

שימו לב לשנות את שם ה-ServerName לשם השרת שלכם.

כעת נפעיל את שרות ה-httpd (עם הפקודה: service httpd restart) ועם הדפדפן ניגש לכתובת: http://rhelrepo/getPackage (שוב, שנו את השם rhelrepo לשם השרת שלכם). אם הכל תקין, תקבלו רשימה ארוכה של קבצי ה-RPM.

עכשיו מגיע החלק שתפיצו בעזרת כל כלי שתרצו – אל כל השרתים שלכם, קובץ repo שב בתיקיה etc/yum.repos.d/ שם ניצור קובץ שנקרא לו rhel6.repo

[RHEL-6-UPDATES]
name=RHEL-6.x Updates
baseurl=http://rhelrepo/getPackage/
enabled=1
gpgcheck=0

מומלץ למחוק את שאר הקבצים שנמצאים באותה תיקיה (ושמורידים את אותם עדכונים מרחוק).

כעת הגיע המבחן הגדול: הריצו yum update ותראו אם המערכת מוצאת עדכונים ומורידה אותם. אם כן, אז ברכותיי – הרמתם לכם שרת REPO מקומי משלכם.

מה שנשאר לעשות הוא להשתמש בפקודות ה-reposync וה-createrepo בתוך סקריפט שירוץ אחת ליום דרך ה-crontab ויעדכן את החבילות ישירות מרד-האט. את זמן ההפצה לכל השרתים והתחנות אתם קובעים לפי הנהלים באותה חברה.

אם אתם צריכים עדכונים ל-RHEL-5, ההבדל היחיד הוא בשם הערוץ, אותו תוכלו לקבל עם פקודת rhn-channel -l

בהצלחה

טיפ: להפוך מערכת CentOS ל-RHEL

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

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

לשם ההפיכה, נצטרך קודם כל את ה-ISO פרוס לקבצים בתיקיה כלשהי (אפשר כמובן על NFS, רק כדאי שתבצעו קודם כל mount במכונה שאנחנו הולכים לשנות). לאחר שביצענו mount נעבור למצב root (זה המצב שבו נישאר כרגע) עם sudo או – su.

עתה יש להריץ את הפקודה הבאה:

rpm -e --nodeps centos-release

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

עתה, נרים לנו REPO משלנו עם הנקודה שאליה ביצענו mount. כנסו לתיקיית etc/yum.repos.d/ ושם ניצור קובץ dvd.repo – הנה דוגמא משלי:

[DVD]
name=DVD REPO
baseurl=///mnt/Server/
enabled=1
gpgcheck=0

במקרה הנ"ל, ה-mount שביצעתי היה לתוך תיקיית mnt/ כמו כן יש לשים לב שכמות הקו נטוי (/) היא בתוספת / כך שאם מדובר במערכת קבצים מקומית (ולא http) יש צורך שיהיו 3 קווים נטויים.

כעת יש להעיף את קבצי ה-repo האחרים של CentOS (הם מתחילים במילה CentOS)

עכשיו ננסה להשתמש ב-repo החדש שהוספנו. הריצו את הפקודה הבאה:

yum install redhat-release

סביר להניח שההתקנה תבקש לעדכן את initscripts. אשרו את ההתקנה.

כעת יש צורך להריץ yum update על מנת לעדכן חבילות שונות. הכל יבוצע אוטומטית.

אם אתם מעוניינים לרשום את המכונה בשרתים של רד-האט, יש להריץ את הפקודה הבאה:

yum install rhnlib rhnsd rhn-client-tools rhn-check yum-rhn-plugin rhn-setup

שימו לב לא להכניס מספרי גרסאות, המערכת תתקין את הגרסאות האחרונות מהיכן שהיא מוצאת ב-REPO.

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

זהו, כעת כל מה שנותר לבצע הוא reboot וכעת יש לכם שרת RHEL כאילו התקנתם אותו מאפס מה-ISO. תוכלו לבדוק זאת ע"י הקשת פקודת: lsb_release -d

גוגל נכנסת חזק לתחום הענן הציבורי

עד לאחרונה, בכל הקשור למחשוב ענן שפתוח לציבור, האפשרויות הכי ידועות היו אמזון (כמובן) ומיקרוסופט עם Azure, כאשר אמזון מובילה בביטחה בכמות המשתמשים, הפתרונות, הפלטפורמות וכמובן – ערימת השרותים שהיא מציעה הכוללת שורה ארוכה של שרותים שאף ספק מתחרה לא נותן תחת קורת גג אחת. מכיון שאמזון מציעה את כל אותם שרותים במחירים תחרותיים מאוד, הרבה מאוד סטארט-אפים וגם חברות גדולות וידועות (טוויטר?) משתמשים בתשתיות של אמזון ולאמזון יש תשתיות בשפע ופתרון כמעט לכל דבר שתרצה, החל מענייני ניתוב DNS, אם זה CDN, הרמה של כמות מכונות גדולה בזמן קצר כדי להתמודד עם עומסים, מאזן עומסים (Load Balancer), ועוד – וכל זאת במחירים נמוכים (יחסית, כמובן. אם אתה צריך רק שרת אחד שעליו אתה עושה הכל בלי שום שרותים נוספים ובלי שרידות, אמזון לא מתאימה לך).

לתחום הענן הציבורי נכנסה בשנתיים האחרונות (באיחור אופנתי, כרגיל) מיקרוסופט עם ה-Azure שלה. בהתחלה כמערכת שאתה מפתח עליה אפליקציות במגוון שפות, ולאחר מכן שרותי Azure גדלו ל-IAAS/PAAS. במיקרוסופט, שהכח העיקרי שלה מגיע מהשוק העסקי, עשו דברים קצת שונים מאמזון והחלו את המתקפה על השוק העסקי עם Office 365 כשהם משכנעים ארגונים רבים לאחסן את המייל/יומן/מסמכים בענן, ורק לאחרונה נודע כי מיקרוסופט הולכת להציע שרותים אלו גם גירסה אישית במחיר של 7$ לחודש (או 90$ לשנה) שאותה אפשר להריץ על Windows או MAC או בגרסאות הטאבלט/מובייל שמיקרוסופט הוציאה ותוציא. במקביל מיקרוסופט מנסה לדחוף בצורה אגרסיבית את שרותי ה-IAAS כתחליף לאמזון ולשם כך היא משתמשת ב"צבא" אנשי המכירות שיש להם עם דילים שונים בהתאם לגודל הארגון. עד כה המאמצים להעביר חברות מאמזון ל-Azure לא ממש מנחילים הצלחה רבה למיקרוסופט, אבל תסמכו על מיקרוסופט שיעשו הכל כדי שחברות סטארט-אפ או כל חברה שמציעה שרותי Web ישתמשו ב-Azure. מיקרוסופט אפילו נותנת תמיכה (לא מי יודע מה, למען האמת) בגרסאות לינוקס CentOS/RHEL (מנסיון אישי שלי: אם נתקלת בבאגים, תתחיל לחפש פתרונות בגוגל, התמיכה של מיקרוסופט כולל תמיכה בחו"ל פשוט לא יודעים לתמוך בלינוקס, במיוחד אם אתה מרים הגדרות רשת מורכבות.)

לשטח הזה נכנסים גוגל (ליתר דיוק נכנסו). עד כה גוגל הציעו את ה-App Engine, שרות PAAS שמאפשר לך לפתח אפליקציה שתרוץ בענן של גוגל, אולם בשנה האחרונה גוגל התחילה להציע שרותי IAAS כאשר ההצעות שהם מציעים נשמעים מעולים לאנשי לינוקס שמכירים לינוקס טוב, אבל לך תסביר את הדברים למנהל מעליך, במיוחד שכמות מערכות ההפעלה שנתמכות היתה די קטנה וממש מיועדת לגיקים (Debian 6,7, CentOS 6.2), או שתסביר לו כמה זה מעולה שאתה יכול להרים מערכות Diskless, את זה שאתה יכול להרים 1200 מערכות מאפס תוך פחות מדקה, ושלל דברים מגניבים ששוב – מדברים לגיקים שבינינו אבל קשה לשכנע את ההנהלות לקחת את ה-IAAS ולהשתמש בו כמשאב עיקרי לחברה, כך שהמצב היה שגוגל התחילה להציע דברים, אבל מבחינת שוק – לא הרבה נכנסו אליו. אבל דברים מתחילים להשתנות אצל גוגל ועכשיו הם מתחילים לצאת לאור, ועבדכם הנאמן יגלה כאן כמה דברים שאותם תשמעו רשמית עוד שבועיים: גוגל אתמול הוציאה הודעה שעשתה כאב ראש רציני למתחרים: חיתוך מחירים סופר אגרסיבי באחסון און ליין, ספציפית ב-Google Drive. מעתה, 100 ג'יגהבייט יעלו לך בחודש רק $1.99. רוצה טרהבייט של מקום? בכיף, המחיר צונח מ-50 דולר ל-$9.99 לחודש. רוצה לאחסן את כל ספריית המוסיקה/קליפים/תמונות שלך וצריך 10 טרה? זה יעלה לך $99.99 לחודש, כלומר המחיר צנח בעשרות אחוזים כלפי מטה. זה נחמד, אבל מה עם האחסון ב-IAAS? (מה שתואם ל-S3 של אמזון) – ובכן, גם הוא בעוד שבועיים יקבל הנחתת מחיר אגרסיבית.

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

צריך גרסאות Windows? כן, גם בגוגל שמעו שעסקים מעוניינים ב-Windows Server והם שכרו צוותים שלמים לתמיכה והקמת מערכות כך שתוכל להקים לך Windows Server 2012 כ-VM כולל כל השרותים והתמיכה שתצטרך.
ה-App engine יעבור שדרוג מאסיבי ומעתה תוכל להרים עליו שרותים כמו Joomla ועוד – כך שכל מה שתצטרך זה להקים Engine, לזרוק עליו Joomla עם העיצובים והתוספים שלך. לגבי כל עניין ה-Scaling לא תצטרך לדאוג כי המערכת של גוגל תדאג לזה (אה, ולא תצטרך לשבור את הראש על ההגדרות של Web Server או MySQL וכו' – הכל יהיה יותר קל)
אפליקציות נוספות יתמכו ללא שינוי קוד דרך ה-App Engine
הרצת כל גירסת Linux וכל Kernel שתרצה. (כן, כולל תמיכה ב-SELinux וגם הפצות מבוססות Rolling Release).
תמיכה מלאה ב-Docker (כך שתוכל להקים כמה קונטיינרים עם מערכות לינוקס אחרות על VM יחיד)
הבטחה להגנה נגד DDoS
ואת שאר הדברים תשמעו עוד שבועיים (אני לא מעוניין למתוח את החבל יותר מדי עם גוגל..)

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

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

ולבסוף: אינטגרטורים שעוברים ל-Cloud Platform של גוגל: נא לעדכן מיידית את ה-gcutil. (כן, אני חובב את הפלטפורמה של גוגל, אבל אני גם יודע לפרסם פאקים שלהם).

הטריקים של אורקל עם OVS

מאז שאורקל רכשה את SUN, מנסה החברה למכור את השרתים שלה בכל דרך, ומכיוון שחברות מעוניינות מאוד בוירטואליזציה, אורקל מוכרים בחבילה פתרון וירטואלי, שנקרא Oracle VM Server או בקיצור OVS. היתרון לרוכש הוא בתמחור האגרסיבי של אורקל: קח פתרון ברזל, וירטואליזציה עולה לך אפס ורשיונות אורקל תקבל בהנחה – אם הם ירוצו על פתרון הוירטואליזציה שלהם.

נשמע משתלם, לא?

לא בדיוק.

הבה נציץ מאחורי הקלעים: פתרון הוירטואליזציה שאורקל נותנים עם המערכת הוא פתרון שהיה נקרא בעבר Virtual Iron שהיה מבוסס על Xen. מאז שאורקל רכשו את החברה, הפיתוח הואט כנראה וכיום הוא אפילו לא משתווה למתחרה הישיר שלו – XenServer של Citrix. מה שאורקל שינו מאז במערכת הם שינויים קטנים ועדכונים (כך לדוגמא, אם אתה חושב להצמיד כרטיס PCI למכונה וירטואלית, תתכונן לכשלון, זה פועל בקושי. חושב על פתרון כמו Shared Memory בין מערכות וירטואליות שמריצות את אותה מערכת הפעלה? יש, אבל שלא תחשוב שזה כמו ESXI) אבל הם מתנדפים בהשוואה למערכות וירטואליות כמו ESXI או אפילו Hyper-V. אם אתם לא מכירים לינוקס טוב, תתכוננו להרבה תסכול, כי זה מה שה-GUI (ה-VM Manager) נותן: תצוגה מוזרה של דברים, נעילות של מכונות אם JOB נופל (לך חפש את ה-JOB ומהיכן לשחרר נעילה), ותשכח ממצב לראות סטטוס כללי של כל המכונות הוירטואליות שלך אם הם רצים, כמה זכרון הם משתמשים וכו'. רוצים סקירה קצת יותר עמוקה על המוצר? קחו, קראו בעצמכם.

לא מדובר פה באיזו "אשמה" של המערכת הוירטואלית עצמה (XEN) כלל וכלל! אם תיקחו לדוגמא את XenServer של Citrix, יש למוצר דווקא ממשק בכלל לא רע כי ל-Citrix יש הרבה יותר נסיון עם ממשקים, Windows וכו'. גם מבחינת תמחור קשה להתחרות במוצר של Citrix. אפשר להוריד אותו בחינם (קוד פתוח) ואפשר לקבל שרותי תמיכה בתשלום שנתי של $199 פר תושבת מעבד.

פה בישראל, הבעיה חמורה בהרבה. הבעיה עצמה מתחילה בתמיכה, והח"מ, כאחד שעבד עם התמיכה של אורקל למוצר, אני יכול לתאר את אותה תמיכה כמתחת לכל ביקורת. תומכים שלא יודעים על מה הם סחים, אינטגרטורים של אורקל עצמה שמגיעים ולא יודעים מה הם מתקינים (או שמתקינים ושוכחים להתקין קבצי RPM שונים) או שלא יודעים להתקין דברים בצורה נכונה (ראיתי אישית מקרה של'קח להם יומיים לפתור תקלה של … invalid boot signature של GRUB. הם פירמטו את המכונה הפיזית, אני לא צוחק!). בשבוע האחרון ראיתי את ה"יעילות" של אורקל. עמית פתח באורקל תקלה על אחד מהשרתים הוירטואליים (שנתמך ע"י אורקל). לכלי איסוף לוגים של אורקל לקח כמעט 3 שעות עבודה ליצור קובץ שצריך לשלוח לתמיכה (אחרת הם לא עוזרים לך בכלים), אני החלטתי מנסיוני פשוט לפתור את העניין וסיימתי את התקלה (לאחר תיקונים והתקנות של חבילות חסרות שאורקל ישראל לא התקינו) לאחר דקות ספורות. אם לא הייתי נותן שרות ללקוח, הוא היה מושבת לפחות ליום!.

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

ודא כי יש לך איש לינוקס מקצועי בחברה או פרילאנסר שנותן שרותים ושהוא מקצועי, עם המערכת OVS של אורקל, אתה בהחלט תצטרך את זה.
אם החלטת ללכת על פתרון XEN, כדאי שתתקין על שרת טסטים את XenServer, הוא יותר מעודכן ויותר ידידותי לחובבי GUI (אם כי גם שם תצטרך איש לינוקס לכל האוטומציה, סקריפטים וכו').
אל תאמין לכל מיני חומרים שיווקיים שמראים לך כי OVS יותר טוב מ-ESXI או Hyper-V. הייתי שמח לפרסם תוצאות ביצועים, אולם הרשיון של OVS אוסר זאת.

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

מוגש כחומר למחשבה.

הדרך ל-LAB משלי (פרק ראשון)

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

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

מה מטרות ה-LAB שלי? יש לה כמה מטרות:

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

אתחיל במשהו שלא קשור ישירות למחשבים אלא לאחסונם. היו מספר אנשים שהציעו לי לפנות לאחת ממפעילי ה-Data Center ולקחת שם חצי ארון או ארון, ואז כל פעם שיש לי ציוד שאני צריך להשתמש בו, להתקין אותו שם ולפעול מרחוק. הבעיה? המחיר. חישוב סולידי שלי לכמות ה-U שאצטרך בארון מגיע בין 12U ל-16U, מה שאומר שצריך להשכיר לפחות חצי ארון. עלות השכרת חצי ארון? לא פחות מ-2500 שקל לחודש.

לעומת זאת, אם נחשב תצרוכת חשמל של 2 שרתי Storage, עוד 4 מחשבי דסקטופ שישמשו כשרתים, מתג ואולי עוד מחשב אחד, נקבל סכום נמוך בהרבה. קילוואט שעה נמכר כיום הוא 63.76 אגורות (כולל מע"מ). נניח שאשתמש ב-3 קוט"ש (נניח פרוע מאוד, המספר שסביר שיהיה אצלי הוא בסביבות 2 גג). אז נכפיל 3 כפול 65.76, יוצא 197.28 אגורות. נכפיל את זה ב-744 (שזה 24 שעות כפול 31 ימים בחודש), ונמיר לשקלים, יוצא 1467.76 שקל. נחזור למציאות ששם אשתמש ב-2 קוט"ש לשעה גג, יוצא 978 שקל, בערך שליש מעלות השכרת ארון בחוות שרתים כלשהי. כך זה כואב פחות בכיס.

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

הבעיות של VCSA

קצת היסטוריה על VMWare ו-ESX: כש-VMWare החליטו בזמנו לצאת עם גירסת שרת מלאה (לפני כן היתה “גירסת שרת” אבל שהיתה רצה על מערכת ההפעלה שמותקנת במחשב שלך) הם יצאו עם 2 גרסאות: האחת נקראה ESX והשניה ESXi. גירסת ה-ESX נראתה כמו הפצת לינוקס (מה שגרם לרבים להתבלבל ולחשוב שמדובר בהפצת לינוקס מטעם VMWare עם קרנל לינוקס. המציאות היא שהקרנל הוא כולו של VMWare והם השתמשו בממשק תאימות בינארית ללינוקס (ABI) על מנת להריץ שרותי לינוקס שונים על ה-ESX וגם שמנהל השרת יוכל להתקין שרותים נוספים מלינוקסים אחרים על המכונה (זה היה תואם רד-האט). גירסת ESXi לעומת זאת היתה גירסה רזה שכללה רק את הקרנל + Shell מינימלי ועוד כמה כלים, רק בלי חומת אש, שרותי לינוקס וכו’.כיום יש רק גירסת ESXi.

אחד הדברים שהפתיע אנשי לינוקס רבים היה כלי הניהול של VMWare, מה שמוכר בתור ה-vCenter (לשעבר Virtual Center) שהיה כלי על טהרת ה-Windows שנכתב בדוט-נט ושגם שילב בתוכו חלקים מאינטרנט אקספלורר. VMWare גם הוציאה כלי וובי אבל שלא נתן הרבה פונקציונאליות (כלומר הוא לא יכל להחליף את ה-vCenter). מנהלי רשת רבים התלוננו מדוע אין כלי לינוקסאי כזה והתשובה של VMWare היתה שחרור של SDK וגם מכונה וירטואלית לינוקסאית קטנה שכללה סקריפטים שאפשרו לחברות שמשתמשות בלינוקס – להתממשק עם ה-vCenter.

בגירסה 5 הדברים התחילו להשנות (והשתנו יותר בגירסה 5.1) כאשר VMWare שחררו את ה-VCSA (ר”ת של VMWare vCenter Server Appliance) – זו מכונת לינוקס וירטואלית שאמורה להחליף את הגירסה החלונאית בגירסת לינוקס. היא עדיין לא כוללת את כל הפונקציונאליות של הכלי החלונאי (כך לדוגמא עדיין לא ניתן להתקין תוספים/Plugins ב-VCSA עצמו), אבל VMWare נתנה רמז עבה מאוד שזו דרכה – היא חוזרת ללינוקס ובגרסאות עתידיות היא תשקיע יותר ב-Appliance הלינוקסאי מאשר בכלי החלונאי.

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

הבעיה הראשית מתחילה בזה ש-VMWare לא שחררה אותו כקובץ ISO להתקנה שמזכירה לינוקס (כמו שהיה ב-ESX 3.X) אלא שחררה אותו כקופסא סגורה עם קבצי OVF, VMDK וכו’, ומה ששחררו קיימות בו כל מיני בעיות הקשורות לרשת שפוסט זה יתייחס אליהם.

כאן אצלי בבית ב-LAB שלי, יש לי 2 שרתי DNS (מאסטר/סלייב) וסביר להניח שאם אתה מתעסק עם VMWare בחברה, יש לכם איזה שרת DNS, בין אם זה לינוקס או (סביר להניח) הפתרון של מיקרוסופט שמשולב Active Directory. אני מניח שהכנת לך שם hostname יחודי עבור ה-VCSA עם כתובת IP יחודית משלו ושלא ממש הלכת ל-Go Daddy או ספקים אחרים כדי לרכוש לשרת תעודת SSL, וכאן מתחילה הבעיה (לא באי רכישה) – ה-VCSA מגיע עם שם מכונה localhost שזה לא בדיוק דבר שתרצה.

אתה יכול להיכנס לממשק הוובי, להגדיר כתובת IP ושם hostname, להתחבר ל-AD ואולי להשתמש ב-DB חיצוני (אורקל או DB2 של IBM, עוד לא SQL של מיקרוסופט וגם משום מה לא MySQL, קצת מפתיע ש-VMWare משתמשים ב-JAVA ב-VCSA והם משתמשים ב-JDBC ב-Tomcat אבל הם לא כוללים תמיכה ל-DB אחרים. אם אתם רוצים להוסיף תמיכה למיקרוסופט SQL נסו את הלינק הזה [אגב, הלינק כרגע מת, אבל תודות לגוגל אפשר לראות את הגירסה הטקסטואלית כאן]), אבל ברגע שתשנו כתובת IP ואת ה-hostname ושאר פרמטרים (לא לשכוח ללחוץ על Toggle certificate settings שישתנה ל-yes) – תצטרכו להפעיל את המכונה מחדש (דרך החוצץ System)

ואז המכונה תיתקע בעליה, אם תסתכלו בקונסולה, תראו שהוא נתקע בשורה שכתוב:

waiting for the embedded database to startup [ok]

מה קרה? אוה, טוב ששאלתם…

ה-VCSA הבין שצריך ליצור תעודת SSL חדשה, והוא יצר, אבל הסקריפט של ה-DB לא יודע מה לעשות הלאה, אז הוא פשוט נתקע. אם תעשו Reboot למחשב, זה לא יעזור. זה יחזור שוב. מה שצריך לעשות הוא לבטל את האופציה ליצור תעודות SSL, אבל … אין לכם גישה לא לממשק הוובי ולא ל-SSH. תצטרכו לטפל בזה כמו שמטפלים בתקלה בשרת לינוקס (לא חשבתם שתתחמקו מלינוקס, נכון?)

אז איך מטפלים? כרגיל עם VCSA, מי שבנה את ה-Appliance בנה בצורה מחורבנת לגמרי. Safe mode לא יעזור לכם, ולכן עקבו אחר ההוראות הבאות:

הפעילו את השרת מחדש והיכנסו מיד ל-Console ולחצו על מקש (לדוגמא רווח) כדי לעצור את הטיימר.
לחצו על מקש p ואז ה-grub יבקש סיסמא. הסיסמא היא סיסמת ה-root שלכם (אם לא שיניתם אותה עדיין, היא vmware באותיות קטנות)
לאחר הקשת הסיסמא תחזרו שוב ל-GRUB. בחרו בשורה הראשונה ולחצו על מקש e
כעת יופיעו לכם השורות ש-grub אמור להריץ. לחצו על החץ למטה ובחרו בשורה השניה ושוב לחצו על מקש e
לכו עם החיצים עד סוף השורה והוסיפו את הטקסט הבא: init=/bin/sh ולחצו על מקש enter
כעת לחצו על מקש b והלינוקס יתחיל להיטען ולאחר מספר שניות הוא יעצר עם סימן #
כעת עלינו למחוק קובץ. כל עוד הקובץ קיים, המערכת תנסה ליצור תעודות חדשות והמערכת תיתקע ב-boot רגיל, לכן הכניסו את הפקודה:
rm /etc/vmware-vpx/ssl/allow_regeneration
הקישו את הפקודה reboot ולחצו enter. המערכת תיתן אולי מספר הודעות שגיאה. תתעלמו.
המערכת תעלה מחדש ובהצלחה. לאחר שתקבלו את המסך הכחול (אחלה בחירת צבעים יש להם), תמתינו עוד מספר שניות (או דקות, תלוי במעבד וכמה חזקה המכונה) ואז היכנסו לממשק הוובי

ברכותיי. נגמרה הבעיה.

אני ממליץ בחום לא להשתמש ב-VCSA במערכות פרודקשן! כותב שורות אליו מצא המון סקריפטים בתוך ה-VCSA שיש להם באגים ומי שכתב אותם כנראה למד לינוקס מתוך ספר ולא מתוך התנסות מלאה (שורות של סקריפטים שחוזרות במקום להשתמש ב-while וכו’) ויש גם לא מעט שגיאות במימוש התחברות ל-NFS – עקבו אחר ההוראות כאן) ואני משער שהדברים ישתפרו בעתיד (ואולי, מי יודע, אולי הם יוסיפו איזה משהו שמראה הורדת גירסה בזמן שמשדרגים במקום מסך סטטי שאין לך אפשרות לדעת אם יורד משהו וכמה ירד!), אבל עד אז, שימו את ה-VCSA כ-VM על מכונה צדדית (אגב, בניגוד להגדרות שם, אין צורך ב-8 ג’יגה זכרון, גם 4 יספיקו בשביל הטסטים). אני גם מקווה שבעתיד הם יוציאו גירסת ISO נורמלית ואולי, רק אולי, יהיה פורום או מקום כלשהו לדווח על באגים ואולי לתת להם תיקוני סקריפטים, גם למי שאין לו מנוי בתשלום (היי, אני יכול לקוות, לא?).

כמה מילים על KVM ועל Open Stack

אנשי IT רבים, כשהם מדברים על וירטואליזציה, הם מדברים בד”כ על אחת מ-2 הפתרונות הידועים: VMware עם סל הפתרונות שלו או פתרונות מבוססי Hyper-V של מיקרוסופט. חלק קטן מהאנשים גם מכיר פתרונות מבוססי Xen כמו הפתרון של Citrix.

לאחרונה יותר ויותר אנשים שומעים על Open Stack, ואמנם רבים מתחילים להתעניין בו וחלק מהחברות גם מתחילות (בזהירות) להטמיע פתרונות שהם “Open Stack”. חברות רבות מייצרות פתרון Open Stack ובמקרים לא מעטים פתרון אחד אינו תואם לפתרון אחר, אבל לא ניכנס לזה כרגע.

חלק עיקרי מ-Open Stack הוא החלק של הוירטואליזציה, העיבוד, ה-Compute ולמרות ש-Open Stack יכול לעבוד כמעט עם כל פתרון וירטואליזציה, בברירת המחדל שלו הוא משתמש ב-KVM של רד האט.

KVM שבעבר נתפס כמשהו “נחמד” אך רבים העדיפו לא להיכנס אליו (ואם להשתמש בפתרון מבוסס קוד פתוח אז פתרון מבוסס Xen), נתפס היום ככלי וירטואליזציה רציני מאוד. חברות כמו גוגל עם ה-Compute Engine שלה משתמשת ב-KVM, חברות Hosting רבות יורדות לאט מהפתרון שיש להם ועוברות להשתמש ב-KVM, וגם חברות שמציעות שרתים וירטואליים ממש בזול (כמו Digital Ocean) נותנות את הפתרון עם KVM ולא עם פתרונות וירטואליזציה אחרים. גם חברות ענק כמו IBM שבעבר היו נותנות פתרונות מבוססי VMWare או פתרונות אחרים, נותנות כיום פתרונות עם KVM ועם תוכנות נוספות משלימות. כך לדוגמא IBM מציעה פתרונות VDI עם שילוב פתרון של VERDE כאשר הוירטואליזציה עצמה היא KVM “נטו”.

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

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

יתרון גדול נוסף הוא שגם מבחינת Middlewear אינך מוגבל. אתה משתמש ב-SAN כלשהו? כל עוד אותו SAN יודע “לדבר” בפרוטוקולים כמו iSCSI או NFS וכל פתרון לינוקס/יוניקס ידוע, הוא יוכל לעבוד עם KVM. אתה מעוניין ב-Switch וירטואלי חזק שיודע לעשות פילטרים, QoS ודברים אחרים? פתרון כמו OpenVSwitch ישמח לגשר בין המכונות הוירטואליות שלך ולתת לך את מה שאתה צריך. פתרונות מבוססי VDI ל-Windows או Linux? אם זה Windows, אז יש לך פתרון RDP כבר בתוך ה-Windows (ומעליו יש לך VLC לראות את ה-Boot אם אתה רוצה), ובלינוקס אתה יכול להשתמש בפתרונות כמו NX שיחסוך לך תעבורה וגם יתן לך איכות תצוגה מעולה.

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

רוצה לעבוד עם סקריפטים? (סביר להניח שהתשובה שלך תהיה “כן”): אז הפתרון הראשי שתרצה לבדוק הוא Libvirt שנותן לך תמיכה בכל שפת סקריפטים ידועה ואפילו בשפה כמו #C. עם Libvirt אתה יכול לעשות אוטומציה להכל, כיד הדמיון הטובה עליך.כלי שיכול לעזור לך הרבה בתוך Libvirt הוא virsh, שניתן להריץ אותו דרך shell ולבצע דברים. אגב, עם Libvirt ניתן גם לנהל מערכות וירטואליות מתחרות כמו vCenter או שרתי VMware בחיבור יש ל-host.
רוצה קצת GUI על הלינוקס שלך? (נו טוב, יש גם כאלו). לשם כך יש כלי כמו Virt-Manager. עם הכלי הזה תוכל בקלות להרים מכונות, לראות צריכת משאבים וכו’. זה ל-vCenter כמובן, אבל זה כלי בסיסי מספיק כדי להתחיל ללמוד וגם לעקוב אחרי מערכות קיימות שרצות.
מה עם כלי רציני שרץ דרך דפדפן? אה, טוב ששאלתם, בשביל זה יש את oVirt. זה הכלי הכי רציני שנותן לך לנהל הכל ב-KVM.

אז מה ההבדל הגדול בין KVM ל-Open Stack? אפשר להשוות את ההבדל ביניהם להבדל בין vCenter ל-vCloud Director. ה-Open Stack מתאים למצבים שיש צורך בהמון, המון מחשוב ענן של אלפי שרתים וירטואליים, פריסה על פני כמה Data Centers, צורך בשרותים דמויי AWS של אמזון (כמו S3 וכו’) ובקיצור – כשמדובר על דברים גדולים, Open Stack יכול בהחלט להיות אופציה טובה.

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