יעוץ VPS – עמוד 3 – הבלוג של חץ ביז

על אחסון וגדילה – חלק שני

בפוסט הקודם הסברתי בכלליות לגבי אחסון שקיים ב-Enterprise/Corporate ומהו ההבדל הכללי בין Scale Up ל-Scale Out. בפוסט זה אסביר יותר לגבי סוגי אחסון של Scale Out, פתרונות קניינים, קוד פתוח ועוד.

לפני שאתחיל להסביר לגבי Scale Out, אני רוצה לענות על שאלה שנשאלתי בכמה הזדמנויות: האם פתרון Scale Out מתאים לכולם או לרובם? האם זה יכול להחליף פתרון אחסון שיש כיום לרוב החברות?

התשובה אינה יכולה להסתכם ב"כן" או "לא". אם לדוגמא יש לך 10 שרתים פיזיים שמריצים נניח 100 מכונות VM ויש לך אחסון כלשהו (בין אם זה של Oracle, NetApp, EMC ואחרים) – אז התשובה היא "לא" – פתרון Scale Out לא יתאים לך מכיוון שמדובר בהגדלה והוספה של לפחות 4-5 שרתים פיזיים וערימות של דיסקים קשיחים מסוגים שונים. עלות של דבר כזה תעקוף בקלילות עלות של אחסון זהה למה שיש לך כיום כך שלא תרוויח מזה הרבה. במקרים כאלו אם אתה רוצה להחליף את האחסון הנוכחי באחסון מבוסס קוד פתוח לדוגמא – עדיף שתסתכל על פתרון מבוסס ZFS לדוגמא.

היכן זה כן יכול להתאים? במקומות שיש צורך בדברים כמו:

הרצה של אלפי מכונות וירטואליות מבוססות KVM או XEN (כמובן גם Open Stack)
מקומות שיש כמויות קבצים עצומות (עשרות מיליונים ומעלה) עם המון משתמשים שניגשים
חוות HPC
ארכיבאות ענקית
פתרונות Cold Storage (נתונים שהגישה אליהם היא נדירה אך כמות המידע היא ענקית ונמדדת ב-Petabytes, Exabytes ומעלה)
שידורים (Streaming)

תעשיות שצריכות פתרון Scale Out לדוגמא:

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

מה נותן לנו Scale Out? גישה שונה לאחסון/שימוש במידע. אין יותר שרת X שממנו אנו ניגשים לקבל את המידע. ליתר דיוק יש לנו "שרת X" אבל הוא לא ממש שרת, הוא משמש יותר כ-Gateway שמצוין על ידי שם host שעבורנו יהיה קל יותר לפנות, אך מה שחשוב לזכור הוא שאיננו פונים לשרת שמאחסן את הנתונים. אם יהיו לנו 100 שרתים פיזיים שמריצים את אותו פתרון אחסון שהוא בנוי ב-Scale Out, אין לנו צורך לפנות לאחד מהשרתים. ה-Gateway כבר יפנה למי שצריך.

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

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

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

פתרון מבוסס Ethernet – תוכל לבחור בין 10/25/40 ג'יגהביט
פתרון מבוסס Infiniband – עם פתרון זה גם תוכל להגיע ל-100 ג'יגהביט, אבל תצטרך להשקיע לא מעט במתגים וכרטיסים, ומתגים מנוהלים ב-Infiniband ממש אינם זולים.

באחסון הרגיל שאנו מכירים, אנחנו מחלקים את סוגי האחסון ל-2: קבצים ו"בלוקים" (לשם פוסט זה נקרא לזה פשוט LUN). מערכות אחסון סטנדרטיות שומרות את הקבצים ומאפשרות גישה אליהם דרך SMB/CIFS או NFS (יש כמובן שיטות נוספות אך לא אתייחס אליהן כרגע). ה"בלוקים" לעומת זאת בד"כ ייוצאו דרך האחסון לדברים כמו ESXi או Hyper-V (או כל פתרון וירטואליזציה אחר) דרך פרוטוקול iSCSI.

באחסון Scale Out לעומת זאת, יש 3 סוגים:

אחסון "תמונות" – מדובר באחסון קבצים סטטיים, קבצים שלא ישונו בשרת האחסון וההרשאות לגישה לקבצים הן קטנות ופשוטות. השם שקולע במדויק הוא שרות של אמזון – ה-S3 שלהם, זה בדיוק זה.
אחסון "בלוקים" – אחסון "שטחים" שמהם המערכת תייצא החוצה Block Device, בדיוק כמו שמערכת iSCSI מייצאת החוצה. אתה מתחבר ל-Block Device ומפרמט אותו לפי הצרכים שלך ב-Client. מבחינת מערכת האחסון עצמה, אין לה מושג ירוק מה תאכסן באותו בלוק, כך שאם תפרמט את זה ל-NTFS או VMFS או EXT4 או XFS – האחסון לא יהיה מודע לכך.
אחסון קבצים סטנדרטי – בדיוק כמו באחסון רגיל שאנחנו מכירים, כאן מתאחסנים קבצים עם גישה דרך CIFS/SMB או NFS וכו'.

מבחינת פתרונות Scale Out, ישנם פתרונות קנייניים מכל יצרניות האחסון, החל מ-EMC עם Isilon, דרך IBM עם XIV, ממשיכים ב-NetApp (סידרת FAS8000 ומעלה), ויש עוד כמה. האם הם טובים? כן, אם כי לכל אחד מהם יש חסרונות ויתרונות (בקשו מאנשי המכירות של IBM לדוגמא לשלוח לכם את המצגות הפנימיות שלהם על חסרונות של מוצרים מתחרים, תתפלאו כמה הם "חפרו" לעומק המוצרים האחרים כדי לגלות כל פיפס וכל פאק רציני בכל מיני עומסים) – אבל החסרון הגדול של כולם הוא המחיר. הוא מטורף וזה יכול להגיע למצבים שגם חברות מאוד מבוססות לא חותמות כל כך מהר על הזמנת הפתרון.

מהצד השני יש פתרונות קוד פתוח וכאן יש כמה שמות ידועים כמו: Luster, GlusterFS, iRods, HDFS. אלו פתרונות שידועים ונמצאים בשימוש בכל מיני מקומות גדולים עם שימוש מאסיבי. החסרון שלהם הוא בכך שאינך יכול לכתוב פקודת mkfs והאחסון יהיה מוכן, ותצטרך להשקיע זמן רציני כדי לתכנן ולהכין ולבדוק את המערכת אחסון לפני שתוכל ממש להשתמש בה, אך מצד שני ה-TCO יגרום להרבה מנהלים לחייך.

ויש את Ceph.

בעקרון, Ceph מכוונת להיות One Stop Solution אם אתה מחפש פתרון Scale Out. בזמן שפתרונות מבוססי קוד פתוח כמו Luster יכולים לתת לך פתרונות כמו Block Device, Images, FS – החסרון של Lustre זה שהכל עובר דרך שרת פיזי אחד, מה שאומר שתקבל "צוואר בקבוק" תוך זמן קצר, וכנ"ל גם iRODs עם אותה בעיה. אם נדבר על HDFS לדוגמא – הוא מעולה לאחסון קבצים אבל צוואר הבקבוק בו קשור ל-NameNode. לסיום Gluster לא מאפשר Block Device או FS (אם כי פונקציונאליות זו אפשרית עם plugins).

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

בחלק התחתון יש לנו את RADOS (ר"ת של Reliable, Autonomous, Distributed, Object Store) והוא החלק האחראי על אחסון הנתונים עצמם. מעליו יש לנו "גישות" שונות לנתונים:

גישת ה-APP, הגישה שמתאימה למפתחים: אתה יכול לגשת במספר שפות פיתווח שונות דרך ספריה שנקראית librados אל הקבצים (יש כמובן גם Authentication שלא כל אחד יוכל לגשת). זהו פתרון מעולה אם החברה מפתחת את הכל בעצמה או שהיא רוצה להתממשק עם ממשק משלה ל-Ceph.
גישת ה-RADOSGW – זו גישה שתואמת הן את S3 של אמזון והן ל-Swift של Open Stack, כך שאם יש לך קוד שניגש ל-S3, תצטרך שינויים מינוריים כדי לגשת לנתונים.
גישת RBD – בגישה זו אתה יכול ליצור ולקבל גישה אל Block Device, כאשר ה-Block Device הוא בעצם מורכב מאובייקטים שפזורים על פני ה-Nodes השונים באשכול Ceph. דרייברים קיימים כיום ללינוקס, ל-KVM ול-XEN, דרייבר ל-Hyper-V יצא בחודשים הקרובים ואחריו דרייבר ל-ESXi.
ניתן גם לחבר Block Device לשרת לינוקס אחר, ומאותו שרת לינוקס לייצא את הבלוק כ-iSCSI או לפרמט את הבלוק ולהגיש אותו דרך SAMBA או NFS (דרך Ganesha)
גישת Client – מאפשרת לך להשתמש ב-CephFS כשרת קבצים לכל דבר ועניין, כאשר ה-FS יכול להיות XFS, BTRFS או EXT4. הלינוקס קרנל תומך בכך עוד מגירסאות 2.6.32 ומעלה.

אחד הדברים שצריך להפנים עם Ceph (וחלק מהפתרונות Scale Out שמבוססים בקוד פתוח) הוא שאין צורך ב-RAID יותר. אתה יכול להשתמש כמובן ב-RAID איזה שתרצה אבל אתה פשוט תפחית ביצועים למערכת כי היא בנויה מההתחלה להפיץ את החלקים השונים בין ה-Nodes. יש מקרים ש-RAID כן יכול לסייע לך כמו RAID-0 לשם Cache בין מספר כונני SSD. (כן, RAID-0 הוא לא לשם שרידות, אבל בין כה Cache אינו שורד).

Ceph, כמו ZFS, מפריד בין ה-Data ל-MetaData. כך לדוגמא אם יש לי תמונת נוף, אז התמונה עצמה היא ה-DATA אולם שם הקובץ, הרשאות גישה, היכן הוא מאוחסן ועוד פרמטרים – הם Meta Data והם נשמרים ב-Journal, רק שבניגוד למערכת לינוקס רגילה, מומלץ את ה-Journal לשמור על פרטישן בכונן SSD להאצת ביצועים (בדיוק כמו ב-ZFS את ה-SLOG מומלץ לשמור על SSD). בניגוד ל-ZFS שכותב קודם כל את ה-Meta Data והטרנזאקציה עצמה ל-SLOG ובכך מונע בעיה שבמקרה של הפסקת חשמל יאבדו הנתונים – עם Ceph מומלץ שבקר הדיסקים שלך יהיה עם סוללת גיבוי.

הגישה לדיסקים ב-Ceph נעשית ע"י Daemon מיוחד שנקרא OSD (או Object Store Daemon), זהו תהליך שרץ על כל דיסק. בעקרון, Ceph מפרמט כל דיסק שמוכנס אליו בברירת המחדל ל-XFS (אך אפשר להגדיר זאת ל-EXT4 או BTRFS) כפי שתוכלו לראות בתמונה הבאה:

osd

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

nodes

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

mds

אחד הדברים ש-Ceph אימץ מתוך NFS-4 הוא רעיון ה-MDS (כלומר MetaData Server). גם הוא, כמו Monitor, רץ רק מספר קטן של פעמים (ולא בכל ה-Nodes), ותפקידו הוא בעצם להצביע היכן נמצאים האובייקטים ומה צריך להגיע ל-Clients. הוא לא מעביר את הקבצים עצמם ל-Clients כך שהוא תמיד פנוי לקבל פניות כדי להצביע היכן נמצאים קבצים. אם משתמשים ב-Ceph ולא משתמשים ב-CephFS אז אין צורך ב-MDS.

איך Ceph כותב קבצים אם הם מחולקים ל-Nodes שונים? ב-Ceph יש מושג שנקרא CRUSH (ר"ת Controlled, Scalable, Decentralized Placement of Replicated Data). הנה תמונה שמבהירה מעט יותר:

crush

אז CRUSH הוא אלגוריתם שלוקח בחשבון כל מיני פרמטרים ובהתאם – מאחסן חלקים של הקובץ בצוורה שווה בין ה-Nodes ב-Cluster. הוא עושה את החישוב בצורה מאוד מהירה. CRUSH (בסיוע ה-Monitor ו-OSD) יודע גם לטפל בבעיה אם נופל שרת או דיסק, הוא ידע מהיכן לקחת את הנתונים ולהיכן לשכפל.

נקודה חשובה שיש ל-Ceph זה שכל ה-Block Devices שהוא יוצר הם Thin Provisioned, כך שאם יש לך מאסטר אחד וממנו אתה רוצה להרים כמה מאות או אלפי VM ומהר, תוכל לעשות זאת ללא צורך בעשרות ומאות שכפולים. רק ה-Delta של השינויים עצמם יכתבו. כנ"ל לגבי Snapshots – ניתן ליצור Snapshots ו-Incremental Snapshots (כן, כמו ZFS). בכל הקשור לכתיבה, גם כאן, כמו ZFS, מערכת Ceph מבצעת Copy on Write, וכן, כמו ב-ZFS גם ב-Ceph יש Scrub (לבדיקת שלמות הנתונים על הדיסקים).

מכיוון ש-Ceph תהיה ממומשת במערכים גדולים של מאות ואלפי דיסקים, ישנה בעיה של מהירות כתיבה. אחרי הכל, אף גוף שפוי (אוקיי, רובם..) לא יסכים להכניס רק SSD, צריכים שתהיה גישה מהירה יותר וכאן Ceph שוב מעתיק מ-ZFS, רק שהוא לוקח את זה 10 צעדים קדימה ומאפשר לך דבר שנקרא Cache Tier. אתה יכול להגדיר לכל Pool היכן תשתמש בדיסקים מהירים (כמו SSD) לכתיבה מהירה, היכן הכתיבה תהיה איטית ועוד. תוכלו לקרוא על כך בהרחבה כאן.

כפי שאתם יכולים לנחש, Ceph זו חתיכת מערכת אחסון שמנסה לענות על כל הצרכים לחברות שצריכות אחסונים שונים ובצורות שונות. היא יכולה להחליף לדוגמא אחסון של Hadoop, אם החברה מריצה Open Stack אז היא יכולה לתת פתרון גם ל-Object Storage וגם Block לשרתים הוירטואליים, וגם לתת שרותי FS (אם כי כדאי לזכור שהחלק הזה עדיין בשלבי QA).

עד כאן הכל טוב ויפה, אבל אני מניח ש-3 שאלות צצות למנהלי תחומי IT:

האם יש GUI לכל הדבר הזה? התשובה, גם כאן, אינה בדיוק פשוטה. כן, יש GUI שיועד יותר לסטטיסטיקות (ונקרא Calamari), כמו מה מצב ה-IOPS שלך, כמה השתמשת והיכן, פילוחים שונים, מצבי דיסקים ועוד. לא, אם צריך לעשות תחזוקה לדברים – צריכים את זה לבצע דרך ה-Shell בלינוקס. וידאו של אותו GUI בסוף פוסט זה.
מי החברה שעומדת מאחורי זה? מי נותן תמיכה? (טוב נו, חוץ מהעסק שלי 🙂 ) – התשובה היא שרד-האט מוכרת כיום את Ceph ו-רד-האט ישראל משתתפת בפיתוח Ceph. (ד"ש חם ליהודה שדה מ-רד-האט ישראל).
מה עם תמיכה מלאה ב-Hyper-V ו-ESXi? בחודשים הקרובים תהיה תמיכה מלאה ל-2 המוצרים.

ולסיום, וידאו הכולל הדגמה של Ceph וה-GUI:

עתיד אמצעי אחסון ב-Enterprise

[stextbox id="info" caption="הערה"]מאמר זה מדבר על הדיסקים/כוננים המשמשים לאחסון ולא על פתרונות כמו NAS/SAN וכו'.[/stextbox]

מבחינת דיסקים/כוננים קשיחים, אנחנו נמצאים בתקופה מאוד מעניינת. ב-15 שנים האחרונות היו שינויים בתחום זה, אך לא שינויים כה מהותיים. רוב החברות בעשור האחרון השתמשו בכונני SAS (ולפני כן SCSI לגרסאותיו) בשרתים, וההתקדמות בכל הקשור לתחום הכוננים המגנטיים – היתה מועטה. היתה קפיצת מהירות סיבוב לדקה מ-10K ל-15K, היו הכפלות כמות אחסון (144G ל-300G ברוטו, 300 ל-600 ומשם ל-900) ופה ושם ראינו גם "נגיעות" של יצרניות הדיסקים בהטמעת פתרון Cache קטן כלשהו בדיסקים.

מבחינת כוננים מבוססי טכנולוגיית Flash, ראינו התפתחות ממצב של "1 ביט בתא" (SLC) ל-2 ביטים ויותר בתא (MLC) (היתה גם קפיצה ל-TLC – של 3 ביטים בתא, אולם הם היו מיועדים לשימוש ביתי/דסקטופ) וגם קומבינציות שיותר מתאימות ל-Corporate כמו eMLC, ואפשר לקרוא על כך בקצרה כאן.

אחד הדברים שחברות רצו בכל הקשור לדיסקים מגנטיים – היו גדלים יותר רציניים. זה נחמד שיש גדלים כמו 150 או 300 ג'יגה, אבל במחשב שלך יושב לו בנחת דיסק של 2-4 טרהבייט. הוא בהחלט לא מתאים ל-Enterprise והיצרניות החלו לקבל שאלות לגבי דיסקים גדולים ב-Enterprise. מכיוון שאי אפשר להכניס פלטות כמו שיש דיסקים של דסקטופ ל-Enterprise SAS ולהאיץ את מהירות הסביבוב ל-15K, הגו היצרניות סטנדרט חדש שנקרא Nearline Storage SAS ובקיצור: NL-SAS.

מהו NL-SAS? אלו דיסקים SATA שמיוצרים בטכנולוגיה שונה במעט מטכנולוגיית הדיסקים לדסקטופ, אך הבקר שיש לאותו דיסק הוא בקר SAS, כך שדברים כמו Command Queue, ערוץ תעבורה כפול ועוד יתרונות שיש ל-SAS – קיימים לדיסקים הללו, אך האמינות שלהם אינה כמו האמינות של דיסקים SAS "אמיתיים" (תוכלו לקרוא על כך יותר כאן). אז נכון, יש פחות אמינות מבחינת שגיאות כתיבה וטיפול בהן בהשוואה ל-SAS, ואין מהירות של 15K סיבובים לשניה (יש דיסקים SATA עם מהירות 10K, אגב, והם יקרים), אבל מצד שני – יש הרבה יותר שטח אחסון בדיסק.

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

טכנולוגיות ה-SSD הלכו והתפתחו יותר ויותר. מהירות ה-SAS (של 6 ג'יגהביט בשניה) נהפכה לצוואר בקבוק ואז הגיעה טכנולוגיית ה-SAS במהירות 12 ג'יגהביט. אם היינו חיים בעולם של דיסקים מגנטיים בלבד, הסטנדרט הזה היה נשאר למספר שנים, אך הסטנדרט הנ"ל לא מחזיק מעמד והיצרנים החלו לפנות לפתרון אחר: ערוץ ה-PCIe X4 (ברוב המקרים הכרטיס הוא בחיבור פיזי של PCIe X8 שהוא יותר סטנדרטי) והכונן כפי שהכרנו אותו הפך לכרטיס PCIe ומכיוון שהחיבור ב-PCIe הוא הרבה יותר מהיר מ-SAS (עם Latency מאוד נמוך), מהירות הכתיבה והקריאה זינקה בפראות למהירויות בג'יגהבייטים, אך אז צצה בעיה אחרת: כמה כרטיסים אתה יכול להכניס בשרת 1U? אולי 2 במקרה הטוב, ואולי 3-4 בשרתי 2U.

NVM_Express_logo היה צריך פתרון אחר והוא הגיע. הפתרון הוא NVME. טכנולוגיית ה-NVMe בעצם "מורידה" את הפתרון מהצורך ב-Slot פיזי של PCIe ומעבירה אותו בחיבור חוטי על בקר MVNe שיושב בכונן עצמו.

Samsung-XS1715-1.6GB-NVMe-SSD-Connector כך נראה חיבור NVMe (בתמונה מימין) בכונן של סמסונג בדגם XS1715. כפי שאתם יכולים לראות, מדובר בחיבור שונה לחלוטין מ-SAS או SATA. זהו חיבור בסטנדרט חדש שנקרא SFF-8639 (הוא דומה מאוד לחיבור SFF-8482). היתרונות של חיבור כזה הוא שהוא תואם אחורה ל-SAS ול-SATA והוא משתמש בכל הפינים ה"מיותרים" למימוש חיבור PCIe. (כמובן שיש צורך בכך שלוח האם ידע לתמוך בחיבור SFF-8639). חיבור זה, בשלב זה, יודע לתמוך רק בכונני SSD בתצורה של 2.5 אינטש בעובי 15 מ"מ.

הבה נסתכל על המפרט של ה-XS1715. זהו כונן שמתחרה בדגמים ל-Enterprise כמו של אינטל P3700 או כונן אחר של חברת Micron. להלן הטבלה:

SamsungXS1715-Specs

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

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

סמסונג היתה הראשונה להציג כונן עם נתונים מטורפים כאלו, אך המתחרים לא נמצאים מאחור. אינטל תכריז כבר בקרוב על סידרה P3800 (השמועות מדברות כבר על סידרה P4XXX עם שינויים רציניים וכפי הנראה שגם אינטל תרד מגירסת הכרטיסים) שתתן את אותם ביצועים כמו של סמסונג. סאנדיסק ומיקרון גם יוציאו מוצרים עם IOPS פחות או יותר באותה רמה במחצית השניה של השנה ובינתיים מדברים על כך שלקראת סוף השנה נתחיל לראות כוננים בטכנולוגיית NVMe עם IOPS של 7 ספרות. כל הכוננים הנ"ל מגיעים עם כמות אחסון החל מ-300 ג'יגהבייט ועד 3.2 טרהבייט, וזה עוד לפני שאותן חברות מתחילות להכניס את טכנולוגיית יצור צ'יפים בתלת מימד (שכבה על שכבה, סמסונג משווקת כיום לדוגמא את ה-Pro 850 שמיועד לשימוש Semi Enterprise/Workstation ב-32 שכבות, [גירסא הבאה תהיה כבר לפי השמועות – 128 שכבות] מה שיתן גם ביצועים יותר טובים מכונני SSD מבוססים SLC, וגם אין צורך בליטוגרפיה כה נמוכה – מה שסמסונג משתמשת זה 40 ננומטר)

כך שהמירוץ – בעיצומו, ועוד לא דיברנו על פתרון יותר מדהים – פתרונות SSD שיושבים על .. תושבות הזכרון בשרת. (שוב – Latency הרבה יותר נמוך מ-NVMe של משהו כמו 2-3 ננו-שניות).

אז לאן אנחנו מתקדמים בעצם? לפיצול.

מבחינת עלויות/אחסון – כוננים מגנטיים מבוססי SAS במהירות 10-15K סיבובים לשניה יופסקו להיות מיוצרים במהלך השנים הקרובות (לא השנה או השנה הבאה כמובן) מכיוון שלטכנולוגיה הזו אין ממש המשך. אפשר להאריך לה את החיים באופן מלאכותי בכך שהיצרנים יטמיעו Cache יותר גדול, אך בעידן שחברות רוצות שטחי אחסון יותר ויותר גדולים, ה-NL-SAS וגם כונני SATA יתפסו יותר מקום כשמדובר על אחסון שלא מצריך IOPS מטורף (לוגים, ארכיבאות, גיבויים, וידאו בזרימה). כיום המחיר להרים Cluster לצורך אחסון יורד כל הזמן וישנן מספר מערכות בקוד פתוח (וגם קנייניות כמובן) המאפשרות לך לקבל ביצועים טובים במחיר די זול תוך שילוב כונני SSD להאצת גישה, מהם תוכל לייצא החוצה iSCSI או NFS או SMB לשימושי החברה.

מבחינת עלויות/ביצועים (כן, IOPS) התחרות עושה את שלה ולחברות/יצרני Storage יש מגוון אפשרויות חדשות לבנות מערכות שנותנות IOPS גבוה בהתאם לתקציב של הלקוח, החל מ-SAS, המשך ב-NVMe ועד ULLtraDimm, ורובן יאפשרו ללקוח לשלב מודולים שונים כך שאפשר תמיד לגדול ולקבל IOPS יותר גבוה. שילוב טכנולוגיית התלת מימד ביצור רכיבי Flash מוזילה משמעותית את עלות היצור וכמות הצ'יפים שיש צורך בכונן SSD כזה, ואני משער שכבר ב-3 השנים הקרובות נתחיל לראות תחרות רצינית שתתן גם לחברות הקטנות פתרונות IOPS מכובדים.

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

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

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

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

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

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

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

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

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

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

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

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

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

ZFS בהשוואה ל-File Systems אחרים בלינוקס

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

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

בלינוקס כשאתה מכניס דיסק קשיח חדש (בין אם זה ב-Hot Swap או דיסק שהכנסת ואז הפעלת את המחשב) המערכת תכיר אותו מיידית, אבל לא תוכל להשתמש בו מיידית עם ה-File Systems הנוכחיים שקיימים בלינוקס. אתה קודם כל צריך ליצור Partition אחד או יותר (לפי הצורך), או שאתה יכול לשייך את הדיסק למערך RAID כלשהו (אם אתה משתמש במערכת MD). אם אתה משתמש ב-RAID חומרה, תוכל להיכנס למערכת הניהול הפנימית (בין אם זה בהפעלה מחדש וכניסה ל-GUI הבסיסי) או דרך Client שונים שיודעים להתממשק לבקר ה-RAID. מעבר לכך, אם בדיסק קיימים Partitions ואתה מוסיף או מוריד אחד מהם, תצטרך לעשות Reboot על מנת שהמערכת תכיר בשינוי (לפי רד-האט, אין צורך לעשות reboot אם הדיסק הוא ללא Partitions ואתה מוסיף אותם עתה. לשם כך יש את פקודת partprobe).

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

נניח ויש לי מערכת לינוקס שמשתמשת ב-LVM כך ש-use לדוגמא נמצא את Logical Volume אחד, ו-home נמצא על Logical Volume אחר. שניהם נמצאים באותו Volume Group. נניח שמחיצת ה-usr שלי התמלאה אך אני בקושי משתמש במחיצת home ויש שם הרבה מקום. ל-LVM יש פקודות הגדלה והקטנה אולם אינני יכול לשנות ווליום שהוא בסטטוס mounted. אני יכול לבצע unmount ל-home (אם אני אבצע כניסה כ-root מבלי שיהיה לי משתמש פתוח שמשתמש במחיצת home) אבל אינני יכול לבצע unmount ל-usr מכיוון שישנם שרותים שרצים ומשתמשים בו. הדרך היחידה שאוכל לשנות את גודל הווליומים הלוגיים, היא דרך הפעלה מחדש של המערכת עם Live CD כלשהו, לבצע vgchange כדי שיכיר בווליומים ואז לבצע את השינוי ולאחריו שוב reboot כדי שהשינוי יכנס לתוקף ואוכל להשתמש במערכת.

מבחינת File Systems המצב יחסית די טוב בלינוקס. מערכת XFS ו-EXT4 הן טובות ויודעות (בד"כ) להתאושש במקרה שעשו כיבוי והפעלה (או reset) לשרת. אם יש לך קרנל מגירסה 3.7 ומעלה, ויש לך כונני SSD אז ישנה תמיכה ל-TRIM בכל מערכות הקבצים המוכרות כמו ext4, xfs, btrfs, jfs ואפילו ל-vfat, כך שאורך חיי הכוננים ישאר די ארוך(יחסית).

מכיוון שישנה הפרדה בין File System למה שרץ מתחת (Volume Management, Partitions table), כמעט כל מערכות File systems שקיימות כיום ללינוקס, אינן מתערכות בשכבות מתחת. כך לדוגמא אם אתה מעוניין לבצע snapshots (מומלץ לבצע לפני שדרוגים), תצטרך לפנות ל-LVM (כמובן, אם החלטת להקים מערכת לינוקס בלי LVM, לא תוכל לבצע snapshots אלא אם מדובר במערכת וירטואלית ואז תוכל לבצע snapshot ברמת ה-Hypervisor). המערכת היחידה שכלולה ב-kernel שכן מאפשרת לבצע snapshots היא btrfs.

לינוקס בד"כ רץ על כל מיני חומרות, ואני מעוניין להתייחס ל-2 הקטגוריות העיקריות שבהם משתמשים בלינוקס: תחנות עבודה/Desktop ושרתים ושימוש ב-ZFS כמערכת חלופית למערכות File Systems שמגיעות עם הקרנל.

מבחינת תחנות עבודה – כל עוד יש לך דיסק קשיח יחיד, אתה לא תקבל ביצועים טובים ב-ZFS. גם אם יש לך 2 כוננים לא תקבל ביצועים טובים (בהשוואה ל-xfs, ext4) אלא אם יש לך כונן נוסף מבוסס SSD (גם כונן קטן של כמה עשרות ג'יגה יכול להספיק). למערכת ZFS יש הרבה דברים שהיא מבצעת שמערכות File Systems אחרות לא מבצעות. כך לדוגמא ZFS משתמש ב-checksum על כל פיפס של מידע ומערכות אחרות (למעט btrfs ו-xfs עם קרנל 3.10 וגם זה נמצא ב-experimental). בנוסף, ל-ZFS יש גם תהליכים של "קרצוף" שלא ממש נמצאים ב-file systems אחרים (שוב, למעט btrfs שתיכף אתייחס אליו בנפרד).

מבחינת שרת לעומת זאת, ZFS עוזר יותר מכל file systems אחרים שקיימים ללינוקס (שוב, btrfs יקבל יחס בנפרד). קודם כל, הוא מוזיל עלויות מבחינת חומרה – אתה כבר לא צריך RAID יקר עם סוללת גיבוי, כי ZFS דורש מצב פעילות JBOD, הוא יעשה הכל והוא הוא נותן הרבה יותר יתרונות (הסתכלו בפוסט הראשון – לינק למעלה). רוצה להוסיף דיסקים? זרוק לתוך השרת עוד כמה דיסקים וצור RAIDZ חדש, כל המחיצות על ה-pool יקבלו את המקום ואתה לא תצטרך להילחם ב-LVM (כי אין LVM ב-ZFS). רוצה להחליף דיסקים של 1 טרה ב-2/3/4/6 טרהבייט? (לא דיסקים מבוססים SMR החדשים והזולים!!!) תכניס אחד, תן למערכת לטפל בו, אחרי זה תכניס שני וכו'. אתה גם לא חייב להשתמש בדיסקים גדולים מבוססי SSD בלבד או דיסקים SAS יקרים – אתה יכול להכניס דיסקים מבוססי SATA (כל עוד יש לך לפחות 2 דיסקים קטנים מבוססי SSD כדי לקבל ביצועים) או שאתה יכול להכניס דיסקים SAS ו-SSD. אתה לא מוגבל. (רק כדאי לשים לב שהספק שאתם קונים ממנו את הדיסקים, אינו ספק שרוצה "בדיקות מעבדה" לדיסק תקול לפני שהוא מחליף, לצערי ראיתי מקרה כזה לפני חודש). יחד עם זאת, אם אותו שרת מבצע פעילויות אחרות (הוא שרת DB, שרת אפליקציות או דברים יעודיים וכבדים אחרים חוץ משרותי קבצים) ואין לכם תקציב לשרת קבצים עצמאי – עדיף להשתמש ב-file systems הקיימים בקרנל וב-RAID חומרה. זיכרו – ZFS הוא הרבה יותר מסתם עוד file system.

לגבי btrfs: אורקל, ב"גאונותה" הגדולה, החליטה החלטה שנראה כאילו היא נלקחה מסידרת הקומיקס Dilbert: יש להם את הקוד של ZFS אז במקום לפתוח אותו ולהמשיך לפתח אותו כדי שהוא יכנס לקרנל של לינוקס, הם החליטו שהם יוצרים משהו חדש – את btrfs. הרעיון מאחורי btrfs הוא רעיון טוב בעקרון – לעשות מה ש-ZFS עושה אבל עם תוספות. כך לדוגמא ב-ZFS יש Quota, ב-btrfs לקחו את זה צעד קדימה ויש גם Quota Groups, דבר יעיל מאוד שיש לך כמה מאות משתמשים בקבוצות שונות ואתה רוצה להגדיר לכל קבוצה Quota בפקודה פשוטה אחת, או פונקציה נחמדה אחרת של snaphots – ב-ZFS הם read only, ב-btrfs אפשר ליצור snapshots שהם read-write ויש עוד פונקציות נחמדות רבות (templates וכו').

אבל הבעיה המרכזית של btrfs היא שזו מערכת שהיא עדיין בשלב של "נסיוני" (experimental). פונקציות חדשות עדיין מתווספות (בקרנל 3.19 האחרון שיצא לדוגמא – התווסף האפשרות לבצע scrub למערכי RAID והחלפת מערכות RAID. על הפוקנציה הראשונה אני עדיין חוכך את פדחתי להבין מדוע צריך אותה – אם scrub אז שיעשה להכל, ולגבי הפונקציה השניה – זה בהחלט טוב בהשוואה ל-ZFS). שום הפצה (טוב, למעט Open SuSE) לא מאפשרת הקמת שרת/Desktop עם btrfs כמערכת ברירת מחדל וכל ההפצות כותבות בפירוש ליד השם btrfs שזה experimental, כך שאם אתה מרים שרת עם btrfs, וזה שרת פרודקשן, תתפלל שזה יהיה יציב ועדיף שתכיר ממש טוב את btrfs ובמיוחד את btrfs-rescue. במקרה כזה אם החלטת ללכת "על הקצה", עדיף שההפצת לינוקס עצמה תהיה מותקנת ב-xfs ושאר התכנים יהיו ב-btrfs, כך לפחות תוכל לעבוד עם הלינוקס עצמו ללא צורך ב-live CD כלשהו.

אם אתם רוצים להשתמש ב-btrfs כמערכת file system מרכזית על דסקטופ/לאפטופ שלכם, אני ממליץ בחום להשתמש בהפצת לינוקס שהיא Rolling Release (כמו Open SuSE), כך לפחות תקבלו גירסאות core-utils יותר מעודכנות וגרסאות קרנל חדשות עם תיקוני באגים ל-btrfs.

בשביל ש-btrfs יהיה טוב לשרתים, יצטרכו קודם כל באורקל לבצע feature freeze עם הקוד (מה שעדיין לא קורה, תסתכלו בחדשות wiki של btrfs) ואז להתחיל לטפל בבאגים (ויש באגים מסמרי שיער! rsync כבד עם קרנל שהוא פחות מ-3.16 גורם ל-deadlock עם btrfs, ויש עוד כמה Gotchas למיניהם, ונכון לאתמול – יש גם memory leaks, הידד!) ואז יצטרכו המון טסטים כדי שזה יעבוד בצורה ממש יציבה, וכאן מדובר על טסטים הרבה יותר מורכבים ממה שהיה ל-ext3/ext4/xfs כי כמו ZFS, גם btrfs היא לא רק מערכת file-system. אני מאמין שזה יקח בין שנה לשנתיים.

עוד מערכת קבצים שלא כל כך התייחסתי אליה אבל כדאי להכיר אותה (במיוחד לדסקטופ/לאפטופ עם כונני SSD) היא מערכת F2FS שסמסונג פיתחה וכיום מפותחת גם ע"י אחרים. היא לא מתאימה לשרתים והיא עדיין נסיונית, אבל מצד שני יש לה ביצועים לא רעים בכלל ופונקציונאליות בהחלט מעניינת (כמו rollback ו-fitrim), תוכלו לראות Benchmarks בהשוואה לאחרים כאן.

ועוד משהו קטן שדווקא לא קשור ללינוקס אלא למתחרים – למיקרוסופט. גם הם ראו את ZFS ו-btrfs וגם להם יש תשובה (אם כי לא מומלץ לאיש סיסטם Windows להשתמש כרגע בפתרון הנ"ל אלא אם הוא מעוניין בפיטורין..) – וזה ה-ReFS, אם כי בהשוואה ל-btrfs ו-ZFS, חסרים לה פונקציות כמו דחיסה, Deduplication, COW.

אסכם את הדברים כך: לכל file system יש יתרונות וחסרונות. אני ממליץ לשקול את כל האפשרויות שזה מגיע לשרתי קבצים בפרודקשן, במיוחד כשזה מגיע לעניין של ברזלים ותקציבים וגם השיקול הקטן של לילות לבנים כשחטפתם deadlock או כל תקלה אחרת. קחו בחשבון גם שיקולים (שלצערי חלק מהאנשים שוכחים) כמו מה אתם הולכים לאחסן (אם לדוגמא יש לכם תיקיה עם כמה מאות אלפי או מיליוני קבצים, ללכת על ext4 לדוגמא זה רעיון גרוע), מה היעוד של מערכת הקבצים ומול מה היא מתחברת, האם יש דברים כמו thin provisioning קל לביצוע, האם המערכת יודעת לדאוג ולטפל בדיסקים, האם ההגדלה שלה כרוכה בהשבתות או שניתן לבצע דברים Online, האם קל לגבות מערכת חיה, ועוד דברים.

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

אחסון על NAS במחיר זול מאוד

לפני מספר ימים ראיתי שאלה בפורום IT של תפוז לגבי מחירי NAS ואיזה פתרון NAS יתאים לבית.

בבלוג האישי שלי בקטגוריית My-Lab אני כותב פוסטים על בניית NAS לצרכים רציניים, כאשר יש לך בבית 2-3 שרתים פיזיים (שהם PC עם הרבה זכרון וכמות גדולה של דיסקים) ואתה מריץ כמה וכמה מכונות וירטואליות, מה שרוב האנשים כלל לא צריכים.

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

אתחיל בפתרונות ה-NAS הקיימים היום למכירה: הפתרונות הללו יכולים להיות פתרונות טובים, אך הבעיה איתם היא שאתה "נעול" לספק מסוים עם תוכנה מסויימת שהוא מספק לך. סביר להניח שיש לו ממשק מבוסס Web ידידותי נחמד וקל לתפעול, אבל הבעיה המרכזית היא שספקי NAS במקרים רבים "נוטשים" את המוצר אחרי שנתיים פלוס, כך שעדכונים לגירסאות יותר מתקדמות לא תוכל לקבל ועדכוני אבטחה – מגיעים באיחור אם בכלל. במקרים רבים אתה לא יכול גם להחליף את התוכנה אלא אם יש לך ידע מעולה בלינוקס (או FreeBSD), אתה מכיר File Systems של מערכות יוניקס וכמובן – אתה מכיר הגדרות לעומק של שרותים שונים. בלי הידע הזה – אין לך הרבה לאן לזוז..

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

נתחיל במחשב:

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

הדבר שמצא חן בעיניי הוא דווקא הלוח-אם של ASRock. מנסיוני הלוחות שלהם כיום הרבה יותר איכותיים מבעבר, ולוח זה יכול לקבל מעבדים עד Xeon E3 מבוסס Haswell בלי בעיה. רק לוודא שיש לך גירסת UEFI אחרונה על המחשב ואתה יכול להחליף מעבד.

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

סה"כ מחיר למחשב: 992 שקל כולל מע"מ.

השלב הבא הוא זכרון. אנחנו לא צריכים הרבה אבל כדאי שיהיה 8 ג'יגהבייט זכרון. מחיר של 2 מקלות DDR3-1333 שכל אחד מהם 4 ג'יגהבייט יעלה לנו 199 שקל ב-KSP, כך שהמחיר ל-8 ג'יגה זכרון יהיה 398 שקל.

עכשיו מגיע החלק החשוב: דיסקים. בעקרון בבית כשהשרת קבצים משמש רק לאחסן תכנים דיגיטליים כמו סרטים, מוסיקה, אחסון ארכיב של גיבויים וכו', אין צורך בדברים כמו RAID-5. מה שכן נשתמש בו לשרידות מבחינת דיסקים הוא Mirror כך שהכל ישמר אוטומטית על 2 דיסקים, כך שאם נדפק דיסק אחד, השני ימשיך לעבוד.

שוב נסתכל ב-ZAP ונראה שם את Western Digital סידרה RED בגודל 2 טרהבייט וגם כאן חברת speed4u מוכרת אותו במחיר הכי זול של 504 שקלים. אנחנו צריכים 2 דיסקים, כך שהמחיר יוצא: 1008 שקלים.

עוד חלק קטן שהוא אופציונאלי הוא דיסק און קי קטן לשמור בו את מערכת ההפעלה (אם אנחנו נשתמש ב- FreeNAS). דיסק און קי בגודל 8 ג'יגהבייט יעלה לנו ב-KSP מחיר של 18 שקלים

סה"כ עלות סופית של הכל: 2416 שקל כולל מע"מ.

אחרי שרכשנו את הכל והרכבנו, מגיע החלק של התקנת מערכת הפעלה, וכאן יש לנו הרבה אפשרויות, נתרכז ב-2 אפשרויות:

אם אתם מחפשים ממשק מבוסס Web קל לתפעול ונותן שיתוף מחיצות, שרות Time Machine (לבעלי ה-MAC) או מקום אחסון לגיבויים יומיים – אז אתם יכולים להשתמש בתוכנת FreeNAS שמבוססת על FreeBSD ומערכת ה-File System שלה היא ZFS ויש לה המון מדריכים ברשת כיצד להגדיר אותה. השדרוגים הם בחינם ותמיד תוכלו לשדרג לגירסה האחרונה, גם אם זה יהיה עוד 3 שנים.
יתרון גדול של ה-FreeNAS הוא שכשהמערכת עולה, המערכת עולה ל-RAM כך שלא משנה ממש איזה דיסק און קי תשתמשו בו, הכל ירוץ בסוף מה-RAM.
אם אתם מכירים לינוקס טוב, אז אתם יכולים להתקין כל הפצה (שמוגדרת ל-Server) ולהשתמש במגוון כלים כדי להגדיר שיתופי שרותים שונים עם מחשבים אחרים בביתכם. מומלץ לכם להתקין את הלינוקס על אותו דיסק של 500 ג'יגהבייט, ואני ממליץ לכתוב סקריפט פשוט לבצע גיבוי של חומרים חשובים מה-MIRROR אל הדיסק הקטן.

ישנן כמובן אפשרויות נוספות כמו NAS4FREE (שהוא מעין "פיצול" של FreeNAS בגירסה מוקדמת), OpenFiler ויש גם את Nexenta (שיותר מיועדת לאנשים שיש להם נסיון עם ZFS וסולאריס) וכמובן יש את UnRAID שמאפשר לך להרכיב דיסקים בגדלים שונים ולקבל את מקסימום מקום פנוי (בניגוד ל-RAID קלאסי).

מבחינת File System אני ממליץ להשתמש ב-ZFS (מה ש-FreeNAS משתמשת) מכיוון שהיא נותנת אפשרויות לבצע snapshot לפני שינויים, אפשר (ומומלץ מאוד) לבצע איתה Scrub כדי לבדוק אם הדיסקים נמצאים במצב כשיר (פעולת ה-Scrub היא בדיקה של כל הקבצים והתגיות הפנימיים על מנת לוודא שכל הנתונים זמינים ואם לא, המערכת תשתמש במקום פנוי ותוודא שהקובץ זמין ותקין), אך גם מערכות File Systems אחרות כמו EXT4 או XFS הן אמינות לשימוש הביתי מבלי שצריך לעבור קורס מיוחד איך לטפל ב-File System.

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

בהצלחה 🙂

בוקר שחור: TrueCrypt

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

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

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

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

כשבודקים את המפתחות שנחתמו איתם קבצי ה-Installer ל-Windows לדוגמא, מוצאים כי גירסת ה-EXE האחרונה ששוחררה לפני יומיים בלבד משתמשת באותו מפתח שאיתו נחתמה הגירסה מינואר. בדיקת WHOIS ובדיקת DNS מראה כי אין שינויים שבוצעו לאחרונה כך שעניין ההתפרקות הוא אותנטי. בבלוג Kerb On Security כותב הבלוג שופך אור יותר על העניין כולל ראיון קצרצר עם מי שעדיין בודק את הקוד לאחר שאנשים תרמו כסף לקמפיין לבדיקת הקוד אם הוא לא כולל חורים "תודות" ל-NSA ושאר גורמים שמעוניינים להיכנס לתכנים מוצפנים. אני ממליץ להיכנס ללינק ולקרוא שם, לאלו המתעניינים.

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

לכן, ההמלצות שלי בשלב זה הן:

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

אם יהיו עדכונים, אעדכן פוסט זה.

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

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).

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

עד לאחרונה, בכל הקשור למחשוב ענן שפתוח לציבור, האפשרויות הכי ידועות היו אמזון (כמובן) ומיקרוסופט עם 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. (כן, אני חובב את הפלטפורמה של גוגל, אבל אני גם יודע לפרסם פאקים שלהם).