آشنایی با شبکه مبتنی بر نرم افزار با صفحه کنترل توزیعی

با سلام خدمت دوست داران و علاقه مندان دنیای SDN

اگر در شروع کار هستید توصیه می‌کنیم حتما نقشه راه SDN را مطالعه کنید.

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

درحال حاضر پروژه ها و موضوعات مختلفی برای کار با شبکه های SDN با چندین کنترلر موجود می­ باشد، از جمله: توازن بار بین کنترلرهای متعدد، تحمل پذیری خطا، مهندسی ترافیک، سبز کردن و صرفه جویی در مصرف انرژی و منابع موجود در شبکه، مسیریابی و سایر موضوعاتی که ممکن است موضوع کاری خود شما نیز باشد.

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

اهمیت و ضرورت بخش کنترلی توزیع شده

اگرچه  SDN نسبت به شبکه های سنتی، به دلیل بخش کنترلی قابل برنامه ریزی، موثرتر عمل می‌کند و سبب توزیع مناسب بار ترافیک و بهبود کیفیت سرویس و کاهش تاخیر می شود، اما همزمان با رشد شبکه ها وافزایش تعداد سوئیچ ها، تنوع در بار ترافیک، شبکه های SDN با یک کنترلر متمرکز با مشکلاتی روبرو شده اند ازجمله:  نیاز به توان محاسباتی، ذخیره سازی داده و گذردهی بیشتر در یک کنترلر برای تحویل ترافیک، چالش مقیاس پذیری برای شبکه های بزرگ و ترافیک انفجاری در تعداد حالات ارسالی در جداول جریان و تاخیر اضافی و افزایش احتمال خرابی شبکه، پیکربندی ایستای نگاشت بین سوئیچ و یک کنترلر، هم چنین مشکل تنها نقطه شکست که سبب افزایش آسیب پذیری شبکه دربرابر حملات و اختلالات و بی ثباتی شبکه می شود. بنابراین با توجه به محدودیت عملکرد و ظرفیت پردازشی کنترلر واحد و به منظورکاهش نرخ انتقال بخش داده ، استفاده بهینه تر ازمنابع، هم‌چنین رفع چالش هایی مانند: دسترس پذیری، مقیاس پذیری، مشکل تک نقطه شکست (single point of failure)، بروز سربار، کاهش کیفیت سرویس، کاهش گذردهی، عدم استفاده بهینه از منابع و تاخیر انتقالات داده، به خصوص در مراکز داده بزرگ، نیاز به کنترلر توزیع شده جهت دستیابی به مقیاس پذیری و قابلیت اطمینان، به شدت احساس می­ شود.

قابل توجه شما دوستان، که یک نمونه بارز کاربرد این مورد، google  است که مراکز داده خود را در سراسر جهان توزیع کرده ­اند و هماهنگی آن­ها  را بر مبنای SDN بنا نهاده است.

معماری های شبکه های مبتنی بر نرم افزار با صفحه کنترل توزیعی

واژه “متعدد (multiple)” در بخش کنترلی، بیان کننده دو مفهوم کنترلرهای همسان (homogeneous) با ظرفیت های برابر و نقش­های متفاوت، و کنترلرهای ناهمسان (heterogeneous) با ظرفیت­های متفاوت می­باشد. در کنترلرهای همسان، ارتباطات بین کنترلرهای اغلب محدود به ارتباطات “east-west” است و در کنترلرهای ناهمسان، ارتباطات سلسله مراتبی “north-south” رایج تر است.

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

  • معماری متمرکز فیزیکی دربرابر توزیع شده فیزیکی

SDN در زمان ظهورش، گرایش زیادی به یک کنترلر متمرکز فیزیکی داشت. اما با توجه به برخی مسائل، مانند single point of failure و مقیاس پذیری، کارشناسان شبکه طرح توزیع شده فیزیکی را پیشنهاد دادند.

 بسیار مهم است که بدانید، زمانی که درباره معماری صفحه کنترل توزیعی (multi controller)  صحبت می­ کنیم، درک کنید منظور فقط شبکه توزیع شده فیزیکی است. بنابراین، در ادامه بحث، همیشه فرض ما بر این است که کنترلرها به طور فیزیکی، توزیع شده­ اند.

کنترلرهایی مثل Beacon و NOX از تکنیک های چندنخی برای جداسازی منطقی یک کنترل کننده واحد، به منظور افزایش کارایی  استفاده می­ کنند. در این حالت، کاملا واضح است که فقط یک کنترلر واحد داریم و درباره معماری multi controller صحبت نمی­ کنیم.

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

در ادامه، به شرح بیشتر موضوعات مختلف مربوط به یک معماری توزیع شده فیزیکی می­ پردازیم.

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

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

متمرکز منطقی به این معناست که بتوان از مزایای مفهوم طراحی multi controller بهره برد، اما در این حالت همواره یک کنترل واحد را درنظر می­ گیریم. به عبارتی، بار و هزینه مربوطه بین چندین کنترلر توزیع می ­شود، اما برای لایه زیرین مانند این است که فقط یک کنترلربه کل شبکه فرمان می­ دهد.

ایده دیگری که قبل از multiple controller پیاده سازی شده بود، تکرار کنترلرها برای حذف تک نقطه شکست بوده است. با این وجود، این روش دارای معایب بسیاری از جمله استفاده از کنترلرهای غیرفعالی می­ باشد که فعال خواهند شد، تنها در این مورد کنترلر اصلی با شکست مواجه می­ شود. درمعماری متمرکز منطقی، همه کنترلرها مسئولیت های یکسانی دارند، و هزینه ها را به طور معادل تقسیم می­ کنند. آن ها همیشه از هر تغییری در شبکه آگاه هستند، و به لطف همگام سازی شبکه، اطلاعات مشابه را بلافاصله به اشتراک می­ گذارند.

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

در یک کلام، معماری متمرکز منطقی از گرایش های اولیه SDN بوده که از یک کنترلر واحد یا کنترل کننده چند هسته ای (multi core) برای بهبود عملکرد شبکه استفاده می­ کرد.

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

  • معماری مسطح (Flat) در برابر معماری سلسله مراتبی (Hierarchical)

در اکثر مقالات مرتبط، دریافتیم که معماری multi controller می­ تواند یک طرح مسطح یا سلسله مراتبی را دنبال کند.

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

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

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

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

  • معماری پویا دربرابر معماری ایستا

یک معماری متمرکز منطقی می ­تواند پویا یا ایستا باشد. در یک معماری پویا و منعطف، لینک­ ها و موقعیت­ های بین کنترلرها، همانند سوئیچ­ ها، قابل تغییر می­ باشند، و این خود سبب انعطاف پذیری شبکه می­ گردد. در حالی که در یک معماری ایستا، لینک­ ها و موقعیت­ های بین کنترلرها و سوئیچ ­ها غیرقابل تغییر است، در این حالت شبکه نسبت به معماری پویا، پایداری بیشتر و سربار کمتری خواهد داشت.

حال می خواهیم، پس از آشنایی با ساختارهای فوق، می­خواهیم چندین نمونه از معماری­رهای multi controller متمرکز منطقی را به شما معرفی کنیم:

معماری های متمرکز منطقی

  • ONIX، یک بخش کنترلی توزیع شده شامل خوشه ای از یک یا تعداد بیشتری سرور فیزیکی است، که هر کدام ممکن است چندین نمونه از ONIX را اجرا کنند. یک شبکه تحت کنترل ONIX چهار مولفه دارد: اول، زیرساخت فیزیکی، که شامل سوئیچ­ ها و مسیریاب ­ها و سایر دیوایس ­های شبکه، مانند متوازن کننده بار و فایروال است. ONIX ازطریق خواندن و نوشتن حالت کنترلی هر المان، با زیرساخت فیزیکی در ارتباط است. دوم، زیرساخت ارتباطی، برای ارتباط بین شبکه فیزیکی و ONIX، سوم، منطق کنترلی وابسته به API. که رفتار شبکه را کنترل می ­کند، و چهارم، ONIX، مسئول ارائه دسترسی برنامه ریزی شده منطق کنترلی به شبکه است. درواقع ONIX، سناریویی برای بهبود مقیاس پذیری شبکه است، یعنی به کمک آن می توانید شبکه ای با تعداد زیادی سوئیچ داشته باشید که به راحتی توسط یک نمونه ONIX مدیریت می­ شوند. هم­چنین منطق کنترلی آن قادر به ثبت اطلاعات فوروارد از سوئیچ ها می­ باشد و می ­تواند تمامی داده ها را هماهنگ کند و آن­ها را بین چندین کنترل کننده به اشتراک بگذارد. یکی از کارهایی که ONIX، جهت بهبود مقیاس پذیری انجام می­ دهد، تقسیم منطقی شبکه و توزیع بارکاری بین چندین نمونه از ONIX است. بنابراین این حالت، سبب بروز سربار در یک نمونه ONIX می­ گردد، در این صورت، سوئیچ­ های متصل به آن می­ توانند به نمونه دیگری متصل شوند.
  • HyperFlow، یک اپلیکیشن توسعه یافته کنترلرNOX، برای فعال سازی معماری های multi controller متمرکز منطقی، که رویدادها را در همه گره های توزیع شده تکرار می­ کند، بنابراین هرگره می­ تواند چنین رویدادهایی را پردازش کند و به طور محلی حالت آن­ها را به روز رسانی کند. HyperFlow شامل سه بخش است: یک لایه کنترلی، یک لایه فوروارد، و یک لایه اپلیکیشن. لایه کنترل شامل تعدادی کنترل کننده NOX است به طور هماهنگ با هم کار می ­کنند. در لایه فوروارد، سوئیچ­ ها به نزدیک ترین کنترل کننده متصل هستند. با این حال، یک سوئیچ می­ تواند در حالت خرابی این کنترلر، مجددا به کنترلر دیگری متصل شود. الگوی پیام رسانی و انتشار اطلاعات HyperFlow، “انتشار/تقبل” است. در این روش، ترتیب رویدادهای انتشار یافته توسط یک کنترلر حفظ می­ گردد. هم­چنین، این روش، ترافیک مورد نیاز جهت ارتباط بین کنترلرها را به حداقل می ­رساند تا سربار کم­تری حاصل گردد. کنترلرهای مبتنی بر HyperFlow درمقایسه با NOX، همگام سازی حالت کنترلر ها در شرایطی که  بارسنگینی موجود باشد، راحت تر اجرا می­ کنند و حداقل تاخیر را دارند. هم­چنین HyperFlow می­ تواند سازگاری قابل قبولی را بین کنترلرها برای برخی از هزار رویدادی که در ثانیه می­رسد، حفظ کند. این رویدادها می ­توانند شامل اتصالات سوئیچ و میزبان و قطع اتصال شبکه و تغییر حالت یک لینک باشند. با این وجود باید نقطه ضعف موجود رابه شما متذکر شویم که تاخیر افزوده شده در زمان همگرایی یا همگام شدن  کنترلر های شبکه ، سبب افزایش زمان پاسخ می­گردد.
معماری HyperFlow

معماری HyperFlow

 

  • ONOS، یک سیستم عامل توزیع شده باز و پلتفرم کنترلی توزیع شده است، توجه کنید منظور این است که ذاتا توزیع شده است و توزیع شدگی جز اهداف طراحی آن است نه حمایت­ های بعد از طراحی. ازطرفی کنترلری مثل floodlight، ساختار توزیع شده ندارد، اما برای پیاده سازی توزیع شدگی از آن استفاده می­ شود. اما ONOS و OpenDaylight ذاتا ساختار توزیع شده دارند. در جهت توسعه ONOS، دو نمونه اولیه از یک مدل multi controller شبکه SDN ارائه داده شده که دارای خصوصیات متفاوتی هستند.

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

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

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

معماری نمونه اول ONOS

معماری نمونه اول ONOS

نمونه اولیه دوم درحالی که دید جهانی شبکه را حفظ می­ کند، روی بهبود عملکرد نمونه اول متمرکز است. از آن ­جایی که مشکل اصلی نمونه اول عملیات ذخیره داده گران بوده، در نمونه 2، سعی شده با پیگیری دو رویکرد مکمل، این مساله را بهبود بخشند. 1) عملیات remote با سرعت هرچه بیشتر،2) کاهش تعداد عملیات remote. ­هم­چنین، برای حل مساله ارتباطات بین کنترلر ها، از سیستم ارتباطی Hazelcast استفاده می­کنند.

معماری نمونه دوم ONOS

معماری نمونه دوم ONOS

اما بهتر است بدانید ONOS یکی از کارهای پژوهشی جدید  با اهداف تجاری در زمینه Clustering می­باشد که تاکنون چندین نسخه از آن منتشر شده و در حال توسعه می­ باشد. از این رو ممکن است برخی از اهداف و کاربردها درحال حاضر با استفاده از ONOS ،  قابل پیاده سازی نباشند. از طرفی شما برای کار با ONOS، نیاز به دانش قوی در زمینه شبکه، نحوه تشکیل cluster و تنظیمات مربوط به آن دارید، هم­چنین باید به خوبی ساختار و معماری آن را درک نمایید و بررسی کنید و با مفاهیم java، Maven، Karaf به عنوان بسته های نرم افزاری پیش نیاز ONOS  آشنا باشید. از طرفی  شما برای نصب چندین نمونه ONOS، ممکن است با محدودیت هایی از نظر ظرفیت پردازشی سیستم خود روبرو شوید، زیرا  نیاز به فضای ذخیره سازی  و قدرت پردازشی بالا دارد. هم چنین درحال حاضر تنها روی Ubuntu server 14.04 قابلیت نصب و اجرا دارد.

  •  ElastiCon یک معماری منعطف و پویا برای بخش کنترلی است، که شامل خوشه ای از کنترلر ها است که به منظور ارائه دید جهانی شبکه، بارکاری را به اشتراک می ­گذارند. این دید جهانی توسط ماژول ذخیره داده توزیع شده ساخته می­ شود. هر کنترلر یک کانال TCP برای ارتباط با کنترلر همسایه اش به منظور تضمین تبادل پیام بین کنترلر ها و مهاجرت سوئیچ دارد.لایه فیزیکی، شامل چندین سوئیچ می­ باشد، هرکدام به تعدادی کنترلر متصل هستند، اما تنها یکی از آن­ها master است و بقیه equal یا slave هستند. وقتی کنترلری master یا equal باشد قادر به دریافت و پردازش پیام های آسنکرون مثل packet-in از طرف سوئیچ هستند، اما در نقش slave فقط قادر به خواندن این پیام هاست و قدرت پردازش آن ها را ندارد.هر کنترلر دارای ماژول core می­ باشد و تمام مسئولیت های یک کنترلر متمرکز را برعهده می­ گیرد. هم­چنین به کنترلر توانایی برقراری ارتباط با کنترلرهای دیگر برای انتخاب master می­ دهد.در فرایند مهاجرت سوئیچ، می­توان کنترلرها را براساس حد آستانه های از پیش تعریف شده اضافه یا حذف نمود. همچنین الگوریتم  توازن بار پویا با توجه به تغییرات ترافیکی از نظر زمانی و مکانی به صورت دوره ای اجرا می­گردد و همواره کارایی قابل قبولی را تضمین می­ کند.
    معماری ElastiCon

    معماری ElastiCon

    برای پیاده سازی ElastiCon، به mininet برای ارزیابی شبکه ای از Open vSwitch ها، کنترلر floodlight و منبع داده توزیع شده Hazelcast نیاز دارید. با افزودن تعداد کنترلر ها شاهد افزایش خطی گذردهی  و کاهش زمان پاسخ خواهید بود. هم­چنین در این معماری، استفاده از پروتکل 4 مرحله ای مهاجرت به منظور کاهش اختلال تبادل پیام در حین مهاجرت، سبب بهبود سرعت عملیات مهاجرت سوئیچ شده است.

معماری های توزیع شده منطقی

  • Kandoo، یک کنترلر توزیع شده منطقی با طراحی سلسله مراتبی دو لایه است. لایه پایینی شامل کنترلر های محلی است، که هر کدام زیردامنه خودش را کنترل می­ کند، در حالی که لایه بالایی شامل کنترلر متمرکز منطقی برای نگه داری وضعیت شبکه می­ باشد.

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

    Kandoo، قادر به همزیستی با سایر کنترلر ها در همان شبکه و سفارشی سازی درجهت نیازهای خاص شبکه می­ باشد. هم­چنین سبب بهبود قابل توجهی در مقیاس پذیری نسبت به شبکه های سنتی  Open Flowشده است.

معماری kandoo

معماری kandoo

اما مطالعات صورت گرفته بیانگر این هستند که هیچ اطلاعی درباره بار کاری و عملکرد کنترلر های محلی، در مقایسه با یک توپولوژی استاندارد Open Flow وجود ندارد.

  • ORION ، یک بخش کنترلی سلسله مراتبی ترکیبی است، که ترکیبی از معماری های مسطح و سلسله مراتبی است. در این معماری، مزایای هردو طرح ترکیب شده و برای اجتناب از مسائلی که هر معماری به طور جداگانه با آن ها روبرو است، مانند افزایش پیچیدگی محاسباتی فوق خطی، به دلیل افزایش مقیاس معماری های مسطح و طولانی شدن مسیر طرح سلسله مراتبی، همه آن­ها در یک ساختار ترکیبی قرار می­ گیرند.ارتباطات کنترلرهای درون یک دامنه در ORION، وابسته به ماژول ارتباطات افقی است که برای ساخت یک دید جهانی، اطلاعات بین کنترلرهای یک دامنه را هماهنگ می ­کند. در حالی که ارتباطات بین کنترلرهای دامنه های متفاوت، وابسته به ماژول ارتباطات عمودی است، که مجموعه ای از اتصالات TCP است که به کنترلر های یک محدوده اجازه ارسال توپولوژی لایه زیرساخت و درخواست اطلاعات از کنترلر دامنه را در زمانی که یک میزبان بخواهد به میزبان خاصی در دامنه دیگر دسترسی یابد، می­ دهد.در واقع اگر بخواهید کاربرد اصلی این معماری را بدانید، باید به شما بگوییم که بیشتر برای ماژول مدیریت مسیریابی مورد استفاده قرار می­ گیرد، که در آن همه وظایف مسیریابی با استفاده از الگوریتم دایجسترا کنترل می­ شوند.ORION هم به منظور امکان سنجی و بررسی کارایی از mininet استفاده می ­کند، زمان محاسباتی آن دارای یک رشد خطی می­ باشد، که نسبت به الگوریتم سنتی مسیریابی دایجسترا بسیار کم­تر است. هرچند با افزایش مقیاس، تاخیر افزایش می­یابد، اما سربار کمی دارد.

جایگزینی (placement) کنترل کننده ها در معماری با صفحه کنترل توزیعی

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

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

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

شاید برای شما هم تعجب برانگیز باشد که یک کنترلر واحد برای زمان پاسخ مورد نیاز در یک شبکه با مقیاس متوسط، کفایت می­ کند!

ارتباطات بین کنترل کننده ها

شما برای تبادل اطلاعات بین چندین کنترلر در SDN نیاز به برقراری ارتباط بین آن­ها دارید.

برای مثال در سیستم انتقال پیام  “انتشار و تقبل”، مجموعه ای از سوئیچ­ ها توسط یک کنترلر خاص متقبل می­ شوند و هر کنترلر کار مشابهی انجام می­ دهد. سپس، کنترلر برای ساخت یک دید جهانی از شبکه اطلاعات خود را منتشر می­ کند.

 مثال دیگر، سیستم تبادل اطلاعات است، که هر کنترلر، اطلاعات حالت محلی خودش را به همسایگانش ارسال می­کند. این مورد بیشتر مناسب معماری های متمرکز است، درحالی که معماری های توزیع شده بیشتر به دنبال پیاده سازی پروتکل های مسیریابی، مثل BGP، OSPF و IS-IS هستند.

حتما شما دوستان گرامی تا کنون دریافتید که ساختن دید جهانی از شبکه با مفهوم سازگاری (Consistency) درارتباط است. بهتر است بدانید که دو نوع سازگاری وجود دارد: ا) سازگاری ضعیف، که اجرای به روز رسانی ها بین کنترلر ها مدت زمانی طول می­ کشد تا به طور کامل اعمال گردد. 2) سازگاری قوی، چندین کنترل کننده به طور هم­زمان به روز رسانی­ ها را می­ خوانند. این حالت سبب تاثیر مثبت برروی عملکرد شبکه می­ گردد.

طبق مطالعات صورت گرفته و بررسی مقالات و کارهای مرتبط، نیاز به یک پایگاه داده توزیع شده برای قرارگیری اطلاعات شبکه مانند اطلاعات خاص سوئیچ ها، کنترلرها، اطلاعاتی که بین کنترلرها و سوئیچ­ ها مبادله می­ گردد، اطلاعات توپولوژی شبکه، لینک­ ها و… ضروری است. هم­چنین از جمله پرکاربردترین منبع داده های مورد استفاده، Casandra، با قابلیت مقیاس پذیری و دسترس پذیری بالا و مبتنی بر پایگاه داده توزیع شده NoSQL و Hazelcast یک منبع داده درون حافظه (in-memory) توزیع شده با قابلیت انعطاف پذیری، دسترس پذیری بالا، تاخیر دسترسی پایین، و پشتیبانی از سازگاری قوی که به جاوا نوشته شده است، می­ باشند.

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

برای هماهنگی عملیات کنترلر ها و آگاهی آن ها جهت استفاده از اطلاعات موجود در منابع داده، نیاز به ابزاری جهت این کار دارید. باید خدمت شما عزیزان عرض نماییم که طبق بررسی های صورت گرفته، یکی از پرکاربردترین روش ها جهت هماهنگی وسازگاری حالت بین کنترلرها، استفاده  از Zookeeper یک سرویس هماهنگ کننده متن باز وبا کارایی بالا برای اپلیکیشن های توزیع شده می ­باشد، که در پیاده سازی های اخیر برای پیاده سازی معماری توزیع شده بخش کنترلی با استفاده از کنترلرهای floodlight ، OpenDaylight و هم­چنین برای ساخت نمونه اولیه کنترلر توزیع شده ONOS، مورد استفاده قرار گرفته است.

البته ابزاری مانند JGroup هم برای پیام رسانی قابل اطمینان بین کنترلرها وجود دارد، اما توصیه ما به شما استفاه از zookeeper، به دلیل سادگی، سریع بودن، قابلیت binding به جاوا و C وسایر مزایا می ­باشد.

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

قابل توجه آن دسته از علاقمندانی که با کنترلر Floodlight کار می­کنند، در نسخه جدید این کنترلر، امکان تنظیمات ماژول sync فراهم شده است، که اگر به درستی تنظیمات لازم را اعمال کنید، با اجرای ماژول ها و الگوریتم هایی که نیاز به هماهنگی کنترلرها دارند مثل ماژول simpleFT در floodlight به منظور fault tolerance ، مشاهده می ­کنید که به ازای هر بار اجرای کنترلر و هرگونه تغییر یا به روزرسانی، آن ها یکدیگر را sync می کنند.

اما درحال حاضر ماژول sync درحال توسعه می­ باشد، و نکات مبهمی درباره امکان تبادل و اطلاعات دقیقی که جهت پیاده سازی موضوع مورد نظر توسط آن مبادله می­ شود ، نحوه فراخوانی آن در شرایط لازم، امکان sync تعداد زیادی از کنترلرها توسط آن و دیگر نکاتی در این زمینه وجود دارد، که درحال بررسی این نکات می­ باشیم.

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

منابع:

[1] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, and S. Shenker, “Onix: A distributed control platform for large-scale production networks.” In OSDI, vol. 10, pp. 1–6, 2010.

[2] Soheil Hassas Yeganeh, and Yashar Ganjali. “Kandoo: a framework for efficient and scalable offloading of control applications.” In Proceedings of the first workshop on Hot topics in software defined networks, pp. 19-24. ACM, 2012.

[3] A. Tootoonchian and Y. Ganjali, “Hyperflow: A distributed control plane for openflow,” in Proceedings of the 2010 internet network management conference on Research on enterprise networking, pp. 3–3, 2010.

[4] Cassandra. http://cassandra.apache.org/.

[5] D. Erickson, “The Beacon OpenFlow controller,” in Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN ’13), pp. 13–18, ACM, New York, NY, USA, 2013.

[6] N. Gude, T. Koponen, J. Pettit et al., “NOX: towards an operating system for networks,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 3, pp. 105–110, 2008.

[7] B. Heller, R. Sherwood, and N. McKeown, “The controller placement problem,” in Proceedings of the 1st Workshop on Hot Topics in Software Defined Networks (HotSDN ’12), ACM, Helsinki, Finland, 2012.

[8] U. Krishnaswamy, P. Berde, J. Hart et al., “ONOS: an open source distributed SDN OS,” 2013, http://www.slideshare.net/umeshkrishnaswamy/open-network-operating-system.

[9] Hazelcast Project, http://www.hazelcast.org/.

[10] A. Dixit, F. Hao, S. Mukherjee, T. V. Lakshman, and R. Kompella, “Towards an elastic distributed SDN controller,” in Proceedings of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN ’13), pp. 7–12, ACM, Hong Kong, 2013.

[11] Y. Fu, J. Bi, K. Gao, Z. Chen, J. Wu, and B. Hao, “Orion: a hybrid hierarchical control plane of software-defined networking for large-scale networks,” in Proceedings of the 22nd IEEE International Conference on Network Protocols (ICNP ’14), pp. 569–576, Raleigh, NC, USA, October 2014.

[12] Akram Hakiri, Aniruddha Gokhale, Pascal Berthou, Douglas C. Schmidt, Thierry Gayraud. “Software-Defined Networking: Challenges and research opportunities for Future Internet”. Journal of computer networks, vol. 75, pp. 453-471, Elsevier, 2014.

 

آشنایی با شبکه مبتنی بر نرم افزار با صفحه کنترل توزیعی
میانگین 5 امتیاز از 1 رای

(5) دیدگاه

  • Mphr پاسخ

    سلام، ممنون از تبادل اطلاعاتتون

    من هم رو موضوع SDN و جزیی تر کنترلرهای توزیع شده در حال انجام تز هستم،  سوالی دارم این که کدام یک از این راه کارها، برای پیاده سازی تمامی کدها و سورس هاش و….در دسترس است؟ بچه هایی که به مرحله پیاده سازی رسیدن مثلا آیا میشه رو همین پکیج  اپن دی لایت این راه کارها رو تست کرد (مثلا elastiCon)؟

    سپاس

     

    ۲۰ تیر ۱۳۹۵ در ۱۰:۲۵ ق.ظ
  • Masoudi پاسخ

    با سلام و احترام

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

    ممنون

    ۲۰ تیر ۱۳۹۵ در ۹:۳۰ ب.ظ
  • امید پاسخ

    خیلی ممنون از مطلب مفیدتون. با تشکر از شما

    ۲۱ آبان ۱۳۹۶ در ۱۲:۴۵ ق.ظ
  • محمدی پاسخ

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

    ۱۶ بهمن ۱۳۹۶ در ۵:۰۶ ب.ظ
  • مهسا پاسخ

    سلام و خسته نباشید. میشه بگید برای مبحث تحمل خرابی کنترلر ها در sdn چه روشهای پیاده سازی وجود داره؟ فقط با مینی نت؟

    ۲۶ اسفند ۱۳۹۶ در ۴:۳۱ ب.ظ

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *