קטגוריה: וירטואליזציה

על NFS v3 מול NFS v4.1 ו-pNFS

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

בעולם היוניקס, פרוטוקול שיתוף הקבצים הכי ידוע הוא NFS (שפותח ע"י SUN) וספציפית גירסה 3 (כלומר NFS v3) וגירסה זו היתה שיפור של דברים ישנים יותר כמו DFS ו-AFS. בפרוטוקול זה, כל יצרני היוניקס/BSD ולינוקס השתמשו ומשתמשים עד היום, למרות שהפרוטוקול עצמו די ותיק (השנה ימלאו לו 20).

גירסה 3 של NFS הומצאה בזמנים שכמות התעבורה וכמויות המידע שהיו לחברות, היו נמוכות (במושגים של היום) ובהתחלה גירסה 3 תמכה רק בהרשאות של מה שקיים בשרת עצמו, כלומר אם משתמש X לא קיים במערכת, אז משתמש X לא היה יכול להשתמש/לקרוא/לכתוב קבצים ששותפו ע"י ה-NFS. במשך הזמן אותה גירסה 3 "שופצה" והתווספו לה (בעקיפין) תמיכה לדברים כמו NIS, LDAP, AD ואחרים, בין באמצעות שימוש ב-Mapping (במקרים של משתמשים בודדים עם הגדרות ידניות ללא שרת אותנטיקציה) ובין בשימוש ב-Translation שהשתמש ב-nsswitch ואותו nsswitch היה מתממשק לשרות האותנטיקציה.

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

ב-SUN היו מודעים לבעיות והם שחררו ב-2000 לפתח את גירסה 4 (וגירסה זו זכתה לשיפוצים ב-2003). מכיוון שהם רצו שזה יהיה סטנדרט, הם עבדו עם ארגון ה-IETF וב-2010 יצאה גירסה 4.1 בצורה רשמית כסטנדרט.

אנחנו נמצאים בשנת 2015 והשימוש ב-NFS 4.1 אינו גדול בעולם. מדוע? ישנן מספר סיבות:

  • אחת הסיבות שלא משתמשים (או שמשתמשים ב"עירוב" של גירסה 3 ו-4, מה שלא ממש מקל על צוות ה-IT) היא חוסר תמיכה לגירסה 4.1. כל חברה שמכבדת את עצמה משתמשת בוירטואליזציה ואם רצית להשתמש בוירטואליזציה עם NFS, האפשרות היחידה שהיתה לך – זה להשתמש ב-NFS 3 (או iSCSI).
  • סיבה נוספת ודי עיקרית – אין Clients, במיוחד שלא היה שום Client רשמי ללינוקס, כיום רוב השרתים שאינם מבוססי Windows הם לינוקס, ומכיוון שלא היתה תמיכה (עד גירסת Red Hat 6.4 וגם אז זה היה מוגדר כ-Technology Preview) – חברות העדיפו להשתמש ב-NFS 3 או בפרוטוקולים אחרים.

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

אולם אחד היתרונות הגדולים של גירסה 4.1, היא שאין יותר מצב של שרת אחד שמשרת את כולם. מעתה אפשר לשים כמה שרתי נתונים (Data Storage) שעליהם מאוחסנים הנתונים (בשכפול או בכל תצורה אחרת) וישנו שרת שמנהל את ה-Meta Data (וגם נקרא כך – MDS – Meta Data Server), כך שהתחנות שפונות וצריכות שרותי NFS, מדברות בהתחלה עם ה-MDS וה-MDS מפנה אותם לשרתי DS שעליהם מאוחסן המידע. זה, אגב, ה-pNFS שהוא בעצם חלק מ-NFS 4.1.

בנוסף, יתרון גדול מאוד שיש לגירסה 4.1, זה שעתה במקום לתת רק שרותי קבצים, השרת יכול להגיש עוד 2 סוגים של אחסון: האחד הוא Object Storage והשני (שסביר להניח שרבים יאהבו) הוא Block Storage – כמו iSCSI, FC, FCoE וכו'. כלומר, אפשר להכין כמה LUN נחמדים, לתת ל-MDS לעשות Discovery מול ה-iSCSI Target ולשתף אותם, דבר שבעייתי לבצע עם iSCSI Initiator שונים (למעט במקרים של Cluster Aware כמו ב-ESXi, Hyper-V וכו').

ויש עוד יתרונות רבים ל-NFS v4.1.

נשמע נחמד, לא?

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

הבעיה הגדולה היא שמה שרד-האט והפצות אחרות נותנים, זה רק Client. אסייג בדבריי ואומר שאין מניעה מלהרים שרת NFS 4.1, אולם בגירסת רד-האט 7 האחרונה, יש תמיכה בשיתוף קבצים, אולם תמיכה ב-Object Storage וב-Block Storage מוגדרת כ-Technology Preview (גם בגירסת רד האט/סנטוס 7.1 שתצא בקרוב). התמיכה הרצינית ש-pNFS (כ-שרת) צריך תגיע רק בקרנל 4.0, וגם אז התמיכה היא ל-XFS בלבד.

אבל הבעיות לא עוצרות כאן. גם אם נורא בא לך לקמפל קרנל, לשדרג את חבילות ה-nfs-utils ואחרות (שנמצאות ב-Fedora 22 שעוד לא יצא), אתה תמצא מהר מאוד שקיימת בעיה רצינית של תיעוד. הוא פשוט כמעט ולא קיים ומה שקיים כתוב בצורה שקשה להבין מי נגד מה ואיך, כמו איך להגדיר שרת קבצים כ-DS, מה צריך להיות בשרת MDS, איך משתפים בלוק של iSCSI ועוד ועוד. דווקא ניסיתי לשלוח מספר מיילים ולצ'וטט ב-IRC בערוץ linux-nfs, אך עד כה לא קיבלתי כל תשובה..

עם כל הבעיות, יש בהחלט מקום לאופטימיות. אני מאמין שהדברים ישתנו בחודשים הקרובים וישנם גם שיפורים שהחבר'ה מאורקל (לשעבר SUN) גם ירצו לאמץ כמו 21 הטלאים שהוצעו כ-RFC אתמול ל-Linux-NFS שמאפשרים דבר חדש: RichACL, כלומר ACL שיתן תאימות מלאה גם ל-SMB וגם ל-NFS, דבר שיכול להקל מאוד לסביבות מעורבות (ויכול להחליף את ה-POSIX ACL).

האם חייבים להשקיע ב-DR כמו במערכת פרודקשן?

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

ההחלטה: להרים מערכת DR זהה מבחינת ברזלים ותוכנות – למערכת הפרודקשן.

מכיוון שיש אנשים שונים שמבינים את המושג "DR" במשמעויות שונות. המשמעות שאני מדבר עליה היא כדלקמן:

  • מערכת שהיא Active/Passive – כלומר מערכת הפרוקדשן נותנת שרות ומערכת ה-DR לא נותנת שרות בזמן שהיא "פאסיבית". אף אחד לא מתחבר אליה והחיבור היחיד שיש הוא בין המערכת DR למערכת הפרודקשן עם אפליקציית סינכרון מתמשכת שמעבירה כל ביט בין ה-Storage השונים (ה-Storage שבפרודקשן ל-Storage ב-DR), וסינכרונים נוספים רצים בין שרתים עצמאיים (Active Directory וכו').

הנה מערכת קטנה ופשוטה לדוגמא. יש לנו שרת קבצים גדול שאליו מחוברים עוד 2 JBOD (בתצורת RAID, אפשר לחשוב עליהם כמודולים המרחיבים את המקום הפנוי ב-Storage), נתב, חומת אש, ו-12 שרתים שמריצים מכונות וירטואליות שונות.

האם אנו צריכים בדיוק אותו דבר למערכת DR?

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

מערכת DR באופן עקרוני, חוץ מלקבל נתונים מה-Storage ושרותים שונים, רוב הזמן כשמערכת הפרודקשן עובדת, היא לא עושה כמעט כלום. אם ניקח את המושג "DR" במובן הקלאסי, השרתים וה-Storage יושבים במיקום פיזי אחר, אולי בבניין אחר, אולי בעיר אחרת, בחוות שרתים שאינה החווה שלנו ואם נשתמש בה שם כ-Active/Active, החברה תצטרך לשלם לא מעט על רוחב פס, חשמל (מה לעשות, חוות שרתים גובות בערך 150-250% יותר מתעריפי חברת החשמל שאתם משלמים בבניין שלכם).

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

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

אז כשמקימים את ה-DR, אפשר להקים אותו ולחסוך כספים בדרכים הבאות:

  • לא חייבים לרכוש במיליוני שקלים שרת קבצים. זיכרו – שרת הקבצים ב-DR יתן שרותים לזמן קצר עד שהתקלה תטופל, כלומר זה יכול להיות למשך מספר שעות ובמצב אסון טבע – כמה ימים עד שבועות, לא חודשים עד שנים.
  • מבחינת שרת קבצים – אנחנו צריכים 2 (השני ישמש כגיבוי לראשון כי אין לנו במצב חרום קלטות). עם 2 השרתים אנחנו יכולים להשתמש ב-ZFS ובמקום להשתמש בדיסקים מבוססים SAS יקרים, אנחנו יכולים "להעמיס" דיסקים מבוססי SATA זולים וגדולים (הם זולים – בערך 200$ ל-4 טרהבייט ויש אחריות ל-5 שנים) ובשביל לקבל מהירות נוסיף בין 2-4 דיסקים מבוססי SSD שישמשו כ-Cache. ככל שנעמיס יותר דיסקים SATA על המערכת, מהירות הקריאה תהיה הרבה יותר גבוהה כי אנו ניצור RAID של ZFS עם יותר דיסקים מיכניים, כך שאפשר להגיע בקלות למהירות קריאה של בין 400 ל-800 מגהבייט לשניה (אם אתה משתמש בחיבורי 10 ג'יגה או שאתה מחבר מספר פורטים של 1 ג'יגה).
    שרת הגיבוי לעומת זאת, לא מצריך הרבה השקעה – שוב, אפשר נניח להכניס 10 דיסקים של 4 טרהבייט (SATA), ו-2 דיסקים SSD. רוב התעבורה אליו היא כתיבה ולכן ה-SSD יקבל באופן מהיר את הנתונים וברקע מערכת ה-ZFS תכתוב את הנתונים לדיסקים המכניים.
  • לא חייבים לשים שרתים מהדור האחרון, אפשר לשים שרתים מדור קודם או לפני כן במיוחד אם אתם שוכרים מקום לפי ארונות ולא לפי U בחוות שרתים. ה"סוד" הכי ידוע בוירטואליזציה זה זכרון – ואפשר להשיג בזול זכרון לשרתים מלפני 3-4 שנים.
  • אם לא נעביר את כל השרותים, יהיה לנו מקום "להתפרס" מבחינת השרותים, כך שכמות המכונות הוירטואליות שרצות פר שרת לא תהיה גדולה, וכך נוכל לתת את אותו שרות חרום – במהירות מיטבית.
  • גם מבחינת רוחב פס החוצה מהשרתים למשרדי החברה נצטרך לדאוג ל-Policy כלשהו ש"אין חגיגות" כי במצב חרום לא רק תעבורת אינטרנט מבחוץ עוברת, עכשיו גם כל ה-DATA מהשרתים מבחוץ עוברים על אותו רוחב פס, והדבר האחרון שאתם צריכים זה לא להצליח להיות מחוברים לשרתים בחוץ כי כמה עובדים החליטו שעכשיו בדיוק הזמן לצפות בשידורים חיים לגבי המצב. (פתרון למצב כזה שהרמתי בעבר: PC עם מודם 3G שמצד אחד מקבל שידורים דרך סקריפט, ומצד שני משדר אותם ב-LAN הפנימי דרך VLC תוך וידוא שאין אפשרות להתחבר למודם 3G מבחוץ).

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

בפוסט הבא נדבר על מערכות Active/Active.

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

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

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

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

  • עריכות וידאו (כאשר ישנן מספר תחנות שעליהן עורכים וידאו וכל התכנים יושבים על שרת ZoL)
  • VOD – לשידור וידאו החוצה ללקוחות
  • גיבויים ושחזורים, ארכיב
  • שרת PXE/BOOT לתחנות Diskless
  • שרת קבצים (CIFS, iSCSI, NFS)

כפי שציינתי בפוסטים קודמים, עם ZFS אין לך בעיה של התרחבות. נגמר לך המקום בשרת מבחינת כמות דיסקים שאפשר להכניס? חבר JBOD כלשהו ואם זה JBOD שאתה בונה, אני ממליץ להשתמש בפאנל של Areca מסוג 8026 או 8028, כך שאתה יכול לחבר אליו עוד 2 JBOD נוספים ואם צריך, לשרשר אליהם (אם כי במקרים כאלו אני ממליץ לפצל את חיבור ה-SAS מה-JBOD השונים בשרת עצמו למספר כרטיסים). ל-ZoL/ZFS אין שום בעיה לתמוך בעשרות אלפי כוננים ובאקסבייטים של נתונים והעבודה עצמה לאחר ההרכבה מאוד פשוטה: להגדיר RAIDZ ברמה כלשהי (אם יש לך הרבה דיסקים אז רמת RAIDZ3 מומלצת, כך שעד 3 דיסקים קשיחים יכולים להתקלקל והמכונה עדיין תמשיך לעבוד בצורה חלקה), ומיד תראה שיש לך מקום שזמין לכל השרותים שאתה מריץ על השרתים השונים ללא צורך בהגדרות LVM.

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

אחת הדוגמאות לכך היא שרותי NFS לשרתי ESXI.

הבעיה עצמה מחולקת ל-2 חלקים, כאשר ZFS עצמו אינו אשם במצב, אלא המערכת מתחת שנותנת שרותי NFS וגם VMware קצת אשמים.

יצרני הפצות לינוקס (במיוחד רד-האט) דוחפים תמיד את ההפצה קדימה מבחינת טכנולוגיות שהלינוקס בהפצה נותן ללקוחות. כך לדוגמא בלינוקס יש NFS גירסה 3 וגם NFS גירסה 4.1 (מ-RHEL 7 ומעלה), אבל ה-NFS-3 שקיים ללינוקס לא יכול להשתוות בביצועים שלו ל-NFS-3 של סולאריס כי מדובר ב-2 מימושים שונים לחלוטין. בלינוקס פשוט החליטו לא להשקיע יותר מדי ועברו למימוש גירסה 4 ו-4.1 שנותנים ביצועים הרבה יותר טובים וגם אבטחה הרבה יותר גבוהה עם אפשרויות התחברות מקביליות (pNFS), ואפשר לקבל יותר פרטים ממסמך ה-PDF הזה.

כשמחברים שרת לינוקס לשרת ZoL אפשר להתגבר על הבעיות ביצועים עם mount options שונים כמו rsize,wsize וכו', וכאן צצה הבעיה שמגיעה ל-VMWare.

ב-VMware, כשאתה מחבר NFS דרך vSphere או vCenter או VSA לשרתי ESXI (או ישירות לשרת ESXI מסויים) אין לך יותר מדי מקום "לשחק". אתה צריך לתת לו את שם השרת, שם ה-Share, השם שיהיה ל-Datastore וזהו. אתה לא יכול להכניס פרמטרים ובנוסף לכך – התמיכה היא רק ב-NFS-3, כלומר התמיכה ב-NFS במוצרים של VMWare כבר מהרגע הראשון היא לא מי יודע מה. המימוש עצמו עובד עם כל השרותים של vCenter/VSA כמו DR, HA, DRS וכו' מול NFS, אבל גם אז הביצועים לא יהיו הכי טובים שניתן לקבל.

מהצד של VMware הבעיה תוקנה באופן רשמי בגירסת ה-vSphere החדשה (גירסה 6) ששוחררה חודש שעבר. סוף סוף יש תמיכה ב-NFS 4.1 עם אותנטיקציה כך ששרת vSphere 6 מול ZoL יעבוד בצורה טובה מאוד.

תיקון לבעיה הזו קיים בגירסה 0.6.4 של ZoL והמצב יותר טוב, אך עדיין, אם יש לך שרתי vSphere 5 ואתה רוצה לחבר אותם רק דרך NFS ל-ZFS, אולי כדאי גם לבדוק פתרון מבוסס Opensolaris (כמו Openindiana) ואז לראות מי נותן לך פתרון יותר טוב.

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

טכנית, ב-ZFS הדבר הראשון שמגדירים הוא ה-Pool, שזו ההגדרה הראשית כל מערכת הקבצים של ZFS שמתחתה יושבים כל ה-RAIDZ, הגדרות וכו' וכו'. הבעיה? גירסת ה-Pool.

כל מימושי ה-ZFS השונים, בין אם זה תחת לינוקס, BSD, גירסאות פתוחות של סולאריס משתמשים בגירסה אחידה שנקראת 5000 ומערכות ZFS יודעות לייבא Pool מגרסאות ישנות יותר עד גירסה 28. סולאריס הרשמית נמצאת כיום בגירסה 35 אבל שום גירסת ZFS פתוחה לא יכולה לתמוך בכל משהו שהוא מעל גירסה 28, כלומר אם הרמת Pool על BSD או על גירסת סולאריס פתוחה, אין שום בעיה להביא את הדיסקים למכונת לינוקס, להריץ פקודת zfs import והוא יכניס מיידית את הדיסקים שהבאת לשימוש, הפורמט נשמר ותואם, אולם אם ה-pool נוצר בסולאריס סגור  (מגירסה 11 ומעלה), לא תוכל להשתמש ב-pool הזה בשום גירסת ZFS פתוחה. הכל "תודות" לאורקל שסגרו את הקוד. אגב, ההבדל הגדול בין גירסה מעל 28 ל-5000 זה שיש הצפנה, ובגירסה 5000 יש פתרון עקיף להצפנה בשימוש אפליקציה נוספת שעושה זאת.

ו"חסרון" אחרון שהוא יותר פסיכולוגי הוא עניין גירסת ה-ZoL. כיום יש את גירסת 0.6.3 ובשבועות הקרובים תצא גירסת 0.6.4 שתשפר מספר דברים. היכן גירסה 1.0? היא כנראה תצא בשנה הבאה, אולם אין צורך להמתין לה. גירסה 0.6.3 מוכרזת כ-Production Ready, כלומר אפשר להתחיל ולהשתמש בהן כבר עכשיו. גרסאות חדשות שיצאו בהמשך הן גרסאות תואמות, תוכל פשוט לבצע yum update, להפעיל את השרת מחדש ולהריץ פקודת zpool upgrade, וזהו. אין שינויים שתצטרך להתכונן אליהם במיוחד וגם השינויים שמבוצעים בגרסאות לא משפיעים מבחינת הגדרות, השרת יכול להמשיך לעבוד ולשרת את השרתים ותחנות אחרים.

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

שימוש ב-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]

כמה עדכונים על וירטואליזציות שונות

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

העדכון הראשון נוגע ל-vSphere גירסה 6 שאמורה לצאת בשנה הבאה. ישנם לא מעט חידושים (כל אחד יכול להצטרף לבטא) ואחד מהחידושים שכבר נכנס בגירסה 5.5 הוא NDDK חדש (ר"ת של Native Driver Development Kit). מי שמעוניין לקרוא קצת יותר מה שכתבו על כך, אפשר לקרוא כאן. אני אתייחס לאספקט טיפה שונה.

טכנית, עד גירסה 5.5 חברת VMWare די "תפסה טרמפ" על הדרייברים שיש ללינוקס. לא, ESXI אינו בנוי עם קרנל של לינוקס, אך ישנה מעין "שכבה" (vmkernel) שמתרגמת בין לקרנל הקנייני של ESXI לדרייברים שכתובים עבור לינוקס. היתרון: כבר ביום הראשון, היה אפשר להתקין את ESXI על כל דבר, כל עוד שזה היה מעבד X86 עם 64 סיביות ותמיכת VT. החסרון: שכבת ה"תרגום" הורידה חלק מהביצועים.

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

ה-NDDK הוא קוד סגור ו-VMWare בשלב זה לא מתכננת לשחרר אותו לציבור, כך שיהיה מעניין לראות איך קהילת המשתמשים הביתיים תתגבר על הבעיה (מה עוד שב-6.0 תצטרך להתרגל להשתמש ב-VCSA במקום ה-vCenter שהיה רץ על Windows).

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

אחת הבעיות הגדולות בגרפיקה עם וירטואליזציה – היא המהירות של הגרפיקה. היא פשוט א-י-ט-י-ת. אינטל הוציאה את תמיכת ה-VT-D שמאפשרת לך (תאורתית) למפות כרטיס PCi-E (כמו כרטיס מסך) למערכת הפעלה אורחת. לצערי, התמיכה של אינטל בתוספת הזו היא כמו הליכה בשדה מוקשים: יכול להיות שהמעבד החדש שלך תומך בכך, אבל אתה צריך לבדוק שגם ה-Chipset בלוח האם שלך תומך ושגם ה-UEFI/BIOS בלוח האם שלך תומך, אחרת לא תוכל להשתמש ב-VT-D.

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

אז זהו, שגם אם תעשה את השמיניות באוויר הללו, אתה תמצא שאתה לא יכול למפות כרטיס GTX מבוסס nVidia אלא רק כרטיסי Quadro יוקרתיים (יש אפשרות "להמיר" כרטיסים ישנים יותר שיהיו Quadro אבל זה לא לבעלי לב חלש, בחלק מהמקרים תצטרך להלחים..). עם כרטיסי Radeon יהיה לך יותר מזל אבל גם לכך תצטרך לשחק עם כל מיני הגדרות (כמו למפות את הזכרון שהמכונה תיקח כזכרון שלא ניתן למיפוי ל-VM אחר, אחרת הכל יתקע, מנסיון…), אבל תוכל לעשות משהו, שכמובן לא נתמך ע"י אף אחד.

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

לתוך הבעיה הזו אינטל נכנסה לאחרונה, עם גישה מאוד מעניינת: עד היום, הפתרונות שיש נתנו לך להריץ רק מכונה וירטואלית אחת עם האצה גרפית אמיתית (במקרה של Hyper-V אפשר מספר מכונות עם RemoteFX אך התמיכה הזו מאוד מוגבלת ולא כוללת דברים כמו OpenGL כך ששום אפליקציה רצינית לא תרוץ בצורה מואצת). מדוע שלא נבנה מחדש את כל רעיון ה-vGPU כך שכל מכונה וירטואלית תוכל לגשת למעבד הגרפי (של אינטל, לא מעבדים גרפיים אחרים) ותקבל ביצועים מעולים? אז 3 מהנדסים באינטל עובדים על כך והפרויקט נקרא KVMGT. תוכלו לראות מצגת (PDF) על כך כאן.

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

אינטל כמובן לוקחת את הצד הניטרלי והשינויים יכנסו גם ל-QEMU, גם ל-XEN וגם ל-KVM. זה עדיין כמובן לא אומר שתוכל לרנדר פוטשופ עם כמה מאות שכבות בשניות, וכמובן זה לא ממש יתאים להריץ את המשחקים האחרונים שחונקים את המעבד הגרפי עד שהוא מתחנן לטישו, אבל זהו צעד ענק שאין ספק שיאומץ על ידי פתרונות וירטואליזציה אחרים כמו VirtualBox ואולי גם ע"י VMWare ומיקרוסופט (מי יודע..). בשלב זה המתחרים (AMD ו-nVidia) לא מציגים פתרונות מתחרים, אולם אני מאמין שלחץ מהמשתמשים יגרום להם לחשוב מחדש לגבי פיתוח פתרונות שיאומצו ע"י יצרני פתרונות הוירטואליזציה השונים.

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

עוד עדכונים – בקרוב.

כמה מילים לגבי שדרוג ל-RHEL-7/CENTOS-7

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

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

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

ניקח לדוגמא את מערכת SystemD, זו מערכת חדשה שמחליפה את SysV הישנה שהיתה עד כה בהפצות לינוקס. ב-RHEL-7 אין יותר SysV ואי אפשר במחי פקודת yum להעיף את systemd, היא משובצת לאורך ולרוחב ההפצעה, מה-Boot ועד ה-Login ונוגעת בכל החלקים, כולל שרותים (Services), לוגים וכו'. כל פורום לינוקס רציני שתבקרו בו, תמצאו ויכוחים ופיצוצים בעד ונגד SystemD, ואפשר למצוא בכל מיני מקומות "בעד" ו"נגד" כאשר אנשי יוניקס ותיקים רוקעים ברגליים ורוצים את Sys V init בחזרה ולעומתם רבים אחרים מסבירים את יתרונות ה-SystemD (כאן לדוגמא). הסיבה העיקרית שרד האט (ולאחרונה גם הפצות אחרות כמו אובונטו הבא) עוברים ל-SystemD זה התמודדות עם הצרכים של היום שלא היו בעבר. כיום יש מספיק מקרים שבהם אתה מכניס ציוד בצורה "חמה" (כלומר ללא כיבוי והפעלה) ובמקרים של שרתים יקרים מאוד גם ציוד שבעבר לא היה ניתן להכניס בצורה חמה כמו מעבדים, זכרונות, והתקנים נוספים (גם כרטיסי PCI-E), ומערכות Sys V init שהיו צריכות סקריפטים מסובכים ו-1001 ספריות ו-daemons שונים כדי להתמודד עם זה – הכל הוחלף ב-SystemD. יש לו Journal (מערכת לוגים משולבת) שנותנת לך לראות בפקודה אחת פשוטה סטטוס יותר מפורט של שרות, אם הוא לא עלה, מדוע הוא לא עלה – מבלי שתשב ותכתוב תוך כמה דקות/שעות (תלוי בכשרון שלך) משהו שינפה את הפלט של dmesg או var/log/messages/ או קבצי לוג אחרים.

ב-RHEL-7 (וכמובן CentOS-7), בשונה מגרסאות לינוקס ל-Enterprise הכל השתנה, החל מה-Kernel שהוא גירסה 3 (בעבר 2.6), המשך ב-Boot (כיום GRUB-2 a שהוא הרבה הרבה יותר מורכב מה-GRUB הראשון), דרך שפות פיתוח, ממשק גרפי, טיפול בציודים, הגדרות רשת, דיסקים, File System וכו', מה שאומר שאם תיקח שרת שרץ עליו RHEL-6 ותעביר אותו לגירסה 7, יש סיכוי רב שחלק מהדברים לא יעבוד או שהמכונה אפילו לא תעלה (כבר יצא לי לראות שרת שמישהו החליט שזה רעיון מעולה לשדרג אותו דרך YUM מ-CentOS 6.1 ל-7 ובסופו של דבר נשאר שרת יקר אבל שלא מצליח לעשות אפילו Boot).

RHEL-7 לפיכך אינו מתאים לשדרוג דרך YUM או דרך בחירת "שדרוג" כשעושים BOOT ל-ISO. במילים אחרות אל תסמכו על ה"שדרוג" הזה. הוא בהחלט ישדרג את קבצי ה-RPM, אבל יש מספיק דברים שהשתנו לגמרי בין 6.5 ל-7. סתם דוגמא: מריצים שרת Apache? מריצים מודולים שקימפלתם? תתפלאו – ב-RHEL-7 האפאצ'י הוא גירסה 2.4 ומודולים רבים לא מצליחים להתקמפל מולו, וחלק מהמודולים האחרים מתקמפלים אבל נופלים בעת העלאת שרות ה-Apache. כיף!

לפיכך, בהתאם למה שהצלחתי לאסוף מנסיוני ומנסיון חבריי, הנה מספר נקודות לגבי מעבר ל-RHEL-7:

  • תחנות Desktop/Workstations שמריצים תוכנות סגורות (שרטוט תלת מימד, קומפיילרים קנייניים, תוכנות IDE קנויות וכו') – לא לשדרג כרגע ל-7. תוכנות סגורות רבות עדיין אינן מתאימות לגירסה 7. אגב, שדרוג לגירסה 6.6 יצא בקרוב, אם בא לכם, אתם יכולים לשחק עם ה-Beta כאן.
  • תחנת שמריצות דברים בקוד פתוח – מומלץ להרים מכונות VM נסיוניות (לא שדרוג) עם האפליקציות ולתת למפתחים לשחק עם זה כמה ימים כדי לראות מה פעיל ומה שבור.
  • שרתים – גם כאן, אני ממליץ להרים מכונת VM ריקה עם RHEL-7 ולהתקין עליה את האפליקציות ולראות מה עובד ומה לא עובד. מצאתם שהכל עובד? אל תשדרגו עם הכלים של רד-האט, עדיף שתפרמטו ותתקינו מחדש, ועל כך תיכף ארחיב.
  • מכונות קומפילציות, Hadoop ושאר דברים יעודיים – נסו עם מספר מכונות VM להרים חווה קטנטנה כדי לראות שהכל עובד, כולל Stress Testing. קצת אחרי ששוחררה RHEL-7 היה באג רציני שתוקן באחד העדכונים.

כפי שציינתי לעיל, בשדרוגים יש סיכוי גבוה שמעבר מ-6.5 ל-7 (או גירסה מוקדמת יותר ל-7) דברים ישברו מבחינת סימנים (Symbols), תאימות בינארית (צורך בהתקנת compat למיניהם) ולכן אני ממליץ להקים את המכונה מחדש. לשמור את כל ה-DATA בנפרד ולהתחיל התקנה מחדש (ובהזדמנות להתחיל לחשוב על שימוש יותר מאסיבי עם Kickstart למי ש…אהממ… עדיין עובד עם ה-ISO). ישנם מערכות File Systems חדשות ויותר יציבות שיודעות לטפל בכמות הרבה יותר גדולה של קבצים – כמו XFS של סיליקון גרפיקס (בברירת מחדל אם לא תגדיר ידנית, RHEL תפרמט את הדיסק שלך ב-XFS). ה-LVM עבר שיפור (בבקשה, בבקשה, חדל מההתקנה של כל מערכת ההפעלה יחד עם הקבצים של המשתמש וה-SWAP הכל תחת Partition יחיד!), אם אתם משתמשים בחברה ב-Active Directory אז תוכלו ישירות מההתקנה להגדיר חיבור לדומיין ואת המשתמשים, וישנם שיפורים רבים נוספים, ובכלל, מומלץ לקרוא לעומק את ה-Installation Guide.

אם אתם הולכים להתקין את ההפצה על וירטואליזציה כמו HyperV או ESXI, אז אני שמח להודיעכם שאין צורך להתקין שום תוספים (ולא, גם לא VMWare Tools). הכל מגיע עם ההפצה בהתקנה רגילה, כך שאינכם צריכים להתקין כלום. למשתמשי HyperV – הבאג המעצבן של NFS עם NetApp על CentOS (המתנה של כמה עשרות שניות בין פקודה לפקודה) – תוקן ע"י רד-האט בתוך ההפצה. משתמשי ESXI – אתם תראו שה-TOOLS מופיעים כ-3rd Party, זה בסדר, הכלי שמותקן בפנים ושמפעיל vmtoolsd נעשה בשיתוף המהנדסים של VMWare.

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

לסיכום: כן, דברים השתנו לחלוטין בגירסה 7, אבל מה לעשות, דברים משתנים וטכנולוגיות והגדרות משתנות. אי אפשר להישאר כל הזמן בעבר. הטכנולוגיה היום דורשת פתרונות יותר דינמיים, הצרכים משתנים והפתרונות גם. נכון, לסקריפטולוגים מביניכם שקיצרו את העבודה היום יומית שלהם לפקודות של 3-4 אותיות תהיה קצת עבודה לשנות את הסקריפטים (לחובבי פייתון – הגירסת ברירת מחדל עכשיו היא 2.7 עדיין, אבל זו הגירסה האחרונה שתתן אותו כברירת מחדל. הגירסה הבאה תקפוץ ישר ל-3.4 או מה שיהיה אז), אבל מבחינת SystemD עדיין סקריפטים שמשתמשים ב-chkconfig, service וכו' יוכלו לרוץ, תסתכלו במסמך הזה אך יחד עם זאת, תתחילו להכין את הסקריפטים שלכם ל-SystemD. לא לשכוח גם להוסיף את ה-REPO הזה.

בהצלחה

תכירו את Docker

להלן סיטואציה שבוודאי מוכרת לכם מהתשתית אצלכם בחברה: יש לכם שרת שמריץ אפליקציה וכל העולם ואחותו בחברה מתחבר כדי לעבוד על האפליקציה. האפליקציה היא קריטית ויכול להיות שעקב עומס אתה מריץ שרת נוסף, בין אם אתה עושה Load Balancing או High Availability – זה לא חשוב כרגע.

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

כלומר עד כה, ספרנו 5 שרתים שמריצים פחות או יותר את אותה אפליקציה ואת אותה מערכת הפעלה. אם אתם משתמשים בוירטואליזציה כמו ESXI או Hyper-V או Xen – אז אתם מריצים 5 מערכות הפעלה זהות שתופסות לא מעט משאבים, הן מבחינת CPU, הן מבחינת דיסק וכמובן מבחינת RAM, וכנראה גם Storage. אם אתם מריצים את זה על ברזלים אמיתיים, אז התשתית שהסביבה לעיל תופסת היא בערך רבע/חמישית ארון.

וירטואליזציית "ברזל" (כמו ESXI, Hyper-V, KVM, Xen) נתנה לנו משהו מדהים לארכיטקטורת ה-PC (זה היה קיים הרבה לפני כן במערכות IBM ואחרות): תיאורתית אתה יכול לקחת ארון שלם של שרתים ו"לדחוף" את כולו ל-2 שרתים עוצמתיים. החסכון בתחזוקה, בחשמל ובמשאבים. פתאום אתה יכול להרים עוד 10 שרתים וירטואליים מבלי לרוץ ולבקש תקציב נוסף ל-10 שרתים פיזיים עם כל כאב הראש המתלווה לכך.

מערכות הוירטואליזציה האלו הן בד"כ מסוג HyperVisor Type 1. יש גם Hypervisor Type-2 כמו VirtualBox או VMWare Workstation שרצות בעצם על מערכת הפעלה קיימת (בין אם זה Linux או Windows) ואינן ניגשות ישירות ל"ברזל" כמו ESXI ואחרות.

ישנה עוד וירטואליזציה. נקרא לזה "וירטואליזציה אפליקטיבית". גם כאן, הרעיון עצמו ישן והוא רץ שנים רבות על OS/400 (מכירים LPAR?), בסולאריס (Zones), בגרסאות BSD (נקרא Jails) ובלינוקס בזמנו היתה תוכנה מסחרית שנקראה OpenVZ (שהיום גם אם ישלמו לי, עם מקל אני לא נוגע בה!) וכמובן Jailed Root/Chroot בכל מערכת יוניקס/לינוקס והתוספת שהיתה ללינוקס מלפני מס' שנים: LXC. כולן נתנו (מי פחות ומי יותר) בערך את אותו דבר: הרצת אותה מערכת הפעלה כמו ה-Host (או גרסאות קרובות, לדוגמא: Solaris 9 על Solaris 11) בצורה נפרדת ללא צורך בעותק נוסף של מערכת ההפעלה. יתרון ענקי שיש לשיטה זו על פני כל Hypervisor היא המהירות: האפליקציה רצה ב-100% מהירות, כך שכל מכונה וירטואלית בשיטה זו תופסת כמעט כלום מבחינת משאבים (היא כמובן תתפוס לאחר שתמלא את המכונה באפליקציה שלך, אבל עדיין, כמות המשאבים שהיא תצרוך קטנה בהרבה בהשוואה לאפליקציה כזו שתרוץ תחת מערכת הפעלה נפרדת ב-Hypervisor כלשהו).

וכאן אנו מגיעים ל-Docker (שאגב, בקרוב יהיה זמין גם רשמית לסולאריס ע"י אורקל. כך השמועות אומרות).

להלן תרשים של Docker בגירסה 0.9:

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

Docker משתמש ב"מילה האחרונה" מבחינת טכנולוגיות לינוקס עדכניות כדי לתת כמה שיותר עוצמה לקונטיינר. כך לדוגמא אתה יכול לקבוע כמות כרטיסי רשתות, כמות זכרון, דיסקים, אתה יכול להשתמש ב-Device Mapper (תודה לאלכסנדר לארסון מ-Red Hat שכתב את המימוש) כך שבעצם קונטיינר ישב תחת Device ממופה, ואותו Device הוא בעצם "דיסק" שאתה יכול לקבוע את גודלו ומה שהכי נחמד – הוא Thin Provisioned ללא "קנסות" בביצועים. (אפשר לקרוא את הפוסט של אלכסנדר על כך כאן). אנחנו יכולים לבצע הגנות על הקונטיינרים עם SELinux ועוד.

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

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

Docker תופס פופולריות במהירות מבהילה. החברות הגדולות כמו Google, eBay, Baidu כבר מזמן משתמשות ב-Docker וחברות רבות אחרות. כך שמבחינת אימוץ טכנולוגיה, Docker מאומץ בחום ע"י רבים וכדאי להשקיע בו וללמוד אותו.

לסיום: נקודה חשובה גם למי שמכיר את Docker: החל מגירסה 0.9 Docker כבר אינו משתמש יותר ב-LXC (לא אכנס לנסיבות מדוע. דמיינו לבד..), והאפליקציה משתמשת בספריה משלה (libcontainer) שיודעת לדבר עם דברים כמו libvirt ואחרים.

עוד נקודה אחת קטנה: הבלוג עבר לדומיין חדש שמשקף את השרותים שאני מציע, תגידו מזל טוב 🙂

(גילוי נאות: הח"מ נותן שרותים בתשלום על הדרכה והטמעת Docker בחברות וארגונים).

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

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

Exit mobile version