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

עוד נקודות חשובות לפני מעבר לענן

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

לעומת זאת, חברות לא מעטות בארץ ובחו"ל מעדיפות את הענן של מיקרוסופט, וכאן איש ה-Devops יצטרך יודע ידע בטכנולוגיות של מיקרוסופט (PowerShell ואחרים) כדי לעבוד. מיקרוסופט נותנים SDK לשפות אחרות ו-CLI למערכות הפעלה פופולריות, אך מי שעובד לדוגמא הרבה עם AWS ויעבור להשתמש ב-Azure, יגלה לאחר זמן מה שמיקרוסופט יותר משקיעה בטכנולוגיות שלה מאשר בטכנולוגיות האחרות. כך לדוגמא אם תרצה לבצע אוטומציה עם הכלים הפופולריים בלינוקס, החיים שלך לא יהיו כל כך קלים.

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

סיכום שנת 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 אינו מפחיד אותן.

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

"מאחורי הקלעים" של אבטחת שרתים

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

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

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

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

אז זהו, שזה הפוך.

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

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

אחרי שעוברים את המשוכה הזו, צריכים להחליט את מה מקשיחים. התשובה לשאלה כזו בד"כ תיענה ב-"את הכל", וכאן מתחילה בעיה. בחברה קטנה עם 4-5 מכונות לינוקס העניין פשוט וקל, אותו דבר בייצור Appliance, אבל כשיש לחברה מאות או אלפי מכונות VM שמריצות לינוקס, הבעיה הרבה יותר מורכבת: לכל גירסת הפצת לינוקס יש לממש את סטנדרט ה-CIS שלה ברובו מחדש, כך שמדובר פה על השקעה שיכולה לקחת מספר חודשים. הסטנדרט שונה בין CentOS לבין SuSE לבין אובונטו ורק חלק קטן מהסטנדרטים חופף בין ההפצות. כמובן שאם כל המכונות שלכם מריצים את אותה הפצת לינוקס ואותה גירסה – אז חייכם דבש 🙂

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

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

זהו, שלא ממש..

אחת הבעיות המרכזיות כשזה מגיע לאבטחת שרתים, היא בעיית חורי אבטחה שמתגלים כמעט כל יום. העדכונים לחורי האבטחה מגיעים רק לאחר מספר ימים (במקרה הטוב) או כמה שבועות (במקרה הפחות טוב) או אפילו חודשים (אהלן מיקרוסופט!). מה עושים עד אז? בד"כ יצרניות ההפצה יתנו הוראות מניעה זמניות כיצד לפתור לבינתיים את הבעיה. העניין הוא שההוראות מגיעות באנגלית ואולי עם דוגמא לסקריפט BASH או Python. איך בדיוק תפיץ את זה למאות שרתים? אתה כמובן יכול לבנות חבילה (RPM או DEB), להוסיף ל-REPO מקומי ולהפיץ זאת דרך תוכנת העדכונים שלכם, אבל תצטרכו איכשהו לעשות לתיקון הזמני Roll Back וזה לא ממש קל, במיוחד אם חור האבטחה נוגע לאפליקציה שיש לה המון תלויות ואז מדובר במתכון בטוח לכאב ראש פר שרת.

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

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

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

מעבר לענן שאלות ותשובות (חלק 1)

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

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

ש: האם יש הבדל גדול בין ספקי ענן בארץ לבין ספקים כמו אמזון/גוגל/מיקרוסופט?
ת: קודם כל – כמובן, עניין הגודל 🙂
וברצינות – ספקים כמו השלישיה שצוינה לעיל עובדים באופן שונה לחלוטין מכל מה שמכירים בישראל. גוגל/אמזון/מיקרוסופט בונים את הארכיטקטורה שלהם באופן שונה לחלוטין. כשמדברים על Storage לדוגמא, לא תמצאו אצלם NetApp או EMC או כל סטורג' (גדול ככל שיהיה) שקיים ללקוחות בשוק הרחב. מדובר על "פתרון סטורג'" שאותו ספק ענן תכנן, בנה ופיתח בעצמו. אין דיסקים SAS ואין RAID ואין LUN או כל המושגים שאנחנו מכירים מעולם ה-IT הרגיל שלנו. המערכות שלהם יודעות להתמודד באופן שגרתי גם עם נפילות של 8 או 10 דיסקים, גם אם זה קרה בעת ובעונה אחת (נדיר ביותר) והנתונים שלך תמיד זמינים. לדוגמא: אחסון ב-S3 של אמזון מגיע עם SLA מדהים של 99.999999999%. לכו תמצאו ספק אחד בארץ שיתן לכם את אותו SLA.

גם אשכול (Cluster) שאנחנו מכירים הוא די שונה אצל אותם ספקי ענן. תסתכל לדוגמא אצלכם בחברה על Cluster שהקמת. 2 המכונות באשכול (נניח) נמצאים ב-2 שרתים כאשר שתיהם נמצאים אחד מעל השני, אולי בארונות נפרדים ואולי אפילו בקומות נפרדים. אצל השלישיה – Cluster זה אומר ש-2 המכונות עבורך יושבים ב-DC שונים גיאוגרפית באותה מדינה (לאמזון לדוגמא בוירג'יניה יש לא פחות מ-5 DC. בשפה של אמזון הם נקראים Zones), כך שאם מתרחש אסון, האשכול ממשיך לעבוד וברקע מוקמת מכונה אחרת אך עדיין השרות יעבוד.

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

כאן בישראל לעומת זאת, ספקי הענן עובדים בדיוק כמו שעובדים ב-Corporate. הסטורג' הוא סטורג' מסחרי סגור, האשכול מוקם באותו DC, ואם מתרחשת תקלה (אהממ.. מזגנים, קבלן אידיוט שלחץ עם הגב על הכפתור האדום והשבית חשמל, דברים שהתרחשו בארץ) – המערכת שלך מושבתת והרעיון להקים אשכול בין 2 DC יהיה קצת בעייתי (במיוחד אם אתה צריך אחסון משותף ל-2 השרתים). בגלל זה בד"כ בארץ עובדים בשיטה של DR (כלומר Disaster Recovery) כאשר אם המערכות שלך בארץ נופלות, המערכות שלך אצל ספק חיצוני "תופסות שליטה" אבל זה כמובן שונה לחלוטין מאשכול שעובד בברירת המחדל אצל השלישיה כ-Active/Active.

יחד עם זאת, לספקים בארץ (ורוב חברות ה-Hosting הגדולות בחו"ל) יש יתרון על פני השלישיה בכל הקשור להתרחבות תשתית קיימת. אם אתה משתמש לדוגמא ב-vSphere של VMWare ואתה מעוניין להתרחב מעבר ל-DC הקיים שלך, מוצר כמו vCloud Air (או כל פתרון Hybrid Cloud אחר בהתאם לתשתית הוירטואליזציה שלך) יכול בקלות לעזור לך להתרחב, כל מה שתצטרך לעשות זה למצוא שותפים לפלטפורמת ה-vCloud במדינה שאתה מעוניין לבצע את ההרחבה אליה, להיכנס למו"מ לגבי מחירים ולאחר החתימה להתקין את ה-vCloud Air, לבצע הגדרות – ואתה מוכן להתרחבות. האם ניתן יהיה לעשות זאת עם השלישיה? עוד לא (עם אמזון זה נמצא בשלב ה-Technology Preview ואני בספק אם יהיה ניתן לעשות זאת עם Azure של מיקרוסופט) אבל גם אם זה אפשרי – לא תמצאו שם חסכון (זיכרו: אצל ספק רגיל בחבילה אתם מקבלים X טרהבייט תעבורה החוצה, באמזון כל ביט שיוצא החוצה מעבר לג'יגהבייט הראשון – אתם משלמים).

מה שמוביל לשאלה הבאה:

ש: מה ההבדל בין העננים של השלישיה לבין Hybrid Cloud?
ת: כפי שתיארתי לעיל, הרעיון של Hybrid Cloud הוא בעצם הרחבה של ה"ענן" הפרטי שיש לכם בחברה, כאשר הכל בעצם מבוסס על מכונות VM שרצות. לדוגמא: ב-Hybrid Cloud אם אתה צריך שרות כמו SQL, אז אתה מרים VM שמריץ SQL Server, Oracle או MySQL לדוגמא וה-VM הנ"ל מספק שרות SQL לאחרים. אין לך ספק חיצוני שמספק לך שרות SQL בהתאם לדברים שאתה צריך. סטורג' – כמעט אותו סיפור: או שיש לך סטורג' חיצוני שממנו תשתף תכנים (CIFS/NFS) או תשתמש ב-iSCSI אבל הכל בסופו של דבר כרוך בסטורג' החיצוני שלך, או שתרים VM עם דיסקים גדולים וממנו תייצא את אותם שרותים, כך ש-Hybrid Cloud מאפשר לך בעצם להתרחב בדיוק עם אותה תשתית ושימוש ב-VM וסטורג' חיצוני (או דיסקים פנימיים בחלק מהמקרים, תלוי בגודל חברה, תקציב וכו')

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

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

ש: האם השלישיה מציעה שרותי SSO? (ר"ת Single Sign On)
ת: תלוי לאיזה ספק ענן אתה פונה.

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

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

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

אפשרות יותר זולה היא להשתמש בשרותי ה-VPC/VPN של אמזון. באופן עקרוני, כשאתה פותח חשבון באמזון, המערכת של אמזון בונה עבורך VPC (ר"ת Virtual Private Cloud) ולזה אתה יכול לחבר VPN חומרה ולהתחבר בחיבור מאובטח VPN Site to Site ויש גם אפשרויות אחרות. פרטים ניתן לראות כאן.

לגבי מי ששאל על SD-WAN: זה תלוי בספק SDN שלכם. רובם מציעים כבר פתרון חיבור מאובטח לשלישיה (לפחות ל-Azure ולאמזון כיום)

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

כל ספק מציע ערימות שרותים, אולם כדי לתכנת את השרותים, הספק מציע API שאיתו אתם עובדים. ב-Azure לדוגמא יש צורך בידע טוב של PowerShell ובמקרים מסויימים #C. באמזון לדוגמא כדאי שיהיה לך ידע של Python, Java ולפעמים גם JS וקצת BASH. בגוגל – אותו דבר כמו במקרה של אמזון.

משהו נוסף שדי חשוב שיהיה לכם במקרים של אמזון וגוגל: ידע די טוב בלינוקס (אם המכונות שלכם מבוססות לינוקס) ובמקרה של אוטומציה – עדיף שתדעו Chef או Puppet וכמובן שידע כלשהו ב-Ruby זה לא יזיק. אם אתם חובבי Ansible (הח"מ חובב זאת) אז יש תמיכה ישירות ב-AWS כולל עבודה יותר קלה בהשוואה ל-CloudFormation של אמזון.

על יעילות IT בחברות

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

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

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

בפוסט זה אני רוצה לדבר על 3 נקודות:

  • על Image ועל נחיצות Image להתקנה על מחשב
  • אוטומציה
  • תיעוד

נתחיל בעניין Images:

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

אך כשזה מגיע למחשבים ניידים לדוגמא, הרעיון של Image בניגוד למה שחושבים הוא אינו יעיל. קודם כל, תסתכלו בכל חברה ותראו מספר דגמים של מחשבים ניידים (מה לעשות, ההנהלה מקבלת דגמים הרבה יותר יקרים מהעובדים), כך שגם אם ניצור Image והמחשב יהיה מוכן להתחברות ל-AD, אנחנו נצטרך להריץ עדכונים של מיקרוסופט, עדכוני דרייבים ותוכנות של יצרן המחשב, עדכוני תוכנות צד ג' (פלאש, JAVA וכו') כך שהזמן מרגע הפעלת המחשב עד שהוא מוכן לשימוש אינו קצר, ואגב – אם תבדקו לדוגמא את השחזור מערכת הפעלה שהיצרן מספק ב-Partition נפרד, תראו שהוא אינו מזריק Image ל-Partition המרכזי אלא יש שם מספר קבצי BAT שמתקינים WIM בסיסי ועל זה הם מתקינים אפליקציה אפליקציה והגדרות עד למצב קבלת מערכת מוכנה (במפעלים המצב שונה כמובן כי שם יש שכפול מכני של הדיסקים באלפים, אם כי גם שם בחלק מהתהליך יש "הזרקה" של נתונים כמו מספר סידורי של Windows ל-UEFI ועוד).

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

אפשרות אחת פשוטה היא שימוש ב-PXE (לדוגמא iPXE) כך שהמחשב הנייד יהיה עם דיסק קשיח ריק והמחשב יבצע Boot מהרשת, וב-Boot הזה ניתן יהיה להתקין WIM בסיסי לחלוטין ללא הדרייברים החיצוניים שהספק נותן (הדרייברים הללו במקרים רבים מוסיפים זבל רב – "מנהל תקשורת", "מנהל סוללה" למרות ש-Windows מספק את שניהם בצורה טובה כולל דרייברים שמספיקים להתחבר ל-LAN ולתת תצוגה) ועם NET. ו-PowerShell.

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

  • לחבר את המחשב ל-AD
  • לבקש שם משתמש של הבחור/ה שהולך להשתמש במחשב
  • לבדוק לאיזו מחלקה הוא שייך
  • להתקין לו את האפליקציות שהוא צריך ואפליקציות שהארגון מצריך
  • לבדוק PCI ID של ציוד שאין לו עדיין דרייברים ולהתקין אותם דרך SCCM (או OneGet או NuGet) עם ה-MSI שהיצרן נותן (כאן לדוגמא – של לנובו).
  • במידה ויש הגדרות מיוחדותת, הסקריפט יריץ סקריפט אחר שיבצע את ההגדרות
  • התקנת עדכוני Windows אחרונים, אנטי וירוס וכו'
  • חלק ידני – בקשת הכנסת סיסמא חדשה מהמשתמש הסופי.

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

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

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

נעבור לאוטומציה:

אם יש משהו שכל איש Devops מתחיל צריך ללמוד ומהר – זה לעשות לכל פיפס תהליך אוטומציה דרך כלי אוטומציה (Ansible, Chef, Puppet וכו') כך שהוא לא יצטרך לחזור על התהליכים – וזהו בדיוק אחד הדברים שלדעתי כל חברה צריכה לא רק בשרתים – אלא גם בדסקטופים.

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

ומכאן – לתיעוד/דוקומנטציה.

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

מדוע בעצם זה קורה?

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

וזו בדיוק הבעיה של ה-wiki הפנימי או ה-Sharepoint של החברה או כל מערכת תיעוד אחרת: היא מסובכת למשתמש, וברוב המקרים היא טקסטואלית ואינה מושכת. חושבים שמישהו ממחלקת השיווק ישב לקרוא מסמך שתומך כתב איך לתקן בעיה XYZ? תשכחו מזה – והנה עוד טיקט נוסף לרשימה הבלתי סופית של טיקטים שהתומכים יצטרכו לטפל ועוד זמן שנשרף.

מה ניתן לעשות? כמה דברים:

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

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

להלן הוידאו מכנס JAMF:

המעבר לעננים

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

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

האם המעבר לאופיס 365 תגרום ל-Corporates השונים בארץ לעבור לגמרי לענן? לעניות דעתי – לא כל כך מהר. בשביל Mail, השהיה (Latency) של 100 מילישניות לערך אינה כזה עניין גדול, לא מרגישים את זה, אך כשמדובר ב-RDP או פרוטוקולים אחרים כמו HTTP ואחרים – העניין הופך לבעייתי ובכלל בארץ, בניגוד לסטארטאפים שמתחילים מהדקה הראשונה עבודה על ענן, ה-Corporates מאוד שמרנים ויקח זמן עד שהם יעברו לענן. גוגל, אמזון ומיקרוסופט מודעות בהחלט לעניין, ומיקרוסופט לדוגמא מכינה את ה-Azure Stack – הנה לך אדוני המנמ"ר/CTO "מיני Azure" שכולו יושב ב-Data Center שלך. כל ה-DATA שלך יושב בחווה שלכם ושום דבר לא זז החוצה אם לא תרצה, ואם תרצה – תוכל לחבר את ה-Stack הזה בקלות ל-Azure הענן. גם אמזון התכוננו לרגע הזה והם חתמו עם VMWare על פרויקט חדש שנקרא VMWare Cloud on AWS שנותן לך גם פתרון שמשלב את ה-Data Center שלך עם AWS כך שתוכל להתרחב מה-DC שלך החוצה ל-AWS (והפוך). גם לגוגל יש פתרון שהוא בפיתוח ובשלב זה אין עליו מידע פתוח.

המעבר לענן, לעניות דעתי, לא יהיה שאלה של "אם" אלא "מתי". אני לא צופה שבשנה הקרובה חטיבות ה-Hosting בסלקום/בזק בינלאומי/אורנג'/טריפל C יודיעו בקרוב שהן עוברות להפסדים כי הלקוחות העיפו את השרתים מהן (לזה יקח זמן רב, אם בכלל) – אבל המחשבה והדיבור על מעבר של לפחות חלק מהתשתית לענן ציבורי תעלה שוב ושוב בכל "צומת" שהחברה תצטרך להשקיע סכומים נכבדים ב-IT: רכישת רשיונות למערכות הפעלה, מעבר לסטורג' גדול אחר, הקמת ענן פרטי (כמו OpenStack) וכו'. כמובן שיהיו גם מקרים רבים שגם בעוד 10 שנים השרתים יהיו פה ב-DC בגלל רגולציה במקרים שונים.

ובכל זאת, חברות רבות "מסתקרנות" לגבי מעבר לענן. הסיפורים של כל מיני סטארטאפים איך הם נותנים שרות למליוני אנשים ומשלמים רק כמה אלפי דולרים בודדים בחודש לספק הענן גורם לסקרנות ולרצון להתנסות, המחירים בסנטים גם קורצים לחברה שמסתקרנת רצון לטבול אצבעות, ואז הן הולכות למחשבונים של ספקי הענן ואחרי מספר חישובים הן נרתעות. סתם דוגמא: באמזון, שרת Windows יחיד עם 8 ליבות ו-32 ג'יגה זכרון עם דיסק (EBS) של 200 ג'יגה יעלה לחברה $733 בחודש וזה כמובן לא כולל תעבורה החוצה וגם התמיכה של אמזון היא ברמת הבסיס. זול – זה לא. (אגב, גם בגוגל וגם במיקרוסופט המחיר יהיה פחות או יותר זהה) – אז הרעיון לנסות מעבר כלשהו נכנס בחזרה למגירה.

הרווח הגדול של ספקי הענן הגדולים מגיע מהשכרת שרתים ובמיוחד מהליבות (cores). הם מוכרים כל ליבה במחיר מוערך של 30-50$ לחודש וגם הזכרון אינו זול (בערך 10-20$ לחודש, תלוי בקונפיגורציה, מערכת הפעלה, סוג תקשורת וכו'). מדוע? כי כמות הליבות שניתנת למכירה בשרת אינה כה גדולה. שרת עם 16 ליבות אפשר למכור לדוגמא ל-20 לקוחות שכל אחד מקבל ליבה, אבל לא ל-30 לקוחות – כי הלקוחות רוצים ביצועים (בניגוד לספקי VPS שדוחפים עשרות לקוחות על מכונה עם 8 ליבות). ספקי הענן יכולים לרכוש שרתים עם 8 מעבדים כשכל אחד מהם כולל 16 ליבות לדוגמא, אבל העלות של שרת כזה גבוהה מדי בשבילם ולכן ברוב המקרים אם תבדקו מה המעבד שנמצא במכונה שלקחתם מספק הענן, תמצאו שהמכונה מכילה מעבדים כמו Xeon E5 26XX (כלומר מקסימום 2 מעבדים ועד 8 ליבות פר מעבד, ברוב הזמן זה יהיה דגם של 4 ליבות). יש לספקי הענן גם מכונות עם מספר מעבדים וליבות גדולים, אך המחיר – גבוה בהרבה מהמחיר שציינתי.

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

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

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

אחרי שפתחנו חשבון אצל ספק הענן, נצטרך לבחור מה הפרויקט שאנחנו הולכים להעביר ואלו VM הולכים לעשות מעבר, והכי חשוב – כמה ג'יגהבייט/טרהבייט אתם הולכים להעביר לספק ענן. אם מדובר לדוגמא בג'יגהבייטים בודדים או עשרות בודדות של ג'יגהבייט, אפשר להעלות את קבצי ה-VM דרך האינטנט, אך אם מדובר בעשרות או מאות ג'יגהבייט או יותר – כדאי להשתמש בשרותי ה-import/export Disk של ספק הענן, כלומר תצטרכו להכין דיסק קשיח (או פתרון אחר בהתאם לספק הענן) ולשלוח אותו לפי הוראות ספק הענן. המחיר – דווקא די זול, בסביבות ה-80$ ועוד 2.50 דולר פר שעת עבודה להעלאת הנתונים (אמזון לדוגמא).

לאחר שהנתונים יועלו לספק הענן, נצטרך להתחיל לבנות את התשתית המאובטחת שלנו מבחינת כתובות IP פנימיות, Subnet, Internet Gateway וכו' וכו' ולהחיל אותם על ה-VM שלנו שבענן (אצל חלק מהספקים יש צורך בהקמת ה-VM מהגיבוי שהעלתם/שלחתם, אצל חלק זה אוטומטי). אחרי שיש לנו את ה-VM למעלה, יכול להיות שנצטרך לשנות כתובות IP בהתאם לתשתית שהגדרנו. המטרה הסופית היא שבסוף כל ה-VM ששלחתם יעלו ותהיה לכם תקשורת אליהם בדיוק כמו שיש אצלכם ב-DC (אם כי ישנם שינויים שתצטרכו לעשות, כמו לא לתת כתובת IP חיצונית לכל שרת אלא לעבוד בצורה מסודרת מול Gateway או עם Bastion אם אתם עובדים עם מכונות לינוקס). הכל עובד? מצוין. בשלב זה תתחילו לעבוד עם המערכת כמו שהיא בימים או שבועות הקרובים. קיבלתם קרדיט, זה לא עולה לכם שקל, נצלו את זה 🙂

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

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

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

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

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

ולמי שמעוניין לעבור את התהליך או לקבל יעוץ – אשמח לסייע 🙂