קונים/מטמיעים שרתים? כדאי שתקראו

ברוב החברות, עד שהם רוכשים שרתים אפשר לפתוח בקבוק שמפניה. רוב החברות רוכשות שרתים אחת לכמה שנים ועם כניסת טכנולוגיות הוירטואליזציה השונות, כמות השרתים הנרכשת – קטנה. אחרי הכל, הרבה יותר קל וזול לדחוף עוד כמה עשרות ג'יגהבייט זכרון לשרת ואולי להוסיף/לשדרג מעבדים מאשר לרכוש ברזל חדש (האמת שיש לי בנושא ויכוח עם כמה אנשי IT. אחרי הכל, שרתים בסיסיים שכוללים 2 מעבדים 4 או 8 ליבות ו-16 ג'יגה זכרון + 2 דיסקים SATA – לעיתים יותר זולים משדרוג שרת קיים, תלוי בגודל השדרוג) – בתחום הזה כל חברה מחליטה לעצמה איך ולאן מתקדמים.

תחום השרתים עצמו די מתפתח. היו לנו שרתי Blade (זוכרים?) וכיום יש מחברות כמו SuperMicro שרתים שהם Twin שהם 2 או 4 שרתים במארז 2U או 4U (בהתאמה) וחברות אחרות גם העתיקו את הטכנולוגיה. היום גם ניתן להכניס דיסקים SSD PCI שעברו דיאטה רצחנית והם בעובי 7 מ"מ וניתן להכניס בין 10-15 דיסקים כאלו במארז 1U (תלוי ביצרן). מבחינה פנימית – כל יצרן בנה לעצמו פתרונות (שחלקם הגדול די קנייני) על מנת לבדל את מוצריו מהמתחרים. חלק מהפתרונות לדעתי תמוהים, חלק מעניינים – אבל ברוב המקרים הטכנולוגיה סגורה. קחו לדוגמא את HP – תכניסו דיסקים שאינם של HP (שבעצמם כלל לא מייצרים דיסקים) ותקבלו הודעה מעצבנת שהדיסקים אמנם יעבדו אבל אם תהיה תקלה – לא תקבלו LED אדום על אותו דיסק. בשבילי כאחד שעוקב כמעט מדי יום לגבי טכנולוגיות חדשות כמעט בכל סוג חומרה – זה מעצבן, כי תמיד יש פתרונות חדשים במחירים מעניינים. בשביל חברות – זה כלל אינו ISSUE, הם פשוט יקנו את הדיסקים מיצרן השרת וישלמו עוד כמה אלפי דולרים. בגלל זה אני מעדיף שרתים "לבנים" מיצרנים כמו TYAN, SuperMicro, ASRockRack, Gigabyte ו-ASUS (האחרונים יותר מייצרים לוחות אם מאשר שרתים מוכנים ללקוח).

ישנה נקודה חשובה שלצערי אינה ידועה רבות כשרוכשים שרתים חדשים: לא מומלץ להכניס אותם ל-DMZ שלכם. מדוע? אסביר.

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

  • החברה אינה מודעת לכך שיש עדכונים, במיוחד כשמותקנת מערכת כמו ESXI או לינוקס. אחרי הכל, למערכות הפעלה אלו יש מערכת עדכונים שמעדכנת את ה-OS, אך לא ממש מעדכנות UEFI/BIOS או עדכוני קושחה אחרים לשרת.
  • שרתים חדשים לא מקבלים בדיקות אבטחה מספיקות. מה לעשות, יצרניות לא פעם מתקמצנות להשאיל/לשכור חברות אבטחה חיצוניות ש"יקרעו" את השרת מבחינת התקפות ונסיונות התקפה על הכניסות/יציאות ועל תוכנות פנימיות שרצות על שבבים פנימיים. התוצאה – עובר זמן עד שמתגלים חורי אבטחה, עוד זמן עד שמתוקן החור אבטחה, והרבה יותר זמן עד שהלקוח מתקין זאת.

כדי לראות את הבעיה בזמן אמת, אתם מוזמנים לבצע את התרגיל הבא מול חוות השרתים שלכם: בחרו לכם מספר שרתים מיצרנים שונים, בדקו גירסאות BIOS/UEFI והשוו את מספר הגירסה למספר הגירסה שמופיעה באתר היצרן. מהיכרות שלי: בסביבות ה-50-70% מהמקרים, השרת אינו מעודכן לקושחות ול-UEFI/BIOS האחרונים (הסיבה שאני שומע הכי הרבה: "זה רץ, אז למה לנסות להתקין דברים חדשים?". התשובה שלי: אבטחה).

ישנם לעיתים חורי אבטחה ממש גדולים. קחו לדוגמא את ה-Management Engine של אינטל שנמצא בכל שרת ובכל תחנת עבודה (שכוללים את הדרייברים של אינטל). משנת 2010 ישנו חור אבטחה רציני שתוקף יכול להגיע אל ה-Management Engine (שנמצא כחומרה בתוך המכונה), להשתלט עליו ולעקוב אחרי מה שקורה במכונה במקרה הקל או להזיק לדברים שרצים במכונה במקרה היותר גרוע. שום פירמוט או החלפת דיסקים לא יעזרו. תצטרכו להשתלט על ה-Management Engine מחדש על מנת לפתור את הבעיה. לאינטל לקח 7 שנים עד שבחודש מאי הם שחררו עדכון. החור קיים ב- Intel's Active Management Technology (AMT), Standard Manageability (ISM) ,Small Business Technology (SBT) מגירסאות 6 עד 11.6. האם עדכנתם אצלכם את השרתים לחסום את הפירצה הזו? (אפשר לקרוא עוד על כך כאן)

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

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

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

כמה מילים לגבי שדרוג ל-RHEL-7/CENTOS-7

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

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

לטובת אנשי לינוקס שלא היו בתחום מעבר לעשור האחרון, הנה תקציר פשוט לגבי רד-האט: רד האט אוהבים להכניס להפצות שלה דברים חדשים מאוד, לעיתים גם כשמה שהם מכניסים לא יציב פלדה אלא יציב מספיק. רד-האט לא כל כך משקיעים בשמירת תאימות מלאה לאחרות בגרסאות MAJOR (לדוגמא: 5 ל-6, 6 ל-7) והכי חשוב: רד האט לא פוחדים משינויים.

ניקח לדוגמא את מערכת SystemD, זו מערכת חדשה שמחליפה את SysV הישנה שהיתה עד כה בהפצות לינוקס. ב-RHEL-7 אין יותר SysV ואי אפשר במחי פקודת yum להעיף את systemd, היא משובצת לאורך ולרוחב ההפצעה, מה-Boot ועד ה-Login ונוגעת בכל החלקים, כולל שרותים (Services), לוגים וכו'. כל פורום לינוקס רציני שתבקרו בו, תמצאו ויכוחים ופיצוצים בעד ונגד SystemD, ואפשר למצוא בכל מיני מקומות "בעד" ו"נגד" כאשר אנשי יוניקס ותיקים רוקעים ברגליים ורוצים את Sys V init בחזרה ולעומתם רבים אחרים מסבירים את יתרונות ה-SystemD (כאן לדוגמא). הסיבה העיקרית שרד האט (ולאחרונה גם הפצות אחרות כמו אובונטו הבא) עוברים ל-SystemD זה התמודדות עם הצרכים של היום שלא היו בעבר. כיום יש מספיק מקרים שבהם אתה מכניס ציוד בצורה "חמה" (כלומר ללא כיבוי והפעלה) ובמקרים של שרתים יקרים מאוד גם ציוד שבעבר לא היה ניתן להכניס בצורה חמה כמו מעבדים, זכרונות, והתקנים נוספים (גם כרטיסי PCI-E), ומערכות Sys V init שהיו צריכות סקריפטים מסובכים ו-1001 ספריות ו-daemons שונים כדי להתמודד עם זה – הכל הוחלף ב-SystemD. יש לו Journal (מערכת לוגים משולבת) שנותנת לך לראות בפקודה אחת פשוטה סטטוס יותר מפורט של שרות, אם הוא לא עלה, מדוע הוא לא עלה – מבלי שתשב ותכתוב תוך כמה דקות/שעות (תלוי בכשרון שלך) משהו שינפה את הפלט של dmesg או var/log/messages/ או קבצי לוג אחרים.

ב-RHEL-7 (וכמובן CentOS-7), בשונה מגרסאות לינוקס ל-Enterprise הכל השתנה, החל מה-Kernel שהוא גירסה 3 (בעבר 2.6), המשך ב-Boot (כיום GRUB-2 a שהוא הרבה הרבה יותר מורכב מה-GRUB הראשון), דרך שפות פיתוח, ממשק גרפי, טיפול בציודים, הגדרות רשת, דיסקים, File System וכו', מה שאומר שאם תיקח שרת שרץ עליו RHEL-6 ותעביר אותו לגירסה 7, יש סיכוי רב שחלק מהדברים לא יעבוד או שהמכונה אפילו לא תעלה (כבר יצא לי לראות שרת שמישהו החליט שזה רעיון מעולה לשדרג אותו דרך YUM מ-CentOS 6.1 ל-7 ובסופו של דבר נשאר שרת יקר אבל שלא מצליח לעשות אפילו Boot).

RHEL-7 לפיכך אינו מתאים לשדרוג דרך YUM או דרך בחירת "שדרוג" כשעושים BOOT ל-ISO. במילים אחרות אל תסמכו על ה"שדרוג" הזה. הוא בהחלט ישדרג את קבצי ה-RPM, אבל יש מספיק דברים שהשתנו לגמרי בין 6.5 ל-7. סתם דוגמא: מריצים שרת Apache? מריצים מודולים שקימפלתם? תתפלאו – ב-RHEL-7 האפאצ'י הוא גירסה 2.4 ומודולים רבים לא מצליחים להתקמפל מולו, וחלק מהמודולים האחרים מתקמפלים אבל נופלים בעת העלאת שרות ה-Apache. כיף!

לפיכך, בהתאם למה שהצלחתי לאסוף מנסיוני ומנסיון חבריי, הנה מספר נקודות לגבי מעבר ל-RHEL-7:

  • תחנות Desktop/Workstations שמריצים תוכנות סגורות (שרטוט תלת מימד, קומפיילרים קנייניים, תוכנות IDE קנויות וכו') – לא לשדרג כרגע ל-7. תוכנות סגורות רבות עדיין אינן מתאימות לגירסה 7. אגב, שדרוג לגירסה 6.6 יצא בקרוב, אם בא לכם, אתם יכולים לשחק עם ה-Beta כאן.
  • תחנת שמריצות דברים בקוד פתוח – מומלץ להרים מכונות VM נסיוניות (לא שדרוג) עם האפליקציות ולתת למפתחים לשחק עם זה כמה ימים כדי לראות מה פעיל ומה שבור.
  • שרתים – גם כאן, אני ממליץ להרים מכונת VM ריקה עם RHEL-7 ולהתקין עליה את האפליקציות ולראות מה עובד ומה לא עובד. מצאתם שהכל עובד? אל תשדרגו עם הכלים של רד-האט, עדיף שתפרמטו ותתקינו מחדש, ועל כך תיכף ארחיב.
  • מכונות קומפילציות, Hadoop ושאר דברים יעודיים – נסו עם מספר מכונות VM להרים חווה קטנטנה כדי לראות שהכל עובד, כולל Stress Testing. קצת אחרי ששוחררה RHEL-7 היה באג רציני שתוקן באחד העדכונים.

כפי שציינתי לעיל, בשדרוגים יש סיכוי גבוה שמעבר מ-6.5 ל-7 (או גירסה מוקדמת יותר ל-7) דברים ישברו מבחינת סימנים (Symbols), תאימות בינארית (צורך בהתקנת compat למיניהם) ולכן אני ממליץ להקים את המכונה מחדש. לשמור את כל ה-DATA בנפרד ולהתחיל התקנה מחדש (ובהזדמנות להתחיל לחשוב על שימוש יותר מאסיבי עם Kickstart למי ש…אהממ… עדיין עובד עם ה-ISO). ישנם מערכות File Systems חדשות ויותר יציבות שיודעות לטפל בכמות הרבה יותר גדולה של קבצים – כמו XFS של סיליקון גרפיקס (בברירת מחדל אם לא תגדיר ידנית, RHEL תפרמט את הדיסק שלך ב-XFS). ה-LVM עבר שיפור (בבקשה, בבקשה, חדל מההתקנה של כל מערכת ההפעלה יחד עם הקבצים של המשתמש וה-SWAP הכל תחת Partition יחיד!), אם אתם משתמשים בחברה ב-Active Directory אז תוכלו ישירות מההתקנה להגדיר חיבור לדומיין ואת המשתמשים, וישנם שיפורים רבים נוספים, ובכלל, מומלץ לקרוא לעומק את ה-Installation Guide.

אם אתם הולכים להתקין את ההפצה על וירטואליזציה כמו HyperV או ESXI, אז אני שמח להודיעכם שאין צורך להתקין שום תוספים (ולא, גם לא VMWare Tools). הכל מגיע עם ההפצה בהתקנה רגילה, כך שאינכם צריכים להתקין כלום. למשתמשי HyperV – הבאג המעצבן של NFS עם NetApp על CentOS (המתנה של כמה עשרות שניות בין פקודה לפקודה) – תוקן ע"י רד-האט בתוך ההפצה. משתמשי ESXI – אתם תראו שה-TOOLS מופיעים כ-3rd Party, זה בסדר, הכלי שמותקן בפנים ושמפעיל vmtoolsd נעשה בשיתוף המהנדסים של VMWare.

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

לסיכום: כן, דברים השתנו לחלוטין בגירסה 7, אבל מה לעשות, דברים משתנים וטכנולוגיות והגדרות משתנות. אי אפשר להישאר כל הזמן בעבר. הטכנולוגיה היום דורשת פתרונות יותר דינמיים, הצרכים משתנים והפתרונות גם. נכון, לסקריפטולוגים מביניכם שקיצרו את העבודה היום יומית שלהם לפקודות של 3-4 אותיות תהיה קצת עבודה לשנות את הסקריפטים (לחובבי פייתון – הגירסת ברירת מחדל עכשיו היא 2.7 עדיין, אבל זו הגירסה האחרונה שתתן אותו כברירת מחדל. הגירסה הבאה תקפוץ ישר ל-3.4 או מה שיהיה אז), אבל מבחינת SystemD עדיין סקריפטים שמשתמשים ב-chkconfig, service וכו' יוכלו לרוץ, תסתכלו במסמך הזה אך יחד עם זאת, תתחילו להכין את הסקריפטים שלכם ל-SystemD. לא לשכוח גם להוסיף את ה-REPO הזה.

בהצלחה

טיפ בנושא: שדרוג מכונות RHEL

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

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

לרד-האט יש פתרו שנקרא Red Hat Satellite המאפשר לא רק עדכונים אלא life-cycle שלם למכונות ושרתים שכולל שרותים כמו דיווחי באגים, תמיכה, קבלת תיקונים, בדיקות, יצירת ISO לצרכים שונים וכו'. הכלי הוא כלי גדול וגם עולה בהתאם (כמה אלפי דולרים מחיר התחלתי). אנחנו לעומת זאת צריכים רק את העדכונים, לאחסן אותם על שרת שלנו ואנחנו כבר נפיץ אותם בזמן שנקבע.

על מנת לבצע זאת, נצטרך קודם כל לברר אלו גרסאות RHEL אנחנו משתמשים בחברה. 5? 6? עבור כל אחת מהגרסאות העיקריות נצטרך VM עם המון דיסק פנוי (במינימום 40-50 ג'יגה) וכמובן רשיונות, רשיון פר גירסה Major כך שאם אנחנו משתמשים בחברה ב-RHEL-6 וגם RHEL-5 ולשתיהם אנחנו צריכים עדכונים, אנחנו צריכים 2 רשיונות (כמובן שצריך רשיונות לכל תחנת/שרת RHEL כדי לקבל תמיכה וכו') על מנת לבצע את הקמת ה-REPO החדש שלנו.

ראשית, יש להקים VM עם גירסת RHEL הרצויה. ההתקנה מספיק שתהיה בסיסית עם גישת רשת החוצה ב-HTTP. ויש לבצע register של אותה מכונה ל-RHN. לאחר ההתקנה יש ליצור תיקיה שאליה נאחסן את הקבצים. נקרא לה var/repo/

כעת יש לוודא שחבילת yum-utils וחבילת createrepo מותקנות. אם לא, אפשר להתקין אותם ישירות מה-ISO או בעזרת yum.

כעת נוודא שהשרת רשום לערוץ שממנו אנו רוצים לשאוב עדכונים. לשם כך אפשר להשתמש בפקודה:

rhn-channel -l

אם הכל תקין, נקבל תשובה: rhel-x86_64-server-6 (במקרה שההתקנה היא 64 ביט גירסה 6).

כעת נתחיל לשאוב את העדכונים:

cd /var/repo
reposync -l --repoid=rhel-x86_64-server-6

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

הסתיים? מצוין, עכשיו ניצור ממה שירד repository עם הפקודה הבאה:

createrepo -v --update rhel-x86_64-server-6/getPackage/

זהו. יש לנו repo עם כל ה-RPMS שיש ב-RHEL-6 כולל דברים ישנים וחדשים.

על מנת לאפשר גישה לקבצים שהורדנו, נקים שרות httpd. התקינו את חבילת httpd ובתוך etc/httpd/conf.d/ נקים קובץ בשם repo.conf שיאפשר גישה לקבצים. הנה דוגמא לקובץ:

<VirtualHost *:80>
ServerName rhelrepo
DocumentRoot /var/repo/rhel-x86_64-server-6
ErrorLog logs/repo-error_log
CustomLog logs/repo-access_log common
<Directory "/var/repo/rhel-x86_64-server-6/">
Options Indexes FollowSymLinks
</Directory>
</VirtualHost>

שימו לב לשנות את שם ה-ServerName לשם השרת שלכם.

כעת נפעיל את שרות ה-httpd (עם הפקודה: service httpd restart) ועם הדפדפן ניגש לכתובת: http://rhelrepo/getPackage (שוב, שנו את השם rhelrepo לשם השרת שלכם). אם הכל תקין, תקבלו רשימה ארוכה של קבצי ה-RPM.

עכשיו מגיע החלק שתפיצו בעזרת כל כלי שתרצו – אל כל השרתים שלכם, קובץ repo שב בתיקיה etc/yum.repos.d/ שם ניצור קובץ שנקרא לו rhel6.repo

[RHEL-6-UPDATES]
name=RHEL-6.x Updates
baseurl=http://rhelrepo/getPackage/
enabled=1
gpgcheck=0

מומלץ למחוק את שאר הקבצים שנמצאים באותה תיקיה (ושמורידים את אותם עדכונים מרחוק).

כעת הגיע המבחן הגדול: הריצו yum update ותראו אם המערכת מוצאת עדכונים ומורידה אותם. אם כן, אז ברכותיי – הרמתם לכם שרת REPO מקומי משלכם.

מה שנשאר לעשות הוא להשתמש בפקודות ה-reposync וה-createrepo בתוך סקריפט שירוץ אחת ליום דרך ה-crontab ויעדכן את החבילות ישירות מרד-האט. את זמן ההפצה לכל השרתים והתחנות אתם קובעים לפי הנהלים באותה חברה.

אם אתם צריכים עדכונים ל-RHEL-5, ההבדל היחיד הוא בשם הערוץ, אותו תוכלו לקבל עם פקודת rhn-channel -l

בהצלחה