فضای ذخیره‌سازی داریم؛ پس چرا سامانه‌ها کند شده‌اند؟

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

در این راهنما، موضوع از چند زاویه بررسی می‌شود: ظرفیت، IOPS، Throughput و Latency چه تفاوتی دارند؟، شکایت «کند است» را به مسئله قابل اندازه‌گیری تبدیل کنیم، میانگین‌ها قله‌های کوتاه را پنهان می‌کنند. هدف این است که مخاطب پس از مطالعه، معیارهای تصمیم‌گیری و اقدام بعدی را روشن‌تر ببیند.

ظرفیت، IOPS، Throughput و Latency چه تفاوتی دارند؟

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

برای مدیران، مثال ساده مفیدتر از تعریف فنی است. سامانه مالی ممکن است هزاران خواندن و نوشتن کوچک داشته باشد و به تأخیر حساس باشد. آرشیو ویدئو شاید فایل‌های بزرگ‌تر را با تعداد عملیات کمتر منتقل کند و به پهنای باند بیشتری نیاز داشته باشد. یک Storage واحد اگر برای یکی مناسب باشد، الزاماً برای دیگری بهترین انتخاب نیست. مستندات Microsoft نیز نشان می‌دهد محدودیت عملکرد می‌تواند در دیسک، ماشین یا مسیر میان آن‌ها ایجاد شود و فقط مشخصات یک جزء تصویر کامل را نمی‌دهد.[۱]

شکایت «کند است» را به مسئله قابل اندازه‌گیری تبدیل کنیم

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

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

میانگین‌ها قله‌های کوتاه را پنهان می‌کنند

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

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

گلوگاه ممکن است بیرون از Storage باشد

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

در جلسه بررسی باید مسیر درخواست از کاربر تا داده رسم شود: برنامه، پایگاه داده، ماشین یا میزبان، شبکه و Storage. برای هر بخش یک یا دو شاهد کلیدی کافی است. هدف تولید انبوه نمودار نیست؛ باید بدانیم درخواست کجا منتظر مانده است. گاهی یک تنظیم، توزیع نامناسب بار یا Job زمان‌بندی‌شده اصلاح می‌شود و خرید بزرگ به مرحله بعد موکول می‌گردد.

داده داغ و سرد را یکسان نبینیم

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

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

رشد ظرفیت با رشد کارایی یکی نیست

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

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

نسبت کاهش داده را با ظرفیت قابل استفاده اشتباه نگیریم

قابلیت‌هایی مانند Deduplication و Compression می‌توانند مصرف فیزیکی را کاهش دهند، اما میزان واقعی کاهش به نوع داده وابسته است. عدد بروشور یا تجربه یک سازمان دیگر نباید مستقیماً وارد بودجه شود. فایل‌های فشرده، داده رمزگذاری‌شده و پایگاه‌های داده ممکن است رفتار متفاوتی داشته باشند. ظرفیت خام، ظرفیت قابل استفاده و ظرفیت مؤثر سه عدد یکسان نیستند.

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

کندی پس از تغییر را با خط مبنا بررسی کنیم

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

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

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

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

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

آزمون مصنوعی را با بار واقعی تکمیل کنیم

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

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

هزینه کندی را به زبان کسب‌وکار بنویسیم

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

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

سه نوع اقدام را از هم جدا کنیم

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

این تفکیک با محدودیت بودجه همدلانه‌تر است. سازمان مجبور نیست همه مشکلات را با یک خرید بزرگ حل کند. هر اقدام باید اثر موردانتظار، هزینه، ریسک، مسئول و روش تأیید داشته باشد. اگر اقدام کم‌هزینه نتیجه کافی ایجاد کند، منابع برای اولویت‌های دیگر حفظ می‌شود؛ اگر کافی نباشد، شواهد لازم برای سرمایه‌گذاری بعدی فراهم است.

ارزیابی Storage در راگا از کجا شروع می‌شود؟

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

خروجی باید برای مدیریت قابل استفاده باشد: مشکل مشاهده‌شده، شاهد، اثر کسب‌وکاری، گزینه اصلاح و اولویت. ممکن است نتیجه به تنظیم و بازتوزیع ختم شود یا نیاز به ارتقای Storage، شبکه، میزبان یا طراحی جدید را نشان دهد. ارزش ارزیابی در جلوگیری از خرید حدسی و اتصال بودجه به نتیجه قابل سنجش است.

تصمیم جلسه بعدی

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

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

مسئله کارایی را پس از اصلاح دوباره بسنجیم

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

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

گزارش نهایی باید تصمیم خرید را پاسخ دهد

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

چک‌لیست تصمیم‌گیری

• ظرفیت و کارایی به‌صورت جداگانه اندازه‌گیری شوند.
• نوع بار کاری و الگوی رشد داده مشخص باشد.
• دوره نگهداری و فضای رزرو در محاسبه بیایند.
• آزمون تحویل و بازیابی با داده نماینده انجام شود.

سؤالات متداول

فضای آزاد برای ارزیابی Storage کافی است؟

خیر. تأخیر، IOPS، Throughput، نوع بار کاری، رشد و فضای رزرو نیز باید بررسی شوند.

ظرفیت آینده Storage چگونه محاسبه می‌شود؟

نرخ رشد، دوره نگهداری، کاهش داده، فضای رزرو و زمان تأمین باید در مدل ظرفیت لحاظ شوند.

تحویل Storage چگونه تأیید می‌شود؟

آزمون ظرفیت، کارایی، دسترس‌پذیری و بازیابی باید با معیار پذیرش از پیش توافق‌شده انجام شود.

منابع

[۱] Microsoft Learn — راهنمای عملکرد ماشین مجازی و دیسک و تفکیک محدودیت‌های IOPS و Throughput مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، خدمات تأمین تجهیزات IT راگا و مقاله «Immutable Backup در برابر باج‌افزار چه نقشی دارد؟» را ببینید.