OVN چیست؟ بررسی کاربرد و نحوه مدیریت شبکه‌های مجازی

OVN چیست و چگونه شبکه‌های مجازی را مدیریت می‌کند؟

23 سپتامبر 2026
10 دقیقه

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

اینجاست که OVN (Open Virtual Network) وارد میدان می‌شود؛ سیستمی که منطق شبکه را از سخت‌افزار فیزیکی جدا کرده و یک Control Plane متمرکز برای مدیریت دیتاسنترهای مقیاس‌پذیر ارائه می‌دهد. در این مقاله قرار است زیر کاپوت OVN را بررسی کنیم، جایگاه آن را در اکوسیستم OpenStack بشناسیم و نحوه اتصالش به شبکه فیزیکی را باز کنیم. با درک Trade-offهای این معماری، یاد می‌گیرید که چگونه امنیت، هدایت ترافیک و خطایابی را در محیط‌های Production بهینه‌تر مدیریت کنید.

OVN چیست و چه نقشی در شبکه دارد؟

پروژه OVN (Open Virtual Network) در هسته خود، یک Control Plane توزیع‌شده برای Open vSwitch (OVS) است. وقتی کلاستر شما بزرگ می‌شود، مدیریت دستی جریان‌های شبکه روی تک‌تک نودها غیرممکن و مستعد خطاست. OVN با ایجاد یک لایه انتزاعی، این چالش را حل می‌کند؛ شما توپولوژی منطقی شبکه (سوییچ‌ها، روترها و ACLها) را طراحی می‌کنید و OVN آن را به‌صورت خودکار به پیکربندی‌های اجرایی در لایه زیرساخت ترجمه می‌کند.

جدول زیر مرزهای عملکردی این دو کامپوننت را روشن‌تر می‌کند:

ویژگی	OVS (Open vSwitch)	OVN (Open Virtual Network)
لایه عملکردی	Data Plane (لایه انتقال)	Control Plane (لایه مدیریت)
مسئولیت اصلی	سوئیچینگ و فوروارد کردن پکت‌ها	ترجمه معماری منطقی به تنظیمات OVS
محدوده آگاهی	محدود به نود محلی (Local Node)	دید جامع و سراسری به کل کلاستر

بزرگ‌ترین دستاورد این ساختار، حذف گلوگاه‌های متمرکز است. چون OVN روتینگ را به‌صورت توزیع‌شده روی تمام نودها اعمال می‌کند، ترافیک برای مسیریابی نیازی به عبور از یک روتر مرکزی (Hairpinning) ندارد و این یعنی کاهش چشم‌گیر تاخیر (Latency) در ارتباطات.

OVN در معماری OpenStack چه جایگاهی دارد؟

پلتفرم OpenStack به عنوان استاندارد اصلی راه‌اندازی و ارائه خدمات ابر خصوصی، برای ارکستریشن شبکه به کامپوننت Neutron متکی است. در معماری‌های قدیمی (مثل معماری سنتی ML2/OVS)، مقیاس‌پذیری شبکه با دو گلوگاه جدی روبه‌رو می‌شد: سربار شدید روی Message Queueها (نظیر RabbitMQ) و تمرکز فشار مسیریابی روی Network Nodeها.

جایگاه OVN در OpenStack، دقیقاً عبور از این معماری متمرکز و حذف گلوگاه‌های ترافیکی است. در استقرارهای مدرن، OVN به کمک مکانیزم‌های یکپارچه‌ساز مستقیماً درایور شبکه Neutron می‌شود و جایگزین ایجنت‌های پردردسر آن (مثل L2/L3 Agent و DHCP Agent) روی نودهای پردازشی (Compute Nodes) می‌گردد.

نتیجه‌ی عملیاتی این تغییر معماری چیست؟

وقتی یک شبکه یا روتر مجازی جدید در داشبورد OpenStack تعریف می‌کنید، نیازی به درگیر شدن صف‌های پیام‌رسان سنگین نیست. OVN تغییرات را دریافت کرده، مستقیماً در پایگاه‌داده توزیع‌شده‌ی خود می‌نویسد و با سرعت بالا روی نودهای هدف اعمال می‌کند. این ساختار، علاوه بر کاهش چشم‌گیر زمان پروویژن شدن منابع شبکه، پایداری کلاستر را در زمان لود بالا تضمین می‌کند.

اجزای اصلی OVN چگونه با یکدیگر کار می‌کنند؟

معماری OVN بر پایه همگام‌سازی وضعیت (State Synchronization) بنا شده است و برخلاف راهکارهای قدیمی، نیازی به Message Brokerهای سنگین و مستعد قطعی ندارد. این سیستم برای ترجمه بی‌نقص تنظیمات شبکه از لایه منطقی به لایه فیزیکی، گردش کار خود را روی چهار کامپوننت اصلی متمرکز می‌کند:

پایگاه‌داده OVN-NB (Northbound): نقطه ورود تنظیمات است. این دیتابیس، معماری سطح بالای شبکه (مثل ساخت سوییچ، روتر یا قوانین ACL) را از پلتفرم ارکستریشن (مانند OpenStack) دریافت و ذخیره می‌کند.
سرویس ovn-northd (مغز ترجمه): این سرویس دائماً دیتابیس Northbound را پایش می‌کند. توپولوژی منطقی را می‌خواند، آن را به جریان‌های داده‌ای قابل‌فهم (Logical Flows) تبدیل کرده و به دیتابیس لایه پایین‌تر می‌فرستد.
پایگاه‌‌داده OVN-SB (Southbound): مرکز حقیقت (Source of Truth) شبکه شماست. این دیتابیس علاوه بر نگهداری جریان‌های منطقی، اطلاعات لحظه‌ای و وضعیت فیزیکی تمام نودهای کلاستر و پورت‌ها را ذخیره می‌کند.
سرویس ovn-controller (ایجنت محلی): این ایجنت روی تک‌تک نودهای پردازشی (Compute Nodes) در حال اجراست. تغییرات دیتابیس Southbound را می‌خواند و آن‌ها را مستقیماً به رول‌های OpenFlow برای ماشین Open vSwitch (OVS) در همان نود ترجمه می‌کند.

روند کار در پروداکشن به شکل آبشاری است؛ نودهای زیرساخت هرگز مستقیماً با لایه مدیریت (CMS) درگیر نمی‌شوند و فقط به دیتابیس Southbound گوش می‌دهند. بسته به ابعاد کلاستر و برای جلوگیری از Single Point of Failure، معماری این دیتابیس‌ها معمولاً روی الگوریتم توافقی Raft کلاستر می‌شود تا پایداری و High Availability در Control Plane تضمین گردد.

OVN چگونه شبکه‌های مجازی را مدیریت می‌کند؟

مدیریت شبکه‌های مجازی در OVN بر پایه معماری Overlay Network و مکانیزم‌های تونل‌زنی (عمدتاً پروتکل Geneve) استوار است. OVN به جای درگیر کردن تجهیزات زیرساختی با روتینگ ماشین‌های مجازی، سوییچ‌ها و روترهای منطقی (Logical) ایجاد می‌کند. زمانی که یک پکت از ماشین مجازی خارج می‌شود، ایجنت ovn-controller در همان نود پردازشی، قوانین لایه دوم و سوم را روی آن اعمال کرده و در صورت نیاز به ارسال در بستر شبکه، پکت را مستقیماً به سمت نود مقصد کپسوله (Encapsulate) می‌کند.

بزرگ‌ترین دستاورد فنی این معماری، پیاده‌سازی روتینگ توزیع‌شده (Distributed Routing) است. برای درک اثر عملیاتی این طراحی، سناریوی زیر را بررسی می‌کنیم:

سناریوی واقعی: عیب‌یابی تاخیر در ترافیک East-West

معرفی مسئله در پروداکشن: ارتباطات داخلی بین سرویس‌های دیتابیس و کانتینرهای بک‌اند (مستقر در Subnetهای متفاوت) با تاخیر شبکه‌ای غیرمنطقی روبه‌رو بود و این موضوع باعث افت پرفورمنس کوئری‌ها می‌شد.
علت ایجاد مشکل: در معماری قبلی، پکت‌ها برای جابه‌جایی بین دو Subnet حتی روی یک Hypervisor مشترک، مجبور بودند به یک نود شبکه (Network Node) مرکزی بروند و دوباره به همان سرور برگردند (پدیده Hairpinning).
روند تحلیل و انتخاب راهکار: با استقرار OVN، روتر منطقی به‌صورت توزیع‌شده روی تمامی نودها قرار گرفت. در این ساختار، نیاز به عبور ترافیک از گلوگاه مرکزی از بین رفت؛ زیرا ovn-controller پردازش لایه ۳ (مسیریابی) را به‌صورت Local انجام داده و پکت را مستقیماً در همان سرور تحویل ماشین مقصد می‌دهد.
نتیجه فنی: حذف کامل وابستگی به روتر متمرکز، کاهش تاخیر (Latency) ترافیک داخلی تا ۶۰ درصد و جلوگیری از اشغال بی‌دلیل پهنای باند فیزیکی سوییچ‌های دیتاسنتر.

OVN چگونه به شبکه فیزیکی متصل می‌شود؟

اتصال شبکه‌های مجازی (Overlay) به زیرساخت فیزیکی دیتاسنتر در OVN از طریق پورت‌های ویژه‌ای به نام localnet انجام می‌شود. با این پورت‌ها، سوییچ منطقی مستقیماً به شبکه‌های VLAN یا Flat متصل شده و ترافیک بدون نیاز به کپسوله‌سازی (Tunneling) منتقل می‌گردد.

برای مدیریت ترافیک ورودی و خروجی اینترنت (North-South) و اعمال NAT، معماری OVN روی Distributed Gateway Ports تکیه می‌کند. از آنجا که ترافیک خارجی باید از مسیر مشخصی هدایت شود، این پورت‌ها روی نودهای فیزیکی اختصاصی (Gateway Chassis) متصل می‌شوند.

در محیط‌های Enterprise، انتخاب استراتژی پایداری برای این گیت‌وی‌ها یک تصمیم معماری مهم است:

استراتژی گیت‌وی	Trade-off (مبادله معماری)
Active-Backup	افزونگی ساده با مانیتورینگ BFD؛ اما محدود شدن پهنای باند خروجی به توان یک لینک فعال.
ECMP	توزیع بار روی چندین مسیر و استفاده حداکثری از ظرفیت فیزیکی؛ نیازمند کانفیگ پیچیده‌تر BGP در زیرساخت.

نقش OVN در شبکه ابر خصوصی چیست؟

معماری ابر خصوصی بر پایه اصل ایزولاسیون (Multi-tenancy) و تخصیص پویای منابع استوار است. OVN در این محیط به تیم‌های مهندسی اجازه می‌دهد شبکه‌های مجازی (VPC) خود را بدون نگرانی از تداخل آدرس‌های IP یا وابستگی به پیکربندی تجهیزات فیزیکی، در لحظه پروویژن کنند.

با این معماری، محدودیت‌های کلاسیک دیتاسنتر حذف می‌شود؛ برای مثال، سقف ۴۰۹۶ تایی شبکه‌های VLAN جای خود را به ظرفیت عظیم شناسه‌های پروتکل Geneve می‌دهد تا مقیاس‌پذیری در سطح میلیون‌ها شبکه منطقی فراهم شود.

با این حال، این انعطاف‌پذیری یک Trade-off مهم دارد: کپسوله‌سازی ترافیک در شبکه Overlay نیازمند تنظیم دقیق MTU در تجهیزات فیزیکی است. کوچک‌ترین عدم تطابق باعث قطعه‌قطعه شدن پکت‌ها (Fragmentation) و افت شدید پرفورمنس می‌شود. بسته به حجم ترافیک کلاستر، استفاده از کارت‌های شبکه هوشمند (SmartNICs) برای انتقال بار پردازشی OVS (تکنیک Hardware Offloading) می‌تواند گزینه بهینه‌ای برای دور زدن این گلوگاه باشد.

بیشتر بخوانید: تفاوت Snapshot و Backup در ابر خصوصی OpenStack و Ceph

OVN چگونه امنیت و جداسازی شبکه را مدیریت می‌کند؟

امنیت در شبکه‌های نرم‌افزاری صرفاً با دیوارهای آتش لبه شبکه تامین نمی‌شود؛ بلکه نیازمند اعمال سیاست‌های دسترسی (ACLs) در نزدیک‌ترین نقطه به بار کاری (Workload) است. در OVN، مکانیزم‌های امنیتی و ایزولاسیون به‌صورت توزیع‌شده پیاده‌سازی می‌شوند؛ یعنی قوانین امنیتی مستقیماً به پورت‌های منطقی متصل شده و توسط ایجنت محلی (ovn-controller) روی نود پردازشی اعمال می‌گردند.

این معماری دو مزیت عملیاتی بزرگ به همراه دارد:

حذف ترافیک اضافی: فیلترینگ پکت‌ها قبل از خروج از نود مبدأ انجام می‌شود و پکت‌های غیرمجاز منابع شبکه را درگیر نمی‌کنند.
بازدهی پردازشی: بار پردازشی دیوارهای آتش روی یک گره متمرکز انباشته نمی‌شود و میان تمامی نودهای کلاستر تقسیم می‌گردد.

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

چالش‌های پیاده‌سازی و عیب‌یابی OVN چیست؟

استقرار OVN در مقیاس پروداکشن، به دلیل وابستگی عمیق به لایه هسته لینوکس و ساختار پایگاه‌داده‌های توزیع‌شده، چالش‌های عیب‌یابی خاص خود را به همراه دارد. هنگامی که ارتباط بین کانتینرها یا ماشین‌های مجازی دچار اختلال می‌شود، ادمین زیرساخت با یک زنجیره پیچیده از کامپوننت‌ها (از پایگاه‌داده Southbound گرفته تا جریان‌های منطقی و رول‌های OVS) روبه‌روست.

پیچیدگی عیب‌یابی در این معماری ناشی از توزیع‌شدگی آن است. اگر اختلالی در شبکه زیرساخت (Underlay) رخ دهد یا سنکرون‌سازی در کلاستر Raft دیتابیس‌های OVN دچار تاخیر شود، ایجنت‌های محلی (ovn-controller) به‌موقع از تغییرات توپولوژی مطلع نمی‌شوند و همین امر می‌تواند به انحراف وضعیت شبکه (Network State Drift) بینجامد. ابزارهایی مانند ovn-trace برای رهگیری مسیر منطقی پکت‌ها و تحلیل جریان داده‌ها ابزارهای حیاتی هستند، اما استفاده از آن‌ها نیازمند تسلط کامل بر منطق ترجمه در OVN است.

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

OVN چه نقشی در مقیاس‌پذیری شبکه دارد؟

در زیرساخت‌های مقیاس‌پذیر، گلوگاه اصلی همیشه محدودیت سخت‌افزاری نیست، بلکه توانایی Control Plane در مدیریت حجم بالای تغییرات و رویدادهای شبکه است. در راهکارهای سنتی مبتنی بر ایجنت‌های متمرکز، با افزایش تعداد نودها و کانتینرها، بار سنگینی روی دوش سوییچ‌ها و صف‌های پیام‌رسان قرار می‌گرفت که عملاً مقیاس‌پذیری کلاستر را متوقف می‌کرد.

معماری OVN با استفاده از دیتابیس‌های توزیع‌شده و پردازش غیرمتمرکز، این محدودیت را از میان برمی‌دارد. در این ساختار، هر ایجنت محلی فقط تغییرات مربوط به نود خود را از دیتابیس Southbound می‌خواند؛ در نتیجه، با رشد کلاستر و افزایش تعداد پورت‌ها، فشار کمتری به هسته مدیریت وارد می‌شود.

البته مقیاس‌دهی به این سادگی هم بدون ملاحظه نیست. در کلاسترهای ابری بسیار بزرگ، تعداد کل پورت‌ها و رول‌های امنیتی روی دیتابیس Southbound تاثیر مستقیم می‌‌گذارد و در صورت کمبود منابع سخت‌افزاری روی نودهای کنترلر، زمان پاسخگویی پایگاه‌داده افزایش می‌یابد. بسته به نیازمندی‌های سیستم و تعداد نودها، بهینه‌سازی منابع سخت‌افزاری کنترل‌پلن و تنظیم دقیق فواصل همگام‌سازی (Heartbeat) در کلاستر Raft، از الزامات اصلی حفظ پرفورمنس در مقیاس‌های کلان است.

جمع‌بندی

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

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