چطور ظرفیت F5 BIG-IP را بر اساس تعداد Session و TPS درست سایز کنیم؟

سایزینگ F5 BIG-IP یکی از آن موضوعاتی است که اگر درست انجام شود، سال‌ها خیال تیم فنی را راحت می‌کند و اگر اشتباه انجام شود، حتی قوی‌ترین معماری‌ها را هم به نقطه گلوگاه می‌رساند. برخلاف تصور رایج، انتخاب مدل F5 فقط بر اساس پهنای باند یا تعداد هسته CPU تصمیم درستی نیست. در دنیای واقعی، ظرفیت F5 بیشتر از هر چیز به تعداد Session هم‌زمان، نرخ ایجاد Session جدید و TPS (Transaction Per Second) وابسته است.

در بسیاری از پروژه‌ها، F5 از نظر Throughput هنوز ظرفیت دارد، اما به‌دلیل اشباع Session Table یا فشار ناشی از TPS بالا، با Delay، Drop یا حتی Reset Connection مواجه می‌شود. این مقاله با رویکردی کاملاً مهندسی و مبتنی بر تجربه پروژه‌های Enterprise، توضیح می‌دهد چطور باید ظرفیت F5 BIG-IP را بر اساس Session و TPS به‌درستی تحلیل و سایز کرد.

چرا سایزینگ F5 فقط با پهنای باند اشتباه است

سایزینگ F5 صرفاً بر اساس پهنای باند یکی از رایج‌ترین و در عین حال پرهزینه‌ترین اشتباهات در طراحی زیرساخت‌های Application Delivery است. این رویکرد از یک فرض نادرست نشأت می‌گیرد: اینکه F5 فقط نقش یک عبوردهنده ترافیک را دارد و هرچه حجم ترافیک کمتر از ظرفیت لینک باشد، مشکلی وجود نخواهد داشت. در حالی که در معماری‌های واقعی، F5 بسیار فراتر از یک دستگاه L4 عمل می‌کند و بخش عمده‌ای از بار پردازشی آن هیچ ارتباط مستقیمی با Mbps یا Gbps ندارد.

در دنیای واقعی، F5 بیشتر با «تعداد» و «نرخ» سروکار دارد تا «حجم». هر Session جدید، هر Handshake، هر درخواست HTTP یا API، و هر تصمیم Policy نیازمند پردازش CPU، مصرف Memory و استفاده از Tableهای داخلی است. ممکن است کل ترافیک شما فقط چند صد مگابیت باشد، اما اگر این ترافیک از هزاران کاربر با Sessionهای کوتاه و Requestهای مکرر تولید شود، فشار واقعی روی F5 بسیار بیشتر از یک لینک چند گیگابیتی با ترافیک پایدار خواهد بود.

یکی از سناریوهای بسیار رایج این است که F5 از نظر Throughput کاملاً سالم است، اما به‌دلیل بالا بودن نرخ ایجاد Connection یا TPS، CPU به سقف می‌رسد. در این حالت، هیچ هشدار مستقیمی درباره اشباع پهنای باند وجود ندارد، اما کاربران با علائمی مانند Delay تصادفی، Timeout یا Reset Connection مواجه می‌شوند. این نوع اختلال‌ها معمولاً به‌اشتباه به Backend یا شبکه نسبت داده می‌شوند، در حالی که ریشه مشکل در سایزینگ اشتباه F5 بر اساس معیار نادرست است.

عامل مهم دیگر، نقش ماژول‌ها و Featureهای فعال روی F5 است. SSL Termination، WAF، APM، Rate Limiting و iRuleها همگی بار پردازشی مستقل از حجم ترافیک ایجاد می‌کنند. برای مثال، یک Request چند کیلوبایتی که نیاز به SSL Decryption، WAF Inspection و اجرای iRule دارد، ممکن است چندین برابر یک Request حجیم ساده CPU مصرف کند. در چنین شرایطی، نگاه کردن به Mbps نه‌تنها کمکی نمی‌کند، بلکه کاملاً گمراه‌کننده است.

پهنای باند همچنین هیچ تصویری از رفتار Burstی ترافیک ارائه نمی‌دهد. بسیاری از اپلیکیشن‌ها در بازه‌های کوتاه دچار Spike در TPS یا Session Creation Rate می‌شوند. این Burstها ممکن است فقط چند ثانیه طول بکشند، اما اگر F5 برای تحمل آن‌ها سایز نشده باشد، دقیقاً در همین لحظات دچار افت عملکرد می‌شود. سایزینگ مبتنی بر میانگین پهنای باند، این واقعیت را کاملاً نادیده می‌گیرد.

نکته مهم دیگر، تفاوت بنیادین بین ترافیک کاربرمحور و سیستم‌محور است. در APIها، یک Client می‌تواند با حجم ترافیک بسیار کم، TPS بسیار بالایی ایجاد کند. در این سناریو، پهنای باند تقریباً بی‌اهمیت است، اما Session Rate و TPS تعیین‌کننده‌اند. سایزینگ مبتنی بر پهنای باند در چنین معماری‌هایی تقریباً همیشه منجر به انتخاب F5 کوچک‌تر از نیاز واقعی می‌شود.

Session و TPS در F5 دقیقاً چه معنایی دارند

در سایزینگ و تحلیل ظرفیت F5 BIG-IP، مفاهیم Session و TPS اغلب به‌صورت اشتباه یا ساده‌سازی‌شده استفاده می‌شوند، در حالی که هرکدام لایه متفاوتی از بار واقعی سیستم را توصیف می‌کنند. درک دقیق این دو مفهوم، پایه اصلی تصمیم‌گیری درست در انتخاب مدل F5 و پیش‌بینی رفتار آن در شرایط واقعی است.

Session در F5 به‌طور کلی به معنای یک ارتباط فعال که نیازمند نگه‌داشت State است می‌باشد، اما این تعریف بسته به لایه‌ای که به آن نگاه می‌کنیم، می‌تواند متفاوت باشد. در ساده‌ترین حالت، Session می‌تواند یک TCP Connection فعال باشد که از زمان Handshake تا Close شدن نگه‌داری می‌شود. هر Session مصرف‌کننده منابعی مانند Memory، Table Entry و بخشی از Context پردازشی است. هرچه تعداد Sessionهای هم‌زمان بیشتر باشد، فشار بیشتری روی حافظه و ساختارهای کنترلی F5 وارد می‌شود.

اما در بسیاری از سناریوهای Application-level، Session مفهومی فراتر از TCP دارد. برای مثال، در F5 APM یا در Persistenceهای مبتنی بر Cookie، Session به معنای نگه‌داشت وضعیت کاربر است، حتی اگر Connectionهای زیرین مرتب باز و بسته شوند. در این حالت، یک کاربر می‌تواند چندین Connection کوتاه‌مدت داشته باشد، اما فقط یک Session منطقی. این تفاوت باعث می‌شود که صرف نگاه کردن به تعداد Connectionها تصویر کاملی از بار واقعی ایجاد نکند.

TPS یا Transaction Per Second مفهومی کاملاً متفاوت را اندازه‌گیری می‌کند. TPS نشان‌دهنده نرخ پردازش درخواست‌هاست، نه تعداد ارتباط‌های هم‌زمان. هر HTTP Request، API Call یا Transaction منطقی که نیازمند بررسی، تصمیم‌گیری و پردازش توسط F5 باشد، یک واحد TPS محسوب می‌شود. TPS بیشتر به CPU و توان پردازشی وابسته است، در حالی که Session بیشتر به Memory و ظرفیت نگه‌داری State مرتبط است.

نکته کلیدی اینجاست که یک Session می‌تواند TPS بسیار بالایی تولید کند یا تقریباً هیچ TPSی نداشته باشد. برای مثال، یک Connection Keep-Alive که کاربر روی آن ده‌ها Request در ثانیه ارسال می‌کند، TPS بالایی دارد اما فقط یک Session محسوب می‌شود. برعکس، اپلیکیشنی با Connectionهای کوتاه‌عمر ممکن است Sessionهای زیادی ایجاد کند، اما TPS متوسطی داشته باشد. این تفاوت دقیقاً همان جایی است که سایزینگ‌های اشتباه شکل می‌گیرند.

در اپلیکیشن‌های مدرن، به‌ویژه APIمحورها، TPS معمولاً عامل محدودکننده اصلی است. یک Client می‌تواند با حجم بسیار کم داده، صدها Request در ثانیه ارسال کند. در این سناریو، پهنای باند تقریباً بی‌اهمیت است، اما CPU F5 به‌سرعت تحت فشار قرار می‌گیرد. در مقابل، در سیستم‌هایی با کاربران زیاد و Sessionهای بلندمدت، مانند پورتال‌های سازمانی، معمولاً تعداد Session هم‌زمان عامل اصلی محدودکننده است.

رابطه Session و TPS همچنین به Featureهای فعال روی F5 وابسته است. SSL Termination، WAF Inspection، iRule Processing یا APM Authentication باعث می‌شوند هر TPS هزینه پردازشی بیشتری داشته باشد. یعنی دو F5 با TPS یکسان، اما با Featureهای متفاوت، رفتار کاملاً متفاوتی از نظر مصرف CPU خواهند داشت. به همین دلیل، TPS اعلام‌شده در Datasheet بدون در نظر گرفتن سناریوی واقعی استفاده، عددی گمراه‌کننده است.

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

رابطه مستقیم Session، TPS و مصرف منابع F5

در F5، هر Session مصرف‌کننده منابع مختلفی است؛ از حافظه گرفته تا CPU و Tableهای داخلی. افزایش تعداد Session هم‌زمان، Memory Pressure ایجاد می‌کند و افزایش TPS، CPU Pressure. اگر یکی از این دو به سقف برسد، حتی اگر دیگری آزاد باشد، عملکرد کلی افت می‌کند.

در پروژه‌های واقعی، بارها دیده شده F5 از نظر Memory کاملاً سالم است، اما CPU به‌دلیل TPS بالا به ۸۰ یا ۹۰ درصد می‌رسد. در این وضعیت، ایجاد Session جدید کند می‌شود و کاربران با Delay یا Timeout مواجه می‌شوند. برعکس این حالت هم ممکن است رخ دهد؛ TPS متوسط است، اما Sessionهای Long-lived باعث پر شدن Tableها می‌شوند.

تحلیل الگوی Session در اپلیکیشن قبل از سایزینگ

سایزینگ درست F5 بدون شناخت الگوی Session اپلیکیشن تقریباً غیرممکن است. باید مشخص شود Sessionها کوتاه‌عمر هستند یا بلندمدت، آیا Keep-Alive فعال است یا خیر، و کاربران به‌طور متوسط چند Session هم‌زمان دارند.

برای مثال، اپلیکیشن‌هایی که از HTTP Keep-Alive یا HTTP/2 استفاده می‌کنند، TPS بالاتری دارند ولی Sessionهای کمتری ایجاد می‌کنند. در مقابل، اپلیکیشن‌هایی با Sessionهای کوتاه و Connectionهای مکرر، فشار زیادی روی Connection Setup Rate وارد می‌کنند. این تفاوت‌ها مستقیماً روی انتخاب مدل F5 تأثیر می‌گذارند.

نقش SSL و تأثیر آن بر TPS و Session

SSL Termination یکی از مهم‌ترین عوامل تأثیرگذار بر سایزینگ F5 است. Handshakeهای SSL به‌ویژه در TLSهای مدرن مصرف CPU بالایی دارند. اگر Session Reuse یا Session Cache به‌درستی طراحی نشده باشد، TPS مؤثر چند برابر می‌شود.

در بسیاری از پروژه‌ها، تعداد کاربران زیاد نیست، اما به‌دلیل عدم استفاده از SSL Session Reuse، هر Request یک Handshake جدید ایجاد می‌کند. این موضوع باعث می‌شود F5 خیلی زود به سقف TPS خود برسد، حتی اگر از نظر پهنای باند کاملاً آزاد باشد. بنابراین در سایزینگ باید مشخص شود چه درصدی از ترافیک شامل Handshake جدید است.

تأثیر ماژول‌ها بر ظرفیت واقعی F5

مدل F5 روی کاغذ ممکن است عدد مشخصی برای TPS یا Concurrent Session اعلام کند، اما این اعداد معمولاً در حالت پایه و بدون ماژول‌های سنگین هستند. فعال بودن WAF، APM، iRules پیچیده یا Bot Protection می‌تواند ظرفیت واقعی را به‌طور قابل توجهی کاهش دهد.

برای مثال، WAF با Deep Inspection باعث افزایش مصرف CPU به‌ازای هر Request می‌شود. APM با نگه‌داشتن State کاربران، فشار بیشتری روی Memory و Session Table ایجاد می‌کند. بنابراین سایزینگ باید بر اساس سناریوی واقعی استفاده انجام شود، نه اعداد Datasheet.

محاسبه تقریبی ظرفیت بر اساس Session

در یک رویکرد عملی، ابتدا باید تعداد کاربران هم‌زمان و میانگین Session هر کاربر مشخص شود. اگر مثلاً ۱۰ هزار کاربر هم‌زمان داریم و هر کاربر به‌طور متوسط ۵ Session فعال دارد، F5 باید حداقل ۵۰ هزار Session هم‌زمان را با حاشیه امن مدیریت کند.

اما این عدد پایان کار نیست. باید Peakها، Failover Scenario و رشد آینده نیز در نظر گرفته شوند. در معماری‌های HA، معمولاً فرض می‌شود یک Device بتواند بار هر دو را تحمل کند. این یعنی سایزینگ باید حداقل برای ۱.۵ تا ۲ برابر بار عادی انجام شود.

محاسبه TPS در سناریوهای واقعی

برای TPS، باید به رفتار واقعی اپلیکیشن نگاه کرد. اگر هر کاربر در اوج مصرف ۱۰ Request در ثانیه ارسال می‌کند و ۵ هزار کاربر فعال داریم، TPS برابر با ۵۰ هزار خواهد بود. این عدد برای APIمحورها یا سیستم‌های مالی می‌تواند به‌مراتب بیشتر باشد.

نکته مهم این است که TPS پایدار با TPS لحظه‌ای تفاوت دارد. F5 باید بتواند Burstهای کوتاه‌مدت را هم تحمل کند. بسیاری از اختلال‌ها دقیقاً در همین Burstها رخ می‌دهند، نه در بار متوسط.

تست و Validation قبل از انتخاب نهایی

هیچ سایزینگی بدون تست معتبر نیست. استفاده از ابزارهای Load Test برای شبیه‌سازی TPS و Session واقعی قبل از خرید یا نهایی‌سازی مدل F5 بسیار ارزشمند است. این تست‌ها اغلب نشان می‌دهند گلوگاه واقعی کجاست؛ CPU، Memory یا SSL.

در پروژه‌های حرفه‌ای، سایزینگ یک فرآیند Iterative است. ابتدا برآورد انجام می‌شود، سپس تست، و در نهایت اصلاح اعداد بر اساس نتایج واقعی.

اشتباهات رایج در سایزینگ F5

یکی از اشتباهات رایج، سایزینگ فقط برای وضعیت عادی و نادیده گرفتن Failover است. اشتباه دیگر، اتکا به Datasheet بدون در نظر گرفتن ماژول‌ها و iRuleهاست. همچنین بسیاری از تیم‌ها رشد آینده را دست‌کم می‌گیرند و F5 خیلی زود به سقف ظرفیت می‌رسد.

نقش وینو سرور در سایزینگ دقیق F5 BIG-IP

سایزینگ صحیح F5 BIG-IP نیازمند ترکیب دانش فنی، تجربه عملی و شناخت رفتار اپلیکیشن‌هاست. وینو سرور با تجربه اجرای پروژه‌های متعدد F5 در مقیاس Enterprise، توانایی تحلیل Session، TPS و الگوی مصرف واقعی سازمان‌ها را دارد و بر اساس آن، پیشنهاد سایزینگ دقیق و قابل اتکا ارائه می‌دهد.

این رویکرد باعث می‌شود F5 نه بیش‌ازحد بزرگ و پرهزینه انتخاب شود و نه کوچک و پرریسک. برای سازمان‌هایی که پایداری، رشد آینده و جلوگیری از Bottleneckهای پنهان برایشان اهمیت دارد، وینو سرور می‌تواند به‌عنوان یک مرجع تخصصی و شریک فنی قابل اعتماد در سایزینگ F5 BIG-IP نقش کلیدی ایفا کند.