Чи є причина змінити жорсткий диск сервера, перш ніж він вийде з ладу?

Лише швидке запитання: чи є причина змінити жорсткий диск сервера через x років до того, як він вийде з ладу (зрештою, це станеться в якийсь момент) чи я повинен просто залишити його, поки не вийде з ладу? У мене мало досвіду з фактичним адмініструванням сервера, тому мені цікаво ...

Відмінний привід змінити це, якщо ви хочете додати до списку речей ще одне завдання, збільшуючи шанси на те, що щось піде не так.

Усі жартують убік, насправді немає жодної причини, яку я чув, щоб достроково змінити привід. Якщо у вас є RAID, у вас вже є захист (якщо припустити, що у вас є пристойні резервні копії), і ви не створюєте відходи у вигляді мертвого диска для утилізації, і вам не доведеться зайво працювати над усуненням чутливі дані з накопичувача. Ви не будете витрачати зайві гроші на нові накопичувачі, і все одно не будете активно захищати від речей, які все одно можуть піти не так, як несправний контролер накопичувача, який не є звичайним джерелом несправностей накопичувача, але може статися.

З іншого боку, це може допомогти вам виявити непоправні помилки накопичувача, які не викликають тривоги на RAID-блоці, як це траплялося з RAID 5. Нас укусив це, і в кінцевому підсумку потрібно було відновити з чистого металу з резервного копіювання (так, навіть у такому випадку належна резервна копія допоможе вам відновити.) Рівень RAID, який враховує більші потужності накопичувача та неприпустимі допуски помилок, допомогли б нам, як ні, резервне копіювання врятує день.

Більшість адміністраторів мають гідний план RAID та резервного копіювання, тому немає необхідності створювати зайві відходи, замінюючи накопичувачі без потреби.

Єдиний раз, коли я міг би вважати це, якби у мене була маса дисків із тієї ж партії, а інші в партії почали виходити з ладу, то я можу це врахувати.

Якби я був простором у просторі, то, звичайно, я би це зробив - але не з іншої причини, як тільки тому, що старіє? Ні, тому що в середньому рівень відмов у перший рік схожий на рівень відмов у будь-який інший рік . (зауважте, що графік розбивається на перший рік за 3 місяці, 6 місяців, 1 рік, але вам доведеться додати їх усі разом, щоб отримати шанс невдачі через 1 рік). А якщо дивитися на високу використання диска, то швидше вийде з ладу в перший рік, ніж у наступні три роки разом.

Єдине співвідношення із затримкою пізнього накопичувача було у гарячих приміщеннях, і ми зберігаємо серверні кімнати прохолодними.

Я все за те, що я став проактивним, але ніколи цього не робив і ніколи не чув, щоб хтось це робив. Імовірно, у вас є певний тип налаштування RAID і у вас регулярно виникають дійсні резервні копії для відповідних систем.

Так, продуктивність та потужність. Якщо старий жорсткий диск робить зчитування з підтримкою 70 Мб / сек і 100 IOPS, а потенційна заміна робить зчитування з підтримкою 200 МБ / с і 175 IOPS, а також має тричі більше можливостей, ви можете бути виправданими купувати нові накопичувачі та замінювати старі на нові просто на причини / продуктивність. (і ці цифри повністю складені, справа новіша, можна значно швидше).

Тепер що ви робите зі старими накопичувачами. Ви можете використовувати їх на тестовому сервері або додати їх до резервної копії до дискового масиву або утримувати їх як запасні частини. Або ви можете просто витерти їх та відправити на утилізацію.

Ваша середня кількість днів на сервері пов'язана з IO більше, ніж пов'язана з процесором (або принаймні всі мої). Отже, якщо у вас є справді старий сервер, який не має проблем із часом процесора чи пам'яттю, ви, ймовірно, маєте змогу значно покращити продуктивність, замінивши жорсткі диски, які на кілька поколінь позаду того, що ви можете легко придбати, щоб замінити їх.

Це залежить від впливу, якщо виникла несправність на жорсткому диску.

Якщо у вас немає RAID
Якщо ви не переймаєтесь наявністю сервера, тому що послуга може бути зупинена або через те, що вона доступна і якщо у вас є резервна копія даних. Я б сказав: Гаразд, нехай диск загине та змінить його та відновіть дані, коли він вийде з ладу.
Якщо ви дбаєте про доступність, я скажу використовувати RAID;)

Якщо у вас RAID (1, 5, 6, ...),
я б сказав, навіщо міняти жорсткий диск перед помилкою? RAID (і резервне копіювання) тут для цього. Заміна жорсткого диска на випадок, якщо він може вийти з ладу - це ризик зламати щось (реконструкція рейду завжди ризикована)

Але це лише моя точка зору! Якщо ви вважаєте, що ваш накопичувач може бути занадто застарілим, ви можете також змінити свій сервер.

Деякі диски гинуть за 1 годину, інші тривають 2 десятиліття.

Якщо це не виходить з ладу або виходить з ладу (щось, що зазвичай можна встановити за допомогою SMART-моніторингу або проблем із роботою), то єдиною іншою причиною його викинути є, якщо він недостатньо великий або досить швидкий для ваших цілей.

Що стосується дисків, питання не в тому, якщо вони вийдуть з ладу, а коли . Це механічні пристрої (якщо не використовувати SSD, але вони мають свої застереження), тому вони рано чи пізно вийдуть з ладу.

Продавці дисків прагнуть адаптувати свої виробничі процеси як можна дешевше, тому що навіть один цент, що зберігається на диску, може бути дуже важливим, коли ви виробляєте і продаєте тисячі з них; але вони, звичайно, не хочуть, щоб їхні диски вийшли з ладу до закінчення гарантійного терміну, або вони заміняли б їх постійно; Таким чином, вони із задоволенням витратять стільки, скільки потрібно, щоб тривати їх до тих пір, поки гарантія покриває їх ... але ні на один цент більше.

Кінцевий результат: більшість дисків, як правило, виходять з ладу незабаром після закінчення гарантійного терміну. Це, звичайно, не загальне правило, це лише статистика, і ваш диск може вийти з ладу зараз або тривати, поки вам це більше не знадобиться ... але, статистично, існує багато дисків, які виходять з ладу через кілька днів або місяців після їх гарантія минула

Звичайно, придбання нових, коли вони все ще не потрібні, може бути дорогим ... але заміна їх після закінчення гарантії, і вони не виконали, все одно буде дорогим.

Тепер, якщо ви зможете знайти спосіб збити їх з ладу, поки все це гарантовано (і не втрачати дані в процесі, тобто мати гарні резервні копії RAID AND ), то це було б оптимально ;-)

Я б більше не замінив робочий привід, ніж замінив робоче джерело живлення. Обидва в кінцевому рахунку не зможуть, але немає сенсу ні технічно, ні фінансово їх замінювати без поважних причин. Замініть їх, коли вони почнуть виявляти ознаки неприємностей.

Що стосується жорстких дисків, то тенденція полягає в тому, що якщо накопичувач вийде з ладу рано, це буде більш ніж ймовірно, що це зробиться в перший рік. На диски, які працюють без проблем протягом 6 років, як правило, можна покластися, що вони можуть працювати ще принаймні ще кілька років. Очевидно, що існує багато винятків, але це загальна тенденція.

Крім того, майте на увазі, що більшість накопичувачів серверного класу мають більш жорсткі вимоги до виготовлення і, як правило, більш надійні, ніж настільні накопичувачі з низькою вартістю / бюджетом. Таким чином, окрім небезпеки заміни «хорошого» накопичувача, якщо він, можливо, не вдасться, це може призвести до великої суми грошей.

Крім того, при використанні RAID, тому добре, що на сервері є хоча б одна гаряча запасна частина, тому вона може швидко почати перебудовуватися і залишатися здоровою, поки ви не придбаєте замінники за необхідності.

Я робив це в системах з "нульовим простоєм". Насправді, ви так само ймовірні, що втратите інший привід, коли RAID відбудується ... Я поміняв його один раз, а потім закінчив поміняти його, коли інший диск почав викидати помилки під час відновлення.

Це питання філософії насправді: якщо ви вірите в проактивне стрес-тестування (як у масиві, так і у вашій серцево-судинній системі), тоді вам слід поміняти свої накопичувачі. Але насправді, ти ніколи не дізнаєшся, який привід буде поганий далі. Зовсім малоймовірно, що ви можете втратити нещодавно замінений привід, перш ніж втратити будь-який із старих перевірених приводів.

Попри це, я б витрачав час на тест на стрес-тестування свого резервного рішення і залишаю диски в спокої, поки вони не почнуть насправді кидати помилки.