پرش به محتوا

مجازی‌سازی عملکردهای شبکه

از ویکی‌پدیا، دانشنامهٔ آزاد

مجازی‌سازی عملکردهای شبکه (NFV)[۱] یک مفهوم معماری شبکه است که از فناوری‌های مجازی‌سازی IT استفاده می‌کند تا دسته‌های کامل از توابع گره شبکه را به بلوک‌های ساختمانی مجازی تبدیل کند. این بلوک‌ها می‌توانند به هم متصل شوند یا زنجیره‌ای ایجاد کنند تا خدمات ارتباطی را ایجاد و ارائه دهند. NFV بر تکنیک‌های سنتی مجازی‌سازی سرور تکیه دارد، مانند آنچه در فناوری اطلاعات سازمانی استفاده می‌شود. یک تابع شبکه مجازی سازی (VNF) در یک یا چند ماشین مجازی یا کانتینر اجرا می‌شود که نرم‌افزارها و فرآیندهای مختلفی را بر روی سرورهای معمولی، سوئیچ‌ها و دستگاه‌های ذخیره‌سازی با حجم بالا یا حتی زیرساخت‌های رایانش ابری اجرا می‌کنند. این فرایند به جای استفاده از سخت‌افزارهای سفارشی برای هر تابع شبکه انجام می‌شود و از قفل شدن به یک فروشنده خاص جلوگیری می‌کند. برای مثال، می‌توان یک کنترل‌کننده مرزی مجازی برای محافظت از شبکه مستقر کرد، بدون نیاز به هزینه‌ها و پیچیدگی‌های معمول تهیه و نصب واحدهای فیزیکی حفاظت از شبکه. سایر مثال‌های NFV شامل متعادل‌کننده‌های بار مجازی، دیوارهای آتش، سامانه تشخیص نفوذ، و بهینه‌سازی شبکه گسترده هستند.[۲] جدا کردن نرم‌افزار توابع شبکه از پلتفرم سخت‌افزاری سفارشی، یک معماری شبکه انعطاف‌پذیر را ایجاد می‌کند. این معماری مدیریت شبکه چابک، راه‌اندازی سریع خدمات جدید، و کاهش قابل توجه در هزینه‌های سرمایه‌ای (CAPEX) و عملیاتی (OPEX) را ممکن می‌سازد.

پس زمینه

[ویرایش]

توسعه محصول در صنعت مخابرات به‌طور سنتی از استانداردهای دقیق برای پایداری، رعایت پروتکل‌ها و کیفیت پیروی می‌کرد، که این امر با استفاده از اصطلاح «درجه حمل‌کننده» برای توصیف تجهیزاتی که این سطح از اعتمادپذیری و عملکرد بالا را نشان می‌دهند، منعکس می‌شد.[۳] در حالی که این مدل در گذشته به خوبی کار می‌کرد، به‌طور اجتناب‌ناپذیری منجر به دوره‌های طولانی توسعه محصول، سرعت پایین پیشرفت و وابستگی به سخت‌افزار خاص یا اختصاصی می‌شد، مانند مدارهای مجتمع با کاربرد خاص (ASIC) برای برنامه‌های خاص. این مدل توسعه باعث تأخیرهای قابل توجه در زمان راه‌اندازی خدمات جدید، چالش‌های پیچیده در هم‌افزایی سیستم‌ها و افزایش قابل توجه هزینه‌های سرمایه‌ای و عملیاتی (CAPEX/OPEX) هنگام مقیاس‌دهی به سیستم‌های شبکه و زیرساخت‌ها و ارتقاء قابلیت‌های خدمات شبکه برای پاسخگویی به بار و تقاضاهای عملکردی رو به رشد می‌شد. علاوه بر این، ظهور رقابت‌های قابل توجه از سوی سازمان‌های چابک که در مقیاس بزرگ بر روی اینترنت عمومی فعالیت می‌کنند (مانند Google Talk, Skype و Netflix)، باعث شد تا ارائه‌دهندگان خدمات به دنبال روش‌های نوآورانه برای اختلال در وضعیت موجود و افزایش منابع درآمدی خود باشند.

تاریخچه

[ویرایش]

در اکتبر ۲۰۱۲، گروهی از اپراتورهای مخابراتی یک اوراق سفید[۴] در یک کنفرانس در دارمشتات، آلمان، دربارهٔ شبکه های نرم‌افزارمحور (SDN) و اوپن فلو منتشر کردند. فراخوان اقدام در پایان این مقاله سفید منجر به ایجاد گروه مشخصات صنعتی مجازی‌سازی توابع شبکه (NFV)[۵] در داخل نهاد های استانداردهای مخابراتی اروپا (ETSI) شد. این گروه مشخصات صنعتی (ISG) متشکل از نمایندگان صنعت مخابرات از اروپا و سایر نقاط جهان بود.[۶][۷] گروه ISG NFV در ETSI بسیاری از جنبه‌ها را پوشش می‌دهد، از جمله معماری عملکردی، مدل اطلاعات، مدل داده، پروتکل‌ها، APIها، تست، قابلیت اطمینان، امنیت، تکامل‌های آینده و غیره.

گروه ISG NFV ETSI از می ۲۰۲۱ نسخه ۵ مشخصات خود را منتشر کرده است که هدف آن تولید مشخصات جدید و گسترش مشخصات قبلی بر اساس ویژگی‌ها و بهبودهای جدید است.

از زمان انتشار مقاله سفید، این گروه بیش از ۱۰۰ انتشار[۸] تولید کرده است که در صنعت به‌طور گسترده‌ای پذیرفته شده و در پروژه‌های متن‌باز برجسته مانند OpenStack, ONAP و Open Source MANO (OSM) به‌کار گرفته شده است. به دلیل فعالیت‌های متقابل و همکاری‌های فعال، مشخصات NFV ETSI همچنین در سایر سازمان‌های توسعه استاندارد (SDO) مانند 3GPP, IETF و ETSI MEC نیز مورد ارجاع قرار گرفته است.

چهارچوب

[ویرایش]

چارچوب NFV از سه مؤلفه اصلی تشکیل شده است:[۹]

1. توابع شبکه مجازی‌شده (VNFs): این توابع، پیاده‌سازی‌های نرم‌افزاری از توابع شبکه هستند که می‌توانند بر روی زیرساخت مجازی‌سازی توابع شبکه (NFVI) مستقر شوند.[۱۰]

2. زیرساخت مجازی‌سازی توابع شبکه (NFVI): این عبارت به مجموع تمام اجزای سخت‌افزاری و نرم‌افزاری اطلاق می‌شود که محیطی را برای استقرار VNFs فراهم می‌آورد. زیرساخت NFVI ممکن است شامل چندین موقعیت جغرافیایی باشد. شبکه‌ای که اتصال بین این موقعیت‌ها را فراهم می‌کند، به‌عنوان بخشی از زیرساخت NFVI در نظر گرفته می‌شود. 3. چارچوب معماری مدیریت و ارکستراسیون مجازی‌سازی توابع شبکه (NFV-MANO Architectural Framework): این چارچوب مجموعه‌ای از بلوک‌های عملکردی، مخازن داده مورد استفاده توسط این بلوک‌ها، و نقاط مرجع و رابط‌هایی است که از طریق آن‌ها این بلوک‌ها برای هدف مدیریت و ارکستراسیون NFVI و VNFs اطلاعات مبادله می‌کنند. بلوک ساختاری برای هر دو NFVI و NFV-MANO، پلتفرم NFV است. در نقش NFVI، این پلتفرم شامل منابع پردازشی و ذخیره‌سازی مجازی و فیزیکی و نرم‌افزار مجازی‌سازی است. در نقش NFV-MANO، این پلتفرم شامل مدیران VNF و NFVI و نرم‌افزار مجازی‌سازی است که بر روی یک کنترلر سخت‌افزاری عمل می‌کند. پلتفرم NFV ویژگی‌های سطح carrier-grade را پیاده‌سازی می‌کند که برای مدیریت و نظارت بر اجزای پلتفرم، بازیابی از خرابی‌ها و تأمین امنیت مؤثر مورد نیاز شبکه‌های عمومی حمل‌کننده است.

جنبه علمی

[ویرایش]

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

جنبه دیگر پیاده‌سازی NFV، فرایند ارکستراسیون است. برای ساخت خدمات با قابلیت اطمینان و مقیاس‌پذیری بالا، NFV نیاز دارد که شبکه بتواند نمونه‌های VNF را ایجاد کند، آن‌ها را نظارت کند، تعمیر کند و (مهم‌تر از همه برای کسب‌وکار یک ارائه‌دهنده خدمات) هزینه خدمات ارائه‌شده را محاسبه کند. این ویژگی‌ها، که به عنوان ویژگی‌های carrier-grade شناخته می‌شوند،[۱۱] به لایه ارکستراسیون اختصاص داده می‌شوند تا قابلیت دسترسی بالا، امنیت و هزینه‌های پایین عملیات و نگهداری را فراهم کنند. نکته مهم این است که لایه ارکستراسیون باید بتواند VNFs را صرف‌نظر از فناوری زیرساختی داخل VNF مدیریت کند. به‌عنوان مثال، لایه ارکستراسیون باید بتواند یک VNF SBC از فروشنده X را که بر روی VMware vSphere اجرا می‌شود، به همان اندازه که یک VNF IMS از فروشنده Y را که بر روی KVM اجرا می‌شود، مدیریت کند.

NFV توزیع‌شده

[ویرایش]

برداشت اولیه از NFV این بود که قابلیت‌های مجازی‌شده باید در مراکز داده پیاده‌سازی شوند. این رویکرد در بسیاری از موارد کار می‌کند، اما در همه موارد نه. NFV بر انعطاف‌پذیری گسترده در خصوص مکان فیزیکی توابع مجازی‌شده تأکید دارد.

بنابراین، به‌طور ایده‌آل، توابع مجازی‌شده باید در جایی قرار گیرند که مؤثرترین و کم‌هزینه‌ترین باشد. این بدان معناست که ارائه‌دهنده خدمات باید آزادی داشته باشد تا NFV را در تمام مکان‌های ممکن، از مرکز داده گرفته تا گره شبکه و محل استقرار مشتری مستقر کند. این رویکرد که به آن NFV توزیع‌شده گفته می‌شود، از همان ابتدا که NFV در حال توسعه و استانداردسازی بود، مورد تأکید قرار گرفت و در اسناد منتشرشده اخیر NFV ISG برجسته است.[۱۲]

در برخی موارد، برای یک ارائه‌دهنده خدمات، واضح است که قرار دادن این عملکردهای مجازی‌شده در محل مشتری مزایای مشخصی دارد. این مزایا از جنبه‌های اقتصادی، عملکردی و قابلیت مجازی‌سازی توابع مختلف متغیر است.[۱۳]

اولین اثبات مفهوم چندفروشنده‌ای عمومی (PoC) برای D-NFV که توسط ETSI NFV ISG تأیید شد، توسط Cyan, Inc. , RAD, Fortinet و Certes Networks در شیکاگو در ژوئن ۲۰۱۴ برگزار شد و توسط CenturyLink پشتیبانی می‌شد. این PoC مبتنی بر تجهیزات D-NFV در لبه مشتری RAD و با استفاده از فایروال نسل جدید (NGFW) Fortinet و موتور رمزگذاری/رمزگشایی مجازی Certes Networks به‌عنوان توابع شبکه مجازی‌شده (VNFs) با سیستم Blue Planet Cyan برای ارکستراسیون کل اکوسیستم بود.[۱۴] راه‌حل D-NFV RAD، یک واحد ترمینال شبکه لایه ۲/لایه ۳ (NTU) بود که با یک ماژول سرور X86 D-NFV مجهز شده بود و به‌عنوان یک موتور مجازی‌سازی در لبه مشتری عمل می‌کرد و در انتهای همان ماه تجاری شد.[۱۵] در طول سال ۲۰۱۴، RAD همچنین یک اتحادیه D-NFV را سازماندهی کرد که یک اکوسیستم از فروشندگان و یکپارچه‌سازان سیستم بین‌المللی بود که به‌طور تخصصی بر روی کاربردهای جدید NFV تمرکز داشتند.[۱۶]

مزایای مدولاریتهٔ NFV

[ویرایش]

هنگام طراحی و توسعه نرم‌افزاری که توابع VNFs را فراهم می‌کند، فروشندگان ممکن است آن نرم‌افزار را به اجزای نرم‌افزاری تقسیم کنند (نمای پیاده‌سازی معماری نرم‌افزار) و این اجزا را در یک یا چند تصویر (نمای استقرار معماری نرم‌افزار) بسته‌بندی کنند. این اجزای نرم‌افزاری تعریف‌شده توسط فروشنده، به‌عنوان اجزای تابع شبکه مجازی‌شده (VNFCs) شناخته می‌شوند. VNFs با یک یا چند VNFC پیاده‌سازی می‌شوند و فرض بر این است که نمونه‌های VNFC به‌طور یک‌به‌یک با تصاویر VM هم‌راستا هستند.

به‌طور کلی، VNFCها باید قادر به افزایش مقیاس (scale up) و/یا گسترش مقیاس (scale out) باشند. با تخصیص CPUهای مجازی منعطف به هر یک از نمونه‌های VNFC، لایه مدیریت شبکه می‌تواند VNFC را برای تأمین نیازهای عملکردی و مقیاس‌پذیری بر روی یک سیستم یا پلتفرم واحد مقیاس عمودی دهد. به‌طور مشابه، لایه مدیریت شبکه می‌تواند یک VNFC را با فعال‌سازی چندین نمونه از آن VNFC بر روی چندین پلتفرم گسترش دهد و بنابراین به مشخصات عملکردی و معماری دست یابد بدون اینکه به پایداری عملکرد سایر VNFCها آسیب بزند.

پذیرندگان اولیه چنین الگوهای معماری اصول مدولاریتهٔ NFV را پیاده‌سازی کرده‌اند.[۱۷]

ارتباط NFV با SDN

[ویرایش]

مجازی‌سازی توابع شبکه (NFV) به‌شدت با SDN (شبکه‌سازی تعریف‌شده از نرم‌افزار) مکمل است.[۴] در واقع، SDN رویکردی برای ساخت تجهیزات و نرم‌افزار شبکه داده است که اجزای این سیستم‌ها را از هم جدا و抽象 می‌کند. این کار از طریق جدا کردن Plane کنترل و داده از یکدیگر انجام می‌شود، به‌طوری‌که Plane کنترل به‌طور مرکزی قرار می‌گیرد و اجزای ارسال‌کننده (forwarding) به‌طور توزیع‌شده باقی می‌مانند. Plane کنترل با هر دو جهت شمالی و جنوبی تعامل دارد. در جهت شمالی، Plane کنترل یک نمای抽اعشده مشترک از شبکه را برای برنامه‌ها و برنامه‌های سطح بالا با استفاده از APIهای سطح بالا و پارادایم‌های مدیریت نوآورانه مانند شبکه‌سازی مبتنی بر قصد (Intent-based networking) فراهم می‌کند. در جهت جنوبی، Plane کنترل رفتار ارسال داده را از طریق APIهای سطح دستگاه تجهیزات شبکه فیزیکی توزیع‌شده در شبکه برنامه‌ریزی می‌کند.

بنابراین، NFV به SDN یا مفاهیم SDN وابسته نیست، اما NFV و SDN می‌توانند برای بهبود مدیریت زیرساخت NFV و ایجاد یک محیط شبکه پویا با هم همکاری کنند. کاملاً ممکن است که یک تابع شبکه مجازی‌شده (VNF) به‌عنوان یک نهاد مستقل با استفاده از پارادایم‌های موجود شبکه‌سازی و ارکستراسیون پیاده‌سازی شود. با این حال، مزایای ذاتی در بهره‌برداری از مفاهیم SDN برای پیاده‌سازی و مدیریت زیرساخت NFV وجود دارد، به‌ویژه زمانی که به مدیریت و ارکستراسیون خدمات شبکه (NS) نگاه می‌کنیم که از توابع مختلف شبکه (NF) شامل توابع شبکه فیزیکی (PNF) و VNFs تشکیل‌شده است و در بین زیرساخت‌های NFV جغرافیایی مختلف توزیع می‌شود، و به همین دلیل پلتفرم‌های چندفروشنده تعریف می‌شوند که SDN و NFV را در اکوسیستم‌های هماهنگ ترکیب می‌کنند.[۱۸]

یک سیستم NFV به یک سیستم ارکستراسیون و مدیریت مرکزی نیاز دارد که درخواست‌های اپراتور را برای یک NS یا VNF دریافت کرده و آن‌ها را به پردازش، ذخیره‌سازی و پیکربندی شبکه مناسب برای به‌کارگیری NS یا VNF تبدیل کند. پس از شروع به کار، VNF و شبکه‌های مرتبط باید برای ظرفیت و استفاده نظارت شوند و در صورت نیاز تغییراتی اعمال گردد.[۱۹]

تمامی عملکردهای کنترل شبکه در زیرساخت NFV می‌توانند با استفاده از مفاهیم SDN انجام شوند و بنابراین می‌توان NFV را یکی از اصلی‌ترین کاربردهای SDN در محیط‌های ارائه‌دهنده خدمات در نظر گرفت.[۱۹]

تأثیر صنعت

[ویرایش]

NFV در دوران ابتدایی خود به استانداردی محبوب تبدیل شده است. کاربردهای فوری آن بسیار زیاد است، از جمله مجازی‌سازی ایستگاه‌های پایه موبایل، پلتفرم به عنوان سرویس (PaaS)، شبکه‌های تحویل محتوا (CDN)، دسترسی ثابت و محیط‌های خانگی.[۲۰] پیش‌بینی می‌شود که مزایای بالقوه NFV چشمگیر باشد. مجازی‌سازی توابع شبکه که بر روی سخت‌افزارهای عمومی و استاندارد شده پیاده‌سازی می‌شود، انتظار می‌رود که هزینه‌های سرمایه‌ای و عملیاتی را کاهش دهد و زمان‌های معرفی سرویس و محصول را کوتاه‌تر کند.[۲۱][۲۲] بسیاری از تأمین‌کنندگان تجهیزات شبکه بزرگ، از پشتیبانی NFV خبر داده‌اند.[۲۳] این موضوع با اعلام پشتیبانی از NFV توسط تأمین‌کنندگان نرم‌افزار بزرگ همزمان شده است، که پلتفرم‌های NFV مورد استفاده توسط تأمین‌کنندگان تجهیزات برای ساخت محصولات NFV خود را فراهم می‌کنند.[۲۴][۲۵] با این حال، برای تحقق مزایای پیش‌بینی‌شده مجازی‌سازی، تأمین‌کنندگان تجهیزات شبکه در حال بهبود فناوری مجازی‌سازی IT هستند تا ویژگی‌های کلاس Carrier مورد نیاز برای دستیابی به در دسترس‌بودن بالا، مقیاس‌پذیری، عملکرد و قابلیت‌های مدیریت مؤثر شبکه را گنجانده و پیاده‌سازی کنند.[۲۶] برای کاهش هزینه مالکیت کل (TCO)، ویژگی‌های کلاس Carrier باید به کارآمدترین روش ممکن پیاده‌سازی شوند. این نیاز دارد که راه‌حل‌های NFV از منابع پشتیبان به‌طور مؤثر استفاده کنند تا در دسترس‌بودن پنج‌نکته (۹۹٫۹۹۹٪)[۲۷] را به دست آورده و از منابع محاسباتی بدون کاهش پیش‌بینی‌پذیری عملکرد استفاده کنند. پلتفرم NFV پایه‌ای برای دستیابی به راه‌حل‌های کارآمد NFV با ویژگی‌های کلاس Carrier است.[۲۸] این پلتفرم نرم‌افزاری است که بر روی سخت‌افزارهای استاندارد چند هسته‌ای اجرا می‌شود و با استفاده از نرم‌افزارهای منبع باز ساخته شده است که ویژگی‌های کلاس Carrier را در خود گنجانده است. نرم‌افزار پلتفرم NFV مسئول تخصیص مجدد دینامیک VNFs به دلیل خرابی‌ها و تغییرات در بار ترافیکی است، و بنابراین نقش مهمی در دستیابی به در دسترس‌بودن بالا ایفا می‌کند. بسیاری از ابتکارات در حال انجام هستند تا قابلیت‌های NFV کلاس Carrier را مشخص، هماهنگ و ترویج کنند، مانند آزمایش مفهومی NFV از ETSI،[۲۹] پروژه Open Platform for NFV از ATIS،[۳۰] جوایز مجازی‌سازی شبکه‌های Carrier و اکوسیستم‌های مختلف تأمین‌کنندگان.[۳۱] vSwitch، که یکی از اجزای کلیدی پلتفرم‌های NFV است، مسئول ارائه اتصال هم بین VM به VM (بین ماشین‌های مجازی) و هم بین ماشین‌های مجازی و شبکه خارجی است. عملکرد آن بر روی پهنای باند VNFs و همچنین کارایی هزینه NFV تأثیرگذار است. عملکرد استاندارد Open vSwitch (OVS) دارای نقاط ضعفی است که باید برای برآوردن نیازهای راه‌حل‌های NFVI رفع شود.[۳۲] تأمین‌کنندگان NFV گزارش‌هایی از بهبودهای قابل توجه در عملکرد OVS و نسخه‌های Accelerated Open vSwitch (AVS) ارائه کرده‌اند.[۳۳][۳۴] مجازی‌سازی همچنین روش مشخص‌کردن، اندازه‌گیری و دستیابی به دسترسی در راه‌حل‌های NFV را تغییر می‌دهد. به‌عنوان‌مثال، به‌عنوان‌جایگزین کردن VNFs با تجهیزات اختصاصی برای عملکردهای سنتی، شیفتی از دسترسی مبتنی بر تجهیزات به رویکرد مبتنی بر خدمات، به‌صورت انتها به انتها و لایه‌ای ایجاد می‌شود.[۳۵][۳۶] مجازی‌سازی توابع شبکه باعث شکستن ارتباط صریح با تجهیزات خاص می‌شود، بنابراین دسترسی بر اساس دسترسی به خدمات VNF تعریف می‌شود. از آنجایی که فناوری NFV قادر است انواع مختلفی از توابع شبکه را مجازی‌سازی کند که هرکدام انتظارات خاص خود را در زمینه دسترسی خدمات دارند، پلتفرم‌های NFV باید از گزینه‌های تحمل خطای متنوعی پشتیبانی کنند. این انعطاف‌پذیری به CSP ها این امکان را می‌دهد که راه‌حل‌های NFV خود را به گونه‌ای بهینه‌سازی کنند که هرگونه نیاز به دسترسی به VNF را برآورده کنند.

مدیریت و ارکستراسیون (MANO)

[ویرایش]

ETSI پیش از این اعلام کرده است که بخش مهمی از کنترل محیط NFV باید از طریق ارکستراسیون خودکار انجام شود. مدیریت و ارکستراسیون NFV (NFV-MANO) به مجموعه‌ای از عملکردها در یک سیستم NFV اطلاق می‌شود که تخصیص منابع زیرساخت مجازی به توابع شبکه مجازی‌شده (VNFs) و خدمات شبکه (NSs) را مدیریت و ارکستراسیون می‌کند. این عملکردها مغز سیستم NFV هستند و کلید فعال‌سازی خودکار آن.

بلوک‌های عملکردی اصلی در چارچوب معماری NFV-MANO عبارتند از:

ارکستراسیون تابع شبکه مجازی‌شده (NFVO)؛ مدیر تابع شبکه مجازی‌شده (VNFM)؛ مدیر زیرساخت مجازی‌شده (VIM). نقطه ورودی در NFV-MANO برای سیستم‌های پشتیبانی عملیات خارجی (OSS) و سیستم‌های پشتیبانی کسب‌وکار (BSS) NFVO است، که مسئول مدیریت چرخه حیات نمونه‌های NS (خدمات شبکه) می‌باشد. مدیریت چرخه حیات نمونه‌های VNF که یک نمونه NS را تشکیل می‌دهند، توسط NFVO به یکی از VNFMs (مدیران VNF) واگذار می‌شود. هم NFVO و هم VNFMs از خدمات ارائه‌شده توسط یک یا چند VIM (مدیر زیرساخت مجازی) برای تخصیص منابع زیرساخت مجازی به اشیاء تحت مدیریت خود استفاده می‌کنند. علاوه بر این، توابع اضافی برای مدیریت VNFهای کانتینری وجود دارند: این توابع شامل مدیریت زیرساخت خدمات کانتینر (CISM) و رجیستری تصویر کانتینر (CIR) هستند. CISM مسئول نگهداری بارهای کاری کانتینری است، در حالی که CIR مسئول ذخیره و نگهداری اطلاعات تصاویر نرم‌افزاری کانتینر سیستم‌عامل است. رفتار NFVO و VNFM توسط محتوای قالب‌های استقرار (که به آن‌ها توصیف‌گرهای NFV نیز گفته می‌شود) مانند توصیف‌گر خدمات شبکه (NSD) و توصیف‌گر VNF (VNFD) هدایت می‌شود. ETSI مجموعه کاملی از استانداردها را ارائه می‌دهد که یک اکوسیستم باز را امکان‌پذیر می‌سازد، جایی که توابع شبکه مجازی‌شده (VNFs) می‌توانند با سیستم‌های مدیریت و ارکستراسیون مستقل توسعه‌یافته، تعامل داشته باشند و اجزای سیستم‌های مدیریت و ارکستراسیون خود نیز قادر به تعامل با یکدیگر هستند. این شامل مجموعه‌ای از مشخصات APIهای Restful و همچنین مشخصات یک فرمت بسته‌بندی برای ارائه VNFs به ارائه‌دهندگان خدمات و قالب‌های استقرار است که با تصاویر نرم‌افزاری بسته‌بندی می‌شوند تا امکان مدیریت چرخه حیات VNFs را فراهم کنند. قالب‌های استقرار می‌توانند مبتنی بر TOSCA یا YANG باشند.[۳۷][۳۸] مطالعات اضافی در حال انجام است در داخل ETSI به منظور بررسی بهبودهای ممکن در چارچوب NFV-MANO برای ارتقای قابلیت‌های اتوماتیک‌سازی و معرفی مکانیزم‌های مدیریت خودکار (مراجعه کنید به ETSI GR NFV-IFA 041).

مطالعه عملکرد

[ویرایش]

مطالعه عملکرد اخیر بر روی NFV تمرکز داشت بر Throughput (توان عملیاتی)، Latency (تأخیر) و Jitter (نوسان زمان تأخیر) توابع شبکه مجازی‌شده (VNFs)، همچنین مقیاس‌پذیری NFV در خصوص تعداد VNFs که یک سرور فیزیکی واحد می‌تواند پشتیبانی کند.[۳۹] پلتفرم‌های NFV متن‌باز در دسترس هستند، یکی از نمایندگان آن openNetVM است.[۴۰] openNetVM یک پلتفرم NFV با عملکرد بالا است که بر اساس DPDK و کانتینرهای Docker ساخته شده است. openNetVM یک چارچوب انعطاف‌پذیر برای استقرار توابع شبکه و اتصال آنها به یکدیگر جهت ساخت زنجیره‌های خدمات فراهم می‌آورد. این پلتفرم نسخه متن‌باز از پلتفرم NetVM است که در مقالات NSDI 2014 و HotMiddlebox 2016 توصیف شده و تحت مجوز BSD منتشر شده است. کد منبع آن در GitHub: openNetVM قابل دسترسی است.[۴۱]

توابع شبکه مبتنی بر ابر (Cloud-native Network Functions)

[ویرایش]

از سال ۲۰۱۸، بسیاری از ارائه‌دهندگان VNF شروع به مهاجرت بسیاری از توابع شبکه خود به معماری مبتنی بر کانتینر کردند. این توابع شبکه که به توابع شبکه مبتنی بر ابر (CNF) شناخته می‌شوند، از بسیاری از نوآوری‌هایی که به‌طور معمول در زیرساخت اینترنتی پیاده‌سازی می‌شوند، استفاده می‌کنند. این نوآوری‌ها شامل اسکالینگ خودکار، پشتیبانی از مدل تحویل مداوم/ DevOps و افزایش کارایی با به اشتراک‌گذاری خدمات مشترک در پلتفرم‌ها است. از طریق کشف سرویس و ارکستراسیون، شبکه‌ای که بر اساس CNF ساخته شده باشد، در برابر خرابی‌های منابع زیرساختی مقاوم‌تر خواهد بود. استفاده از کانتینرها و حذف سربار ناشی از مجازی‌سازی سنتی از طریق حذف سیستم عامل مهمان می‌تواند کارایی منابع زیرساخت را به طرز چشمگیری افزایش دهد.[۴۲]

جستارهای وابسته

[ویرایش]

منابع

[ویرایش]
  1. "ETSI - Standards for NFV - Network Functions Virtualisation | NFV Solutions".
  2. "Network Functions Virtualisation (NFV); Use NFV is present and SDN is future" (PDF). Retrieved 6 June 2014.
  3. Stephenson, Rick (2013-03-13). "How Low-Cost Telecom Killed Five 9s in Cloud Computing". Wired. Retrieved 2016-06-27.
  4. ۴٫۰ ۴٫۱ "Network Functions Virtualization— Introductory White Paper" (PDF). ETSI. 22 October 2012. Retrieved 20 June 2013.
  5. "Network Functions Virtualisation". ETSI Standards for NFV. Retrieved 30 June 2020.
  6. Le Maistre, Ray (22 October 2012). "Tier 1 Carriers Tackle Telco SDN". Light Reading. Retrieved 20 June 2013.
  7. "Latest Agenda at SDN & OpenFlow World Congress". Layer123.com. Archived from the original on October 14, 2012. Retrieved 20 June 2013.
  8. "Standards for NFV: Network Functions Virtualisation". ETSI (به انگلیسی). NFV Solutions.
  9. "Network-Functions Virtualization (NFV) Proofs of Concept".
  10. "What is Network Function Virtualization (NFV)". blog.datapath.io. Archived from the original on 2017-02-01. Retrieved 2017-01-20.
  11. Ashton, Charlie (April 2014). "Don't Confuse "High Availability" with "Carrier Grade"". Embedded Community. Archived from the original on 2017-07-03.
  12. Tom Nolle (18 September 2013). "Is "Distributed NFV" Teaching Us Something?". CIMI Corporation's Public Blog. Retrieved 2 January 2014.
  13. Carol Wilson (3 October 2013). "RAD Rolls Out Distributed NFV Strategy". Light Reading. Retrieved 2 January 2014.
  14. "4 Vendors Bring Distributed NFV to BTE". Light Reading. June 11, 2014. Retrieved March 3, 2015.
  15. "RAD launches customer-edge distributed NFV solution based on ETX NTU platform". Optical Keyhole. June 16, 2014. Retrieved March 3, 2015.
  16. "RAD adds new partners to D-NFV Alliance". Telecompaper. December 9, 2014. Retrieved March 3, 2015.
  17. TMCnet News (26 June 2014). "Qosmos Awarded a 2014 INTERNET TELEPHONY NFV Pioneer Award". TMC. Retrieved 26 June 2014.
  18. "Platform to Multivendor Virtual and Physical Infrastructure".
  19. Liyanage, Madhusanka (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. UK: John Wiley. pp. 1–438. ISBN 978-1-118-90028-4.
  20. "Network Functions Virtualization (NFV) Use Cases" (PDF).
  21. "What's NFV – Network Functions Virtualization?". SDN Central.
  22. "Carrier Network Virtualization". ETSI news. Archived from the original on 31 October 2013. Retrieved 29 November 2024.
  23. "Openwave Exec Discusses the Benefits, Challenges of NFV & SDN". Article. 12 November 2013. Archived from the original on 3 March 2016. Retrieved 22 November 2013.
  24. Doyle, Lee. "Middleware for the NFV Generation". Service Provider IT Report.[پیوند مرده]
  25. Sharma, Ray. "Wind River Launches NFV Ecosystem Program with Five Industry Leaders". PCC Mobile Broadband.
  26. Ashton, Charlie (January 2015). "Carrier-Grade Reliability—A "Must-Have" for NFV Success". Electronic Design.
  27. Lemke, Andreas (November 2014). "5 must-have attributes of an NFV platform". Techzine, Alcatel-Lucent. Archived from the original on 2015-05-26.
  28. "Why Service Providers Need an NFV Platform" (PDF). Intel Strategic paper. Archived from the original (PDF) on 2015-05-26.
  29. "NFV Proof of Concept". ETSI.
  30. Wilson, Carol (16 September 2015). "New NFV Forum Focused on Interoperability". Light Reading.
  31. Nolle, Tom (June 2014). "Wind River's Ecosystemic Solution to NFV and Orchestration". CIMI Corporation Public Blog.
  32. Pettit, Justin (11 November 2014). "Accelerating Open vSwitch to "Ludicruos Speed"". Network Heresy: Tales of the network reformation.
  33. "Wind River Delivers Breakthrough Performance for Accelerated vSwitch Optimized for NFV". Wind River News Room. May 2014. Archived from the original on 24 April 2016. Retrieved 29 November 2024.
  34. "6WIND Announces Open vSwitch Acceleration for Red Hat Enterprise Linux OpenStack Platform". PRweb. April 2014.
  35. "Network Functions Virtualization Challenges and Solutions" (PDF). Alcatel-Lucent. 2013.
  36. "NFV: The Myth of Application-Level High Availability". Wind River. May 2015. Archived from the original on 2015-10-05.
  37. ETSI COMS TEAM. "ETSI - ETSI releases a standard for NFV Deployment Templates". ETSI. Retrieved 2019-07-09.
  38. "Technology blogs, NFV, MEC, NGP, ZSM, ENI - SOL006 – NFV descriptors based on YANG Specification". www.etsi.org. Retrieved 2019-07-09.
  39. Wang, Chengwei; Spatscheck, Oliver; Gopalakrishnan, Vijay; Xu, Yang; Applegate, David (2016). "Toward High-Performance and Scalable Network Functions Virtualization". IEEE Internet Computing. 20 (6): 10–20. doi:10.1109/MIC.2016.111. S2CID 15518060.
  40. "OpenNetVM: A Platform for High Performance Network Service Chains" (PDF). doi:10.1145/2940147.2940155. S2CID 13706879. {{cite journal}}: Cite journal requires |journal= (help)
  41. "GitHub- OpenNetVM". GitHub.
  42. "Cloud-Native Network Functions". Cisco. Retrieved 1 April 2021.

پیوند به بیرون

[ویرایش]