קטגוריה: כללי

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

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

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

[stextbox id="info"]הערה לקוראים: מדובר על דו"ח הפצות לינוקס ב-Corporate, לא בסטארט-אפים, לא בבית ולא במערכות משובצות.[/stextbox]

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

החלטתי לכתוב דו"ח מקוצר משלי, רק שבניגוד לכל מיני דוח"ות, אף אחד לא משלם לי על הפוסט הזה ואינני מנסה "לדחוף" שום הפצת לינוקס. מה שאני משתמש באופן אישי בביתי ובשרתים הוירטואליים שלי בין כה לא יתאים לחברות (אני משתמש בפדורה 24 וב-Clear Linux של אינטל למטרות שונות) ובוודאי לא לפרודקשן.

בעולם ה-Windows אף אחד לא מתקין לעצמו Windows Server 2012 R2 כתחנת עבודה. בלינוקס לעומת זאת, באופן עקרוני כל הפצת לינוקס יכולה לשמש הן לת"ע והן לשרת. אם תיקחו לדוגמא הפצה כמו CentOS 7.2 ותבחרו את הרכיבים הנכונים, לא תהיה שום בעיה להריץ אותה על כל שרת כ-שרת או על לאפטופ כמכונת דסקטופ רגילה. יחד עם זאת – ישנם הפצות שמיועדות יותר ל-Workstation, ויש ל-Server.

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

מבחינת ת"ע, הבחירות שקיימות היום לשוק ה-Corporate הן ההפצות הבאות:

• רד-האט 7.2 ותואמיו (CentOS, Oracle Linux)
• אובונטו
• SuSE Linux Enterprise Desktop (או בקצרה: SLED)

ישנן כמובן עוד הפצות כמו Debian, Gentoo, Arch ואחרות, אולם הם מיועדות לאנשי לינוקס מקצועיים ובד"כ לא רואים אותן בחברות הישראליות.

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

מבחינת הבדלים בין הפצות – רד-האט ותואמיו, ו-SLED עובדים על עקרון פשוט: מה שיש בהפצה מבחינת אפליקציות, שרותים, ספריות וכו' – זה מה שיש, זה מה שמקבל באופן רשמי תמיכה. מחר תצא גירסת Ruby חדשה, PHP חדשה או ספריות חדשות? הן לא חלק מהחבילה והן לא נתמכות במסגרת חוזה התמיכה של החברה מול יצרן ההפצה. הדבר שבראש וראשונה מודגש בהפצות לינוקס האלו היא שמירת תאימות ויציבות, גם במחיר ויתור על פונקציונאליות חדשה. כשאתה משתמש בהפצה כזו, אתה יכול להיות שקט מבחינת תמיכה. ברד-האט לדוגמא, כל גירסת Major של הפצה נתמכת 10 שנים (וכך אגב, גם ההפצות התואמות לרד-האט). בתוך תקופה זו היצרן משחרר עדכונים תקופתיים, אך עדכונים אלו שומרים על 100% תאימות בינארית, כלומר אין בעיה לדוגמא לעבור מרד-האט 6.1 ל-6.8 במכה אחת, התאימות תישאר במלואה.

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

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

• אם ההתקנה תבוצע עבור הרצה של אפליקציות מסחריות שמגיעות עם קבצים בינאריים בלבד כקוד סגור (SolidWorks, סימולציות רפואיות, סימולציות מדעיות, שימוש בכרטיסי Tesla או כרטיסי PCie קנייניים לשימושים ספצייפיים, לא כרטיסי GPU רגילים וכו') – מומלץ לבחור הפצה כמו Red Hat או SLED או אורקל לינוקס. אלו הפצות שנמכרות בתשלום. אם אין כסף לרכישת הפצה, אפשר להשתמש ב-CentOS, רק כדאי לקחת בחשבון שיצרני התוכנה הנ"ל לא ששים לתת תמיכה ל-CentOS (פוליטיקה). אובונטו במקרים רבים עם אפליקציות כאלו מקבל "כתף קרה" – תשאלו את IBM לדוגמא.
• אם ההתקנה תבוצע עבור פיתוח אפליקציות בקוד פתוח תוך שימוש בקוד פתוח אחר כאשר אין הסתמכות על אפליקציות בינאריות סגורות – כאן אפשר לבחור את SLED, CentOS או אובונטו LTS. אלו הפצות שקל מאוד להרחיב אותן בעזרת מאגרים (Repositories) חיצוניים נוספים על מנת לקבל גרסאות חדשות של אפליקציות ודברים שלא מגיעים עם ה-ISO הרשמי.
• אם ההתקנה מיועדת לאנשי לינוקס ותיקים שלא מצריכים תמיכה – אני ממליץ פשוט לתת להם לבחור ISO ושהם יתקינו בעצמם מה שהם רוצים. אנשי לינוקס מקצועיים מסתדרים בד"כ בעצמם עם הבעיות בתחנה שלהם 🙂

כשזה מגיע לשרתים – ההפצות המומלצות שונות במעט מת"ע:

• Red Hat Server Edition
• SuSe Linux Enterprise Server (בקצרה: SLES)
• Ubuntu LTS
• CentOS 7.2 Server Edition (גירסת DVD ISO)
• Oracle Linux

מכיוון ששרתים נחשבים הרבה יותר "חשובים" מדסקטופ/ת"ע, חשוב לבחור בהפצה הנכונה וגם במי שנותן לחברה תמיכה. אפשר בארץ לדוגמא לרכוש רשיון ל-Red Hat ואת התמיכה המוצעת, אך גם חברת SuSE ישראל וגם אורקל ישראל מוכרים שרותי תמיכה לרד-האט (ל-SuSE יש גם כלי מסחרי לניהול עדכונים שנקרא SuSE Manager הן ל-SLES, SLED, CentOS, Red Hat שנמכר ונתמך פה בארץ). הפצות כמו Red Hat ו-SLES מגיעות עם תמיכה מסחרית כך שההנהלה יכולה להיות שקטה שאם תקרה תקלה, יהיה מי שיענה, גם באמצע הלילה (ובמקרה של SuSE – בעברית). אני מודע לכך שחברות מעדיפות לוותר על רכישת רשיון (במיוחד כשיש צוות IT עם ידע בלינוקס), אבל לפעמים יש צורך ברכישת רשיונות כשצריך להריץ אפליקציות בינאריות והיצרן מתנה תמיכה רק אם בשרת מותקנת הפצת לינוקס מסחרית עם רשיון תקף.

לכן, חשוב לבחור איזו הפצת לינוקס להתקין בשרתים וחשוב לבחור הפצה שיצרני חומרה תומכים בה באופן רשמי. הפצות אלו הן Red Hat (הגרסאות התואמות יכולות להריץ דרייברים שנכתבו עבור רד-האט במידת הצורך), SLES. אובונטו, שוב, מקבל הרבה פחות תמיכה ו-Certficiation מיצרנים, גם בגירסת LTS, במיוחד כשמדובר בציודים כמו NVMe שהפצת גירסת ה-Server של אובונטו לא תומכת בצורה טובה, לדוגמא.

כשמדובר במכונות וירטואליות, כל ההפצות נתמכות, אם כי, שוב, רד-האט ותואמיו לוקחים את זה צעד קדימה וכל הכלים כדי להתממשק עם ה-Host כבר נמצאים ב-ISO, בין אם מדובר ב-ESXi או Hyper-V ווירטואליזציות אחרות. הכל תלוי ב-Policy של החברה.

כשמגיעים לבחירת הפצת לינוקס, לא חשוב איזו הפצה החלטתם לרכוש, חשוב לדעת ממי לרכוש. בארץ יש לא מעט License Pushers שסגרו עסקאות עם הפצות לינוקס שונות והם מוכרים רשיונות. כשזה מגיע לתמיכה לעומת זאת .. או שתקבל תמיכה מהודים, או שתקבל איש לינוקס הכי זול שהם מצאו כדי שיגיע אליך ולא בטוח שהוא יוכל לתמוך בך. לכן חשוב לבחור חברה שנותנת לך תמיכה בעברית עם אנשים שיש להם ידע עשיר בלינוקס בהתאם ל-SLA שאתה בוחר ושיש לה נציגות רשמית, לא נציגות של מפיץ. ל- Red Hat, SuSE ואורקל יש כאלו בארץ. ראיתי לצערי מספיק מקרים שחברות התפתו להתקין שרתי לינוקס מחברה שמוכרת שרותי Windows ואז יום אחד אותו ספק הפסיק לתמוך בלינוקס שהם התקינו ללקוח כי .. איש הלינוקס של אותה חברה המשיך הלאה בחייו, לכן כשזה מגיע לרשיונות וחוזי תמיכה – קחו מחברות שלינוקס זו הפעילות העיקרית שלהן.

והערה לסיום: ראיתי לא מעט חברות שעוברות ללינוקס או עוברות לגירסת לינוקס אחרת והדבר נעשה ע"י חברה חיצונית. בלא מעט מקרים לא נלקח יעוץ עצמאי ובלתי תלותי לגבי המעבר והח"מ ראה מספיק מקרים של פרויקטים שנעשו עם המון דברים לא נכונים ו/או מיותרים ו/או חסרים, החל מדברים פשוטים כמו Volume Management ועד תצורת אשכולות שכלל אינה לוקחת בחשבון את מה שרץ מתחתיה כדי לקבל יתרונות נוספים. המלצתי האישית – קחו יעוץ עצמאי ובלתי תלותי (לא מישהו מטעם מי שיבנה את הפרויקט) שיתן "מבט שני" בפרויקט ומה הולכים לעשות. זה יעלה כמה מאות דולרים/שקלים (תלוי ביועץ) – וזה שווה את זה. היעוץ הזה יכול במקרים רבים לחסוך הרבה יותר מהעלות של היעוץ. מבלי לאמר שמות, אני יכול לציין לדוגמא חברה ממשלתית שהשקיעו מאות אלפי דולרים במערכת שרתים ואפליקציות והם צריכים בקרוב לשלם יותר מ-$50,000 תחזוקה שנתית – ולפי בדיקה שערכתי, כל המערכת הזו לא עברה בחיים ניצול של יותר מ-2.5 אחוזים, שרתים שלא היה להם יותר מ-1% שימוש ומערכי דיסקים שאינם מפורמטים אפילו ואיש אינו חושב להרחיב את המערכת. למה? כי מישהו שמע הצעה אחת של חברה והחליט לשפוך כסף.

לכל מי שיש בבית מספר מחשבים שמשמשים אותו כ-LAB, משתמש בוודאי בוירטואליזציה כדי להקים מספר שרתים וירטואליים וכמעט כולם מקימים לעצמם שרותים כמו DNS, AD, DHCP, מייל (החוצה) ואולי גם מערכת ניטור פשוטה כדי להשגיח על הכל.

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

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

לכן אני ממליץ בד"כ להקים את הדברים החיוניים על "שרת" נפרד שאינו וירטואלי, ועד כה ההמלצה שלי היתה על Raspberry Pi (במיוחד על ה-3). הוא קטן ואפשר להחביא אותו, ואפשר לסדר לו פתרון "UPS" שמורכב מסוללה חיצונית וזה יחזיק יותר מ-10-15 שעות בלי יותר מדי מאמץ. צריך אמנם לכתוב סקריפטים שידעו לבדוק אם יש חיבור LAN (ואם לא, לבצע unmount או לבצע soft mount), ואולי גם לחבר לו מודם סלולרי כך שבמקרה ויש הפסקת חשמל הוא ימשיך לעבוד, לצלם ולשלוח את התוצאות לענן דרך מודם סלולרי.

אבל ל-Pi-3 יש כמה בעיות קטנות:

• אין לו אמצעי אחסון אמין. כרטיס מיקרו SD הוא טוב אבל הם מתקלקלים הרבה יותר מהר מאשר אמצעי אחסון פנימי "אמיתי", במיוחד אם השרת הקטן כותב קבצי לוגים לוקאלית, קבצי תמונות (מהמצלמה) או קבצים אחרים – בעת ובעונה אחת. כרטיס מיקרו SD הוא מדיום מאוד איטי בכתיבה והוא לא יודע לעבוד במצב של גם קריאה וגם כתיבה במקביל, זה או זה או זה.
• כמות RAM: רבים מספרים ש-1 ג'יגהבייט RAM ל-Pi-3 זה מספיק בהחלט, וזה נכון כשמריצים כמות דברים קטנה, אך מנסיון – כשדברים עובדים, רוצים להכניס עוד כמה שרותים "קטנים" – אולי איזה Torrrent Client קטן שיעשה את העבודה ב-NFS/CIFS, אולי תוכנת ניטור שאינה מינימלית, אולי תוכנת מעקב מצלמה – וכך ה-Pi-3 הנחמד יהיה עמוס וצוואר הבקבוק הראשי עדיין יהיה כרטיס המיקרו SD או הזכרון.

אחד החסרונות של השוק הסיני הוא שבשוק זה יש המון יצרנים (חלקם מייצרים דברים טובים, הרוב זבל) – אבל במקרים רבים הם מפספסים שווקים פוטנציאליים. קחו לדוגמא את שוק המחשבי MINI PC – בקושי היו כאלו עד שאינטל הודיעה שהיא תעזור ליצרנים בהכל – החל מתכנון לוח, אספקת רכיבים (כולל לוח מוכן עם צ'יפים מולחמים) – ואז השוק הזה פרח. במקביל שוק האנדרואיד (שמיועד לטלפון/טאבלט) גם פרח בשוק הסיני וקיבלנו הצפה עם מחירים שמתחילים ב-22$ ומעלה.

הבעיה של השוק הזה – שהוא לא מזהה הזדמנויות כמו מכירה של הציוד עם הפצת לינוקס. כיום לדוגמא, ישנם מכשירים בודדים שמציעים לינוקס. יש כמובן את כל אלו שמתחרים ב-Pi-3 אבל ברוב המקרים מדובר במעבדים חלשים ואלו שטובים – מגיעים (כולל קופסא, ספק וכו') בקלות למחיר ה-100$. לעניות דעתי, אם ציוד שנמכר עם אנדרואיד במחיר של 40-50$ היה נמכר עם אופציה חינמית להתקנת לינוקס – היצרנים היו יכולים לעשות כסף לא רע, אבל כיום – מספר האופציות מצומצם יחסית – (אם אתה מחפש קופסא אחת שכבר בנויה ומכילה הכל ולא בחלקים או ציוד די חלש)

בשבועות האחרונים ראיתי משהו מעניין – יש לא מעט חברות סיניות שמוכרות MINI-PC פשוטים וזולים במחירים של בערך 70-80$ (ומעלה) שכוללים:

• מעבד ATOM Z8300 מרובע ליבות במהירות עד 1.8 ג'יגהרץ
• 2 ג'יגהבייט RAM
• 32 ג'יגהבייט אחסון פנימי
• כניסת כרטיס מיקרו SD
• 2-4 פורטים USB-2/USB-3
• Windows 10 (חלקם ללא רשיון מאוקטב, חלקם מאוקטב, חלקם עם רשיון פרוץ)

הנה לדוגמא מכשיר NEXBOX T10 שעולה 77$ לערך. יש גם את Wintel Pro CX-W8 שעולה 72$ (אך יש לו 3 חיבורי USB, לא 4).

אם נשווה את המחירים האלו ל-Pi-3 (גירסת חבילה), ה-Pi-3 עולה כ-50$, כלומר ההבדל הוא בסביבות ה-20-30$.

מכשירי Mini PC כמו הדוגמאות לעיל יכולים להיות "שרתים" מצויינים בהשוואה ל-Pi-3. היתרונות:

• כמות זכרון (RAM) כפולה
• מעבד יותר מהיר (ב-10-60% תלוי במבחן)
• אמצעי אחסון פנימי הרבה יותר אמין מכרטיס מיקרו SD (וב-32 ג'יגהבייט אפשר להתקין המון דברים כשזה מגיע ללינוקס)
• מכיוון שמדובר במעבד אינטל, אפשר להתקין כמעט כל הפצת לינוקס עדכנית (פדורה, OpenSuSE או אובונטו 16) ואם צריכים להוסיף REPO/PPA חיצוני – אז לא צריך לחפש אם יש גירסאות ARM לאפליקציה, אפליקציות 32 ו-64 ביט ירוצו מעולה על מכשיר כזה (שימו לב איזו גירסת הפצה אתם מתקינים, גירסת 32 ביט לא יכולה להריץ אפליקציות 64 ביט אבל ההיפך אפשרי).
• מבחינת UPS – לא צריך UPS גדול ויקר, אפשר לחפש Battery Pack שיכול לשמש כ-UPS (מומלץ לבדוק את הנושא לפני שרוכשים כל Battery Pack).
• אם רשיון ה-Windows 10 Home חשוב לך, גבה את המכשיר לפני שתפרמט, אולי תשים את זה על VM כלשהו 🙂

עם פתרון כזה אנחנו מקבלים "כמו Pi-3" אבל עם זכרון כפול, אחסון קבוע, ותאימות אינטל.

אישית – אני מחכה ל-Wintel שיגיע לי כדי להשמיש אותו כ"שרת".

ומה דעתכם?

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

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

אחד הדברים החשובים הוא לשים לב לאיזה דיסקים SSD אתם הולכים לרכוש ומה המשימות שיריץ השרת עם הדיסקים שאתם רוכשים.

לדוגמא: יש לכם 2-3 שרתי ESXI, אין לכם אחסון משותף (NAS או SAN) ואתם מפעילים DRS (זה אפשרי, אם עומדים בדרישות). אחד מהשרתים נהיה עמוס והמערכת מתחילה להעיף VM החוצה לשרתים אחרים, מה שאומר – הרבה קריאה, הרבה כתיבה, אבל אם בחרתם SSD מבלי לבחור לדוגמא Mixed Intensive כל פעילות המיגרציה תהיה איטית ולא רק המיגרציה תהיה איטית אלא כל פעילות המכונות הוירטואליות שרצות בין השרתים שעוברים מ/אל השרתים הפיזיים – תהיה איטית. מדוע? כי זה שביקשתם SSD לא אומר שתקבלו את הדיסקים העוצמתיים, קיבלתם את הדיסקים שהם לא ממש "חיות ביצוע" (בלשון המעטה).

אחת הטעויות שרבים הרוכשים שרתים שעושים – היא להסתכל בטבלה של היצרן ולבדוק IOPS. קחו לדוגמא את HP שמציגים את ה-SAS SSD שלהם עם IOPS מעולה של 6 ספרות בקריאה ו-5 בכתיבה. נשמע מעולה, נכון? רק שהמספרים הללו משקפים עומס צפוי ולפרק זמן קצר, כלומר המספרים משקפים עומס שאינו רלוונטי במציאות. כמו שאנו יודעים, במציאות כשאנחנו מעבירים לדוגמא VM (ולא משנה אם מדובר ב-Hyper-V או ESXi) גודל ה-VM הוא עשרות ואפילו מאות ג'יגהבייטים, כך שאתם תראו העברה שמתחילה מהר אך כבר לאחר רגעים ספורים ההעברה תהיה איטית. איפה כל ה-IOPS שהובטח? אז הבטיחו.

ציינתי לעיל שבמקרה של DRS דברים נהיים איטיים בדיסקים SSD שקונים בברירת המחדל, אך נקודה חשובה  לא פחות היא העובדה שכל VM גם הוא דורש כתיבה/קריאה ובחלק מה-VM הכתיבה היא מרובה יותר מקריאה ובחלק אחר זה הפוך ובעוד חלק – זה "באמצע". כל כתיבה/קריאה נכנסת ל-Queue, מה שנקרא Queue Depth וככל שה-Queue יותר גדול, כך לוקח זמן ל-SSD שמגיע בברירת המחדל ברכישת שרת – לעשות את העבודה, וזאת בניגוד ל-SSD שתוכננו מראש גם לעמוד בעומסים של QD 32-256 לדוגמא, כך ששוב – תכנון ובחירת SSD נכונים עושים הבדלים של שמיים וארץ!

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

וזה אחד הדברים שלצערי הרבה מנהלי IT מסרבים בעקשנות לעשות: לקנות דיסקים מספק חיצוני במקרים של LENOVO/HP. סמסונג, ואינטל (וקצת משתרכת מאחור Sandisk ו-Toshiba) מרעננים דגמים כל שנה עם בקרים יותר משוכללים, עם מהירויות מטורפות ועם אורך חיים יותר גדול. גם לסמסונג וגם לאינטל יש נציגים רציניים בארץ עם שרות שליחים במקרה של תקלות (בדיסקים Enterprise) ובמקרים רבים אפשר לחסוך מאות דולרים פר דיסק וגם לקבל את המילה האחרונה ב-SSD ובכך לקבל ביצועים מעולה ושרות מנציג יצרן הדיסקים (אגב, אני תמיד ממליץ לרכוש את כל הפלסטיקים של ה-Tray – היכן שיושבים הדיסקים, כך שבעת רכישת דיסק נוסף, לא צריך לחפש את ה-Tray כדי להכניס חדש).

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

נקודה שנשאלתי כמה פעמים: קנינו כבר שרתים עם SSD. הם ב-RAID-5 כבר. מה לעשות? פה זה תלוי בכם. אם אתם מרוצים מהביצועים – השאירו את הדברים כך ובהזמנה הבאה תשנו דברים. לא מרוצים מהתוצאות? העבירו VM שדורשים יותר כתיבה לשרתים אחרים והעבירו VM שקוראים הרבה יותר משכותבים – למכונות הנוכחיות עם ה-SSD שכבר קניתם.

לסיכום: אם אין לכם את הידע, קחו יעוץ. שעה שעתיים של יעוץ יכולה לחסוך המון כאבי ראש ואכזבות בעתיד.