مقدمه ای بر بخش شبکه زیرساخت ابری

رایانش ابری عمیق‌تر و عمیق‌تر به زندگی ما نفوذ می‌کند و احتمالاً حتی یک نفر نیست که حداقل یک بار از هیچ سرویس ابری استفاده نکرده باشد. با این حال، اینکه یک ابر دقیقاً چیست و چگونه کار می کند، افراد کمی حتی در سطح یک ایده می دانند. 5G در حال حاضر در حال تبدیل شدن به واقعیت است و زیرساخت های مخابراتی شروع به حرکت از راه حل های ستونی به راه حل های ابری کرده است، درست مانند زمانی که از راه حل های کاملا سخت افزاری به "ستون های مجازی" منتقل شد.

امروز ما در مورد دنیای درونی زیرساخت ابری صحبت خواهیم کرد، به ویژه ما به اصول اولیه بخش شبکه نگاه خواهیم کرد.

ابر چیست؟ همون مجازی سازی - نمای پروفایل؟

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

رایانش ابری (از این پس ابر نامیده می شود) مدلی برای ارائه دسترسی کاربر پسند به منابع محاسباتی توزیع شده است که باید در صورت تقاضا با کمترین تأخیر ممکن و حداقل هزینه برای ارائه دهنده خدمات مستقر و راه اندازی شود.

مجازی سازی - این توانایی تقسیم یک موجودیت فیزیکی (به عنوان مثال، یک سرور) به چندین مورد مجازی است، در نتیجه استفاده از منابع افزایش می یابد (به عنوان مثال، شما 3 سرور را با 25-30 درصد بارگذاری کرده اید، پس از مجازی سازی، 1 سرور بارگیری می شود. در 80-90 درصد). به طور طبیعی، مجازی سازی برخی از منابع را می خورد - شما باید هایپروایزر را تغذیه کنید، با این حال، همانطور که تمرین نشان داده است، بازی ارزش شمع را دارد. نمونه ایده آل مجازی سازی VMWare است که ماشین های مجازی را به طور کامل آماده می کند یا مثلا KVM که من ترجیح می دهم، اما این یک سلیقه است.

ما بدون اینکه متوجه باشیم از مجازی سازی استفاده می کنیم و حتی روترهای آهنی هم از مجازی سازی استفاده می کنند - به عنوان مثال، در آخرین نسخه JunOS، سیستم عامل به عنوان یک ماشین مجازی در بالای یک توزیع بلادرنگ لینوکس (Wind River 9) نصب می شود. اما مجازی سازی ابر نیست، اما ابر بدون مجازی سازی نمی تواند وجود داشته باشد.

مجازی سازی یکی از بلوک های ساختمانی است که ابر بر روی آن ساخته شده است.

ساختن یک ابر با جمع آوری چند Hypervisor در یک دامنه L2، افزودن چند کتاب yaml برای ثبت خودکار vlan ها از طریق نوعی ansible و پارازیت چیزی مانند یک سیستم ارکستراسیون روی همه آن برای ایجاد خودکار ماشین های مجازی کار نخواهد کرد. دقیق‌تر خواهد بود، اما فرانکشتاین حاصل، ابری نیست که ما به آن نیاز داریم، اگرچه ممکن است رویای نهایی برای دیگران باشد. علاوه بر این، اگر همان Openstack را انتخاب کنید، اساساً هنوز فرانکشتاین است، اما خب، اجازه دهید فعلا در مورد آن صحبت نکنیم.

اما من درک می کنم که از تعریف ارائه شده در بالا کاملاً مشخص نیست که در واقع چه چیزی را می توان ابر نامید.

بنابراین، یک سند از NIST (موسسه ملی استاندارد و فناوری) 5 ویژگی اصلی را ارائه می دهد که یک زیرساخت ابری باید داشته باشد:

ارائه خدمات در صورت درخواست کاربر باید به منابع رایانه ای که به او اختصاص داده شده است (مانند شبکه ها، دیسک های مجازی، حافظه، هسته های پردازنده و غیره) دسترسی آزاد داشته باشد و این منابع باید به طور خودکار - یعنی بدون دخالت ارائه دهنده خدمات - ارائه شوند.

در دسترس بودن گسترده خدمات. دسترسی به منابع باید با مکانیسم های استانداردی فراهم شود تا امکان استفاده از رایانه های شخصی استاندارد و تین کلاینت ها و دستگاه های تلفن همراه فراهم شود.

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

سازگاری سریع با شرایط مختلف خدمات باید انعطاف پذیر باشند - ارائه سریع منابع، توزیع مجدد آنها، افزودن یا کاهش منابع به درخواست مشتری، و از طرف مشتری باید این احساس وجود داشته باشد که منابع ابری بی پایان هستند. به عنوان مثال، برای سهولت درک، هشداری مبنی بر اینکه بخشی از فضای دیسک شما در Apple iCloud ناپدید شده است، نمی بینید زیرا هارد درایو سرور خراب شده است و درایوها خراب می شوند. علاوه بر این، از طرف شما، امکانات این سرویس تقریبا نامحدود است - شما به 2 ترابایت نیاز دارید - مشکلی نیست، شما آن را پرداخت کردید و دریافت کردید. مثال مشابهی را می توان با Google.Drive یا Yandex.Disk ارائه داد.

امکان اندازه گیری خدمات ارائه شده. سیستم های ابری باید به طور خودکار منابع مصرف شده را کنترل و بهینه کنند و این مکانیسم ها باید هم برای کاربر و هم برای ارائه دهنده خدمات شفاف باشد. یعنی همیشه می توانید بررسی کنید که شما و مشتریانتان چه تعداد منابع را مصرف می کنید.

شایان ذکر است که این الزامات بیشتر الزامات یک ابر عمومی هستند، بنابراین برای یک ابر خصوصی (یعنی ابری که برای نیازهای داخلی شرکت راه اندازی شده است) این الزامات می تواند کمی تنظیم شود. با این حال، آنها هنوز باید انجام شوند، در غیر این صورت ما تمام مزایای رایانش ابری را نخواهیم داشت.

چرا به ابر نیاز داریم؟

با این حال، هر فناوری جدید یا موجود، هر پروتکل جدیدی برای چیزی ایجاد می شود (البته به جز RIP-ng). هیچ کس به خاطر یک پروتکل به پروتکل نیاز ندارد (البته به جز RIP-ng). منطقی است که Cloud برای ارائه نوعی خدمات به کاربر/مشتری ایجاد شود. همه ما حداقل با چند سرویس ابری آشنا هستیم، به عنوان مثال Dropbox یا Google.Docs، و معتقدم اکثر مردم با موفقیت از آنها استفاده می کنند - برای مثال، این مقاله با استفاده از سرویس ابری Google.Docs نوشته شده است. اما سرویس‌های ابری که ما می‌دانیم، تنها بخشی از قابلیت‌های ابر هستند - به‌طور دقیق‌تر، آنها فقط یک سرویس از نوع SaaS هستند. ما می توانیم یک سرویس ابری را به سه روش ارائه دهیم: به شکل SaaS، PaaS یا IaaS. اینکه چه خدماتی نیاز دارید بستگی به خواسته ها و توانایی های شما دارد.

بیایید به ترتیب به هر یک نگاه کنیم:

نرم افزار به عنوان یک سرویس (SaaS) مدلی برای ارائه یک سرویس تمام عیار به مشتری است، به عنوان مثال، یک سرویس ایمیل مانند Yandex.Mail یا Gmail. در این مدل ارائه خدمات، شما به عنوان یک مشتری، در واقع هیچ کاری جز استفاده از خدمات انجام نمی دهید - یعنی نیازی نیست به راه اندازی سرویس، تحمل خطا یا افزونگی آن فکر کنید. نکته اصلی این است که رمز عبور خود را به خطر نیاندازید، ارائه دهنده این سرویس بقیه کارها را برای شما انجام خواهد داد. از نقطه نظر ارائه دهنده خدمات، او مسئولیت کامل کل سرویس را بر عهده دارد - از سخت افزار سرور و سیستم عامل میزبان گرفته تا تنظیمات پایگاه داده و نرم افزار.

بستر به عنوان یک سرویس (PaaS) - هنگام استفاده از این مدل، ارائه‌دهنده خدمات یک قطعه کار برای سرویس به مشتری ارائه می‌کند، به عنوان مثال، اجازه دهید یک وب سرور را در نظر بگیریم. ارائه دهنده سرویس یک سرور مجازی (در واقع مجموعه ای از منابع مانند RAM/CPU/Storage/Nets و غیره) در اختیار مشتری قرار داده و حتی سیستم عامل و نرم افزارهای لازم را بر روی این سرور نصب کرده است، با این حال، پیکربندی همه این کارها توسط خود مشتری انجام می شود و برای انجام خدمات مشتری پاسخ می دهد. ارائه دهنده خدمات، مانند مورد قبلی، مسئولیت عملکرد تجهیزات فیزیکی، هایپروایزر، خود ماشین مجازی، در دسترس بودن شبکه و غیره را بر عهده دارد، اما خود سرویس دیگر در حیطه مسئولیت خود نیست.

زیرساخت به عنوان یک سرویس (IaaS) - این رویکرد در حال حاضر جالب تر است، در واقع، ارائه دهنده خدمات یک زیرساخت مجازی کامل را به مشتری ارائه می دهد - یعنی مجموعه ای (پول) از منابع، مانند هسته های CPU، RAM، شبکه ها و غیره. مشتری - کاری که مشتری می خواهد با این منابع در محدوده اختصاص داده شده (سهمیه) انجام دهد - برای تامین کننده اهمیت خاصی ندارد. چه مشتری بخواهد vEPC خود را ایجاد کند یا حتی یک اپراتور کوچک ایجاد کند و خدمات ارتباطی ارائه دهد - بدون شک - این کار را انجام دهید. در چنین سناریویی، ارائه‌دهنده خدمات مسئول تأمین منابع، تحمل خطا و در دسترس بودن آنها و همچنین سیستم‌عاملی است که به آنها اجازه می‌دهد این منابع را جمع کرده و با قابلیت افزایش یا کاهش منابع در هر زمان در دسترس مشتری قرار دهند. به درخواست مشتری کلاینت تمام ماشین های مجازی و سایر قلاب ها را خودش از طریق پورتال و کنسول سلف سرویس، از جمله راه اندازی شبکه ها (به جز شبکه های خارجی) پیکربندی می کند.

OpenStack چیست؟

در هر سه گزینه، ارائه دهنده خدمات به یک سیستم عامل نیاز دارد که ایجاد یک زیرساخت ابری را امکان پذیر کند. در واقع، با SaaS، بیش از یک بخش مسئولیت کل پشته فناوری ها را بر عهده دارد - یک بخش وجود دارد که مسئول زیرساخت است - یعنی IaaS را به بخش دیگری ارائه می دهد، این بخش SaaS را به مشتری ارائه می دهد. OpenStack یکی از سیستم‌عامل‌های ابری است که به شما امکان می‌دهد دسته‌ای از سوئیچ‌ها، سرورها و سیستم‌های ذخیره‌سازی را در یک منبع واحد جمع‌آوری کنید، این استخر مشترک را به زیرپول‌ها (مستاجر) تقسیم کنید و این منابع را از طریق شبکه در اختیار مشتریان قرار دهید.

OpenStack یک سیستم عامل ابری است که به شما امکان می دهد مجموعه های بزرگی از منابع محاسباتی، ذخیره سازی داده ها و منابع شبکه را کنترل کنید که از طریق API با استفاده از مکانیزم های احراز هویت استاندارد تهیه و مدیریت می شوند.

به عبارت دیگر، این مجموعه ای از پروژه های نرم افزار رایگان است که برای ایجاد سرویس های ابری (هم عمومی و هم خصوصی) طراحی شده است - یعنی مجموعه ای از ابزارهایی که به شما امکان می دهد سرور و تجهیزات سوئیچینگ را در یک استخر واحد از منابع ترکیب کنید، مدیریت کنید. این منابع، سطح لازم از تحمل خطا را فراهم می کند.

در زمان نوشتن این مطالب، ساختار OpenStack به این صورت است:

عکس گرفته شده از openstack.org

هر یک از اجزای موجود در OpenStack عملکرد خاصی را انجام می دهد. این معماری توزیع شده به شما امکان می دهد مجموعه ای از اجزای عملکردی مورد نیاز خود را در راه حل قرار دهید. با این حال، برخی از اجزاء اجزای ریشه هستند و حذف آنها منجر به عدم کارکرد کامل یا جزئی محلول در کل می شود. این اجزا معمولاً به صورت زیر طبقه بندی می شوند:

• داشبورد - رابط کاربری گرافیکی مبتنی بر وب برای مدیریت خدمات OpenStack
• سنگ سراطاق یک سرویس هویت متمرکز است که قابلیت احراز هویت و مجوز برای سایر سرویس‌ها و همچنین مدیریت اعتبار کاربر و نقش‌های آنها را فراهم می‌کند.
• نوترون - یک سرویس شبکه ای که اتصال بین رابط های سرویس های مختلف OpenStack (از جمله اتصال بین ماشین های مجازی و دسترسی آنها به دنیای خارج) را فراهم می کند.
• سیلر - دسترسی به ذخیره سازی مسدود برای ماشین های مجازی را فراهم می کند
• نو اختر - مدیریت چرخه زندگی ماشین های مجازی
• نگاه - مخزن تصاویر و عکس های فوری ماشین مجازی
• سریع - دسترسی به شی ذخیره سازی را فراهم می کند
• سقف - سرویسی که توانایی جمع آوری تله متری و اندازه گیری منابع موجود و مصرف شده را فراهم می کند
• حرارت - ارکستراسیون بر اساس الگوهایی برای ایجاد و تهیه خودکار منابع

لیست کامل همه پروژه ها و هدف آنها قابل مشاهده است اینجا.

هر جزء OpenStack سرویسی است که عملکرد خاصی را انجام می دهد و یک API برای مدیریت آن عملکرد و تعامل با سایر سرویس های سیستم عامل ابری برای ایجاد یک زیرساخت یکپارچه ارائه می دهد. به عنوان مثال، Nova مدیریت منابع محاسباتی و یک API برای دسترسی به پیکربندی این منابع ارائه می دهد، Glance مدیریت تصویر و یک API برای مدیریت آنها، Cinder ذخیره سازی بلوک و یک API برای مدیریت آن و غیره ارائه می دهد. همه عملکردها به روشی بسیار نزدیک به هم مرتبط هستند.

با این حال، اگر به آن نگاه کنید، تمام سرویس‌های در حال اجرا در OpenStack در نهایت نوعی ماشین مجازی (یا کانتینر) متصل به شبکه هستند. این سوال مطرح می شود - چرا ما به این همه عناصر نیاز داریم؟

بیایید الگوریتم ایجاد یک ماشین مجازی و اتصال آن به شبکه و ذخیره سازی مداوم در Openstack را مرور کنیم.

1. وقتی درخواستی برای ایجاد ماشین ایجاد می‌کنید، چه درخواستی از طریق Horizon (داشبورد) یا درخواستی از طریق CLI، اولین چیزی که اتفاق می‌افتد مجوز درخواست شما در Keystone است - آیا می‌توانید یک ماشین ایجاد کنید، آیا آن را دارد حق استفاده از این شبکه، سهمیه پیش نویس شما و غیره را انجام می دهد.
2. Keystone درخواست شما را احراز هویت می کند و یک نشانه تأیید اعتبار در پیام پاسخ ایجاد می کند که بیشتر مورد استفاده قرار می گیرد. پس از دریافت پاسخ از Keystone، درخواست به Nova (nova api) ارسال می شود.
3. Nova-api اعتبار درخواست شما را با تماس با کیستون با استفاده از توکن تاییدیه قبلی ایجاد شده بررسی می کند.
4. Keystone احراز هویت را انجام می دهد و اطلاعاتی در مورد مجوزها و محدودیت ها بر اساس این توکن احراز هویت ارائه می دهد.
5. Nova-api یک ورودی برای VM جدید در nova-database ایجاد می کند و درخواست ایجاد ماشین را به nova-scheduler ارسال می کند.
6. Nova-scheduler میزبان (گره کامپیوتری) که ماشین مجازی روی آن مستقر می شود را بر اساس پارامترها، وزن ها و مناطق مشخص شده انتخاب می کند. یک رکورد از این و VM ID در پایگاه داده nova نوشته می شود.
7. در مرحله بعد، nova-scheduler با nova-compute با درخواست استقرار یک نمونه تماس می گیرد. Nova-compute با nova-conductor تماس می گیرد تا اطلاعات مربوط به پارامترهای ماشین را به دست آورد (nova-conductor یک عنصر nova است که به عنوان یک سرور پراکسی بین nova-database و nova-compute عمل می کند و تعداد درخواست ها را به nova-database محدود می کند تا از مشکلات با پایگاه داده جلوگیری کند. کاهش بار قوام).
8. Nova-conductor اطلاعات درخواستی را از nova-database دریافت کرده و آن را به nova-compute ارسال می کند.
9. در مرحله بعد، نوا-کامپیوتر برای به دست آوردن شناسه تصویر نگاهی به فراخوانی می اندازد. Glace درخواست را در Keystone تأیید می کند و اطلاعات درخواستی را برمی گرداند.
10. Nova-Computes نوترون تماس برای به دست آوردن اطلاعات در مورد پارامترهای شبکه. نوترون مانند یک نگاه، درخواست را در Keystone تایید می کند، پس از آن یک ورودی در پایگاه داده (شناسه پورت و غیره) ایجاد می کند، یک درخواست برای ایجاد یک پورت ایجاد می کند و اطلاعات درخواستی را به nova-compute برمی گرداند.
11. Nova-compute مخاطبین با درخواست تخصیص یک حجم به ماشین مجازی سیلندر می شوند. سیدر مانند یک نگاه، درخواست را در Keystone تأیید می کند، یک درخواست ایجاد حجم ایجاد می کند و اطلاعات درخواستی را برمی گرداند.
12. Nova-compute مخاطبین libvirt با درخواست استقرار یک ماشین مجازی با پارامترهای مشخص شده.

در واقع، عملیات به ظاهر ساده ایجاد یک ماشین مجازی ساده به گردابی از فراخوانی های API بین عناصر پلت فرم ابری تبدیل می شود. علاوه بر این، همانطور که می بینید، حتی سرویس های تعیین شده قبلی نیز از اجزای کوچکتری تشکیل شده اند که بین آنها تعامل رخ می دهد. ایجاد یک ماشین تنها بخش کوچکی از کاری است که پلتفرم ابری به شما اجازه می دهد انجام دهید - یک سرویس مسئول متعادل کردن ترافیک، یک سرویس مسئول ذخیره سازی بلوک، یک سرویس مسئول DNS، یک سرویس مسئول تهیه سرورهای فلزی خالی و غیره وجود دارد. ابر به شما این امکان را می دهد که با ماشین های مجازی خود مانند یک گله گوسفند رفتار کنید (برخلاف مجازی سازی). اگر اتفاقی برای دستگاه شما در یک محیط مجازی بیفتد - آن را از پشتیبان گیری و غیره بازیابی می کنید، اما برنامه های ابری به گونه ای ساخته شده اند که ماشین مجازی نقش مهمی را ایفا نمی کند - ماشین مجازی "مرده" - مشکلی نیست - یک وسیله نقلیه جدید به سادگی ایجاد می شود ، وسیله نقلیه بر اساس الگو است و همانطور که می گویند ، تیم متوجه از دست دادن جنگنده نشد. به طور طبیعی، این امکان وجود مکانیسم های ارکستراسیون را فراهم می کند - با استفاده از قالب های Heat، می توانید به راحتی یک عملکرد پیچیده متشکل از ده ها شبکه و ماشین های مجازی را مستقر کنید.

همیشه ارزش این را دارد که در نظر داشته باشید که هیچ زیرساخت ابری بدون شبکه وجود ندارد - هر عنصر از طریق شبکه با عناصر دیگر در تعامل است. علاوه بر این، ابر دارای یک شبکه کاملا غیر ایستا است. به طور طبیعی، شبکه زیر لایه حتی کم و بیش ثابت است - گره ها و سوئیچ های جدید هر روز اضافه نمی شوند، اما مولفه همپوشانی به طور اجتناب ناپذیری می تواند تغییر کند و تغییر خواهد کرد - شبکه های جدید اضافه یا حذف خواهند شد، ماشین های مجازی جدید ظاهر می شوند و شبکه های قدیمی ظاهر می شوند. بمیر و همانطور که از تعریف ابر ارائه شده در همان ابتدای مقاله به یاد دارید، منابع باید به طور خودکار و با کمترین (یا بهتر بگوییم، بدون) مداخله ارائه دهنده خدمات به کاربر تخصیص داده شود. یعنی نوع ارائه منابع شبکه که اکنون به صورت فرانت اند در قالب حساب شخصی شما قابل دسترسی از طریق http/https و مهندس شبکه حین کار واسیلی به عنوان باطن وجود دارد، حتی یک ابر نیست. اگر واسیلی هشت دست داشته باشد.

نوترون، به عنوان یک سرویس شبکه، یک API برای مدیریت بخش شبکه زیرساخت ابری ارائه می دهد. این سرویس بخش شبکه Openstack را با ارائه یک لایه انتزاعی به نام Network-as-a-Service (NaaS) نیرو می دهد و مدیریت می کند. یعنی شبکه همان واحد مجازی قابل اندازه گیری است که مثلاً هسته های CPU مجازی یا مقدار رم.

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

بنابراین ما دو VM مشتری RED و دو VM مشتری GREEN داریم. بیایید فرض کنیم که این ماشین ها بر روی دو Hypervisor به این صورت قرار دارند:

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

برای ساختن یک ابر، باید چندین جزء اضافه کنیم. ابتدا قسمت شبکه را مجازی می کنیم - باید این 4 ماشین را به صورت جفت به هم وصل کنیم و کلاینت ها یک اتصال L2 می خواهند. می توانید از یک سوئیچ استفاده کنید و یک ترانک را در جهت آن پیکربندی کنید و همه چیز را با استفاده از یک پل لینوکس یا برای کاربران پیشرفته تر، openvswitch حل کنید (ما بعداً به این موضوع باز خواهیم گشت). اما ممکن است شبکه های زیادی وجود داشته باشد و فشار دادن مداوم L2 از طریق سوئیچ بهترین ایده نیست - بخش های مختلف، یک میز خدمات، ماه ها انتظار برای تکمیل یک برنامه، هفته ها عیب یابی وجود دارد - در دنیای مدرن این رویکرد دیگر کار نمی کند و هر چه یک شرکت زودتر این را بفهمد، حرکت رو به جلو برایش آسان تر است. بنابراین، بین هایپروایزرها یک شبکه L3 را انتخاب می کنیم که ماشین های مجازی ما از طریق آن ارتباط برقرار می کنند و در بالای این شبکه L3، شبکه های پوشش مجازی L2 را می سازیم که ترافیک ماشین های مجازی ما در آنجا اجرا می شود. می توانید از GRE، Geneve یا VxLAN به عنوان کپسوله استفاده کنید. بیایید فعلاً روی دومی تمرکز کنیم، اگرچه اهمیت خاصی ندارد.

ما باید VTEP را در جایی پیدا کنیم (امیدوارم همه با اصطلاحات VxLAN آشنا باشند). از آنجایی که ما یک شبکه L3 داریم که مستقیماً از سرورها می آید، هیچ چیز مانع از قرار دادن VTEP روی خود سرورها نمی شود و OVS (OpenvSwitch) در انجام این کار عالی است. در نتیجه، این طرح را دریافت کردیم:

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

اکنون می توانیم ماشین ها و شبکه های مجازی خود را بدون هیچ مشکلی برای آنها ایجاد کنیم.

با این حال، اگر مشتری ماشین دیگری داشته باشد، اما در شبکه دیگری باشد، چه؟ ما به روت کردن بین شبکه ها نیاز داریم. هنگامی که از مسیریابی متمرکز استفاده می شود، به یک گزینه ساده نگاه خواهیم کرد - یعنی ترافیک از طریق گره های شبکه اختصاصی ویژه هدایت می شود (خوب، به عنوان یک قاعده، آنها با گره های کنترل ترکیب می شوند، بنابراین ما همان چیزی را خواهیم داشت).

به نظر می رسد هیچ چیز پیچیده ای نباشد - ما یک رابط پل بر روی گره کنترل ایجاد می کنیم، ترافیک را به سمت آن هدایت می کنیم و از آنجا آن را در جایی که به آن نیاز داریم هدایت می کنیم. اما مشکل اینجاست که کلاینت RED می خواهد از شبکه 10.0.0.0/24 استفاده کند و کلاینت GREEN می خواهد از شبکه 10.0.0.0/24 استفاده کند. یعنی شروع به تقاطع فضاهای آدرس می کنیم. علاوه بر این، کلاینت‌ها نمی‌خواهند سایر کلاینت‌ها بتوانند به شبکه‌های داخلی خود راه یابند، که منطقی است. برای جداسازی شبکه ها و ترافیک داده های کلاینت، برای هر یک از آنها یک فضای نام جداگانه اختصاص می دهیم. فضای نام در واقع یک کپی از پشته شبکه لینوکس است، یعنی کلاینت‌ها در فضای نام RED کاملاً از کلاینت‌ها از فضای نام GREEN جدا می‌شوند (خوب، یا مسیریابی بین این شبکه‌های کلاینت از طریق فضای نام پیش‌فرض یا در تجهیزات انتقال بالادست مجاز است).

یعنی نمودار زیر را بدست می آوریم:

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

با این حال، مهم ترین چیز را فراموش کردیم. ماشین مجازی باید یک سرویس به مشتری ارائه دهد، یعنی حداقل یک رابط خارجی داشته باشد که از طریق آن بتوان به آن دسترسی داشت. یعنی باید به دنیای بیرون برویم. در اینجا گزینه های مختلفی وجود دارد. بیایید ساده ترین گزینه را انجام دهیم. ما به هر کلاینت یک شبکه اضافه می کنیم که در شبکه ارائه دهنده معتبر است و با شبکه های دیگر همپوشانی ندارد. شبکه ها همچنین می توانند با هم قطع شوند و به VRF های مختلف در کنار شبکه ارائه دهنده نگاه کنند. داده های شبکه نیز در فضای نام هر مشتری زندگی می کنند. با این حال، آنها همچنان از طریق یک رابط فیزیکی (یا پیوند، که منطقی تر است) به دنیای خارج خواهند رفت. برای جداسازی ترافیک مشتری، ترافیکی که به بیرون می رود با یک تگ VLAN تخصیص یافته به مشتری برچسب گذاری می شود.

در نتیجه به این نمودار رسیدیم:

یک سوال منطقی این است که چرا دروازه هایی را روی خود گره های محاسباتی ایجاد نمی کنیم؟ این مشکل بزرگی نیست؛ علاوه بر این، اگر روتر توزیع شده (DVR) را روشن کنید، کار می کند. در این سناریو، ما ساده ترین گزینه را با یک دروازه متمرکز در نظر می گیریم که به طور پیش فرض در Openstack استفاده می شود. برای عملکردهای پر بار، آنها از یک روتر توزیع شده و فناوری های شتاب دهنده مانند SR-IOV و Passthrough استفاده می کنند، اما همانطور که می گویند، این داستان کاملاً متفاوت است. ابتدا به قسمت اصلی می پردازیم و سپس به جزئیات می پردازیم.

در واقع، طرح ما در حال حاضر قابل اجرا است، اما چند تفاوت وجود دارد:

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

بیایید با محافظت از ماشین شروع کنیم. برای این کار می توانید از iptable های پیش پا افتاده استفاده کنید، چرا که نه.

یعنی اکنون توپولوژی ما کمی پیچیده تر شده است:

بیایید ادامه دهیم. باید یک سرور DHCP اضافه کنیم. ایده آل ترین مکان برای قرار دادن سرورهای DHCP برای هر مشتری، گره کنترلی است که قبلاً در بالا ذکر شد، جایی که فضاهای نام در آن قرار دارند:

با این حال، یک مشکل کوچک وجود دارد. اگر همه چیز دوباره راه اندازی شود و تمام اطلاعات مربوط به اجاره آدرس ها در DHCP ناپدید شود چه می شود. منطقی است که به ماشین ها آدرس های جدیدی داده شود که خیلی راحت نیست. در اینجا دو راه وجود دارد - یا از نام دامنه استفاده کنید و یک سرور DNS برای هر مشتری اضافه کنید، سپس آدرس برای ما اهمیت خاصی نخواهد داشت (مشابه قسمت شبکه در k8s) - اما مشکلی در شبکه های خارجی وجود دارد، زیرا آدرس ها را نیز می توان از طریق DHCP در آنها صادر کرد - شما نیاز به همگام سازی با سرورهای DNS در پلت فرم ابری و یک سرور DNS خارجی دارید که به نظر من خیلی انعطاف پذیر نیست، اما کاملاً ممکن است. یا گزینه دوم استفاده از ابرداده است - یعنی اطلاعات مربوط به آدرس صادر شده برای دستگاه را ذخیره کنید تا سرور DHCP بداند اگر دستگاه قبلاً آدرسی دریافت کرده باشد، کدام آدرس را برای دستگاه صادر کند. گزینه دوم ساده تر و انعطاف پذیرتر است، زیرا به شما امکان می دهد اطلاعات اضافی در مورد ماشین ذخیره کنید. حالا بیایید ابرداده عامل را به نمودار اضافه کنیم:

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

و در اینجا NAT به کمک ما می آید - ما فقط دسترسی مشتریان را به دنیای خارج از طریق فضای نام پیش فرض با استفاده از ترجمه NAT ممکن می کنیم. خوب، اینجا یک مشکل کوچک است. این در صورتی خوب است که سرور کلاینت به عنوان یک کلاینت عمل کند نه به عنوان یک سرور - یعنی به جای اینکه اتصالات را بپذیرد، راه اندازی می کند. اما برای ما برعکس خواهد بود. در این حالت، باید NAT مقصد را انجام دهیم تا هنگام دریافت ترافیک، گره کنترل بفهمد که این ترافیک برای ماشین مجازی A مشتری A در نظر گرفته شده است، یعنی باید از یک آدرس خارجی، به عنوان مثال 100.1.1.1 ترجمه NAT انجام دهیم. .10.0.0.1، به آدرس داخلی 100. در این حالت، اگرچه همه کلاینت‌ها از یک شبکه استفاده خواهند کرد، اما ایزوله داخلی کاملاً حفظ می‌شود. یعنی باید dNAT و sNAT را روی گره کنترل انجام دهیم. اینکه از یک شبکه واحد با آدرس‌های شناور یا شبکه‌های خارجی یا هر دو به طور همزمان استفاده کنید، بستگی به آنچه می‌خواهید در فضای ابری بیاورید، دارد. آدرس‌های شناور را به نمودار اضافه نمی‌کنیم، بلکه شبکه‌های خارجی را که قبلاً اضافه شده‌اند ترک می‌کنیم - هر مشتری شبکه خارجی خود را دارد (در نمودار آنها به عنوان vlan 200 و XNUMX در رابط خارجی نشان داده شده‌اند).

در نتیجه، ما یک راه حل جالب و در عین حال سنجیده دریافت کردیم که دارای انعطاف پذیری خاصی است اما هنوز مکانیسم های تحمل خطا را ندارد.

اولا، ما فقط یک گره کنترل داریم - شکست آن منجر به فروپاشی همه سیستم ها می شود. برای رفع این مشکل، باید حداقل 3 گره را به حد نصاب برسانید. بیایید این را به نمودار اضافه کنیم:

به طور طبیعی، همه گره ها هماهنگ هستند و هنگامی که یک گره فعال خارج می شود، گره دیگری مسئولیت آن را بر عهده می گیرد.

مشکل بعدی دیسک های ماشین مجازی است. در حال حاضر، آنها روی خود هایپروایزرها ذخیره می شوند و در صورت بروز مشکل در هایپروایزر، ما تمام داده ها را از دست می دهیم - و اگر نه دیسک، بلکه کل سرور را از دست بدهیم، وجود حمله در اینجا کمکی نمی کند. برای انجام این کار، باید سرویسی بسازیم که به عنوان قسمت جلویی برای نوعی ذخیره سازی عمل کند. نوع ذخیره‌سازی آن برای ما اهمیت خاصی ندارد، اما باید از داده‌های ما در برابر خرابی دیسک و گره و احتمالاً کل کابینت محافظت کند. چندین گزینه در اینجا وجود دارد - البته شبکه های SAN با کانال فیبر وجود دارد، اما بیایید صادق باشیم - FC در حال حاضر یادگاری از گذشته است - آنالوگ E1 در حمل و نقل - بله، موافقم، هنوز هم استفاده می شود، اما فقط در جایی که بدون آن مطلقاً غیرممکن است. بنابراین، من به طور داوطلبانه یک شبکه FC را در سال 2020 مستقر نمی کنم، زیرا می دانم که جایگزین های جالب تری وجود دارد. اگرچه برای هر یک از او، ممکن است کسانی باشند که معتقدند FC با همه محدودیت‌هایش تنها چیزی است که ما نیاز داریم - من بحث نمی‌کنم، هر کسی نظر خود را دارد. با این حال، جالب ترین راه حل به نظر من استفاده از SDS، مانند Ceph است.

Ceph به شما این امکان را می‌دهد تا یک راه‌حل ذخیره‌سازی داده بسیار در دسترس را با مجموعه‌ای از گزینه‌های پشتیبان‌گیری بسازید، که با کدهایی با بررسی برابری (مشابه با حمله 5 یا 6) شروع می‌شود و با تکثیر کامل داده‌ها به دیسک‌های مختلف، با در نظر گرفتن موقعیت دیسک‌ها در سرورها و سرورها در کابینت ها و غیره

برای ساخت Ceph به 3 گره دیگر نیاز دارید. تعامل با ذخیره سازی نیز از طریق شبکه با استفاده از سرویس های ذخیره سازی بلوک، شی و فایل انجام خواهد شد. بیایید فضای ذخیره سازی را به طرح اضافه کنیم:

توجه: شما همچنین می توانید گره های محاسباتی ابرهمگرا ایجاد کنید - این مفهوم ترکیب چندین تابع در یک گره است - به عنوان مثال، ذخیره سازی + محاسبه - بدون اختصاص گره های ویژه برای ذخیره سازی ceph. ما همان طرح تحمل خطا را دریافت خواهیم کرد - زیرا SDS داده ها را با سطح رزروی که ما مشخص کرده ایم ذخیره می کند. با این حال، گره های بیش همگرا همیشه یک مصالحه هستند - از آنجایی که گره ذخیره سازی فقط هوا را همانطور که در نگاه اول به نظر می رسد گرم نمی کند (از آنجایی که هیچ ماشین مجازی روی آن وجود ندارد) - منابع CPU را صرف سرویس SDS می کند (در واقع، همه کارها را انجام می دهد. تکرار و بازیابی پس از خرابی گره ها، دیسک ها و غیره). یعنی اگر گره محاسباتی را با فضای ذخیره سازی ترکیب کنید مقداری از قدرت آن را از دست خواهید داد.

همه این موارد باید به نحوی مدیریت شوند - ما به چیزی نیاز داریم که از طریق آن بتوانیم یک ماشین، یک شبکه، یک روتر مجازی و غیره ایجاد کنیم. برای انجام این کار، ما یک سرویس به گره کنترل اضافه می کنیم که به عنوان داشبورد عمل می کند - کلاینت می تواند از طریق http/ https به این پورتال متصل شود و هر کاری را که نیاز دارد انجام دهد (خوب، تقریباً).

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

معماری نوترونی

در OpenStack، این Neutron است که مسئول اتصال پورت های ماشین مجازی به یک شبکه L2 مشترک، اطمینان از مسیریابی ترافیک بین ماشین های مجازی واقع در شبکه های L2 مختلف، و همچنین مسیریابی به بیرون، ارائه خدماتی مانند NAT، Floating IP، DHCP و غیره است.

در سطح بالا، عملکرد سرویس شبکه (بخش اصلی) را می توان به شرح زیر توصیف کرد.

هنگام راه اندازی VM، سرویس شبکه:

1. یک پورت برای یک ماشین مجازی (یا پورت) ایجاد می کند و سرویس DHCP را در مورد آن مطلع می کند.
2. یک دستگاه شبکه مجازی جدید ایجاد می شود (از طریق libvirt).
3. VM به پورت(های) ایجاد شده در مرحله 1 متصل می شود.

به اندازه کافی عجیب، کار نوترون مبتنی بر مکانیسم‌های استانداردی است که برای همه کسانی که تا به حال وارد لینوکس شده‌اند آشنا هستند - فضاهای نام، iptables، پل‌های لینوکس، openvswitch، conntrack و غیره.

بلافاصله باید روشن شود که نوترون یک کنترل کننده SDN نیست.

نوترون از چندین جزء به هم پیوسته تشکیل شده است:

Openstack-neutron-server دیمونی است که با درخواست های کاربر از طریق API کار می کند. این دیو در ثبت هیچ اتصال شبکه ای دخالتی ندارد، اما اطلاعات لازم برای این کار را در اختیار پلاگین های خود قرار می دهد و سپس عنصر شبکه مورد نظر را پیکربندی می کند. عوامل نوترونی در گره های OpenStack با سرور نوترون ثبت می شوند.

سرور نوترون در واقع برنامه ای است که به زبان پایتون نوشته شده و از دو بخش تشکیل شده است:

• سرویس REST
• پلاگین نوترون (هسته/سرویس)

سرویس REST برای دریافت تماس های API از سایر مؤلفه ها (به عنوان مثال، درخواست برای ارائه برخی اطلاعات و غیره) طراحی شده است.

پلاگین‌ها اجزا/ماژول‌های نرم‌افزاری افزونه‌ای هستند که در طول درخواست‌های API فراخوانی می‌شوند - یعنی انتساب یک سرویس از طریق آنها انجام می‌شود. پلاگین ها به دو نوع سرویس و ریشه تقسیم می شوند. به عنوان یک قاعده، پلاگین اسب عمدتاً مسئولیت مدیریت فضای آدرس و اتصالات L2 بین ماشین های مجازی را بر عهده دارد و افزونه های سرویس از قبل عملکردهای اضافی مانند VPN یا FW را ارائه می دهند.

لیست پلاگین های موجود امروز را می توان به عنوان مثال مشاهده کرد اینجا

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

openstack-neutron-ml2 پلاگین روت استاندارد Openstack است. این افزونه دارای معماری ماژولار است (برخلاف نسخه قبلی خود) و سرویس شبکه را از طریق درایورهای متصل به آن پیکربندی می کند. ما کمی بعد به خود پلاگین نگاه خواهیم کرد، زیرا در واقع انعطاف پذیری OpenStack را در بخش شبکه می دهد. پلاگین ریشه را می توان جایگزین کرد (به عنوان مثال، Contrail Networking چنین جایگزینی را انجام می دهد).

سرویس RPC (سرور rabbitmq) — سرویسی که مدیریت صف و تعامل با سایر سرویس های OpenStack و همچنین تعامل بین عوامل خدمات شبکه را فراهم می کند.

عوامل شبکه - عواملی که در هر گره قرار دارند و خدمات شبکه از طریق آنها پیکربندی می شوند.

چندین نوع عامل وجود دارد.

عامل اصلی است عامل L2. این عوامل بر روی هر یک از Hypervisor ها، از جمله گره های کنترل (به طور دقیق تر، در تمام گره هایی که هر گونه خدماتی را برای مستاجران ارائه می دهند) اجرا می شوند و وظیفه اصلی آنها اتصال ماشین های مجازی به یک شبکه مشترک L2 و همچنین ایجاد هشدار در صورت وقوع هر رویدادی است. برای مثال پورت را غیرفعال/فعال کنید).

عامل بعدی، نه کمتر مهم است عامل L3. به طور پیش فرض، این عامل به طور انحصاری بر روی یک گره شبکه اجرا می شود (اغلب گره شبکه با یک گره کنترل ترکیب می شود) و مسیریابی بین شبکه های مستاجر (هم بین شبکه های خود و هم بین شبکه های مستاجر دیگر و برای دنیای خارج قابل دسترسی است، فراهم می کند) NAT و همچنین سرویس DHCP). با این حال، هنگام استفاده از DVR (روتر توزیع شده)، نیاز به پلاگین L3 نیز در گره های محاسباتی ظاهر می شود.

عامل L3 از فضاهای نام لینوکس استفاده می کند تا برای هر مستأجر مجموعه ای از شبکه های جدا شده خود و عملکرد روترهای مجازی که ترافیک را هدایت می کنند و خدمات دروازه را برای شبکه های لایه 2 ارائه می کنند، ارائه دهد.

پایگاه داده - پایگاه داده ای از شناسه های شبکه ها، زیرشبکه ها، پورت ها، استخرها و غیره.

در واقع، نوترون درخواست‌های API را از ایجاد هر موجودیت شبکه می‌پذیرد، درخواست را احراز هویت می‌کند و از طریق RPC (اگر به پلاگین یا عاملی دسترسی داشته باشد) یا REST API (اگر در SDN ارتباط برقرار کند) به عوامل (از طریق افزونه‌ها) ارسال می‌کند. دستورالعمل های لازم برای سازماندهی خدمات درخواستی

حالا بیایید به نصب آزمایشی بپردازیم (نحوه استقرار آن و آنچه در آن گنجانده شده است، بعداً در بخش عملی خواهیم دید) و ببینیم که هر جزء در کجا قرار دارد:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

در واقع، این کل ساختار نوترون است. اکنون ارزش آن را دارد که مدتی را روی افزونه ML2 صرف کنید.

لایه ماژولار 2

همانطور که در بالا ذکر شد، این افزونه یک پلاگین روت استاندارد OpenStack است و دارای معماری ماژولار است.

سلف افزونه ML2 ساختار یکپارچه ای داشت که به عنوان مثال امکان استفاده از ترکیبی از چندین فناوری را در یک نصب نمی داد. به عنوان مثال، شما نمی توانید از openvswitch و linuxbridge به طور همزمان استفاده کنید - چه اولی چه دومی. به همین دلیل افزونه ML2 با معماری آن ساخته شد.

ML2 دارای دو جزء است - دو نوع درایور: درایورهای نوع و درایورهای مکانیزم.

درایورها را تایپ کنید فناوری هایی را که برای سازماندهی اتصالات شبکه مورد استفاده قرار می گیرند، تعیین کنید، به عنوان مثال VxLAN، VLAN، GRE. در عین حال، راننده امکان استفاده از فناوری های مختلف را می دهد. فناوری استاندارد، کپسوله سازی VxLAN برای شبکه های همپوشانی و شبکه های خارجی vlan است.

درایورهای نوع شامل انواع شبکه زیر هستند:

صاف - شبکه بدون برچسب گذاری
VLAN ها - شبکه برچسب گذاری شده
محلی - نوع خاصی از شبکه برای نصب همه در یک (اینگونه نصب ها برای توسعه دهندگان یا برای آموزش مورد نیاز است)
GRE - پوشش شبکه با استفاده از تونل های GRE
VxLAN - پوشش شبکه با استفاده از تونل های VxLAN

درایورهای مکانیزم ابزارهایی را تعریف کنید که سازماندهی فناوری های مشخص شده در درایور نوع را تضمین می کند - به عنوان مثال، openvswitch، sr-iov، opendaylight، OVN و غیره.

بسته به پیاده سازی این درایور، یا از عوامل کنترل شده توسط نوترون استفاده می شود یا از اتصالات به یک کنترلر SDN خارجی استفاده می شود که تمام مسائل مربوط به سازماندهی شبکه های L2، مسیریابی و غیره را بر عهده می گیرد.

مثال: اگر از ML2 همراه با OVS استفاده کنیم، یک عامل L2 روی هر گره محاسباتی نصب می شود که OVS را مدیریت می کند. با این حال، اگر به عنوان مثال از OVN یا OpenDayLight استفاده کنیم، کنترل OVS تحت صلاحیت آنها قرار می گیرد - نوترون، از طریق پلاگین root، دستوراتی را به کنترل کننده می دهد، و قبلاً آنچه را که گفته شده انجام می دهد.

بیایید Open vSwitch را بررسی کنیم

در حال حاضر، یکی از اجزای کلیدی OpenStack Open vSwitch است.
هنگام نصب OpenStack بدون هیچ SDN فروشنده اضافی مانند Juniper Contrail یا Nokia Nuage، OVS جزء اصلی شبکه شبکه ابری است و همراه با iptables، conntrack، فضاهای نام، به شما امکان می‌دهد شبکه‌های همپوشانی چند اجاره‌ای کامل را سازماندهی کنید. به طور طبیعی، این جزء را می توان جایگزین کرد، به عنوان مثال، هنگام استفاده از راه حل های SDN اختصاصی (فروشنده) شخص ثالث.

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

در حال حاضر، OVS دارای عملکرد بسیار مناسبی است که شامل فناوری هایی مانند QoS، LACP، VLAN، VxLAN، GENEVE، OpenFlow، DPDK و غیره است.

توجه: OVS در ابتدا به عنوان یک سوئیچ نرم برای عملکردهای مخابراتی با بارگذاری بالا در نظر گرفته نشد و بیشتر برای عملکردهای فناوری اطلاعات با پهنای باند کمتر مانند سرور وب یا سرور پست طراحی شده بود. با این حال، OVS بیشتر در حال توسعه است و پیاده سازی های فعلی OVS عملکرد و قابلیت های آن را بسیار بهبود بخشیده است، که به اپراتورهای مخابراتی با عملکردهای بسیار بارگذاری شده امکان استفاده از آن را می دهد، به عنوان مثال، یک پیاده سازی OVS با پشتیبانی از شتاب DPDK وجود دارد.

سه جزء مهم OVS وجود دارد که باید از آنها آگاه باشید:

• ماژول کرنل - یک جزء واقع در فضای هسته که ترافیک را بر اساس قوانین دریافت شده از عنصر کنترل پردازش می کند.
• v سوئیچ daemon (ovs-vswitchd) یک فرآیند راه اندازی شده در فضای کاربر است که مسئول برنامه نویسی ماژول هسته است - یعنی مستقیماً منطق عملکرد سوئیچ را نشان می دهد.
• سرور پایگاه داده - یک پایگاه داده محلی واقع در هر میزبانی که OVS را اجرا می کند، که پیکربندی در آن ذخیره می شود. کنترل کننده های SDN می توانند از طریق این ماژول با استفاده از پروتکل OVSDB ارتباط برقرار کنند.

همه اینها با مجموعه ای از ابزارهای تشخیصی و مدیریتی مانند ovs-vsctl، ovs-appctl، ovs-ofctl و غیره همراه است.

در حال حاضر، Openstack به طور گسترده توسط اپراتورهای مخابراتی برای انتقال عملکردهای شبکه به آن استفاده می شود، مانند EPC، SBC، HLR، و غیره. برخی از توابع می توانند بدون مشکل با OVS زندگی کنند، اما برای مثال، EPC ترافیک مشترک را پردازش می کند - سپس از آن عبور می کند. حجم عظیمی از ترافیک (اکنون حجم ترافیک به چند صد گیگابیت در ثانیه می رسد). به طور طبیعی، هدایت چنین ترافیکی از طریق فضای هسته (از آنجایی که فورواردر به طور پیش فرض در آنجا قرار دارد) بهترین ایده نیست. بنابراین، OVS اغلب به طور کامل در فضای کاربر با استفاده از فناوری شتاب DPDK برای انتقال ترافیک از NIC به فضای کاربر با دور زدن هسته مستقر می شود.

توجه: برای یک ابر مستقر شده برای عملکردهای مخابراتی، خروجی ترافیک از یک گره محاسباتی با دور زدن OVS مستقیماً به تجهیزات سوئیچینگ امکان پذیر است. برای این منظور از مکانیسم های SR-IOV و Passthrough استفاده می شود.

این چگونه در یک طرح واقعی کار می کند؟

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

ابتدا، اجازه دهید یک نصب ساده Openstack را اجرا کنیم. از آنجایی که من مجموعه ای از سرورها را برای آزمایش در دسترس ندارم، نمونه اولیه را روی یک سرور فیزیکی از ماشین های مجازی مونتاژ می کنیم. بله، طبیعتا چنین راه حلی برای اهداف تجاری مناسب نیست، اما برای دیدن نمونه ای از نحوه عملکرد شبکه در Openstack، چنین نصبی برای چشم کافی است. علاوه بر این ، چنین نصبی برای اهداف آموزشی جالب تر است - زیرا می توانید ترافیک و غیره را بگیرید.

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

بنابراین، بیایید به ترتیب شروع کنیم. اول، کمی تئوری. ما Openstack را با استفاده از TripleO (Openstack در Openstack) نصب خواهیم کرد. ماهیت TripleO این است که Openstack All-in-one (یعنی روی یک گره) به نام undercloud را نصب می کنیم و سپس از قابلیت های Openstack مستقر شده برای نصب Openstack در نظر گرفته شده برای عملیات به نام overcloud استفاده می کنیم. Undercloud از توانایی ذاتی خود برای مدیریت سرورهای فیزیکی (فلز خالی) - پروژه Ironic - برای ارائه هایپروایزرهایی استفاده می کند که نقش گره های محاسبه، کنترل و ذخیره سازی را انجام می دهند. یعنی ما از هیچ ابزار شخص ثالثی برای استقرار Openstack استفاده نمی کنیم - ما Openstack را با استفاده از Openstack مستقر می کنیم. با پیشرفت نصب بسیار واضح تر می شود، بنابراین ما در اینجا متوقف نمی شویم و به جلو حرکت نمی کنیم.

توجه: در این مقاله، برای سادگی، از جداسازی شبکه برای شبکه‌های Openstack داخلی استفاده نکردم، اما همه چیز فقط با استفاده از یک شبکه اجرا می‌شود. با این حال، وجود یا عدم وجود جداسازی شبکه بر عملکرد اصلی راه حل تأثیر نمی گذارد - همه چیز دقیقاً مانند هنگام استفاده از ایزوله کار می کند، اما ترافیک در همان شبکه جریان دارد. برای نصب تجاری، طبیعتاً استفاده از ایزوله با استفاده از vlan ها و رابط های مختلف ضروری است. به عنوان مثال، ترافیک مدیریت ذخیره سازی ceph و خود ترافیک داده (دسترسی ماشین به دیسک ها و غیره) زمانی که ایزوله هستند از زیرشبکه های مختلف (مدیریت ذخیره سازی و ذخیره سازی) استفاده می کنند و این به شما امکان می دهد با تقسیم این ترافیک راه حل را مقاوم تر کنید. ، در پورت های مختلف یا استفاده از پروفایل های QoS مختلف برای ترافیک مختلف به طوری که ترافیک داده ترافیک سیگنالینگ را تحت فشار قرار ندهد. در مورد ما، آنها در همان شبکه خواهند رفت و در واقع این به هیچ وجه ما را محدود نمی کند.

توجه: از آنجایی که قصد داریم ماشین های مجازی را در یک محیط مجازی مبتنی بر ماشین های مجازی اجرا کنیم، ابتدا باید مجازی سازی تودرتو را فعال کنیم.

شما می توانید بررسی کنید که آیا مجازی سازی تودرتو فعال است یا خیر:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

اگر حرف N را می بینید، ما پشتیبانی از مجازی سازی تودرتو را با توجه به هر راهنمایی که در شبکه پیدا می کنید، برای مثال فعال می کنیم. چنین .

ما باید مدار زیر را از ماشین های مجازی جمع کنیم:

در مورد من، برای اتصال ماشین‌های مجازی که بخشی از نصب آینده هستند (و من 7 مورد از آنها را دریافت کردم، اما اگر منابع زیادی ندارید، می‌توانید با 4 تا از آن عبور کنید)، از OpenvSwitch استفاده کردم. من یک پل ovs ایجاد کردم و ماشین های مجازی را از طریق پورت-گروه ها به آن متصل کردم. برای انجام این کار، من یک فایل xml به شکل زیر ایجاد کردم:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

سه گروه پورت در اینجا اعلام شده است - دو دسترسی و یک ترانک (این دومی برای سرور DNS مورد نیاز بود ، اما می توانید بدون آن انجام دهید یا آن را روی دستگاه میزبان نصب کنید - هر کدام برای شما راحت تر است). در مرحله بعد، با استفاده از این الگو، ما از طریق virsh net-define خود را اعلام می کنیم:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

اکنون تنظیمات پورت هایپروایزر را ویرایش می کنیم:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

توجه: در این سناریو آدرس پورت ovs-br1 به دلیل نداشتن تگ vlan قابل دسترسی نخواهد بود. برای رفع این مشکل، باید دستور sudo ovs-vsctl set port ovs-br1 tag=100 را صادر کنید. با این حال، پس از راه اندازی مجدد، این برچسب ناپدید می شود (اگر کسی می داند چگونه آن را در جای خود ثابت نگه دارد، بسیار سپاسگزار خواهم بود). اما این چندان مهم نیست، زیرا ما فقط در حین نصب به این آدرس نیاز خواهیم داشت و زمانی که Openstack به طور کامل اجرا شد به آن نیازی نخواهیم داشت.

بعد، ما یک ماشین undercloud ایجاد می کنیم:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

در حین نصب، شما تمام پارامترهای لازم مانند نام ماشین، رمز عبور، کاربران، سرورهای ntp و غیره را تنظیم می کنید، بلافاصله می توانید پورت ها را پیکربندی کنید، اما شخصا برای من، پس از نصب، ورود به دستگاه از طریق آسان تر است. کنسول و فایل های لازم را تصحیح کنید. اگر از قبل یک تصویر آماده دارید، می توانید از آن استفاده کنید، یا کاری را که من انجام دادم انجام دهید - تصویر حداقل Centos 7 را دانلود کنید و از آن برای نصب VM استفاده کنید.

پس از نصب موفقیت آمیز، باید یک ماشین مجازی داشته باشید که می توانید undercloud را روی آن نصب کنید

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

ابتدا ابزارهای لازم برای فرآیند نصب را نصب کنید:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

نصب Undercloud

ما یک کاربر پشته ایجاد می کنیم، یک رمز عبور تنظیم می کنیم، آن را به sudoer اضافه می کنیم و به او این امکان را می دهیم که دستورات root را از طریق sudo بدون نیاز به وارد کردن رمز عبور اجرا کند:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

اکنون نام کامل undercloud را در فایل host مشخص می کنیم:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

در مرحله بعد، مخازن را اضافه می کنیم و نرم افزار مورد نیاز خود را نصب می کنیم:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

توجه: اگر قصد نصب ceph را ندارید، نیازی به وارد کردن دستورات مربوط به ceph ندارید. من از نسخه Queens استفاده کردم، اما شما می توانید از هر نسخه دیگری که دوست دارید استفاده کنید.

سپس، فایل پیکربندی undercloud را در پشته فهرست اصلی کاربر کپی کنید:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

اکنون باید این فایل را تصحیح کنیم و آن را با نصب خود تنظیم کنیم.

شما باید این خطوط را به ابتدای فایل اضافه کنید:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

بنابراین، بیایید تنظیمات را مرور کنیم:

undercloud_hostname - نام کامل سرور undercloud باید با ورودی سرور DNS مطابقت داشته باشد

local_ip - آدرس undercloud محلی به سمت تامین شبکه

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

undercloud_public_host - آدرس API خارجی، هر آدرس رایگان از شبکه تامین کننده اختصاص داده می شود

undercloud_admin_host آدرس API داخلی، هر آدرس رایگان از شبکه تامین کننده اختصاص داده می شود

سرورهای undercloud_name - سرور DNS

Generation_service_certificate - این خط در مثال فعلی بسیار مهم است، زیرا اگر آن را روی false قرار ندهید، در حین نصب با خطا مواجه می شوید، مشکل در ردیاب اشکال Red Hat توضیح داده شده است.

local_interface رابط در تامین شبکه این رابط در حین استقرار undercloud پیکربندی مجدد خواهد شد، بنابراین شما باید دو رابط در undercloud داشته باشید - یکی برای دسترسی به آن، دومی برای تامین

local_mtu - MTU. از آنجایی که ما یک آزمایشگاه تست داریم و من MTU 1500 روی پورت های سوئیچ OVS دارم، لازم است آن را روی 1450 تنظیم کنم تا بسته های کپسوله شده در VxLAN بتوانند از آن عبور کنند.

network_cidr - شبکه تامین

masquerade - استفاده از NAT برای دسترسی به یک شبکه خارجی

بالماسکه_شبکه - شبکه ای که NATE خواهد شد

dhcp_start - آدرس شروع مخزن آدرس که از آن آدرس ها به گره ها در حین استقرار overcloud اختصاص داده می شود.

dhcp_end - آدرس نهایی مخزن آدرس که از آن آدرس‌ها به گره‌ها در حین استقرار overcloud اختصاص می‌یابد.

inspection_iprange - مجموعه ای از آدرس های لازم برای درون نگری (نباید با مجموعه فوق همپوشانی داشته باشد)

scheduler_max_attempts - حداکثر تعداد تلاش برای نصب overcloud (باید بیشتر یا مساوی تعداد گره ها باشد)

پس از توصیف فایل، می‌توانید دستور Deploy undercloud را بدهید:

openstack undercloud install

این روش بسته به میزان آهن شما بین 10 تا 30 دقیقه طول می کشد. در نهایت شما باید خروجی را مانند این ببینید:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

این خروجی می گوید که شما با موفقیت undercloud را نصب کرده اید و اکنون می توانید وضعیت undercloud را بررسی کرده و اقدام به نصب overcloud کنید.

اگر به خروجی ifconfig نگاه کنید، خواهید دید که یک رابط پل جدید ظاهر شده است

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

استقرار Overcloud اکنون از طریق این رابط انجام خواهد شد.

از خروجی زیر می توانید ببینید که ما همه خدمات را در یک گره داریم:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

در زیر پیکربندی قسمت شبکه undercloud آمده است:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

نصب Overcloud

در حال حاضر ما فقط undercloud داریم و گره های کافی نداریم که از آنها overcloud جمع آوری شود. بنابراین، اول از همه، اجازه دهید ماشین های مجازی مورد نیاز خود را مستقر کنیم. در حین استقرار، undercloud خود سیستم عامل و نرم افزارهای لازم را روی دستگاه overcloud نصب می کند - یعنی نیازی نیست دستگاه را به طور کامل مستقر کنیم، بلکه فقط یک دیسک (یا دیسک) برای آن ایجاد می کنیم و پارامترهای آن را تعیین می کنیم - یعنی ، در واقع، ما یک سرور خالی بدون سیستم عامل نصب شده روی آن دریافت می کنیم.

بیایید به پوشه ای با دیسک های ماشین های مجازی خود برویم و دیسک هایی با اندازه مورد نیاز ایجاد کنیم:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

از آنجایی که ما به عنوان روت کار می کنیم، باید مالک این دیسک ها را تغییر دهیم تا با حقوق مشکلی نداشته باشیم:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

توجه: اگر قصد ندارید ceph را برای مطالعه آن نصب کنید، دستورات حداقل 3 گره با حداقل دو دیسک ایجاد نمی کنند، بلکه در قالب نشان می دهد که از دیسک های مجازی vda، vdb و غیره استفاده می شود.

عالی است، اکنون باید همه این ماشین ها را تعریف کنیم:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

در پایان یک دستور -print-xml > /tmp/storage-1.xml وجود دارد که یک فایل xml با توضیحات هر دستگاه در پوشه /tmp/ ایجاد می‌کند؛ اگر آن را اضافه نکنید، دیگر نمی‌توانید قادر به شناسایی ماشین های مجازی

اکنون باید همه این ماشین ها را به صورت virsh تعریف کنیم:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

اکنون یک تفاوت کوچک - tripleO از IPMI برای مدیریت سرورها در حین نصب و بررسی درونی استفاده می کند.

درون نگری فرآیند بازرسی سخت افزار به منظور بدست آوردن پارامترهای لازم برای تهیه بیشتر گره ها است. Introspection با استفاده از ironic انجام می شود، سرویسی که برای کار با سرورهای فلزی لخت طراحی شده است.

اما مشکل اینجاست - در حالی که سرورهای IPMI سخت افزاری یک پورت جداگانه دارند (یا یک پورت مشترک، اما این مهم نیست)، ماشین های مجازی چنین پورت هایی ندارند. در اینجا یک عصا به نام vbmc به کمک ما می آید - ابزاری که به شما امکان می دهد یک پورت IPMI را شبیه سازی کنید. این تفاوت ظریف به ویژه برای کسانی که می خواهند چنین آزمایشگاهی را روی هایپروایزر ESXI راه اندازی کنند ارزش توجه دارد - صادقانه بگویم، نمی دانم آیا آنالوگ vbmc دارد یا نه، بنابراین ارزش دارد که قبل از استقرار همه چیز در مورد این موضوع تعجب کنید. .

vbmc را نصب کنید:

yum install yum install python2-virtualbmc

اگر سیستم عامل شما نمی تواند بسته را پیدا کند، مخزن را اضافه کنید:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

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

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

برای اینکه آنها ظاهر شوند، باید به صورت دستی به این شکل اعلام شوند:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

من فکر می کنم دستور دستور بدون توضیح واضح است. با این حال، در حال حاضر همه جلسات ما در وضعیت DOWN هستند. برای اینکه آنها به وضعیت UP منتقل شوند، باید آنها را فعال کنید:

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

و آخرین لمس - باید قوانین فایروال را اصلاح کنید (یا آن را به طور کامل غیرفعال کنید):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

حالا بیایید به undercloud برویم و بررسی کنیم که همه چیز کار می کند. آدرس ماشین میزبان 192.168.255.200 است، در undercloud بسته ipmitool لازم را در حین آماده سازی برای استقرار اضافه کردیم:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

همانطور که می بینید، گره کنترل را با موفقیت از طریق vbmc راه اندازی کردیم. حالا بیایید آن را خاموش کنیم و ادامه دهیم:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

مرحله بعدی درون نگری گره هایی است که Overcloud روی آنها نصب می شود. برای این کار باید یک فایل json با توضیحات گره های خود آماده کنیم. لطفاً توجه داشته باشید که برخلاف نصب بر روی سرورهای خالی، فایل نشان دهنده پورتی است که vbmc در آن برای هر دستگاه اجرا می شود.

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

نکته: گره کنترل دارای دو رابط است، اما در این مورد این مهم نیست، در این نصب یکی برای ما کافی خواهد بود.

حالا فایل json را آماده می کنیم. ما باید آدرس poppy پورتی را که از طریق آن تجهیز انجام می شود ، پارامترهای گره ها ، نام گذاری آنها و نحوه دسترسی به ipmi را مشخص کنیم:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

حال باید تصاویر را برای ایرونی آماده کنیم. برای انجام این کار، آنها را از طریق wget دانلود و نصب کنید:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

آپلود تصاویر در undercloud:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

بررسی بارگیری همه تصاویر

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

یک چیز دیگر - شما باید یک سرور DNS اضافه کنید:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

حالا می‌توانیم دستور introspection را بدهیم:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

همانطور که از خروجی می بینید، همه چیز بدون خطا کامل شد. بیایید بررسی کنیم که همه گره ها در وضعیت موجود هستند:

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

اگر گره‌ها در وضعیت متفاوتی هستند، معمولاً قابل مدیریت هستند، مشکلی پیش آمده است و باید به گزارش نگاه کنید و علت این اتفاق را بیابید. به خاطر داشته باشید که در این سناریو ما از مجازی سازی استفاده می کنیم و ممکن است باگ هایی در ارتباط با استفاده از ماشین های مجازی یا vbmc وجود داشته باشد.

در مرحله بعد، باید مشخص کنیم که کدام گره کدام عملکرد را انجام می دهد - یعنی نمایه ای را که گره با آن مستقر می شود را مشخص کنیم:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

مشخصات هر گره را مشخص کنید:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

بیایید بررسی کنیم که همه چیز را به درستی انجام داده ایم:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

اگر همه چیز درست باشد، دستور Deploy overcloud را می دهیم:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

توجه: متغیر qemu از نوع --libvirt در این مورد ضروری است، زیرا ما از مجازی سازی تودرتو استفاده خواهیم کرد. در غیر این صورت نمی توانید ماشین های مجازی را اجرا کنید.

حالا شما حدود یک ساعت یا شاید بیشتر وقت دارید (بسته به توانایی های سخت افزار) و فقط می توانید امیدوار باشید که بعد از این مدت پیام زیر را مشاهده کنید:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

اکنون یک نسخه تقریباً کامل از openstack دارید که می توانید روی آن مطالعه کنید، آزمایش کنید و غیره.

بیایید بررسی کنیم که همه چیز به درستی کار می کند. در پشته فهرست اصلی کاربر دو فایل وجود دارد - یکی stackrc (برای مدیریت undercloud) و دیگری overcloudrc (برای مدیریت overcloud). این فایل ها باید به عنوان منبع مشخص شوند، زیرا حاوی اطلاعات لازم برای احراز هویت هستند.

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

نصب من هنوز به یک لمس کوچک نیاز دارد - اضافه کردن یک مسیر روی کنترلر، زیرا دستگاهی که با آن کار می کنم در شبکه دیگری است. برای این کار زیر اکانت heat-admin به control-1 رفته و مسیر را ثبت کنید

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

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

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

چگونه ترافیک بین ماشین های مجازی جریان دارد؟

در این مقاله سه گزینه برای عبور ترافیک را بررسی خواهیم کرد

• دو ماشین روی یک هایپروایزر در یک شبکه L2
• دو ماشین روی هایپروایزرهای مختلف در یک شبکه L2
• دو ماشین در شبکه های مختلف (روت کردن بین شبکه ای)

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

برای بررسی، بیایید نمودار زیر را کنار هم قرار دهیم:

ما 4 ماشین مجازی ایجاد کرده ایم - 3 مورد در یک شبکه L2 - net-1 و 1 ماشین دیگر در شبکه net-2

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

بیایید ببینیم ماشین های ایجاد شده روی چه هایپروایزرهایی قرار دارند:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(overcloud) [stack@undercloud ~]$
ماشین‌های vm-1 و vm-3 روی compute-0، ماشین‌های vm-2 و vm-4 روی node compute-1 قرار دارند.

علاوه بر این، یک روتر مجازی برای فعال کردن مسیریابی بین شبکه های مشخص شده ایجاد شده است:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

روتر دارای دو پورت مجازی است که به عنوان دروازه برای شبکه ها عمل می کنند:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

در حال حاضر، گره دارای سه پل ovs است - br-int، br-tun، br-ex. بین آنها، همانطور که می بینیم، مجموعه ای از رابط ها وجود دارد. برای سهولت درک، بیایید همه این رابط ها را در نمودار ترسیم کنیم و ببینیم چه اتفاقی می افتد.

با نگاهی به آدرس‌هایی که تونل‌های VxLAN به آن‌ها ارتقا یافته‌اند، می‌توان دید که یک تونل به محاسبه-1 (192.168.255.26) ارتقا یافته است، تونل دوم به کنترل-1 (192.168.255.15) نگاه می‌کند. اما جالب‌ترین چیز این است که br-ex رابط فیزیکی ندارد و اگر به پیکربندی جریان‌ها نگاه کنید، می‌بینید که این پل در حال حاضر فقط می‌تواند ترافیک را کاهش دهد.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

طبق قانون اول، هر چیزی که از پورت phy-br-ex آمده است باید دور ریخته شود.
در واقع، در حال حاضر هیچ جای دیگری برای ورود ترافیک به این پل وجود ندارد، به جز این رابط (رابط با br-int)، و با قضاوت بر اساس افت، ترافیک BUM قبلاً به داخل پل سرازیر شده است.

یعنی ترافیک فقط از طریق تونل VxLAN می تواند از این گره خارج شود و نه چیز دیگری. با این حال، اگر DVR را روشن کنید، وضعیت تغییر می کند، اما ما در فرصتی دیگر به آن خواهیم پرداخت. هنگام استفاده از جداسازی شبکه، به عنوان مثال با استفاده از vlans، شما نه یک رابط L3 در vlan 0، بلکه چندین رابط خواهید داشت. با این حال، ترافیک VxLAN به همان روش گره را ترک می کند، اما همچنین در نوعی vlan اختصاصی محصور می شود.

ما گره محاسباتی را مرتب کردیم، بیایید به گره کنترل برویم.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

این پورت به پل br-ex گره خورده است و از آنجایی که هیچ برچسب vlan روی آن وجود ندارد، این پورت یک پورت ترانک است که تمام vlan ها روی آن مجاز هستند، اکنون ترافیک بدون برچسب به بیرون می رود، همانطور که با vlan-id 0 در نشان داده شده است. خروجی بالا

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

در این مقاله گره‌های ذخیره‌سازی را در نظر نخواهیم گرفت، اما برای درک بهتر باید گفت که بخش شبکه این گره‌ها تا حد آبروریزی پیش پا افتاده است. در مورد ما، تنها یک پورت فیزیکی (eth0) با یک آدرس IP اختصاص داده شده به آن وجود دارد و تمام. هیچ تونل VxLAN، پل تونل و غیره وجود ندارد - به هیچ وجه ovs وجود ندارد، زیرا هیچ نکته ای در آن وجود ندارد. هنگام استفاده از جداسازی شبکه، این گره دارای دو رابط (پورت فیزیکی، بدنه، یا فقط دو vlan - مهم نیست - بستگی به آنچه می خواهید دارد) خواهد داشت - یکی برای مدیریت، دومی برای ترافیک (نوشتن در دیسک VM). ، خواندن از روی دیسک و غیره)

ما متوجه شدیم که در غیاب هیچ سرویسی چه چیزی روی گره ها داریم. حالا بیایید 4 ماشین مجازی را راه اندازی کنیم و ببینیم که طرح توضیح داده شده در بالا چگونه تغییر می کند - ما باید پورت ها، روترهای مجازی و غیره داشته باشیم.

تا اینجا شبکه ما به این صورت است:

ما در هر گره کامپیوتر دو ماشین مجازی داریم. با استفاده از compute-0 به عنوان مثال، بیایید ببینیم که چگونه همه چیز گنجانده شده است.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

دستگاه فقط یک رابط مجازی دارد - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

این رابط در پل لینوکس به نظر می رسد:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

همانطور که از خروجی می بینید، تنها دو رابط در پل وجود دارد - tap95d96a75-a0 و qvb95d96a75-a0.

در اینجا ارزش آن را دارد که کمی در مورد انواع دستگاه های شبکه مجازی در OpenStack صحبت کنیم:
vtap - رابط مجازی متصل به یک نمونه (VM)
qbr - پل لینوکس
qvb و qvo - جفت vEth به پل لینوکس و پل vSwitch باز می شود
br-int، br-tun، br-vlan - پل های vSwitch را باز کنید
patch-, int-br-, phy-br- - باز کردن رابط های vSwitch پچ پل های اتصال
qg، qr، ha، fg، sg - پورت‌های vSwitch را باز کنید که توسط دستگاه‌های مجازی برای اتصال به OVS استفاده می‌شود.

همانطور که متوجه شدید، اگر یک پورت qvb95d96a75-a0 در پل داشته باشیم که جفت vEth است، در جایی مشابه آن وجود دارد که منطقاً باید qvo95d96a75-a0 نامیده شود. بیایید ببینیم چه پورت هایی در OVS وجود دارد.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

همانطور که می بینیم، پورت در br-int است. Br-int به عنوان سوئیچ عمل می کند که پورت های ماشین مجازی را خاتمه می دهد. علاوه بر qvo95d96a75-a0، پورت qvo5bd37136-47 در خروجی قابل مشاهده است. این پورت دومین ماشین مجازی است. در نتیجه، نمودار ما اکنون به صورت زیر است:

سوالی که باید بلافاصله خواننده توجه را جلب کند - پل لینوکس بین پورت ماشین مجازی و پورت OVS چیست؟ واقعیت این است که برای محافظت از دستگاه از گروه های امنیتی استفاده می شود که چیزی جز iptable نیست. OVS با iptable ها کار نمی کند، بنابراین این "عصا" اختراع شد. با این حال، در حال منسوخ شدن است - در نسخه های جدید با conntrack جایگزین می شود.

یعنی در نهایت این طرح به این صورت است:

دو ماشین روی یک هایپروایزر در یک شبکه L2

از آنجایی که این دو ماشین مجازی در یک شبکه L2 و روی یک هایپروایزر قرار دارند، ترافیک بین آنها به طور منطقی از طریق br-int جریان می یابد، زیرا هر دو ماشین در یک VLAN هستند:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

دو ماشین روی هایپروایزرهای مختلف در یک شبکه L2

حال بیایید ببینیم ترافیک بین دو ماشین در یک شبکه L2، اما در هایپروایزرهای مختلف، چگونه خواهد رفت. صادقانه بگویم، هیچ چیز تغییر زیادی نخواهد کرد، فقط ترافیک بین هایپروایزرها از طریق تونل vxlan می گذرد. بیایید به یک مثال نگاه کنیم.

آدرس ماشین های مجازی که بین آنها ترافیک را مشاهده خواهیم کرد:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

ما به جدول ارسال در br-int در محاسبه-0 نگاه می کنیم:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ترافیک باید به پورت 2 برود - بیایید ببینیم چه نوع پورتی است:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

این Patch-tun است - یعنی رابط در br-tun. بیایید ببینیم چه اتفاقی برای بسته در br-tun می افتد:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

بسته در VxLAN بسته بندی شده و به پورت 2 ارسال می شود. بیایید ببینیم پورت 2 به کجا منتهی می شود:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

این یک تونل vxlan در compute-1 است:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

بیایید به compute-1 برویم و ببینیم بعداً با بسته چه اتفاقی می‌افتد:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

مک در جدول ارسال br-int در compute-1 قرار دارد و همانطور که از خروجی بالا مشخص است، از طریق پورت 2 که پورت به سمت br-tun است قابل مشاهده است:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

خوب، سپس می بینیم که در br-int در compute-1 یک پاپیون مقصد وجود دارد:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

یعنی بسته دریافتی به پورت 3 پرواز می کند که در پشت آن یک ماشین مجازی instance-00000003 وجود دارد.

زیبایی استقرار Openstack برای یادگیری در زیرساخت مجازی این است که می‌توانیم به راحتی ترافیک بین هایپروایزرها را ضبط کنیم و ببینیم با آن چه اتفاقی می‌افتد. این کاری است که اکنون انجام خواهیم داد، tcpdump را در پورت vnet به سمت compute-0 اجرا کنیم:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

خط اول نشان می دهد که Patek از آدرس 10.0.1.85 به آدرس 10.0.1.88 (ترافیک ICMP) می رود و در یک بسته VxLAN با vni 22 پیچیده شده است و بسته از میزبان 192.168.255.19 (compute-0) به میزبان 192.168.255.26 می رود. .1 ( محاسبه-XNUMX). ما می توانیم بررسی کنیم که VNI با آنچه در ovs مشخص شده است مطابقت دارد.

بیایید به این خط برگردیم: actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 در سیستم اعداد هگزا دسیمال vni است. بیایید این عدد را به سیستم دهم تبدیل کنیم:

16 = 6*16^0+1*16^1 = 6+16 = 22

یعنی vni با واقعیت مطابقت دارد.

خط دوم ترافیک برگشتی رو نشون میده خوب توضیحش فایده نداره اونجا همه چیز مشخصه.

دو ماشین در شبکه های مختلف (مسیریابی بین شبکه ای)

آخرین مورد برای امروز، مسیریابی بین شبکه ها در یک پروژه با استفاده از یک روتر مجازی است. ما در حال بررسی یک مورد بدون DVR هستیم (در مقاله دیگری به آن نگاه خواهیم کرد)، بنابراین مسیریابی در گره شبکه رخ می دهد. در مورد ما، گره شبکه در یک موجودیت جداگانه قرار نمی گیرد و روی گره کنترل قرار دارد.

ابتدا، بیایید ببینیم که مسیریابی کار می کند:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

از آنجایی که در این حالت بسته باید به دروازه برود و در آنجا مسیریابی شود، باید آدرس poppy دروازه را پیدا کنیم، که برای آن به جدول ARP در مثال نگاه می کنیم:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

حالا بیایید ببینیم ترافیک با مقصد (10.0.1.254) fa:16:3e:c4:64:70 باید به کجا ارسال شود:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

بیایید نگاه کنیم که پورت 2 به کجا منتهی می شود:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

همه چیز منطقی است، ترافیک به سمت br-tun می رود. بیایید ببینیم که در کدام تونل vxlan پیچیده می شود:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

پورت سوم یک تونل vxlan است:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

که به گره کنترل نگاه می کند:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ترافیک به گره کنترل رسیده است، بنابراین باید به آن برویم و ببینیم مسیریابی چگونه انجام می شود.

همانطور که به یاد دارید، گره کنترل داخل دقیقاً شبیه به گره محاسباتی بود - همان سه پل، فقط br-ex یک پورت فیزیکی داشت که از طریق آن گره می توانست ترافیک را به خارج ارسال کند. ایجاد نمونه‌ها پیکربندی گره‌های محاسباتی را تغییر داد - پل لینوکس، iptables و رابط‌ها به گره‌ها اضافه شدند. ایجاد شبکه ها و یک روتر مجازی نیز اثر خود را در پیکربندی گره کنترل به جا گذاشت.

بنابراین، بدیهی است که آدرس MAC دروازه باید در جدول ارسال br-int در گره کنترل باشد. بیایید بررسی کنیم که وجود دارد و به کجا نگاه می کند:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

مک از پورت qr-0c52b15f-8f قابل مشاهده است. اگر به لیست پورت های مجازی در Openstack برگردیم، از این نوع پورت برای اتصال دستگاه های مجازی مختلف به OVS استفاده می شود. به طور دقیق تر، qr یک پورت به روتر مجازی است که به عنوان یک فضای نام نمایش داده می شود.

بیایید ببینیم چه فضاهای نامی در سرور وجود دارد:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

به اندازه سه نسخه. اما با قضاوت بر اساس نام، می توانید هدف هر یک از آنها را حدس بزنید. بعداً به نمونه‌هایی با ID 0 و 1 باز خواهیم گشت، اکنون به فضای نام qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe علاقه مندیم:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

این فضای نام شامل دو فضای داخلی است که قبلا ایجاد کردیم. هر دو پورت مجازی به br-int اضافه شده اند. بیایید آدرس مک پورت qr-0c52b15f-8f را بررسی کنیم، زیرا ترافیک، با قضاوت بر اساس آدرس مک مقصد، به این رابط رفت.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

یعنی در این حالت همه چیز طبق قوانین مسیریابی استاندارد کار می کند. از آنجایی که ترافیک برای میزبان 10.0.2.8 است، باید از طریق واسط دوم qr-92fa49b5-54 خارج شود و از طریق تونل vxlan به گره محاسباتی برود:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

همه چیز منطقی است، بدون تعجب. بیایید ببینیم آدرس poppy میزبان 10.0.2.8 در br-int کجا قابل مشاهده است:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

همانطور که انتظار می رود، ترافیک به br-tun می رود، بیایید ببینیم که ترافیک به کدام تونل می رود:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ترافیک برای محاسبه-1 به داخل تونل می رود. خوب، در compute-1 همه چیز ساده است - از br-tun بسته به br-int و از آنجا به رابط ماشین مجازی می رود:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

بیایید بررسی کنیم که این واقعاً رابط صحیح است:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

در واقع، ما تمام راه را از طریق بسته رفتیم. فکر می کنم متوجه شده اید که ترافیک از تونل های مختلف vxlan عبور کرده و با VNI های مختلف خارج می شود. بیایید ببینیم اینها چه نوع VNI هستند، پس از آن یک Dump در پورت کنترل گره جمع آوری می کنیم و مطمئن می شویم که ترافیک دقیقاً همانطور که در بالا توضیح داده شد جریان دارد.
بنابراین، تونل برای محاسبه-0 اقدامات زیر را دارد=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],خروجی:3. بیایید 0x16 را به سیستم اعداد اعشاری تبدیل کنیم:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

تونل محاسبه-1 دارای VNI زیر است:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],خروجی:2. بیایید 0x63 را به سیستم اعداد اعشاری تبدیل کنیم:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

خوب، حالا بیایید به روگرفت نگاه کنیم:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

بسته اول یک بسته vxlan از میزبان 192.168.255.19 (compute-0) تا میزبان 192.168.255.15 (control-1) با vni 22 است که در داخل آن بسته ICMP از میزبان 10.0.1.85 به میزبان 10.0.2.8 بسته بندی شده است. همانطور که در بالا محاسبه کردیم، vni با آنچه در خروجی دیدیم مطابقت دارد.

بسته دوم یک بسته vxlan از میزبان 192.168.255.15 (control-1) به میزبان 192.168.255.26 (compute-1) با vni 99 است که در داخل آن بسته ICMP از میزبان 10.0.1.85 به میزبان 10.0.2.8 بسته بندی شده است. همانطور که در بالا محاسبه کردیم، vni با آنچه در خروجی دیدیم مطابقت دارد.

دو بسته بعدی ترافیک برگشتی از 10.0.2.8 هستند نه 10.0.1.85.

یعنی در نهایت ما طرح گره کنترل زیر را دریافت کردیم:

به نظر می رسد این است؟ ما دو فضای نام را فراموش کردیم:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

همانطور که در مورد معماری پلتفرم ابری صحبت کردیم، اگر ماشین‌ها آدرس‌ها را به صورت خودکار از یک سرور DHCP دریافت کنند، خوب است. اینها دو سرور DHCP برای دو شبکه ما 10.0.1.0/24 و 10.0.2.0/24 هستند.

بیایید بررسی کنیم که این درست است. فقط یک آدرس در این فضای نام وجود دارد - 10.0.1.1 - آدرس خود سرور DHCP، و همچنین در br-int گنجانده شده است:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

بیایید ببینیم که آیا فرآیندهای حاوی qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 به نام خود در گره کنترل هستند یا خیر:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

چنین فرآیندی وجود دارد و بر اساس اطلاعات ارائه شده در خروجی بالا، می‌توانیم به عنوان مثال ببینیم در حال حاضر چه چیزی برای اجاره داریم:

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

در نتیجه، مجموعه خدمات زیر را در گره کنترل دریافت می کنیم:

خوب، به خاطر داشته باشید - این فقط 4 ماشین، 2 شبکه داخلی و یک روتر مجازی است... ما الان اینجا شبکه خارجی نداریم، یکسری پروژه های مختلف، هر کدام با شبکه های خاص خود (همپوشانی) و ما داریم یک روتر توزیع شده خاموش شد و در نهایت فقط یک گره کنترل در میز تست وجود داشت (برای تحمل خطا باید حد نصاب سه گره وجود داشته باشد). منطقی است که در تجارت همه چیز "کمی" پیچیده تر است، اما در این مثال ساده می دانیم که چگونه باید کار کند - اینکه 3 یا 300 فضای نام دارید البته مهم است، اما از نقطه نظر عملکرد کل ساختار، هیچ چیز تغییر زیادی نخواهد کرد... هرچند تا زمانی که برخی از SDN های فروشنده را وصل نکنید. اما این یک داستان کاملا متفاوت است.

امیدوارم جالب بوده باشه اگر نظر/اضافه‌ای دارید، یا جایی که من کاملاً دروغ گفته‌ام (من انسان هستم و نظر من همیشه ذهنی خواهد بود) - آنچه را که باید اصلاح شود/اضافه شود بنویسید - ما همه چیز را اصلاح می‌کنیم/ اضافه می‌کنیم.

در پایان، من می خواهم چند کلمه در مورد مقایسه Openstack (هم وانیلی و هم فروشنده) با راه حل ابری VMWare بگویم - در چند سال گذشته این سؤال از من بسیار پرسیده شده است و صادقانه بگویم، من قبلاً از آن خسته شده ام، اما هنوز به نظر من مقایسه این دو راه حل بسیار دشوار است، اما به طور قطع می توان گفت که در هر دو راه حل معایبی وجود دارد و هنگام انتخاب یک راه حل باید جوانب مثبت و منفی را بسنجید.

اگر OpenStack یک راه حل جامعه محور است، پس VMWare حق دارد فقط آنچه را که می خواهد انجام دهد (بخوانید - چه چیزی برای آن سودآور است) و این منطقی است - زیرا یک شرکت تجاری است که عادت دارد از مشتریان خود درآمد کسب کند. اما یک چیز بزرگ و چاق وجود دارد - شما می توانید از OpenStack خارج شوید، به عنوان مثال از نوکیا، و با هزینه کمی به راه حلی مانند Juniper (Contrail Cloud) بروید، اما بعید است که بتوانید از VMWare خارج شوید. . برای من، این دو راه حل شبیه این هستند - Openstack (فروشنده) یک قفس ساده است که شما در آن قرار می گیرید، اما شما یک کلید دارید و می توانید هر زمان که بخواهید آن را ترک کنید. VMWare یک قفس طلایی است، صاحبش کلید قفس را دارد و هزینه زیادی برای شما خواهد داشت.

من نه محصول اول و نه دوم را تبلیغ نمی کنم - شما آنچه را که نیاز دارید انتخاب می کنید. اما اگر چنین انتخابی داشتم، هر دو راه‌حل را انتخاب می‌کردم - VMWare برای ابر فناوری اطلاعات (بارگیری کم، مدیریت آسان)، OpenStack از برخی فروشنده‌ها (Nokia و Juniper راه‌حل‌های کلید در دست بسیار خوبی ارائه می‌دهند) - برای ابر مخابراتی. من از Openstack برای فناوری اطلاعات خالص استفاده نمی‌کنم - مانند تیراندازی به گنجشک‌ها با توپ است، اما هیچ منع مصرفی برای استفاده از آن به جز افزونگی نمی‌بینم. با این حال، استفاده از VMWare در مخابرات مانند حمل سنگ خرد شده در فورد رپتور است - از بیرون زیبا است، اما راننده باید به جای یک سفر، 10 سفر انجام دهد.

به نظر من، بزرگترین نقطه ضعف VMWare بسته بودن کامل آن است - شرکت هیچ اطلاعاتی در مورد نحوه کار آن به شما نمی دهد، به عنوان مثال، vSAN یا آنچه در هسته هایپروایزر وجود دارد - به سادگی برای آن سودی ندارد - یعنی شما این کار را خواهید کرد. هرگز در VMWare متخصص نشوید - بدون پشتیبانی فروشنده، شما محکوم به فنا هستید (بسیار اوقات من با کارشناسان VMWare ملاقات می کنم که با سؤالات بی اهمیت گیج می شوند). برای من، VMWare ماشینی با کاپوت قفل می‌خرد - بله، ممکن است متخصصانی داشته باشید که بتوانند تسمه تایم را عوض کنند، اما فقط کسی که این راه حل را به شما فروخته است می‌تواند کاپوت را باز کند. من شخصاً راه حل هایی را که نمی توانم در آن جا بیاورم دوست ندارم. شما خواهید گفت که ممکن است مجبور نباشید زیر کاپوت بروید. بله، این امکان پذیر است، اما زمانی به شما نگاه خواهم کرد که بخواهید یک تابع بزرگ را در فضای ابری از 20-30 ماشین مجازی، 40-50 شبکه جمع آوری کنید، که نیمی از آنها می خواهند به بیرون بروند، و نیمه دوم درخواست می کند. شتاب SR-IOV، در غیر این صورت به دوجین خودرو بیشتر نیاز خواهید داشت - در غیر این صورت عملکرد کافی نخواهد بود.

دیدگاه های دیگری نیز وجود دارد، بنابراین فقط شما می توانید تصمیم بگیرید که چه چیزی را انتخاب کنید و مهمتر از همه، شما مسئول انتخاب خود خواهید بود. این فقط نظر من است - شخصی که حداقل 4 محصول را دیده و لمس کرده است - نوکیا، جونیپر، ردهت و VMWare. یعنی چیزی برای مقایسه دارم.

منبع: www.habr.com