مشکل با SDN

ارسال شده توسط مدیر 4 مارس, 2016

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

اهمیت اتوماسیون و ارکستراسیون (عملیاتی) از شبکه را نمی توان دست کم گرفت. این نقش در بهبود زمان بازار و کاهش دادن هزینه های عملیاتی – هر دو برای مدیران سطح C امروزه اولویت هستند- این به خوبی در این نقطه قابل درک می باشد. امروزه مقیاس گذاری یک کسب و کار به معنی مقیاس گذاری برنامه ها است، که به نوبه خود نیاز به مقیاس گذاری زیرساخت ارائه شده و امنیت آن برنامه های کاربردی دارد.

به طور فزاینده، ما شاهدیم SDN به این مفهوم اتوماسیون گره خورده است و ارکستراسیون در مخفف جدید : MANO (مدیریت و ارکستراسیون) در برگرفته شده است. این مهم است که به جدایی “مدیریت” از “ارکستراسیون” توجه کنید، شاید ما این دو را یکسان فرض می کنیم . آنها یکسان نیستند و اینجاست که مشکل با SDN شروع می شود.

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

سپس ما دیدیم که Open Flow تنها بخشی از راه حل بود؛ آن برای تهیه کردن زیرساخت ارائه کننده سرویس های شبکه فرمان بالاتر (لایه 4-7) که به همان منوال خودکار باشد شکست خورد SDN تکامل یافت، شروع به تمرکز کرد که شامل رویکرد جامع، تامین و خدمات شبکه مدیریت بود. APIs و قالب ها همراه با “استاد” موتورهای ارکستراسیون مانند Cisco ACl و VMware NSX با تمرکز بر روی ارائه قابلیت های مورد نیاز از برنامه های کاربردی در محیط مدرن پدید آمد.

صداها مگر ما آنها را تحت کنترل نداریم، داریم؟

در حالیکه بهره بردای با SDN ، DevOps یا حتی NFV قطعا ارکستراسیون جزء از MANO خطاب می کند، این لزوما آدرس جزء مدیریت نیست.

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

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

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

ممکن است این دو تابع- مدیریت و ارکستراسیون- لزوما نیازی به دو راه حل معماری جداگانه داشته باشند. راه حل که اتوماسیون و ارکستراسیون عملیات پیکر بندی را پشتیبانی می کند ممکن نیست مشابه باشد با آن یکی که مدیریت از دستگاهها و پلت فرم ها را فعال می کندکه سرویس ها در حال هماهنگی ارائه می دهد.

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