چرا ظرفیت اسمی یک سوئیچ 48 پورت با عملکرد واقعی آن متفاوت است؟ بررسی Throughput، Switching Fabric و Bottleneck داخلی

وقتی درباره یک سوئیچ 48 پورت صحبت می‌کنیم، اولین عددی که توجه مدیر شبکه یا خریدار را جلب می‌کند، ظرفیت اسمی آن است. روی دیتاشیت نوشته شده است 176Gbps، 216Gbps یا حتی بالاتر. از نظر تئوری، این عدد باید تضمین کند که همه پورت‌ها می‌توانند همزمان با حداکثر سرعت خود کار کنند. اما در عمل، بسیاری از مهندسان شبکه با سناریویی مواجه می‌شوند که در آن با وجود سالم بودن لینک‌ها، نبود CRC و نبود خطای فیزیکی، باز هم Packet Drop، افزایش Latency یا افت Throughput دیده می‌شود. اینجا همان نقطه‌ای است که تفاوت ظرفیت اسمی و عملکرد واقعی آشکار می‌شود.

برای درک دقیق این موضوع باید سه مفهوم کلیدی را به‌صورت عمیق بررسی کنیم: Throughput واقعی، معماری Switching Fabric و Bottleneck داخلی. این سه عامل تعیین می‌کنند که آیا یک سوئیچ 48 پورت واقعاً می‌تواند همه پورت‌ها را همزمان با Full Speed سرویس دهد یا خیر.

ظرفیت اسمی دقیقاً به چه معناست؟

ظرفیت اسمی یا Switching Capacity عددی است که مجموع پهنای باند تئوری سوئیچ را نشان می‌دهد. این عدد معمولاً بر اساس مجموع ظرفیت ارسال و دریافت همه پورت‌ها محاسبه می‌شود. به عنوان مثال اگر یک سوئیچ 48 پورت گیگابیتی داشته باشیم، هر پورت 1Gbps در جهت ارسال و 1Gbps در جهت دریافت دارد. در حالت Full Duplex، این عدد برای هر پورت 2Gbps در نظر گرفته می‌شود. در نتیجه ظرفیت اسمی تئوری برابر خواهد بود با:

48 × 2Gbps = 96Gbps

اگر سوئیچ دارای Uplink ده گیگابیتی باشد، آن هم به این عدد اضافه می‌شود. اما این محاسبه تنها یک عدد ریاضی است. این عدد تضمین نمی‌کند که Fabric داخلی، بافرها و معماری پردازشی سوئیچ بتوانند در هر شرایط ترافیکی این حجم را مدیریت کنند.

Throughput واقعی؛ آنچه در شبکه اتفاق می‌افتد

Throughput واقعی میزان دیتایی است که عملاً در واحد زمان از سوئیچ عبور می‌کند. این عدد تحت تأثیر فاکتورهای متعددی قرار دارد؛ از جمله اندازه Packet، نوع ترافیک، الگوی ارتباطی بین پورت‌ها و وضعیت Uplink.

در بسیاری از تست‌های آزمایشگاهی، ظرفیت اسمی بر اساس Packetهای بزرگ 1518 بایتی اندازه‌گیری می‌شود. اما در شبکه واقعی، به‌ویژه در سناریوهایی مثل VoIP، ARP، DNS یا ترافیک کنترلی، تعداد زیادی Packet کوچک در حال عبور هستند. Packetهای کوچک فشار بیشتری بر CPU و Fabric وارد می‌کنند، زیرا تعداد Frame در ثانیه افزایش می‌یابد. در چنین شرایطی ممکن است Throughput واقعی کمتر از ظرفیت اسمی باشد، حتی اگر از نظر پهنای باند خام مشکلی وجود نداشته باشد.

نقش Switching Fabric در عملکرد واقعی سوئیچ

Switching Fabric هسته اصلی هر سوئیچ است. این بخش مسئول انتقال Frameها بین پورت‌هاست. نوع طراحی Fabric می‌تواند Shared، Crossbar یا مبتنی بر معماری ASICهای توزیع‌شده باشد. در سوئیچ‌های اقتصادی، معمولاً Fabric به‌صورت Shared طراحی می‌شود، یعنی همه پورت‌ها یک مسیر داخلی مشترک را به اشتراک می‌گذارند. در چنین معماری‌ای، اگر چندین پورت به‌صورت همزمان ترافیک سنگین تولید کنند، رقابت برای استفاده از Fabric آغاز می‌شود و در صورت اشباع، Packet Drop اتفاق می‌افتد.

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

Oversubscription؛ عامل پنهان Bottleneck

Oversubscription به نسبت مجموع ظرفیت پورت‌های Access به ظرفیت Uplink گفته می‌شود. فرض کنید یک سوئیچ 48 پورت گیگابیتی داریم که تنها دو Uplink ده گیگابیتی دارد. مجموع ظرفیت Access برابر 48Gbps است، در حالی که مجموع Uplink برابر 20Gbps است. در این حالت اگر همه کاربران همزمان بخواهند به سمت Core یا اینترنت ترافیک ارسال کنند، Uplink به Bottleneck تبدیل می‌شود.

در چنین شرایطی حتی اگر Switching Fabric ظرفیت کافی داشته باشد، محدودیت Uplink باعث کاهش Throughput و افزایش Packet Drop می‌شود. این یکی از رایج‌ترین دلایلی است که نشان می‌دهد ظرفیت اسمی یک سوئیچ 48 پورت الزاماً به معنای Full Speed همزمان برای همه پورت‌ها نیست.

بافر سوئیچ و تأثیر آن بر Packet Drop

هر سوئیچ دارای Buffer است؛ حافظه‌ای موقت برای نگهداری Packetها قبل از ارسال. در زمان‌هایی که ترافیک به‌صورت Burst وارد می‌شود، بافر نقش حیاتی در جلوگیری از Drop ایفا می‌کند. اما ظرفیت بافر محدود است. در سوئیچ‌های ارزان‌تر، بافر کوچک‌تر است و در برابر ترافیک انفجاری سریع‌تر اشباع می‌شود.

زمانی که بافر پر شود، سوئیچ مجبور به حذف Packetهای جدید خواهد شد. این موضوع معمولاً در خروجی دستور show interface به‌صورت افزایش Output Drops دیده می‌شود. جالب اینجاست که در چنین حالتی ممکن است هیچ Input Error یا CRC مشاهده نشود. لینک کاملاً سالم است، اما Bottleneck داخلی باعث افت عملکرد شده است.

پردازش CPU و کنترل پلین

بخشی از ترافیک شبکه از طریق ASIC فوروارد می‌شود و بخشی دیگر باید توسط CPU پردازش شود. پروتکل‌هایی مانند STP، ARP، LLDP و برخی انواع Broadcast در Control Plane پردازش می‌شوند. اگر حجم این نوع ترافیک زیاد شود، CPU تحت فشار قرار می‌گیرد و این فشار می‌تواند باعث کاهش کارایی کلی سوئیچ شود. در سناریوهایی مانند ARP Flood یا MAC Table Exhaustion، حتی اگر ظرفیت اسمی بالا باشد، سوئیچ ممکن است به دلیل فشار پردازشی دچار افت Throughput شود. بنابراین عملکرد واقعی تنها به عدد Switching Capacity وابسته نیست، بلکه به توان پردازشی و معماری Control Plane نیز وابسته است.

تفاوت ترافیک East-West و North-South

در شبکه‌های مدرن، بخش زیادی از ترافیک به‌صورت East-West یعنی بین سرورها یا کاربران داخل شبکه جریان دارد. اگر این ترافیک عمدتاً داخل همان سوئیچ باقی بماند، فشار روی Uplink کمتر است. اما در ترافیک North-South که به سمت Core یا اینترنت می‌رود، Uplink به عامل محدودکننده تبدیل می‌شود. در یک سوئیچ 48 پورت، اگر کاربران عمدتاً با یک سرور داخل همان سوئیچ ارتباط داشته باشند، امکان دستیابی به Throughput بالاتر وجود دارد. اما اگر همه کاربران به اینترنت متصل شوند، Uplink ظرفیت واقعی را تعیین می‌کند.

اندازه Packet و Frame Per Second

ظرفیت اسمی اغلب بر اساس بیت بر ثانیه اعلام می‌شود، اما یکی از شاخص‌های مهم دیگر Packet Per Second است. پردازش Packetهای کوچک‌تر نیازمند تعداد بیشتری عملیات در ثانیه است. بنابراین ممکن است سوئیچ از نظر Gbps اشباع نشده باشد، اما از نظر PPS به سقف برسد. در کاربردهایی مثل VoIP یا IoT که Packetهای کوچک زیادی تولید می‌شود، این محدودیت بیشتر نمایان می‌شود. بنابراین هنگام تحلیل عملکرد واقعی، بررسی PPS به اندازه بررسی Gbps اهمیت دارد.

Stack شدن سوئیچ‌ها و Bottleneck داخلی

در معماری Stack، چند سوئیچ از طریق لینک StackWise یا مشابه آن به یکدیگر متصل می‌شوند. اگر ظرفیت لینک Stack محدود باشد و ترافیک زیادی بین اعضای Stack جابجا شود، لینک Stack به Bottleneck تبدیل می‌شود. در این حالت ممکن است همه پورت‌ها فعال باشند، اما ترافیک داخلی بین سوئیچ‌ها باعث Drop شود. این سناریو به‌ویژه در طراحی‌هایی که VLANها به‌درستی توزیع نشده‌اند یا سرورها در سوئیچ‌های مختلف Stack قرار دارند، رایج است.

چرا عدد روی دیتاشیت کافی نیست؟

دیتاشیت معمولاً بهترین سناریوی ممکن را نشان می‌دهد. شرایط آزمایشگاهی، Packetهای بزرگ، نبود Broadcast Storm و نبود Oversubscription شدید. اما شبکه واقعی ترکیبی از Burst Traffic، Broadcast، Multicast و ترافیک نامتقارن است. به همین دلیل، ظرفیت اسمی تنها یکی از پارامترهای تصمیم‌گیری است. برای ارزیابی واقعی باید به معماری داخلی، اندازه بافر، نسبت Oversubscription، توان CPU و نوع کاربرد شبکه توجه کرد.

چگونه عملکرد واقعی را تحلیل کنیم؟

برای تحلیل دقیق عملکرد یک سوئیچ 48 پورت باید مانیتورینگ مستمر انجام شود. بررسی Interface Counters، میزان Output Drops، Queue Utilization و وضعیت CPU اطلاعات ارزشمندی ارائه می‌دهد. همچنین ابزارهای NetFlow یا sFlow می‌توانند الگوی ترافیکی را مشخص کنند. در بسیاری از موارد، مشکل نه در خود سوئیچ بلکه در طراحی شبکه است. کاهش Oversubscription، افزایش Uplink یا توزیع بهتر VLANها می‌تواند عملکرد واقعی را به ظرفیت اسمی نزدیک‌تر کند.

جمع‌بندی نهایی

تفاوت ظرفیت اسمی یک سوئیچ 48 پورت با عملکرد واقعی آن نتیجه ترکیبی از عوامل معماری، طراحی شبکه و الگوی ترافیک است. Switching Fabric، بافر، Uplink، Oversubscription، پردازش CPU و اندازه Packet همگی در تعیین Throughput واقعی نقش دارند. عددی که روی دیتاشیت درج شده یک ظرفیت تئوری است، نه تضمین عملکرد در همه سناریوها. اگر هدف دستیابی به Full Speed همزمان برای همه پورت‌ها باشد، باید طراحی شبکه با در نظر گرفتن Bottleneckهای داخلی انجام شود.

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