Де ви знаходите свої дані MTBF?


9

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

Проблема в тому, що їхні номери MTBF вже ніхто не повідомляє. (У будь-якому випадку, крім виробників жорстких дисків.)

Куди ви шукаєте дані MTBF для компонентів та серверів?


Мені цікаво дізнатися, як ви використовуєте дані MTBF.
dr.pooter

Відповіді:


2

Чому MTBF не має значення

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

Незважаючи на те, що MTBF для приводів професійного та споживчого рівня в останні роки збільшився на порядок, рівень непоправної помилки залишився відносно постійним. Ця швидкість оцінюється в 10 ^ 14 біт, тому один біт на 12 терабайт зчитується для споживчих накопичувачів SATA, джерело .

Чому вам слід втратити сон над масивом RAID 5

Отже, це лише 6 пропускань бренду, що лупить новий привід 2 Тб. Скільки часу потрібно для зчитування даних 12 Тб? Набагато менше часу, ніж MTBF для цього накопичувача.

http://storagemojo.com/2008/02/18/latent-sector-errors-in-disk-drives/

Що ще більше стосується, це шанс подвійного зчитування зчитування в масиві RAID 5, що складається з великих дисків. Із масивом RAID 5 з накопичувачем 7 Тб, ймовірність помилок у повторному зчитуванні під час відновлення RAID становить 50%.

http://blogs.zdnet.com/storage/?p=162


Ви завжди можете використовувати RAID6, можливо?
Chopper3

3
Чудова відповідь, але охоплює лише жорсткі диски
Марк Хендерсон,

@ Chopper3, так, RAID6 дійсно покращує ситуацію, але як тільки ви виділили два диски на паритет, а третього на гарячу запасну, тоді на 7 дисковому масиві ви наблизитесь до того ж простору, що і масив RAID10.
Дейв Чейні

Я шукаю дані для більш ніж просто жорстких дисків. Цілі сервери час від часу відмовляються, тому варто вимірювати, як часто.

1

Прикро, що люди думають, що цифри MTBF не застосовуються до складних систем. Справжня проблема (afaik) полягає в тому, що виробники не мають цифр MTBF для своїх апаратних модулів. Це цифри, які за всіма правами повинні бути доступними. Dell каже: "Dell більше не перераховує конкретні MTBF для своїх серверів". насправді жорстокий! Вони також можуть сказати: "Ну, наші речі насправді недостатньо надійні, щоб використовуватись там, де потрібна цифра MTBF".

Інженер з надійності (або хлопець, який носить шапку RE), повинен обмежувати сферу дослідження доступності. Це часто обмежується апаратними модулями.

Щодо класифікації того, що є невдачею ... Ну, тому ми проводимо аналіз FMECA.

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


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

0

Я бачив, як MTBF повідомляв на сайтах підтримки компаній. Щоб отримати інформацію, поговоріть зі своїм торговим представником або SE.


0

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


І все-таки деякі сервери все ще надійніші за інші. Нам потрібно відповісти на запитання на кшталт "чи варто цього другого джерела живлення?" Для цього нам потрібні дані. В ідеалі це була б реальна статистика несправностей, яка повідомляється для всіх подібних пристроїв. Ми використовуємо MTBF як слабкий проксі для цього фактичного розподілу.

Справедливо. У моєму маленькому світі ідея надмірності є очікуваною частиною процесу. Для іншого прикладу подивіться на більшість масштабних хостинг-провайдерів або google. Я все-таки припускаю, що з огляду на товарний статус серверів wintel, це слабша проблема. Якщо ви говорите про z-серії чи подібні, рівняння та очікування значно відрізняються.
dr.pooter

0

На жаль, MTBF не є практичним або надійним вимірюванням на сучасних серверах. Вся концепція MTBF полягає в тому, що якщо певна модель / конфігурація багато хто використовується протягом тривалого часу, ми, ймовірно, можемо знати її надійність.

Сьогодні більшість із нас із задоволенням торгують потенційною додатковою надійністю для доведених додаткових показників та енергоефективності. Наприклад, ви б побудували свої нові сервери на 18-24-місячному обладнанні лише тому, що це довели свою надійність? або просто йти з процесорами останнього покоління з більш ядрами, кінськими силами та енергоефективністю?

Крім того, на відміну від старих телефонних систем телефонії, системи досить налаштовані, і, звичайно, значною мірою залежать від програмного забезпечення. Наскільки надійною є версія BIOS x.xx або версія драйвера y.yyy? Чи останні патчі сервера ОС / DB / додатків підвищують стабільність чи мають регресії стабільності? Скільки серверів у світі фактично використовують ту саму точну суміш апаратної / стекової версії, що і ви?

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


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

Здається, немає надії на те, щоб ІТ колись перетворився на науку. Ми продовжуємо працювати над припущеннями, відсутністю важких даних та витрачанням ресурсів. Сьогодні більше нагадує чорну магію, ніж щось інше. Інженерія здається далекою метою.
Джованні Тірлоні

0

Я згоден з більшістю інших відповідей: номери MTBF мені не корисні, і я ніколи їх не перевіряю.

Єдиний виняток - це жорсткі диски, але навіть там я дивлюся лише на MTBF дуже грубо, і обов'язково купую більш надійні диски "серверного класу", якщо є вибір.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.