ה-LAB הבא: על צריכת חשמל

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

בואו ניקח מחשב דסקטופ רגיל. אנחנו נמצא בו מעבד של AMD או אינטל עם צריכת חשמל של עד 65 או 90 וואט (ללא Overclocking) זה ה-TDP שהוא ממוצע. מעבד כמו אינטל i7-6700K בעומס יצרוך 116 וואט. בחלק מהמקרים שיש שם גם כרטיס גרפי יעודי למשחקים וכו', צריכת החשמל שלו תהיה בין 100-300 וואט (ה-300 במקרים של VEGA מ-AMD, במקרים של nVidia זה בד"כ מגיע גג בצריכה מקסימלית ל-250 וואט). שאר הציודים במחשב לא ממש צורכים הרבה. מאוורר (גם בפעילות מלאה) צורך 0.6 וואט ודיסק קשיח צורך בין 5-9 וואט.

כלומר ספק כח של 300-500 וואט יכול בהחלט להספיק ל-PC רגיל. (שוב, בלי Overclocking)

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

אם נסתכל על החלק שצורך את הכי הרבה חשמל, מדובר כמובן במעבדים. הבה ניקח מעבד פופולרי בשרתים כמו ה-Xeon E5-2620 V4 בזוג. אם תסתכלו על הדף הזה, תראו שהמקסימום צריכה של כל השרת מגיע ל-368 וואט. שוב, ספק 500 וואט יספיק פה לחלוטין.

כל העניין של חיבור תלת פאזי הוא מהסיבה שאנחנו רואים את זה בחוות שרתים. ארון 42U עם 20 שרתי 2U, או 40 שרתי 1U (או הרבה פחות אם השרת הוא עם U יותר גבוה) אז כן – צריכת החשמל עולה ועולה ואז באמת צריך חיבור תלת פאזי.

אבל בבית, מה בדיוק נקים? 2-4 שרתים? ברוב המקרים זה יהיה 2-3), זה יהיה כמו להפעיל 5 מחשבי PC בתצורת Desktop. נוסיף לכך את העניין שמדובר ב-LAB וברוב המקרים מה שנריץ לא יתפוס באופן קבוע את המעבדים בצריכת 100% אלא יותר לכיוון ה-20-40% כך שצריכת החשמל עצמה לא תהיה גבוהה.

בלוח החשמל שלנו יש לנו מתג ראשי שמקבל כמות מסויימת של אמפר (בחלק מהמקומות זה 24, בחלק 32 וכו' – צריך לשאול את חברת חשמל לגבי הבית שלך), והמתגים המשניים יכולים להעביר X אמפר לאותם נקודות להם מחוברת נקודת המשנה (בד"כ זה 10 או 16 אמפר, תלוי במתג המשני). כשמתכננים LAB, כדאי לחשב צריכה פר שרת (Amp = Watt/Volt) וכמובן יש לקחת בחשבון ציודים אחרים שמחוברים לאותו מתג משני, כך שאפשר בהחלט להגיע למצב שלא צריך להגיע לקניית הרחבה לחיבור תלת פאזי.

נקודה נוספת חשובה: סוג המעבד. מעבדים כמו Xxxxx (כמו X5670) ומעבדי E5 צורכים לא מעט וואט, אבל אפשר גם ללכת על מעבדי L עם מעטפת צריכת חשמל נמוכה (65 וואט). החסרון: המהירות נמוכה ב-1 ג'יגהרץ לערך ממעבד E5, כך שאם אתה מוכן לאיטיות קלה, תוכל לחסוך בחשמל.

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

כאב ראש: התקנת אפליקציות כבדות וממשקי משתמש בהווה

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

אחת הבעיות היותר מתסכלות בכל מיני אפליקציות כבדות – היא התקנה במערכות לינוקס (ואני לא מדבר על התקנת אפליקציות ב-DEB או RPM שבהם פקודת yum או apt עושה לך את העבודה). תרשו לי לתת 2 דוגמאות להקמת מערכת POC של אפליקציות כבדות כאלו.

נתחיל עם OpenStack. חברת קוקי יבואני נעליים (כן, שם מהסרטים) החליטה ש-Openstack זה יכול להיות אחלה פתרון בשבילם, אבל הם קודם רוצים ללמוד בכלל מה זה, ואם אפשר – שיקימו על VM את המערכת שהחבר'ה יוכלו להתרשם וקצת לשחק עם זה. בשום מקרה ה-VM לא הולך להיות שרת פרודקשן. במקרה כזה אם מישהו מחברת קוקי יצור איתי כפרילאנסר קשר לגבי זה, אשמח לדוגמא להפנות אותם לדף פרויקט ה-RDO כדי להקים את ה-OpenStack. כל איש סיסטם, גם אחד כזה שאין לו הרבה נסיון עם לינוקס יוכל לעקוב אחר ההוראות הכי פשוטות ולהקים מערכת. אחרי הכל, כל מה שאיש הסיסטם יצטרך לעשות זה להקים VM עם מערכת הפעלה CentOS 7, עם 32 ג'יגהבייט זכרון ועם 4 ליבות, לבצע SSH למערכת, לוודא ששם ה-hostname הוא אכן תקין ומופיע ב-DNS של החברה, ולהריץ את הפקודות. משם הכל יבוצע באופן אוטומטי ולבסוף גם יופיעו לו הוראות איך להתחבר למערכת.

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

ויש גם דוגמאות הפוכות: אותה חברת קוקי, נניח שהיא קראה בבלוג העסקי שלי על OpenShift והיא רוצה להקים אותו אצלה כדי "לשחק" עם הפלטפורמה. בחברה יש כבר נסיון עם קונטיינרים והם שוב פונים אליי, ואני אשמח להפנות אותם לדף הזה אם הם משתמשים במערכות Red Hat או לדף הזה אם הם משתמשים ב-CentOS וספציפית לחלק של הקונטיינרים עם Docker. הפקודה שם לא תעבוד כי מישהו שכח להוסיף פרמטר
(v /sys/fs/cgroup:/sys/fs/cgroup:rw-) ורק אחרי הוספת הפרמטר הקונטיינרים יעלו והמערכת תעבוד, אבל אחרי שהם יכנסו למערכת הם יראו שיש מספר "הפתעות" לא נעימות כמו:

  • אין Templates. למה? שאלה טובה. אפשר להשלים את זה כשעוקבים אחר ההוראות בדף הזה (ההוראות שם לא תמיד עובדות, יש צורך בידע ב-BASH) כדי להתגבר.
  • על מנת להקים קונטיינרים ולאכסן אותם – יש צורך ב-Container Registry. הפתעה! יש קונטיינר עם Registry אבל הקונטיינר של ה-OpenShift והוא "לא מדברים", בהצלחה עם השילוב ביניהם.

אז אולי יש דרך אחרת להקים OpenShift? כן, יש Installer כלשהו וזה זמין כאן אך מכיוון שרובנו עובדים עם CentOS ולא עם RedHat אז עדיף לך ללכת לקישור לדף העליון שמוזכר לגבי CentOS, רק שאל תבנה על כך יותר מדי, רד-האט הוציאו את ה-Installer הזה לפנסיה מוקדמת. פתרון חלופי ל-Installer? רעיון טוב, בינתיים אין משהו. יש כמובן את הדרך של ההתקנה עם Ansible, רק שהיא מצריכה ידע כלשהו ב-Ansible והיא דרך די מעולה… לגרום לך להוציא שערות מהאף (אם אתה לא מכיר Ansible). יש כמובן דוגמאות באינטרנט איך אתה יוצר קובץ הגדרות די מינימלי ומריץ אותו מול תיקיה מסויימת ב-openshift-ansible (שאותו אתה צריך לשכפל מה-GIT) עם קובץ מה-GIT בשם openshift-ansible/playbook/byo/config.yml רק ש.. הפתעה, הקובץ config.yml לא קיים, ואף אחד לא טרח לעדכן את זה וגם כשאתה מצליח למצוא פתרון חלופי (כאן) תקבל כמה שגיאות בהרצת ה-playbook (הנה הטיקט שלי על כך) כאן.

(אגב, מי שמחפש להקים על הלאפטופ שלו את OpenShift, יש את minishift שהוא באמת קל להתקנה ולחובבי Kubernetes יש את minikube – הכל רץ על Windows, Mac ולינוקס כל עוד מותקן לכם פתרון וירטואליזציה בלאפטופ, אם כי יש בעיה להקים את זה על ESXI, המערכת מקימה בתוכה VM פנימי עם NAT ואז אינך יכול לגשת לשם ממשק web או לאפליקציות שלך. שינוי מ-NAT ל-Bridge לא עוזר).

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

  1. לבנות ממשק Web או ממשק טרמינל עם ncurses (זוהי ספריה שמאפשרת לך ליצור "GUI" טקסטואלי, משהו שמזכיר בעבר הרחוק את Magic ב-DOS למי שזוכר) שאיתם ניתן לבנות ממשק ששואל את המשתמש קבוצת שאלות כל פעם.
  2. ממשק ה-Web/GUI אמור לבדוק את הפרמטרים מיידית. הכנסת שם FQDN לא נכון? כתובת לא נכונה? פורט לא נכון? תיקיה לא נכונה? המערכת אמורה מיידית לסמן שהפרמטר בשדה זה שגוי (בד"כ עם מסגרת מלבנית אדומה סביב אותו שדה) ולא לתת למשתמש להמשיך הלאה עד שזה יתוקן.
  3. אפשרות חביבה שקיימת ב-oVirt היא שמירת קובץ תשובות, כך שאפשר במסגרת ממשק ההתקנה לאפשר למשתמש להעלות קובץ תשובות קודם, כך שאם צריך להקים את המערכת בשרת אחר, הדברים יהיו קלים ומהירים בהרבה.
  4. התקנה אוטומטית דרך SALT או Ansible הכלולים בחבילה אמורה להוציא גם פלט קריא אנושית כך שגם מישהו שאינו מומחה אוטומציה יוכל להבין מה בדיוק התקלה ואולי יוכל לתקן אותה. אחרי הכל – אם מישהו נמצא במסגרת Trial, הוא לא תמיד זכאי לתמיכה.

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

Exit mobile version