پارچه شبکه برای مرکز داده Cisco ACI - برای کمک به مدیر

با کمک این قطعه جادویی اسکریپت Cisco ACI، می توانید به سرعت یک شبکه راه اندازی کنید.

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

چیست و از کجا آمده است؟

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

از یک طرف، راه‌حل‌های SDN «نسل اول» مبتنی بر OpenFlow وعده داده بودند که شبکه‌ها را انعطاف‌پذیرتر و در عین حال ارزان‌تر کنند. ایده این بود که تصمیم گیری که به طور سنتی توسط نرم افزار سوئیچ اختصاصی انجام می شد به یک کنترل کننده مرکزی منتقل شود.

این کنترلر یک دید واحد از هر اتفاقی خواهد داشت و بر این اساس، سخت افزار تمام سوئیچ ها را در سطح قوانینی برای پردازش جریان های خاص برنامه ریزی می کند.
از سوی دیگر، راه حل های شبکه همپوشانی، اجرای سیاست های اتصال و امنیت لازم را بدون هیچ تغییری در شبکه فیزیکی، ایجاد تونل های نرم افزاری بین هاست های مجازی شده امکان پذیر می کند. شناخته شده ترین نمونه از این رویکرد Nicira بود که در آن زمان توسط VMWare به مبلغ 1,26 میلیارد دلار خریداری شده بود و باعث ایجاد VMWare NSX فعلی شد. با این واقعیت که بنیانگذاران Nicira همان افرادی بودند که قبلاً در منشأ OpenFlow ایستاده بودند، اکنون می گویند که برای ایجاد یک کارخانه مرکز داده، برخی از موارد تلخ به وضعیت اضافه شد. OpenFlow مناسب نیست.

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

ACI به "پاسخ نامتقارن" سیسکو (به طور دقیق تر، شرکت Insieme آن که توسط کارمندان سابقش تأسیس شده است) به همه موارد فوق تبدیل شده است.

تفاوت با OpenFlow چیست؟

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

ACI از رویکرد معکوس استفاده می کند: البته، یک کنترلر نیز وجود دارد، اما سوئیچ ها سیاست های اعلامی سطح بالایی را از آن دریافت می کنند و خود سوئیچ رندر آنها را به جزئیات تنظیمات خاص در سخت افزار انجام می دهد. می توان کنترلر را دوباره راه اندازی کرد یا به طور کلی خاموش کرد و هیچ اتفاق بدی برای شبکه نخواهد افتاد، البته به جز عدم کنترل در این لحظه. جالب اینجاست که موقعیت‌هایی در ACI وجود دارد که در آن OpenFlow هنوز استفاده می‌شود، اما به صورت محلی در میزبان برای برنامه‌نویسی Open vSwitch.

ACI به طور کامل بر روی انتقال همپوشانی مبتنی بر VXLAN ساخته شده است، اما شامل انتقال IP اساسی به عنوان بخشی از یک راه حل واحد است. سیسکو این را اصطلاح "همپوشانی یکپارچه" نامید. به عنوان نقطه پایانی برای همپوشانی در ACI، در بیشتر موارد، از سوئیچ های کارخانه استفاده می شود (آنها این کار را با سرعت پیوند انجام می دهند). هاست ها نیازی به دانستن چیزی در مورد کارخانه، کپسولاسیون و غیره ندارند، با این حال، در برخی موارد (مثلاً برای اتصال هاست های OpenStack)، می توان ترافیک VXLAN را به آنها منتقل کرد.

پوشش‌ها در ACI نه تنها برای ارائه اتصال انعطاف‌پذیر از طریق شبکه حمل‌ونقل، بلکه برای انتقال اطلاعات فرااطلاعاتی (مثلاً برای اعمال سیاست‌های امنیتی استفاده می‌شود).

تراشه‌های Broadcom قبلاً توسط سیسکو در سوئیچ‌های سری Nexus 3000 استفاده می‌شد. در خانواده Nexus 9000 که به‌ویژه برای پشتیبانی از ACI منتشر شد، ابتدا یک مدل ترکیبی پیاده‌سازی شد که Merchant + نام داشت. این سوئیچ به طور همزمان از تراشه جدید Broadcom Trident 2 و یک تراشه مکمل توسعه یافته توسط Cisco استفاده کرد که تمام جادوی ACI را پیاده سازی می کند. ظاهراً این امر امکان تسریع در عرضه محصول و کاهش قیمت سوئیچ را به سطحی نزدیک به مدل‌های مبتنی بر Trident 2 می‌دهد. این رویکرد برای دو یا سه سال اول تحویل ACI کافی بود. در این مدت، سیسکو نسل بعدی Nexus 9000 را بر روی تراشه های خود با عملکرد و مجموعه ویژگی های بیشتر، اما در همان سطح قیمت، توسعه و روانه بازار کرده است. مشخصات خارجی از نظر تعامل در کارخانه کاملاً حفظ شده است. در همان زمان، پر کردن داخلی به طور کامل تغییر کرده است: چیزی شبیه به بازسازی، اما برای آهن.

معماری Cisco ACI چگونه کار می کند

در ساده ترین حالت، ACI بر اساس توپولوژی شبکه Klose یا همانطور که اغلب می گویند Spine-Leaf ساخته شده است. سوئیچ های سطح ستون فقرات می توانند از دو (یا یک، اگر به تحمل خطا اهمیتی نمی دهیم) تا شش باشند. بر این اساس، هرچه تعداد آنها بیشتر باشد، تحمل خطا (کاهش پهنای باند و قابلیت اطمینان در صورت تصادف یا نگهداری یک ستون فقرات کمتر) و عملکرد کلی بالاتر است. همه اتصالات خارجی به سوئیچ‌های سطح برگ می‌روند: اینها سرورها و اتصال به شبکه‌های خارجی از طریق L2 یا L3 و اتصال کنترل‌کننده‌های APIC هستند. به طور کلی، با ACI، نه تنها پیکربندی، بلکه جمع آوری آمار، نظارت بر خرابی و غیره نیز انجام می شود - همه چیز از طریق رابط کنترلرها انجام می شود که سه مورد از آنها در اندازه استاندارد اجرا می شود.

شما هرگز نیازی به اتصال به سوئیچ ها با کنسول ندارید، حتی برای راه اندازی شبکه: خود کنترل کننده سوئیچ ها را شناسایی می کند و کارخانه ای را از آنها جمع آوری می کند، از جمله تنظیمات تمام پروتکل های خدمات، بنابراین، به هر حال، بسیار مهم است که شماره سریال تجهیزات در حال نصب را در حین نصب یادداشت کنید تا بعداً مجبور نباشید حدس بزنید کدام سوئیچ در کدام رک قرار دارد. برای عیب یابی، در صورت لزوم، می توانید از طریق SSH به سوئیچ ها متصل شوید: آنها دستورات نمایش معمول سیسکو را با دقت کامل بازتولید می کنند.

در داخل، کارخانه از حمل و نقل IP استفاده می کند، بنابراین درخت پوشاننده و سایر وحشت های گذشته در آن وجود ندارد: همه پیوندها درگیر هستند و همگرایی در صورت خرابی بسیار سریع است. ترافیک در پارچه از طریق تونل های مبتنی بر VXLAN منتقل می شود. به طور دقیق‌تر، سیسکو خود iVXLAN را کپسوله‌سازی می‌نامد و تفاوت آن با VXLAN معمولی در این است که از فیلدهای رزرو شده در هدر شبکه برای انتقال اطلاعات سرویس، عمدتاً در مورد ارتباط ترافیک با گروه EPG استفاده می‌شود. این به شما امکان می دهد قوانین تعامل بین گروه ها را در تجهیزات پیاده سازی کنید، با استفاده از شماره آنها به همان روشی که آدرس ها در لیست های دسترسی معمولی استفاده می شود.

تونل ها به هر دو بخش L2 و L3 (یعنی VRF) اجازه می دهند که از طریق انتقال IP داخلی کشیده شوند. در این حالت، دروازه پیش فرض توزیع می شود. این بدان معناست که هر سوئیچ وظیفه هدایت ترافیک ورودی به فابریک را بر عهده دارد. از نظر منطق جریان ترافیک، ACI شبیه به فابریک VXLAN/EVPN است.

اگر چنین است، چه تفاوت هایی وجود دارد؟ همه چیز دیگر!

تفاوت شماره یک شما با ACI نحوه اتصال سرورها به شبکه است. در شبکه‌های سنتی، گنجاندن سرورهای فیزیکی و ماشین‌های مجازی به VLAN‌ها می‌رود و هر چیز دیگری از آن‌ها جدا می‌شود: اتصال، امنیت و غیره. در ACI از طرحی استفاده می‌شود که سیسکو آن را EPG (End-point Group) می‌نامد. جایی برای فرار وجود ندارد آیا می توان آن را با VLAN برابر کرد؟ بله، اما در این مورد شانس از دست دادن بیشتر آنچه ACI می دهد وجود دارد.

در رابطه با EPG تمامی قوانین دسترسی فرموله شده است و در ACI به طور پیش فرض از اصل “لیست سفید” استفاده می شود، یعنی فقط ترافیک مجاز است که عبور از آن به صراحت مجاز است. یعنی می‌توانیم گروه‌های EPG «Web» و «MySQL» را ایجاد کنیم و قاعده‌ای تعریف کنیم که فقط در پورت 3306 بین آنها ارتباط برقرار کند.

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

قوانین ترافیکی در ACI قرارداد نامیده می شود. در چنین قراردادی، یک یا چند گروه یا سطح در یک برنامه چند لایه به ارائه‌دهنده خدمات (مثلاً یک سرویس پایگاه داده) تبدیل می‌شوند، و بقیه به مصرف‌کننده تبدیل می‌شوند. قرارداد می تواند به سادگی ترافیک را منتقل کند، یا می تواند کاری پیچیده تر انجام دهد، به عنوان مثال، آن را به یک فایروال یا متعادل کننده هدایت کند، و همچنین مقدار QoS را تغییر دهد.

چگونه سرورها وارد این گروه ها می شوند؟ اگر اینها سرورهای فیزیکی یا چیزی هستند که در یک شبکه موجود گنجانده شده است که ما در آن یک VLAN Trunk ایجاد کرده ایم، برای قرار دادن آنها در EPG، باید به پورت سوئیچ و VLAN استفاده شده روی آن اشاره کنید. همانطور که می بینید، VLAN ها در جایی ظاهر می شوند که بدون آنها نمی توانید انجام دهید.

اگر سرورها ماشین های مجازی هستند، کافی است به محیط مجازی سازی متصل مراجعه کنید، و سپس همه چیز خود به خود اتفاق می افتد: یک گروه پورت (از نظر VMWare) برای اتصال VM ایجاد می شود، VLAN ها یا VXLAN های لازم ایجاد می شود. بنابراین، اگرچه ACI حول یک شبکه فیزیکی ساخته شده است، اتصالات برای سرورهای مجازی بسیار ساده تر از اتصالات فیزیکی به نظر می رسد. ACI قبلاً دارای اتصال داخلی با VMWare و MS Hyper-V و همچنین پشتیبانی از OpenStack و RedHat Virtualization است. از نقطه‌ای به بعد، پشتیبانی داخلی برای پلتفرم‌های کانتینر نیز ظاهر شده است: Kubernetes، OpenShift، Cloud Foundry، در حالی که هم مربوط به اعمال خط‌مشی‌ها و هم نظارت است، یعنی مدیر شبکه می‌تواند فوراً ببیند که کدام میزبان‌ها روی کدام پادها کار می‌کنند و در چه گروه هایی قرار می گیرند.

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

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

به طور کلی، منطق کنترل در ACI به هیچ وجه شبیه چیزی نیست که معمولاً مشاهده می کنید
در شبکه‌های سنتی از همان سیسکو: رابط نرم‌افزار اصلی است و GUI یا CLI ثانویه هستند، زیرا از طریق یک API کار می‌کنند. بنابراین، تقریباً همه افراد درگیر در ACI، پس از مدتی، شروع به حرکت در مدل شیء مورد استفاده برای مدیریت می‌کنند و چیزی را متناسب با نیازهای خود خودکار می‌کنند. ساده ترین راه برای انجام این کار از پایتون است: ابزارهای آماده و مناسبی برای آن وجود دارد.

چنگک جمع کن وعده داده شده

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

از نظر قیمت، در مقیاس های بزرگ و متوسط، شبکه های ACI در واقع با شبکه های سنتی تجهیزات سیسکو تفاوتی ندارند، زیرا از همان سوئیچ ها برای ساخت آنها استفاده می شود (Nexus 9000 می تواند در ACI و در حالت سنتی کار کند و اکنون تبدیل به اصلی شده است. "اسب کار" برای پروژه های جدید مرکز داده). اما برای مراکز داده دو سوییچ، البته وجود کنترلرها و معماری Spine-Leaf خود را احساس می کند. اخیراً یک کارخانه Mini ACI ظاهر شده است که در آن دو تا از سه کنترلر با ماشین های مجازی جایگزین شده اند. این تفاوت در هزینه را کاهش می دهد، اما همچنان باقی می ماند. بنابراین برای مشتری، میزان علاقه او به ویژگی‌های امنیتی، یکپارچه‌سازی با مجازی‌سازی، یک نقطه کنترل و غیره تعیین می‌شود.

منبع: www.habr.com