קצת על רד-האט, BTRFS, פוליטיקה ומוכנות ל-Enterprise

אם נסתכל כיום על תשתיות של כל Enterprise או כל חברה גדולה, נראה שכיום רוב מכונות הלינוקס וה-Windows רצות כרגע על VM, בין אם זה רץ על ESXI, על Hyper-V, על OpenStack או בעננים ציבוריים או פרטיים. גם לינוקס וגם Windows רצים בלי בעיה כ-VM ולכל מערכת הפעלה יש תמיכה טובה בקישוריות בין ה-VM ל-Hypervisor שמריץ אותו.

הבעיות מתחילות כשצריכים להריץ הפצות לינוקס כמו רד-האט או סנטוס על "ברזל" פיזי או Appliance פיזי. אין שום בעיה להתקין לינוקס וברוב המקרים גם לא נצטרך דרייברים, וה-File system יעבוד כמו שצריך, אולם יש דברים בלינוקס שהם אינם קלים או מובנים למשתמשים רבים שאינם אנשי לינוקס ותיקים. יצירת RAID מבוסס תוכנה (Software RAID או Fake RAID) הם לא בדיוק דבר הכי קליל, במיוחד אם רוצים לשלב Volume Management בתוך אותו RAID תוכנה (אם כי כמובן יש אתרים שמסבירים כיצד לעשות זאת). את המשוכה הזו ניתן לדלג עליה די בקלות אולם אם אנחנו רוצים לבצע Snapshots או להוסיף SSD כ-Cache לאותו RAID, זה כבר נהיה יותר מורכב. רוצה גם לבצע Compression ו-DeDup בזמן אמת? כאן כבר תצטרך איש לינוקס טוב וזה לא תמיד אפשרי, תלוי במה קיים ובאפשרות לשנות דברים.

האם ניתן לעשות את הדברים בלינוקס? התשובה היא שבהחלט כן. אני כותב את הפוסט הזה בביתי ואחד משרתי ה-NAS שלי עושה בדיוק את הדברים הללו: ה-RAID הוא תוכנה, המערכת מייצאת iSCSI, CIFS, NFS החוצה למערכות אחרות (כל עריכת הוידאו שלי שאתם רואים בערוץ הוידאו של העסק מבוצעת על CIFS/SAMBA, לא על דיסק מקומי), יש DeDuplication  ויש דחיסה והכל רץ על "מפלצת" עם … מעבד i5 ועם 16 ג'יגהבייט זכרון, 5 דיסקים מכניים ו-2 דיסקים SSD ישנים שישבו אצלי במגירות. המערכת עצמה רצה על ZFS עם הפצת CentOS 7 ועם כל העומס שאני זורק עליה (ויש עומס) – היא עושה את עבודתה יציב כבר 4 שנים בלי תקלה אחת הקשורה ל-ZFS.

אז אם יש את זה, מדוע אינך רואה בהפצת לינוקס מבוססת רד-האט או סוזה אפשרות להקים מכונה עם ZFS? הרי ל-ZFS יש כבר ותק של בערך 12 שנה ב-Sun עם סולאריס (המערכת פותחה שם במשך 5 שנים לפני שהיא שולבה בסולאריס).

הסיבה הרשמית היא "בעיה ברשיון", הסיבה המציאותית יותר היא … פוליטית.

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

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

ב-2008 החלה לקום מערכת ניהול קבצים ודיסקים חדשה בשם BTRFS. בעקרון, BTRFS אמור להיות התשובה ל-ZFS רק בקוד GPL והוא משולב בתוך הליבת לינוקס. אנחנו ב-2017 וכיום כל הפצת לינוקס תומכת ב-BTRFS אולם הבעיה הגדולה ביותר של BTRFS היא ביציבות. ה-BTRFS יציב מבחינת file-system אך יש לא מעט בעיות במימוש ה-RAID שלו ובחלקים אחרים. בזמנו הקוד נבנה תחת קורת הגג של אורקל, אולם מאז שאורקל החליטה לברוח מקוד פתוח כאילו מדובר במחלה מדבקת – התפזרו המפתחים לכל עבר ואין עבודה יציבה על BTRFS, מה שגרם לרד-האט להודיע שהיא "יורדת" מ-BTRFS בגירסאות הבאות של הפצת הלינוקס שלה (בינתיים שאר ההפצות ממשיכות לתמוך ב-BTRFS, וזו מערכת עיקרית בהפצות כמו SuSE).

נשמע כמו צעד די דרסטי – לא? אכן, רק שבימים האחרונים הסתבר מדוע רד-האט עשתה זאת. רד-האט רכשה חברה קטנה בשם Permabit ש.. מציעה בדיוק את השרותים שה-Enterprise צריך: דחיסה, Dedupe, thin provisioning וכו'. האם רד-האט תציע זאת בחינם לקהל הרחב? כן, אבל יקח זמן. במילים אחרות, במקום לחכות ש-BTRFS יבשיל, רד-האט העדיפה לקנות חברה וטכנולוגיה. במקביל הודיעה רד-האט שהם החלו פרויקט חדש שנקרא Stratis שיאפשר לבצע חלק מהדברים בצורה קלה ופשוטה. אל תחזיקו את נשימתכם, לפרויקט יקח כמה שנים עד שיהיו פירות וניתן יהיה להשתמש בו בצורה בטוחה.

לסיכום: כיום ב-8 מתוך 10 מקרים, כשמקימים מכונת לינוקס, מקימים אותה כ-VM. לא צריך RAID ב-VM (אבל כן צריך LVM אם תרצו להגדיל דיסק או להוסיף דיסק ל-VM) ו-snapshots ניתן לעשות ברמת VM – ועדיין, עקב כל מיני החלטות שאני קורא להן "פוליטיות" הפצות רשמיות עדיין לא כוללות (גם בגרסאות המסחריות) דברים ש-Enterprise צריכים כשמקימים מערכת עם דיסקים מקומיים. הרכישה ש-רד האט ביצעה מסייעת במשהו, אבל אם רד-האט היתה עושה צעדים לפני מס' שנים כדי לסגור עיסקה עם אורקל, אז היינו כיום עם מערכת כמו ZFS שנותנת את הדברים שאותם לקוחות חשובים צריכים, במיוחד במקומות שמעוניינים להרים Software defined storage בשיטה של Scale Up.

העתיד: דיסקים, Storage ו-NVME-OF

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

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

התשובה: במקרים של דיסקים מכניים – בהחלט. במקרים של SSD – זה יוצא ההיפך. קחו דיסק SSD בחיבור SATA ותקבלו לדוגמא מהירות קריאה של 550 מגהבייט לשניה. לזה, שום SAS לא הגיע עם דיסקים מכניים (אלא אם מכניסים את ה-Cache של הבקר אבל זה יפה במבחנים, לא לעבודה במציאות) וכך עולם הדיסקים חזר "אחורה" ל-SATA ופורמט ה-SAS די "מת" למרות מאמצים מצד יצרני בקרים ושרתים להוציא (מאוחר מדי, LSI היו הראשונים להוציא מוצרים ב-2013) את SAS-12G, וכך המצב בשנתיים האחרונות בשוק הוא שדיסקים SSD קיימים בגירסאות SATA בלבד – אבל הדיסקים עצמם מכילים את כל תכונות ה-Enterprise כמו תיקון תקלות אוטומטי, שמירת מידע עצמאית בעת הפסקת חשמל, שרידות גבוהה בעבודות כבדות ועוד.

דיסקים SSD מבוססים SATA מאפשרים לחברות להמשיך לעבוד כאילו הם עובדים עם דיסקים מכניים או דיסקים SSD ישנים, ורבים נוטים עדיין לעשות את הטעות לעבוד כ-RAID-5,50,60 כשהם שוכחים 2 דברים מאוד חשובים:

ה-RAID-5 וה"אחים" שלו 50,60 ביצעו 2 דברים חשובים: נתנו ביצועים גבוהים הנובעים מעבודה עם ריבוי דיסקים וחלוקת העבודה בין הדיסקים, ושרידות יותר גבוהה מכיוון שאם הולך דיסק אחד או 2 (בהתאם לשלב ה-RAID) – המערכת היתה ניתנת לשיקום לאחר החלפת הדיסקים. עם SSD לעומת זאת (גירסת Enterprise!) הביצועים שהדיסקים האלו מוציאים די "חונקים" כל כרטיס רשת. תחשבו על כך: 2 דיסקים SSD ב-RAID-0 מוציאים מהירות תיאורתית של 1100 מגהבייט לשניה (בקריאה). נתרגם זאת לג'יגהביט ונקבל .. 8 ג'יגהביט, כלומר כרטיס רשת של 10 ג'יגהביט יהיה תפוס ב-80% בזמן שהוא משדר את ה-DATA מצמד הדיסקים, ושוב – אני מדבר על 2 דיסקים בלבד. אז מה בעצם נותן בקר דיסקים? ביצועים? יש כבר לדיסקים, לא צריך גם Cache. שרידות? ב-SSD ל-Enterprise יש יכולות הרבה יותר מרשימות של שרידות פנימית מאשר כמעט כל בקר RAID בשוק. ובכל זאת, חברות ממשיכות לעבוד כך. מדוע? אני חושב שזה עניין של הרגל.

בשנתיים האחרונות נכנסנו לעידן חדש של דיסקים SSD, מה שבהתחלה נקרא PCI SSD והיום פשוט נקרא NVME SSD. לדיסקים הללו לא תמצאו שום RAID כי הדיסק מחובר ישירות לתושבת PCIE X4 (בחיבור שנקרא כיום U.2, חלק מהיצרנים לצערי עדיין משתמשים בחיבור קנייני משלהם, לרווחתם של יצרני הדיסקים והשרתים, לצערם של הלקוחות ש"ננעלים" בכך שלא ניתן להכניס דיסקים יותר טובים מצד ג'). הדיסקים הללו כיחידות עצמאיות נותנות יותר ביצועים מכל מה שתשיג עם SSD ו-RAID, מהירויות של 2-4 ג'יגהבייט לשניה בקריאה ועד 2 ג'יגהבייט בכתיבה עם עשרות עד מאות אלפי IOPS (וכמובן את המילה האחרונה בשרידות, ושוב – שרידות הרבה יותר גבוהה מכל דיסק מכני שאתם מכירים) ושם כבר אין RAID (ואם רוצים RAID 0,1,10 – עושים זאת בתוכנה. הביצועים לא יהיו נמוכים יותר בהשוואה לבקר יעודי, האמינו לי, גם אם תנסו את זה על מעבד i5 פשוט [ניסיתי בעצמי מול בקר יוקרתי של LSI ]).

מי שבתחום כבר בוודאי מכיר את כל מה שכתבתי, אבל מה בעצם הלאה?

אם נסתכל מבחינת דיסקים, בשנה הנוכחית השוק מנסה להסתגל למצב חדש שבו יש הרבה יותר ביקוש מהיצע. דיסקים NVME SSD של 3-4 טרהבייט, גם אם תנפנף מול היצרן בכרטיס אשראי פלטיניום, תשלום מיידי או ערימת מזומנים – תיאלץ במקרים רבים לחכות וזה כרגע עדיין "מכה" ב-HP, DELL וגם ב-Lenovo. היצרנים נתפסו "במערומיהם" עם דרישות היסטריות לשבבי Flash מצד כל יצרני המחשבים והטלפונים. כולם רוצים שבבי NAND ועכשיו. יצרני השבבים גדלים (חברת TSMC לדוגמא, אחת החברות הגדולות ליצור שבבים – מתכננת בניה של FAB נוסף בסין בדיוק בשביל זה) ושבבי ה-3D NAND החדשים מאפשרים ליצור שבבים עם כמות אחסון יותר גדלה בליטוגרפיה בשיטות יותר "ישנות" כך שניתן פר Waffer ליצור יותר שבבים. שלבים אלו ואחרים יתורגמו לשחרור לחץ בשוק במהלך השנה שנתיים הקרובות.

אבל גם אם הבעיה תיפתר, נמצא את עצמנו בבעיה אחרת: בשביל ביצועים רציניים צריך NVME SSD וגם אם יש לך דיסקים חדשים וגדולים כאלו, איך בדיוק תשתמש בהם? זה לא שיש לך בקר RAID להגדיר Virtual Disk שעל זה אתה מתקין Windows, Linux, vSphere וכו'.. אפשר כמובן להוסיף דיסק קשיח כלשהו (ולהשתמש בבקר הפנימי כדי לבנות RAID-1 מדיסקים פשוטים) כדי להתקין את מערכת ההפעלה וכו', אבל הדבר הבא שהיצרנים ידחפו נקרא NVME-OF (זהירות, לינק לקובץ PDF). זהו הסטנדרט חדש שנבנה ע"י החברות שבנו את סטנדרט NVME, ועם הסטנדרט הזה אנחנו משתמשים בכמה מושגים שבוודאי שמעתם עליהם:

  • ה-AFA (כלומר All Flash Array) – מערכת סטורג' (או שרת) שבנוי כולו מדיסקים NVME SSD.
  • על מה נעביר את הנתונים? זוכרים ROCE? אז הוא חוזר לסיבוב נוסף, ולאלו שאוהבים לשפוך כסף כאילו אין מחר (בנקים, מכוני מחקר יוקרתיים וכו') – Infiniband.
  • ובאיזו שיטה? זוכרים iSCSI? אז נגזור משם את ה-Target ו-Initiator, שיהיה לכם חיים יותר קלים.
  • אבל מה עם כתובות IP וכו'? זה ישאר, רק שהפעם זה "נעקר" מה-OS ומועבר לביצוע ע"י כרטיס הרשת (כלומר TCP Offload).

עכשיו נשלב את הכל ביחד: נבנה שרת מבוסס Dual Xeon עם 128 ג'יגה (עדיף יותר, תלוי בכמות ה-Clients וכו') מבוסס לינוקס עם קרנל 4.8.7 ומעלה, עליו נרים מערכת שתהווה בעצם Target ובה ישבו לא רק הדיסקים אלא גם מספר כרטיסי רשת עם פס רחב (25 ג'יגה ומעלה או Infiniband). הכרטיסים יחוברו למתג תואם ומשם יחוברו לשאר השרתים שאנו מעוניינים. את חלוקת ה-Volumes וכו' נעשה על ה-Linux והמערכת בלינוקס תשדר זאת דרך ה-ROCE כבלוקים (אפשר עם שילוב TCP/IP, אפשר גם בלי אבל אז יתחילו הצרחות ממחלקת ה-IT) וה-Initiator בשרתים יתחבר ל-Target (יהיו גם אפשרויות אותנטיקציה, הצפנה וכו'). שרתים ישנים יוכלו להעלות את ה-Initiator לדוגמא דרך IPXE (או PXE לחובבי טכנולוגיה קלאסית) ומשם ה-OS יעלה ויקבל תמיכה מלאה כאילו מדובר בדיסקים מקומיים.

והביצועים? אם נשווה זאת לדיסקים NVME מקומיים, ההבדל יהיה באחוזים בודדים. מכיוון שכל השיטה מעיפה כל דבר שמוסיף Latency, הביצועים נראים כאילו מדובר בדיסקים מקומיים, רק שאין צורך לבצע תחזוקת דיסקים פר שרת והכל מבוצע ממקום אחד (ומנסיון, התחזוקה לא כזו מורכבת). סתם דוגמא: גם אם שפכתם כסף והפכתם את המערכת תקשורת שלכם ל-100 ג'יגהביט, תקבלו (במספר חיבורים במקביל) קצב של 93 ג'יגהביט בקריאה, ו-40 ג'יגהביט בכתיבה. עכשיו תנסו לדמיין מערכת VDI לאלפי משתמשים ואיך זה יעבוד, וכן – יש Initiators ללינוקס, Windows ול-VMWare כבר כיום.

כמובן שחובבי מיקרוסופט לא ישארו בצד ואם הם רוצים להקים לעצמם Target מבוסס Windows Storage Server אז הם יצטרכו להמתין קצת לגירסה הבאה.

לסיכום: דיברתי כאן על דיסקים SSD, על תקשורת שגבוהה בהרבה מ-10 ג'יגהביט, על NVME-OF (ממש על קצה המזלג). הטכנולוגיה קיימת כבר כיום (חברת Mellanox  כבר דוחפת ומדגימה אותה), אבל שום חברה לא עוברת מהיום למחר לטכנולוגיה חדשה שמצריכה החלפת מתגים וכרטיסי רשת ורכישה רצינית של NVME SSD ושרתים לכך. אלו דברים שלוקחים זמן, לפעמים שנים – אבל זהו הכיוון שהשוק ל-Data Center עובר אליו. חברות סטורג' רבות ישמחו למכור לכם את הפתרון לאחסון מחר בבוקר, אבל לפחות מבחינת TCO ו-ROI (ואם החברה מוכנה לאמץ מעט ראש פתוח) אני ממליץ לחשוב על פתרון בניה עצמית. הוא הרבה יותר קל ממה שרבים נוטים לחשוב (סתם דוגמא: הוא הרבה יותר קל מאשר הקמה וניהול של שרת ZFS) והוא פתרון שיכול להיות Scale Out די בקלות וזול בהרבה אם חושבים להרחיב – מאשר פתרון קנייני.

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

שאלות ותשובות על Cloudforms/ManageIQ

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

ש: האם CF/MIQ מתאים להחליף את הממשק ה-Windows/Flash/Web של vSphere?
ת: באופן עקרוני CF/MIQ בהחלט יכולים להחליף הממשק הקנייני של vSphere (או vCenter כפי רבים מכירים זאת), כמו שהוא יכול להחליף את ממשק ה-SCVMM בכל מה שקשור למכונות VM, אבל שימוש בכלי כזה רק לשם החלפת ממשק כמוהו כחיסול זבוב עם תותח 🙂

חשוב – שימוש ב-CF/MIQ אינו מייתר רכישת vSphere. ה-CF/MIQ מתממשק ישירות ל-CF/MIQ ולפיכך יש צורך ברכישת הרשיון vSphere.

המטרה העיקרית של CF/MIQ היא לנהל Life Cycle מלא של מכונות VM, וכדי לייעל תהליכים להקמת VM שאינם קשורים ישירות לפלטפורמת ה-VM שלך (פרטית או ענן). תהליכים הקשורים לבירוקרטיה בחברה, אורך חיי VM, פורטל בקשות הקמת VM ע"י הצוותים השונים בחברה, מימוש נהלים, עדכוני אבטחה (בשלב זה במכונות Linux Guest) ועוד. אם נשווה את זה לכלים המוכרים בתחום VMWare למשל, אז זה משהו כמו vRealize Orchestrator + vCenter Server – רק ש-CF/MIQ לוקחים את זה צעד קדימה לאפשר לך להתחבר גם לפלטפורמות VM אחרות ולעננים פרטיים וציבוריים.

ש: אם יש לי מספר פלטפורמות VM שונות, האם מספיקה מכונה אחת עם CF/MIQ?
ת: לא. לכל פלטפורמת VM יש צורך במכונת CF/MIQ. כל מכונה מתחברת לפלטפורמת ה-VM והתקשורת מבוצעת למעשה בין שרתי CF/MIQ שמעבירים את הפעולות הלאה לפלטפורמת ה-VM השונה יחד עם המידע והתוכן.

ש: האם ניתן להשתמש בחלק מה-Appliances גם בגירסה הפתוחה (MIQ) וגם בגירסה המסחרית (CF)
ת: ברוב המקרים התשובה היא "כן", אבל אז אינך יכול לקבל תמיכה רשמית למערכות CF/MIQ. חברות שמעוניינות בפתרון, צריכות או להשתמש בגירסה המסחרית או בגירסה החופשיה (ללא תמיכה רשמית).

ש: האם ישנה פלטפורמת אוטומציה ב-CF/MIQ?
ת: בהחלט! בברירת המחדל CF/MIQ תומכת ב-Puppet יחד עם Foreman, ניתן להשתמש גם ב-Chef וב-Ansible.

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

ש: איזו גירסה יותר מעודכנת ועם יותר Features ואיזו גירסה נחשבת יציבה?
ת: ה-ManageIQ כולל את "המילה האחרונה" מבחינת תכונות המערכת. זו המערכת שמפותחת מדי יום (לתוך GIT מרכזי פתוח) וניתן לשלוף את הגירסה האחרונה או גרסאות קודמות. האם מערכת כזו נחשבת יציבה? כל עוד לא הולכים ל-Bleeding Edge (או ה-Master ב-GIT) – אז יחסית כן, אם כי יכולים לצוץ באגים פה ושם.

לעומת זאת ה-Cloudform זו מערכת שמבוססת על ManageIQ אם כי לא על הגירסה האחרונה של ManageIQ. לגירסה זו נערכים בדיקות ומתוקנים באגים ורק למוצר הרשמי ניתנת התמיכה הרשמית של רד-האט.

ש: מה המחיר של Cloudforms?
ת: עניין המחיר הוא דינמי, זה תלוי על איזו מכונה אתה מריץ את CF, כמה Appliances אתה צריך, מהו סוג השרות שאתה מחפש (NBD, 24/7 וכו'), האם אתם משתמשים בעוד מוצרי רד-האט וכו'. אינני יכול לתת מספרים אבל אני כן יכול לרמוז שהמחיר נמוך ממחיר vRealize Operations (ואתה מקבל יותר, ואף אחד לא "יושב לך על הצוואר" מבחינת כמות VM) 🙂

ש: אנחנו משתמשים באובונטו במערכות שלנו, האם המוצר (המסחרי או הפתוח) יכול לרוץ על VM אובונטו?
ת: מכיוון שה-CF הוא Appliance, הוא מגיע כ-VM מוכן שצריך רק לבצע לו Deploy, להגדיר כתובת IP (או DHCP), להיכנס למסך הניהול ולהגדיר את שאר הדברים משם (ניתן כמובן לבצע SSH ולהשתמש במכונה כמכונת לינוקס אם רוצים לשנות דברים, לא מומלץ אם לא מכירים CF/MIQ).
יחד עם זאת, אם אתם משתמשים בגירסת ManageIQ, ישנם הוראות ברשת איך להקים זאת על VM מבוסס אובונטו (ולכך כמובן לא ניתן לקבל תמיכה מרד-האט).

ש: היכן ניתן לראות רשימת Features שקיימים בגירסה האחרונה?
ת: הנה (לחצו להגדלה)

ש: בחברתנו חוששים להכניס מוצרים כאלו מכיוון שבמקרים רבים התיעוד לוקה בחסר. האם למוצר יש תיעוד מלא שנגיש ללקוחות?
ת: במקרה של Cloudforms כלקוח אתה מקבל גישה מלאה ואתה יכול להוריד את ההסברים וההוראות כקבצי PDF. בנוסף יש גם ספרות רשמית שניתנת להורדה.
גם ל-ManageIQ יש תיעוד (ברובו אותו תיעוד של Cloudforms) אולם יש לשים לב לשינויים שיש פה ושם בין ManageIQ לבין Cloudforms.

ש: האם למעט מחיר ה-Appliance (אם החלטנו לרכוש אותו) יש עלות נוספת שצריך לשלם לפלטפורמת ה-VM?
ת: במקרים של ספקי ענן ציבוריים, תצטרך לשלם לספק הענן הציבורי על Instance של מכונת לינוקס (לא ניתן בשלב זה לרכוש מכונה מוכנה + רשיון דרך ה-AWS Marketplace לדוגמא) + הדיסק והתעבורה.

ש: האם יש תמיכה ב-Cluster/High Availability?
ת: בהחלט! זה אחד הדברים הראשונים שהתיעוד מסביר איך לעשות אם אתה רוצה להשתמש במערכת כ-Cluster.

ש: כמה זמן לוקח לאינטגרטור מטעם רד-האט בארץ להקים PoC של Cloudform מקומית? האם יש גירסת Trial?
ת: זה מאוד תלוי ב-Scope של ה-PoC ותלוי במסמך ה-SoW. לדוגמא: הקמה של Appliance וחיבור לפלטפורמת ה-VM הנוכחית שלכם אפשר לבצע תוך יום עבודה. קאסטומיזציה, טפסים, כתיבת תוספים – אלו דברים שלוקחים זמן נוסף. כל פרויקט לגופו.

לגבי Trial – בהחלט יש.

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

ש: יש לנו שרתים פיזיים רבים (שאינם מריצים VM אלא אפליקציות יעודיות). האם CF/MIQ יכול לסייע בהקמה/ניהול?
ת: כן. ה-CF/MIQ כולל התחברות לשרת PXE וניתן גם להתממשק ל-IPMI שיש בשרת, כך שהוא יכול להתקין מערכת עם Kickstart ולהריץ עליה אוטומציה לבצע דברים שדרושים לשרת.

ש: יש תמיכה ב-LDAP/Active Directory?
ת: בהחלט. מטרת המערכת בסופו של דבר לתת למספר אנשים גדול בחברה להיכנס ולמלא בקשות שונות ולמנהלים לתת הוראות ואישורים.

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

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

על דיסקים SSD בתצורת NVMe/PCIe

בשנתיים האחרונות נכנסה טכנולוגיית דיסקים (SSD) חדשה לשוק – טכנולוגיית ה-NVMe SSD (או PCI SSD – זה אותו דבר). רבים לקחו את עניין ה-SSD הנ"ל כמשהו שהוא יותר אבולוציה מאשר רבולוציה. עד היום היה לנו דיסקים SATA, NL-SAS, SAS ועכשיו יש לנו PCI/NVMe. לא?

זהו, שלא כל כך.

טכנולוגיית ה-NVMe משנה את כל עניין התקשורת של הדיסק SSD עם המחשב. בעבר בכל שרת שמכבד את עצמו היה בקר RAID שאליו היו מחוברים דיסקים. בחלק מהמקרים הדיסקים היו מחוברים ל-2 בקרי RAID, בחלק מהמקרים חצי מהדיסקים בשרת היו מחוברים לבקר אחד והחצי השני לבקר אחר, כל יצרן והשטיקים שלו.

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

בקרי RAID נועדו בראש ובראשונה ליצור לנו "אשכולות" של דיסקים שיחדיו יוכרו כ-RAID Volume. קח לדוגמא אנו יכולים לקחת מספר דיסקים ולבנות RAID 5, או 2 דיסקים ולבנות מהם RAID-1 או RAID-0 אם אנחנו רוצים לאכסן דברים שלא אכפת לנו שימחקו אם דיסק נפל (לדוגמא: Cache לאפליקציות). בקר ה-RAID גם "לקח אחריות" על כל מה שקורה מבחינת חיי ותקינות הדיסקים: בעיות כתיבה/קריאה? הוא יקרא מדיסק אחר. צריך לשמור נתונים בעת הפסקת חשמל? יש זכרון וסוללה על בקר ה-RAID וכך הנתונים ישמרו עד שיחזור החשמל וכשהוא יחזור הבקר יכתוב את הנתונים בצורה נכונה לדיסקים. זה הרעיון המרכזי של בקר RAID.

ב-NVMe לעומת זאת, הדיסק לא מדבר לשום בקר. הדיסק, כמו כל כרטיס PCIe, מדבר ישירות למערכת דרך ה-DMI, כלומר הנתונים עוברים ישירות אל הזכרון (RAM) בשרת וכך נחסך כל ה"תיווך" של הבקר.

אבל עדיין – כמו שכולנו יודעים – צריך בקר לאמצעי אחסון. יש תקלות קריאה/כתיבה, צריך לשמור נתונים בעת הפסקת חשמל, וכאן בדיוק הסיבה מדוע דיסק NVMe הוא דיסק שהוא יקר מדיסק SATA SSD או SAS SSD. בתוך הדיסק עצמו יש בקר (בחלק מהמקרים עם מעבד ARM בעל 2 או 3 ליבות) שכבר מטפל בכל עניין תעבורה ותחזוקת הנתונים. הדיסק עצמו מחולק פנימית ל-RAID-0 (רק בניגוד ל-RAID-0 רגיל, במקרה ויש תקלה בנתונים, הבקר יודע לטפל בה מבלי שהנתונים ינזקו), יש "סופר כבלים" (Super Capacitors) שיודעים לשמור נתונים במקרה של הפסקת חשמל, ומבחינת ביצועים – ה-NVMe ל-Enterprise נע בסביבות ה-2.4 ג'יגהבייט כתיבה לשניה ו-3 ג'יגהבייט קריאה לשניה. יותר זריז מכל SSD RAID שתכינו!

ומה לגבי עמידות/שרידות? הרי לא תסכימו לזרוק את כל הנתונים על דיסק אחד מבלי שיהיה לכך איזה סוג של בטחון, והתשובה לכך נקראת DWPD או Endurance (תלוי ביצרן דיסקים). ה-DWPD מציין כמה פעמים אתה יכול לכתוב על כל הדיסק נתונים ביום והדיסק עדיין יהיה תקין. קחו לדוגמא את ה-DC P3600 של אינטל, שמתאים ל-Enterprise: אם נניח מדובר בגירסת 2 טרהבייט, אז אתה יכול לכתוב עליו עד 6 טרהבייט ליום (מחיקה וכתיבה) והדיסק יעבוד טוב ויעמוד באחריות יצרן.

אז כפי שניתן להבין – אין כיום שום בקר RAID לדיסקים PCI SSD ושיטת העבודה צריכה להיות שונה. חושבים לדוגמא להרים ESXI על מערכת עם 2+ דיסקים כאלו? בהצלחה, תצטרכו לפרמט כל דיסק כ-Datastore בפני עצמו. לעומת זאת, אם אתם מרימים מערכת הפעלה Windows, ודאו שמדובר ב-Windows 2012 ואם זה לינוקס אז Ubuntu LTD האחרון או RedHat/CentOS 7 ומעלה. בתוך מערכת ההפעלה תוכלו לבחור את הדיסקים ולהקים את ה-RAID שרציתם (ותרו על RAID-0 – לא תקבלו ביצועים יותר גבוהים בגלל הארכיטקטורה של NVMe ו-RAID-5 יהווה בזבוז ושחיקת דיסקים לשווא). כמובן שלשם כך יהיה כדאי לצרף לשרת דיסק SSD שאינו NVMe/PCIe כדי להתקין עליו את מערכת ההפעלה.

באם אתם חושבים להרים שרת קבצים (לא חשוב איזו מערכת הפעלה) שתהיה מאוד מהירה וניתנת לגידול בהוספת דיסקים או JBOF – אז מערכת מבוססת דיסקים כאלו (ועדיף שתהיה מחוברת לכרטיסי רשת 10 ג'יגהביט ומעלה בלבד!) תהיה פתרון מעולה. אם אתם רוצים פונקציות כמו הסטורג'ים הגדולים (טוב, לפחות חלק מהפונקציות) כמו DeDup, Compression וכו' – כדאי לחשוב על ZFS.

לסיכום: דיסקים PCIe SSD הם ההווה והעתיד בכל מה שקשור לביצועים. זה לא אומר שצריך לזרוק את כל הדיסקים SAS לפח (מגנטי או SSD) אבל אם משלבים את ה-NVMe SSD כדאי לקחת בחשבון את היתרונות שלו ולהיערך בהתאם ואם אתם קונים שרתים חדשים, אני ממליץ לוודא כי ניתן להכניס אליהם דיסקים של יצרנים אחרים (במיוחד סמסונג, סאנדיסק ואינטל – כולם מאוד אמינים, מנסיון) ואתם לא "נעולים" רק על הדיסקים שמשווק יצרן השרתים שלכם (כמו HPE דור 9) מכיוון שהתחרות בשוק כיום מאוד אגרסיבית והמחירים צונחים משנה לשנה בעשרות אחוזים. דיסקים כאלו גם יכולים להוות בסיס טוב אם אתם רוצים להרים אשכולות (Clusters) מכיוון שכל דיסק נחשב כמספר דיסקים+בקר RAID. השמיים הם הגבול.

אהההמ.. ואם אתם רוצים להקים "חייה" של דיסקים NVMe, תכירו את המכונות האלו של SuperMicro 🙂

על אחסון ווידאו בחברות מדיה

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

בעולם ה-Corporate, סטורג' הינו חלק קריטי מהתשתית. מכונות VM מאוחסנות על סטורג' ולא על דיסקים מקומיים, אפליקציות כמו SQL/Oracle DB דורשות סטורג' (במיוחד אם מריצים כתצורת אשכול [cluster]), כל קבצי העבודה של העובדים (מסמכים, קוד וכו') מאוחסנים בסטורג', גיבויים זמניים מאוחסנים בסטורג' ובקיצור – הסטורג' "נוגע" כמעט בכל תחום. אחרי הכל, כולם מכירים: כשסטורג' נופל – ההיסטריה בשיאה.

בשנים האחרונות, עם חדירת העננים הציבוריים ל-Corporate – השימוש ב-Storage פוחת במעט (ככל שמעבירים VM ושרותים לענן), אך עדיין לסטורג' יש מקום מאוד שוב. יחד עם זאת, כמות השדרוגים או רכישות סטורג' חדש – מתמעטת. אחרי הכל, אם "העפתי" 50 VM ל-AWS לדוגמא, והם יעבדו ב-AWS באופן קבוע, אני אשמור מקומית גיבוי, אבל אני לא אצטרך להשאיר אותם ב-Datastore היקר המקומי, אני אמחק אותם ואז יתפנה לי מקום בסטורג', מה שאומר שרכישת עוד מדף סטורג' תיהפך למיותרת. בנוסף, בעולם ה-Corporate הגדילה היא איטית. לא כל יום מרימים עוד 100 VM (וגם אם מרימים, משתמשים ב-Template כך שרק השינויים נשמרים ולא כל VM שוקל 10 ג'יגה ומעלה).

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

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

מדוע? כי חברות הוידאו דורשות צילום איכותי וגבוה. פעם היו מסתפקים ברזולוציית SD ולאחר מכן העולם קפץ ל-HD ול-Full HD וכיום הרוב מצולם ב-4K או 5K ו-6K וחלק (שמשתמשים ב-RED לדוגמא) מצולם בכלל ב-8K. בניגוד לצילום באייפון (או גוגל פיקסל) – מצלמות מקצועיות מצלמות ב-Bitrate החל מ-20 מגהביט ועד 80-130 מגהביט (ומעלה במקרה של RED אם לא משתמשים ב-REDCODE) ועוד לא דיברנו על ביטים פר ערוץ צבע (8,10,12 וכו') ועוד. במקרים רבים מצלמים ב-2 מצלמות (או יותר), נוסיף אודיו שמוקלט בנפרד, צילומי סטילס (בחלק מהמקרים). את כל הערימה הזו צריך להעלות לאיזה סטורג' כלשהו ובחלק מהמקרים צריך גם לתרגם (Transcode) ל-Codec אחר (מה שנקרא Mezzanine Codec) בכדי לאפשר עבודה רציפה על התכנים בהתאם לתוכנת העריכה המועדפת על החברה. אחרי זה יש צורך בעריכה של הקובץ, הוספת תכנים שונים (אפקטים, תלת מימד, אנימציות, אודיו וכו'), ולבסוף יש צורך שוב בהמרה של התכנים לפורמטים שונים (הוצאה לאולפנים שונים בהתאם לדרישות שלהם, יוטיוב, סטרימינג וכו').

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

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

הבה נאמר שלחברה יש סטורג' כיום זמין שאליו מתחברים עורכי הוידאו ומשתמשים בתכנים. אחרי שהתוכן עבר עריכה והמרה – יש צורך לאחסן את התכנים על מנת שיהיו זמינים מיידית. כאן פתרון Scale Up פתוח (כמו ZFS) יכול להוות פתרון מעולה תוך שימוש בשרת יחיד שאליו משורשרים מספר JBOD ובתוך אותה מערכת יש מספר קטן של דיסקים SSD מהירים והשאר – דיסקים SATA פשוטים (או SAS או NL-SAS, בהתאם לתקציב) וגדולים מאוד (8,10,12 טרהבייט) עם תצורת RAIDZ שמאפשרת מצב שגם אם 2 דיסקים קשיחים נדפקים, התוכן נשאר תקין בצורה זמינה. זיכרו – סטורג' זה משמש רק לאחסון ולא לעבודה ישירות, כך שעורך שצריך תוכן כלשהו, רואה את הקבצים כ-Read Only ללא אפשרות שינוי. נגמר המקום? מוסיפים JBOD גדול עם 36 דיסקים (לדוגמא) וכל דיסק הוא בגודל 10 טרהבייט, ב-RAIDZ2, הרי שנטו נקבל תוספת של 309 טרהבייט, ואם חברה רוצה ממש אחסון של 1 פטהבייט, אז 4 JBOD כאלו מלאים יתנו 1.2 פטהבייט עם שרידות טובה.

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

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

סיכום שנת 2016 – אחסון מבוסס קוד פתוח

שנת 2016 לא התאפיינה בטכנולוגיות פורצות דרך חדשות בעולם ה-Storage בכל הקשור לפתרונות קוד פתוח חינמיים/סמי חינמיים. יחד עם זאת, מי שקיבל תנופה הם פתרונות ה-Scale Out בכל הקשור לסטורג'.

מבחינת מוצרים מסחריים, ScaleIO של EMC יצא השנה בגירסה 2.0 עם שיפורים ניכרים הן בטכנולוגיה והן מבחינת ביצועים (לתשומת ScaleIO – אכפת לכם לרדת משמות ציודים כמו dev/sda/? היום הכל הולך ב-UUID, כך שמי שמזיז דיסקים, לא יקבל שמות שונים ומערכת שנופלת!). עוד ועוד חברות מוציאות Appliances שמשתמשים במוצרי קוד פתוח קיימים (Gluster, Ceph, ZFS) כדי למכור פתרונות Scale Out המאפשרים הרחבה לגדלים של פטהבייטים ומעלה. קשה לפרט כי יש המון כאלו.

מבחינת פתרונות Scale Up, עדיין ZFS שולט בראש, ומוצרים הכוללים אותו (QuantaStor, FreeNAS ואחרים) הולכים ומשתפרים "מסביב" – כלומר הטכנולוגיה נשארת אותה טכנולוגיה, רק שנוספים דברים כמו תמיכה יותר טובה ל-Active Directory, מכונות וירטואליות קטנות שניתן להרים על הקופסא הפיזית של ה-Storage (במקרה של FreeNAS) ועוד. השנה גם אינטל החלה להיכנס בזהירות לתוך ZFS (במיוחד ללינוקס) עם תרומות קוד בכל הקשור לטסטים ונסיונות על מכונות עם דיסקים מרובים (מה לעשות, אין הרבה חברות שמרימות מכונות עם 40+ דיסקים מכניים + SSD רק לשם טסטים). השנה גם עניין ההצפנה נכלל באופן טבעי ב-ZFS עם מספר אפשרויות להצפנה הן ברמת קובץ או Volume וכו'.

מבחינת Scale Out – פתרונות CEPH שולטים כפתרונות קוד פתוח וחינמי/זול. השנה סוף סוף הגיעה היציבות ל-CephFS כך שניתן לבצע ישירות mount ל-CephFS לשרתי לינוקס שונים ללא צורך בהגדרות מיוחדות. השנה החלה גם להיכנס (עדיין לא בצורה יציבה אלא כ-Technology Preview) ה-BlueStore – טכנולוגיה שכותבת את המידע שמגיע ל-Ceph בצורה שונה ויותר אופטימלית כך ששימוש ב-SSD ב-Ceph יכול לתת ביצועים פי 2 ומעלה. עוד דבר חשוב – טכנולוגיות דיסקים חדשות (PMR, SMR וכו') נתמכות ב-BlueStore עוד הרבה לפני הפתרונות הסגורים המסחריים (לא מומלץ להכניס דיסקים SMR לפתרונות סטורג' ל-VM או דברים כאלו, אלו דיסקים שמיועדים לגיבוי וארכיבאות בלבד)

וכמובן, 2 שאלות שאני תמיד נשאל היא "האם שווה לנו לרכוש פתרון כזה? זה נותן מענה?"

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

למי שמחפש את הגירסה הארוכה:

אם נסתכל מבחינת ביצועים נטו, הן ZFS והן Ceph יכולים להוציא מיליוני IOPS בלי יותר מדי בעיות ולשרת משתמשים מרובים בצורה חלקה. כמובן שיש צורך בלהגדיר דברים רבים בשביל להגיע לתוצאות אלו – אך זה בהחלט דבר אפשרי, הן לעבודה מול שרתי וירטואליזציה, עיבוד תמונה, עיבוד וידאו, הזרמת וידאו וכו' וכו'. יחד עם זאת – אני לא ממהר להמליץ לזרוק את ה-Netapp/EMC/3PAR שלכם לטובת מערכות כאלו מהסיבה הפשוטה שיש הרבה דברים שהמערכות הסגורות נותנות וזה כולל ממשק נוח, הרחבות שונות קנייניות שעוזרות בעבודה של הסטורג' ועוד.

ב-2 הפתרונות, ניתן לייצא החוצה קבצים ב-CIFS ו-NFS וכמו כן Block Devices (כמו iSCSI).

בד"כ הסיטואציות שאני ממליץ להשתמש בפתרונות קוד פתוח הן:

  • בתוך LAB
  • בשימוש בוירטואליזציות קוד פתוח (Open Stack, KVM, Xen, Oracle VM, VirtualBox)
  • שרת אחסון נתונים הן כגיבוי והן כהזרמה (Streaming – לגיבוי אני יותר ממליץ את ZFS)
  • צוותי פיתוח (לזה אני ממליץ יותר את ZFS)
  • מקומות עריכה גדולים של וידאו (4K), אודיו וסטילס (פוטושופ)

מבחינת בחירת פתרון – Ceph ו-ZFS דורשים פתרונות חומרה שונים לחלוטין. ב-Ceph מתחילים עם 3 שרתים יעודיים (שלא יריצו כלום חוץ מ-Ceph) ומתג רציני (10 או 40 ג'יגה) וזה הפתרון שמאוד מתאים לחברות שרוצות להגדיל את הנפחים ומהר או להתחיל מההתחלה במאות טרה בייט ולגדול לפטהבייטים ומעלה. לעומת זאת, ZFS שאמנם יכול לגדול ל-Zettabyte עם תוספת בקרים שונים וקופסאות JBOD נוספות, אך הגדילה שלו מעבר לפטהבייטים מצריכה הרמת אשכולות ZFS ושימוש בפתרונות כמו Lustre וזהו עניין שבהחלט אפשרי – אך מורכב.

מבחינת חסכון: פתרון קוד פתוח לא מבטיח עלות אפס גם אם אתם מיישמים לבד הכל. כן, זה יהיה יותר זול מפתרון קנייני, אבל דיסקים, דיסקים SSD ל-Enterprise, המכונות עצמן, מתגים וכו' – עולים לא מעט ותחזוקת החומרה היא עליכם. בנוסף, יש לא מעט מקרים שאני ממליץ (במיוחד ב-Ceph) לרכוש את הגירסה המסחרית של תוכנת הקוד הפתוח על מנת לקבל עדכוני תוכנה ותיקוני תוכנה וכדאי לקחת זאת בחשבון (במקרה של Ceph ישנו הפתרון בישראל של SuSE SES 4 ו-RedHat Storage 2.1 – שתיהן מבוססות על Ceph בגירסת Jewel).

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

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

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

הערה
מאמר זה מדבר על הדיסקים/כוננים המשמשים לאחסון ולא על פתרונות כמו NAS/SAN וכו'.

מבחינת דיסקים/כוננים קשיחים, אנחנו נמצאים בתקופה מאוד מעניינת. ב-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 מכובדים.

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

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

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

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

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

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

mind mapping software

האם אנו צריכים בדיוק אותו דבר למערכת 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.

המלצות לגבי שרת 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).

גילוי נאות
כותב שורות אלו מוכר שרותי יעוץ/הקמה/הגדרות למערכות יוניקס/לינוקס עם ZFS

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 שונות ולבדוק את טיב הביצועים ואז להחליט.