קטגוריה: אחסון / Storage

מה ההבדל האמיתי בין SSD רגיל ל-SSD ל-Enterprise?

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

הרשו לי להציג לכם את ה"יורש" של הסמסונג 850 PRO  שיצא שלשום – אחד מכונני ה-SSD שהצליח במשך 3 שנים להתעלות מעל רוב כונני ה-SSD הביתיים מבחינת ביצועים. זהו הסמסונג 860 PRO. מבחינת ביצועים הן מבדיקות והן "על הנייר" – זו חיה: 560 מגהבייט לשניה בקריאה ו-530 מגהבייט לשניה בכתיבה (זהו כונן בחיבור SATA). מבחינת IOPS יש לו בהחלט מה להתגאות: 100000 בקריאה, 90000 בכתיבה, ואורך החיים שלו – אתם יכולים לכתוב עליו ולמחוק – עד 4800 טרהבייט בכל משך ימי חייו. שום דיסק מכני לא נותן דבר כזה כמובן. מחיר: $238 לחצי טרהבייט.

והנה ה"אח הבכור" – ה-960 PRO בגירסת M.2 NVME. הביצועים? 3.5 ג'יגהבייט קריאה, 1.9 ג'יגהבייט כתיבה. IOPS? טוב ששאלתם: 440000 בקריאה, 360,000 בכתיבה. המחיר: $300 לחצי טרהבייט. אפשר לכתוב עליו באורך חייו כ-400 טרהבייט. (כן, ה-860 מחזיק הרבה יותר).

תכירו את ה-SSD החדש ביותר של אינטל (כתבתי עליו בעבר) – ה-900P. הוא יקר יותר ($628 לגירסה של 480 ג'יגהבייט), הוא יותר איטי בגישה לנתונים (2.5 ג'יגה בקריאה, 2 ג'יגה בכתיבה) אבל כשזה מגיע ל-IOPS, הוא בועט בכולם: 550,000 בקריאה, 500,000 בכתיבה.

אז מי מהם מתאים לחברות ומי לא מתאים לבית? ומדוע ההבדלים?

נתחיל ב-900P (הוא "האח הקטן" של ה-DC P4800X). נניח שאתה רוצה SSD מהיר לבית, אתה עורך וידאו נניח או מוכן לשפוך סכומים רציניים על המחשב למשחקים שלך. הכסף לא ממש משנה לך. האם כדאי לקנות אותו? התשובה היא לא. אם נעמיד את ה-900P במבחן מול ה-960 PRO או ה-860 PRO, שתיהם ינצחו אותו בקלות, כלומר אתה יכול לחסוך 300 דולר ולקבל SSD שיתאים לך לבית.

עכשיו נלך לחברה. נניח שאנחנו מקימים Storage משלנו, נניח שאנחנו מקימים שרת SQL כלשהו (לא חשוב אם זה מיקרוסופט, אורקל או PostgreSQL או MySQL) או שרת אפליקציה שאמור לתת שרות למחשבים רבים או משתמשים רבים. כאן דווקא ה-900P יתן ביצועים הרבה יותר גבוהים בהשוואה ל-2 ה-SSD של סמסונג, הם "יחנקו" מהר מאוד.

ה-SSD ל-Enterprise בעקרון בנוי לתת שרות לכמה שיותר משתמשים/מחשבים/תחנות, כמה שיותר Clients, בשעה שה-2 השניים בנויים לתת שרותים לכמה שפחות, כלומר למחשב אחד, לכמה אפליקציות שרצות במקביל במחשב הביתי/תחנת עבודה. במילים אחרות – אם לא מעמיסים על דיסק SSD ל-Enterprise אתם תקבלו ביצועים רחוקים מאוד ממה שמוצהר ע"י היצרן.

פרסמתי כאן בתחילת השנה פוסט על SSD ל-Enterprise והוא רלוונטי בדיוק לפוסט זה. בפוסט הקודם הזכרתי את ה-QD (ה-Queue Depth) שצריך אותו כדי לתת שרותים לכמה שיותר Clients וזה בדיוק מה ש-SSD ל-Enterprise מצטיין בו ו-SSD לבית גרוע בו. ניקח לדוגמא את ה-960 PRO, אם תסתכלו בסקירה זו תיראו שברגע שמתחילים להעמיס עליו, הביצועים צונחים דרמטית.

עכשיו נשארנו עם בעיה אחת: נניח ואנחנו רוצים ביצועים מאוד גבוהים לשרתים עם דיסקים מקומיים (כן, לאלו שמריצים vSphere עם דיסקים מקומיים לדוגמא) אבל המחיר מפחיד. ה-DC P4800X לדוגמא בגירסה צנועה של 375 ג'יגהבייט עולה $1700 (המחיר קצת יקר באמזון, המחיר הרשמי הוא $1520) וגירסת ה-750 ג'יגהבייט עולה מחיר "צנוע" של $3,653. במחיר כזה, גם חברות גדולות מתחילות לחשוב פעמיים אם לקנות במחיר כזה.

מה ניתן לעשות? ישנן מס' אפשרויות:

  • לקנות כמה קטנים. אפשר לדוגמא לרכוש 2 כרטיסי 900P (אגב, אם השרתים שלכם חדשים, אז ניתן לקנות את ה-900P בגירסת U.2 שנכנסת מקדימה) ולחבר אותם ב-RAID-0 ולהגדיר אותם כ-Cache. זה מתאים למצבים שאנחנו רוצים להריץ את השרת כשרת קבצים או כשרת NFS/SAMBA ואליו נחבר לדוגמא שרתי vSphere.
  • אם אנחנו רוצים להריץ שרת SQL או שרת אפליקציה כבד, נוסיף דיסק SSD כלשהו למערכת, עליו נתקין את מערכת ההפעלה והאפליקציות אך ה-DATA ישב ב-RAID-0 (מתוך הנחה שיש לכם גיבוי יומי!) כ"כונן" נפרד.
  • נבחר כונני Enterprise יותר זולים. לאינטל יש את ה-750 שישן קצת (מ-2015) אבל נותן ביצועים יותר טובים, יש את ה-P4600 ו-4700, שהם מעולים. חברות גדולות, כמובן, לא קונות כוננים ישירות מאינטל או סמסונג, ולכן מומלץ לחברות אלו לבדוק מיצרן השרת שלהם אלו דיסקים ניתן לקנות (לא מומלץ לקנות עם חיבור SAS, לכולן יש פאנל קדמי לחיבור דיסקים SSD בחיבור U.2 או SATA).

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

על פריצת ה-Spectre V2

בפעם הקודמת כתבתי כאן על הפריצות Meltdown ו-Spectre, על תיקונים ועל ביצועים. הפעם אני מעוניין להתעכב על Spectre גירסה 2 (V2), ומה קורה עם זה.. למעוניינים: פריצת Meltdown כבר תוקנה, ה-Spectre V1 גם (פחות או יותר) אבל Spectre V2 מתגלה כבעיה עקשנית..

והאצבעות מופנות הפעם ל… אינטל. (היתה בעיה עם מעבדי AMD, היא כבר טופלה [כולל במעדי Epyc ו-Threadripper]).

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

את הפירצה בגירסה 2 של Spectre אפשר לסכם בפשטות כך: מריצים VM בוירטואליזציה כלשהי? (באמת שלא חשוב מה פתרון הוירטואליזציה, כולם משתמשים ב-VT-X, VT-D במעבדי אינטל) אז מאותו VM ניתן להגיע למכונות VM אחרות ול-HOST עצמו. מריצים קונטיינרים? אז מהקונטיינר ניתן להגיע אל ה-HOST עצמו וב-2 המקרים מספיק קוד זדוני די קטן כדי להשתמש בפירצה. מספיק חמור?

בניגוד למקרים אחרים, בכדי לטפל ב-Spectre V2 צריך עדכון מיקרוקוד ישירות למעבד וכאן הדברים מתחילים להיות טיפה יותר מורכבים: כשזה מגיע ללינוקס ול-VMWare (נו טוב, VMWare בחלקן מכיל תואמות ברמת ה-Host ללינוקס ברמה של ABI) – אז עדכון המיקרוקוד מגיע מיצרן הפצת הלינוקס או מ-VMWare, כך שלא צריך לפנות ליצרן החומרה כדי לקבל את העדכונים. בעקרון, לינוקס קורא אמנם את הגדרות ה-UEFI/BIOS אבל לא מתייחס לכל ההגדרות ברצינות (מפתחי Kernel ותיקים בלינוקס די מזלזלים במימושי ה-UEFI/BIOS, בהצדקה מסויימת).

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

אינטל שחררה עדכוני מיקרוקוד ויצרניות הפצת הלינוקס הכניסו אותו לעדכוני הפצת לינוקס, וגם VMWare הכניסה את העדכון (דרך ה-VUM), אלא שאז התגלתה הפדיחה של אינטל. כנראה שאינטל לא ביצעה מספיק ניסויים ובדיקות על מעבדי E5/E7 V3, V4 וחלק מהחברות שעדכנו את המיקרוקוד קיבלו "הפתעה" לא נעימה – אתה מפעיל את המכונה, מתחיל לבצע עבודות ולפתע – המחשב מבצע לעצמו Reset. אין לוגים, אין כלום. נסו לדמיין את זה על שרת שמריץ ESXI או איזה שרת DB כבד שפתאום מנתקים לו את החשמל.

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

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

שימו לב: ההבדל העיקרי בין עדכונים מיצרן השרת לבין עדכוני לינוקס/VMWare בכל הקשור למיקרוקוד, הוא שבמערכות לינוקס/VMWare, עדכוני המיקרוקוד חלים על המערכת זמנית, אחר ה-Boot ואילו עדכוני המיקרוקוד של יצרן השרתים שנמצאים בחבילת ה-BIOS/UEFI הם קבועים. זה לא כל כך משנה בלינוקס וב-VMware אולם בהחלט משנים ברמה של מערכות מבוססות Windows.

אז מה עושים כרגע? לא ניתן לעשות יותר מדי דברים עד שיצא עדכון חדש. בשלב זה אם תיפנו ל-Red Hat (ואתם לא לקוח גדול כמו בנק או חברת Fortune 500) אז תופנו בנימוס ליצרן השרת שיטפל בכם (ויצרן השרת יפנה בנימוס ל-Red Hat כי עם כל הכבוד, תמיכת הלינוקס של יצרני השרתים היא לא בדיוק רמה גבוהה..) ואם תפנו בנימוס לאינטל, היא תפנה אותך ליצרן מערכת ההפעלה שלך ואם מערכת ההפעלה שלך היא Windows אתה תופנה בנימוס ל.. יצרן המכונה שלך. כיף!!

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

לסיכום: כרגע, לא ניתן לעשות הרבה זולת המתנה לאינטל שישחררו עדכון מיקרוקוד יותר יציב שנבדק על מעבדים ישנים יותר. אם יש לכם מערכות סריקה (IPS ושאר קיצורי שמות) – אני מאמין שהם הוציאו עדכוני חתימות לגלות אם מישהו מנסה להזריק לכם קוד שמשתמש ב-Spectre (אבל אני לא בטוח כמה זה יתפוס, אפשר להשתמש בפירצה הזו גם עם קוד JS פשוט ובמקרים רבים ניתן פשוט לבצע code obfuscation ["ערפול קוד"], במיוחד כשיש לכם מערכות חשופות לאינטרנט).

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

אחסון אובייקטים (Object storage) ו-Ceph

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

באופן עקרוני, בניגוד ל-GlusterFS ו-ZFS, ה-Ceph היא מערכת מבוססים אחסון קבצים (Object Storage). היתרון במערכת כזו היא שהיא "מפשיטה" את כל המורכבות של File System רגיל (כמו XFS, EXT4 וכו') ל"קוביות" קטנות אחידות בגודל 64 קילובייט ואת אותן "קוביות" (שהם בעצם Objects) המערכת משכפלת לשרתים אחרים על מנת ליצור שרידות גבוהה מצד אחד, והם נגישים ל-Clients השונים מכל שכפול, כך קורה מצב שאם לדוגמא מספר מכונות דורשות את אותו קובץ, הוא נקרא משרתים שונים. בנוסף, מאותו Object Storage המערכת בונה גם שרותים אחרים שהיא מציעה, בין אם מדובר באחסון דומה ל-S3, אחסון File System, או NFS (ש"רוכב" על ה-File System") או אחסון "בלוקים" עבור iSCSI.

עם Ceph ניתן לאחסן מיליוני קבצים (ומעלה) עם גישה מאוד מהירה כאשר מגדירים את האחסון וקריאה כמו שקוראים לקבצים ב-S3. היכן זה יכול לעזור לדוגמא? כאשר רוצים לשדר וידאו. בדרך כלל לא מומלץ לחבר שרתי שידור (כמו WOWZA) לאחסון כמו Ceph, אלא מחברים זאת למערכת CDN טובה שהיא מפיצה את התוכן לנקודות EDGE/POP במקומות שונים בארץ/בעולם ומאותן נקודות השידור עצמו מתבצע. באותה שיטה (רק ללא צורך ב-CDN ברוב המקרים) ניתן לדוגמא להקים ארכיב ענק של קבצי מסמכים (גם בגודל של פטהבייטים רבים) ולאפשר גישה מאובטחת למסמכים דרך REST API שניגש ל-RADOS ב-Ceph שמחבר את אותן "קוביות" לאובייקטים ומשם האפליקציה יכולה לקרוא את המסמך ולהנגיש אותו עבור הלקוח. יתרון נוסף הוא באבטחה: אם מישהו מחר גונב שרת ומצפה למצוא את הקבצים שהוא מעניין בהם, הוא יתאכזב לראות שאין ממש קבצי DOC/PDF, יש "קוביות" וצריך את כל המערכת בכדי לקבל את הקבצים הרצויים.

טכנולוגיה חדשה שנכנסת לשוק בשנים האחרונות הם אמצעי אחסון מוכוונים KV (כלומר Key Value) והם מיועדים בראש ובראשונה לאחסן אובייקטים. חברת Seagate לדוגמא הדגימה דיסקים מסוג SMR (שהם דיסקים המיועדים לארכיב – Shingled Magnetic Recorder) בצירוב SSD מאיץ מסוג Nytro נותן ביצועים גבוהים פי 11 בהשוואה לדיסקים מכניים רגילים עם Ceph (ניתן לקרוא על כך ולראות וידאו בנושא כאן).

במסגרת תערוכת CES האחרונה, סמסונג הציגה SSD בפורמט חדש (NGSFF) לשרתים, זהו ה-PM983 וניתן לרכוש אותו בגודל של 8 טרהבייט ובמחצית השניה של השנה, הדגם הזה ימכר בגודל מדהים של 16 טרהבייט למקל. חברת Supermicro הכריזה על שרת פיצה (דגם:SSG-1029P-NMR36L – שם ממש קליט…) בגודל 1U שיכול לאחסן 36 מקלות כאלו, כך שניתן לאחסן 288 טרהבייט על שרת כזה. זה נראה כך:

Supermicro_SSG_1029P_NMR36L

היתרון בשרת כזו הוא שהוא בנוי כולו לאחסון של Ceph. מקלות זכרון האחסון של סמסונג מובנים מראש לאחסון KV וסמסונג מדגימה זאת בתמונה הבאה:

Samsung_KV_Stack_diagram

כפי שאתם יכולים לראות, מצד שמאל זה המצב הרגיל שקיים כיום כשמקימים אחסון מבוסס Ceph: מכניסים דיסקים רגילים או SSD, יוצרים פרטישנים, File System ואז משם מקימים את ה-KV Store שעליו מאוחסנים האובייקטים. מצד ימין רואים פתרון של סמסונג שכל מה שצריך הוא דרייבר והשאר נעשה בצורה טבעית על קושחת ה-SSD, אין צורך בשכבת "המרה" בחזרה ל-File System. במילים אחרות: אם תרכשו לקראת הרבעון השלישי את המכונה הזו ומקלות של 16 טרהבייט, תוכלו לקבל עם 10 מכונות כאלו 5 פטהבייט לאחסון אובייקטים. פעם זה היה לוקח ארון שלם..

לסיכום: כשצריכים לאחסן המון קבצים (כשמדובר במיליונים ומעלה) אחסון מבוסס Object Storage הוא הפתרון, ואמזון הדגימה זאת לעולם במסגרת שרותי ה-S3 שלה, ו-Ceph נותן בדיוק את אותו פתרון, ועתה גם חברות חומרה נכנסות ומציעות אחסון בצורה טבעית שמורידה את כל שלב התרגום מ-Object ל-File system ובחזרה. זהו אינו פתרון זול (ובוודאי לא פתרון להחליף File Server רגיל) – אך פתרונות כאלו מציעים שרידות וביצועים למי שצריך זאת ומוכן לשלם על כך. למעוניינים בפתרונות Ceph בארץ אני ממליץ לפנות ל-SuSE ישראל.

הבאג הקריטי במעבדי אינטל – עדכונים

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

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

בפעם שעברה דיברתי על הנחתה בביצועים בין 5 ל-30%, וכאן יש לעדכן: זה תלוי במעבדים בשרתים. מעבדים עד 5 שנים אחורה. מעבדים כמו Xeon E3/E5/E7 V3 ומעלה יש בתוכם פונקציונאליות שעוזרת למגר את הנחתת הביצועים כך שלא תהיה הנחתה משמעותית בביצועים, אולי אחוזים בודדים.

במעבדים היותר ישנים (שרתים כמו DELL דור 11 ומטה, HPE דור 7 ומטה, לנובו/IBM דור M3 ומטה) עדיין יורגשו הנחתות בביצועים במקרים מסויימים. המקרה הכי נפוץ שמצאתי הוא שכשמריצים שרתים כאלו כ-Hypervisor (כמו Hyper-V או ESXi) ומריצים את המכונות דרך Datastore שעובד על דיסקים מקומיים. מכיוון שלשרתים אלו אין אפשרות להיות משודרגים למעבדים מדור 3 ו-4 (טוב, למעט SuperMicro ששם אתה יכול להחליף לוח אם, בנוסף למעבדים, ובנוסף גם זכרון..) – האפשרויות שישנם הינן:

  • להקים מכונת VM שמחוברת לבקר דיסקים ולהריץ עליה מערכת שרות קבצים NFS/iSCSI.
  • להקים פתרון כמו שתיארתי לעיל אבל בתצורה פיזית.
  • לקנות פתרון סטורג' כלשהו.

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

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

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

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

לסיכום: מכיוון שרוב החברות הגדולות כבר לא מחזיקות בשרתים ישנים – אז הבעיה אינה כל כך חמורה בכל הקשור ל-Meltdown. בנוגע ל-Spectre בגירסה הראשונה, העדכון לא מוריד ביצועים (והתיקונים לגירסה השניה יעשו הן ע"י יצרניות מערכות הפעלה והן ע"י יצרניות אפליקציות). עדיין נשארו בעיות בכל הקשור ל-Spectre על טלפונים מבוססי אנדרואיד ועדכונים יצאו ע"י יצרני הטלפונים (ואם יש לכם מכשירים ישנים, אולי כדאי להחליף להם ROM למשהו כמו LineageOS). מבחינת ספקי ענן – כולם משתמשים בציוד די חדיש וכולם מעדכנים את כל השרתים שלהם, יכול להיות שתקבלו הודעה מנומסת מהן לעשות Reboot ל-Instances שלכם. מבחינת מחשבי Desktop, לאפטופים – ההנחתה בביצועים כמעט ולא קיימת. מה שהכי חשוב – יש לעדכן את כל השרתים ולבצע לאחר מכן Reboot לאותם שרתים.

כמה מילים על SSD ל-Enterprise

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

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

התשובה לכך פשוטה וקשורה ל… תור, ספציפית לדבר שנקרא QD (כלומר: Queue Depth). המושג QD אומר בעצם כמה פעולות הבקר והדיסק יכולים להתמודד מבחינת תור. נסו לדמיין את עצמכם בסופרמרקט, זה עתה סיימתם להכניס מוצרים לעגלה ואתם עוברים לקופות. בד"כ אתם לא תגיעו ישר לקופאית, אלא תמתינו בתור כמו כל אחד אחר (טוב, תמיד יש תחמנים אבל זה משהו אחר) עד שיגיע תורכם להעלות את המוצרים מהעגלה למסוע, לתת לקופאית להעביר את המוצרים בסורק ולבסוף לשלם על המוצרים. ככל שיש יותר קופות פתוחות, התורים מתקצרים, וזה ההבדל הגדול בין דיסק SAS ל-SATA: בדיסק SATA יש 32 ערוצי תורים, ב-SAS יש 254 תורים, כך ש-SAS תמיד ישרת את הפניות יותר מהר.

עכשיו נשנה את הסיטואציה: אין קופאיות, העגלה בעצמה סורקת את המוצרים שלך ואז אתה מעביר את כרטיס האשראי בעמדות תשלום. האם התור יתקצר? בוודאי, תוך 2-3 דקות תוכל לסיים את הקניה, להעביר לשקיות ולצאת (טוב נו, בתיאוריה) – וזה מה שקורה עם SATA SSD: בגלל שה-SSD מאד מהיר והוא יודע בדיוק כל קובץ היכן הוא נמצא ואין צורך בראשים שיגיעו ויתחילו לקרוא את הנתונים ממקומות שונים, אז כתיבת/קריאת הנתונים תהיה מאוד זריזה, בוודאי כשנשווה זאת מול דיסק SAS מכני ולא חשוב מה תהיה מהירות ה-RPM שלו. בנוסף, דיסק SSD SATA טוב מגיע למהירות קריאה/כתיבה לפחות כפולה מכל דיסק SAS מכני והוא מריץ את ה-QD המוגבל שלו הרבה יותר יעיל ומהר מדיסק SAS מכני.

עוד סוג דיסקים שקיים הוא SAS SSD. טכנית, הדיסק נותן מהירות כפולה מדיסק SATA SSD, אך אם תבדקו אצל יצרנים שונים, תראו שהם פשוט כבר כמעט לא מייצרים כאלו מהסיבה הפשוטה: אם אתה רוצה משהו יותר מהיר מ-SATA, עבור ל-NVME. סמסונג, לדוגמא, מייצרת רק דיסק SSD אחד בחיבור SAS, והוא ה-PM1633a שמיוצר בגודל מרשים של 15.3 טרהבייט. המחיר? 4500$ לחתיכה. משום מה אני בספק אם יהיו רבים בארץ שיקנו אותו.

דיסקים NVME לא מתחברים לשום בקר RAID אלא מתחברים דרך חיבור U.2 (שהוא בעצם PCIe X4) ישירות ללוח ולמעבד (אם כי בחלק מהמקרים הוא עובר דרך צ'יפ "Switch" שנקרא PLX כי בלוח אין הרבה יציאות PCIe בלוחות מבוססי אינטל, ב-AMD Epyc התמונה אחרת לגמרי).

דיסקים SSD NVME בנוים בתצורה כזו של שרידות מאוד גבוהה, כך שאפשר לעבוד עליהם כיחידים או שניתן לקבוע זוג (דרך ה-BIOS/UEFI) כ-RAID-1 בשביל שרידות טובה או RAID-0 בשביל איחוד מקום (הדיסקים האלו הרבה יותר אמינים מכל דיסק SAS והם יודעים בעצמם לתקן שגיאות, בגלל זה יש להם גם אחריות של 5 שנים), אבל לפני שרצים חשוב לשים לב לא לקנות את הכי יקרים מהסיבה הפשוטה: אם אתם מייעדים את הדיסקים לשימוש אותו שרת מקומי בלבד או אם אתם מכניסים את זה לשרת קבצים שישרת 2-4 שרתים, אז הדיסקים המאוד יקרים לא יתנו לכם את הביצועים שאתם צריכים, בשביל שיתנו ביצועים גבוהים, צריכים כמה שיותר שרתים ושרותים שיכתבו ויקראו לדיסק, כלומר צריך למלא את ה-QD והרבה – בד"כ QD של 128 ידע לנצל את הדיסק הזה ואגב, אם SAS יכול לתת 254 תורים, דיסק NVME יכול לתת.. 50,000 תורים וכמה שתמלא את התור הזה הביצועים יהיו יותר גבוהים, לכן מומלצים דיסקים NVME מהסוג כמו של סמסונג כמו ה-PM863a  שמכיל 1 טרהבייט ועולה (בחו"ל) 480$. חשוב גם להכניס למחיר פאנל קדמי שיודע לתמוך ב-NVME (זה מגיע רק בתוספת תשלום ובחלק מהדגמים רק לחלק מהפאנל).

נקודה חשובה נוספת בשיקול היא דיסקים SSD עם או בלי סופר-קבלים (Supercapacitors). ישנם דיסקים רבים ל-Enterprise שמכילים זאת ובכך הם שומרים נתונים שעדיין לא נכתבו בעת הפסקת חשמל. זהו דבר חשוב אם אתם קונים דיסקים NVME, אולם אם הדיסקים הם SATA SSD, בד"כ הסוללה על הבקר תשמור את הנתונים עד לחזרת החשמל. כדאי לקחת זאת בחשבון.

לסיכום: מעבר ל-SSD זה דבר שיכול רק להועיל. לא חייבים לשרוף את התקציב השנתי על דיסקים ולא תמיד חייבים דיסקים Enterprise במקרים של SSD, אבל אם גם הולכים על דיסקים Enterprise, אין תמיד הצדקה לרכוש את היקרים ביותר – מכיוון שהם לא יתנו את הביצועים אם הדברים שאנחנו הולכים לבצע לא "קורעים" את ה-QD. לא מומלץ לנסות להקים RAID-5/RAID-6 על דיסקים NVME (ולמען האמת גם לא על SATA SSD) כי זה יקצר את חייהם משמעותית ולכן עדיף לרכוש דיסקים מעט יותר גדולים ולחבר אותם (דרך ה-BIOS/UEFI או תוכנת Storage) כ-RAID-1/RAID-10.

פתרון GlusterFS – היכן הוא מתאים לכם?

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

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

נתחיל בהצהרה די פשוטה: למרות שטכנית ניתן לבנות את GlusterFS כפתרון שיכול לתת "פייט" רציני לכל פתרון אחסון Scale Up מסחרי, לא תמצאו אותי מחר אץ רץ לחברות תקשורת, בנקים וכו' וממליץ להם בחום לזרוק את פתרון האחסון שלהם לטובת GlusterFS, בדיוק כמו שפתרון VSAN של VMWare אינו פתרון להחליף סטורג' רציני עתיר משאבים. אלו 2 דברים שונים לחלוטין.

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

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

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

סיטואציה ראשונה
כאחד שנותן שרותי תמיכה ל-vSphere לגרסאותיו השונות, יש לי מילים חמות לאמר על VSAN. זהו פתרון אמין מאוד עם שרידות גבוהה מאוד ללא צורך בסטורג'. עם VSAN אפשר להגדיר פונקציות שונות כמו פונקציית שרידות מאוד גבוהה כך שמתוך קבוצה של 3 שרתים פיזיים, 2 נכבים, אפשר להגדיר ש-VM קריטי עדיין ישרוד.
הבעיה המרכזית עם VSAN אינה טכנית, אלא בעיה כספית. במחיר של $2500 לרשיון פר מעבד, על קבוצה של 3 שרתים פיזיים, אנחנו מדברים על 15,000$ וזה לא כולל את הרשיון היעודי של vSphere ולא כולל תמיכה של 3 שנים (שזה עוד 15,000$) ועוד לא הגענו בכלל למחירי הדיסקים – במיוחד שעם VSAN חובה ללכת בתצורת קבוצות של 2+1 (כלומר 2 דיסקים מכניים ו-1 SSD אם כי אפשר ללכת בתצורה היותר יקרה של 3 SSD ונוסיף לכך שאתה צריך שרתים מהדור האחרון או לפניו כדי להריץ את כל הדברים. מחיר כזה, לדעתי, אינו מוצדק עבור Dev, stage, testing, POC וכו'. במחיר כזה חברות כבר יחשבו על קניית אחסון יעודי.

במקום זה, אנחנו יכולים לקחת 3 מכונות שדווקא אינן חדשות (כל עוד בקר הדיסקים שלהם תומך ב-6 ג'יגהביט SATA/SAS, אם זה תומך רק ב-SATA 2.0, אז אפשר להכניס כרטיס בקר צד ג') כמו דור 7 של HP, דור 11 של DELL, דור 3 של LENOVO, ולמלא אותן בדיסקים. ניקח דוגמא: 10 דיסקים SATA של WD RED PRO (מחיר של 319$ באמזון פר דיסק, המחיר קצת יותר יקר אצל המפיץ בארץ) או WD GOLD Enterprise בגודל 10 טרה שעולה $361 פר דיסק, או Seagate מסידרת EXOS ל-Enterprise בגודל 10 טרהבייט שגם עולה $360. סה"כ עד כה – בערך $3600 (פר שרת). נוסיף עוד 2 דיסקים SSD – אם מחפשים זול וטוב, אז 2 דיסקים מה-850 PRO של סמסונג יוכלים לעבוד טוב (סה"כ 418$)ואם המכונה היא 2U, אז 2 כרטיסי SSD PCIE מסוג אינטל 900P 280GB AIC בתצורת PCIE (סה"כ 780$) יכולים לתת Cache די רציני למכונה.

ניקח את הבקר (ואת כרטיסי ה-PCIE) ונצמיד את כולם למכונת VM, נצמיד לה 32 ג'יגהבייט זכרון ו-4 ליבות, ועליה נרים GlusterFS (אם אתם מעוניינים בדחיסה, Dedup ושאר תפנוקים – יש צורך להקים עליה ZFS ועל זה GlusterFS), נחבר את המכונות ברשת פרטית וברשת "ציבורית") (כלומר 2 כרטיסי רשת וירטואלית פר VM של GlusterFS) והרי לנו תחליף ל-VSAN שיכול לתת לנו iSCSI, CIFS, NFS, אחסון אובייקטים (Object Storage) ועוד ועוד. בשביל ביצועים ושרידות נצטרך עוד מכונה כזו (עדיף עוד 2) – ויש לנו אחסון עם שרידות חזקה וביצועים גבוהים, ובו זמנית אפשר להריץ על השרתים עוד מכונות VM, ואת כל זה נעשה דרך ה-vSphere, כך שמבחינת עלות – שילמנו רק על החומרה ולא הפכנו את השרתים היעודיים לסטורג' בלבד (כך שלא נצטרך לבזבז שרתים). מבחינת גיבוי – זה VM ואפשר לגבות בכל תוכנה שמשתמשים בחברה (רק שחשוב לזכור לא לגבות את כל ה-VM שמריצים GlusterFS אלא רק אחד, חבל לשמור את הנתונים באותו גיבוי 3 פעמים).

סיטואציה שניה – אפליקציות
קונטיינרים הם ה"שוס" בשנתיים האחרונות ורבים מעבירים חלק מהמערכות לרוץ בקונטיינרים, שזה מעולה, אבל בחלק מהמקרים עדיין מעדיפים להריץ אפליקציות מסויימות בהכפלה וכו', לדוגמא MySQL על 2-3 מכונות VM, שרתי Front ו-Back על מספר מכונות VM ועוד. בכל המקרים הללו, באותם שרתים ניתן להקים GlusterFS כ-VM כמו שתיארתי לעיל (עם פחות דיסקים, רק חשוב שיהיה לפחות SSD אחד שישמש כ-Cache) ואז ה-DATA של האפליקציה (לדוגמא עם MySQL התיקיה var/lib/mysql/) תשב ב-GlusterFS (איך עושים? עוקבים אחרי ההוראות כאן), ה-WWW של שרת ה-Web ישב ב-GlusterFS וכו' וכו'. יהיו מספר שינויים קטנים שצריך לבצע (אולי להשתמש ב-HAProxy), וכך נוכל לקבל שרידות רצינית ומהירות משופרת בהרבה מכיוון שכל שרת אפליקציות יכול לקבל נתונים משרת GlusterFS קרוב וסינכרון הנתונים הוא מיידי – מבלי להשקיע כספים רבים.

סיטואציה שלישית – קונטיינרים/Kubernetes/Openshift
קונטיינרים רצים בד"כ על שרתי VM וקבצי ה-YAML, קבצי קונפיגורציות יושבים על דיסקים מקומיים אך ניתן להגדיר את ה-VM שירוצו על דיסקים וירטואליים שה-vSphere יקבל מ-GlusterFS דרך NFS או iSCSI. בנוסף, ניתן להגדיר Volumes עבור ה-Pods שישתמשו ב-GlusterFS (גם Kubernetes וגם אפליקציות שמריצות את Kubernetes כמנוע כמו Rancher, OpenShift וכו' תומכים ב-GlusterFS החל מ-Kubernetes 1.5). ואנחנו יכולים להשתמש לדוגמא ב-Volume מסויים במספר Pods במקביל, ועם GlusterFS ניתן לוותר על הרצת קבצי YAML/JSON ליצור את ה-Volumes ולגשת ישר ל-Volume Claim, המערכת תיצור את ה-Volume אוטומטית.

סיטואציה רביעית – בענן
מכיוון של-GlusterFS לא אכפת מה נמצא מתחתיו (דיסק מסכן, EBS וכו'), אפשר להקים את GlusterFS גם בענן. כל מה שאנחנו נצטרך הם מספר Instances (מומלץ 3 ומעלה לפרודקשן, 2 לטסטים) ולאותם Instances (שישמשו כ-Nodes) נחבר 2-3 אחסוני EBS ונתקין את GlusterFS ומשם אנחנו יכולים להשתמש ב-GlusterFS כפתרון אחסון לצרכים שלנו.

סיטואציה חמישית – קרוב רחוק
הקמה של GlusterFS זה דבר טוב ועוזר, אולם לפעמים אנחנו צריכים את הנתונים בחוץ, בחוות שרתים אחרת בארץ או בחו"ל. לשם כך, החל מ-GlusterFS 3.8 ומעלה ניתן להריץ Geo Replication לסנכרן בין מספר Volumes (בשיטת Master/Slave), ואפשר גם לספק צרכים "מופרעים" כאלו:

סיטואציה 6 – פתרון אחסון ל-VDI
הקמת VDI למאות עובדים זה פרויקט מורכב עם עלויות אסטרונומיות. (בימים אלו אני מנסה בבית להקים פתרון VDI עם דגש על מחירים נמוכים, ברגע שאצליח, אפרסם פוסט על כך). יש צורך לשלם למיקרוסופט, ל-VMWare וכמובן כל נציג מכירות יאמר לך – All Flash Array, כך שאם תרצה פתרון VDI טוב, תחשוב על כך סכום של 7 ספרות.

האם GlusterFS יכול לחסוך כאן במחיר? התשובה היא בהחלט. נתחיל בגירסה הזולה: זוכרים שהמלצתי על השרתים הישנים להרצת GlusterFS? אנחנו נשתמש בכאלו בגודל 2U עם פאנל קידמי של כונני 2.5 אינטש כך שאפשר יהיה להכניס בין 16 ל-24 דיסקים 2.5". לתוכם נכניס דיסקים 850 PRO של סמסונג בגודל שתבחרו, יש עד 2 טרהבייט (יש לוודא שהבקר דיסקים תומך במצב JBOD ושהוא תומך ב-SATA-3, אם לא – יש צורך בבקר אחר) ונכניס את הדיסקים הנ"ל למגירות ונצטרך לרכוש או אינטל 900P בגודל 480 ג'יגה או 2 כרטיסי אינטל 900P בגודל 280 ג'יגה, הכל לפי התקציב (עם 2 כרטיסים השרידות הרבה יותר גבוהה). על כל שרת כזה נקים ZFS עם Hot Spare ל-2 דיסקים SSD. כל ה-RAID יוגדר דרך ה-ZFS (כלומר RAIDZ לפי תצורה שמחליטים) ועל זה נקים את GlusterFS. את החיבור בין השרתים נחבר ב-10 ג'יגהביט (נחושת, SFF, FC – החלטה שלכם) ואת הזכרון נמלא ב-ECC 3 8500R (שהוא פחות מהיר אבל המהירות אינה ממש חשובה כשהשרת משמש Node ל-Gluster, הזכרון משמש בראש וראשונה כ-Cache ב-ZFS) עד המקסימום. המחיר לא כזה יקר: 2000 שקל (תלוי מהיכן אתם קונים) ל-192 ג'יגהבייט זכרון. נצטרך 3 מכונות. שימו לב: בשרת כזה נרוץ "על הברזל" ללא וירטואליזציה כלל ונוכל לגבות אותו כמו כל תחנת לינוקס (אם כי צריך לגבות רק אחד מהם, לא את שלושתם).

אם יש לכם כמה וכמה שרתים ישנים, אפשר לפצל את כמות הדיסקים לפי כמות השרתים הישנים שלכם (לדוגמא – 6 דיסקים בשרת 1U) ובכך לקבל ביצועים יותר גבוהים הואיל ולא מדובר בסיטואציית Active/Passive אלא עבודת קריאה/כתיבה מקבילית לכל המכונות.

אם מצד שני יש תקציב – אפשר לרכוש 3 שרתים כשהפאנל הקדמי שלהם הוא NVME ונרכוש דיסקים NVME U.2 – גם סמסונג וגם אינטל מוכרים דיסקים מעולים, והעלות משתנה לפי גודל הדיסק והפירמה שקונים ממנה. מבחינת רשת, תצטרכו לחשוב איך לחבר את הכל מכיוון שברוטו, תעבורת הקריאה מגיעה בין 40-60 ג'יגהבייט לשניה. אפשרי לצמד מס' כרטיסי רשת 10 ג'יגהביט או לרכוש כרטיסים ו-Switch של 40 ג'יגהביט (מלאנוקס, אינטל וכו' ישמחו למכור לכם). עם ההצעה הזו, המחיר שתצטרכו לשלם בהשוואה לפתרון אחסון מבוסס AFA (כלומר All Flash Array) יהיה נמוך יותר ב-50-70% מפתרון קופסא, וגם יש לכם שרידות יותר גבוהה.

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

ומה עם תמיכה? רד האט מוכרת את פתרון ה-GlusterFS כמוצר (Red Hat Gluster Storage) עם תמיכה מסביב לשעון.

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

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

אחד מול השני: Ceph מול GlusterFS

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

2 הפתרונות שבגינן יש בלבול רב הם GlusterFS מול Ceph. למרות ש-2 הפתרונות הם פתרונות Scale Up, יש שוני גדול ביניהם שכדאי להכיר לפני שחושבים לאמץ פתרון זה או אחר.

נתחיל ב-Ceph. מערכת Ceph היא מערכת "חייתית" שהמטרה שלה אחת היא: לתת ביצועים מקסימליים לחברות שמוכנות להשקיע בתשתית. באופן עקרוני, מערכת Ceph שולטת במכונות האחסון בדברים מ-א' ועד ת' – הן שולטות על הדיסקים, המערכת שולטת לאן כל דבר יכתב ואיך יכתב ומהיכן צריך לשחזר ואיך לשחזר במקרה שקם צורך להתקין מכונה אחרת במקום אחת שהלכה, ובגלל זה חישוב האחסון הוא מעט שונה: על כל ג'יגהבייט שתרצה לאחסן, תצטרך בדיסקים מקום של 3 ג'יגהבייט לערך (יותר בכיוון 2.4) ומכונה אחת אינה מספיקה, יש צורך ב-3 מכונות (כאשר כל מכונה היא בעצם שרת 2 או 3U מלאה בדיסקים מכניים וחלק SSD) עם הרבה זכרון, רוחב פס של 40 ג'יגהביט (המינימום הוא 10 ג'יגהביט) ועם מעבדים חזקים, כך שכל דרישה להגדיל כמות אחסון או מענה מבחינת מהירות ורשת ללקוחות – מצריך הוספה של מכונות (במדריך ההטמעה של SuSE לדוגמא יש "רשימת קניות" מה הדרישות חומרה פר Node).

מי שיציץ בלינק יחשוב בוודאי שזה נשמע מוגזם מבחינת דרישות חומרה, וכאן בדיוק העניין: זהו פתרון שאינו מתאים לחברות קטנות ובינוניות. זה פתרון שיכול להתאים לבנקים, קופות חולים, חברות ביטוח, חברות פיננסיות גדולות שיש להן המון DATA ואותם נתונים אמורים להיות זמינים בכל דקה, 24/7/365 ועם Latency מאוד נמוך. האם הן כבר אצות רצות להטמיע? התשובה היא "עדיין לא". מנמר"ים, מנהלי IT ו-CTO רבים צריכים בשביל זה "להחליף דיסקט", וכשאני שומע מהם שהם מחפשים פתרון שיהיה Active/Active או Active/Passive אז אני מבין שהם עדיין לא ממש "נכנסו לראש" של Scale Out.

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

עם GlusterFS המצב שונה לחלוטין. נתחיל בכך שאם ב-Ceph כל השרת 2U/3U מיועד לשימוש הסטורג', ב-GlusterFS המצב הפוך. אם לדוגמא אתם מריצים vSphere/ESXi, אז אתם בוודאי מכירים את העניין שאפשר לעשות boot ל-ESXi מ-Disk on key או PXE ואין צורך בדיסק קשיח מקומי להתקנת ה-OS, אז אפשר על אותה מכונה להקים ESXI, להקים VM עם נניח 16 ג'יגהבייט זכרון, ולמפות אל ה-VM את כרטיס ה-RAID עם הדיסקים. ונצטרך להגדיר גם 2 חיבורי רשת פיזיים (האחד לקבל שרותים מה-Gluster והשני לחבר את כל המכונות שישתתפו ב-GlusterFS). לא צריך שרת חדש נוצץ מהניילונים, גם שרת R610/R710 דור 11 של DELL, שרתי HP G7, שרתי X3550/3650 M2 של לנובו/IBM יתאימו למטה (כל עוד הבקר תומך ב-SATA במהירות 6 ג'יגהביט), אפשר למלא דיסקים פשוטים (WD RED PRO ואחרים שנותנים מהירות 7200 RPM) ואולי 1-2 דיסקים SSD בחיבור SATA. שאר משאבי המערכת ישומשו טובת הרצת אפליקציות אחרות, מכונות וירטואליות, קונטיינרים (בפוסט קרוב אדגים איך Gluster FS יכול לעזור ל-Kubernetes בכך שתצטרך מעתה לבקש רק Volume Claim מבלי ליצור Volume, המערכת תיצור אוטומטית וניתן לגשת לאותו Volume ממספר קונטיינרים במקביל) וכו'.

גם כאן, כמות המכונות המשתתפות ביצירת Volume יכולה להיות מינימום 2 אך עדיף ברוב המקרים להתחיל עם 3, רק שכאן אם אתם רוצים להישאר עם 3 ולהוסיף דיסקים לדוגמא, חברו JBOD עם הדיסקים, צרו מהדיסקים דבר שנקרא Brick, והוסיפו אותו ל-Volume קיים. זה יספיק. מבחינת File system, ל-Gluster FS זה כלל לא משנה. תקים ZFS על הדיסקים ועל זה תריץ GlusterFS? אין בעיה. תרצה לפרמט עם בקר ה-RAID שלך את כל הדיסקים לאיזה RAID מסוים ועל זה להריץ GlusteFS? אין שום בעיה. גם כמות הדיסקים אינה ממש משנה, ואפשר אפילו להתחיל בדיסק יחיד (לא כל כך מומלץ אלא אם זה דיסק וירטואלי).

עכשיו החלק היותר מעניין: החלק הכי קריטי בבחירת מערכת זה החלק של השרותים. איזה שרותים אפשר לקבל עם הפתרון? גם עם Ceph וגם עם Gluster FS, אתה יכול לקבל את אותם פתרונות. רוצה iSCSI MP? יש. NFS כולל גירסה 4.1 או PNFS? יש. רוצה Object Store? יש. שרידות במקרה ששרת פיזי נופל? יש. מחפש Deduplication? ב-Gluster FS ניתן לקבל זאת כשמפרמטים את הדיסקים עם מערכת ZFS ובדרך גם ניתן לקבל דחיסה. (ב-Ceph כרגע אין את זה). מה עם Caching ו-Erasure Coding? יש ב-Ceph ויש גם ב-Gluster FS, וכן, לשתיהם יש גם ממשק WEB.

מה עם שרות ותמיכה? לגבי Ceph – גם SuSE ישראל וגם רד-האט ישראל (דרך הנציגים שלהם בארץ) מוכרים חבילה מסחרית ותמיכה מסביב לשעון של Ceph (ב-Suse זה נקרא SuSE enterprise storage 5, ב-רד-האט זה נקרא Red Hat Ceph Storage) עם תמיכה מסביב לשעון. כשזה מגיע ל-Gluster, רד-האט מוכרת את Red Hat Gluster Storage. אני ממליץ לשים לב לנקודה עקרונית: לא מומלץ להתקין את התוכנות אם אתם לא קונים ואין לכם מישהו שיתמוך לכם בתוכנה. נכון, Gluster FS לוקח חצי שעה להקים, אבל כשהתקלות מתחילות, אם אין ידע, זה כאב ראש (במיוחד ב-Ceph).

לסיכום: למי שמחפש פתרון סטורג' Scale Out, אלו 2 פתרונות טובים עם "גב" מאחוריהם. הפתרון של Gluster הוא טוב והוא יכול לתמוך גם בפטהבייט בלי שום בעיה והוא יכול להתאים לכל גוף שמחפש לעצמו פתרון אחסון חזק עם שרידות מעולה. הפתרון של Ceph לעומת זאת הוא פתרון "מפלצת" שנועד בראש ובראשונה לשרת אלפי, עשרות אלפי ומאות אלפי לקוחות בו זמנית ובנוסף, 2 הפתרונות נותנים לכם חופש מוחלט בבחירת הציודים שישמשו לאותו פתרון סטורג', כך שאין צורך יותר לשלם אלפי שקלים נוספים פר דיסק בגלל .. מדבקה (וכן, אני עומד מאחורי ההצהרה הזו). פתרון Active/Passive או Active/Active זה אחלה, אבל פתרון עם 3 מכונות נותן שרידות הרבה יותר טובה וגם נהנים ממהירות הביצועים.

תכירו את Kubevirt

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

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

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

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

אחת הבעיות שנוצרות מהכנסת קונטיינרים ומערכת ניהול/אורקסטרציה (כמו Kubernetes, OpenShift, Docker-swarm ואחרים) היא שמעתה צריך לנהל 2 מערכות שונות. האחת לניהול השרתים הוירטואליים שלכם (Hyper-V, vSphere) ואחד לניהול הקונטיינרים שלכם ולמרות שברמה העקרונית שתיהן מרימות דברים שהם מופרדים (קונטיינרים, VM), יש תהום של הבדלים ביניהם:

  • ב-Kubernetes הרשת מנוהלת בצורה אחרת לגמרי
  • כל עניין ה-Clustering הוא משהו שונה וחדש שלא קיים בשום פתרון וירטואליזציה
  • דיסקים בכלל מוגדרים בצורה שונה ואין אפשרות לנהל את ה"דיסקים" בפתרון כמו Kubernetes (להגדיל, להקטין דברים שקיימים)
  • שיטת העבודה עם Kubernetes (ו-OpenShift) היא בכלל שיטה "הצהרתית" (כלומר אתה מצהיר מה אתה רוצה שיקרה, המערכת עובדת על לקיים את רצונך. Genie כזו 🙂 ).

יחד עם זאת, לא היה נחמד יותר להשתמש ב-Kubernetes (או OpenShift או CAAS של SuSE)?

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

תכירו את Kubevirt.

הרעיון של Kubevirt הוא די פשוט: בתוך Kubernetes יש דבר שנקרא CRI (ר"ת Container Runtime Interface). פרויקט oVirt מרחיב את ה-CRI ואת Kubernetes עצמו כך שיוכל להפעיל גם מכונות וירטואליות כאילו מדובר בהפעלת קונטיינרים. בד"כ ע"מ ליצור POD עם קונטיינר, אנחנו יוצרים קובץ בפורמט YAML (או JSON, בהתאם להעדפות), וכאן הדברים יהיו דומים. הנה דוגמא לקובץ YAML כזה.

אם נשתמש ב-kubevirt עם קובץ ה-YAML הזה, תקום לנו מכונה וירטואלית קטנה (64 מגה זכרון) והדיסק שלה יהיה iSCSI. כך נוכל לערב בין קונטיינרים למכונות VM, לפי הצורך.

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

לאלו שמעוניינים להבין מה קורה מאחורי הקלעים, הוידאו הפעם מכנס KVM פורום יוכל לסייע:

כמה מילים על VMWare on AWS

(תודה לניצן וייסברג שהעיר את תשומת ליבי לגבי השרות החדש)

בכנס Re:Invent האחרון של אמזון, חברת VMWare הכריזה על שרות חדש בשיתוף אמזון שנקרא VMWare on AWS – שרות שנותן לך להרים SDDC (כלומר Software Defined Data Center). עם שרות זה, הלקוח מקבל מינימום 4 שרתים פיזיים שמותקנים עליהם ESXI יחד עם VSAN ו-NSX וכמובן כל השרותים של vSphere שמגיעים ברשיון Enterprise Plus. הלכתי לקרוא בכמה מקומות על השרות ולהלן התרשמותי:

מבחינת המכונות – אין מה לאמר, מפלצות אחת אחת. בכל מכונה תקבל 36 ליבות (מהמעבדים האחרונים – Xeon-SP של אינטל), 512 ג'יגהבייט זכרון, ו-8 דיסקים SSD NVME (כל אחד בגודל של 2 טרה, כאשר 2 מתוכם משמשים כ-Cache, כך שמבחינת Storage בחישוב כולל, יש לך בערך 20 טרהבייט, לפי הדף באתר של אמזון) והרשת היא ברוחב פס רציני של 25 ג'יגהביט. אין מה לאמר – הלוואי על כולנו!

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

איך נאמר בפרסומת: סבבה אגוזים!

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

הכל טוב ויפה, עד שמגיעים … למחיר, וכפי שאתם יכולים להסתכל על מפרט הברזלים לעיל – זול זה לא הולך להיות!

המחיר מתחיל ב-8.3681 דולר לשעה פר ברזל ומכיוון שצריך מינימום 4 ברזלים (אי אפשר פחות), אז אנחנו מדברים על 33.47 דולר לשעה. נכפיל ב-720 שעות לחודש ונגיע ל-24,100 דולר לחודש, או 289,201 דולר לשנה. המחיר כמובן לא נגמר פה, על כך יש להוסיף מחיר תעבורה מהתשתית של אמזון החוצה (רוצים להתחבר ב-Remote? להוריד VM לארץ? להוריד DATA לארץ? סינכרוניזציה או רפליקציה בין VMים משם לכאן? אז תוסיפו בבקשה, 5 סנט פר ג'יגהבייט) וכרגע אם אתם רוצים Latency נמוך, אתם יכולים לשכוח מזה – בשלב זה השרות זמין בצפון אמריקה בלבד (אלא אם יש לכם קו יעודי לארה"ב, שזה סיפור אחר כמובן).

רוצים הנחה? בשמחה! תתחייבו לשנה מראש, ותשלמו פר הוסט סכום של 51,987 דולר, נכפיל ב-4 וכך נרד למחיר "מציאה" של 208,000 דולר לערך או 437,464 דולר בהתחייבות ל-3 שנים. אין שוטף+30 או 60, זה תשלום מיידי ואין אפשרות לצאת מהמחויבות באמצע התקופה.

אבל בואו נעזוב את המחיר. יש לא מעט חברות גדולות מאוד ששרפו מיליוני דולרים באגפי המחשוב בצעדים תמוהים (אל תאמינו לי, תראו מה קרה עם 600 מיליון שקל וביטוח לאומי) שבשבילם Money is not a object ואין להם בעיה להוציא מאות אלפי דולרים בשנה – האם להם זה שווה?

מבחינה טכנית גרידא, התשובה היא לא רבתי, מהסיבות הבאות:

  • השרידות היא אשלייתית. באמזון לדוגמא, אם תשתמש בשרות Aurura להקים שרות MySQL, אתה מגדיר שם Availability Zone, כלומר השרות שיוקם עבורך מבוזר על פני שרתים שנמצאים ב-Zones שונים שנמצאים באותו Region, כך שאם Zone נופל (הנה דוגמא) אז Zone אחר תופס פיקוד ואתה אפילו לא מרגיש נפילה. עם השרות החדש הזה – כל השרתים שלך נמצאים באותו Zone, ואם ה-Zone נופל, הכל נופל בתשתית המרוחקת. מעבר לכך, לא ניתן לפרוס את ה-Hosts על פני Regions שונים של אמזון (אם כי ניתן להקים SDDC שונים ב-Regions שונים, אך כרגע רק בצפון אמריקה).
  • גדילה של Storage היא בעייתית בהשוואה למחיר. זה שתוסיף עוד Host לא תקבל עוד 20 טרה אחסון, אלא סביר להניח שתקבל בערך 5 טרהבייט נטו (הסיבה לכך שעם VSAN, ה-DATA של מכונות ה-VM או DATA שאתה מייצא כ-iSCSI החוצה – מתרפלק בין המכונות כולן, כך שאם מכונה אחת נופלת, ה-Cluster ממשיך לעבוד כי ה-DATA נמצא. אפשר לעשות את החישובים כאן). הדבר המוזר בכל השרות הזה הוא שלא ניתן לחבר EBS מסוג io1 (או כל סוג EBS) כ-Datastore לתשתית.
  • חייבים 4 מכונות, למרות ש-VSAN יכול לעבוד גם בתצורות של 2 ו-3 מכונות פיזיות.

אבל שוב, אם יש לחברה את התקציבים, יש גם יתרונות:

  • הקמה של SDDC מלא עם מכונות מאוד חזקות בשעות ספורות במקום לבזבז מס' חודשים על בדיקת הצעות מחיר, ישיבות תקציב, הזמנות, הגעת ציוד, הגדרות והכנה לעבודה.
  • גדילה של התשתית הרחוקה תוך דקות ספורות. צריך עוד 2 ברזלים? זה יקח מס' דקות והברזלים יהיו מחוברים לתשתית ה-SDDC שלך. Host נפל? לא נורא, תוך דקות תקום מכונה אחרת ואתה יכול לגדול ל-עד 32 מכונות פיזיות (כרגע).
  • עבודה שקופה – מנהלי תשתית ה-vSphere שלך יכולים להקים מכונות פה או שם (או פה ושם) בצורה מהירה, מבלי להכיר לעומק איך לעבוד עם AWS (למעט החלק הראשוני של הקמת ה-SDDC).
  • גיבויים – הקץ ל"אין מקום לגבות". עובדים עם Veeam? מעכשיו תוכלו להשתמש באמולציית ה-VTL שלו ולגבות ל-S3 של אמזון. גם זול, גם שרידות סופר גבוהה, וזה תמיד זמין. (כעקרון אפשר לעבוד עם כל תוכנת גיבוי שיודעת לעבוד עם S3).
  • אחריות ושרות – אתה מקבל ניהול תשתית ומענה לכל בעיה ישירות מ-VMWare.
  • תשלום פר שימוש – אפשר לנסות את זה לכמה שעות או כמה ימים מבלי להתחייב על כלום ולשלם רק על השעות שניצלת.

לסיכום: אם בחברה שלכם יש תקציבים כמו מים זורמים, ואתם משתמשים בתשתית vSphere, אז בהחלט כדאי להסתכל בהצעה החדשה של אמזון/VMware. אם לעומת זאת כל שרת נרכש אצלכם בדם-ויזע, אז עדיף לוותר על השרות ומבחינה כספית – יהיה יותר זול לרכוש שרתים חזקים + רשיונות ולהכניס אותם ל-Data Center שלכם או באחת החוות של ספקי האינטרנט.

על תשתיות IT והקמת פרויקטים מבוססי לינוקס ב-Enterprise

נניח שאתם שוכרים את שרותי להקמת שרת אפליקציה לינוקסי כלשהו. לא חשוב מהי האפליקציה. סביר להניח שאקבל מכונת VM כלשהי עם הפצת לינוקס שאתם עובדים עליה. ברוב המקרים, סביר להניח שאני אצטרך חיבור אינטרנט כדי להוריד חבילות נוספות מעבר למה שקיים ב-ISO image של הפצת הלינוקס שבחרתם. לפעמים זה חבילה או 2 ולפעמים – מאות חבילות. לבקש שיורידו לי חבילה X זה לא פתרון כי לכל חבילה יש חבילות שכנות שנקראות "תלויות" (Dependencies), כך שלשם ביצוע המשימה, אני צריך את החיבור לאינטרנט, ולפעמים גם ביטול זמני של DLM ודברים כאלו שלא מאפשרים לחבילות בלינוקס לרדת.

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

אבל כשזה מגיע לחברות מאוד גדולות, כמו חברות בטחוניות, בנקים, ביטוח וכו' – הסיפור הרבה הרבה יותר מורכב, לפעמים צריך לקיים ישיבות, להעביר טפסים, להסביר שוב ושוב – עד שמקבלים את פתיחת ה-Firewall הזמנית כדי להוריד את החבילות ובמקרים רבים – אף אחד לא אוהב את זה. אחד התירוצים לסירוב פתיחת Firewall לאותה מכונה זה "תוריד מראש ותביא", רק שבמקרים רבים פתרון כזה אינו רלוונטי הואיל ובקונפיגורציות מסויימות יהיו מצבים שנצטרך עוד חבילות (כמו במקרים שבהם יש צורך במאגר חבילות [Repository] שאין אותו בחברה ואז חוזרים על הסיפור מחדש). אפשר להביא את הכל בדיסק נייד, נכון? אבל אז יש צורך לחבר ב-USB ואסור לחבר שום דבר ל-USB בלי ש"ילבינו" את זה קודם ולך "תלבין" דיסק קשיח שמפורמט בלינוקס..

בלינוקס, ולא חשוב איזו הפצת לינוקס, עניין החבילות שונה לחלוטין מ-Windows (אם כי ב-Windows השינויים בחבילות גם נכנסים לאט, כמו חבילות שמתקינים עם Powershell). מאגרי חבילות לדוגמא במקרים רבים לא יורדים מאיזה שרת ספציפי מסוים בחו"ל. במקרים רבים, פקודת ההורדה (yum ב-CentOS או Red Hat לדוגמא) דוגמת מהירת גישה ממספר שרתים שונים באינטרנט וגם במהלך ההורדה, אם לדוגמא חבילה מסויימת לא קיימת בשרת מסוים, ההתקנה אוטומטית "קופצת" לשרת אחר (בכתובת שונה) ומורידה את החבילות משם. אם תרצו לאחר יותר מיומיים שוב להוריד חבילות, מערכת ההתקנה שוב תדגום מהירות של מספר שרתים ויכול להיות שתבחר שרת mirror אחר כדי להוריד, כך שפתיחה ב-Firewall לכתובת URL אחת לא תסייע, מה עוד שבמקרים רבים כתובת ה-URL משתנה עם redirect ואז שוב ה-Firewall חוסם.

אז כן, הפצות לינוקס ו-Firewall בכל הקשור להתקנת חבילות – הם לא החברים הכי טובים.

מה ניתן לעשות?

ההמלצה שלי לחברות גדולות זה להקים שרת (אפשר גם שרת ישן וגם דסקטופ עם מעבד i3 יספיק עם 4 ג'יגהבייט זכרון, כל עוד מדובר על עשרות מכונות VM שיקבלו את החבילות) עם 2-3 דיסקים גדולים (SATA פשוטים של 4-8 טרהבייט, לא צריך Enterprise) ב-RAID 1 ועם 2 חיבורי רשת, רגל אחת תהיה מחוברת החוצה ורגל אחת פנימה. השרת שנקים יהיה בעצם שרת Mirror פנימי לחברה עצמה, ובשרת נריץ מספר סקריפטים שיתחברו אחת ליום לכל מיני מאגרי חבילות ויקבלו את כל החבילות של אותה הפצת לינוקס לגרסאותיה השונות. השרת מתעדכן מדי יום (לעיתים פעמיים ביום) בחבילות וכל החבילות של ההפצות יורדות ומסונכרנות עם שרת Mirror אחר או שרת Master.

אחרי שהקמנו את השרת הזה, נגדיר את השרתים הפנימיים שלנו לקבל עדכונים רק משרת ה-Mirror הפנימי שלנו (כמובן, אם יש בחברה אלפי שרתי לינוקס, PC פשוט לא יספיק ויכול להיות שיהיה צורך להקים זאת על מספר מכונות VM כאשר כל המכונות מקבלות את הקבצים משיתוף NFS ויהיה Load Balancer שיפנה את הדרישות למכונות השונות). כל החבילות חתומות כך שזה יכול לשמח את מחלקת אבטחת המידע.

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

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