קטגוריה: תחזוקה

טיפים להגנה על האתרים שלך

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

זה לא משנה אם הדעות הפוליטיות שלך הן ימין, שמאל, או מרכז, כולנו יודעים שישראל היא מטרה להתקפות תדירות על כל פיפס שקורה במדינה ושקשור למצב בטחוני, מצב בשטחים וכו'. כל מיני "התקהלויות" שונות קובעים תאריכים כדי לתקוף אתרים שמתארחים בארץ (או בחו"ל) כל עוד יש להם קשר כלשהו לישראל, ולפעמים מספיק שיש לאתר דומיין עם סיומת co.il/org.il/net.il כדי שהאתר יהיה באיזו "רשימת מטרות" להתקפה.

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

אתרים רבים מתארכים באחת מ-2 חבילות עקריות לאירוח אתרים: אכסון משותף (Shared Hosting) ושרת יעודי (בין אם וירטואלי או פיזי). אתחיל באכסון המשותף.

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

אירוח אתר (או אתרים) בשרת פיזי או וירטואלי נותן יתרונות גדולים וברורים כגון:

  • רוחב פס יותר גדול לשרת את גולשי האתר
  • אפשרות לאחסן הרבה יותר אתרים ותתי-אתרים
  • אפשרות לקבוע אלו שרותים ירוצו
  • אתם קובעים את הגדרות האבטחה
  • ועוד ועוד

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

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

  1. מומלץ להעביר את התוכן של האתר דרך ספק CDN כלשהו ודרכו בלבד. ישנם 2 ספקי CDN גדולים שאני יכול להמליץ עליהם:  Cloudflare ו-Incapsula. ל-Incapsula יש יתרון שיש להם שרת סופי (Edge) בישראל, אולם כמות הנתונים שהשרות נותן בחבילת החינם היא קטנה מאוד (50 ג'יגהבייט). ל-Cloudflare לעומת זאת, אין מגבלת תעבורת נתונים גם בחבילת החינם. אצל 2 הספקים החבילות המסחריות נותנות הגנה רצינית מאוד נגד סוגים רבים של התקפות כך שכל גלישה לאתרכם (ובמידה והתעבורה של האתר שלכם עוברת דרך אותו ספק CDN) – המערכת תבדוק מהיכן הגולש מגיע, האם זהו גולש אמיתי או סקריפט זדוני, האם זהו נסיון גלישה אמיתי או נסיון לפרוץ לכם את האתר וכו'. למי שיש אתר והאתר יוצר רווחים עבורו, אני ממליץ להתחבר לאחד מספקי ה-CDN כמה שיותר מהר.
    נקודה חשובה שרבים מתבלבלים בה – ספק CDN אינו מארח את האתר שלכם. הוא שומר חלקית עותק מקבצים מסויימים ובכך הוא מאיץ את מהירות הגשת חלק מהדפים לגולש, אך כשמגיעה בקשה לדף מסויים לדוגמא, הוא מעביר את הבקשה לשרת שלכם (למעט מקרים שהשרות מזהה שמדובר בסקריפט זדוני, במקרים כאלו הוא ינקוט צעדים שונים למנוע מהסקריפט לפרוץ).
  2. שרות Mail – שרתים וירטואליים רבים של לקוחות מריצים שרותי Mail כך שהאתר ישלח אימיילים ללקוחות וגם ישלח לבעל האתר הודעות אימייל שונות (אישורים לתגובות, אישורי רכישה מהאתר, הודעות מלקוחות וכו'). במקרים רבים שרות ה-Mail אינו מוגדר בצורה מיטבית או בצורה מאובטחת בצורה מספקת, כך שיכולים לקרות במקרים רבים בעיות של שליחה וקבלת הודעות מייל מכיוון שהשרת נחסם ע"י שרתים אחרים וההודעות שיוצאות מהשרת הוירטואלי יסומנו כ"זבל" (spam).
    אני ממליץ לבטל את שרות ה-Mail המתוקן בשרת ולהשתמש בשרות כמו של חברת Mailgun. החשבון החינמי שאותה חברה נותנת, מאפשר משלוח וקבלה של עד 10,000 אימיילים בחודש. האתר עצמו אינו מארח חשבונות אימייל, אלא משמש כ-redirect, כך שהשרות ישלח את המייל בשם האתר שלכם וכל מייל שיגיע אליכם, יופנה אוטומטית לחשבון מייל שיש לכם.
  3. התחברות דרך SSH: ישנם מאות אלפי סקריפטים שסורקים את רשת האינטרנט למצוא דרכים להיכנס לאתר שלכם, במיוחד דרך חיבור SSH (זהו החיבור שדרכו ניתן לבצע פעולות על השרת שלכם דרך מסוף [terminal]). יש לי 3 המלצות לגבי שרות זה (ההמלצות מיועדות למי שמתחזק את השרת):
    * להעביר את חיבור ה-SSH מכניסה 22 למספר פורט אחר (מעל 1024)
    * לחסום כניסת root ישירות (כך ששימוש ב-root יתאפשר ע"י sudo או su בלבד)
    * לעבור מכניסה של סיסמאות לכניסה עם מפתחות
    * לעבור להשתמש ב-Port Knocking.
  4. שימוש בפאנלים כמו WHM/cPanel או Direct Admin: פאנלים אלו הם פאנלים נוחים לעבודה למי שאינו מכיר לינוקס, אולם הבעיה המרכזית איתם שהם מוגבלים מדי לחסום הגדרות שבעל האתר עושה שיגרמו לכך שהשרת יהיה חשוף לפריצות.
    לכן, אם אתם מתעקשים לעבוד עם פאנל כלשהו, לכל הפחות מומלץ לגשת אל הפאנל מאחורי שרות VPN (כדי שהפאנל לא יהיה חשוף לנסיונות תקיפה). אם יש לכם הרבה אתרים והגדרות שונות שאתם צריכים תדיר, מומלץ במקום פאנל לקחת מישהו שמבין בלינוקס ובאבטחת מידע, כך שהשרת יהיה כמה שיותר מוגן.

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

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

המלצות לגבי שרת ZFS ל-Enterprise

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

נתחיל במעבד: ל-ZFS אין צורך במעבדים ממש חזקים, כך שעד גבול מסויים אתה יכול להשתמש במעבד Xeon נמוך מאוד או מעבד Atom שמיועד לשרתים (סידרה C25XX או C27XX). מה הגבול? הגבול קשור לדברים שאתה רוצה ממערכת ZFS. אם לדוגמא אתה צריך Deduplication או הצפנה, תצטרך בהחלט משאבי מעבד טובים כמו Xeon E3 / E5.

שמתם לב שלא הזכרתי לעיל מעבדים כמו כל סידרת ה-i5/i7? הסיבה לכך פשוטה: שרת ZFS ב-Enterprise צריך זכרון ECC, ומעבדי i3/i5/i7 (או מעבדי AMD מסידרה 8XXX/6XXX ומטה) אינם תומכים בזכרון זה. כשמדובר בשרת ביתי, חשיבות הדיוק של קריאת הנתונים מהדיסקים אינה כה קריטית ורוב הזמן לא תהיה בעיה, אבל ב-Enterprise, במיוחד שאתה מחבר שרתים לשרת ZFS, כל ביט חשוב שיעבור בדיקה ויגיע ליעדו בצורה תקינה (זה היתרון של ZFS – הוא לא בודק checksum של כל מה שהוא כותב לדיסקים, אלא גם הפוך, כשהוא קורא ושולח אותו, דבר שלא מבוצע במערכות מתחרות שמשתמשות במצבי RAID חומרה, וכך יכולים לקרות גם מצבים לא נעימים של bit-flip) ולכן זכרון ECC הוא חשוב מאוד.

אם דיברנו על זכרון: כמות הזכרון שצריך לשרת ZFS מאוד תלויה בשרותים שתריצו על שרת זה החוצה (SMB, NFS, iSCSI וכו'). שרותים כאלו צריכים זכרון. גם ZFS בעצמו צריך לא מעט זכרון, ושוב, במיוחד אם אתה רוצה להשתמש ב-Deduplication – תצטרך ערימה של מקלות זכרון (עם ECC).

בברירת מחדל, ZFS ישתמש בערך במחצית ה-RAM שיש במכונה שלך לצרכי ARC (סוג מסויים של Cache שיושב על ה-RAM) אבל המכונה תצטרך גם כונני SSD (תיכף אגיע לכך) לצרכי Cache. במקומות רבים התיעוד של ZFS הולך עם "כלל אצבע" שיש צורך ב-1 ג'יגהבייט זכרון על כל טרה דיסק שאתה מכניס (מדובר על טרהבייט "ברוטו" לפני RAIDZ) אבל אם אינך משתמש ב-deduplication, כלל זה אינו נכון. מנסיוני, אני ממליץ על הדברים הבאים:

  • 16 ג'יגהבייט זכרון על מערכת בינונית שכוללת בין 4-8 דיסקים של 1-3 טרהבייט
  • 32 ג'יגהבייט זכרון על מערכת שמורכבת מ-8-16 דיסקים של 2 טרהבייט
  • 64 ג'יגהבייט זכרון על מערכת שמורכבת מ-12-24 דיסקים של 2-4 טרהבייט

חשוב לציין: את הגדרות ה-Cache של ARC ניתן כמובן להגדיר מבחינתם מינימום/מקסימום, ולכן אלו רק המלצות ולא "כללי ברזל", אך ככל שהשרת ZFS מגיש/מקבל יותר ויותר קבצים והעומס גודל – יש צורך ב-ARC גדול יותר, כך שהמערכת תגיש קבצים בצורה מהירה יותר.

דיסקים קשיחים: את נושא הדיסקים אחלק ל-3:

  1. מערכת הפעלה – מכיוון ש-ZFS עצמו לא משנה הרבה דברים במערכת, כל דיסק קשיח קטן יכול להספיק. את קבצי ההגדרות של ZFS ניתן בקלות לגבות לתוך מערכת ה-ZFS (או החוצה), כך שגם אם הדיסק הזה הולך, אפשר להקים על דיסק חדש לינוקס מינימלי, להתקין את ה-ZFS, לבצע import של ה-pool ואולי להעתיק קובץ הגדרות יחיד, לבצע reboot (לשם בדיקה) ולחזור להשתמש. למחמירים, אפשר להכניס את מערכת ההפעלה על 2 דיסקים קטנים ב-RAID-1 (שאינו ZFS), אבל זה מיותר ברוב המקרים (הח"מ עובד בתקופה הנוכחית על סקריפט להתקנת כל המערכת הפעלה עבור ה-ZFS ישירות לתוך ה-ZFS עצמו כך שכמעט ולא יהיה צורך במחיצות נפרדות על ext3/4/xfs, והצורך היחידי יהיה מחיצות עבור UEFI ו-boot/ שאותן אפשר להכניס על כרטיס SD כי הן לא משתנות.
  2. דיסקים ל-Cache ול-Logs (נקרא ZIL – ZFS Intent Log) – כאן מומלץ על דיסקים SSD, מומלץ לפחות 2-4 דיסקים. ל-logs עצמם יש צורך ב-Partition קטן מאוד (אין צורך יותר מ-5 ג'יגהבייט), וכל שאר המקום ב-SSD יחובר יחדיו (כמו RAID-0) לשמש כ-Cache גם לכתיבה וגם לקריאה. הנתונים עליו אינם חשובים והם בין כה מתאפסים בזמן reboot, אבל עצם קיומם נותן ל-ZFS אפשרות לתת ביצועים ממש מעולים. אין צורך לקנות כונני SSD ממש גדולים (1 טרה ומעלה), אפשר להסתפק ב-2-3 כוננים של 256 ג'יגהבייט – בהתאם לעומס המתוכנן שאתם רוצים להעמיס על אותו שרת ZFS.
    לגבי סוג של SSD – אנחנו ב-2015, כיום כונני ה-SSD מחברות רציניות (כמו סמסונג, סאנדסיק, אינטל, וכו') כוללות בקר בכונן SSD שיודע מתי לכתוב את הנתונים בצורה שהכי פחות תשחק את הכונן, ומבחינת TRIM – מערכות לינוקס (ZFS על לינוקס) יודעות לתמוך ב-Trim על מנת להאריך את חיי הכונן.
  3. דיסקים קשיחים – ידוע לי כי ב-Enterprise מאוד אוהבים דיסקים מבוססי SAS ו-ZFS מאוד שמח לעבוד עם דיסקים כאלו, אולם ניתן לעבוד גם עם דיסקים מבוססי SATA, ולפני שגבות יורמו לאחר קריאת השורה לעיל – הדיסקים שיצאו בשנת 2014 לפחות הם אמינים לא פחות מדיסקים מבוססי SAS ולראיה – הרחבת האחריות שיצרני הדיסקים ביצעו לאחרונה. כך לדוגמא עם דיסקים Red Pro של Western Digital (כן, עם חיבור SATA) האחריות הורחבה מ-3 ל-5 שנים.
    אני מניח שרבים יטענו כי דיסקים SAS נותנים ביצועי כתיבה/קריאה הרבה יותר מהירים, אבל בעולם ה-ZFS הדברים שונים: הכל נכנס ויוצא דרך 2 שכבות ה-Cache (ה-ARC ו-L2ARC) שאחת מהן יושבת על ה-RAM והשניה יושבת על SSD. יש כמובן דיסקים SAS עם בקרים שכותבים/קוראים במהירות מדהימה של 12 ג'יגהביט לשניה, אבל המחירים שלהם מאוד גבוהים. אני ממליץ לקרוא את המאמר הזה לגבי SAS מול SATA בהתייחסות ל-ZFS.

מבחינת ברזל שיארח את הדיסקים, אפשר כמובן ללכת בשיטה הקלאסית של להכניס את הכל על שרת 2U או 3U בהתאם לכמות הדיסקים שאתם מכניסים, וזה עובד מצוין.
אישית ההמלצה שלי היא להפריד בין הדברים. להשתמש (לדוגמא) בשרת 1U שבו ישב הדיסק עם מערכת ההפעלה, וכונני ה-SSD (ב-1U אפשר להכניס בקלות 6 כונני SSD) כשכל הדיסקים הם 2.5". שאר הדיסקים המכניים יכולים לשבת בתוך מארז JBOD שמתחבר ב-SAS חיצוני לשרת 1U.
הסיבה להמלצה? כמה סיבות:
* במארזי JBOD אין הרבה אלקטרוניקה שיכולה להתקלקל (אין זכרונות, אין לוח אם)
* קל לשרשר JBOD נוספים אם רוצים להתרחב.
* ב-JBOD יש לוגיקה פשוטה – backplane ובקר.
* אפשר להעביר את ה-JBOD למערכות אחרות במידה ויהיה לכך צורך.

חיבורי רשת – מכיוון ש-ZFS רץ על לינוקס מערכת הפעלה, מי שמטפל בכל עניין התקשורת פנימה החוצה זו מערכת ההפעלה, לא ה-ZFS, כך שאפשר להשתמש בכל סוג חיבור שמעוניינים, החל מחיבור Ethernet של 1 ג'יגהביט ועד Infiniband בחיבור EDR ומעלה או בכלל להשתמש בסיבים אופטיים. הכל תלוי בתשתית שיש לכם ובהשקעה שאתם רוצים להשקיע.
ההמלצה שלי לכל הפחות היא להשתמש ב-4 חיבורי רשת שקיימים בכל שרת מכובד, ולהפריד בין iSCSI, SMB, NFS וכמובן ניהול. אם אתם משתמשים בפרוטוקול יחיד כלשהו (iSCSI לדוגמא) אז אפשר כמובן לצרף חיבורים וגם להגדיר את החיבורים בשיטות שונות.

אלו בעקרון ההמלצות. אין שום בעיה לקחת PC, לדחוף כמה דיסקים ולהרים מערכת ZFS, אבל התוצאות יהיו בהתאם. מערכות ZFS אינן "קסם" והן דורשות משאבים (במיוחד תהליך ה"קרצוף" שמומלץ שירוץ אחת לשבוע אם מדובר בדיסקים SATA או אחת לחודש אם מדובר בדיסקים SAS).

[stextbox id="info" caption="גילוי נאות"]כותב שורות אלו מוכר שרותי יעוץ/הקמה/הגדרות למערכות יוניקס/לינוקס עם ZFS[/stextbox]

ZFS על לינוקס בהשוואה לפתרונות ZFS אחרים

לפני מספר שנים, חברת Sun שחררה כקוד פתוח את הקוד של ZFS, Solaris וכלים אחרים, והפצות יוניקס שונות אימצו את קוד ה-ZFS בשמחה. כך לדוגמא הפצות מבוססות BSD לגרסאותיו מגיעות עם תמיכה מובנית של ZFS, כמו גם גרסאות קוד פתוח של Open Solaris.

לאחר שחברת Sun נקנתה ע"י Oracle, פרוייקטי הקוד הפתוח נסגרו ומה שנשאר בחוץ – היווה הבסיס ל-ZFS שבשנים האחרונות קיבל Push משמעותי באותן הפצות יוניקס, כמו גם ZFS על לינוקס (שנקרא במקרים רבים ZoL, כלומר ZFS On Linux).

כיום ישנן הפצות יוניקס "ידידותיות" כמו FreeNAS ואחרות שמיועדות לרוץ מ-Disk On Key על מחשב פשוט, ובכך ניתן תוך דקות ספורות להרים "שרת" שיתן שרותי שיתוף שמערכת הקבצים הינה ZFS. ישנה גם מערכת של חברת Nexenta שרצה תחת גירסת קוד פתוח של Solaris אשר מאפשרת לך להרים בעזרת ממשק Web (לא ממש ידידותי, לעניות דעתי) מערכת ZFS.

האם אני ממליץ על מערכות אלו ל-Corporate? לא כל כך, וברשותכם, אסביר.

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

המצב שונה לחלוטין בגרסאות BSD למיניהן, וגם בגרסאות הקוד הפתוח של Solaris (כמו Open Indiana) – שם כמות הפיתוח נמוכה משמעותית ובמקרים רבים היא נעשית ע"י חברות קטנות שמפתחות דרייברים עבור שרת מסוים או Appliance מסוים. אם זה ירוץ על כרטיסים אחרים – מה טוב, ואם לא .. אז תממן פיתוח (כפי שאמרו לי חברת iX systems כשניסיתי להריץ FreeNAS ללקוח עקשן על שרתי DELL מסדרות R7XX).. כמה חברות אתם מכירים שמוכנים לשפוך כמה עשרות אלפי דולרים על פיתוח דרייברים בשביל שמערכת כלשהי תרוץ על שרת שהם רוצים? לא הרבה.

ומה עם אורקל? או, שאלה מצויינת.

אורקל מפתחת דרייבים ל-Solaris הסגור כל עוד השבבים נמצאים בתוך השרתים שהם מוכרים והם גם תומכים ומתקנים באגים אך לשם כך עליך להשתמש ב-Solaris הסגור (ואם אינך משתמש במכונה של Sun/Oracle, התעריף למערכת ההפעלה נע בין 1000-3000 דולר למכונה עם 1-4 מעבדים + 200 דולר עבור DVD – התקליטור, לא הכונן) ומחיר זה מקנה לך את מערכת ההפעלה עצמה, שום דבר אחר.

cw20v1-zfs-zs3-ba-04-2267398לאורקל יש ארונות שלמים וגם פתרונות של 4U, 20U ו-36U (תוכל לראות את הדגמים כאן) והמחירים כמובן בשמיים. על גירסת 4U לדוגמא שנותנת 6 טרהבייט (שמורכבים מ-20 דיסקים של 300 ג'יגה + מאיץ כתיבה [כונן SSD]) תצטרך לשלם פה בארץ משהו כמו 200,000 שקל (יש צורך להוסיף מיסוי, תוספת של יבואן וכו' למחיר המופיע בקישור). חשקה נפשך במשהו שנותן כמעט 400 טרהבייט של אחסון מהיר? המנכ"ל יצטרך להיות מעורב, כי בארץ זה יצא בערך מיליון שקל וגירסת ה-736 טרהבייט תצא בין 1.5-2 מיליון שקלים. אגב, מחירים אלו כוללים תמיכה רק לשנה הראשונה. לשנה השניה והלאה, יש צורך בהפרשה של סכומים ניכרים נוספים לתמיכה.

במחירים כאלו, אני בהחלט ממליץ לבדוק פתרונות מתחרים, למרות היתרונות הרבים של ZFS.

שאלה שאני נתקל בה במקרים רבים היא "איזו גירסת ZFS הכי מתקדמת?", ולצערי אין תשובה מאוד פשוטה לכך. ZFS מפותח גם בלינוקס וגם ב-Illumos, אך Illumos הוא Kernel ויש הפצות שונות שמכילות אותו, וגם שם קיימים בעיות של דרייברים לציוד חדש ויש צורך בידע רציני ב-Solaris על מנת להקים ולהתאים מערכת ZFS. יחד עם זאת, החדשות הטובות הן שהצוות שמפתח את ZFS מתייחס גם ל-ZFS On Linux והוא משחרר את רוב הפיתוחים גם לגירסת הלינוקס.

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

אז מה ההמלצה שלי? המלצתי מחולקת למספר חלקים:

  • אם אתם לוקחים PC פשוט ולא חדש (כלומר שיש לו תמיכה ב-BIOS או ב-Legacy Mode ב-UEFI) ויש לכם את הכח ללמוד ולהתנסות על דרך הלימוד והטעיה ואתם צריכים ממשק WEB ולהרים מערכת עכשיו – אתם יכולים לנסות את FreeNAS. החסרון: תמיכה בפורומים לפי המזל שלך. בעבר שיגרתי כמה בעיות רציניות שגיליתי עם FreeNAS שהיה מחובר ל-VCSA, רק כדי לגלות שאף אחד לא עונה.
  • אם המכונה היא PC (לא חדש) או שרת ישן (בן לפחות 3-4 שנים) עם BIOS, אתם יכולים להתקין Nexenta (כל עוד המערכת תכיר בדיסקים, בקרים, רשת ושאר ציוד, לא תמיד הציוד מוכר) עם מגבלה של גירסת ה-Community שלא מקבלת תמיכה רשמית, והגודל (ברוטו) אינו יותר מ-18 טרהבייט (כך שאם יש לך 2 דיסקים של 3 טרהבייט והם יהיו Mirror, אז החישוב הוא של 6 טרה, לא 3). מעבר לכך, המחיר הוא בערך $1800 דולר לשנה (אתם יכולים לראות רשימת מחירים של משווקים שלהם כאן) והמחיר עולה בהתאם לכמות האחסון וברמת התמיכה הרצויה.
  • אם מדובר בשרת רציני או שרת חדש (2 מעבדים ומעלה, 16 ג'יגה זכרון ומעלה, כמות רצינית של דיסקים) ואתם צריכים משהו חזק ויציב – אז ZFS שרץ על לינוקס יכול להוות פתרון מעולה (אפשר ליצור במייל קשר בנושא).

בפוסט הבא אסביר את ההבדל בין ZFS ל-File systems "מתחרים" שקיימים בשוק. פוסט נוסף שמסביר יותר לגבי חסרונות של ZFS On Linux ותשובות לבעיות – מופיע כאן.

[stextbox id="info" caption="גילוי נאות"]כותב פוסט זה נותן שרותי הקמה/תמיכה/אינטגרציה של ZFS לארגונים.[/stextbox]

שימוש ב-ZFS בשרת קבצים מבוסס לינוקס

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

יש בחברה שרת קבצים מאוד רציני שנותן שרותים שונים: CIFS/SMB, NFS, iSCSI ועוד. הוא מתממשק ל-Active Directory של החברה ודרכו שרתים שונים ותחנות עבודה מקבלים שיתופים שונים, הן בצורת "כוננים", כ-LUN וכו'. שרת הקבצים הזה (יכול להיות של NetApp או EMC או של IBM לדוגמא) מאוד קריטי בחברה והוא מאוד יקר, הן מבחינת תכנים שיש עליו והן מבחינת ה"ברזלים" שבו. כל מגהבייט מחושב בקפידה ואי אפשר לבוא למי שמנהל אותו ולבקש "תן לי 2 טרהבייט LUN למספר בדיקות שאני צריך לעשות". בקשה כזו בד"כ תצטרך להיות מלווה בנוהל שמצדיק את המקום, עם תאור מה הולכים לעשות ולמה צריכים את המקום, במקרים רבים יש ישיבות ולבסוף מחליטים אם לאשר או לא, ואם התשובה היא שלילית, ינתן פתרון אלטרנטיבי כלשהו.

מוכר לכם? גם לי זה מוכר.

סיטואציה נוספת שקיימת היא שיש צורך בשרת קבצים מחלקתי, נניח עבור קבוצת מפתחים, ומפתחים בד"כ "משתוללים" עם הצרכים שלהם. הם משתמשים ב-Version Control כלשהו ש"מטיס" המון קבצים מפה לשם, פתאום לכל משתמש יש כמה מאות קבצים בתיקיה והמספר הולך וגודל בקצב מהיר מאוד, לפעמים יש גם צורך בהקמת מכונות וירטואליות לטסטים שצריכים לא רק מקום אלא גם חיבור מהיר ותגובה מהירה מצד השרת (שלא לדבר על קצב IOPS…). כל הדברים הללו יכולים לשבת בשרת קבצים יקר, אך אם תשאלו כמעט כל מנהל Storage, הוא יעדיף שאת כל ה"השתוללות" הזו שתבוצע בשרת קבצים אחר ופעם ביום יהיה גיבוי אליו שלאחר מכן יועבר למערכת הגיבוי המרכזית, לדוגמא. אני לא מכיר אף מנהל מערכת Storage שממש מחפש לראות איך המערכת שלו "נחנקת" על ידי 1001 דברים שאפשר להפנות אותם לפתרונות משניים.

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

  • הביצועים של שרת כזה במקרים רבים הם לא בדיוק מהירים, במיוחד שמחברים אותו לשרותים תובעניים כמו vSphere. ב-vSphere אם לדוגמא תרים מכונות וירטואליות דרך NFS, וכל הדיסקים בשרת קבצים הם דיסקים מכניים (לא SSD) – אתה תכיר את העובדה ש-vSphere מחכה בכל פעם שיש כתיבה לדיסק דרך NFS, שהשרת קבצים באמת כתב כל בייט לדיסק (תקימו מכונת VM מבוססתWindows 7 או 8 ותראו זאת כבר בהתחלה, לדוגמא).
  • גיבוי של שרת כזה מצריך לעיתים פתרונות די "יצירתיים". אם אתה משתמש ב-LVM על הלינוקס, אתה יכול להשתמש בפונקציית ה-Snapshot שלו, אך פתרון זה הוא פתרון די מורכב (והוא בכלל ברמה של מתחת ל-File system). אם תשתמש בפתרונות מבוססים tar או rsync, סביר להניח שתיתקל בבעיות אחרות (במיוחד שכל המכונות הוירטואליות רצות), שלא לדבר על ביצועים נחותים יותר בזמן הגיבוי. (אפשר כמובן לגבות מכונות וירטואליות עם VEEAM לדוגמא, אבל אז מדובר בצורך ברכישת רישוי וכו').
  • אם יש לך הפסקת חשמל או ששרת הקבצים נופל בגלל סיבה כלשהי (בעיות בקר דיסק לדוגמא או כבל SAS סורר), תצטרך לטפל בשרת קבצים ולקוות שה-VMs לא נדפקו, במיוחד אם הם היו עסוקים בפעילות אינטנסיבית של כתיבת קבצים רבים ורק אחר כך לטפל בכל המערכת וירטואליזציה, והסיפור נהיה יותר מורכב כשמדובר ב-Version Control שונים.
  • ויש עוד מספר אתגרים. (חוק מרפי מאוד אוהב מצבים כאלו).

שימוש ב-ZFS לעומת זאת על שרת קבצים כזה יכול להקל על החיים של מי שינהל את השרת בכמה אספקטים:

  1. מבחינת "חזרה לאחור" (הערה: snapshots בכל מערכת אינם גיבויים), אפשר לבצע snapshots מיידים שלא לוקחים כמעט שום מקום ואותם snapshots זמינים מיידית לקריאה והעתקה מהם/שחזור מהם. כך לדוגמא אני מממש סכמת Snapshots:
    1. יצירת snapshot כל רבע שעה (בשיטת FIFO כך שהראשון מושמד בהתחלת שעה וכו')
    2. יצירת snapshot כל שעה עגולה (שוב, בשיטת FIFO) כאשר ה-24 ה-snapshots האחרונים זמינים לי.
    3. יצירת snapshot יומי לכל החודש (31 סטים סה"כ)
    4. יצירת snapshot שבועי (4 סטים סה"כ)
    5. יצירת snapshot דו שבועי (2 סטים סה"כ)
    6. יצירת snapshot חודשי (12 סטים)
  2. לכל הקבצים במערכת יש checksum שנכתב ונבדק אוטומטית ע"י ה-ZFS, כך שאני בטוח מבחינת קבצים וסקטורים מקולקלים. יש בעיה בקובץ? ה-ZFS יקח אוטומטית את הקובץ ממקום אחר (mirror).
  3. אין לי צורך בשום LVM, ואני ממש לא צריך לחשוב על Partitions למיניהם, שלא לדבר על מקום שנגמר בווליום כלשהו. ב-ZFS הכל מחובר ביחד ואפשר לתת מקום לכולם ומצד שני אפשר להגביל מקום או לשמור מקום לצרכים שונים.
  4. יש לי את כל השרותי שיתוף שאני צריך זמינים מיידית. כך לדוגמא אם אני רוצה להגדיר שיתוף NFS, באותה שורה שאני יוצר את השיתוף דרך ה-command line, אני יכול לאמר לו מה יהיה השיתוף ועם מי. גם מבחינת iSCSI אני לא צריך להסתבך יותר מדי ואני יכול להגדיר לי אחד בגודל שאני רוצה (כולל תמיכה ל-thin provisioning) בפקודה אחת פשוטה.
  5. בסופ"ש מערכת ZFS יכולה להריץ פעולת "קרצוף" (scrub) שבודקת כל כל הקבצים בכל הדיסקים ומסמנת לעצמה מה תקין ומה לא ויודעת לנתב אוטומטית ולמפות לעצמה את התוצאות קרצוף.
  6. אני יכול בעזרת מספר פעולות פשוטות לראות איך הביצועים של המערכת מבחינת שיתוף התוכן ולראות היכן הביצועים יורדים, כך שאני יכול לתכנן איך אשדרג כדי לקבל ביצועים יותר גבוהים.
  7. אני יכול להגדיל את המערכת לכמה שצריך, תיקיות יכולות להכיל מאות אלפי או מיליוני קבצים מבלי לשתות קפה ולהמתין לקבלת פלט של ls בתיקיה "מפוצצצת" בקבצים. אין שום בעיה לצרף מספר JBODs כדי לקבל מאות טרהבייטים, פטהבייטים ומעלה.
  8. החלפת דיסקים היא פעולה פשוטה מאוד, ואני יכול להגדיר מערכי RAID (שנקראים RAIDZ ב-ZFS) שבהם גם מצב ש-3 דיסקים הם תקולים – המערכת תמשיך לעבוד.
  9. חשוב: אני לא חייב שכל הדיסקים יהיו SSD או SAS. אני יכול להשתמש בדיסקים מבוססי SATA (אני ממליץ על סידרת Red Pro של WD) ואני יכול להסתפק בכמות מצומצמת (מומלץ 2) של כונני SSD (לא חייבים סדרות שמיועדים ל-Enterprise) על מנת לקבל ביצועים טובים.
  10. אין לי יותר את הבעיה של הפסקת חשמל פתאומית בזמן שהמערכת בדיוק כתבה קבצים, כי ZFS מכיל דבר שנקרא ZIL שיודע להסתדר לבד ברגע שהחשמל יחזור (תאמינו לי, מנסיון של הפסקות חשמל מהסופות האחרונות, זה עובד יופי).
  11. אין לי צורך בבקרי RAID יקרים עם זכרון CACHE או סוללת גיבוי. יספיק לי כרטיס RAID פשוט במצב טיפש (JBOD).
  12. מבחינת גיבוי שרת הקבצים, 2 פקודות פשוטות יבצעו לי גיבוי מהיר לשרת ZFS משני או שאני יכול להתקין כל Client של מערכת גיבוי מרכזית, היא תראה את השרת ZFS כשרת לינוקס רגיל, כל מה שאני צריך זה להגדיר מה אני רוצה לגבות.
  13. אם כבר דיברנו על גיבוי – קל מאוד להתאים אותו לשימוש עם Windows, כך שגם משתמש פשוט יוכל לשחזר קבצים שלו דרך Restore Previous Versions ב-Windows במקום לבקש שישחזרו לו מגיבוי שנמצא על קלטות..

ואפשר גם לגדול:

  1. יש לך כמות דיסקים גדולה בשרת ואתה רוצה שקט נפשי? חלק את הדיסקים ל-2 בקרים שונים (בגלל שזה ZFS הבקרים יכולים להיות בקרי LSI מבוססי SAS2008 פשוטים שאפשר לקנות ב-100$) ומכיוון שאתה רץ על לינוקס, לא תהיה ללינוקס להכיר גם ב-5 בקרים על שרת אחד (מנסיון..)
  2. צריך לשרת יותר שרתים/תחנות? בשמחה! אתה יכול להשתמש ב-Lustre או Gluster עם ZFS, בין אם בשיטה של Active/Active או Active/Passive.
  3. צריך יותר רוחב פס? אתה משתמש בלינוקס, ולינוקס תומך כבר בכל כרטיס שנותנת תקשורת כלשהי, בין אם זה 10G או 40G או אפילו 100G, בין אם מדובר ב-Infiniband וגם פתרון משולב כמו FCoE וגם פתרונות של מספר כרטיסי רשת שונים באותו שרת. הכל רץ ונתמך בלינוקס.
  4. ZFS הוא מאוד גמיש, אפשר להתאים אותו החל מצרכים שלא דורשים הרבה תעבורה החוצה (לדוגמא: ארכיב), או הפוך (לדוגמא: VOD). אפשר להתאים אותו לצרכים תובעניים (לשרת הרבה מכונות VM, בין אם ה-Hypervisor או Hyper-V, vSphere, Xen או KVM).

ZFS הוא שילוב מעולה בין לינוקס למערכת File System הכי טובה שיש כיום. הפצות לינוקס כמו Red Hat או CentOS (וגם SuSE) יודעות לתמוך בשרתים החל מהרמה של שרתים מבוססי מעבדי Atom (סדרות C2XXX) ועד שרתי מפלצת עם 8 מעבדים ו-4 טרהבייט זכרון. לינוקס דואג לכל עניין תמיכת החומרה מבחינת דרייברים בהכל ובצורה הרבה יותר טובה מכל מערכת הפעלה מבוססת יוניקס אחרת (על כך הפוסט הבא ירחיב). ZFS משתלב עם הלינוקס המותקן כך ש-ZFS לא צריך לדאוג לשכבות מתחת ל-File System (חומרה ודרייברים).

מה עם פתרונות שהם ZFS שאינם מבוססי לינוקס כמו הפתרון של אורקל, ופתרונות אחרים כמו FreeNAS וכו'? על כך בפוסט הבא.

[stextbox id="info" caption="גילוי נאות"]כותב פוסט זה נותן שרותי הקמה/תמיכה/אינטגרציה של ZFS לארגונים.[/stextbox]

כמה מילים על פירצת האבטחה של Bash

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

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

נתחיל מה-Web. אם האתר שלך רץ תחת מערכת CentOS או RedHat או SuSE, אז כן – אפשר לפרוץ אם לא תעדכן מיידית את חבילת ה-Bash (פעולת yum update תספיק). שמים לב למשהו? העדכון היחיד הוא ל-BASH, לא לשום אפליקציה אחרת וזאת מהסיבה שדרך BASH המערכת "מרימה" שרותים, וספציפית עם ההפצות הנ"ל מכיוון שבהן ה-Shell (כלומר SH) מקושר ישירות ל-BASH. בהפצות כמו אובונטו או דביאן ה-SH מקושר ל-DASH, כך שמבחינתן זה לא כל כך רלוונטי.

אז עד כאן – העדכון באמת חשוב ויש לבצע אותו.

אבל מכאן ולהיסטריה של Internet Meltdown – המרחק ענק, ברשותכם אסביר.

אם לדוגמא האתר שלך מוגש למשתמשים דרך CDN ואתה מנוי בתשלום ל-CDN כמו Cloudflare העסקי או Akamai או אחרים, הרי שהינך מקבל בחבילה דבר שנקרא WAF (ר"ת Web Application Firewall), ואותו WAF נכון להרגע מעודכן כבר להכיר את הטריק נסיון פריצה עם ה-BASH כך שכל מה שנותר לך לעשות זה להסתכל בפאנל של ספק ה-CDN ולראות איך בזמן אמת מנסים לפרוץ לך … ולגחך. (שימו לב – אני מדבר רק על 2 ספקי ה-CDN הללו. לגבי אחרים – תצטרכו ליצור קשר עם הספק CDN). אני לא טוען שאין צורך לעדכן את המערכת שלך, אלא שאין צורך להיכנס ללחץ.

עדכון החבילה צריך להיעשות על כל הפצת לינוקס. נכון, הפצות מבוססות Debian לא חלה עליהן הפריצה באופן של הפעלת שרות Apache, אבל יש לא מעט שרותים צד ג' שרצים דרך init והשם מפעילים bash בהתחלה (תסתכלו בשורה ראשונה של הסקריפט אם זה משהו שהבאתם מהפצה אחרת). משתמשי אובונטו מוזמנים להסתכל כאן, Debian כאן. אני ממליץ גם להסתכל כאן באתר של רד-האט איך לעדכן וגם איך ניתן לבצע workaround עם mod_security.

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

אז זהו. שלא.

נתבים ושאר ציודים שנותנים ממשק Web אינם משתמשים בד"כ בחבילות שנמצאות בהפצות לינוקס. אף נתב לא מגיע עם Apache אלא אפליקציה אחרת שמגישה דפים ובכל הקשור ל-BASH, בכל הקופסאות משתמשים באפליקציה שנקראת Busybox שמאפשרת לבצע פעולות shell, אך הפריצה הזו אינה חלה עם שום גירסת Busybox.

כך שאפשר קצת לנשום לרווחה.

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

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

ניתוח פירצת Heartbleed

heartbleed1

יש עדכונים בסוף הפוסט.

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

בפוסט זה אנסה לסכם כמה דברים לגבי הפירצה ולהסביר כמה דברים נוספים לגביה.

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

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

חברת Cloudflare ניסתה במשך שבועיים להוציא מפתח פרטי דרך חור האבטחה בשרת טסטים שלהם והם נכשלו ולפיכך הם הכריזו על אתגר – הם הקימו שרת עצמאי עם חור האבטחה ואתגרו את הגולשים למצוא את המפתח הפרטי של השרת. עברו יומיים ו-2 פורצים שונים הצליחו לחלץ את המפתח (לא בקלות – אחד שלך 2,500,000 בקשות והשני 100,000) כך שפתרון הבעיה עצמה ע"י הטמעת טלאי (או עדכון גירסה) אינו מספק ואם יש למישהו מידע חשוב, יש צורך בלהנפיק תעודת SSL חדשה (Re-issue – זה לא עולה כסף). כל החברות שמוכרות תעודות SSL כבר פרסמו הוראות כיצד לבצע זאת.

עדיין, נקודה אחת שחלק גדול לא התייחס אליה הוא עניין ה-Clients. כן, הם גם צריכים עדכון גירסת SSL ואם הם מתחברים מבחוץ דרך https לאתרים שונים, גם הם צריכים עדכון. אפל הודיעה שהמערכות באייפון/אייפד אין להן את הבעיה, אבל אם אתם משתמשים ב-BBM (שרות ההודעות של BlackBerry) אז אתם כן צריכים עדכון (לאפליקציה, שכוללת מימוש OpenSSL משלה). בכל הקשור לאנדרואיד – הגירסה היחידה שכוללת את חור האבטחה היא 4.1.1 (מכשירים של סמסונג ישנים הכוללים אנדרואיד 4.1 כבר כוללים תיקון ל-OpenSSL והם עם אנדרואיד 4.1.2). לחברות פיתוח שמשתמשות בתחנות קצה מבוססות לינוקס (אובונטו, RHEL/CENTOS) – גם את התחנות יש לעדכן אם הן משתמשות בתקשורת החוצה (אחסון בענן, GIT או כל דבר אחר שעובר דרך https). לשם שינוי, הפעם תחנות ושרתים מבוססי Windows לא צריכים עדכון.

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

כמו תמיד, כשצץ לו חור אבטחה גדול, חובבי תיאוריות הקונספירציה מתועררים מריבצם. לא חשוב כמה הבחור שתרם את הקוד נשבע ביקר לו שזו היתה טעות שלו, תמיד יהיו אלו שיהיו בטוחים שהוא עשה את "הטעות" מטעם ה-NSA (שאגב, לפי בלומברג, כבר ידעה על החור כבר שנתיים וניצלה אותו. ה-NSA מכחישים כמובן) ואז כ-ו-ל-ם פתאום שואלים מדוע לא נעשה Code Auditing (בדיקת קוד) והתשובה לכך היא פשוטה: Code Auditing הוא תהליך יקר (תשאלו את הקבוצה שמפתחים את trucrypt), וזה שחברה תעשה בדיקה על קוד של OpenSSL ותכריז "לא מצאנו שום חורים" לא אומר שמישהו יסמוך על הבדיקה הזו (גם פה תמיד יגיע איזה מישהו וימצא שבן דוד של סמנכ"ל הכספים של אותה חברה נראה בפאב יושב במרחק 100 מטר מסתכל על החצאית של מישהי שעבדה ממזמן כמזכירה באיזה ארגון בטחוני ו"בטח יש משהו שם ואסור לסמוך על זה!!") ולכן יש צורך גם בכספים וגם בגוף ניטרלי.

עדכון 1: יובל סיני (ארכיטקט אבטחת מידע בבנק פועלים) מוסיף:

  •  ציודים עם פגיעות: F5 עם ממשקי ניהול כלפי העולם (כלומר הבעיה היא בממשק הניהול, ולא בכל המוצר).
  • Imperva 10.5
  • ב-OpenSSL ישנו חלק שנקרא Heartbeat – בגדול הסוגיה לא קשורה ל OpenSSL, אלא לשיטת עבודה של אפליקציות ב TCP.
  • בעייה דומה הייתה קיימת בעת עבודה עם mod-ssl, ולא כל הארגונים הטמיעו את הפאץ המתאים.

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

עדכון 3: אין שום קשר בין הפריצה הזו ל-SSH. חבילת OpenSSL אין צורך בה לשם הקמת שרת SSH או בשביל SSH Client, והמשכיות התקשורת הרציפה בין מכונות בחיבור SSH נעשית עם keepalive שיש לו קוד שונה לחלוטין מ-Heartbeat.

על איומי סייבר וסחטנות דיגיטלית

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

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

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

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

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

כל נסיון לפתוח את הקבצים הנ"ל יתן תמונה שבה מופיעה הודעה חגיגית כי הקבצים מוצפנים ועל מנת לשחרר אותם, יש לשלם סכום של 500$ בביטקוין ואת ההעברה יש לבצע דרך הרשת המוצפנת TOR. יש לך 48 שעות להעביר את הכסף. ניסית להתחכם ולהכניס קוד שגוי? התוכנה תקצץ לך כמה שעות מה-48 שעות. לא שילמת אחרי 48 שעות? הסכום מוכפל. לא שילמת אחרי חודש? המפתח ימחק ואתה תישאר עם קבצים שלא תוכל לפתוח.

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

… עד שמהנדס כלשהו בסימנטק החליט לגלות לכל העולם ואחותו בפוסט בבלוג של סימנטק שהמפתח נשאר במחשב וגם היכן הוא נמצא. גם אותה כנופיה קראה את הפוסט וב-1/4 הם שחררו גירסה מעודכנת של הנוזקה שמוחקת את המפתח. תודה לסימנטק!

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

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

  • כרגיל, אנטי וירוס יעיל יכול לעזור בעצירה של הנוזקה מלהיכנס אל המחשב שלך.
  • גיבוי – אם הינך מגבה לדיסק אחר שמחובר למחשב שלך או לתיקיה אחרת, זה לא מספיק. נוזקה כזו יודעת להיכנס גם לגיבוי כזה ולהשמיד אותו. לפיכך מומלץ לגבות לענן לשרות כמו DropBox או Google Drive שנותנים כמה ג'יגהבייט בחינם, אך הפתרון הכי טוב הוא גיבוי שאינו זמין כ"כונן" במחשב – פתרון כמו של Backblaze יכול להיות טוב למרות שהוא אינו חינמי (5$ לחודש ללא הגבלת מקום). כעקרון – גם גיבויים למקומות אחרים טובים, כל עוד השרות אינו ממופה כ"כונן".
  • קצת מחשבה – מכיר מי שלח לך? אם לא, אל תפתח. אתה סקרן ולא בטוח? שמור את הקובץ ואל תריץ, סרוק אותו באנטי וירוס שלך או בשרות החינמי Virus Total.
  • מאוד מומלץ לעבור משימוש מתוכנות מייל שמותקנות על המחשב למייל מבוסס רשת כמו GMail, Outlook.com, Yahoo Mail. שרותים אלו סורקים כל הצמדה ומונעים הורדה.
  • אם גיבוי – אז גיבוי מלא: ודא שלפחות אחת לחודש יש לך גיבוי של Full Backup ולא רק Incremental.
  • אם הנוזקה הזו דפקה את המחשב שלך, אל תשחזר מגיבויים לפני שהנוזקה מוסרת ממחשבך, אחרת גם השחזור יוצפן.

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

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 ברורים:

  1. אין צורך ברכישת מכונות רזרביות. בין אם אתה צריך מכונה אחת נוספת או 10,000, תוכל לבצע זאת מיידית.
  2. לא צריך שרות נוסף של Load Balancing שעולה כסף.
  3. אין צורך "לחמם" מכונות VM כדי שיהיו מוכנות להתחבר ל-Load Balancer.
  4. אין צורך בלהקים שרתי Apache או nginx עם כל ההגדרות שישמשו Front End, אתה פשוט יכול להקים סשן GAE בשפה שאתה רוצה (PHP לדוגמא) ולהרים בו את אתר ה-Front End שלך.
  5. לא צריך לשבור את הראש לגבי כתובות IP
  6. אתה יכול להקים אצלך בעבודה את ה-IMAGE שלך עם הלינוקס שאתה אוהב, עם כל ההגדרות שאתה צריך ואתה יכול להעלות את ה-IMAGE ולהשתמש בו.
  7. אתה יכול לבצע SSH ישירות לתוך כל מכונה מבלי להוסיף לה כתובת IP חיצונית ומבלי לזכור את כתובת ה-IP הזמנית שהמערכת מצמידה לה.
  8. אתה תמיד יכול לשנות את ה-VM, לבצע Snapshot ואז להגדיר ב-YAML שכשהמערכת מקימה מכונה חדשה, היא תשתמש ב-IMAGE (שנוצר מה-snapshot).
  9. אין יותר "ביצועים רנדומאליים". מכירים את זה שאתם מתחילים לעבוד על VM שרץ על ענן ופעם אותו VM רץ כמו שד ופעם אחרת זז כמו צב? פה אין את זה. גוגל מגדירים את השרתים לתת ביצועים באופן ליניארי, כך ש-VM אחד לא "חונק" VM שני.
  10. כן – אפשר גם להשתמש במכונת 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

בהצלחה