Комментарии 31
Диски, которые умеют работать с RAID, могут сообщить RAID-контроллеру, что есть проблема с чтением блока данных, запросить этот блок с других дисков и в это время обрабатывать другие запросы, а получив блок — перезаписать его в другом месте проблемного диска.
Что за ерунда? Диск не может ничего запросить у другого диска.
Мне кажется, имелось в виду, что в случае возникновения проблемы с чтением, диск сообщит об этом контроллеру, а уже он, в свою очередь, запросит
этот блок с других дисков и в это время обрабатывать другие запросы, а получив блок — перезаписать его в другом месте проблемного диска.
НЛО прилетело и опубликовало эту надпись здесь
Тут имелось ввиду, что десктопный винчестер будет тупить, пока не прочитает сектор. Если он будет тупить больше какого-то количества секунд (как правило 8-и), то контроллер выкинет его из массива и начнет ребилд. Если диск поддерживает TLER, то он протупит несколько секунд (можно настроить), а потом честно скажет, что прочитать ничего не может. Контроллер восстановит данные с другого диска или по чексуммам, а диск останется в массиве и ребилда не будет. Управляется эта штука через SCT Error Recovery Control (совершенно не понимаю, почему статью переместили на Geektimes)
Начнем с того, что все имеющиеся на рынке накопители, можно четко разделить на классы:
— SATA
— SAS
— SSD
Скорость вращения — параметр вторичный.
Далее, те же «все диски» делятся по типу использования
— для линейного доступа
— для конкурентного доступа
Опять же, скорость вращения — параметр вторичный.
Так вот, я не увидел в Вашем обзоре разделение дисков на типы с точки зрения работы в конкурентной среде, например виртуализация, параллельное выполнение долгих операций, параллельный доступ нескольких процессов, запись больших и маленьких блоков. А вот тут разные диски проявляют себя очень по разному.
— SATA
— SAS
— SSD
Скорость вращения — параметр вторичный.
Далее, те же «все диски» делятся по типу использования
— для линейного доступа
— для конкурентного доступа
Опять же, скорость вращения — параметр вторичный.
Так вот, я не увидел в Вашем обзоре разделение дисков на типы с точки зрения работы в конкурентной среде, например виртуализация, параллельное выполнение долгих операций, параллельный доступ нескольких процессов, запись больших и маленьких блоков. А вот тут разные диски проявляют себя очень по разному.
Начнем с того, что SATA/SAS — это всего лишь интерфейсы, а не диски. А диски различаются не только по скорости вращения, как Вы верно отметили, или отсутствию вращающихся частей (твердотельные накопители), но по многочисленным другим характеристикам, которые важны для одних задач и менее важны для других.
Разделение дисков на типы с точки зрения работы в конкурентной среде — зависит от задачи, и подобный обзор вместить в одну статью крайне сложно, потому и запрошено было обсуждение этих проблем в комментариях.
Разделение дисков на типы с точки зрения работы в конкурентной среде — зависит от задачи, и подобный обзор вместить в одну статью крайне сложно, потому и запрошено было обсуждение этих проблем в комментариях.
Крайне просто. SATA — диски для десктопа, SAS — для сервера. В целом это именно так. А в статье об этом ни слова. Первый вопрос, который у клиентов хостера возникает, Вы вообще не рассмотрели.
НЛО прилетело и опубликовало эту надпись здесь
Крайне просто. SATA — диски для десктопа, SAS — для сервера. В целом это именно так. А в статье об этом ни слова. Первый вопрос, который у клиентов хостера возникает, Вы вообще не рассмотрел.
Pilat, нет же, такое впечатление, что Вы любите комментировать, но не любите читать. Еще раз прочитайте публикацию внимательно. Desktop-диски — это те диски, которые не умеют взаимодействовать эффективно с RAID и для производительности которых очень критичны вибрации.
SATA RE, SATA ENTERPRISE — хорошие СЕРВЕРНЫЕ ДИСКИ, и они идут с интерфейсом SATA. Если диск имеет интерфейс SATA — это во все не означает, что он десктопный.
Также, как в прочем и твердотельные накопители, SSD могут быть, как с интерфейсом SATA, так и SAS, так и вообще PCI Express.
"… вероятность возникновения ошибки при работе этих [5-ти] дисков в массиве RAID5 будет составлять (5х(1000/12500х1014))/1014x100% = 40%. Как видим, использовать 5 PC-дисков в RAID5 просто нельзя..." Как я понял 40% это вероятность возникновения ошибки при восстановлении RAID5 из ШЕСТИ дисков (один то вылетел, его считать не нужно).
НЛО прилетело и опубликовало эту надпись здесь
Действительно, брался худший сценарий и на практике вероятности могут быть меньше. Тут была больше цель показать, зачем при использовании больших массивов использовать диски RE, а не десктопные, почему не стоит использовать RAID массивы низкого уровня, такие, как RAID5 (безопасность). Само собой, что при выходе из строя одного из дисков в RAID5-массиве, может добавится вероятность краха всего массива по причине того, что RAID станет работать в критичном режиме, если во время не отследить вылетевший диск.
Все эти рассуждения про надёжность не имеют практического значения. Параметры дисков (надёжность) указаны для абстрактных дисков, при этом не учитываются другие факторы — происхождение, бракованная партия, условия хранения… Это учитывается производителями типа HP, но не noname сборщиками. Естественно, обычные SAS диски 15К летят с огромной и неизвестной точно вероятностью. Статистика отказов тоже не имеет практического значения, так как отказ в течении трёх лет говорит ни о чём — к тому времени выпускаются совсем другие диски.
Теперь насчёт приведённых предложений. Что Вам пришло в голову запускать на сервере с 4x4ТБ SATA и 32Gb памяти и линией с трафиком 100Тб?
Теперь насчёт приведённых предложений. Что Вам пришло в голову запускать на сервере с 4x4ТБ SATA и 32Gb памяти и линией с трафиком 100Тб?
Вы не совсем правильно понимаете указанную вероятность отказа производителем. Вероятность отказа в течении скажем миллиона часов, если речь идет о MTBF, не означает, что 1 диск «проживет» 114 лет, это означает, что из партии в 114 дисков в течении года может выйти из строя один диск (худший сценарий).
Кроме прочего, тут не рассматривалась вероятность отказа диска поностью, тут рассматривалась вероятность невосстановимой ошибки.
Это хорошее предложение для файлового-архива и бекап-решения. С хорошим быстрым каналом. В прочем, параметры этого сервера подлежат корректировке, и если есть желание — можно поставить вместо какого-то из дисков SSD (сделав запрос в отдел продаж) или же увеличить объем трафика, если включенного трафика будет недостаточно.
Кроме прочего, тут не рассматривалась вероятность отказа диска поностью, тут рассматривалась вероятность невосстановимой ошибки.
Что Вам пришло в голову запускать на сервере с 4x4ТБ SATA и 32Gb памяти и линией с трафиком 100Тб?
Это хорошее предложение для файлового-архива и бекап-решения. С хорошим быстрым каналом. В прочем, параметры этого сервера подлежат корректировке, и если есть желание — можно поставить вместо какого-то из дисков SSD (сделав запрос в отдел продаж) или же увеличить объем трафика, если включенного трафика будет недостаточно.
Вероятность отказа в течении скажем миллиона часов, если речь идет о MTBF, не означает, что 1 диск «проживет» 114 лет, это означает, что из партии в 114 дисков в течении года может выйти из строя один диск (худший сценарий).
Это было бы корректно, если бы для дисков была бы справедлива эргодическая гипотеза (среднее по времени эквивалентно среднему по ансамблю). Но эта гипотеза очевидно не верна для любых объектов, которые способны «стареть», т. е. изнашиваться, каковыми являются жёсткие диски.
Из парти в 114 дисков один умрёт в течение первого года эксплуатации? А насколько интенсивной предполагается эта эксплуатация? А если я про второй год, 1 из 114 выживших или от первоначального количества, или уже не один? А на десятый год?
В общем, MTBF — это конечно хорошо, но это не про диски. Диски не умирают в соответствии с теорией вероятностей или термодинамикой. Они умирают от скрытых дефектов, например, плохая балансировка ведёт к вибрации, которая усиливает износ, из-за чего ещё сильнее повышается вибрация, и так далее.
C течением времени вероятность нарастает. Само собой, что интенсивность эксплуатации играет не последнюю роль. Те же десктопные диски производитель считает возможным использовать лишь 8*5 = 40 часов в неделю и значение MTBF указано из этого расчета. После 2-х лет работы (для жестких дисков, которые более подвержены износу ввиду движущихся частей), вероятность выхода из строя нарастает экспоненциально.
Как-то ваши сроки совершенно не согласуются со статистикой backblaze. А они там прямо по модели диска таблицу выстроили. И для seagate barracuda 7200.11 среднее время жизни (при круглосуточной нагрузке) 4.3 года. И другие диски тоже долго жили. Как вы это объясните? У вас другая статистика? Ну так покажите же. В идеале — статистика в виде «столько-то дисков вылетело на N-том месяце жизни», чтобы видеть распределение наглядно и можно было хоть что-то объяснять, а то пока от вас есть какие-то общие слова и умозрительные выводы, взятые с потолка.
И немного про математику. Вероятность нарастает экспоненциально — это очень интересно, при условии, что вероятность не может быть больше единицы. Вы уж определитесь, какое из слов в предложении лишнее.
И немного про математику. Вероятность нарастает экспоненциально — это очень интересно, при условии, что вероятность не может быть больше единицы. Вы уж определитесь, какое из слов в предложении лишнее.
https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D1%80%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5
Вы извините, я не математик, а физик, и в физике у нас возможны и экспоненциальный рост к единице и сказанная мной фраза не является ошибочной.
На счет той статистики, которую Вы приводите, это при какой нагрузке? Эта статистика при домашнем пользовании. Причем после 4-х лет — вероятность отказа очень сильно стремится к единице по причине именно механического износа.
Есть реальные данные, пользователь привел ниже, из 120 дисков в течении 2,5 лет сбойный диск раз в месяц. Но опять же, эти все значения зависят от нагрузки.
У нас очень много выделенных серверов, но не все пользователи меняют диски (запрашивают у нас замену), когда они вышли из строя. Так как не все умеют сопровождать свои серверы или следят за ними должным образом, а сопровождение у нас заказывает лишь небольшой % клиентов. Потому, к сожалению, наши данные так же были бы малообъективны.
Однако, тут, они примерно дают представление, какой диск и в каких случаях лучше использовать. В этом смысл был этой статьи, объяснить целесообразность применения дисков. Мы не утверждаем, что статистика, приведенная в статье только такая и другой быть не может. Очень много разных параметров нужно учесть. Но понять, какой диск выбрать для того или иного сценария — возможно.
Вы извините, я не математик, а физик, и в физике у нас возможны и экспоненциальный рост к единице и сказанная мной фраза не является ошибочной.
На счет той статистики, которую Вы приводите, это при какой нагрузке? Эта статистика при домашнем пользовании. Причем после 4-х лет — вероятность отказа очень сильно стремится к единице по причине именно механического износа.
Есть реальные данные, пользователь привел ниже, из 120 дисков в течении 2,5 лет сбойный диск раз в месяц. Но опять же, эти все значения зависят от нагрузки.
У нас очень много выделенных серверов, но не все пользователи меняют диски (запрашивают у нас замену), когда они вышли из строя. Так как не все умеют сопровождать свои серверы или следят за ними должным образом, а сопровождение у нас заказывает лишь небольшой % клиентов. Потому, к сожалению, наши данные так же были бы малообъективны.
Однако, тут, они примерно дают представление, какой диск и в каких случаях лучше использовать. В этом смысл был этой статьи, объяснить целесообразность применения дисков. Мы не утверждаем, что статистика, приведенная в статье только такая и другой быть не может. Очень много разных параметров нужно учесть. Но понять, какой диск выбрать для того или иного сценария — возможно.
Я что-то не совсем понял фразу,
сильно возрастает время ожидания, которое RAID не терпит и непременно сочтет диск потерянным и попытается!!! восстанавливать диск… — крах всего массива.Почему контроллер настроен сам восстанавливать диск? В основном обслуживающий персонал принимает решение, о замене и ребилде массива. И почему во время ребилда должен наступить крах? — просто выдаст ошибку: мол не могу сделать ребилд — поменяйте диск.
Потому, что во время ребилда есть вероятность возникновения невосстановимой ошибки на каком-либо другом диске. Что же касается самого ребилда, если диск «выпал» из массива на время, так как слишком долго пытался считать проблемный кластер, то после завершения попытки — он сам же и вернется в массив, при этом будет автоматически запущен ребилд.
Хватит гнать пургу. На хабре уже была пара статей с независимой статистикой дисков. Они там вообще покупают самые дешёвые диски (т.е. домашние SATA) и отлично с ними живут. «Домашние» SATA на 2 Тб вполне способны под серверной нагрузкой нормально трудиться по три года (если не выйдут из строя за первых три месяца по причине брака) — средний возраст Seagate Barracuda 7200.11 (ST31500341AS) у них вообще 4.3 года.
А тот факт, что честных официальных данных такого рода, не похожих на рекламу нет, намекает, что производители отлично понимают: дешёвые диски работают прекрасно. Они потому и гонят весь этот маркетинговый буллшит, что по-другому просто не могуть продать невменяемо дорогие «серверные» диски. При честном рассчёте стоимость их производительности (iops/руб) и объёма (гб/руб) оказывается больше. То, что на быстрых дисках получаются массивы производительнее, объясняется тем фактом, что эти диски сами по себе меньше по объёму, а значит для получения массива того же объёма мы берём больше шпинделей и значит автоматически получаем больше iops.
Все эти модели MTBF и BER — фикция: предполагается, что вероятность выхода диска из строя не зависит от того, сколько он проработал — а это совершенно не так, вероятности появления ошибок однозначно нарастают по мере эксплуатации. И пока я не видел ни у одного производителя реалистичной модели, которая это учитывает. Единственный показатель на эту тему, из которого можно делать какие-то выводы — это срок гарантии; я ему доверяю, потому, что производители в гарантийном случае сами платят рублём, и чтобы платить меньше хотя бы как-то анализируют ситуацию и срок дают правдоподобный.
Умирание RAID5 больше связано с тем, что диски ставят из одной партии, работают они в массиве одинаковое время и под одинаковой нагрузкой, и соответственно умирают обычно тоже вместе. Если в таком массиве вылетел диск — жди, что все посыпятся. Наблюдал неоднократно, что в течение месяца все диски массива — из одной партии — один за другим были заменены.
А тот факт, что честных официальных данных такого рода, не похожих на рекламу нет, намекает, что производители отлично понимают: дешёвые диски работают прекрасно. Они потому и гонят весь этот маркетинговый буллшит, что по-другому просто не могуть продать невменяемо дорогие «серверные» диски. При честном рассчёте стоимость их производительности (iops/руб) и объёма (гб/руб) оказывается больше. То, что на быстрых дисках получаются массивы производительнее, объясняется тем фактом, что эти диски сами по себе меньше по объёму, а значит для получения массива того же объёма мы берём больше шпинделей и значит автоматически получаем больше iops.
Все эти модели MTBF и BER — фикция: предполагается, что вероятность выхода диска из строя не зависит от того, сколько он проработал — а это совершенно не так, вероятности появления ошибок однозначно нарастают по мере эксплуатации. И пока я не видел ни у одного производителя реалистичной модели, которая это учитывает. Единственный показатель на эту тему, из которого можно делать какие-то выводы — это срок гарантии; я ему доверяю, потому, что производители в гарантийном случае сами платят рублём, и чтобы платить меньше хотя бы как-то анализируют ситуацию и срок дают правдоподобный.
Умирание RAID5 больше связано с тем, что диски ставят из одной партии, работают они в массиве одинаковое время и под одинаковой нагрузкой, и соответственно умирают обычно тоже вместе. Если в таком массиве вылетел диск — жди, что все посыпятся. Наблюдал неоднократно, что в течение месяца все диски массива — из одной партии — один за другим были заменены.
Странный способ получить 40% имея только данные о количестве, без времени.
1 ошибка на 12,5 ТБ, то есть на 1 ТБ винте 1/12,5 ошибок.
Если 1 ошибка это неправильны 1 бит, то вероятность ошибки 1/8Е12
У 5 винтов 5/8Е12. тут 40% и близко даже нет
1 ошибка на 12,5 ТБ, то есть на 1 ТБ винте 1/12,5 ошибок.
Если 1 ошибка это неправильны 1 бит, то вероятность ошибки 1/8Е12
У 5 винтов 5/8Е12. тут 40% и близко даже нет
Ужас какой.
Во-первых, RAID5 на действительно больших массивах перестраивается так долго и так тормозит, что использовать его просто нет смысла. Так что появления URE вы с высокой вероятностью просто не дождетесь, плюнете и пересоберете массив начисто :)
Во-вторых, любой приличный RAID-контроллер умеет отключать кэш на дисках, иначе к чему все эти навороты с батарейками?
В-третьих, SAS 15K никому не нужны, потому что есть SSD за те же деньги в 2.5" форм-факторе и гораздо быстрее. Линейки 15К дисков давным-давно не обновляются.
В-четвертых, хотя идея про неправильное поведение десктопных дисков при ошибках верная, в объяснении у вас каша. Если контроллер «теряет» диск при длительном времени ответа, с чего бы ему начинать ребилд после этого? Ничего он не начнет пока вы диск не поменяете.
А на самом-то деле проблема как раз в том, что контроллер НЕ потеряет диск с длительным временем доступа, и весь массив будет ждать чтения сбойного сектора.
Во-первых, RAID5 на действительно больших массивах перестраивается так долго и так тормозит, что использовать его просто нет смысла. Так что появления URE вы с высокой вероятностью просто не дождетесь, плюнете и пересоберете массив начисто :)
Во-вторых, любой приличный RAID-контроллер умеет отключать кэш на дисках, иначе к чему все эти навороты с батарейками?
В-третьих, SAS 15K никому не нужны, потому что есть SSD за те же деньги в 2.5" форм-факторе и гораздо быстрее. Линейки 15К дисков давным-давно не обновляются.
В-четвертых, хотя идея про неправильное поведение десктопных дисков при ошибках верная, в объяснении у вас каша. Если контроллер «теряет» диск при длительном времени ответа, с чего бы ему начинать ребилд после этого? Ничего он не начнет пока вы диск не поменяете.
А на самом-то деле проблема как раз в том, что контроллер НЕ потеряет диск с длительным временем доступа, и весь массив будет ждать чтения сбойного сектора.
Батарейки — для того, чтоб рейд-контроллер завершил операции и подсчет четностей (контрольных сумм), они не помогут спасти кеш дисков. То, что контроллер умеет отключать кеш — однозначно, об этом и писалось в статье, что его следует отключать.
По поводу того, с чего контроллер решил восстанавливать, если диск «подвис» в результате того, что долго не мог считать проблемный сектор и НА ВРЕМЯ из-за этого был исключен из массива, то после того, как попытки чтения будут завершены и сектор будет все же считан, либо отмечен, как проблемный — диск вернется в массив и будет начата процедура ребилда.
Проблема как раз в том, что контроллер потеряет диск с очень длительным временем доступа, так как массив не может ждать, пока диск ответит, слишком долго.
По поводу того, с чего контроллер решил восстанавливать, если диск «подвис» в результате того, что долго не мог считать проблемный сектор и НА ВРЕМЯ из-за этого был исключен из массива, то после того, как попытки чтения будут завершены и сектор будет все же считан, либо отмечен, как проблемный — диск вернется в массив и будет начата процедура ребилда.
Проблема как раз в том, что контроллер потеряет диск с очень длительным временем доступа, так как массив не может ждать, пока диск ответит, слишком долго.
НЛО прилетело и опубликовало эту надпись здесь
Вот, реальные данные, как видим, картина может быть даже хуже расчетной.
К слову сказать, у нас парк более 1000 серверов, но мы не видим картины полноценно, так как не все пользователи отслеживают проблемы с дисками, у кого-то диск может быть уже не в рейд-массиве, а люди просто об этом не догадываются.
К слову сказать, у нас парк более 1000 серверов, но мы не видим картины полноценно, так как не все пользователи отслеживают проблемы с дисками, у кого-то диск может быть уже не в рейд-массиве, а люди просто об этом не догадываются.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Целесообразность и преимущества применения серверных накопителей, построение RAID-массивов, стоит ли экономить и когда?