تجمیع شبکه در مراکز داده سازمانی با استفاده از زیرساخت همگرا و 10GbE رواج بیشتری پیدا می‌کند. در شرایطی که یک میزبان vSphere دیگر آپ‌لینک‌های مجزایی که توسط NFS برای عبور ترافیک استفاده می‌شوند، ندارد، ممکن است از خود بپرسید که چرا هنوز هم ایده خوبی است که یک پورت منحصر به فرد VMkernel برای عبور ترافیک NFS ایجاد شود. یا بیایید این را در یک سوال خلاصه کنیم:

اگر همه ترافیک از یک uplink خارج می‌شود، چرا باید برای عبور بسته‌های NFS یک پورت VMkernel منحصر به فرد بسازم؟

من فکر می‌کنم این یک سوال ارزشمند است، اما قبل از ادامه بحث، ابتدا به برخی فرضیات نیاز دارم.

ابتدا، باید فرض کنیم که شما از ترکیبی متمایز از VLAN و زیرشبکه برای ترافیک ذخیره‌سازی خود استفاده می‌کنید. دلایل خوب زیادی برای استفاده از VLANها برای تقسیم‌بندی ترافیک وجود دارد که در اینجا قصد ندارم به آنها بپردازم. پورت مدیریت VMkernel شما (که آن را vmk0 می‌نامیم) روی یک VLAN و آرایه ذخیره‌سازی روی VLAN دیگری خواهد بود. بنابراین، برای رسیدن از زیرشبکه مدیریت به زیرشبکه ذخیره‌سازی، مسیریابی بین VLAN مورد نیاز خواهد بود.

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

جریان‌های ترافیک NFS

بر اساس فرضیات بالا، بیایید سناریوی منطقی را بسازیم. VLAN 100 برای ترافیک مدیریت vSphere و VLAN 200 برای ترافیک آرایه ذخیره‌سازی استفاده می‌شود. نمودارهای زیر یک طراحی شبکه عمومی ۳ لایه را نشان می‌دهند. هر لایه تنها با چند سوئیچ نمایش داده می‌شود، اما در واقع ممکن است شامل سوئیچ‌های بسیار بیشتری باشد که همگی به هم متصل هستند. من برای این نمایش از سری Cisco Nexus استفاده می‌کنم.

بدون پورت NFS VMkernel

در این نمودار اول، دو مورد از مسیرهای ممکن که ترافیک باید برای رسیدن به آرایه ذخیره‌سازی شما طی کند را در زمانی که هیچ پورت VMkernel روی NFS VLAN وجود ندارد، شرح داده‌ام.

اساساً، بسته‌ها باید به نقطه‌ای برسند که بتوانند از یک VLAN به VLAN دیگر مسیریابی شوند. از آنجایی که مسیریابی L3 در لایه هسته اتفاق می‌افتد، ترافیک باید مسیر نسبتاً طولانی را طی کند تا به آرایه ذخیره‌سازی بازگردد. در مورد خط نارنجی، این وضعیت را برجسته می‌کند که شاید مشکلی در درخت پوشا یا چرخش‌های سنجاق سری باعث شده باشد که ترافیک در مسیر رسیدن به آرایه ذخیره‌سازی به یک سوئیچ توزیع کاملاً متفاوت منتقل شود.

به عبارت ساده، این یک طراحی ناکارآمد است که توان عملیاتی را در لایه‌های بالاتر هدر می‌دهد و سربار اضافی سوئیچ و تأخیر بسته را ایجاد می‌کند.

با پورت NFS VMkernel

در این نمودار، من یک پورت VMkernel را در زیرشبکه NFS اضافه کرده‌ام. دیگر نیازی به مسیریابی ترافیک نیست، بلکه فقط باید سوئیچ شود. دلیل این امر این است که هم منبع و هم مقصد در یک VLAN و زیرشبکه قرار دارند. اگر میزبان vSphere از آدرس MAC آرایه ذخیره‌سازی آگاه نباشد، کافی است یک درخواست ARP ارسال کند و سپس می‌تواند شروع به ارسال ترافیک کند.

علاوه بر نمودار بالا، می‌توانید آرایه ذخیره‌سازی را روی سوئیچی نزدیک‌تر به میزبان(های) vSphere نیز قرار دهید تا تعداد گام‌ها کاهش یابد. من محیط‌هایی را دیده‌ام که در آن‌ها ذخیره‌سازی به سوئیچ توزیع بالادستی (در این مورد، یک Nexus 5K) متصل بوده تا گام‌های بیشتر کاهش یابد.

در اینجا چند توپولوژی دیگر و جریان‌های آنها آمده است. توجه داشته باشید که مسیر نارنجی به نوع سوئیچ لایه دسترسی مورد استفاده بستگی دارد، زیرا من معتقدم که یک Nexus 2K، که فقط یک FEX است، همچنان نیاز به رفتن به 5K دارد.

نتیجه گیری

اگرچه اطلاعات شبکه‌ای فوق چیز شگفت‌انگیزی نیست، اما باید یک واقعیت ساده را برجسته کند که همیشه ایده خوبی است که هنگام استفاده از NFS، یک پورت VMkernel در همان زیرشبکه آرایه ذخیره‌سازی ایجاد کنید. حتی در سناریویی که فقط از یک سوئیچ استفاده می‌شود، سوئیچ همچنان باید ترافیک را از یک VLAN به دیگری هدایت کند، که باعث ایجاد سربار و احتمالاً تأخیر می‌شود، بدون هیچ دلیل واقعی. من شخصاً یک VLAN غیرقابل مسیریابی را برای ترافیک ذخیره‌سازی NFS ترجیح می‌دهم، مگر اینکه آرایه نتواند رابط‌های مجازی را مدیریت کند یا حاوی رابط مدیریتی نباشد که بتوان آن را در VLAN مدیریتی جداگانه قرار داد.