اگر ماشین مجازی به درخواست‌های کوچک پاسخ می‌دهد، اما انتقال فایل یا ارتباط برنامه هنگام جابه‌جایی داده‌های بزرگ دچار وقفه می‌شود، تنظیم MTU در OpenStack و Ceph یکی از مواردی است که باید بررسی کنید. این نشانه به‌تنهایی علت را ثابت نمی‌کند؛ ازدحام، خطای لینک و تنظیمات برنامه نیز ممکن است رفتار مشابهی ایجاد کنند.
در ابر خصوصی، مسیر شبکه معمولاً از چند لایه عبور می‌کند: رابط ماشین مجازی، شبکه مجازی، میزبان، سوییچ و گاهی تونل ارتباطی. هدف این راهنما، پیدا کردن ناسازگاری میان این لایه‌ها پیش از تغییر تنظیمات است.
MTU چیست و چرا در ابر خصوصی اهمیت دارد؟
MTU بیشترین اندازه بسته‌ای است که یک رابط شبکه در لایه مربوط به خود می‌تواند ارسال کند. هنگام بررسی MTU در سطح IP، نباید اندازه بسته IP را با اندازه کامل فریم اترنت یکسان گرفت؛ بعضی تجهیزات نیز محدودیت فریم را با اصطلاحات متفاوت نمایش می‌دهند.
وقتی بخشی از مسیر اندازه کوچک‌تری را می‌پذیرد، بسته‌های بزرگ ممکن است به سازوکارهای تطبیق اندازه وابسته شوند یا عبور نکنند. بنابراین، موفقیت یک تست اتصال کوچک برای تأیید سلامت انتقال بسته‌های بزرگ کافی نیست. تحلیل باید هم مسیر رفت و هم مسیر برگشت را پوشش دهد.
در OpenStack، سربار Overlay را در نظر بگیرید
طبق مستندات رسمی MTU در Neutron، مقدار MTU شبکه زیرین مبنای محاسبه MTU اجزای مجازی قرار می‌گیرد. در شبکه‌های Overlay، سربار کپسوله‌سازی از ظرفیت قابل استفاده کم می‌شود. برای نمونه، در مثال VXLAN با endpointهای IPv4، زیرساخت ۹۰۰۰ بایتی به MTU برابر ۸۹۵۰ بایت برای ماشین مجازی می‌رسد. این عدد را نباید به همه پروتکل‌ها و توپولوژی‌ها تعمیم داد.
گزینه‌های global_physnet_mtu و path_mtu در تعیین این رفتار نقش دارند و برای شبکه‌های فیزیکی متفاوت، تنظیمات اختصاصی نیز وجود دارد. تغییر این گزینه‌ها، ظرفیت سوییچ یا روتر را تغییر نمی‌دهد. همچنین شبکه‌های موجود ممکن است به به‌روزرسانی ویژگی MTU نیاز داشته باشند؛ روش اجرا را با نسخه و درایور استقرار خود تطبیق دهید.
مسیر Ceph را جداگانه بررسی کنید
مسیر ارتباط ماشین مجازی با برنامه، لزوماً همان مسیر ارتباط میزبان با Ceph نیست. ممکن است یک میزبان از شبکه‌ای برای ترافیک مهمان و از رابط دیگری برای ذخیره‌سازی استفاده کند. مستندکردن این دو مسیر از تغییر اشتباه شبکه جلوگیری می‌کند.
بر اساس مرجع شبکه Ceph Squid، کلاینت‌ها مستقیماً با OSDها ارتباط دارند و تکثیر داده نیز بار شبکه ایجاد می‌کند. Ceph می‌تواند با یک شبکه public کار کند؛ شبکه cluster جداگانه برای برخی ترافیک‌های داخلی قابل تعریف است، اما جداسازی همیشه بهبود محسوسی ایجاد نمی‌کند و پیچیدگی بیشتری دارد. واژه public در اینجا به معنای لزوم دسترسی از اینترنت نیست.
روش مرحله‌به‌مرحله عیب‌یابی ناسازگاری MTU
۱. سناریوی خطا را دقیق ثبت کنید
مشخص کنید اختلال میان کدام دو endpoint، روی چه شبکه‌ای و تحت چه باری دیده می‌شود. آیا ارتباط داخل یک میزبان سالم است و فقط بین میزبان‌ها مشکل دارد؟ آیا همه ماشین‌ها درگیرند یا فقط یک شبکه؟ این تفکیک، محدوده بررسی را کوچک‌تر می‌کند.
۲. نقشه مسیر و مقدار فعلی را جمع‌آوری کنید
برای هر مسیر، MTU رابط مهمان، رابط‌های مجازی، bridge یا تونل، bond، VLAN، کارت شبکه و تجهیزات بین راه را ثبت کنید. علاوه بر تنظیم اعلام‌شده، مسیر واقعی ترافیک را بررسی کنید؛ یک لینک پشتیبان با تنظیم متفاوت ممکن است تنها پس از جابه‌جایی مسیر مشکل را آشکار کند.
۳. اندازه بسته را به‌صورت کنترل‌شده آزمایش کنید
در محیط آزمایشی یا بازه کم‌بار، بسته‌هایی با اندازه افزایشی ارسال و رفتار را ثبت کنید. ابزار، خانواده IP و مجازبودن fragmentation در تفسیر نتیجه اهمیت دارند. مقدار payload ابزارهایی مانند ping با MTU برابر نیست، زیرا headerها نیز فضا می‌گیرند. فیلترشدن پاسخ ICMP هم می‌تواند نتیجه را مبهم کند؛ آن را به‌تنهایی اثبات خرابی MTU ندانید.
۴. شواهد شبکه و سرویس را کنار هم قرار دهید
هم‌زمان، خطا و drop رابط‌ها، تغییر مسیر، retransmissionهای TCP و تأخیر برنامه را بررسی کنید. اگر مشکل هنگام بار ذخیره‌سازی دیده می‌شود، تأخیر I/O و وضعیت شبکه Ceph را نیز مقایسه کنید. هم‌زمانی دو رخداد، سرنخ است و برای تعیین علت به آزمایش کنترل‌شده نیاز دارد.
۵. تغییر را محدود و قابل بازگشت اجرا کنید
ابتدا مقدار قبلی و روش بازگشت را ثبت کنید. یک مسیر یا گروه آزمایشی انتخاب و پس از تغییر، آزمون قبلی را تکرار کنید. سپس ارتباط با شبکه‌های بیرونی، راه‌اندازی مجدد مهمان و مسیر جایگزین را بررسی کنید. تنظیمات را در ابزار مدیریت پیکربندی نیز ثبت کنید تا تغییر دستی در استقرار بعدی از بین نرود.
آیا Jumbo Frame همیشه انتخاب بهتری است؟
Jumbo Frame را یک تصمیم قابل اندازه‌گیری در نظر بگیرید. افزایش MTU به‌تنهایی تضمین نمی‌کند تأخیر کمتر یا ظرفیت بیشتری داشته باشید. نتیجه به نوع بار، تجهیزات و هماهنگی کل مسیر وابسته است. اگر مسیر کامل مشخص نیست، انتخاب یک مقدار بزرگ صرفاً به دلیل رایج‌بودن آن می‌تواند عیب‌یابی را دشوار کند.
برای ارزیابی، بار مشابه واقعی، نرخ خطا، مصرف منابع و زمان پاسخ را قبل و بعد از تغییر مقایسه کنید. معیار پذیرش را پیشاپیش تعیین کنید؛ مثلاً انتقال پایدار در بار هدف و نبود افزایش خطا. این معیار از نتیجه‌گیری بر اساس یک تست کوتاه جلوگیری می‌کند.
چک‌لیست پیش از تغییر MTU
- مسیر مهمان و مسیر ذخیره‌سازی جداگانه مستند شده‌اند.
- سربار Overlay و محدودیت همه تجهیزات مسیر مشخص است.
- تنظیم شبکه‌های موجود و روش دریافت MTU در مهمان بررسی شده است.
- مسیر پشتیبان و ارتباط با شبکه بیرونی در برنامه آزمون قرار دارند.
- مقدار قبلی، مسئول اجرا و روش بازگشت ثبت شده‌اند.
- شاخص‌های مقایسه قبل و بعد از تغییر تعریف شده‌اند.
پرسش‌های متداول
آیا تغییر Neutron به‌تنهایی کافی است؟
خیر. شبکه فیزیکی و مهمان نیز باید با طراحی سازگار باشند. تنظیمات Neutron جای پیکربندی تجهیزات زیرین را نمی‌گیرد.
آیا MTU مهمان و شبکه Ceph باید یکسان باشد؟
الزام عمومی برای یکسان‌بودن این دو وجود ندارد؛ ممکن است مسیرهای مستقلی داشته باشند. سازگاری در طول هر مسیر و محاسبه صحیح سربار اهمیت دارد.
آیا ping موفق یعنی MTU درست است؟
یک ping کوچک فقط همان سناریو را تأیید می‌کند. اندازه‌های مختلف، دو جهت مسیر و رفتار سرویس واقعی نیز باید بررسی شوند.
در طراحی ابر خصوصی مبتنی بر OpenStack و Ceph، مستندسازی مسیر و آزمون تغییرات شبکه باید بخشی از تحویل و نگهداری زیرساخت باشد. تنظیم MTU زمانی قابل اتکاست که نتیجه آن در مسیر واقعی و زیر بار مناسب تأیید شود.
منابع: مستندات رسمی Neutron و Ceph Squid، بررسی‌شده در ۲۹ اکتبر ۲۰۲۶. هنگام اجرا، مستندات نسخه نصب‌شده مرجع نهایی تنظیمات است.
نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *
نظر دهید تعداد کاراکتر مانده: 300