‏OVS و OVN: پشت‌صحنهٔ شبکهٔ OpenStack

نویسنده با یه سناریوی آشنا شروع می‌کنه: دو تا instance روی compute nodeهای مختلف، تو یه شبکه و tenant یکسان، همدیگه رو پینگ نمی‌کنن؛ با این‌که security group مجوز ICMP داده و شبکهٔ فیزیکی هم بالاست. به گفتهٔ نویسنده، تو OpenStack Neutron با OVN بیشتر گم‌شدن بسته‌های بین‌هاست، باگ نیستن — یه انکار flow منطقی هستن که منتظرن خونده بشن. برای همین باید بفهمی OVS و OVN تو دو لایه (dataplane و control plane) چطور کار می‌کنن.

مقاله اول SDN رو توضیح می‌ده. تو شبکه‌بندی سنتی، هر سوییچ و روتر control plane خودشو داره و برای تغییر مسیر ترافیک باید تک‌تک دستگاه‌ها رو دستی پیکربندی کنی؛ این تو یه کلاد با صدها هایپروایزر و هزاران VM غیرممکن می‌شه. SDN با جدا کردن control plane از data plane این بازی رو عوض می‌کنه: یه کنترلر مرکزی تصمیم می‌گیره ترافیک کجا بره و دستگاه‌ها فقط دستور رو اجرا می‌کنن.

تو این مدل، Open vSwitch (OVS) همون data plane پرسرعت روی هر هایپروایزره؛ یه سوییچ مجازی اپن‌سورس که OpenFlow صحبت می‌کنه، تونل‌هایی مثل VXLAN و Geneve رو پشتیبانی می‌کنه و برای دیتاسنترهای بزرگ ساخته شده. OVS از ۲۰۱۲ سوییچ پیش‌فرض Neutron بود، ولی یه محدودیت داشت: فقط قواعد سطح‌پایین OpenFlow رو نشون می‌داد، نه مفهوم‌های منطقی مثل «روتر مجازی» یا «security group». مدیریت مستقیم OVS تو مقیاس بالا یعنی نوشتن flowهای پیچیده با CLI.

این‌جا OVN (Open Virtual Network) میاد وسط. نویسنده می‌گه OVN جایگزین OVS نیست، بلکه روش می‌شینه و یه مدل شبکهٔ منطقی (سوییچ، روتر، پورت و ACL مجازی) می‌ده که خودکار به قواعد OpenFlow داخل OVS ترجمه می‌شه. یه تشبیه خوب: OVS کارگریه که بسته‌ها رو جابه‌جا می‌کنه و OVN مدیریه که تصمیم می‌گیره بسته کجا بره و توپولوژی شبکه رو به‌خاطر می‌سپاره. امروز OVN درایور پیش‌فرض Neutron تو بیشتر توزیع‌های OpenStackه.

مقاله توضیح می‌ده چرا ML2/OVN استاندارد شد. مدل قدیمی ML2/OVS به agentهای متعدد Neutron برای مسیریابی و DHCP تکیه داشت، محدودیت مقیاس داشت و مشکل معروف full-sync رو داشت که می‌تونست موقع ری‌استارت هم‌زمان کلی agent، دیتابیس Neutron یا RabbitMQ رو بخوابونه. OVN این کارها رو تو یه معماری SDN توزیع‌شده یکپارچه کرد: agent کمتر، مقیاس‌پذیری بهتر، و مسیریابی و DHCP توزیع‌شدهٔ بومی. از نسخهٔ 2023.1 (Antelope) به بعد، ML2/OVN گزینهٔ پیش‌فرض و توصیه‌شده برای استقرارهای جدیده.

قلب معماری OVN یه تبدیل سه‌لایه‌ست. وقتی کاربر تو OpenStack شبکه یا روتر یا security group می‌سازه، درایور ML2/OVN اونو به موجودیت‌های منطقی تبدیل می‌کنه و تو دیتابیس Northbound (NBDB) می‌ذاره؛ این دیتابیس «حالت مطلوب» شبکه‌ست و به سوال «شبکهٔ مجازی باید چه شکلی باشه؟» جواب می‌ده. بعد دیمن ovn-northd این تعریف منطقی رو به جزئیات پیاده‌سازی ترجمه می‌کنه و تو دیتابیس Southbound (SBDB) می‌نویسه که جواب سوال «هر نود چطور این حالت رو پیاده کنه؟»ه. در نهایت ovn-controller روی هر compute/gateway node این دیتابیس رو می‌خونه و OVS محلی رو با تونل‌ها و flowهای مناسب برنامه‌ریزی می‌کنه.

نویسنده فرق east-west و north-south رو هم مهم می‌دونه. ترافیک east-west یعنی ارتباط بین workloadهای داخل کلاد (مثلاً VM به VM)؛ این معمولاً داخل overlay می‌مونه و تو تونل Geneve/VXLAN کپسوله می‌شه و به gateway فیزیکی نمی‌رسه، مگه از شبکهٔ provider لایهٔ ۳ عبور کنه. ترافیک north-south یعنی ارتباط با دنیای بیرون (مثل دسترسی به یه سرور با Floating IP یا دانلود از اینترنت)؛ این باید از overlay خارج شه و از طریق روترهای مجازی، NAT (برای Floating IP) و پورت localnetِ متصل به bridge فیزیکی (معمولاً br-ex) به شبکهٔ فیزیکی برسه.

برای عیب‌یابی، مقاله ابزار ovn-trace رو معرفی می‌کنه که به‌جای فرستادن بستهٔ واقعی، سفر بسته رو تو pipelineهای منطقی OVN شبیه‌سازی می‌کنه و مرحله‌به‌مرحله نشون می‌ده کدوم flow مچ می‌شه و بسته کجا خارج یا drop می‌شه. مسیر بسته بسته به مقصد فرق می‌کنه: مقصد روی همون سوییچ منطقی فقط L2 switching و ACL می‌بینه؛ مقصد روی شبکهٔ دیگهٔ همون tenant وارد pipeline روتر منطقی می‌شه (کاهش TTL، lookup مسیر، بازنویسی MAC)؛ و مقصد بیرون کلاد از SNAT/DNAT و انتخاب gateway chassis رد می‌شه. نکتهٔ ظریف اینه که یه خرابی مثل نبود SNAT فقط اتصال بیرونی رو می‌شکنه و به ترافیک east-west دست نمی‌زنه.

جمع‌بندی نویسنده یه رویکرد عیب‌یابیِ بالا‌به‌پایینه: به‌جای پریدن مستقیم سراغ packet capture، اول Southbound DB رو ببین که OVN فکر می‌کنه چی باید رو سیم اتفاق بیفته، بعد Northbound DB رو چک کن که Neutron اولش چی خواسته، و این دو رو مقایسه کن. به گفتهٔ نویسنده، تو بیشتر موارد ریشهٔ مشکل تو فاصلهٔ بین قصد و تحقق زندگی می‌کنه: یه chassis تکراری، یه binding کهنه، یه logical flow پردازش‌نشده یا یه ACL اشتباه اعمال‌شده.

نکات کلیدی:

• OVS یه data plane برنامه‌پذیره و OVN یه control plane توزیع‌شده که مفهوم‌های منطقی رو به OpenFlow ترجمه می‌کنه.
• معماری سه‌لایه: Neutron → دیتابیس Northbound (قصد) → ovn-northd → دیتابیس Southbound (تحقق) → ovn-controller → OVS.
• ML2/OVN از نسخهٔ Antelope پیش‌فرض شد چون agent کمتر و مقیاس‌پذیری بهتری نسبت به ML2/OVS داره.
• برای عیب‌یابی، ovn-trace مسیر منطقی بسته رو شبیه‌سازی می‌کنه؛ ریشهٔ اکثر مشکلات، فاصلهٔ بین قصد و تحققه.