כיצד Yandex.Cloud עובד עם ענן פרטי וירטואלי וכיצד המשתמשים שלנו עוזרים לנו ליישם תכונות שימושיות

שלום, שמי קוסטיה קרמליץ', אני המפתחת המובילה של חטיבת ה-Virtual Private Cloud ב-Yandex.Cloud. אני עובד על רשת וירטואלית, וכפי שאפשר לנחש, במאמר זה אדבר על מכשיר ה-Virtual Private Cloud (VPC) בכלל והרשת הוירטואלית בפרט. ותגלו גם למה אנחנו, מפתחי השירות, מעריכים משוב מהמשתמשים שלנו. אבל דבר ראשון.

מה זה VPC?

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

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

איך נראית רשת וירטואלית מבחוץ

ב-VPC אנו מתכוונים, קודם כל, לרשת שכבת-על ושירותי רשת, כגון VPNaaS, NATaas, LBaas וכו'. וכל זה עובד על גבי תשתית רשת סובלנית לתקלות, שכבר דנו בה. מאמר נהדר כאן על האברה.

בואו נסתכל מקרוב על הרשת הוירטואלית והמבנה שלה.

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

הרשת היא גלובלית. במקביל, הוא מוקרן על כל אחד מאזורי הזמינות בצורה של ישות בשם Subnet. עבור כל רשת משנה אתה מקצה CIDR בגודל 16 או פחות. לכל אזור זמינות יכול להיות יותר מיישות אחת כזו, ותמיד יש ביניהם ניתוב שקוף. המשמעות היא שכל המשאבים שלך בתוך אותו VPC יכולים "לדבר" זה עם זה, גם אם הם נמצאים באזורי זמינות שונים. "לתקשר" ללא גישה לאינטרנט, דרך הערוצים הפנימיים שלנו, "בחושב" שהם בתוך אותה רשת פרטית.

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

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

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

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

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

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

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

אנו מתעדים את המצב הרצוי במסד הנתונים של Yandex והולכים להגדיר חלקים שונים של ה-VPC שלנו. רשת השכבות ב-Yandex.Cloud בנויה על בסיס רכיבים נבחרים של OpenContrail, שנקרא לאחרונה Tungsten Fabric. שירותי רשת מיושמים בפלטפורמת CloudGate אחת. ב-CloudGate השתמשנו גם במספר רכיבי קוד פתוח: GoBGP לטיפול במידע בקרה, וכן VPP להטמעת נתב תוכנה הפועל על גבי DPDK עבור נתיב הנתונים.

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

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

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

VPC1 ממופה לאזור זמינות B אם לאזור זמינות B יש משאבים שנדבקים ל-VPC1. אם אין משאבים מ-VPC2 באזור זמינות B, אנחנו לא מיישמים את VPC2 באזור זה. בתורו, מאחר ומשאבים מ-VPC3 קיימים רק באזור B, VPC3 אינו קיים באזור A. הכל פשוט והגיוני.

בואו נעמיק קצת יותר ונראה איך מארח ספציפי ב-Y.Cloud עובד. הדבר העיקרי שהייתי רוצה לציין הוא שכל המארחים מעוצבים אותו הדבר. אנו מוודאים שרק המינימום הדרוש של שירותים פועל על חומרה; כל השאר פועלים על מכונות וירטואליות. אנו בונים שירותים מסדר גבוה יותר המבוססים על שירותי תשתית בסיסיים, ומשתמשים גם בענן כדי לפתור כמה בעיות הנדסיות, למשל, כחלק מ-Continuous Integration.

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

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

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

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

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

אנו מבחינים בשלוש שכבות במערכת שלנו:

• Config Plane - מגדיר את מצב היעד של המערכת. זה מה שהמשתמש מגדיר דרך ה-API.
• Control Plane - מספק סמנטיקה שצוינה על-ידי המשתמש, כלומר מביא את מצב ה-Data Plane למה שתואר על-ידי המשתמש ב-Config Plane.
• Data Plane - מעבד ישירות מנות משתמש.

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

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

מישור התצורה ב-Tungsten Fabric מעלה את המצב הנדרש למישור הבקרה. באמצעותו, Config Plane מתקשר עם המארחים, ואומר להם מה בדיוק יפעל עליהם בעתיד הקרוב.

עכשיו בואו נראה איך המערכת נראית במארחים. למכונה הוירטואלית יש מתאם רשת מסוים המחובר ל-VRouter. VRouter הוא מודול ליבת בד טונגסטן שמסתכל על מנות. אם כבר יש זרימה עבור חבילה כלשהי, המודול מעבד אותה. אם אין זרימה, המודול עושה מה שנקרא punting, כלומר, הוא שולח את החבילה לתהליך usermod. התהליך מנתח את החבילה או מגיב לה בעצמו, כמו DHCP ו-DNS, או אומר ל-VRouter מה לעשות איתה. לאחר מכן VRouter יכול לעבד את החבילה.

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

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

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

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

תוכניות לעתיד הקרוב

אם נסכם את כל האמור לעיל בכמה משפטים, נוכל לומר ש-VPC ב-Yandex.Cloud פותר שתי בעיות חשובות:

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

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

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

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

• VPN כשירות.
• מופעי DNS פרטיים - תמונות להגדרה מהירה של מכונות וירטואליות עם שרת DNS מוגדר מראש.
• DNS כשירות.
• מאזן עומסים פנימי.
• הוספת כתובת IP "לבנה" מבלי ליצור מחדש את המכונה הוירטואלית.

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

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

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

מקור: www.habr.com