چگونه AWS خدمات الاستیک خود را طبخ می کند. مقیاس بندی شبکه

مقیاس شبکه خدمات وب آمازون 69 منطقه در سراسر جهان در 22 منطقه است: ایالات متحده آمریکا، اروپا، آسیا، آفریقا و استرالیا. هر منطقه شامل حداکثر 8 مرکز داده - مراکز پردازش داده است. هر مرکز داده هزاران یا صدها هزار سرور دارد. شبکه به گونه ای طراحی شده است که تمام سناریوهای قطعی غیر محتمل در نظر گرفته شود. به عنوان مثال، همه مناطق از یکدیگر جدا شده اند و مناطق دسترسی در فواصل چند کیلومتری از هم جدا شده اند. حتی اگر کابل را قطع کنید، سیستم به کانال های پشتیبان تغییر می کند و از دست دادن اطلاعات به تعداد چند بسته داده می رسد. واسیلی پانتیوخین در مورد اینکه این شبکه بر اساس چه اصول دیگری ساخته شده است و ساختار آن چگونه است صحبت خواهد کرد.

واسیلی پانتیوخین به عنوان مدیر یونیکس در شرکت‌های .ru شروع به کار کرد، به مدت 6 سال روی سخت‌افزار بزرگ Sun Microsystem کار کرد و به مدت 11 سال در EMC یک دنیای داده محور را تبلیغ کرد. به طور طبیعی به ابرهای خصوصی تبدیل شد و سپس به ابرهای عمومی منتقل شد. اکنون، به عنوان یک معمار خدمات وب آمازون، او توصیه های فنی برای کمک به زندگی و توسعه در ابر AWS ارائه می دهد.

در قسمت قبلی از سه گانه AWS، واسیلی به طراحی سرورهای فیزیکی و مقیاس بندی پایگاه داده پرداخت. کارت های نیترو، هایپروایزر سفارشی مبتنی بر KVM، پایگاه داده آمازون شفق قطبی - در مورد همه اینها در مطالب "چگونه AWS خدمات الاستیک خود را طبخ می کند. مقیاس پذیری سرورها و پایگاه داده" برای متن بخوانید یا تماشا کنید نوار ویدئویی سخنرانی ها

این بخش بر مقیاس بندی شبکه، یکی از پیچیده ترین سیستم ها در AWS تمرکز خواهد کرد. تکامل از یک شبکه مسطح به یک ابر خصوصی مجازی و طراحی آن، خدمات داخلی Blackfoot و HyperPlane، مشکل یک همسایه پر سر و صدا، و در پایان - مقیاس شبکه، ستون فقرات و کابل های فیزیکی. در مورد همه اینها زیر برش.

سلب مسئولیت: همه موارد زیر نظر شخصی واسیلی است و ممکن است با موقعیت خدمات وب آمازون مطابقت نداشته باشد.

مقیاس بندی شبکه

ابر AWS در سال 2006 راه اندازی شد. شبکه او کاملاً ابتدایی بود - با ساختاری مسطح. دامنه آدرس های خصوصی برای همه مستاجران ابر مشترک بود. هنگام راه اندازی یک ماشین مجازی جدید، به طور تصادفی یک آدرس IP موجود از این محدوده دریافت کردید.

اجرای این رویکرد آسان بود، اما اساساً استفاده از ابر را محدود کرد. به طور خاص، توسعه راه‌حل‌های ترکیبی که شبکه‌های خصوصی را روی زمین و در AWS ترکیب می‌کرد، بسیار دشوار بود. رایج ترین مشکل همپوشانی محدوده آدرس IP بود.

ابر خصوصی مجازی

معلوم شد که ابر مورد تقاضا است. زمان آن فرا رسیده است که به مقیاس پذیری و امکان استفاده از آن توسط ده ها میلیون مستأجر فکر کنیم. شبکه مسطح به یک مانع بزرگ تبدیل شده است. بنابراین، ما به این فکر کردیم که چگونه کاربران را در سطح شبکه از یکدیگر جدا کنیم تا بتوانند به طور مستقل محدوده IP را انتخاب کنند.

وقتی به جداسازی شبکه فکر می کنید اولین چیزی که به ذهنتان خطور می کند چیست؟ قطعا VLAN ها и VRF - مسیریابی و ارسال مجازی.

متاسفانه کار نکرد. VLAN ID فقط 12 بیت است که تنها 4096 بخش جدا شده را به ما می دهد. حتی بزرگترین سوئیچ ها می توانند حداکثر 1-2 هزار VRF استفاده کنند. استفاده از VRF و VLAN با هم تنها چند میلیون زیرشبکه به ما می دهد. این قطعا برای ده ها میلیون مستاجر کافی نیست، که هر کدام باید بتوانند از چندین زیرشبکه استفاده کنند.

ما همچنین به سادگی نمی توانیم تعداد مورد نیاز جعبه های بزرگ را بخریم، به عنوان مثال، از Cisco یا Juniper. دو دلیل وجود دارد: دیوانه وار گران است، و ما نمی خواهیم تحت الحمایه سیاست های توسعه و اصلاح آنها باشیم.

تنها یک نتیجه وجود دارد - راه حل خود را بسازید.

در سال 2009 اعلام کردیم VPC - ابر خصوصی مجازی. این نام گیر کرده و اکنون بسیاری از ارائه دهندگان ابر نیز از آن استفاده می کنند.

VPC یک شبکه مجازی است SDN (شبکه نرم افزاری تعریف شده). تصمیم گرفتیم پروتکل های خاصی را در سطوح L2 و L3 اختراع نکنیم. شبکه بر روی اترنت و IP استاندارد اجرا می شود. برای انتقال از طریق شبکه، ترافیک ماشین مجازی در بسته بندی پروتکل خودمان کپسوله می شود. نشان دهنده شناسه ای است که به VPC مستاجر تعلق دارد.

ساده به نظر می رسد. با این حال، چندین چالش فنی جدی وجود دارد که باید بر آنها غلبه کرد. به عنوان مثال، مکان و نحوه ذخیره داده‌ها در نقشه‌برداری آدرس‌های MAC/IP مجازی، شناسه VPC و MAC/IP فیزیکی مربوطه. در مقیاس AWS، این یک جدول بزرگ است که باید با حداقل تاخیر دسترسی کار کند. مسئول این امر است خدمات نقشه برداری، که در یک لایه نازک در سراسر شبکه پخش می شود.

در ماشین های نسل جدید کپسوله سازی توسط کارت های نیترو در سطح سخت افزار انجام می شود. در نمونه‌های قدیمی‌تر، کپسوله‌سازی و کپسول‌زدایی مبتنی بر نرم‌افزار هستند. 

بیایید بفهمیم که چگونه به طور کلی کار می کند. بیایید با سطح 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 نیترو منبع و مقصد مناسب منتقل می کنیم.

ماشین فیزیکی که بسته به آن مقصد است بررسی را انجام می دهد. این برای جلوگیری از امکان جعل آدرس ضروری است. ماشین یک درخواست ویژه به سرویس نقشه‌برداری می‌فرستد و می‌پرسد: «از ماشین فیزیکی 192.168.0.3 بسته‌ای دریافت کردم که برای 10.0.0.3 در VPC آبی در نظر گرفته شده است. آیا او مشروع است؟ 

سرویس نقشه برداری جدول تخصیص منابع خود را بررسی می کند و به بسته اجازه می دهد یا آن را رد می کند. در تمام موارد جدید، اعتبار سنجی اضافی در کارت های نیترو تعبیه شده است. دور زدن آن حتی از نظر تئوریک غیرممکن است. بنابراین، جعل منابع در VPC دیگر کار نخواهد کرد.

سپس داده ها به ماشین مجازی که برای آن در نظر گرفته شده ارسال می شود. 

سرویس نقشه برداری همچنین به عنوان یک روتر منطقی برای انتقال داده ها بین ماشین های مجازی در زیرشبکه های مختلف کار می کند. همه چیز از نظر مفهومی ساده است، من وارد جزئیات نمی شوم.

معلوم می شود که هنگام انتقال هر بسته، سرورها به سرویس نقشه برداری روی می آورند. چگونه با تاخیرهای اجتناب ناپذیر مقابله کنیم؟ ذخیره سازی، البته.

زیبایی این است که شما نیازی به کش کردن کل جدول بزرگ ندارید. یک سرور فیزیکی میزبان ماشین های مجازی از تعداد نسبتا کمی VPC است. شما فقط باید اطلاعات مربوط به این VPC ها را کش کنید. انتقال داده ها به VPC های دیگر در پیکربندی "پیش فرض" هنوز قانونی نیست. اگر از عملکردهایی مانند VPC-peering استفاده شود، اطلاعات مربوط به VPC های مربوطه نیز در حافظه پنهان بارگذاری می شود. 

ما انتقال داده ها به VPC را مرتب کردیم.

سیاه قلم

در مواردی که ترافیک باید به خارج منتقل شود، مثلاً به اینترنت یا از طریق VPN به زمین، چه باید کرد؟ اینجا به ما کمک می کند سیاه قلم - سرویس داخلی AWS. این توسط تیم آفریقای جنوبی ما توسعه یافته است. به همین دلیل است که این سرویس به نام پنگوئنی که در آفریقای جنوبی زندگی می کند نامگذاری شده است.

Blackfoot ترافیک را کپسوله می کند و آنچه را که لازم است با آن انجام می دهد. داده ها همانطور که هست به اینترنت ارسال می شوند.

هنگام استفاده از VPN، داده ها کپسوله می شوند و دوباره در IPsec پیچیده می شوند.

هنگام استفاده از Direct Connect، ترافیک برچسب گذاری شده و به VLAN مناسب ارسال می شود.

هایپرپلن

این یک سرویس کنترل جریان داخلی است. بسیاری از خدمات شبکه نیاز به نظارت دارند وضعیت های جریان داده. به عنوان مثال، هنگام استفاده از NAT، کنترل جریان باید اطمینان حاصل کند که هر جفت پورت IP: مقصد دارای یک پورت خروجی منحصر به فرد است. در مورد متعادل کننده NLB - متعادل کننده بار شبکه، جریان داده باید همیشه به همان ماشین مجازی هدف هدایت شود. Security Groups یک فایروال حالت دار است. ترافیک ورودی را نظارت می کند و به طور ضمنی پورت ها را برای جریان بسته های خروجی باز می کند.

در ابر AWS، الزامات تأخیر انتقال بسیار زیاد است. از همین رو هایپرپلن برای عملکرد کل شبکه حیاتی است.

Hyperplane بر روی ماشین های مجازی EC2 ساخته شده است. اینجا جادو نیست، فقط حیله گری است. ترفند این است که اینها ماشین های مجازی با رم بزرگ هستند. عملیات تراکنشی بوده و منحصراً در حافظه انجام می شود. این به شما اجازه می دهد تا به تاخیرهای تنها ده ها میکروثانیه برسید. کار با دیسک تمام بهره وری را از بین می برد. 

Hyperplane یک سیستم توزیع شده از تعداد زیادی از چنین ماشین های EC2 است. هر ماشین مجازی دارای پهنای باند 5 گیگابایت بر ثانیه است. در سراسر شبکه منطقه ای، این پهنای باند باورنکردنی را فراهم می کند و امکان پردازش را فراهم می کند. میلیون ها اتصال در ثانیه.

HyperPlane فقط با استریم ها کار می کند. کپسوله کردن بسته VPC برای آن کاملاً شفاف است. یک آسیب پذیری بالقوه در این سرویس داخلی همچنان از شکسته شدن جداسازی VPC جلوگیری می کند. سطوح زیر مسئول امنیت هستند.

همسایه پر سر و صدا

هنوز یه مشکلی هست همسایه پر سر و صدا - همسایه پر سر و صدا. فرض کنید 8 گره داریم. این گره ها جریان های همه کاربران ابر را پردازش می کنند. به نظر می رسد همه چیز خوب است و بار باید به طور مساوی در تمام گره ها توزیع شود. گره ها بسیار قدرتمند هستند و بارگذاری بیش از حد آنها دشوار است.

اما ما معماری خود را بر اساس سناریوهای حتی بعید می سازیم. 

احتمال کم به معنای غیرممکن نیست.

ما می توانیم موقعیتی را تصور کنیم که در آن یک یا چند کاربر بار زیادی تولید کنند. تمام گره های HyperPlane در پردازش این بار دخالت دارند و سایر کاربران به طور بالقوه می توانند نوعی ضربه عملکرد را تجربه کنند. این موضوع مفهوم ابر را که در آن مستاجران توانایی تأثیرگذاری بر یکدیگر را ندارند، می شکند.

چگونه مشکل همسایه پر سر و صدا را حل کنیم؟ اولین چیزی که به ذهن می رسد شاردینگ است. 8 گره ما به طور منطقی به 4 قطعه از 2 گره تقسیم می شوند. اکنون یک همسایه پر سر و صدا فقط یک چهارم کاربران را مزاحم می کند، اما آنها را به شدت مزاحم می کند.

بیایید کارها را متفاوت انجام دهیم. ما فقط 3 گره را به هر کاربر اختصاص خواهیم داد. 

ترفند این است که به طور تصادفی گره ها را به کاربران مختلف اختصاص دهید. در تصویر زیر، کاربر آبی گره ها را با یکی از دو کاربر دیگر - سبز و نارنجی قطع می کند.

با 8 گره و 3 کاربر، احتمال تقاطع همسایه پر سر و صدا با یکی از کاربران 54٪ است. با این احتمال است که یک کاربر آبی روی دیگر مستاجران تأثیر بگذارد. در عین حال، تنها بخشی از بار آن است. در مثال ما، این تأثیر حداقل به نحوی نه برای همه، بلکه برای یک سوم از همه کاربران قابل توجه است. این در حال حاضر یک نتیجه خوب است.

تعداد کاربرانی که متقاطع خواهند شد

احتمال بر حسب درصد

0

٪۱۰۰

1

٪۱۰۰

2

٪۱۰۰

3

2%

بیایید وضعیت را به واقعیت نزدیک کنیم - اجازه دهید 100 گره و 5 کاربر در 5 گره را در نظر بگیریم. در این حالت، هیچ یک از گره ها با احتمال 77 درصد تلاقی نمی کنند. 

تعداد کاربرانی که متقاطع خواهند شد

احتمال بر حسب درصد

0

٪۱۰۰

1

٪۱۰۰

2

٪۱۰۰

3

٪۱۰۰

4

٪۱۰۰

5

٪۱۰۰

در یک موقعیت واقعی، با تعداد زیادی گره و کاربران HyperPlane، تأثیر بالقوه یک همسایه پر سر و صدا بر سایر کاربران حداقل است. این روش نامیده می شود مخلوط کردن شاردینگ - مخلوط کردن شارد. این اثر منفی شکست گره را به حداقل می رساند.

بسیاری از خدمات بر اساس HyperPlane ساخته شده اند: Network Load Balancer، NAT Gateway، Amazon EFS، AWS PrivateLink، AWS Transit Gateway.

مقیاس شبکه

حالا بیایید در مورد مقیاس خود شبکه صحبت کنیم. برای اکتبر 2019 AWS خدمات خود را در این کشور ارائه می دهد 22 منطقهو 9 مورد دیگر برنامه ریزی شده است.

• هر منطقه شامل چندین منطقه در دسترس است. 69 مورد از آنها در سراسر جهان وجود دارد.
• هر AZ از مراکز پردازش داده تشکیل شده است. تعداد آنها بیشتر از 8 نفر نیست.
• این مرکز داده تعداد زیادی سرور را در خود جای داده است که برخی از آنها به 300 می رسد.

حالا بیایید همه اینها را میانگین کنیم، ضرب کنیم و یک رقم چشمگیر که منعکس کننده است به دست آوریم مقیاس ابری آمازون.

پیوندهای نوری زیادی بین Availability Zones و مرکز داده وجود دارد. در یکی از بزرگترین مناطق ما، 388 کانال فقط برای ارتباط AZ بین یکدیگر و مراکز ارتباطی با مناطق دیگر (مراکز حمل و نقل) گذاشته شده است. در کل این می دهد دیوانه 5000 ترابیت.

Backbone AWS به طور خاص برای ابر ساخته شده و برای آن بهینه شده است. ما آن را روی کانال ها می سازیم 100 گیگابایت بر ثانیه. ما آنها را کاملاً کنترل می کنیم، به استثنای مناطقی در چین. ترافیک با بارهای شرکت های دیگر مشترک نیست.

البته، ما تنها ارائه‌دهنده ابری نیستیم که یک شبکه اصلی خصوصی داریم. روز به روز شرکت های بزرگ بیشتری این مسیر را دنبال می کنند. این مورد توسط محققان مستقل، به عنوان مثال از تلجوگرافی.

نمودار نشان می دهد که سهم ارائه دهندگان محتوا و ارائه دهندگان ابری در حال افزایش است. به همین دلیل، سهم ترافیک اینترنت ارائه دهندگان ستون فقرات به طور مداوم در حال کاهش است.

توضیح می دهم که چرا این اتفاق می افتد. پیش از این، بیشتر خدمات وب مستقیماً از طریق اینترنت قابل دسترسی و مصرف بودند. امروزه سرورهای بیشتری در فضای ابری قرار دارند و از طریق آن قابل دسترسی هستند CDN - شبکه توزیع محتوا. برای دسترسی به یک منبع، کاربر فقط از طریق اینترنت به نزدیکترین CDN PoP می رود - نقطه حضور. اغلب در جایی نزدیک است. سپس اینترنت عمومی را ترک می کند و مثلاً از طریق یک ستون فقرات خصوصی در سراسر اقیانوس اطلس پرواز می کند و مستقیماً به منبع می رسد.

من تعجب می کنم که اگر این روند ادامه یابد، اینترنت در 10 سال آینده چگونه تغییر می کند؟

کانال های فیزیکی

دانشمندان هنوز به چگونگی افزایش سرعت نور در کیهان پی نبرده‌اند، اما در روش‌های انتقال نور از طریق فیبر نوری پیشرفت زیادی کرده‌اند. ما در حال حاضر از 6912 کابل فیبر استفاده می کنیم. این به بهینه سازی قابل توجه هزینه نصب آنها کمک می کند.

در برخی مناطق مجبوریم از کابل های مخصوص استفاده کنیم. به عنوان مثال، در منطقه سیدنی از کابل هایی با پوشش ویژه ضد موریانه استفاده می کنیم. 

هیچ کس از مشکلات مصون نیست و گاهی اوقات کانال های ما آسیب می بینند. عکس سمت راست کابل های نوری را در یکی از مناطق آمریکا نشان می دهد که توسط کارگران ساختمانی پاره شده است. در نتیجه این حادثه تنها 13 بسته داده از بین رفت که جای تعجب دارد. یک بار دیگر - فقط 13! سیستم به معنای واقعی کلمه بلافاصله به کانال های پشتیبان تبدیل شد - مقیاس کار می کند.

ما از طریق برخی از خدمات و فناوری‌های ابری آمازون گام برداشتیم. امیدوارم حداقل تصوری از مقیاس وظایفی که مهندسان ما باید حل کنند داشته باشید. من شخصا این را بسیار هیجان انگیز می دانم. 

این آخرین قسمت از سه گانه واسیلی پانتیوخین در مورد دستگاه AWS است. که در اول بخش ها بهینه سازی سرور و مقیاس بندی پایگاه داده را توصیف می کنند و در دوم - توابع بدون سرور و Firecracker.

بر HighLoad++ در ماه نوامبر واسیلی پانتیوخین جزئیات جدیدی از دستگاه آمازون را به اشتراک خواهد گذاشت. او خواهد گفت در مورد علل خرابی ها و طراحی سیستم های توزیع شده در آمازون. 24 اکتبر هنوز امکان پذیر است رزرو کردن بلیط با قیمت مناسب، و بعدا پرداخت کنید. ما در HighLoad++ منتظر شما هستیم، بیایید با هم چت کنیم!

منبع: www.habr.com