ארכיטקטורה

במאמר הזה מתוארת ארכיטקטורת הפריסה, האשכול והרשת של מכשיר Google Distributed Cloud ‏ (GDC) עם בידוד פיזי.

ארכיטקטורת פריסה

בתרשים הבא מוצג אופן השילוב של חומרת ה-Appliance ברשת של לקוח, כולל רכיבים אופציונליים כמו HSM, שרת NTP ולקוחות נוספים ברשת. המכשיר מצויד במישור ניהול, מישור נתונים, שרתים ושרת עם GPU אחד, וכולם מיועדים להפעלת עומסי עבודה ישירות בקצה הרשת.

ארכיטקטורת אשכול

מכשיר GDC עם air gap מפעיל אשכול יחיד שכולל את כל שלושת צמתי ה-Bare Metal שלו, שנקראים אשכול התשתית הארגונית. שרת API ייעודי לניהול, שפועל כעומסי עבודה של פודים באשכול, מארח ממשקי API של מישור הניהול. עומסי עבודה של משתמשים, כולל מכונות וירטואליות ו-pods של Kubernetes, יכולים לפעול באשכול הזה. אין אשכול משתמשים במודל האשכול הזה.

ארכיטקטורת רשת

ה-EL8000 כולל לוח אחורי שיוצר ארבע רשתות נפרדות ברמה 2 (L2) בתוך המכשיר:

1. מסוף Integrated Lights-Out‏ (iLO) ‏ (1GbEth)
2. רשת ניהול (1GbEth)
3. רשת נתונים א' (10GbEth)
4. רשת נתונים ב' (10GbEth)

הדיאגרמה הבאה מציגה כיצד רשתות L2 מחוברות למתג Mellanox (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs). כל רשת ב-blade מתחברת למתג רשת יחיד. כל הרשתות של מסוף iLO בכל להב שרת מתחברות למתג רשת 1. רשתות הניהול מתחברות למתג רשת 2, ורשתות הנתונים מתחברות למתגים 3 ו-4.

ליציאות ברשת של הלקוח (15 ו-17) יש גישה לאשכול (VLAN 100), ומותרת רק תעבורת נתונים ל-CIDR של Ingress. ה-CIDR של התנועה הנכנסת זמין לשירותים, והטווח מפורסם באמצעות Border Gateway Protocol‏ (BGP) ברשת הלקוח.

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

הטופולוגיה של הרשת התחתונה

רשת פיזית

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

העיצוב הפיזי מבוסס על Mellanox SN2010 שמשמש כשער בין Appliance Infra Cluster לבין רשת הלקוחות החיצונית.

אשכול התשתית מורכב מ-3 צמתים של Bare Metal (BM). אפשר לחלק את החיבורים ב-BMs לקטגוריות הבאות:

• קישוריות לרשת נתונים (תת-רשת 198.18.2.0/24) שמתבצעת דרך VLAN 100. ל-BM יש כרטיס NIC עם 2 יציאות, NIC0P1 ו-NIC0P2, שמחוברות יחד ומחוברות למתג TOR. ‫BM1 ו-BM2 מתחברים ישירות למתג, ואילו BM3 מתחבר ל-TOR באמצעות מתג לא מנוהל.
• הקישוריות לרשת הניהול ( תת-רשת 198.18..0/24) היא דרך VLAN 501. ממשקי ה-ILO וה-MGMT מחוברים דרך ה-VLAN הזה באמצעות ממשקי 1G. ממשקי ה-ILO וממשקי ה-MGMT בצמתי ה-BM מתחברים למתג באמצעות מתגים לא מנוהלים.
• אולי: הוספת רשת OTS ב-VLANs 200-203(?), תת-רשת 198.18.1.x

החיבור ממתג Mellanox לנתב של הלקוח מספק קישוריות חיצונית. ממשקי 10G משמשים לקישוריות הזו, ופרוטוקול BGP משמש לפרסום כתובות ה-IP של הרשת החיצונית ללקוח. הלקוחות משתמשים בכתובות ה-IP החיצוניות כדי לגשת לשירותים הנדרשים שמסופקים על ידי יחידת ה-Appliance.

הערה: בתרשים הפיזי של הרשת שמוצג למעלה אפשר לראות מכשיר bootstrapper שמחובר ליציאה 12 של המתג. ה-bootstrapper הזה נועד להקצות את יחידת ה-appliance כחלק משלב ה-bootstrap בצד הנמוך. החיבור הזה לא יהיה קיים כשהמכשיר יישלח ללקוח.

רשת לוגית

יש שתי רשתות מקומיות וירטואליות (VLAN) שמפרידות בין סוגי התנועה השונים:

1. ‫VLAN 100: אשכול (כתובות IP וירטואליות של פרוטוקול אינטרנט (VIP) לכניסה, כתובות IP של אשכול/צומת) עם רשת משנה של IPv4 שסופקה על ידי הלקוחות.
2. ‫VLAN 501: ניהול (iLO, ‏ Mgmt) עם רשת משנה של IPv4 שסופקה על ידי הלקוח.

הטופולוגיה של הרשת העליונה

האשכול מוגדר באמצעות איזון עומסים בשכבה 2 (L2). כתובות ה-VIP של Ingress באשכול מגיעות מאותה תת-רשת כמו הצמתים. כשכתובת VIP של Ingress מוקצית לצומת, הצומת משתמש בפרוטוקול ARP (פרוטוקול לפתרון כתובות) כדי שיהיה אפשר להגיע לצומת מ-TOR.

ה-TOR מבצע פעולת עמיתים עם רשת הלקוח באמצעות BGP, ומפרסם את טווח הכניסה של האשכול (קידומת מצטברת שסופקה על ידי הלקוח) ברשת הלקוח. כשהמתלה עובר למיקום חדש, אנחנו יכולים לפרסם את טווח ה-Ingress של האשכול ברשת הלקוח החדשה. כשמתלה עובר למיקום חדש, צריך לעדכן ידנית את כתובות ה-IP בממשקי TOR שמתחברים לרשת של הלקוח, ולעדכן את פרטי ה-BGP peering כדי להוסיף את עמיתי ה-BGP החדשים.

כל כתובות ה-IP שמשמשות את האשכול מוקצות מתוך externalCidrBlock של המתלה, או מקודדות באופן קשיח (עבור כתובות IP פנימיות של האשכול). בתרשים הבא, הדוגמה externalCidrBlock היא 10.0.0.0/24:

טווחי כתובות IP של אשכולות

יש כמה טווחי כתובות IP שצריך להגדיר באשכול bare metal.

• ‫Pod CIDR: טווח כתובות ה-IP שמשמש להקצאת כתובות IP לפודים באשכול. הטווח הזה משתמש במצב איים, כך שהרשת הפיזית (ToR) לא צריכה לדעת על ה-CIDR של ה-Pod. הדרישה היחידה היא שהטווח לא יחפוף לשום שירות שפודים באשכול צריכים לגשת אליו. אי אפשר לשנות את ה-CIDR של הפוד אחרי שיוצרים את האשכול.
• ‫Service CIDR: משמש לשירותים פנימיים באשכול עם אותה דרישה כמו ה-CIDR של ה-Pod.
• ‫Node CIDR: כתובות ה-IP של הצמתים של אשכול Kubernetes. אי אפשר לשנות את הכתובות האלה אחרי שיוצרים את האשכול.
• טווח כתובות IP לתעבורת נתונים נכנסת: טווח של כתובות IP שמשמשות את כל השירותים באשכול שנחשפים חיצונית. לקוחות חיצוניים משתמשים בכתובות ה-IP האלה כדי לגשת לשירותים בתוך האשכול. צריך לפרסם את הטווח הזה ברשת הלקוח כדי שהלקוחות יוכלו להגיע לכתובות ה-IP של Ingress.
• כתובת VIP של מישור הבקרה: כתובת שמשודרת על ידי האשכול כדי לקבל גישה ל-Kubernetes api-server (בדומה לכתובות ה-VIP של Ingress). כתובת ה-VIP הזו צריכה להיות מאותה רשת משנה כמו הצומת, כשהאשכול נמצא במצב איזון עומסים ברמה 2.

ה-CIDR של ה-Pod וה-CIDR של השירותים עבור האשכולות הם קוד קשיח. ה-CIDR של ה-Pod וה-CIDR של השירות הם 198.18.0.0/16. האשכול משתמש באותו CIDR, כי כתובת ה-IP הזו לא נחשפת מחוץ לאשכול.

הערה: כתובות ה-IP של המכונות הווירטואליות מוקצות מהטווח instance-default-vpc-cidr, שהוא קבוע ב-192.168.0.0/16. אם המכשיר מחובר לרשת של לקוח דרך מתג TOR, חשוב לוודא שטווח כתובות ה-IP של רשת הלקוח לא מתנגש עם הטווח של 192.168.0.0/16. טווחים חופפים של כתובות IP עלולים להוביל לניתוב שגוי של תנועת נתונים במכשיר.

לצמתים מוקצות כתובות IP מתוך externalCidrBlock שהוגדר ב-GDC cell.yaml. כתובות ה-IP האלה מסופקות על ידי הלקוח לפני הקצאת המתלה.

גם טווח ה-Ingress וכתובת ה-VIP של מישור הבקרה של האשכול מוקצים מתוך externalCidrBlock. ה-TOR צריך לפרסם את externalCidrBlock ברשת הלקוחות כדי שהלקוחות מחוץ למתלה יוכלו לגשת לכתובות ה-VIP האלה.