دوره آموزشی SDN (قسمت دوم) – کنترلر

با سلام و عرض خسته‌نباشید خدمت همه دوستان عزیز؛ در ادامه قسمت قبلی از این سری آموزشی،امروز با مبحث کنترلر (Controller)ها، معماری‌توزیع‌شده و معماری‌متمرکز در خدمت‌شما هستم. در حدود سال 2010، رویکردهای جدید مربوط به شبکه‌های کامپیوتری ظهور کردند؛ رویکردهایی که محل تعدادی از توابع Control-planeهارا تغییر میدادند؛ بسیاری از این رویکردها، قسمت‌هایی از عملکرد Control-planeهارا وارد یک نرم‌افزار Centralizedشده به اسم کنترلر (Controller) کردند که در ادامه میخواهیم با مفاهیم مربوط به کنترلرها و معماری‌های شبکه آشنا شویم. با من همراه باشید ;).

کنترلرها و کنترل‌متمرکز(Controllers and Centralized Control)

اکثر پردازش‌های Control-planeهای سُنتی از یک معماری‌توزیع‌شده(Distributed Architecture) استفاده میکنند، یعنی اینکه Control-plane توزیع میشود و روی Deviceهای گوناگون اجرا میشود؛ برای مثال هر روتر، Processـه مربوط به Routing Protocolـه OSPFـه خودش را بصورت جداگانه اجرا میکند. آن Processهای مربوط به Control-planeهای توزیع‌شده، برای درست‌کار کردن از ارسال پیام به یکدیگر برای ارتباط(Communicate) استفاده میکنند؛ مثلا پروتکل OSPF که در بین روترهای خود، پیغام‌ها و پکت‌ها گوناگونی رد و بدل میکند. درنتیجه میتوان اظهار داشت که شبکه‌های سُنتی، از یک Distributed Control-plane استفاده می‌کنند.

افرادی که مفاهیم Control-planeهای امروزی مانند STP،OSPF،EIGRP و... را ایجاد کرده‌اند، میتوانستند تصمیم بگیرند که از یک Control-planـه متمرکز استفاده کنند و منطق را در یک نقطه(دیوایس ویا سرور) قراردهند و لازم نباشد که پراسس‌های مربوط به Control-planeها، روی هر دیوایسی بصورت جداگانه اجرا شود؛ و در ادامه، نرم‌افزار مرکزی هم میتوانست با استفاده از پروتکل‌های مربوط به Messaging، اطلاعات گوناگون را از هر دیوایسی که میخواهد بدست آورد اما پردازش‌های مربوط به آنهارا در یک نقطه مرکزی(که میتواند دید وسیع‌تری نسبت به شبکه داشته‌باشد) انجام دهد؛ اما خب آنها تصمیم گرفتند که بجای این راهکار، از یک معماری‌توزیع‌شده استفاده کنند.

برای انجام هرعملکردی در شبکه، مزایا و معایب گوناگونی برای معماری‌های توزیع‌شده و متمرکز وجود دارد؛ بسیاری از Control-planeها ، دارای سابقه طولانی و خوبی در "عملکرد در معماری‌توزیع‌شده" میباشند. به‌هرحال یک نوشتن یک اپلیکیشن متمرکز، بسیار آسان‌تر از نوشتن یک اپلیکشن توزیع‌شده میباشد؛ چراکه اپلیکیشن متمرکز، تمامی اطلاعات و موارد موردنیازش را در یک نقطه و بصورت آماده، دارد؛ حالا میتوان گفت که این دنیای‌نوظهورِ SDN و Network Programmability عموما از یک معماری متمرکز  و توابع و عملکردهای مربوط بهش در سرویسی به‌نام کنترلر (Controller)، استفاده میکند.

یک کنترلر ویا یک SDNکنترلر(SDN Controller)، کنترل تجهیزات شبکه را، متمرکز میکند؛ اینکه چه‌مواردی، به چه اندازه‌ای Centralized بشوند، میتواند متفاوت باشد. برای شرح بیشتر ایده ی یک کنترلر، تصویر زیر را درنظر بگیرید، یک SDN Controller تمامی عملکردهای مهم Control-plane را متمرکز کرده‌است.

در ابتدا، Controller درجایی از شبکه قرار میگیرد که بتواند به تمامی Devicesهای داخل‌شبکه از طریق IP دسترسی داشته‌باشد و بتواند آنهارا ببیند؛ همچنان هرکدام از دیوایس‌های شبکه، دارای یک Data-plane میباشند اما درنظر داشته‌باشید که هیچکدام از آنها دارای Control-plane نمیباشند. در تغییرات مربوط به SDN(همانطور که در شکل میبینید) ، کنترلر(یا برنامه‌ای که از Controller استفاده میکند) بصورت مستقیم تمامی Data-plane Entryهای جداول هر Deviceرا برنامه‌ریزی و مقداردهی میکند و دیگر دیوایس‌های ما جداول مربوط به Forwardingاشان را با استفاده از پردازش‌های سُنتی Control-planeتوزیع‌شده پُر نمیکنند.

شکل فوق، فقط یک مدل از network programmability و SDN را نمایش‌میدهد، درحالی که موارد دیگری‌هم وجود دارند؛ این تصویر به ما پیش‌زمینه خوبی برای صحبت کردن درمورد کانسپت‌ها و مفاهیم مهم دیگر میدهد، بخصوص درمورد ایده‌های Southbound Interface(به اختصار SBI) و Northbound Interface(به اختصار NBI) که در ادامه قصد داریم که درموردشان صحبت کنیم.

The Southbound Interface

در یک معماری شبکه برپایه کنترلر، کنترلر نیاز به صحبت‌کردن و ارتباط با دیوایس‌های داخل‌شبکه دارد؛ مثل تصویری که در بالا به شما نشان دادیم، عموما Networking Deviceها در نقشه‌ها و مستندات طراحی‌ و معماری‌های‌شبکه در زیر Controller قرار میگیرند، در بین کنترلر و دیوایس‌های‌شبکه یک Interface قرار دارد و با توجه به محل آن اینترفیس در شکل، به آن اینترفیس Southbound Interface یا SBI گفته میشود.

نکته: درحالت عادی، کلمه Interface به کانکتور فیزیکی‌ای بروی روترها و سوئیچ‌ها نسبت داده میشود، اما در این مبحث، کلمه Interface(که در داخل SBI،NBIوAPI هم قرار دارد) به رابطها و اینترفیس‌های نرم‌افزاری نسبت داده‌میشود.

ـ Application Programming Interface یاهمان API، متدی برای انتقال و جابجایی اطلاعات بین 2 اپلیکیشن میباشد یا اگر بخواهیم به‌شکل دیگری تعریفش را بیان کنیم، بایستی گفت که یک API، یک اینترفیس به یک اپلیکشن میباشد؛ برنامه‌ها داده‌هارا پردازش میکنند و API به آنها اجازه میدهد که داده‌هایشان را جابجا کنند. پروتکل‌ها عموما بایک ساختار و بدنه مشخص و مستندشده عمل میکنند، اما API عموما دارای کدها، توابع،متغییرها و ساختمان‌داده‌های گوناگون میباشند، که برنامه دیگری درداخل شبکه میتواند از آنها استفاده کند.

بگذارید به همان SBI برگردیم؛ SBI یک اینترفیس بین کنترلر و نرم‌افزار روی دیوایس‌های‌شبکه است و اجازه میدهد که این دو بایکدیگر ارتباط داشته‌باشند، با این هدف که کنترلر بتواند Data-plane دیوایس را مدیریت کند. دریک معماری‌شبکه که برای Network Programmability ایجاد شده‌است، قابلیت‌های SBIها و APIهایشان، اطلاعات زیادی از توانایی‌ها و ضعف‌هایشان در اختیار ما قرار میدهند؛ برای مثال ممکن است بعضی از کنترلرها برای یکسری اهداف خاص، فقط اجازه استفاده از یک SBI (یا تعداد کم) را بدهند، درصورتی که بقیه موارد از تعداد زیادی SBI پشتیبانی میکنند و دست‌مارا در استفاده از SBIها باز میگذارند. مقایسه انواع SBIها، توضیحات و جزئیات مربوط به خودش را دارد که از حوصله این مطلب خارج است. در ادامه به شما 3 نمونه از معماری‌ها را معرفی میکنیم که بصورت اتفاقی، SBIهای گوناگونی هم دارند:

• ـ Openflow(از ONF)
• ـ OpFlex(از Cisco؛ توسط ACI استفاده میشود)
• ـ CLI(تلنت/SSH و SNMP؛ از Cisco؛ توسط APIC-EM استفاده میشود)

The Northbound Interface

به پیش‌نیازهای برنامه‌نویسی که برای کنترلر موجود در عکس‌قبلی نیاز میباشد فکر کنید، تمرکز تصویر بر این‌است که به شما نشان دهد که کنترلر میتواند به Forwarding tableهای دیوایس‌ها Entry اضافه کند؛ اما سوال اینجاست که کنترلر از کجا میداند که چه‌چیزی را میبایستی به جدول‌ها اضافه کند؟ به چه صورت عمل میکند؟ قبل از اضافه کردن مقادیر، کنترلر شما به چه موارد و اطلاعاتی نیاز دارد تا بتواند مقداری را Addکند؟ احتمالا این موارد به ذهنتان میرسد:

• یک لیست از تمامی دیوایس‌ها در شبکه
• قابلیت‌های هر دیوایس(capabilities)
• اینترفیس‌ها و پورت‌های هر دیوایس
• وضعیت‌فعلی هر پورت
• توپولوژی: هر دیوایس به چه‌جاهایی(دیوایس‌های دیگر) وصل شده‌است و بروی کدام اینترفیس‌ها این ارتباط را برقرار کرده‌اند.
• پیکربندی فعلی دیوایس: IP Addressها، VLANها و الی آخر... .

در یک مدل کنترل‌متمرکز، کنترلر اکثر کارهای موردنیاز و مربوط به Control-planeرا انجام میدهد و تمامی اطلاعات مفید را از شبکه جمع‌آوری میکند(مثل مواردی که در لیست بالا مطرح شد) و در نهایت، خود کنترلر به تنهایی میتواند repository یا مخزنی‌متمرکز از این اطلاعات، برای شبکه، ایجاد کند.

ـ NBIـه یک کنترلر بصورتی است که راه ارتباط مستقیم با کنترلر را برقرار میکند تا برنامه‌های دیگر بتوانند از دیتا و توابعش استفاده کنند. برنامه‌های گوناگون میتوانند اطلاعات گوناگونی را با استفاده از APIـه کنترلر، استخراج نمایند و همچنین NBI به برنامه‌ها اجازه میدهد که با استفاده از SBI از قابلیت‌های Controller در ارسال جریان ترافیکی به دیوایس‌ها استفاده کنند.

برای اینکه ببینید NBI در کجا قرار میگیرد، در ابتدا درمورد خود Controller فکر کنید...، کنترلرِ ما یک نرم‌افزار است که بروی یک سرور اجرا شده‌است(که میتواند یک VM ویا یک سرور فیزیکی باشد)؛ یک اپلیکیشن میتواند بروی همان سروری که کنترلر قرار دارد اجرا شود و از یک NBI استفاده کند، ودر نتیجه هردو نرم‌افزار میتوانند با یکدیگر صحبت کنند(با استفاده از API).

برای مثال به شکل زیر توجه کنید؛ مستطیل نارنجی رنگ نشان‌دهنده محل استقرار "نرم‌افزار کنترلر" میباشد؛ در این مثال ما کنترلر ما با استفاده‌از زبان Java نوشته‌شده است و یک دارای یک Java-based Native API میباشد. هرکسی میتواند براحتی اپلیکیشنی بنویسد که بروی این سیستم اجرا شود و از Java API کنترلر استفاده کند. با استفاده از آن API، اپلیکیشن میتواند اطلاعات گوناگونی درمورد شبکه بدست آورد؛ همچنین اپلیکشن میتواند که جریان‌های شبکه را مدیریت کند؛ کافی‌است از کنترلر بخواهد تا Action خاصی را در Forwarding tableهای دیوایس‌ها انجام دهد.

نکته: NBI بر اساس محل قرارگیری در نقشه(بالای کنترلر) نامگذاری میشود، فقط کافیست که بدانید که شمال نقشه شما کجا میابشد. به همین راحتی!

قبل از اینکه از بحث مربوط به NBIها خارج شویم، بگذارید نگاهی نزدیکتر به دیگر APIهایی که برای یک کنترلر استفاده میگردند داشته باشیم؛ Representational State Transfer (به اختصار REST) نوعی API میباشد که به اپلیکیشن‌ها اجازه میدهد بروی Hostهای مختلفی قرار بگیرند و از HTTP برای انتقال پیغام بر بستر API استفاده میکند.

وقتی که شما نمونه‌های مربوط به SDN که با "یک اپلیکیشن بروی همان سیستم کنترلر" همراه است را میبینید(مانند تصویر بالا)؛ در این شرایط نیازی نیست که API پیغام‌هارا بر بستر شبکه ارسال کند، چراکه هردو برنامه بروی یک سیستم مشترک اجرا شده‌اند. اما وقتی که اپلیکیشن‌های ما بروی سرورها و سیستم‌های جدا از هم قرار گرفته باشند، نیاز است که API بتواند داده‌هارا بر بستر IP ارسال و دریافت کند، و اینجاست که RESTFUL APIها به کمک ما می‌آیند.

شکل زیر، ایده اصلی REST API را نشان میدهد؛ اپلیکیشن بروی یک Host دیگر در بالای تصویر اجرا میشود و در این مثال، در مرحله اول، به یک URI خاص یک درخواست HTTP GET ارسال میکند. URI برای شناسایی یک Object بروی کنترلر استفاده میشود؛ برای مثال ممکن است که URI ما لیستی از اینترفیس‌های فیزیکی یک دیوایس به همراه وضعیت هریک از آنها باشد.

در مرحله دوم، کنترلر پیغام بازگشتی را بصورت یک HTTP GET Response message به همراه Object ارسال میکند؛ اکثر REST APIها، درخواست دریافت یک داده‌ی ساختاریافته را میکنند و عموما از فرمت‌های مانند XML یا JSON برای Network programmability استفاده میکنند(مثل مرحله سوم در شکل فوق).

امیدوارم که این قسمت براتون مفید واقع شده باشه...

موفق باشید.