امنیت ذخیره‌سازی S3 با F5 BIG-IP؛ عملکرد، پایداری و PQC | XNET

در یک دیتاسنتر مجهز به سرورهای GPU، کند شدن دسترسی به داده همیشه با خطای واضحی همراه نیست. ممکن است همه سرورها روشن باشند، شبکه قطعی نداشته باشد و کلاستر ذخیره‌سازی نیز وضعیت سالمی گزارش کند، اما زمان اجرای یک پردازش هوش مصنوعی به‌تدریج افزایش پیدا کند. بررسی دقیق‌تر گاهی نشان می‌دهد که مشکل از توان محاسباتی نیست؛ درخواست‌های خواندن داده در مسیر Object Storage معطل می‌مانند و پردازشگرها بخشی از زمان خود را منتظر دریافت اطلاعات سپری می‌کنند.

امنیت ذخیره‌سازی S3 با F5 BIG-IP؛ وقتی پایداری داده از سرعت مهم‌تر می‌شود

این مسئله محور گزارش تازه F5 است که ۹ اکتبر ۲۰۲۶ و پس از کنفرانس SNIA SDC منتشر شد. شرکت F5 در این گزارش، معماری ذخیره‌سازی S3 را از زاویه‌ای بررسی کرده که در بسیاری از پروژه‌های توسعه دیتاسنتر کمتر به آن توجه می‌شودآیا مسیر دسترسی به داده هنگام خرابی، افزایش بار یا حمله امنیتی همچنان قابل اعتماد باقی می‌ماند؟

پاسخ پیشنهادی F5، قرار دادنBIG-IPدر نقطه ورودی ترافیک S3 است؛ راهکاری که در صورت طراحی صحیح می‌تواند مدیریت اتصال‌ها، توزیع بار و بخشی از کنترل‌های امنیتی را در یک لایه متمرکز کند. برای سازمان‌هایی که از محصولات F5 استفاده می‌کنند یا قصد توسعه زیرساخت هوش مصنوعی دارند، نکته مهم این است که چنین معماری در چه شرایطی ارزش پیاده‌سازی دارد.

مشکل اصلی ذخیره‌سازی S3 در زیرساخت‌های هوش مصنوعی

در معماری S3، برنامه‌ها از طریق درخواست‌های API به Objectهای ذخیره‌شده دسترسی پیدا می‌کنند. این روش برای نگهداری حجم بالای داده و توسعه ظرفیت ذخیره‌سازی مناسب است، اما رفتار آن در بارهای کاری مختلف یکسان نیست.

برای مثال، یک سامانه پشتیبان‌گیری ممکن است هر شب چند فایل حجیم را روی Object Storage بنویسد. در مقابل، سامانه Retrieval-Augmented Generation یا RAG می‌تواند در طول روز هزاران درخواست خواندن برای اسناد، داده‌های پردازش‌شده و فایل‌های مرتبط ارسال کند.

هر دو از S3 استفاده می‌کنند، ولی انتظار متفاوتی از زیرساخت دارند. در پشتیبان‌گیری، تکمیل موفق انتقال و توان عملیاتی پایدار اهمیت بیشتری دارد. در RAG، تأخیر دریافت اطلاعات می‌تواند مستقیماً بر زمان پاسخ‌گویی سرویس اثر بگذارد.

وقتی چندین برنامه و سرور پردازشی از یک مخزن مشترک استفاده می‌کنند، تشخیص علت کندی دشوارتر می‌شود. ممکن است ظرفیت دیسک کافی باشد، اما توزیع درخواست‌ها میان نودها مناسب نباشد. در بعضی شرایط نیز افزایش زمان پاسخ ناشی از بازسازی داده پس از خرابی یک نود است.

به همین دلیل، افزودن دیسک یا سرور ذخیره‌سازی همیشه نخستین راه‌حل نیست. پیش از افزایش ظرفیت باید مشخص شود درخواست‌ها چگونه به کلاستر می‌رسند و سیستم هنگام کاهش توان یکی از نودها چه رفتاری دارد.

• چرا یک Endpoint سالم ممکن است عملکرد ضعیفی داشته باشد؟

فرض کنید یک کلاستر Object Storage از چند نود تشکیل شده و برنامه‌ها از طریق یک آدرس ثابت به آن متصل هستند. یکی از نودها به دلیل عملیات بازیابی داده با کاهش کارایی مواجه می‌شود، اما همچنان به درخواست‌های شبکه پاسخ می‌دهد.

اگر توزیع‌کننده ترافیک فقط باز بودن پورت TCP را بررسی کند، احتمال دارد اتصال‌های جدید را به همان نود هدایت کند. از دید مانیتورینگ شبکه، سرویس در دسترس است؛ درحالی‌که بخشی از درخواست‌ها با تأخیر پاسخ داده می‌شوند.

در این وضعیت، Health Check باید با رفتار واقعی سرویس ذخیره‌سازی ارتباط داشته باشد. البته نحوه پیاده‌سازی آن به معماری محصول S3 بستگی دارد. بعضی سامانه‌ها Endpointهای مشخصی برای بررسی آمادگی سرویس ارائه می‌کنند و در برخی دیگر، باید وضعیت نود و کلاستر با روش متفاوتی ارزیابی شود.

این جزئیات هنگام طراحی Load Balancing اهمیت دارند؛ زیرا تصمیم اشتباه در هدایت ترافیک می‌تواند اثر یک خرابی محدود را به تعداد بیشتری از کاربران منتقل کند.

F5 BIG-IP در مسیر S3 چه کاری انجام می‌دهد؟

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

برنامه‌ها به یک Virtual Server متصل می‌شوند و BIG-IP ارتباط با Backend را مدیریت می‌کند. این ساختار به مدیر زیرساخت اجازه می‌دهد مسیر ترافیک را مستقل از تغییرات داخلی کلاستر کنترل کند.

اگر یکی از اعضای Pool از دسترس خارج شود، اتصال‌های جدید می‌توانند به اعضای سالم هدایت شوند. همچنین امکان تعریف تنظیمات TCP متفاوت برای ارتباط سمت کلاینت و سمت استوریج وجود دارد.

اما انتخاب نود سالم فقط بخشی از مسئله است.

در ذخیره‌سازی S3، ممکن است یک درخواست چند ثانیه طول بکشد یا انتقال یک Object بزرگ برای مدت طولانی ادامه داشته باشد. قطع شدن ارتباط در میانه انتقال الزاماً با تغییر مقصد اتصال برطرف نمی‌شود. کلاینت باید بتواند عملیات را تکرار کند یا مطابق قابلیت‌های سامانه ذخیره‌سازی، انتقال نیمه‌تمام را ادامه دهد.

برای همین، آزمون واقعی Failover نباید به خاموش کردن یک نود و مشاهده سبز شدن وضعیت Pool محدود شود. بهتر است هنگام انتقال فایل‌های حجیم و اجرای درخواست‌های هم‌زمان، خرابی شبیه‌سازی شود و رفتار کلاینت‌ها نیز بررسی شود.

• سازگاری S3 به معنای رفتار یکسان محصولات نیست

یکی از نکات قابل توجه گزارش F5، تفاوت میان سامانه‌های S3-Compatible است.

دو محصول ممکن است هر دو از APIهای رایج S3 پشتیبانی کنند، اما در مدیریت خطا، رفتار Endpoint، محدودیت‌های درخواست یا امکانات مدیریتی تفاوت داشته باشند.

این مسئله هنگام مهاجرت از یک پلتفرم ذخیره‌سازی به پلتفرم دیگر بیشتر دیده می‌شود. برنامه‌ای که با یک Backend بدون مشکل کار می‌کرده، ممکن است در سامانه جدید به تغییر تنظیمات نیاز داشته باشد.

استفاده از یک نقطه ورودی ثابت در BIG-IP می‌تواند بخشی از تغییرات شبکه و مسیریابی را از برنامه‌ها جدا کند. بااین‌حال، ناسازگاری در رفتار API یا تفاوت مجوزهای دسترسی را نمی‌توان صرفاً با Load Balancing حل کرد.

پیش از اجرای چنین معماری، لازم است عملیات مورد استفاده برنامه‌ها، از جمله GET، PUT، Multipart Upload و روش‌های احراز هویت، با Backend مقصد آزمایش شوند.

نتایج آزمایش F5 BIG-IP در کنار Dell ObjectScale

مهم‌ترین بخش فنی گزارش اکتبر F5 به آزمایش عملکرد BIG-IP در مسیر ذخیره‌سازی S3 مربوط است.

قرار گرفتن یک Full Proxy در مسیر انتقال داده، معمولاً این نگرانی را ایجاد می‌کند که پردازش اضافه باعث افت Throughput شود. در بارهای کاری هوش مصنوعی، حتی افت محدود عملکرد نیز ممکن است روی زمان اجرای Jobهای طولانی اثر بگذارد.

F5 اعلام کرده است که با استفاده از پروفایل‌های TCP بهینه‌شده برای S3، عملکرد BIG-IP در آزمایش با Dell ObjectScale توسط SecureIQLab ارزیابی شده است.

طبق نتایج گزارش‌شده، اختلاف Throughput نسبت به مسیر پایه بدون BIG-IP، در ترکیب‌های آزمایش‌شده از اندازه Object و تأخیر شبکه، در محدوده درصدهای پایین تک‌رقمی باقی مانده است.

اهمیت این نتیجه در آن است که سازمان می‌تواند لایه‌ای برای مدیریت ترافیک و کنترل امنیتی اضافه کند، بدون اینکه الزاماً با افت شدید توان انتقال مواجه شود.

البته این نتیجه به معنی افزایش قطعی سرعت یا عملکرد یکسان در تمام دیتاسنترها نیست. مدل BIG-IP، تعداد نشست‌ها، اندازه Objectها، نوع اتصال شبکه و قابلیت‌های امنیتی فعال می‌توانند نتیجه را تغییر دهند.

• پروفایل TCP مناسب برای S3 چگونه انتخاب می‌شود؟

رفتار TCP هنگام انتقال فایل بزرگ با شرایطی که تعداد زیادی درخواست کوچک وجود دارد متفاوت است.

در انتقال‌های حجیم، اندازه پنجره TCP، تأخیر رفت‌وبرگشت شبکه و مدیریت Buffer می‌توانند بر سرعت مؤثر اثر بگذارند. در بارهای کاری شامل درخواست‌های کوچک، سربار ایجاد اتصال و تعداد نشست‌های هم‌زمان اهمیت بیشتری پیدا می‌کند.

BIG-IP به دلیل معماری Full Proxy می‌تواند برای سمت کلاینت و Backend تنظیمات مستقلی داشته باشد. این قابلیت به‌ویژه زمانی مفید است که سرورهای پردازشی و ذخیره‌سازی در بخش‌های متفاوت شبکه قرار دارند.

برای مثال، ارتباط یک کلاستر GPU در همان دیتاسنتر با Object Storage محلی ممکن است به تنظیماتی متفاوت از ارتباط میان دو سایت نیاز داشته باشد.

در عمل، انتخاب پروفایل مناسب باید با اندازه‌گیری انجام شود. اگر پس از اعمال تنظیمات، Throughput بهتر شود اما نرخ خطا یا زمان پاسخ درخواست‌های کوچک افزایش پیدا کند، نمی‌توان تغییر را موفق دانست.

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

امنیت داده‌های S3 با رمزنگاری مقاوم در برابر تهدیدات کوانتومی

بخش دیگری از گزارش F5 به موضوعی مربوط است که هنوز در بسیاری از پروژه‌های ذخیره‌سازی سازمانی جدی گرفته نشده: حفاظت از داده‌های در حال انتقال در برابر تهدیدات آینده رایانش کوانتومی.

در حمله‌ای موسوم به Harvest Now, Decrypt Later، مهاجم ترافیک رمزنگاری‌شده را امروز جمع‌آوری و ذخیره می‌کند، با این امید که در آینده بتواند با استفاده از توان محاسباتی یا روش‌های رمزگشایی جدید به محتوای آن دسترسی پیدا کند.

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

F5 در گزارش خود توضیح داده است که BIG-IP با قابلیت‌های Post-Quantum Cryptography یا PQC می‌تواند بخشی از حفاظت ارتباطی را در نقطه ورودی Object Storage فراهم کند، بدون اینکه لازم باشد تمام سازندگان سامانه‌های ذخیره‌سازی فوراً قابلیت مشابهی را در محصولات خود پیاده‌سازی کنند.

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

• محدودیت حفاظت کوانتومی در مسیر BIG-IP

در طراحی این راهکار باید محدوده حفاظت به‌روشنی مشخص باشد.

اگر ارتباط کلاینت تا BIG-IP از الگوریتم‌های مقاوم در برابر تهدیدات کوانتومی استفاده کند، این موضوع به‌تنهایی تضمین نمی‌کند که ارتباط BIG-IP تا Backend نیز همان سطح حفاظت را داشته باشد.

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

همچنین PQC در مسیر انتقال، جایگزین رمزنگاری داده در حالت ذخیره‌شده، مدیریت کلید یا سیاست‌های کنترل دسترسی نیست.

برای مثال، اگر یک حساب سرویس بیش از حد لازم مجوز خواندن Bucket داشته باشد، تغییر الگوریتم رمزنگاری ارتباطی این ضعف را اصلاح نمی‌کند.

بنابراین، پیاده‌سازی PQC باید در کنار مدیریت هویت، کنترل دسترسی و حفاظت از داده‌های ذخیره‌شده ارزیابی شود.

مقابله با ترافیک مخرب بدون قطع دسترسی به Object Storage

در آزمایش‌های گزارش‌شده توسط F5، علاوه بر اندازه‌گیری عملکرد، رفتار BIG-IP در برابر ترافیک مخرب و حمله شبیه‌سازی‌شده DDoS نیز بررسی شده است.

طبق گزارش شرکت، سرویس S3 در شرایط آزمایش به ارائه خدمات ادامه داده است.

این نتیجه از یک جهت اهمیت دارد: زیرساخت ذخیره‌سازی ممکن است از نظر ظرفیت و سلامت دیسک‌ها مشکلی نداشته باشد، اما به دلیل فشار درخواست‌های غیرعادی از دسترس برنامه‌های مجاز خارج شود.

در چنین شرایطی، کنترل ترافیک در نقطه ورودی می‌تواند مانع رسیدن بخشی از درخواست‌های مخرب به Backend شود.

بااین‌حال، باید میان قابلیت‌های BIG-IP LTM و ماژول‌های امنیتی مانند AFM یا WAF تفاوت قائل شد. همه کنترل‌های امنیتی صرفاً با نصب LTM در اختیار سازمان قرار نمی‌گیرند و نوع لایسنس و نسخه نرم‌افزار در طراحی راهکار مؤثر است.

از سوی دیگر، حمله‌ای که پهنای باند اینترنت یا ارتباط بالادستی را کاملاً اشباع کند، ممکن است به راهکار دفاعی خارج از دیتاسنتر نیز نیاز داشته باشد.

برای ارزیابی مقاومت سرویس، بهتر است آزمون‌ها تنها روی نرخ بالای درخواست متمرکز نباشند. درخواست‌های طولانی، تعداد زیاد اتصال هم‌زمان، الگوهای غیرعادی GET و PUT و رفتار کلاینت‌های مجاز در زمان حمله نیز باید بررسی شوند.

چالش جدید: دسترسی مستقیم Agentهای هوش مصنوعی به داده‌ها

یکی از تغییرات مهم در معماری برنامه‌های سازمانی، افزایش سرویس‌هایی است که بدون دخالت مستقیم کاربر به منابع داده متصل می‌شوند.

یک Agent هوش مصنوعی ممکن است برای انجام وظیفه خود به اسناد داخلی مراجعه کند، فایل جدیدی تولید کند یا اطلاعات را از چند مخزن مختلف جمع‌آوری کند.

در چنین محیطی، صرفاً محدود کردن دسترسی کاربران انسانی کافی نیست. حساب‌های سرویس، کلیدهای API و مجوزهای برنامه‌ها نیز باید مدیریت شوند.

اگر Agent به یک Bucket دسترسی خواندن دارد، باید مشخص باشد آیا واقعاً به تمام Objectهای آن نیاز دارد یا تنها به مجموعه مشخصی از داده‌ها.

BIG-IP می‌تواند بخشی از کنترل‌های ارتباطی و امنیتی را در مسیر این درخواست‌ها اعمال کند، اما تعیین مجوز دسترسی به Objectها همچنان باید در سامانه هویت و پلتفرم ذخیره‌سازی انجام شود.

برای مثال، اگر یک Agent به‌طور غیرمنتظره شروع به دریافت حجم بالایی از اسناد کند، اطلاعات ترافیکی BIG-IP می‌تواند به شناسایی رفتار غیرعادی کمک کند. برای مشخص شدن اینکه دقیقاً کدام Objectها خوانده شده‌اند، لازم است لاگ‌های خود Object Storage نیز بررسی شوند.

این تفکیک در بررسی حوادث امنیتی مهم است؛ زیرا دید شبکه و دید سامانه ذخیره‌سازی مکمل یکدیگر هستند.

چه زمانی استفاده از F5 BIG-IP در کنار S3 توجیه دارد؟

برای هر محیط S3 لزوماً به یک ADC مستقل نیاز نیست.

اگر سازمان یک کلاستر کوچک با تعداد محدود مصرف‌کننده دارد و محصول ذخیره‌سازی، توزیع بار و دسترس‌پذیری موردنیاز را فراهم می‌کند، اضافه کردن BIG-IP ممکن است ارزش عملیاتی کافی نداشته باشد.

در مقابل، شرایط در دیتاسنتری که چند کلاستر ذخیره‌سازی، سرورهای GPU، سرویس‌های RAG و برنامه‌های سازمانی مختلف دارد متفاوت است.

در چنین محیطی، مدیریت متمرکز Endpointها، تنظیم ارتباطات TCP، اعمال کنترل‌های امنیتی و جداسازی تغییرات شبکه از برنامه‌ها می‌تواند ارزشمند باشد.

برای تصمیم‌گیری، بهتر است سه سؤال پاسخ داده شود.

اول، مشکل فعلی زیرساخت چیست؟اگر مسئله اصلی کندی دیسک یا پردازش Metadata باشد، قرار دادن BIG-IP در مسیر آن را برطرف نمی‌کند. اما اگر اختلال به توزیع اتصال‌ها، خرابی نود یا کنترل ترافیک مربوط باشد، بررسی این معماری منطقی است.

دوم، چه سطحی از امنیت لازم است؟سازمانی که داده‌های بلندمدت و حساس نگهداری می‌کند، ممکن است به بررسی PQC و کنترل‌های پیشرفته دسترسی نیاز داشته باشد. در این حالت، باید قابلیت‌های واقعی نسخه BIG-IP و الزامات رمزنگاری دو سمت ارتباط مشخص شوند.

سوم، هزینه عملیاتی این لایه چقدر است؟تجهیز جدید به مانیتورینگ، به‌روزرسانی، مدیریت گواهی، طراحی HA و پشتیبانی نیاز دارد. این هزینه‌ها باید در کنار ارزش حاصل از پایداری و امنیت بیشتر ارزیابی شوند.

پاسخ به این پرسش‌ها معمولاً از مقایسه صرف مشخصات سخت‌افزاری تجهیزات نتیجه دقیق‌تری می‌دهد.

انتخاب و پیاده‌سازی F5 BIG-IP در XNET

پیاده‌سازی BIG-IP در مسیر Object Storage زمانی موفق خواهد بود که انتخاب محصول با شناخت ترافیک و معماری فعلی دیتاسنتر انجام شود.

در مرحله طراحی، باید تعداد مصرف‌کنندگان S3، حجم انتقال داده، نوع Backend، الگوی درخواست‌ها و نیازهای امنیتی مشخص شوند. همچنین لازم است بررسی شود کدام قابلیت‌ها به LTM مربوط هستند و برای اجرای کنترل‌های دیگر چه ماژول‌ها یا لایسنس‌هایی نیاز است.

XNET در زمینه تأمین محصولات F5 و تجهیزات زیرساختی سازمانی فعالیت می‌کند و خدمات مشاوره فنی، نصب، راه‌اندازی، آموزش و پشتیبانی ارائه می‌دهد.

سازمان‌هایی که قصد استفاده از F5 BIG-IP در کنار زیرساخت ذخیره‌سازی S3 یا توسعه سرویس‌های هوش مصنوعی را دارند، می‌توانند برای بررسی ظرفیت موردنیاز، انتخاب پلتفرم و طراحی اولیه راهکار از مشاوره کارشناسان XNET استفاده کنند.

در چنین پروژه‌هایی، انتخاب صحیح تجهیز باید بر اساس نیاز عملیاتی و نتایج ارزیابی فنی انجام شود، نه صرفاً بالاترین ظرفیت اعلام‌شده در مشخصات محصول.

جمع‌بندی

گزارش ۹ اکتبر ۲۰۲۶ شرکت F5 یک نکته مهم را برای معماران دیتاسنتر مطرح می‌کند: در زیرساخت‌های هوش مصنوعی، دسترسی پایدار و امن به داده باید هم‌زمان با توان پردازشی توسعه پیدا کند.

نتایج آزمایش BIG-IP در کنار Dell ObjectScale نشان می‌دهد که با تنظیم مناسب TCP می‌توان یک لایه مدیریت و حفاظت از ترافیک S3 ایجاد کرد و افت Throughput را در شرایط آزمایش محدود نگه داشت. قابلیت‌های PQC نیز امکان بررسی حفاظت پیشرفته‌تر از داده‌های در حال انتقال را فراهم می‌کنند.

بااین‌حال، ارزش واقعی BIG-IP به شرایط زیرساخت وابسته است. اگر مشکل سازمان در مسیر دسترسی، کنترل ترافیک یا دسترس‌پذیری Endpoint باشد، این راهکار می‌تواند بخشی از پاسخ فنی باشد. اگر گلوگاه در خود سامانه ذخیره‌سازی قرار داشته باشد، ابتدا باید همان بخش اصلاح شود.

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

برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.