سلام، نام من Kostya Kramlikh است، من توسعه دهنده اصلی بخش Virtual Private Cloud در Yandex.Cloud هستم. من یک شبکهکننده مجازی هستم و همانطور که ممکن است حدس بزنید، در این مقاله درباره دستگاه ابر خصوصی مجازی (VPC) به طور کلی و شبکه مجازی به طور خاص صحبت خواهم کرد. و همچنین خواهید فهمید که چرا ما، توسعه دهندگان سرویس، به بازخورد کاربران خود ارزش قائل هستیم. اما اول از همه.
VPC چیست؟
امروزه گزینه های مختلفی برای استقرار سرویس ها وجود دارد. من مطمئن هستم که هنوز کسی سرور را زیر میز مدیر نگه می دارد، اگرچه امیدوارم چنین داستان هایی کمتر باشد.
اکنون سرویسها تلاش میکنند به ابرهای عمومی بروند و اینجاست که با VPCها برخورد میکنند. VPC بخشی از یک ابر عمومی است که کاربر، زیرساخت، پلتفرم و ظرفیتهای دیگر را در هر کجا که باشند، در فضای ابری ما یا خارج از آن، به یکدیگر متصل میکند. در عین حال، VPC به شما این امکان را می دهد که این ظرفیت ها را بی جهت در معرض اینترنت قرار ندهید، آنها در شبکه ایزوله شما باقی می مانند.
یک شبکه مجازی از بیرون چگونه به نظر می رسد؟
منظور ما از VPC در درجه اول یک شبکه پوششی و خدمات شبکه مانند VPNaaS، NATaas، LBaas و غیره است.
بیایید نگاهی دقیق تر به شبکه مجازی و دستگاه آن بیندازیم.
دو منطقه در دسترس را در نظر بگیرید. ما یک شبکه مجازی ارائه می دهیم - چیزی که VPC نامیده ایم. در واقع فضای منحصر به فرد بودن آدرس های "خاکستری" شما را مشخص می کند. در هر شبکه مجازی، شما کنترل کاملی بر فضای آدرس هایی دارید که می توانید برای محاسبه منابع اختصاص دهید.
شبکه جهانی است. در همان زمان، در هر یک از مناطق در دسترس به شکل موجودیتی به نام Subnet پیش بینی می شود. برای هر زیرشبکه، یک CIDR با اندازه 16 یا کمتر اختصاص می دهید. در هر منطقه در دسترس میتواند بیش از یک مورد از این قبیل وجود داشته باشد و همیشه مسیریابی شفافی بین آنها وجود دارد. این بدان معنی است که تمام منابع شما در یک VPC می توانند با یکدیگر "صحبت" کنند، حتی اگر در مناطق در دسترس بودن متفاوت باشند. "ارتباط" بدون دسترسی به اینترنت، از طریق کانال های داخلی ما، "فکر" که آنها در همان شبکه خصوصی هستند.
نمودار بالا یک وضعیت معمولی را نشان می دهد: دو VPC که در جایی در آدرس ها قطع می شوند. هر دو می توانند مال شما باشند. به عنوان مثال، یکی برای توسعه، دیگری برای آزمایش. ممکن است به سادگی کاربران مختلفی وجود داشته باشد - در این مورد مهم نیست. و یک ماشین مجازی به هر VPC متصل است.
بیایید این طرح را بدتر کنیم. شما می توانید آن را طوری بسازید که یک ماشین مجازی به طور همزمان در چندین Subnet گیر کند. و نه فقط همینطور، بلکه در شبکه های مجازی مختلف.
در عین حال، اگر نیاز دارید ماشینها را در معرض اینترنت قرار دهید، این کار را میتوان از طریق API یا UI انجام داد. برای انجام این کار، باید ترجمه NAT آدرس داخلی "خاکستری" خود را به "سفید" - عمومی پیکربندی کنید. شما نمی توانید یک آدرس "سفید" انتخاب کنید، این آدرس به طور تصادفی از مجموعه آدرس های ما اختصاص داده می شود. به محض اینکه استفاده از IP خارجی را متوقف کنید، به استخر بازگردانده می شود. شما فقط برای زمان استفاده از آدرس "سفید" پرداخت می کنید.
همچنین امکان دسترسی دستگاه به اینترنت با استفاده از نمونه NAT وجود دارد. شما می توانید ترافیک را از طریق یک جدول مسیریابی ثابت به یک نمونه هدایت کنید. ما چنین موردی را ارائه کرده ایم، زیرا کاربران گاهی اوقات به آن نیاز دارند و ما از آن اطلاع داریم. بر این اساس، کاتالوگ تصویر ما حاوی یک تصویر NAT با پیکربندی خاص است.
اما حتی زمانی که یک تصویر NAT آماده وجود دارد، تنظیم می تواند مشکل باشد. ما فهمیدیم که برای برخی از کاربران این راحتترین گزینه نیست، بنابراین در پایان امکان فعال کردن NAT را برای زیرشبکه مورد نظر با یک کلیک فراهم کردیم. این ویژگی هنوز در دسترسی پیشنمایش بسته است، جایی که با کمک اعضای انجمن آزمایش میشود.
نحوه چیدمان شبکه مجازی از داخل
تعامل کاربر با شبکه مجازی چگونه است؟ وب با API خود به بیرون به نظر می رسد. کاربر به API می آید و با حالت هدف کار می کند. از طریق API، کاربر می بیند که چگونه همه چیز باید مرتب و پیکربندی شود، در حالی که وضعیت را می بیند، وضعیت واقعی چقدر با حالت مورد نظر متفاوت است. این عکس کاربر است. در داخل چه خبر است؟
حالت مورد نظر را در پایگاه داده Yandex می نویسیم و به پیکربندی قسمت های مختلف VPC خود می رویم. شبکه همپوشانی در Yandex.Cloud بر اساس اجزای منتخب OpenContrail است که اخیراً Fabric تنگستن نامیده شده است. خدمات شبکه بر روی یک پلتفرم کلود گیت پیاده سازی می شوند. در CloudGate، ما همچنین از تعدادی مؤلفه منبع باز استفاده کردیم: GoBGP - برای دسترسی به اطلاعات کنترل، و همچنین VPP - برای پیاده سازی یک روتر نرم افزاری که در بالای DPDK برای مسیر داده اجرا می شود.
Fabric تنگستن از طریق GoBGP با CloudGate ارتباط برقرار می کند. می گوید در شبکه همپوشانی چه می گذرد. CloudGate به نوبه خود، شبکه های همپوشانی را با یکدیگر و به اینترنت متصل می کند.
حال بیایید ببینیم که چگونه یک شبکه مجازی مشکلات مقیاس پذیری و در دسترس بودن را حل می کند. بیایید یک مورد ساده را در نظر بگیریم. یک منطقه در دسترس وجود دارد و دو VPC در آن ایجاد می شود. ما یک نمونه از پارچه تنگستن را مستقر کردیم و چندین ده هزار شبکه را می کشاند. شبکه ها با CloudGate ارتباط برقرار می کنند. همانطور که قبلاً گفتیم CloudGate اتصال آنها را با یکدیگر و با اینترنت تضمین می کند.
فرض کنید دومین منطقه در دسترس اضافه شده است. باید کاملا مستقل از اولی شکست بخورد. بنابراین، در دومین منطقه در دسترس، باید یک نمونه پارچه تنگستن جداگانه نصب کنیم. این یک سیستم جداگانه خواهد بود که با همپوشانی سروکار دارد و اطلاعات کمی در مورد سیستم اول دارد. و مشاهده جهانی بودن شبکه مجازی ما، در واقع VPC API ما را ایجاد می کند. این وظیفه اوست.
اگر منابعی در منطقه دسترسی B وجود داشته باشند که به VPC1 فشار داده شده باشند، VPC1 به منطقه دسترسی B نگاشت می شود. اگر هیچ منبعی از VPC2 در منطقه دسترسی B وجود نداشته باشد، VPC2 را در این منطقه محقق نمی کنیم. به نوبه خود، از آنجایی که منابع VPC3 فقط در منطقه B وجود دارد، VPC3 در منطقه A وجود ندارد. همه چیز ساده و منطقی است.
بیایید کمی عمیق تر برویم و ببینیم یک میزبان خاص در Y.Cloud چگونه کار می کند. نکته اصلی که می خواهم به آن توجه کنم این است که همه هاست ها به یک شکل چیده شده اند. ما آن را طوری انجام می دهیم که فقط حداقل خدمات لازم روی سخت افزار اجرا شود و بقیه روی ماشین های مجازی اجرا شوند. ما خدمات مرتبه بالاتری را بر اساس خدمات زیرساخت اولیه ایجاد می کنیم و همچنین از Cloud برای حل برخی از مشکلات مهندسی، به عنوان مثال، در چارچوب Continuous Integration استفاده می کنیم.
اگر به یک هاست خاص نگاه کنیم، می بینیم که سه جزء در سیستم عامل میزبان در حال اجرا هستند:
- محاسبه - بخشی که مسئول توزیع منابع محاسباتی در میزبان است.
- VRouter بخشی از پارچه تنگستن است که یک پوشش را سازماندهی می کند، یعنی بسته ها را از طریق لایه زیرین تونل می کند.
- VDisks تکه های مجازی سازی ذخیره سازی هستند.
علاوه بر این، خدمات در ماشین های مجازی راه اندازی می شوند: خدمات زیرساخت ابری، خدمات پلت فرم و ظرفیت های مشتری. ظرفیتهای مشتری و خدمات پلتفرم همیشه از طریق VRouter به همپوشانی میرود.
سرویسهای زیرساخت میتوانند به روی همپوشانی بچسبند، اما اساساً آنها میخواهند در لایه زیرین کار کنند. آنها با کمک SR-IOV به زیر لایه چسبانده می شوند. در واقع، ما کارت را به کارت های شبکه مجازی (توابع مجازی) برش می دهیم و آنها را به ماشین های مجازی زیرساخت فشار می دهیم تا عملکرد خود را از دست ندهیم. به عنوان مثال، همان CloudGate به عنوان یکی از این ماشین های مجازی زیرساخت راه اندازی می شود.
اکنون که وظایف جهانی شبکه مجازی و ساختار اجزای اساسی ابر را شرح دادیم، بیایید ببینیم که دقیقاً چگونه قسمت های مختلف شبکه مجازی با یکدیگر تعامل دارند.
ما سه لایه را در سیستم خود تشخیص می دهیم:
- Config Plane - وضعیت هدف سیستم را تنظیم می کند. این همان چیزی است که کاربر از طریق API پیکربندی می کند.
- صفحه کنترل - معنایی تعریف شده توسط کاربر را ارائه می دهد، یعنی وضعیت صفحه داده را به آنچه توسط کاربر در صفحه پیکربندی توصیف شده است، می رساند.
- Data Plane - به طور مستقیم بسته های کاربر را پردازش می کند.
همانطور که در بالا گفتم، همه چیز با این واقعیت شروع می شود که کاربر یا سرویس پلت فرم داخلی به API می آید و وضعیت هدف خاصی را توصیف می کند.
این حالت بلافاصله در پایگاه داده Yandex نوشته میشود، شناسه عملیات ناهمزمان را از طریق API برمیگرداند، و ماشینهای داخلی ما را برای بازگرداندن حالت مورد نظر کاربر راهاندازی میکند. کارهای پیکربندی به کنترلکننده SDN میروند و به Tungsten Fabric میگویند که در پوشش چه کاری انجام دهد. مثلا پورت ها، شبکه های مجازی و مواردی از این دست را رزرو می کنند.
Config Plane در پارچه تنگستن حالت مورد نیاز را به صفحه کنترل ارسال می کند. از طریق آن، Config Plane با میزبان ها ارتباط برقرار می کند و می گوید به زودی دقیقاً چه چیزی روی آنها می چرخد.
حال بیایید ببینیم که سیستم در هاست چگونه به نظر می رسد. ماشین مجازی یک آداپتور شبکه دارد که به VRouter وصل شده است. VRouter یک ماژول هسته تنگستن فابریک است که به بسته ها نگاه می کند. اگر در حال حاضر جریانی برای برخی از بسته ها وجود داشته باشد، ماژول آن را پردازش می کند. اگر جریانی وجود نداشته باشد، ماژول به اصطلاح punting را انجام می دهد، یعنی یک بسته را به فرآیند usermod ارسال می کند. این فرآیند بسته را تجزیه می کند و یا خودش به آن پاسخ می دهد، مانند DHCP و DNS، یا به VRouter می گوید که با آن چه کاری انجام دهد. پس از آن، VRouter می تواند بسته را پردازش کند.
علاوه بر این، ترافیک بین ماشینهای مجازی در همان شبکه مجازی به صورت شفاف انجام میشود و به CloudGate هدایت نمیشود. هاست هایی که ماشین های مجازی روی آنها مستقر شده اند مستقیما با یکدیگر ارتباط برقرار می کنند. آنها ترافیک را تونل می کنند و آن را از طریق زیرانداز برای یکدیگر ارسال می کنند.
هواپیماهای کنترلی مانند مسیریاب دیگری بین مناطق در دسترس از طریق BGP با یکدیگر ارتباط برقرار می کنند. آنها می گویند کدام ماشین ها در کجا قرار دارند تا ماشین های مجازی در یک منطقه بتوانند مستقیما با ماشین های مجازی دیگر ارتباط برقرار کنند.
و Control Plane با CloudGate ارتباط برقرار می کند. به طور مشابه، گزارش می دهد که کجا و کدام ماشین های مجازی تولید شده اند، چه آدرس هایی دارند. این به شما امکان می دهد تا ترافیک خارجی و ترافیک را از متعادل کننده ها به آنها هدایت کنید.
ترافیکی که از VPC خارج می شود به CloudGate می رسد، به مسیر داده، جایی که VPP با افزونه های ما به سرعت جویده می شود. سپس ترافیک یا به VPC های دیگر یا خارج از آن، به مسیریاب های مرزی که از طریق صفحه کنترل خود CloudGate پیکربندی شده اند، شلیک می شود.
برنامه هایی برای آینده نزدیک
اگر همه موارد گفته شده در بالا را در چند جمله خلاصه کنیم، می توان گفت که VPC در Yandex.Cloud دو کار مهم را حل می کند:
- انزوا را بین مشتریان مختلف فراهم می کند.
- منابع، زیرساخت ها، خدمات پلتفرم، دیگر ابرها و در محل را در یک شبکه واحد ترکیب می کند.
و برای اینکه این مشکلات را به خوبی حل کنید، باید مقیاس پذیری و تحمل خطا را در سطح معماری داخلی ارائه دهید، که VPC انجام می دهد.
به تدریج VPC عملکردهایی را به دست می آورد، ما ویژگی های جدیدی را پیاده سازی می کنیم، سعی می کنیم چیزی را از نظر راحتی کاربر بهبود دهیم. برخی از ایده ها به لطف اعضای جامعه ما بیان شده و در لیست اولویت قرار می گیرند.
ما در حال حاضر لیست برنامه های زیر را برای آینده نزدیک داریم:
- VPN به عنوان یک سرویس
- نمونههای DNS خصوصی تصاویری برای راهاندازی سریع ماشینهای مجازی با یک سرور DNS از پیش پیکربندی شده هستند.
- DNS به عنوان یک سرویس
- متعادل کننده بار داخلی
- اضافه کردن یک آدرس IP "سفید" بدون ایجاد مجدد ماشین مجازی.
متعادل کننده و قابلیت تغییر آدرس IP برای یک ماشین مجازی از قبل ایجاد شده در این لیست به درخواست کاربران بود. صادقانه بگویم، بدون بازخورد صریح، کمی دیرتر این کارکردها را به عهده می گرفتیم. و بنابراین ما در حال حاضر روی مشکل آدرس ها کار می کنیم.
در ابتدا، یک آدرس IP "سفید" فقط هنگام ایجاد یک ماشین می توانست اضافه شود. اگر کاربر فراموش می کرد این کار را انجام دهد، ماشین مجازی باید دوباره ایجاد می شد. به همین صورت و در صورت لزوم آی پی خارجی را حذف کنید. به زودی روشن و خاموش کردن IP عمومی بدون نیاز به ایجاد مجدد دستگاه امکان پذیر خواهد بود.
با خیال راحت حرف خود را بیان کنید
منبع: www.habr.com