با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Capacity مقدار فضاست
Capacity فقط میگوید چه مقدار داده قابل ذخیره است و درباره سرعت چیزی نمیگوید؛ برای Performance باید IOPS، Throughput و Latency را هم ببینی برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
IOPS تعداد عملیات در ثانیه است
IOPS تعداد عملیات ورودی/خروجی در ثانیه است و برای Workloadهای کوچک و تصادفی مهم میشود؛ IOPS را همراه Latency و نوع IO بخوان عدد بالاتر همیشه به معنی تجربه بهتر نیست اگر Latency زیاد باشد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد
Latency زمان پاسخ I/O است
Latency زمان پاسخ یک عملیات است و در Storage یا شبکه مستقیماً روی حس کندی اثر میگذارد؛ میانگین، اوج و زمان رخداد را مقایسه کن Bandwidth بالا مشکل Latency را لزوماً حل نمیکند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
Throughput حجم انتقال است
Throughput مقدار داده منتقلشده در واحد زمان است و برای Workloadهای ترتیبی بزرگ مهم است؛ Workload کوچک و تصادفی ممکن است بیشتر به IOPS و Latency حساس باشد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
Workload تعیین میکند کدام معیار مهمتر باشد
یک Database با I/O تصادفی و یک Backup ترتیبی الگوی یکسان ندارند؛ قبل از قضاوت درباره Storage نوع Read/Write، اندازه Block و زمان اوج را بشناس نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که ذخیرهسازی و Backup را باید بر اساس نیاز بازیابی طراحی کرد نه صرفاً ظرفیت؛ نوع Workload، الگوی I/O، تحمل خرابی، RPO و RTO تعیین میکنند چه معماریای مناسب است؛ RAID یا Replication میتواند Availability را بهتر کند اما در برابر حذف اشتباه، فساد منطقی یا بعضی حملات جای Backup مستقل را نمیگیرد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، Backup موفق تنها یک Job با وضعیت سبز نیست؛ Restore Test باید نشان دهد فایل، Database یا System State در زمان قابل قبول و با داده سالم بازمیگردد؛ نگهداری نسخه جدا یا محافظتشده و کنترل دسترسی Backup اهمیت دارد چون مهاجم یا خطای مدیریتی ممکن است نسخههای متصل را نیز تحت تأثیر قرار دهد برای کامل شدن تصویر این موضوع، در این درس موضوع را از دید قابلیت بازیابی بررسی میکنیم؛ داشتن Storage یا اجرای موفق Backup بهتنهایی کافی نیست و باید بدانی در خرابی واقعی چه دادهای، تا چه نقطه زمانی و در چه مدت باید برگردد؛ RPO، RTO، سازگاری Application، محل نگهداری نسخه و آزمون Restore معیارهایی هستند که طراحی و عیبیابی را هدایت میکنند
فرض کن در سامانه Backup و Storage مشکلی گزارش شده و احتمال میدهی به Storage؛ Capacity، IOPS و Latency مربوط باشد. قبل از تغییر، وضعیت فعلی را با Backup Console، Job History و Restore Test بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با Storage؛ Capacity، IOPS و Latency قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره Storage؛ Capacity، IOPS و Latency فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با Storage؛ Capacity، IOPS و Latency، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با Backup Console، Job History و Restore Test وضعیت مرتبط با Storage؛ Capacity، IOPS و Latency را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با Storage؛ Capacity، IOPS و Latency بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Capacity مقدار فضاست
- IOPS تعداد عملیات در ثانیه است
- Latency زمان پاسخ I/O است
- Throughput حجم انتقال است
- Workload تعیین میکند کدام معیار مهمتر باشد
- موفق بودن Job بهتنهایی کافی نیست؛ Restore را هم آزمایش کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: Capacity مقدار فضاست. بعد بگو در عمل چطور آن را بررسی میکنی.
Capacity فقط میگوید چه مقدار داده قابل ذخیره است و درباره سرعت چیزی نمیگوید؛ برای Performance باید IOPS، Throughput و Latency را هم ببینی
این نکته را با یک مثال توضیح بده: IOPS تعداد عملیات در ثانیه است. بعد بگو در عمل چطور آن را بررسی میکنی.
IOPS تعداد عملیات ورودی/خروجی در ثانیه است و برای Workloadهای کوچک و تصادفی مهم میشود؛ IOPS را همراه Latency و نوع IO بخوان
این نکته را با یک مثال توضیح بده: Latency زمان پاسخ I/O است. بعد بگو در عمل چطور آن را بررسی میکنی.
Latency زمان پاسخ یک عملیات است و در Storage یا شبکه مستقیماً روی حس کندی اثر میگذارد؛ میانگین، اوج و زمان رخداد را مقایسه کن
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
