כשזה מגיע לניהול מערכות VM

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

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

אבל מה לעשות, ברוב המקרים הטכנולוגיות הן שונות. להרבה חברות לדוגמא יש את Hyper-V מצד אחד או vSphere מקומי ומצד שני הם רוצים לעבוד עם אמזון או גוגל (או במקרים יותר מעניינים – Hyper-V עם אמזון או גוגל). אז לאמזון יש כלי שבקרוב יצא שיתן לך לחבר את AWS אל ה-vSphere שלך (חכו לחשבוניות השוק..), אבל גם פתרון כזה לא מכסה אפילו עשירית ממה ש-AWS מציע מבחינת שרותים וכשזה מגיע לחסכון – אתה חייב להכיר את השרותים השונים בכדי לחסוך. יש מקרים גם שצריך להרים עננים פרטיים (כמו ה-OpenStack) ומה לגבי קונטיינרים? מיקרוסופט ואחרים מאוד מעודדים להשתמש בקונטיינרים.

ישנם בשוק כלים שונים החל מ-Terraform, המשך ב-Ansible, Chef, Puppet ועוד – שהם מיועדים לכתיבת אוטומציה של בניה והגדרות התשתיות הללו, והם אכן מעולים לכך ואני ממליץ עליהם (עם העדפה ל-Ansible) לשימוש בתוך החברות. עם כלים כאלו אפשר לכתוב אוטומציה החל ברמה של הרמת VM ועד ההגדרות הכי קטנות ופרטניות בתוך ה-VM. תן לאוטומציה להריץ סקריפט (או Playbook או Recepie) שכתבת עבור הקמה כזו – והוא אץ רץ להקים זאת.

העניין הוא שחברות רוצות כלי שיש לו:

  • GUI
  • פופולריות רצינית בשוק כך שאפשר למצוא פתרונות לבעיות
  • שניתן להרחבה בקלות בעתיד
  • שיש לו "אבא" – שאפשר לקבל ממנו את התמיכה (ואם ה"אבא" לא אחראי על הקוד שלו, אפשר לתבוע לו את הצורה… שיטה מקובלת מאוד אצל האמריקאים, מה שנקרא indemnification).

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

תכירו את Cloudforms של חברת רד-האט.

ה-Cloudforms הוא כלי מרכזי שמאפשר למנהלי IT (ואחרים – כמו מפתחים, בודקי תוכנה ואחרים, הכל לפי הרשאות) לראות ולנהל את כל תשתית הענן שלהם ולא משנה ממה היא מורכבת. יש לכם Hyper-V? OpenStack? GCE? AWS? Kubernetes? ברזלים ללא VM? (ועוד רבים אחרים, יש ערימות תוספים) – אין שום בעיה. תגדירו אותם במערכת ותתחילו לעבוד. צריכים Orchestration? יש בפנים. רוצים לנהל אותה מבחוץ עם Puppet או Ansible? זה כבר כלול. רוצים גרפים יפים כדי להראות על מסך 50" בחדר ה-NOC? חיבור ל-Grafana מבוצע בקלות! צריכים להעביר VM מכאן בישראל לענן כלשהו ולא חשוב איזה ענן? אין שום בעיה! צריכים סטטיסטיקות מה קורה עם התשתית? כמה קליקים ויש לכם גם את זה. גדילה אוטומטית במקרים של עומס? יש. ויש עוד פונקציות נוספות רבות.

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

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

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

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

איזה מהמוצרים מתאים לכם? אם אתם חברה שאין בה אנשי לינוקס עם ידע רציני, ואתם לוקחים אינטגרטור רק להקמה ואולי לתמיכה – אז גירסת ה-Cloudforms תתאים לכם (יש גם Trial ל-PoC). לעומת זאת, אם אתם חברה שלינוקס זה חלק מהתשתיות שלכם ויש לכם אנשי לינוקס עם ידע רציני, אז ManageIQ יכול להיות פתרון די טוב עבורכם (כל עוד אינכם צריכים תמיכה רשמית).

פתרון אלטרנטיבי אחר (גם מבוסס לינוקס) הוא SuSE Manager (עם תמיכה ישראלית של סוזה ישראל) והוא יותר מתאים לחברות שלא מחפשות להשתמש בשרותים שספק הענן מציע (SQL, מייל וכו') אלא אך ורק להריץ מכונות VM, לנהל את מכונות ה-VM, עדכונים, Policy וכו'. המוצר זמין כגירסה מסחרית בלבד (עם גירסת Trial ל-60 יום).

על דיסקים 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 🙂

על בניית מערכת מוקשחת לאנדרואיד

בארגונים רבים יש נוהל בו ניתן טלפון סלולרי לעובד מחברה כלשהי. מכשיר זה בד"כ מנוהל ע"י צוות ה-IT והוא מקבל עדכונים רשמיים הן מיצרן המכשיר והן דרך תשתית ה-IT (או חנות האפליקציות – כמו Google Play Store או ה-Appstore של אפל). בד"כ מנהל ה-IT יוכל להגדיר לשם אבטחה ביטול או חסימת אפליקציות ושרותים מסויימים. ארגונים שמחפשים להגן על תוכן וגישה לאפליקציות מסויימות במכשיר, יכולים להשתמש בתשתית כמו KNOX (במקרים של סמסונג) או בדברים יותר פשוטים כמו Applock שמאפשרים לנעול אפליקציות מסויימות כך שניתן יהיה להשתמש בהן רק עם טביעת אצבע או קוד מיוחד שיש רק לבעל המכשיר.

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

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

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

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

על מנת לשלוט טוטאלית על מה שיהיה במכשיר ומה לא יהיה, אלו פונקציות יהיו פעילות ואלו לא יהיו קיימות – יש צורך "לבנות" את האנדרואיד מחדש למכשיר ולקמפל כמעט הכל מחדש על מנת ליצור מספר Images שונים – וכאן ה-"Fun" מתחיל…

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

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

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

  • ראשית, יש צורך בשיתוף פעולה מצד יצרן המכשיר במסירת קוד המקור למכשיר או שיתוף פעולה ע"י יצרן המעבד. הסיבה העיקרית לכך היא שישנם חלקים רבים של קוד שאינם קוד פתוח ובלעדיהם לא ניתן לבנות מערכת חדשה. קחו לדוגמא את עניין הדרייברים: ללא קוד מקור לדרייברים, לא ניתן לבצע קימפול אפילו לקוד שמפעיל אפשרות להתחבר לרשת סלולרית או WIFI, מסך מגע או תצוגה חלקה של המסך. ללא שיתוף פעולה ניתן "לקושש" באינטרנט אחר דרייברים בינאריים שנבנו עבור גירסה מסויימת לאנדרואיד, אולם אין שום בטחון שהם יפעלו.
  • רוב יצרני הטלפונים הסלולריים נועלים את מכשיריהם בפני עדכונים לא-מורשים בכך שהם חותמים כל עדכון עם שילוב מפתח פרטי/ציבורי, כך שכל Image שיבנה עבור המכשיר – לא יוכל להיות מותקן על המכשיר. כשיש שיתוף פעולה עם היצרן, ניתן להעביר אליו בקשות חתימה ולעדכן בעזרת תוכנות שונות את קושחת המכשיר. ללא שיתוף פעולה של היצרן – יש צורך בלבצע Root, להתקין תוכנת Recovery (כמו TWRP), לבטל מספר בדיקות שאמורות להגן על המכשיר משינויים ורק אז ניתן להתקין Image שנבנה עבור הלקוח.
  • במידה ומדובר במכשיר שמיוצר עבור החברה (נניח בסין) אז בהחלט ניתן לבנות Image, אולם יש לקחת בחשבון שהעבודה צריכה להתבצע מאפס. אני לא ממליץ לשום חברה בטחונית (או חברה שאבטחת המידע חשובה לה) להסתמך על קושחה/ROM של היצרן הסיני, המכשירים בד"כ מגיעים קושחה עמוסת חורי אבטחה ולפעמים גם הקושחה מגיעה עם תוכנות ש"מחייגות הביתה".
  • עבודת בניית Image היא פרויקט שלוקח זמן (זו הסיבה שיצרני חומרה משחררים עדכוני קושחה רק לאחר מספר חודשים) הואיל וישנם דברים רבים שצריך לכוון ולהגדיר לפי הבקשות של הלקוח. בנוסף, אלו בד"כ פרויקטים מתמשכים – הואיל וגוגל משחררת מדי חודש עדכוני אבטחה ויש צורך לבנות עדכון על סמך העדכונים של גוגל. בנוסף, גוגל משחררת גרסאות אנדרואיד חדשות כל שנה ויש צורך לבצע את רוב העבודה מחדש (גירסת Kernel מוחלפת ואז יש צורך לוודא אם הדרייבים מצליחים לפעול או שצריך לחכות לדרייברים חדשים מיצרן החלק הספציפי של החומרה) – בקיצור אם מישהו חושב שזה תהליך שלוקח שבוע, הוא "טיפה" טועה 🙂

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

על "ספריות" וריבוי עננים

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

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

הבעיה הכי גדולה בד"כ כשמנסים להתממשק במקביל לענן פרטי וענן ציבורי, זה שכל ענן מצריך סקריפטים ו/או אפליקציות שונות להתחבר אליהם. ה-vSphere Client שלך לדוגמא לא יכול לדבר עם Azure או GCE, ולמרות שניתן לחבר אותו ל-AWS, לא ניתן לבצע דברים מרובים שקשורים בסטורג' בענן כמו S3 או דברים אחרים (כמו EFS לדוגמא). חמור מכך – כשיש לך תשתית מורכבת בענן הפרטי ובענן ציבורי, שתיהם יצטרכו תחזוקה אחרת. אחרי הכל, אם אתה משתמש לדוגמא ב-CloudFormation של אמזון, זה לא יעזור לך ממש מול כל ענן אחר, פרטי או ציבורי.

ישנם מספר פתרונות לכך, כולם מבוססים על ספריית libcloud של Apache והם:

פתרונות אלו יכולים לתת לחברה חופש לעבוד כמעט עם כל פתרונות וירטואליזציה מקומית (למעט Hyper-V – זה יותר באשמת מיקרוסופט שעדיין לא מתקנת את התמיכה שלה ב-libvirt) ובמקביל מאפשרת לעבוד עם כל ענן ציבורי, מהגדולים ועד הקטנים (הרשימה המלאה כאן). כך לדוגמא, אם אתה רוצה להרים מספר מכונות עם תשתית רשת פשוטה לצורך ביצוע עבודות שונות, אתה יכול לבחור לדוגמא ב-Digital Ocean או Linode ששם המחירים יותר זולים מהמחירים של ספקי הענן הגדולים ובנוסף אתה לא משלם על התעבורה החוצה (עד 3 או 5 טרהבייט כל חודש). אינך צריך לבנות את הסקריפטים מאפס אלא פשוט להשתמש בספריית libcloud ובפתרון שמתאים לשפה שאתם עובדים איתה כדי להרים את התשתית, לבצע שינויים וכו' ובכך תוכל בשימוש בספריה הזו לשלוט בכל תשתיות הענן שאתם משתמשים ללא צורך בכתיבה מיותרת של ערימות סקריפטים.

חשוב לציין: libcloud לא בא להחליף דברים ספציפיים ויחודיים של ספקי ענן. כפי שציינתי לעיל, זה לא יכול להחליף את cloudformation וזה לא יכול להחליף כלי מדידה קנייניים של ספק הענן, לשם כך תצטרכו פתרונות אחרים (ולשם כך אני ממליץ בחום על Zabbix ו-Grafana), אבל מצד שני – libcloud יותר מתאים לאלו שלא מעוניינים להיות "נעולים" עם שרותים של ספק ענן כלשהו והם מחפשים את החופש להשתמש בשרותי ענן שונים כשהם יכולים לנוע מענן לענן בקלות.

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

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

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