היכרות עם חלק הרשת בתשתית הענן

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

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

מהו ענן? אותה וירטואליזציה - תצוגת פרופיל?

יותר משאלה הגיונית. לא - זו לא וירטואליזציה, למרות שאי אפשר לעשות את זה בלעדיה. בואו נסתכל על שתי הגדרות:

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

וירטואליזציה - זוהי היכולת לחלק ישות פיזית אחת (לדוגמה, שרת) לכמה וירטואליות, ובכך להגדיל את ניצול המשאבים (לדוגמה, היו לך 3 שרתים נטענים ב-25-30 אחוז, לאחר הוירטואליזציה אתה מקבל שרת 1 טעון ב-80-90 אחוז). באופן טבעי, הווירטואליזציה גוזלת חלק מהמשאבים - אתה צריך להאכיל את ה-Hypervisor, עם זאת, כפי שהראה בפועל, המשחק שווה את הנר. דוגמה אידיאלית לווירטואליזציה היא VMWare שמכינה בצורה מושלמת מכונות וירטואליות, או למשל KVM שאני מעדיף, אבל זה עניין של טעם.

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

וירטואליזציה היא אחת מאבני הבניין שעליהן בנוי הענן.

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

אבל אני מבין שמההגדרה שהוצגה לעיל לא לגמרי ברור מה בעצם אפשר לקרוא לענן.

לכן, מסמך מ-NIST (המכון הלאומי לתקנים וטכנולוגיה) מספק 5 מאפיינים עיקריים שיש לתשתית ענן:

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

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

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

התאמה מהירה לתנאים שונים. השירותים חייבים להיות גמישים – אספקה ​​מהירה של משאבים, חלוקה מחדש שלהם, הוספה או צמצום משאבים לפי בקשת הלקוח, ומצד הלקוח צריכה להיות תחושה שמשאבי הענן הם אינסופיים. למען נוחות ההבנה, למשל, אינך רואה אזהרה שחלק משטח הדיסק שלך ב-Apple iCloud נעלם מכיוון שהכונן הקשיח בשרת התקלקל, והכוננים אכן מתקלקלים. בנוסף, מצדכם, האפשרויות של השירות הזה הן כמעט בלתי מוגבלות – צריך 2 TB – אין בעיה, שילמתם וקיבלתם. דוגמה דומה ניתן לתת עם Google.Drive או Yandex.Disk.

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

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

למה אנחנו צריכים ענן?

עם זאת, כל טכנולוגיה חדשה או קיימת, כל פרוטוקול חדש נוצר עבור משהו (טוב, מלבד RIP-ng, כמובן). אף אחד לא צריך פרוטוקול למען פרוטוקול (טוב, מלבד RIP-ng, כמובן). זה הגיוני שהענן נוצר כדי לספק שירות כלשהו למשתמש/לקוח. כולנו מכירים לפחות כמה שירותי ענן, למשל Dropbox או Google.Docs, ואני מאמין שרוב האנשים משתמשים בהם בהצלחה - לדוגמה, מאמר זה נכתב באמצעות שירות הענן Google.Docs. אבל שירותי הענן שאנו מכירים הם רק חלק מהיכולות של הענן - ליתר דיוק, הם רק שירות מסוג SaaS. אנו יכולים לספק שירות ענן בשלוש דרכים: בצורה של SaaS, PaaS או IaaS. איזה שירות אתה צריך תלוי ברצונות וביכולות שלך.

בואו נסתכל על כל אחד לפי הסדר:

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

פלטפורמה כשירות (PaaS) - בעת שימוש במודל זה, ספק השירות מספק ללקוח חומר עבודה עבור השירות, למשל, ניקח שרת אינטרנט. ספק השירות סיפק ללקוח שרת וירטואלי (למעשה, מערך משאבים, כגון RAM/CPU/Storage/Nets וכו'), ואף התקין את מערכת ההפעלה והתוכנה הנחוצה על שרת זה, אולם התצורה של כל הדברים האלה נעשים על ידי הלקוח עצמו ולצורך ביצוע השירות שהלקוח עונה. ספק השירות, כמו במקרה הקודם, אחראי על ביצועי הציוד הפיזי, היפרוויזורים, המכונה הווירטואלית עצמה, זמינות הרשת שלה וכו', אך השירות עצמו אינו נמצא עוד בתחום אחריותו.

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

מה זה OpenStack?

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

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

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

בזמן כתיבת החומר הזה, מבנה OpenStack נראה כך:

תמונה נלקחה מ openstack.org

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

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

ניתן לראות רשימה מלאה של כל הפרויקטים ומטרתם כאן.

כל רכיב OpenStack הוא שירות שמבצע פונקציה ספציפית ומספק API לניהול פונקציה זו ואינטראקציה עם שירותי מערכות הפעלה ענן אחרים כדי ליצור תשתית מאוחדת. כך למשל, Nova מספקת ניהול משאבי מחשוב ו-API לגישה להגדרת משאבים אלו, Glance מספקת ניהול תמונות ו-API לניהולם, Cinder מספקת אחסון בלוק ו-API לניהולו וכו'. כל הפונקציות מחוברות זו לזו בצורה קרובה מאוד.

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

בואו נעבור על האלגוריתם ליצירת מכונה וירטואלית וחיבורה לרשת ולאחסון מתמשך ב-Openstack.

1. כאשר אתה יוצר בקשה ליצירת מכונה, בין אם זו בקשה דרך Horizon (Dashboard) או בקשה דרך ה-CLI, הדבר הראשון שקורה הוא אישור הבקשה שלך ב-Keystone - האם אתה יכול ליצור מכונה, האם יש לה את הזכות להשתמש ברשת הזו, האם את מכסת הטיוטה שלך וכו'.
2. Keystone מאמת את בקשתך ומייצר אסימון אימות בהודעת התגובה, שישמש בהמשך. לאחר קבלת תשובה מקיסטון, הבקשה נשלחת לכיוון נובה (nova api).
3. Nova-api בודק את תקפות הבקשה שלך על ידי יצירת קשר עם Keystone באמצעות אסימון האישור שנוצר קודם לכן
4. Keystone מבצעת אימות ומספקת מידע על הרשאות והגבלות על סמך אסימון אישור זה.
5. Nova-api יוצר ערך עבור ה-VM החדש ב-nova-database ומעביר את הבקשה ליצור את המחשב ל-nova-scheduler.
6. Nova-scheduler בוחר את המארח (צומת המחשב) עליו ייפרס ה-VM בהתבסס על הפרמטרים, המשקלים והאזורים שצוינו. רישום של זה ומזהה VM נכתבים ל-nova-database.
7. לאחר מכן, nova-scheduler יוצר קשר עם nova-compute עם בקשה לפרוס מופע. Nova-compute יוצר קשר עם nova-conductor כדי לקבל מידע על פרמטרי מכונה (nova-conductor הוא אלמנט nova שפועל כשרת פרוקסי בין nova-database ל-nova-compute, מגביל את מספר הבקשות ל-nova-database כדי למנוע בעיות עם מסד הנתונים הפחתת עומס עקביות).
8. Nova-conductor מקבל את המידע המבוקש מ-nova-database ומעביר אותו ל-nova-compute.
9. לאחר מכן, שיחות nova-compute מביטים כדי לקבל את מזהה התמונה. Glace מאמת את הבקשה בקיסטון ומחזירה את המידע המבוקש.
10. Nova-compute מתקשר לנייטרון כדי לקבל מידע על פרמטרי רשת. בדומה למבט, נויטרון מאמת את הבקשה ב-Keystone, ולאחר מכן הוא יוצר ערך במסד הנתונים (מזהה פורטים וכו'), יוצר בקשה ליצירת פורט ומחזיר את המידע המבוקש ל-nova-compute.
11. Nova-compute contacts cinder עם בקשה להקצות נפח למכונה הוירטואלית. בדומה למבט, סיידר מאמת את הבקשה ב-Keystone, יוצר בקשה ליצירת נפח ומחזיר את המידע המבוקש.
12. Nova-compute אנשי קשר עם libvirt עם בקשה לפרוס מכונה וירטואלית עם הפרמטרים שצוינו.

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

תמיד כדאי לזכור שאין תשתית ענן ללא רשת – כל אלמנט מקיים אינטראקציה כזו או אחרת עם אלמנטים אחרים דרך הרשת. בנוסף, לענן יש רשת לא סטטית לחלוטין. מטבע הדברים, רשת השכבה היא אפילו פחות או יותר סטטית - צמתים ומתגים חדשים לא מתווספים כל יום, אבל רכיב השכבה יכול וישתנה בהכרח - רשתות חדשות יתווספו או יימחקו, יופיעו מכונות וירטואליות חדשות וישנות לָמוּת. וכזכור מהגדרת הענן שניתנה ממש בתחילת המאמר, יש להקצות משאבים למשתמש באופן אוטומטי ובמינימום (או יותר טוב, ללא) התערבות מספק השירות. כלומר, סוג האספקה ​​של משאבי רשת שקיים כעת בצורה של חזית קצה בצורת החשבון האישי שלך הנגיש דרך http/https ומהנדס הרשת התורן וסילי כחלק אחורי אינו ענן, אפילו אם לוואסילי יש שמונה ידיים.

Neutron, כשירות רשת, מספקת API לניהול חלק הרשת של תשתית הענן. השירות מפעיל ומנהל את חלק הרשת של Openstack על ידי מתן שכבת הפשטה בשם Network-as-a-Service (NaaS). כלומר, הרשת היא אותה יחידה וירטואלית הניתנת למדידה כמו למשל ליבות מעבד וירטואליות או כמות ה-RAM.

אבל לפני שנעבור לארכיטקטורה של חלק הרשת ב-OpenStack, בואו נבחן איך הרשת הזו עובדת ב-OpenStack ומדוע הרשת היא חלק חשוב ובלתי נפרד מהענן.

אז יש לנו שני VMs RED ושני GREEN VMs. הבה נניח שהמכונות הללו ממוקמות על שני היפרוויזורים בצורה זו:

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

כדי ליצור ענן, עלינו להוסיף מספר רכיבים. ראשית, אנו עושים וירטואליזציה של חלק הרשת - עלינו לחבר את 4 המכונות הללו בזוגות, והלקוחות רוצים חיבור L2. ניתן להשתמש במתג ולהגדיר טראנק לכיוון שלו ולפתור הכל באמצעות גשר לינוקס או, למשתמשים מתקדמים יותר, openvswitch (נחזור לזה בהמשך). אבל יכולות להיות הרבה רשתות, ודחיפה מתמדת של L2 דרך מתג זה לא הרעיון הכי טוב - יש מחלקות שונות, דלפק שירות, חודשים של המתנה לסיום הבקשה, שבועות של פתרון בעיות - בעולם המודרני זה הגישה כבר לא עובדת. וככל שחברה מבינה זאת מוקדם יותר, כך קל לה להתקדם. לכן, בין ההיפרוויזורים נבחר רשת L3 שדרכה יתקשרו המכונות הווירטואליות שלנו, ועל גבי רשת L3 זו נבנה רשתות שכבת L2 וירטואליות שבהן תפעל התעבורה של המכונות הוירטואליות שלנו. אתה יכול להשתמש ב-GRE, Geneve או VxLAN כאנקפסולציה. הבה נתמקד באחרון לעת עתה, למרות שזה לא חשוב במיוחד.

אנחנו צריכים לאתר את VTEP איפשהו (אני מקווה שכולם מכירים את הטרמינולוגיה של VxLAN). מכיוון שיש לנו רשת L3 שמגיעה ישר מהשרתים, שום דבר לא מונע מאיתנו להציב VTEP על השרתים עצמם, ו-OVS (OpenvSwitch) הוא מצוין לעשות זאת. כתוצאה מכך, קיבלנו את העיצוב הזה:

מכיוון שיש לחלק את התעבורה בין מחשבי VM, ליציאות לעבר המכונות הוירטואליות יהיו מספרי vlan שונים. מספר התג משחק תפקיד רק בתוך מתג וירטואלי אחד, שכן כאשר הוא מובלע ב-VxLAN נוכל להסיר אותו בקלות, מכיוון שיהיה לנו VNI.

כעת נוכל ליצור עבורם את המכונות והרשתות הווירטואליות שלנו ללא בעיות.

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

זה נראה כאילו שום דבר לא מסובך - אנחנו יוצרים ממשק גשר על צומת הבקרה, מניעים אליו תנועה ומשם אנחנו מנתבים אותו לאן שאנחנו צריכים אותה. אבל הבעיה היא שהלקוח RED רוצה להשתמש ברשת 10.0.0.0/24, והלקוח GREEN רוצה להשתמש ברשת 10.0.0.0/24. כלומר, אנחנו מתחילים לחתוך מרחבי כתובת. בנוסף, לקוחות לא רוצים שלקוחות אחרים יוכלו לנתב לרשתות הפנימיות שלהם, וזה הגיוני. כדי להפריד בין הרשתות לתעבורת נתוני הלקוח, נקצה מרחב שמות נפרד לכל אחת מהן. מרחב השמות הוא למעשה עותק של מחסנית הרשת של לינוקס, כלומר, לקוחות במרחב השמות RED מבודדים לחלוטין מלקוחות ממרחב השמות GREEN (טוב, ניתוב בין רשתות לקוח אלו מותר דרך מרחב השמות המוגדר כברירת מחדל או בציוד תחבורה במעלה הזרם).

כלומר, נקבל את התרשים הבא:

מנהרות L2 מתכנסות מכל צמתי המחשוב לצומת הבקרה. צומת שבו ממוקם ממשק L3 עבור רשתות אלה, כל אחת במרחב שמות ייעודי לבידוד.

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

כתוצאה מכך, קיבלנו את התרשים הזה:

שאלה סבירה היא מדוע לא ליצור שערים בצמתי המחשוב עצמם? זו לא בעיה גדולה; יתר על כן, אם תפעיל את הנתב המבוזר (DVR), זה יעבוד. בתרחיש זה, אנו שוקלים את האפשרות הפשוטה ביותר עם שער מרכזי, המשמש כברירת מחדל ב-Openstack. עבור פונקציות עומס גבוה, הם ישתמשו גם בנתב מבוזר וגם בטכנולוגיות האצה כמו SR-IOV ו-Passthrough, אבל כמו שאומרים, זה סיפור אחר לגמרי. ראשית, נעסוק בחלק הבסיסי, ולאחר מכן ניכנס לפרטים.

למעשה, התוכנית שלנו כבר ניתנת לביצוע, אבל יש כמה ניואנסים:

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

נתחיל עם הגנת מכונה. בשביל זה אתה יכול להשתמש ב-iptables בנאלי, למה לא.

כלומר, עכשיו הטופולוגיה שלנו הפכה קצת יותר מסובכת:

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

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

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

והנה NAT בא לעזרתנו - אנחנו פשוט נאפשר ללקוחות לגשת לעולם החיצון דרך מרחב השמות המוגדר כברירת מחדל באמצעות תרגום NAT. ובכן, הנה בעיה קטנה. זה טוב אם שרת הלקוח פועל כלקוח ולא כשרת - כלומר הוא יוזם ולא מקבל חיבורים. אבל אצלנו זה יהיה הפוך. במקרה זה, עלינו לעשות NAT של יעד כך שבעת קבלת תעבורה, צומת הבקרה יבין שהתעבורה הזו מיועדת למכונה וירטואלית A של לקוח A, כלומר עלינו לבצע תרגום NAT מכתובת חיצונית, למשל 100.1.1.1 .10.0.0.1, לכתובת פנימית 100. במקרה זה, למרות שכל הלקוחות ישתמשו באותה רשת, הבידוד הפנימי נשמר לחלוטין. כלומר, אנחנו צריכים לעשות dNAT ו-sNAT על צומת הבקרה. האם להשתמש ברשת יחידה עם כתובות צפות או רשתות חיצוניות, או שתיהן בבת אחת, תלוי במה שאתה רוצה להכניס לענן. לא נוסיף לתרשים כתובות צפות, אלא נשאיר את הרשתות החיצוניות שנוספו כבר קודם - לכל לקוח יש רשת חיצונית משלו (בתרשים הם מצוינים כ-vlan 200 ו-XNUMX בממשק החיצוני).

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

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

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

הבעיה הבאה היא דיסקים של מכונות וירטואליות. כרגע הם מאוחסנים על ה-Hypervisors עצמם, ובמקרה של בעיות עם ה-Hypervisor, אנחנו מאבדים את כל הנתונים - והנוכחות של raid לא תעזור כאן אם נאבד לא את הדיסק, אלא את כל השרת. לשם כך, עלינו ליצור שירות שישמש כחזית לאחסון כלשהו. איזה סוג של אחסון זה יהיה לא חשוב לנו במיוחד, אבל זה אמור להגן על הנתונים שלנו מפני כשל של הדיסק וגם של הצומת, ואולי של הארון כולו. יש כאן כמה אפשרויות - יש כמובן רשתות SAN עם Fibre Channel, אבל בואו נהיה כנים - FC הוא כבר שריד לעבר - אנלוגי של E1 בתחבורה - כן, אני מסכים, הוא עדיין בשימוש, אבל רק איפה שאי אפשר בלעדיו לחלוטין. לכן, לא הייתי פורס מרצוני רשת FC בשנת 2020, בידיעה שיש עוד אלטרנטיבות מעניינות יותר. למרות שלכל אחד משלו, אולי יש מי שמאמין ש-FC עם כל המגבלות שלו זה כל מה שאנחנו צריכים - אני לא אתווכח, לכל אחד יש דעה משלו. עם זאת, הפתרון המעניין ביותר לדעתי הוא להשתמש ב-SDS, כמו Ceph.

Ceph מאפשרת לך לבנות פתרון אחסון נתונים זמין ביותר עם שלל אפשרויות גיבוי אפשריות, החל מקודים עם בדיקת זוגיות (אנלוגית ל-Raid 5 או 6) המסתיימים בשכפול מלא של נתונים לדיסקים שונים, תוך התחשבות במיקום הדיסקים ב- שרתים, ושרתים בארונות וכו'.

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

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

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

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

ארכיטקטורת ניוטרונים

ב-OpenStack, Neutron הוא זה שאחראי על חיבור יציאות מכונות וירטואליות לרשת L2 משותפת, הבטחת ניתוב תעבורה בין VMs הממוקמים ברשתות L2 שונות, כמו גם ניתוב החוצה, מתן שירותים כגון NAT, Floating IP, DHCP וכו'.

ברמה גבוהה ניתן לתאר את פעולת שירות הרשת (החלק הבסיסי) באופן הבא.

בעת הפעלת ה-VM, שירות הרשת:

1. יוצר יציאה עבור VM נתון (או יציאות) ומודיע על כך לשירות DHCP;
2. נוצר התקן רשת וירטואלי חדש (דרך libvirt);
3. ה-VM מתחבר ליציאה/ים שנוצרו בשלב 1;

באופן מוזר, העבודה של Neutron מבוססת על מנגנונים סטנדרטיים המוכרים לכל מי שאי פעם צלל ללינוקס - מרחבי שמות, iptables, Linux bridges, openvswitch, conntrack וכו'.

יש להבהיר מיד כי ניוטרון אינו בקר SDN.

ניוטרון מורכב ממספר רכיבים המחוברים ביניהם:

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

Neutron-server הוא למעשה יישום שנכתב ב-python, המורכב משני חלקים:

• שירות REST
• תוסף ניוטרון (ליבה/שירות)

שירות REST נועד לקבל קריאות API ממרכיבים אחרים (לדוגמה, בקשה לספק מידע מסוים וכו')

פלאגינים הם רכיבי תוכנה/מודולים תוספים שנקראים במהלך בקשות API – כלומר ייחוס שירות מתרחש דרכם. תוספים מתחלקים לשני סוגים - שירות ושורש. ככלל, תוסף הסוס אחראי בעיקר על ניהול מרחב הכתובות וחיבורי L2 בין VMs, ותוספי שירות כבר מספקים פונקציונליות נוספת כגון VPN או FW.

ניתן לראות למשל את רשימת התוספים הזמינים כיום כאן

יכולים להיות מספר תוספים של שירות, אבל יכול להיות רק תוסף סוס אחד.

openstack-neutron-ml2 הוא תוסף השורש הסטנדרטי של Openstack. לתוסף זה יש ארכיטקטורה מודולרית (בניגוד לקודמו) ומגדיר את שירות הרשת באמצעות דרייברים המחוברים אליו. נסתכל על התוסף עצמו מעט מאוחר יותר, שכן למעשה הוא נותן את הגמישות שיש ל-OpenStack בחלק הרשת. ניתן להחליף את תוסף השורש (לדוגמה, Contrail Networking עושה החלפה כזו).

שירות RPC (שרת rabbitmq) - שירות המספק ניהול תורים ואינטראקציה עם שירותי OpenStack אחרים, כמו גם אינטראקציה בין סוכני שירותי רשת.

סוכני רשת - סוכנים הממוקמים בכל צומת, דרכם מוגדרים שירותי רשת.

ישנם מספר סוגים של סוכנים.

הסוכן הראשי הוא סוכן L2. סוכנים אלו פועלים על כל אחד מה-hypervisors, כולל צמתי בקרה (ליתר דיוק, בכל הצמתים המספקים שירות כלשהו לדיירים) ותפקידם העיקרי הוא לחבר מכונות וירטואליות לרשת L2 משותפת, וכן ליצור התראות כאשר מתרחשים אירועים כלשהם ( למשל השבת/הפעל את היציאה).

הסוכן הבא, לא פחות חשוב הוא סוכן L3. כברירת מחדל, סוכן זה פועל אך ורק על צומת רשת (לעיתים קרובות צומת הרשת משולב עם צומת בקרה) ומספק ניתוב בין רשתות דיירים (הן בין הרשתות שלו והן לרשתות של דיירים אחרים, והוא נגיש לעולם החיצון, מספק NAT, כמו גם שירות DHCP). עם זאת, בעת שימוש ב-DVR (נתב מבוזר), הצורך בתוסף L3 מופיע גם בצמתי המחשוב.

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

מסד נתונים - מסד נתונים של מזהים של רשתות, רשתות משנה, יציאות, בריכות וכו'.

למעשה, ניוטרון מקבל בקשות API מיצירת ישויות רשת כלשהן, מאמת את הבקשה, ודרך RPC (אם הוא ניגש לתוסף או סוכן כלשהו) או REST API (אם הוא מתקשר ב-SDN) משדר לסוכנים (באמצעות תוספים) הנחיות הדרושות לארגון השירות המבוקש.

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

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

למעשה, זה כל המבנה של ניוטרון. עכשיו שווה להקדיש זמן לתוסף ML2.

שכבה מודולרית 2

כפי שהוזכר לעיל, התוסף הוא תוסף שורש OpenStack סטנדרטי ובעל ארכיטקטורה מודולרית.

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

ל-ML2 שני רכיבים - שני סוגי דרייברים: מנהלי התקנים מסוג ודרייברי מנגנון.

הקלד דרייברים לקבוע את הטכנולוגיות שישמשו לארגון חיבורי רשת, למשל VxLAN, VLAN, GRE. במקביל, הנהג מאפשר שימוש בטכנולוגיות שונות. הטכנולוגיה הסטנדרטית היא אנקפסולציה VxLAN עבור רשתות שכבת-על ורשתות vlan חיצוניות.

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

שטוח - רשת ללא תיוג
VLAN - רשת מתויגת
מקומי - סוג מיוחד של רשת עבור התקנות All-in-one (התקנות כאלה נחוצות למפתחים או להדרכה)
GRE - רשת כיסוי באמצעות מנהרות GRE
VxLAN - רשת שכבת-על באמצעות מנהרות VxLAN

נהגי מנגנון להגדיר כלים המבטיחים את ארגון הטכנולוגיות המצוינות במנהל ההתקן של הסוג - למשל, openvswitch, sr-iov, opendaylight, OVN וכו'.

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

דוגמה: אם אנו משתמשים ב-ML2 יחד עם OVS, אזי סוכן L2 מותקן בכל צומת מחשוב שמנהל את OVS. עם זאת, אם נשתמש, למשל, ב-OVN או ב-OpenDayLight, אז השליטה ב-OVS נמצאת בסמכות השיפוט שלהם - Neutron, דרך תוסף השורש, נותן פקודות לבקר, והוא כבר עושה את מה שנאמר לו.

בואו להתחדש ב-Open vSwitch

נכון לעכשיו, אחד המרכיבים המרכזיים של OpenStack הוא Open vSwitch.
בעת התקנת OpenStack ללא כל ספק נוסף SDN כגון Juniper Contrail או Nokia Nuage, OVS הוא מרכיב הרשת העיקרי של רשת הענן, ויחד עם iptables, conntrack, מרחבי שמות, מאפשר לך לארגן רשתות שכבות מרובות דירות מלאות. באופן טבעי, ניתן להחליף רכיב זה, למשל, בעת שימוש בפתרונות SDN קנייניים (ספק) של צד שלישי.

OVS הוא מתג תוכנה בקוד פתוח המיועד לשימוש בסביבות וירטואליות כמעביר תעבורה וירטואלי.

כרגע ל-OVS יש פונקציונליות ראויה מאוד, הכוללת טכנולוגיות כמו QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK וכו'.

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

ישנם שלושה מרכיבים חשובים של OVS שאתה צריך להיות מודע אליהם:

• מודול ליבה - רכיב הממוקם במרחב הקרנל המעבד תעבורה על סמך הכללים המתקבלים מאלמנט הבקרה;
• vSwitch daemon (ovs-vswitchd) הוא תהליך שהושק במרחב המשתמש שאחראי על תכנות מודול הליבה - כלומר, הוא מייצג ישירות את ההיגיון של פעולת המתג
• שרת מסד - נתונים - מסד נתונים מקומי הממוקם על כל מארח המריץ OVS, בו מאוחסנת התצורה. בקרי SDN יכולים לתקשר באמצעות מודול זה באמצעות פרוטוקול OVSDB.

כל זה מלווה בסט של כלי עזר לאבחון וניהול, כגון ovs-vsctl, ovs-appctl, ovs-ofctl וכו'.

נכון לעכשיו, Openstack נמצא בשימוש נרחב על ידי מפעילי טלקום כדי להעביר אליו פונקציות רשת, כגון EPC, SBC, HLR וכו'. פונקציות מסוימות יכולות לחיות ללא בעיות עם OVS כפי שהן, אבל למשל, EPC מעבד תעבורת מנויים - ואז היא עוברת דרך כמות תנועה עצומה (כעת מגיעות נפחי התנועה לכמה מאות גיגה-ביט לשנייה). מטבע הדברים, העברת תעבורה כזו דרך שטח ליבה (מכיוון שהמשלח נמצא שם כברירת מחדל) אינו הרעיון הטוב ביותר. לכן, OVS לרוב נפרס כולו במרחב המשתמש באמצעות טכנולוגיית האצת DPDK כדי להעביר תעבורה מ-NIC למרחב משתמש עוקף את הליבה.

הערה: עבור ענן שנפרס עבור פונקציות טלקום, ניתן להוציא תעבורה מצומת מחשוב עוקף OVS ישירות לציוד מיתוג. למטרה זו נעשה שימוש במנגנוני SR-IOV ו-Passthrough.

איך זה עובד בפריסה אמיתית?

ובכן, עכשיו בואו נעבור לחלק המעשי ונראה איך הכל עובד בפועל.

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

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

אז בואו נתחיל לפי הסדר. ראשית, קצת תיאוריה. נתקין את Openstack באמצעות TripleO (Openstack ב-Openstack). המהות של TripleO היא שאנו מתקינים Openstack all-in-one (כלומר, על צומת אחד), הנקרא undercloud, ולאחר מכן משתמשים ביכולות של Openstack הפרוס כדי להתקין את Openstack המיועד לפעולה, הנקרא overcloud. Undercloud תשתמש ביכולת הטבועה שלה לנהל שרתים פיזיים (מתכת חשופה) - פרויקט Ironic - כדי לספק hypervisors שיבצעו את התפקידים של צמתי מחשוב, בקרה, אחסון. כלומר, אנחנו לא משתמשים בכלים של צד שלישי כדי לפרוס את Openstack - אנחנו פורסים את Openstack באמצעות Openstack. זה יתברר הרבה יותר ככל שההתקנה תתקדם, אז לא נעצור שם ונתקדם.

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

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

אתה יכול לבדוק אם וירטואליזציה מקוננת מופעלת או לא כך:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

אם אתה רואה את האות N, אנו מאפשרים תמיכה בווירטואליזציה מקוננת לפי כל מדריך שתמצא ברשת, למשל כזה .

עלינו להרכיב את המעגל הבא ממכונות וירטואליות:

במקרה שלי, כדי לחבר את המכונות הוירטואליות שהן חלק מההתקנה העתידית (וקיבלתי 7 מהן, אבל אתה יכול להסתדר עם 4 אם אין לך הרבה משאבים), השתמשתי ב-OpenvSwitch. יצרתי גשר one ovs וחיברתי אליו מכונות וירטואליות באמצעות קבוצות יציאות. כדי לעשות זאת, יצרתי קובץ xml כזה:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

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

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

כעת אנו עורכים את תצורות יציאת ההיפרוויזר:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

הערה: בתרחיש זה, הכתובת בפורט ovs-br1 לא תהיה נגישה מכיוון שאין לה תג vlan. כדי לתקן זאת, עליך להנפיק את הפקודה sudo ovs-vsctl set port ovs-br1 tag=100. עם זאת, לאחר אתחול מחדש, התג הזה ייעלם (אם מישהו יודע איך לגרום לו להישאר במקום, אני אודה לו מאוד). אבל זה לא כל כך חשוב, כי אנחנו נזדקק לכתובת זו רק במהלך ההתקנה ולא נזדקק לה כאשר Openstack פרוסה במלואה.

לאחר מכן, אנו יוצרים מכונת תת ענן:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

במהלך ההתקנה מגדירים את כל הפרמטרים הנדרשים כמו שם המכונה, סיסמאות, משתמשים, שרתי ntp וכו', ניתן להגדיר מיד את הפורטים, אבל לי אישית לאחר ההתקנה קל יותר להיכנס למכונה דרך המסוף ותקן את הקבצים הדרושים. אם כבר יש לך תמונה מוכנה, אתה יכול להשתמש בה, או לעשות מה שעשיתי - להוריד את תמונת Centos 7 המינימלית ולהשתמש בה כדי להתקין את ה-VM.

לאחר התקנה מוצלחת, אמור להיות לך מכונה וירטואלית שבה תוכל להתקין אנדרקלאוד

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

ראשית, התקן את הכלים הדרושים לתהליך ההתקנה:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

התקנת ענן

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

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

כעת אנו מציינים את שם ה-undercloud המלא בקובץ המארחים:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

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

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

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

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

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

כעת עלינו לתקן את הקובץ הזה, להתאים אותו להתקנה שלנו.

אתה צריך להוסיף שורות אלה לתחילת הקובץ:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

אז בואו נעבור על ההגדרות:

undercloud_hostname - השם המלא של שרת ה-undercloud, חייב להתאים לערך בשרת ה-DNS

local_ip - כתובת ענן מקומית לכיוון אספקת רשת

network_gateway - אותה כתובת מקומית, שתשמש כשער לגישה לעולם החיצון במהלך התקנת צמתים בענן יתר, עולה בקנה אחד עם ip מקומי

undercloud_public_host - כתובת API חיצונית, כל כתובת פנויה מרשת האספקה ​​מוקצית

undercloud_admin_host כתובת API פנימית, כל כתובת חופשית מרשת האספקה ​​מוקצית

שרתי שמות_undercloud - שרת DNS

gener_service_certificat - שורה זו חשובה מאוד בדוגמה הנוכחית, מכיוון שאם לא תגדיר אותה ל-false תקבל שגיאה במהלך ההתקנה, הבעיה מתוארת במעקב אחר באגים של Red Hat

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

local_mtu - MTU. מכיוון שיש לנו מעבדת בדיקה ויש לי MTU של 1500 ביציאות של מתג OVS, יש צורך להגדיר אותו ל-1450 כדי שמנות המוקפות ב-VxLAN יוכלו לעבור דרכן

network_cidr - רשת אספקה

מסכות - שימוש ב-NAT כדי לגשת לרשת חיצונית

רשת_מסכות - רשת שתהיה NATed

dhcp_start - כתובת ההתחלה של מאגר הכתובות שממנו יוקצו כתובות לצמתים במהלך פריסת ענן יתר

dhcp_end - הכתובת הסופית של מאגר הכתובות שממנו יוקצו כתובות לצמתים במהלך פריסת ענן יתר

inspection_iprange - מאגר כתובות הכרחי להתבוננות פנימית (לא צריך לחפוף למאגר שלעיל)

מתזמן_מקסימום_נסיונות - המספר המרבי של ניסיונות להתקין overcloud (חייב להיות גדול או שווה למספר הצמתים)

לאחר תיאור הקובץ, אתה יכול לתת את הפקודה לפרוס undercloud:

openstack undercloud install

ההליך לוקח בין 10 ל-30 דקות, תלוי בברזל שלך. בסופו של דבר אתה אמור לראות פלט כזה:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

פלט זה אומר שהתקנת את ה-undercloud בהצלחה וכעת אתה יכול לבדוק את המצב של undercloud ולהמשיך להתקין overcloud.

אם תסתכל על הפלט ifconfig, תראה שממשק גשר חדש הופיע

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

פריסת Overcloud תתבצע כעת דרך ממשק זה.

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

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

להלן התצורה של חלק רשת הענן:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

התקנת ענן יתר

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

בואו נלך לתיקיה עם הדיסקים של המכונות הווירטואליות שלנו וניצור דיסקים בגודל הנדרש:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

מכיוון שאנו פועלים כ-root, עלינו לשנות את הבעלים של הדיסקים הללו כדי לא להיתקל בבעיה בזכויות:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

הערה: אם אינכם מתכננים להתקין ceph כדי ללמוד אותו, אז הפקודות אינן יוצרות לפחות 3 צמתים עם לפחות שני דיסקים, אלא בתבנית מציינים שייעשה שימוש בדיסקים וירטואליים vda, vdb וכו'.

נהדר, עכשיו אנחנו צריכים להגדיר את כל המכונות האלה:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

בסוף יש פקודה -print-xml > /tmp/storage-1.xml, שיוצרת קובץ xml עם תיאור של כל מחשב בתיקיה /tmp/; אם לא תוסיף אותו, לא תהיה מסוגל לזהות מכונות וירטואליות.

כעת עלינו להגדיר את כל המכונות הללו ב-virsh:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

עכשיו ניואנס קטן - tripleO משתמש ב-IPMI לניהול שרתים במהלך התקנה ובדיקה פנימה.

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

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

התקן vbmc:

yum install yum install python2-virtualbmc

אם מערכת ההפעלה שלך לא מוצאת את החבילה, הוסף את המאגר:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

כעת הגדרנו את כלי השירות. הכל כאן בנאלי עד כדי בושה. עכשיו זה הגיוני שאין שרתים ברשימת vbmc

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

כדי שהם יופיעו, יש להצהיר עליהם באופן ידני כך:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

והמגע האחרון - עליך לתקן את חוקי חומת האש (או להשבית אותה לחלוטין):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

עכשיו נעבור לאנדרקלאוד ונבדוק שהכל עובד. הכתובת של המחשב המארח היא 192.168.255.200, ב-undercloud הוספנו את חבילת ה-ipmitool הדרושה במהלך ההכנה לפריסה:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

כפי שאתה יכול לראות, השקנו בהצלחה את צומת הבקרה באמצעות vbmc. עכשיו בואו נכבה אותו ונמשיך הלאה:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

השלב הבא הוא התבוננות פנימית של הצמתים עליהם יותקן overcloud. לשם כך, עלינו להכין קובץ json עם תיאור של הצמתים שלנו. שימו לב שבניגוד להתקנה על שרתים חשופים, הקובץ מציין את היציאה שבה פועל vbmc עבור כל מחשב.

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

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

כעת אנו מכינים את קובץ ה-json. עלינו לציין את כתובת הפרג של הפורט שדרכו תתבצע ההקצאה, את הפרמטרים של הצמתים, לתת להם שמות ולציין כיצד להגיע ל-ipmi:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

עכשיו אנחנו צריכים להכין תמונות לאירוניה. כדי לעשות זאת, הורד אותם דרך wget והתקן:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

העלאת תמונות ל-undercloud:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

בודק שכל התמונות נטענו

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

דבר נוסף - אתה צריך להוסיף שרת DNS:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

כעת אנו יכולים לתת את הפקודה להתבוננות פנימית:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

לאחר מכן, עלינו לציין איזה צומת יבצע איזו פונקציה - כלומר, לציין את הפרופיל איתו יתפרס הצומת:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

ציין את הפרופיל עבור כל צומת:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

בואו נבדוק שעשינו הכל נכון:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

אם הכל נכון, אנו נותנים את הפקודה לפרוס overcloud:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

הערה: המשתנה qemu--libvirt-type נחוץ במקרה זה, מכיוון שנשתמש בווירטואליזציה מקוננת. אחרת, לא תוכל להפעיל מכונות וירטואליות.

כעת יש לך כשעה, או אולי יותר (תלוי ביכולות החומרה) ואתה יכול רק לקוות שאחרי הזמן הזה תראה את ההודעה הבאה:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

עכשיו יש לך גרסה כמעט מלאה של openstack, עליה תוכל ללמוד, להתנסות וכו'.

בוא נבדוק שהכל עובד כמו שצריך. בערימת ספריית הבית של המשתמש ישנם שני קבצים - אחד stackrc (לניהול undercloud) והשני overcloudrc (לניהול overcloud). יש לציין קבצים אלה כמקור, מכיוון שהם מכילים מידע הדרוש לאימות.

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

ובכן, עכשיו אתה יכול ללכת אל האופק. כל המידע - כתובות, כניסה וסיסמא - נמצאים בקובץ /home/stack/overcloudrc. התרשים הסופי נראה כך:

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

כיצד זורמת התעבורה בין מכונות וירטואליות?

במאמר זה נבחן שלוש אפשרויות לתנועה חולפת

• שתי מכונות על היפרוויזר אחד ברשת L2 אחת
• שתי מכונות על היפרוויזורים שונים באותה רשת L2
• שתי מכונות ברשתות שונות (השתרשות חוצת רשתות)

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

כדי לבדוק, בואו נרכיב את התרשים הבא:

יצרנו 4 מכונות וירטואליות - 3 ברשת L2 אחת - net-1, ועוד אחת ברשת net-1

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

בואו נראה באילו היפרוויזורים נמצאים המכונות שנוצרו:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(overcloud) [stack@undercloud ~]$
מכונות vm-1 ו-vm-3 ממוקמות על compute-0, מכונות vm-2 ו-vm-4 ממוקמות על node compute-1.

בנוסף, נוצר נתב וירטואלי כדי לאפשר ניתוב בין הרשתות שצוינו:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

לנתב יש שתי יציאות וירטואליות, המשמשות כשערים לרשתות:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

כרגע, לצומת יש שלושה גשרי ovs - br-int, br-tun, br-ex. ביניהם, כפי שאנו רואים, יש סט של ממשקים. כדי להקל על ההבנה, בואו נתווה את כל הממשקים הללו בתרשים ונראה מה קורה.

בהסתכלות על הכתובות שאליהן מורמות מנהרות VxLAN, ניתן לראות שמנהרה אחת מוגבהת למחשב-1 (192.168.255.26), המנהרה השנייה נראית ל-Control-1 (192.168.255.15). אבל הדבר המעניין ביותר הוא של-br-ex אין ממשקים פיזיים, ואם תסתכל על אילו זרימות מוגדרות, אתה יכול לראות שהגשר הזה יכול רק להפיל תנועה כרגע.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

כפי שניתן לראות מהפלט, הכתובת מוברגת ישירות ליציאה הפיזית, ולא לממשק הגשר הווירטואלי.

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

על פי הכלל הראשון, יש להשליך את כל מה שהגיע מיציאת phy-br-ex.
למעשה, כרגע אין מקום אחר לתעבורה להיכנס לגשר הזה חוץ מהממשק הזה (הממשק עם br-int), ואם לשפוט לפי הנפילות, תנועת BUM כבר עפה לתוך הגשר.

כלומר, תעבורה יכולה לעזוב את הצומת הזה רק דרך מנהרת VxLAN ולא שום דבר אחר. עם זאת, אם תפעיל את ה-DVR, המצב ישתנה, אבל נטפל בזה בפעם אחרת. בעת שימוש בבידוד רשת, למשל באמצעות vlans, לא יהיה לך ממשק L3 אחד ב-vlan 0, אלא מספר ממשקים. עם זאת, תעבורת VxLAN תעזוב את הצומת באותו אופן, אך גם מכוסה באיזשהו vlan ייעודי.

סידרנו את צומת המחשוב, בואו נעבור לצומת הבקרה.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

יציאה זו קשורה לגשר br-ex ומכיוון שאין עליו תגיות vlan, יציאה זו היא יציאת טראנק שעליה מותרים כל ה-vlanים, כעת התנועה יוצאת החוצה ללא תג, כפי שמצוין על ידי vlan-id 0 ב- פלט למעלה.

כל השאר כרגע דומה לצומת המחשוב - אותם גשרים, אותן מנהרות שעוברות לשני צמתי מחשוב.

לא נשקול את צמתי האחסון במאמר זה, אך לצורך ההבנה יש צורך לומר שחלק הרשת של הצמתים הללו הוא בנאלי עד כדי בושה. במקרה שלנו, יש רק יציאה פיזית אחת (eth0) עם כתובת IP שהוקצה לה וזהו. אין מנהרות VxLAN, גשרי מנהרות וכו' - אין ovs בכלל, שכן אין בזה טעם. בעת שימוש בבידוד רשת, לצומת זה יהיו שני ממשקים (יציאות פיזיות, גוף, או רק שני vlans - זה לא משנה - תלוי מה אתה רוצה) - אחד לניהול, השני לתעבורה (כתיבה לדיסק VM , קריאה מדיסק וכו')

הבנו מה יש לנו על הצמתים בהיעדר שירותים כלשהם. עכשיו בואו נשיק 4 מכונות וירטואליות ונראה כיצד הסכימה המתוארת לעיל משתנה - אמורות להיות לנו יציאות, נתבים וירטואליים וכו'.

עד כה הרשת שלנו נראית כך:

יש לנו שתי מכונות וירטואליות בכל צומת מחשב. בעזרת compute-0 כדוגמה, בואו נראה איך הכל כלול.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

למכונה יש רק ממשק וירטואלי אחד - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

הממשק הזה נראה בגשר הלינוקס:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

כפי שניתן לראות מהפלט, יש רק שני ממשקים בגשר - tap95d96a75-a0 ו-qvb95d96a75-a0.

כאן כדאי להתעכב מעט על סוגי מכשירי הרשת הווירטואלית ב-OpenStack:
vtap - ממשק וירטואלי מחובר למופע (VM)
qbr - גשר לינוקס
qvb ו-qvo - זוג vEth מחובר לגשר Linux ול- Open vSwitch bridge
br-int, br-tun, br-vlan - פתחו גשרי vSwitch
patch-, int-br-, phy-br- - פתח ממשקי תיקון vSwitch המחברים גשרים
qg, qr, ha, fg, sg - פתחו יציאות vSwitch המשמשות מכשירים וירטואליים כדי להתחבר ל-OVS

כפי שאתה מבין, אם יש לנו יציאת qvb95d96a75-a0 בגשר, שהוא זוג vEth, אז איפשהו יש את המקבילה שלו, שבאופן הגיוני צריך להיקרא qvo95d96a75-a0. בוא נראה אילו יציאות יש ב-OVS.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

כפי שאנו יכולים לראות, הנמל נמצא ב-br-int. Br-int פועל כמתג שמסיים יציאות של מכונות וירטואליות. בנוסף ל-qvo95d96a75-a0, היציאה qvo5bd37136-47 גלויה בפלט. זוהי היציאה למכונה הוירטואלית השנייה. כתוצאה מכך, הדיאגרמה שלנו נראית כעת כך:

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

כלומר, בסופו של דבר התוכנית נראית כך:

שתי מכונות על היפרוויזר אחד ברשת L2 אחת

מכיוון ששני ה-VMs הללו ממוקמים באותה רשת L2 ובאותו hypervisor, התעבורה ביניהם תזרום באופן לוגי מקומי דרך br-int, מכיוון ששתי המכונות יהיו באותו VLAN:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

שתי מכונות על היפרוויזורים שונים באותה רשת L2

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

כתובות של מכונות וירטואליות שביניהם נצפה בתנועה:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

אנו מסתכלים על טבלת ההעברה ב-br-int ב-compute-0:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

התנועה צריכה לעבור לנמל 2 - בוא נראה איזה סוג של נמל זה:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

זה patch-tun - כלומר הממשק ב-br-tun. בוא נראה מה קורה לחבילה ב-br-tun:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

החבילה נארזת ב-VxLAN ונשלחת ליציאה 2. בואו נראה לאן יציאה 2 מובילה:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

זוהי מנהרת vxlan על compute-1:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

בוא נלך למחשב-1 ונראה מה קורה הלאה עם החבילה:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

Mac נמצא בטבלת ההעברה של br-int ב-compute-1, וכפי שניתן לראות מהפלט למעלה, הוא נראה דרך יציאה 2, שהיא היציאה לכיוון br-tun:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

ובכן, אז אנחנו רואים שב-br-int ב-compute-1 יש פרג יעד:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

כלומר, החבילה המתקבלת תטוס ליציאה 3, שמאחוריה כבר יש מופע של מכונה וירטואלית-00000003.

היופי בפריסת Openstack ללמידה על תשתית וירטואלית הוא שאנו יכולים בקלות לתפוס תעבורה בין היפרוויזורים ולראות מה קורה איתה. זה מה שנעשה עכשיו, תריץ את tcpdump ביציאת vnet לכיוון compute-0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

השורה הראשונה מראה ש-Patek מכתובת 10.0.1.85 עוברת לכתובת 10.0.1.88 (תעבורת ICMP), והיא עטופה בחבילת VxLAN עם vni 22 והמנה עוברת מהמארח 192.168.255.19 (compute-0) למארח 192.168.255.26 .1 (חישוב-XNUMX). אנו יכולים לבדוק שה-VNI תואם לזה שצוין ב-ovs.

נחזור לשורה זו actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],פלט:2. 0x16 הוא vni במערכת המספרים הקסדצימלית. בואו נמיר את המספר הזה למערכת העשירית:

16 = 6*16^0+1*16^1 = 6+16 = 22

כלומר, vni תואם את המציאות.

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

שני מכונות ברשתות שונות (ניתוב בין רשתות)

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

ראשית, בואו נראה שהניתוב עובד:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

מכיוון שבמקרה זה החבילה חייבת ללכת לשער ולהיות מנותבת לשם, עלינו לברר את כתובת ה-MAC של השער, שעבורה אנו מסתכלים על טבלת ה-ARP במופע:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

כעת נראה לאן יש לשלוח את התנועה עם היעד (10.0.1.254) fa:16:3e:c4:64:70:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

בואו נסתכל לאן מובילה יציאה 2:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

הכל הגיוני, התנועה עוברת ל-br-tun. בוא נראה באיזו מנהרת vxlan הוא יהיה עטוף:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

היציאה השלישית היא מנהרת vxlan:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

מה שמסתכל על צומת הבקרה:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

התעבורה הגיעה לצומת הבקרה, אז אנחנו צריכים ללכת אליו ולראות איך הניתוב יקרה.

כזכור, צומת הבקרה בפנים נראה בדיוק כמו צומת המחשוב - אותם שלושה גשרים, רק ל-br-ex היה יציאה פיזית שדרכה הצומת יכול לשלוח תעבורה החוצה. יצירת המופעים שינתה את התצורה בצמתי המחשוב - גשר linux, iptables וממשקים נוספו לצמתים. יצירת רשתות ונתב וירטואלי הותירה את חותמה גם על תצורת צומת הבקרה.

אז ברור שכתובת ה-MAC של השער חייבת להיות בטבלת ההעברה br-int בצומת הבקרה. בוא נבדוק שהוא שם ואיפה הוא מסתכל:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

ה-Mac גלוי מהיציאה qr-0c52b15f-8f. אם נחזור לרשימת הפורטים הווירטואליים ב-Openstack, סוג זה של יציאה משמש לחיבור מכשירים וירטואליים שונים ל-OVS. ליתר דיוק, qr הוא יציאה לנתב הווירטואלי, המיוצג כמרחב שמות.

בוא נראה אילו מרחבי שמות יש בשרת:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

עד שלושה עותקים. אבל אם לשפוט לפי השמות, אתה יכול לנחש את המטרה של כל אחד מהם. נחזור למופעים עם מזהה 0 ו-1 מאוחר יותר, כעת אנו מעוניינים במרחב השמות qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

מרחב השמות הזה מכיל שניים פנימיים שיצרנו קודם לכן. שתי היציאות הוירטואליות נוספו ל-br-int. בואו נבדוק את כתובת ה-mac של היציאה qr-0c52b15f-8f, מכיוון שהתעבורה, אם לשפוט לפי כתובת ה-mac היעד, עברה לממשק הזה.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

כלומר, במקרה הזה הכל עובד לפי חוקי הניתוב הסטנדרטי. מכיוון שהתעבורה מיועדת למארח 10.0.2.8, עליה לצאת דרך הממשק השני qr-92fa49b5-54 ולעבור דרך מנהרת vxlan לצומת החישוב:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

הכל הגיוני, אין הפתעות. בוא נראה היכן מופיעה כתובת הפרג של המארח 10.0.2.8 ב-br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

כצפוי, התנועה עוברת ל-br-tun, בואו נראה לאיזו מנהרה התנועה עוברת הבאה:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

התנועה נכנסת למנהרה כדי לחשב-1. ובכן, ב-compute-1 הכל פשוט - מ-br-tun החבילה עוברת ל-br-int ומשם לממשק המכונה הוירטואלית:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

בואו נבדוק שזה אכן הממשק הנכון:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

למעשה, עברנו את כל הדרך בחבילה. אני חושב ששמת לב שהתנועה עברה דרך מנהרות vxlan שונות ויצאה עם VNIs שונים. בואו נראה באיזה סוג VNI מדובר, שלאחריו נאסוף dump על יציאת הבקרה של הצומת ונוודא שהתעבורה זורמת בדיוק כפי שתואר לעיל.
אז, למנהרה לחישוב-0 יש את הפעולות הבאות=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],פלט:3. בואו נמיר 0x16 למערכת המספרים העשרונית:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

למנהרה לחישוב-1 יש את ה-VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. בואו נמיר 0x63 למערכת המספרים העשרונית:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

ובכן, עכשיו בואו נסתכל על המזבלה:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

החבילה הראשונה היא חבילת vxlan מהמארח 192.168.255.19 (compute-0) למארח 192.168.255.15 (control-1) עם vni 22, שבתוכה ארוזה חבילת ICMP מהמארח 10.0.1.85 למארח 10.0.2.8. כפי שחישבנו למעלה, vni תואם למה שראינו בפלט.

החבילה השנייה היא חבילת vxlan ממארח ​​192.168.255.15 (control-1) למארח 192.168.255.26 (compute-1) עם vni 99, שבתוכה ארוזה חבילת ICMP מהמארח 10.0.1.85 למארח 10.0.2.8. כפי שחישבנו למעלה, vni תואם למה שראינו בפלט.

שתי החבילות הבאות הן תעבורה חוזרת מ-10.0.2.8 ולא מ-10.0.1.85.

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

נראה שזהו? שכחנו משני מרחבי שמות:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

כפי שדיברנו על הארכיטקטורה של פלטפורמת הענן, זה יהיה טוב אם מכונות יקבלו כתובות אוטומטית משרת DHCP. אלו שני שרתי DHCP עבור שתי הרשתות שלנו 10.0.1.0/24 ו-10.0.2.0/24.

בוא נבדוק שזה נכון. יש רק כתובת אחת במרחב השמות הזה - 10.0.1.1 - הכתובת של שרת ה-DHCP עצמו, והיא כלולה גם ב-br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

בואו נראה אם ​​תהליכים המכילים qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 בשמם בצומת הבקרה:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

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

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

כתוצאה מכך, אנו מקבלים את קבוצת השירותים הבאה בצומת הבקרה:

ובכן, זכור - זה רק 4 מכונות, 2 רשתות פנימיות ונתב וירטואלי אחד... אין לנו כאן רשתות חיצוניות עכשיו, חבורה של פרויקטים שונים, שלכל אחד רשתות משלו (חופפות), ויש לנו נתב מבוזר כבוי, ובסופו של דבר אחרי הכל, היה רק ​​צומת בקרה אחד בספסל הבדיקה (עבור סובלנות תקלות חייב להיות מניין של שלושה צמתים). זה הגיוני שבמסחר הכל "קצת" יותר מסובך, אבל בדוגמה הפשוטה הזו אנחנו מבינים איך זה צריך לעבוד - אם יש לך 3 או 300 מרחבי שמות זה כמובן חשוב, אבל מנקודת המבט של הפעולה של כל המבנה, שום דבר לא ישתנה הרבה... למרות שלא תחבר איזה SDN של ספק. אבל זה סיפור אחר לגמרי.

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

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

אם OpenStack הוא פתרון מונע על ידי קהילה, אז ל-VMWare יש את הזכות לעשות רק מה שהיא רוצה (תקראו - מה שמשתלם לה) וזה הגיוני - כי זו חברה מסחרית שרגילה לעשות כסף מלקוחותיה. אבל יש אבל אחד גדול ושמן - אתה יכול לרדת מ-OpenStack, למשל מנוקיה, ועם מעט הוצאות לעבור לפתרון של, למשל, ג'וניפר (Contrail Cloud), אבל לא סביר שתצליח לרדת מ-VMWare . מבחינתי שני הפתרונות הללו נראים כך - Openstack (ספק) הוא כלוב פשוט שבו שמים אותך, אבל יש לך מפתח ואתה יכול לצאת בכל עת. VMWare הוא כלוב מוזהב, לבעלים יש את המפתח לכלוב וזה יעלה לכם הרבה.

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

לדעתי, החיסרון הכי גדול של VMWare הוא הסגירה המוחלטת שלה - החברה לא תיתן לך שום מידע על איך זה עובד, למשל, vSAN או מה יש בליבת ההיפרוויזר - זה פשוט לא משתלם לה - כלומר, אתה תעשה לעולם אל תהפוך למומחה ב-VMWare - ללא תמיכת ספקים, אתה נדון (לעיתים קרובות אני פוגש מומחי VMWare שמבולבלים משאלות טריוויאליות). מבחינתי VMWare קונה רכב עם מכסה מנוע נעול - כן, אולי יש לך מומחים שיכולים להחליף רצועת טיימינג, אבל רק מי שמכר לך את הפתרון הזה יכול לפתוח את מכסה המנוע. באופן אישי, אני לא אוהב פתרונות שאני לא יכול להשתלב בהם. אתה תגיד שאולי לא תצטרך להיכנס מתחת למכסה המנוע. כן, זה אפשרי, אבל אני אסתכל עליך כשתצטרך להרכיב פונקציה גדולה בענן מ-20-30 מכונות וירטואליות, 40-50 רשתות, חצי מהן רוצות לצאת החוצה, והחצי השני מבקש האצת SR-IOV, אחרת תזדקק לעוד כמה עשרות מהמכוניות האלה - אחרת הביצועים לא יספיקו.

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

מקור: www.habr.com