تصویر کلی
Erasure Coding شیء را به Shardهای داده و افزونگی تقسیم و روی Driveها توزیع می‌کند تا خرابی بخشی از رسانه قابل تحمل باشد.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
Parity بیشتر ظرفیت را مصرف می‌کند و سطح تحمل خرابی را تغییر می‌دهد؛ طراحی Set و تعداد Driveها روی نتیجه اثر دارد.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
Bit rot protection و Healing برای خرابی داده/رسانه مفیدند اما حذف اشتباه، Credential compromise یا Ransomware به سیاست Versioning و Backup جدا نیاز دارند.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی MinIO نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
افزونگی داده چه مسئله‌ای را حل می‌کند؟
وقتی شیء روی چند قطعه داده و افزونگی توزیع می‌شود، از دست رفتن بخشی از رسانه‌ها می‌تواند بدون از دست رفتن محتوای شیء قابل تحمل باشد. این ویژگی با داشتن نسخه قدیمی همان شیء فرق دارد. اگر یک کاربر مجاز محتوای اشتباه را جایگزین کند، سامانه می‌تواند همان محتوای اشتباه را با افزونگی کامل نگه دارد. بنابراین تحمل خرابی دیسک، حفاظت از اشتباه انسانی و بازیابی پس از تخریب گسترده سه نیاز جدا هستند. طراحی خوب برای هرکدام پاسخ مشخص دارد و نام یک قابلیت را به جای همه آن‌ها استفاده نمی‌کند.
برای مثال، مخزنی از تصویرهای محصول را در نظر بگیرید. خرابی یک دیسک باید با سازوکار افزونگی پوشش داده شود. حذف تصادفی پوشه منطقی یا جایگزینی اشتباه تصویرها به تاریخچه نسخه یا نسخه پشتیبان نیاز دارد. از دست رفتن کل محل استقرار به نسخه‌ای در دامنه خرابی مستقل نیاز خواهد داشت. اگر همه دیسک‌ها و نسخه‌های منطقی در یک اتاق و زیر اختیار یک حساب مدیریتی باشند، بعضی تهدیدها همچنان مشترک‌اند. فهرست سناریوهای خرابی را قبل از انتخاب تعداد دیسک بنویسید.
مجموعه کدگذاری و دامنه خرابی
تعداد کل دیسک‌های خوشه به تنهایی تعداد خرابی قابل تحمل برای هر شیء را بیان نمی‌کند. شیء در یک مجموعه مشخص کدگذاری قرار می‌گیرد و ترکیب قطعه‌های داده و افزونگی همان مجموعه اهمیت دارد. همچنین محل فیزیکی دیسک‌ها تعیین می‌کند خرابی یک گره یا کنترل‌گر چند قطعه را همزمان از دسترس خارج می‌کند. توزیع نامناسب می‌تواند با وجود تعداد زیاد دیسک، یک نقطه خرابی مشترک بسازد. نقشه گره، دیسک، رک و برق را کنار نقشه منطقی نگه دارید.
در محاسبه ظرفیت، فضای خام را با فضای قابل استفاده یکسان نگیرید. بخشی از ظرفیت صرف افزونگی می‌شود و برای عملیات و رشد نیز باید حاشیه وجود داشته باشد. نسبت دقیق به طرح کدگذاری و چیدمان بستگی دارد. از یک فرمول ساده بدون توجه به محدودیت مجموعه و ظرفیت دیسک‌ها برای سفارش سخت‌افزار استفاده نکنید. اگر اندازه رسانه‌ها متفاوت است، بررسی کنید سامانه چگونه از ظرفیت آن‌ها استفاده می‌کند. محاسبه باید با مستندات همان محصول و نسخه و یک آزمایش کوچک تأیید شود.
خواندن و نوشتن در حالت کاهش‌یافته
توان خواندن یک شیء با توان پذیرش نوشتن تازه الزاماً یکسان نیست. سامانه برای حفظ سازگاری به حد نصاب‌های مشخص نیاز دارد و شرایط آن به طرح داده و افزونگی وابسته است. بنابراین جمله «هنوز چند دیسک سالم داریم» برای نتیجه‌گیری کافی نیست. هنگام اختلال، وضعیت مجموعه مربوط و نوع عملیات شکست‌خورده را بررسی کنید. ممکن است یک درخواست خواندن موفق باشد ولی نوشتن به دلیل نرسیدن به حد نصاب رد شود. این رفتار می‌تواند حفاظت از سازگاری باشد، نه خرابی تصادفی رابط برنامه‌نویسی.
برای آزمایش، در محیط غیرتولیدی چند شیء با اندازه‌های متفاوت بنویسید و مقدار کنترل آن‌ها را ذخیره کنید. سپس یک رسانه آزمایشی را از دسترس خارج کنید و خواندن، نوشتن و فهرست‌گیری را جدا بسنجید. نتیجه را برای همان چیدمان ثبت کنید و آن را به همه معماری‌ها تعمیم ندهید. آزمایش خرابی همزمان چند دیسک باید فقط با داده قابل حذف و طبق طرح روشن انجام شود. هدف شناخت مرز رفتار است، نه تلاش برای اثبات یک عدد تبلیغاتی.
ترمیم چگونه با بار واقعی رقابت می‌کند؟
پس از جایگزینی رسانه یا بازگشت دسترسی، داده ناقص باید بازسازی شود. این کار به خواندن از قطعه‌های موجود، محاسبه و نوشتن نیاز دارد. منابعی که صرف ترمیم می‌شوند ممکن است با درخواست‌های کاربران رقابت کنند. در نتیجه زمان پاسخ در دوره ترمیم می‌تواند با حالت پایدار فرق کند. ظرفیت‌سنجی فقط در حالت همه دیسک‌ها سالم، تصویر کاملی از کیفیت خدمت نمی‌دهد. آزمایش باید دوره کاهش‌یافته و بازسازی را نیز شامل شود.
سرعت ترمیم به اندازه داده، تعداد شیءها، وضعیت شبکه و رسانه و بار همزمان وابسته است. اعلام زمان ثابت برای همه محیط‌ها قابل اعتماد نیست. روند پیشرفت، خطاهای تکرارشونده و فشار منابع را پایش کنید. اگر دیسک جایگزین کند یا مسیر شبکه معیوب باشد، افزایش فشار ترمیم ممکن است وضعیت را بدتر کند. ابتدا گلوگاه را پیدا کنید و سپس تنظیمات مناسب همان نسخه را تغییر دهید. پایان یافتن عملیات نیز باید با بازخوانی نمونه داده و سلامت مجموعه تأیید شود.
تشخیص خرابی خاموش و اهمیت مقدار کنترل
همه خرابی‌ها به صورت قطع کامل دیسک ظاهر نمی‌شوند. داده ممکن است خوانده شود ولی محتوای آن آسیب دیده باشد. سازوکارهای صحت‌سنجی و ترمیم در سامانه ذخیره‌سازی برای چنین مواردی اهمیت دارند، اما برنامه نیز باید بتواند نتیجه مورد انتظار را تأیید کند. برای مجموعه آزمایشی، مقدار کنترل مستقل نگه دارید و پس از خرابی و بازیابی مقایسه کنید. این آزمون از اتکا به صرف پاسخ موفق شبکه جلوگیری می‌کند.
در عین حال، مقدار کنترل به تنهایی اصالت محتوای مورد انتظار را تضمین نمی‌کند اگر همان حساب بتواند هم داده و هم مقدار مرجع را تغییر دهد. برای داده مهم، محل نگهداری مرجع و اختیار تغییر آن را نیز بررسی کنید. هدف این نیست که هر برنامه سامانه رمزنگاری پیچیده‌ای بسازد؛ هدف شناخت این است که هر شاهد چه چیزی را ثابت می‌کند. پاسخ موفق، طول درست فایل و مقدار کنترل معتبر هرکدام سطح متفاوتی از اطمینان می‌دهند.
نسخه‌بندی، تکثیر و پشتیبان مستقل
نسخه‌بندی می‌تواند برای بازگشت از تغییر یا حذف منطقی مفید باشد، ولی مصرف ظرفیت و سیاست نگهداری آن باید مدیریت شود. تکثیر به مقصد دیگر نیز با پشتیبان تاریخی یکسان نیست؛ بعضی تغییرهای نامطلوب ممکن است به مقصد منتقل شوند. رفتار حذف، نسخه‌ها و تأخیر تکثیر را در طرح خود مشخص کنید. اگر مقصد تحت همان اختیار مدیریتی باشد، خطای حساب یا نفوذ ممکن است هر دو طرف را تحت تأثیر قرار دهد. استقلال جغرافیایی بدون استقلال دسترسی همیشه کافی نیست.
یک تمرین بازیابی از نسخه قدیمی انجام دهید و آن را از تمرین تعویض دیسک جدا گزارش کنید. در تمرین نخست باید محتوای قبل از تغییر اشتباه برگردد؛ در تمرین دوم باید همان محتوای جاری با وجود خرابی رسانه قابل استفاده بماند. این دو آزمون معیار متفاوت دارند. همچنین کلیدهای رمزنگاری، تنظیمات هویت و سیاست‌های دسترسی را در بازیابی کامل در نظر بگیرید. داشتن همه بایت‌های شیء بدون کلید یا مجوز لازم ممکن است برای برنامه بی‌فایده باشد.
عملیات روزمره و هشدارهای معنادار
هشدار فقط درباره پر شدن کامل دیسک دیر است. کاهش ظرفیت آزاد، رسانه ناسالم، صف ترمیم، خطاهای شبکه و کاهش حاشیه تحمل خرابی باید قبل از توقف خدمت دیده شوند. پیام هشدار باید مجموعه و گره مربوط را مشخص کند تا اپراتور رسانه اشتباه را خارج نکند. پیش از تعویض، شناسه فیزیکی و منطقی را تطبیق دهید و وضعیت سایر رسانه‌های همان دامنه را بررسی کنید. خارج کردن دیسک سالم به جای خراب می‌تواند یک اختلال قابل تحمل را به بحران تبدیل کند.
در پایان هر عملیات، ثبت کنید چه چیزی تعویض شد، داده چگونه ترمیم شد و کدام آزمون صحت انجام گرفت. این گزارش برای تشخیص خرابی تکراری یک کنترل‌گر یا الگوی مشترک رسانه‌ها مفید است. مستند رسمی فعلی پیوند منبع ممکن است به مجموعه AIStor هدایت شود؛ قابلیت‌ها و فرمان‌ها را با محصول و نسخه نصب‌شده خود تطبیق دهید. اصل پایدار این است که افزونگی رسانه، تاریخچه داده و بازیابی مستقل را جدا طراحی و جدا آزمایش کنید تا هیچ‌کدام پشت نام دیگری پنهان نماند.
سنجش اثر اندازه شیء
بار شامل تعداد زیادی شیء کوچک با بار شامل چند فایل بزرگ یکسان نیست. هزینه فراداده، تعداد درخواست و الگوی دیسک می‌تواند گلوگاه متفاوتی بسازد. آزمایش را با توزیع اندازه نزدیک به برنامه واقعی انجام دهید و فقط مجموع گیگابایت منتقل‌شده را گزارش نکنید. تعداد عملیات، زمان پاسخ انتهایی و میزان همزمانی نیز لازم‌اند. هنگام ترمیم، همین تفاوت اندازه می‌تواند بر زمان پایان و فشار منابع اثر بگذارد. ثبت ترکیب داده آزمایش باعث می‌شود نتیجه بعداً قابل تکرار باشد و تیم خرید یا عملیات آن را خارج از شرایط معتبرش استفاده نکند. ظرفیت مناسب باید هم فضای کافی و هم توان پاسخ به الگوی واقعی درخواست را فراهم کند.
