איך AWS מבשלת את השירותים האלסטיים שלה. קנה מידה רשת

קנה המידה של רשת שירותי האינטרנט של אמזון הוא 69 אזורים ברחבי העולם ב-22 אזורים: ארה"ב, אירופה, אסיה, אפריקה ואוסטרליה. כל אזור מכיל עד 8 מרכזי נתונים - מרכזי עיבוד נתונים. לכל מרכז נתונים יש אלפי או מאות אלפי שרתים. הרשת מתוכננת בצורה כזו שכל תרחישי ההפסקה הבלתי סבירים נלקחים בחשבון. לדוגמה, כל האזורים מבודדים זה מזה, ואזורי נגישות מופרדים למרחקים של מספר קילומטרים. גם אם תחתכו את הכבל, המערכת תעבור לערוצי גיבוי, ואובדן המידע יסתכם בכמה מנות נתונים. Vasily Pantyukhin ידבר על אילו עקרונות נוספים בנויה הרשת וכיצד היא בנויה.

ואסילי פנטיוחין התחיל כמנהל Unix בחברות .ru, עבד על חומרה גדולה של Sun Microsystem במשך 6 שנים, והטיף לעולם ממוקד נתונים במשך 11 שנים ב-EMC. זה התפתח באופן טבעי לעננים פרטיים, ואז עבר לעננים ציבוריים. כעת, כאדריכל שירותי אינטרנט של אמזון, הוא מספק ייעוץ טכני כדי לעזור לחיות ולהתפתח בענן AWS.

בחלק הקודם של טרילוגיית AWS, Vasily התעמק בעיצוב של שרתים פיזיים וקנה מידה של מסד נתונים. כרטיסי Nitro, Hypervisor מותאם אישית מבוסס KVM, מסד נתונים של אמזון אורורה - על כל זה בחומר "איך AWS מבשלת את השירותים האלסטיים שלה. קנה מידה של שרתים ומסד נתונים" קרא להקשר או צפה קַלֶטֶת וִידֵיאוֹ נאומים.

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

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

קנה מידה רשת

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

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

ענן וירטואלי פרטי

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

מה הדבר הראשון שעולה לך בראש כשאתה חושב על בידוד רשת? בְּהֶחלֵט VLAN и VRF - ניתוב והעברה וירטואלית.

למרבה הצער, זה לא עבד. מזהה VLAN הוא רק 12 סיביות, מה שנותן לנו רק 4096 מקטעים מבודדים. אפילו המתגים הגדולים ביותר יכולים להשתמש ב-1-2 אלף VRFs לכל היותר. השימוש ב-VRF וב-VLAN ביחד נותן לנו רק כמה מיליוני רשתות משנה. זה בהחלט לא מספיק לעשרות מיליוני דיירים, שכל אחד מהם חייב להיות מסוגל להשתמש במספר רשתות משנה.

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

יש רק מסקנה אחת - עשה פתרון משלך.

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

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

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

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

בואו להבין איך זה עובד במונחים כלליים. נתחיל עם רמת L2. בוא נניח שיש לנו מכונה וירטואלית עם IP 10.0.0.2 בשרת פיזי 192.168.0.3. הוא שולח נתונים למחשב וירטואלי 10.0.0.3, שחי ב-192.168.1.4. נוצרת בקשת ARP ונשלחת לכרטיס Nitro ברשת. לשם הפשטות, אנו מניחים ששתי המכונות הוירטואליות חיות באותו VPC "כחול".

המפה מחליפה את כתובת המקור בכתובת שלה ומעבירה את מסגרת ה-ARP לשירות המיפוי.

שירות המיפוי מחזיר מידע הדרוש לשידור על גבי הרשת הפיזית L2.

כרטיס הניטרו בתגובת ה-ARP מחליף את ה-MAC ברשת הפיזית בכתובת ב-VPC.

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

המכונה הפיזית אליה מיועדת החבילה מבצעת את הבדיקה. זה הכרחי כדי למנוע את האפשרות של זיוף כתובות. המכונה שולחת בקשה מיוחדת לשירות המיפוי ושואלת: "ממכונה פיזית 192.168.0.3 קיבלתי חבילה המיועדת ל-10.0.0.3 ב-VPC הכחול. האם הוא לגיטימי? 

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

לאחר מכן, הנתונים נשלחים למכונה הווירטואלית שלשמה הם מיועדים. 

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

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

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

סידרנו את העברת הנתונים ל-VPC.

בלקפוט

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

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

הנתונים מפורקים ועטופים מחדש ב-IPsec בעת שימוש ב-VPN.

בעת שימוש ב- Direct Connect, התעבורה מתויגת ונשלחת ל-VLAN המתאים.

HyperPlane

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

בענן AWS, דרישות זמן השידור גבוהות ביותר. בגלל זה HyperPlane קריטי לביצועי הרשת כולה.

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

Hyperplane היא מערכת מבוזרת של מספר עצום של מכונות EC2 כאלה. לכל מכונה וירטואלית יש רוחב פס של 5 GB/s. בכל הרשת האזורית, זה מספק טרה-ביטים מדהימים של רוחב פס ומאפשר עיבוד מיליוני חיבורים בשנייה.

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

שכן רועש

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

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

סבירות נמוכה לא אומר בלתי אפשרי.

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

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

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

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

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

מספר המשתמשים שיצטלבו

הסתברות באחוזים

0

18%

1

54%

2

26%

3

2%

בואו נקרב את המצב למציאות - בואו ניקח 100 צמתים ו-5 משתמשים על 5 צמתים. במקרה זה, אף אחד מהצמתים לא יצטלב בהסתברות של 77%. 

מספר המשתמשים שיצטלבו

הסתברות באחוזים

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

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

שירותים רבים בנויים על בסיס HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

סולם רשת

עכשיו בואו נדבר על קנה המידה של הרשת עצמה. לאוקטובר 2019 AWS מציעה את שירותיה ב 22 אזורים, ועוד 9 מתוכננים.

• כל אזור מכיל מספר אזורי זמינות. יש 69 מהם ברחבי העולם.
• כל AZ מורכב ממרכזי עיבוד נתונים. אין יותר מ-8 מהם בסך הכל.
• מרכז הנתונים מכיל מספר עצום של שרתים, חלקם עם עד 300.

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

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

Backbone AWS נבנה במיוחד עבור הענן ומותאם במיוחד עבורו. אנחנו בונים את זה על הערוצים 100 GB / s. אנחנו שולטים בהם לחלוטין, למעט אזורים בסין. התנועה לא מתחלקת עם המון חברות אחרות.

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

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

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

מעניין איך האינטרנט ישתנה בעוד 10 שנים אם המגמה הזו תימשך?

ערוצים פיזיים

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

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

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

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

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

על HighLoad ++ בנובמבר וסילי פנטיוכין ישתף פרטים חדשים על מכשיר אמזון. הוא יגידו על הגורמים לכשלים ותכנון מערכות מבוזרות באמזון. 24 באוקטובר עדיין אפשרי להזמין כרטיס במחיר טוב, ולשלם מאוחר יותר. אנחנו מחכים לכם ב-HighLoad++, בואו ונדבר!

מקור: www.habr.com