על vSphere ועל החלפת שרתים

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

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

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

אבל אחד הדברים שעדיין מתרחשים בארץ זה חוסר עדכון גרסאות. לא מעט מהחברות עדיין משתמשות בגירסאות 5.5 (הן מבחינת ESXI והן מבחינת vCenter) למרות שנשארו שבועיים בלבד לחיי התוכנה. ב-19 לחודש זה, המוצר "ימות" רשמית ולא יצאו לו כל עדכונים, גם לא עדכוני אבטחה קלים או קריטיים, ולכן חשוב לשדרג גירסה כמה שיותר מהר.

כאן מתקיים איזה משהו מוזר: חברות רבות שכן משתמשות בגירסה 6, אינן משדרגות לגירסה האחרונה (6.7) למרות שאין עלות נוספת מבחינת רשיון (אם כי יש צורך לשנות מספר סידורי – המספר הסריאלי שונה בין 6, 6.5 ו-6.7 ומספר של 6.0 לדוגמא לא יאפשר הפעלה של Schedule DRS על גירסה 6.5 ומעלה). כיום גירסה 6.7 היא גירסה בהחלט יציבה עם פונקציות רבות ותמיכה מתקדמת בדברים כמו NVME 1.3 (המאפשרת לקבל הרבה יותר מידע והתראות על SSD NVME) ודברים רבים נוספים.

וכאן מגיע עניין שדרוג שרתים.

בגירסה 6.7 של ESXI החליטו ב-VMWare להתחיל לנופף את גרזן התאימות אחורה. יש לך שרתים של HP מדור 6 לדוגמא או שרתים אחרים עם Xeon 55XX, Xeon 56xx, ויש עוד רשימה ארוכה של מעבדים שבהם גירסה 6.7 לא תעבוד. מדוע? אין לי גישה לקוד או ל-VMware עצמם, אך אני יכול לנחש שבשביל לתמוך בפונקציונאליות של ה-VT, כתבו ב-VMware הרבה קוד "בעייתי" שהם מתים להעיף, גם במחיר הסרת תאימות למעבדים מסויימים.

מטבע הדברים, מי שקורא את הרשימה ויש לו מעבדים ישנים המוזכרים ברשימה, יעדיף להתקין גירסה יותר ישנה של ESXi כמו 6.0 או 6.5. שם עדיין כמובן נשמרת התאימות.

אך זו, לעניות דעתי, החלטה אינה טובה, מכיוון שגירסה 6.0 נתמכת רק עוד שנה וחצי, ויש עוד נושא אחד חשוב…

PPW – או Performance Per Watt.

בעקרון, מעבדי Xeon נחלקים לדגמים מסויימים בכל גירסה: גירסת L הינה גירסה שצורכת הרבה פחות חשמל (אבל יש לה ביצועים נמוכים), ויש את גירסה E והיא הכי פופולרית (זה מה שבד"כ יצרן השרתים ימכור לך). למעבדים הישנים היתה גם גירסת X ששם מהירות המעבד היתה גבוהה, אבל צריכת החשמל היתה גבוהה בהתאם, פר מעבד.

אם נשווה מעבד Xeon ישן מסידרה 55XX (בלי ה-V) או 56XX בדגמים L או E, למעבדי Xeon E5 V4 לדוגמא (או למשפחה החדשה של ברונזה, כסף, זהב, פלטינום במעבדי Xeon-SP) נראה שצריכת החשמל היא כמעט אותה צריכה, רק שרמת הביצועים שונה לחלוטין. מעבד V4 או SP יתן ביצועים שנעים בין פי 3 ל-פי 10 (תלוי בפלטפורמה, תוכנה וכו') בהשוואה למעבדים הישנים. פלטפורמות כמו vSphere גם יודעות לנצל את הפונקציונאליות החדשה במעבדים כדי לתת HA יותר טוב ודברים נוספים (PCI Pass-through משופר, תמיכה יותר טובה ב-SR-IOV ועוד).

יוצא מכך, שאם תשקיעו חד פעמית בהחלפת השרתים, תוכלו לקבל הרבה יותר (יותר מכונות VM פר ברזל, תמיכה של יותר זכרון, תמיכה בציודים מודרניים ועוד) , וצריכת החשמל שלכם תישאר פחות או יותר אותו דבר (סביר להניח שזה יהיה פחות, המעבדים כיום יותר חכמים ומתחשבים יותר בצריכת חשמל, במיוחד מעבדי EPYC של AMD בוירטואליזציה). נכון, תצטרכו להקים Clusters חדשים (אחרת אין HA), אבל זהו דבר שקל לעשות והעברת מכונות VM בין השרתים הישנים לחדשים מצריכה בסך הכל חיבור ל-Datastore השונים, כיבוי המכונה הוירטואלית והפעלתה מחדש ב-Cluster החדש (יכול להיות שתצטרכו לשנות אולי גם את ה-Network אם חיברתם ל-VLAN אחר).

אישית אני יכול לאמר שאני מפעיל LAB ואני זה שמשלם את החשמל על ה-LAB ומצאתי שהחזקת שרתים ישנים והרצת מכונות VM עליהם פשוט אינה כדאית, במיוחד אם אני משווה את הביצועים וצריכת החשמל למעבדים מודרניים. בשבילי עדיף לי לקנות 2 מכונות עם מעבדי EPYC במקום הפעלה של 4 שרתים ישנים עם מעבדי Xeon 56XX. כך אוכל גם להשתמש ב-NVME, גם אוכל להכניס כרטיסי PCIe 3.0, וכך אוכל להנות מ-יותר ליבות פר מעבד וכל זאת מבלי להפריש עוד כספים לחברת החשמל. אני חושב שהגיון כזה יכול לפעול גם אצל חברות.

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

קונסולידציה – השלב השני שלא מבצעים

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

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

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

ניקח דוגמא: לפנינו 4 ארונות 42U, הם עמוסים ב-40 שרתי 1U בכל ארון (כן, אני משער שבמציאות כמות השרתים פר ארון היא מופחתת הואיל וחלק מהשרתים הם 2U, בחלקם יושבים מדפים של סטורג', סוויצ'ים וכו'). אני מאמין שבכל שרת יש 2 מעבדים שכל אחד מהם הוא 4 או 6 ליבות.

אם ניקח את הדוגמא לעיל, נוכל ללמוד מספר דברים כבר בהתחלה:

  • כמות החשמל שמנוצלת פר ארון היא בערך 12 קילוואט שעה.
  • סביר להניח שפרוסים 40 רשיונות VMWARE Enterprise PLUS רק בארון הזה.

אז איך ניתן לפתור את בעיות הרשיונות או קיצוץ תקציב ה-Datacenter?

התשובה ל-2 בעיות אלו קשורה לפתרון קונסולידציה. קחו לדוגמא ארון עם 40 שרתים – את אותו ארון ניתן להעיף ממנו 34-36 שרתים החוצה וזאת מבלי שצריך לוותר על מכונות VM אחת! נכפיל ב-4 ארונות ונקבל שאנחנו יכולים להגיע למצב שבארון אחד נאחסן 24 שרתים ונקבל את אותם ביצועים וממצב של שימוש של כמעט 50 קוט"ש, נוכל לצמצם זאת ל-5 קוט"ש לערך, חסכון של 90% בחשמל!

גם מבחינת רשיונות VMWare נוכל לקצץ מ-160 רשיונות ל.. 24 רשיונות, יותר מ-75% חסכון מבלי לוותר על שום פונקציונאליות!.

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

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

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

נקודות חשובות בשדרוג ל-CentOS 7.4

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

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

כמו תמיד, בגרסאות עדכון Minor ישנם שינויים רבים בהפצה, אך שינויים אלו עדיין שומרים על תאימות בינארית, תאימות קבצי הגדרות וכו'. יחד עם זאת, בחלק מהמקרים מעדיפים ברד-האט (ונגזר מזה גם ב-CentOS) לשדרג חבילות מסויימות לגרסאות Major מתקדמות יותר ובלבד שתשאר התאימות. הסיבה לכך היא שהפצת לינוקס (בניגוד לגירסת Windows) כוללת אלפי חבילות (וזאת לפני הפעלת מאגר תוכנות מומלץ כמו EPEL) ואין לרד-האט את המשאבים לעקוב אחרי כל החבילות וליישם Backporting של עדכוני אבטחה. ברד-האט בודקים אם ישנן פריצות ידועות ואם הפריצות נחסמו בגירסה יציבה מתקדמת יותר, גירסת העדכון הבאה תכלול את הגירסה המתקדמת יותר (מה שנקרא בשפה המקצועית "Rebase").

ב-רד-האט שחררו מסמך ארוך לגבי השינויים ברד-האט 7.4 (וכמובן כל הדברים נמצאים ב-CentOS 7.4) שנמצא כאן ומאוד מומלץ לקריאה לפני שדרוג שרתים. ישנם שינויים כמעט בכל תחום, Kernel עם עדכוני מודולים, תמיכה בדרייברים חדשים, חבילות בגירסאות חדשות (ה-Rebase שהזכרתי לעיל). בלינק לעיל תוכלו למצוא את ה-General Updates שמדבר בכלליות על השינויים ומתחתיו פירוט לגבי השינויים.

ברוב המקרים, הרצת yum update תשדרג מערכת מכל גירסה קודמת (7.0, 7.1 וכו') לגירסה האחרונה בלי הרבה בעיות, אולם ישנם מקרים בהם השדרוג יכשל או יותר חמור – המכונה/VM לא תצליח לעשות Boot או לא תצליח להפעיל תקשורת דרך כניסות התקשורת הרגילות/וירטואליות.

להלן כמה נקודות חשובות שכדאי לשים אליהן לב לפני שמשדרגים לגירסה 7.4:

  • אם אתם משתמשים ב-iptables וב-ip6tables (הראשון מיועד ל-IPV4 והשני ל-IPV6, הן מותקנות כברירת מחדל בהתקנה רגילה). אם אתם מפעילים את שתיהם, יכולות להיווצר בעיות של תקשורת. הבאג מתוקן ב-CentOS 7.4 בחבילה iptables-1.4.21-18.0.1.el7 אך הוא עדיין לא מתוקן ברד-האט 7.4. הפתרון המומלץ כרגע – להפעיל רק אחד מהם ולבטל את השני (בעזרת פקודת systemctl disable).
  • אם אתם משתמשים ב-Xen, מכונת VM של CentOS 7.4 עם דרייברים Paravirtualized – ה-VM לא יצליח לבצע BOOT וכרגע הפתרון הוא HVM (או PV-on-HVM). תיקון לכך יצא בקרוב.
  • במקרים מסויימים הרצת yum update תתקין חבילות i686 ולא X86-64. הבעיה מתרחשת עקב התקנת RDMA. אם אתם משתמשים ב-RDMA, מומלץ להריץ yum install rdma-core && yum update. אם אתם עדיין רואים בעיה, מומלץ להריץ yum install rdma-core ibacm. 
  • אם אתם רוצים להתקין VirtualBox על תחנת עבודה שתריץ כ-host את CentOS 7.4, תצטרכו להתקין את גירסת VirtualBox 5.1.28 מהאתר. גירסה 5.1.26 לא תעבוד.
  • משתמשים ב-VMware ורוצים להקים VM מבוסס CentOS 7.4? עקב שינויים שרד-האט ביצעו בקרנל, התקשורת הוירטואלית לא תעבוד. יש צורך בהתקנת Patch ל-VMware tools. לפרטים – כנסו ובצעו את ההוראות בקישור הזה.
  • חבילת ה-initramFS הרבה יותר גדולה מבעבר, ולכן אם מחיצת ה-boot/ שלכם קטנה מ-1 ג'יגהבייט, תצטרכו להרחיב אותה לפני השדרוג ל-7.4 לפחות לגודל 1 ג'יגהבייט (אני ממליץ להרחיב לגודל 5 ג'יגהבייט אם הנכם מתקינים מספר גרסאות קרנל).
  • יכול להיות ששרות SAMBA יפול עם השגיאה symbol krb5_get_init_creds_opt_set_pac_request, not defined. במקרים כאלו יש להתקין את חבילת  krb5-libs-1.15.1-8.el7 ולהפעיל את שרות SAMBA מחדש.
  • ועוד בעניין SAMBA – אם אתם עובדים עם אותנטיקציית SSSD ומאפשרים SHARE, זה לא יעבוד. כרגע האפשרות היחידה היא לשנמך לגירסה שקיימת בסנטוס 7.3. כרגע רד-האט עובדים על הבאג הזה.
  • נדיר, אבל ראיתי מקרים שזה קורה: אתם מפעילים את ה-CentOS ואין תקשורת עד שאתם מבצעים Login או שהתקשורת לא מופעלת בזמן Boot. במקרים כאלו, עקבו אחר ההוראות כאן.
  • החל מגירסה 7.4, מינימום זכרון שנדרש עבור המערכת הוא 1 ג'יגהבייט. במקרים שאתם רוצים להריץ את ה-ISO כ-LIVE, יש צורך בלפחות 1.5 ג'יגהבייט זכרון.
  • עוד בענייני VMWare: אם אתם מגדירים ידנית VM לשימוש עם CentOS 7.4, אל תנסו לבחור דרייברים SCSI אלא אך ורק את ה-Paravirtualized. דרייברים ל-SCSI ש-VMWare השתמשו כבר לא קיימים בקרנל הזה.
  • אוהבים את פקודת ifconfig ו-netstat? תתכוננו לשכוח מהם. הם מסומנים כ-Deprecated והם אינם מותקנים כברירת מחדל עם CentOS 7.4, ולכן אם הרשת שלך לא עלתה, השתמשו בפקודת nmcli כדי להפעיל את כרטיס הרשת ואז תוכלו להתקין את החבילה (ותתכוננו לשנות סקריפטים שמשתמשים בפקודות הנ"ל).
  • בסנטוס 7.4 מותקנת גירסה חדשה של sudo שמשתמשת ב-var/db/sudo/lectured/ ולפיכך ההתראה הראשונה שמשתמשים ב-sudo (עם האזהרות וכו') תופיע מחדש לכל המשתמשים ב-sudo לאחר שדרוג לסנטוס 7.4.
  • אם אתם משתמשים ב-CentOS 7.4 עם GNOME, יכול להיות שמנהל הקבצים (Nautilus) יראה את האייקונים מאוד גדולים. הפתרון הוא להריץ את הפקודה: gsettings set org.gnome.nautilus.icon-view default-zoom-level 'small' ולבצע lougout ולאחר מכן login.
  • אם אתם משתמשים ב-CentOS 7.3 (או גרסאות 7 קודמות) ואתם מריצים על זה OpenLDAP ואתם מתכוונים לשדרג, יש לבצע את ההוראות בלינקים כאן וכאן או שתהיה לכם בעיה רצינית עם ה-OpenLDAP. בכל מקרה אם מדובר ב-VM, בצעו snapshot לפני כן.

בכל מקרה, תמיד מומלץ להסתכל בדף ה-Errata של רד-האט ולוודא שאין עדכונים שלא התקנתם או שלא שמתם לב אליהם.

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

טיפ: להפוך מערכת CentOS ל-RHEL

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

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

לשם ההפיכה, נצטרך קודם כל את ה-ISO פרוס לקבצים בתיקיה כלשהי (אפשר כמובן על NFS, רק כדאי שתבצעו קודם כל mount במכונה שאנחנו הולכים לשנות). לאחר שביצענו mount נעבור למצב root (זה המצב שבו נישאר כרגע) עם sudo או – su.

עתה יש להריץ את הפקודה הבאה:

rpm -e --nodeps centos-release

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

עתה, נרים לנו REPO משלנו עם הנקודה שאליה ביצענו mount. כנסו לתיקיית etc/yum.repos.d/ ושם ניצור קובץ dvd.repo – הנה דוגמא משלי:

[DVD]
name=DVD REPO
baseurl=///mnt/Server/
enabled=1
gpgcheck=0

במקרה הנ"ל, ה-mount שביצעתי היה לתוך תיקיית mnt/ כמו כן יש לשים לב שכמות הקו נטוי (/) היא בתוספת / כך שאם מדובר במערכת קבצים מקומית (ולא http) יש צורך שיהיו 3 קווים נטויים.

כעת יש להעיף את קבצי ה-repo האחרים של CentOS (הם מתחילים במילה CentOS)

עכשיו ננסה להשתמש ב-repo החדש שהוספנו. הריצו את הפקודה הבאה:

yum install redhat-release

סביר להניח שההתקנה תבקש לעדכן את initscripts. אשרו את ההתקנה.

כעת יש צורך להריץ yum update על מנת לעדכן חבילות שונות. הכל יבוצע אוטומטית.

אם אתם מעוניינים לרשום את המכונה בשרתים של רד-האט, יש להריץ את הפקודה הבאה:

yum install rhnlib rhnsd rhn-client-tools rhn-check yum-rhn-plugin rhn-setup

שימו לב לא להכניס מספרי גרסאות, המערכת תתקין את הגרסאות האחרונות מהיכן שהיא מוצאת ב-REPO.

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

זהו, כעת כל מה שנותר לבצע הוא reboot וכעת יש לכם שרת RHEL כאילו התקנתם אותו מאפס מה-ISO. תוכלו לבדוק זאת ע"י הקשת פקודת: lsb_release -d