Статья про RAID

@kr0k0k0t прислал статью про неСХД и RAID.

Вместо эпиграфа:
«Был неправ, вспылил. Но теперь считаю своё предложение безобразной ошибкой, раскаиваюсь, прошу дать возможность загладить, искупить. Всё, ушел.» (C) «Обыкновенное чудо.»

Часто приходится быть свидетелем споров типа «а QNAP – это СХД?» «В чем разница между СХД и NAS?», «а можно ли использовать QNAP такие-то цифры для бекапов?» и т.п. Вот и здесь недавно было. Посему, в качестве деятельного раскаяния за флуд решил поделиться своим IMHO’м на эту тему. Возможно, будет для кого-то полезно. Осторожно, многабукаф.

Итак, почему же всё-таки дешевые кунапы и прочие синолоджи – это «не СХД» или «недоСХД». Disclaimer (отмазка): мы искренне извиняемся перед всеми любителями утконосо… торговых марок QNAP и Synolodgy, а также всех их уважаемых представителей. Русские слова «кунап» и «синолоджи» применены автором как нарицательные, обозначающие продукты, несущие ниже описываемые недостатки.

Начнём с того, что полный хаос в чатах рунета порой творится даже с терминологией. Считается незазорным называть системы хранения данных начального уровня «NAS», противопоставляя их «взрослым двухголовым» системам, гордо именуемым «СХД». Не буду ввязываться в эти терминологические распри. Буду использовать термины «детская СХД», и «взрослая СХД».

Обязанность СХД – хранить данные. И отдавать их с гарантированной скоростью. И отдавать именно то, что было записано. Чтобы это делать используются всякие разные уровни RAID. Наиболее известный и распространённый – RAID5. Минус емкость одного диска из набора под четность – и вуаля: скорость линейного чтения почти равна скорости дисков, помноженных на N-1, где N – количество дисков в группе (ну или помноженных на N – если включено упреждающее чтение). И устойчивость к выходу из строя любого одного диска из группы. LUN отдаётся хоть по NFS, хоть по iSCSI. Может, даже кэш есть (в старших моделях). Казалось бы, что еще нужно?

Но емкости дисков (читай – плотность записи информации на пластину) растут. И если вдруг кто не знает, то уже давно то, что головка чтения-записи записала на пластину, вообще не равно тому, что она считывает. А целостность данных обеспечивается магией высших порядков, начиная от PRML и продолжая жутко избыточным кодированием перед этой самой записью, и в процессе чтения непонятно чего. Т.е. вопрос, считаем ли мы с носителя то, что записали, это вопрос вероятности. Так-то! И злобная царица наук просто констатирует, что если вероятность скрытой ошибки чтения с купленного на массовом рынке диска 10^-14 – то вероятность словить скрытую ошибку при восстановлении массива RAID5 из 4×2 Тб дисков – 38% (источник https://qastack.ru/superuser/516949/formula-to-calculate-probability-of-unrecoverable-read-error-during-raid-rebuild). Ну или 4,7% – если вдруг случилось чудо, и купившие «дешевую коробочку» разорились к ней на диски энтерпрайз уровня с вероятностью 10^-15 (для еще более полного просветления можно покурить это: http://true-system.blogspot.com/2013/04/mtbf-afr-uer-raid.html ).

Эта же вероятность ошибки применима к простому чтению всей записанной информации с массива RAID5 в «кунапах и прочих синолоджи». Почему? А потому, что они дешевые. А значит – слабые процессоры, и софт, спроектированный «дешевыми архитекторами» и написанный «дешевыми программистами». ) И поэтому, пока коробочка считает, что все диски из набора «в поряде» – она просто считывает страйпы и отдаёт их в сеть. Не проверяя четность. Ибо если бы проверяла – процессор, запроектированный «дешевыми архитекторами» или «ушлыми маркетологами», был бы нагружен на 146%, и коробочка не выдавала бы и половины от «заявленных мегабитов» даже в режиме потокового чтения.

И это очень легко проверить: берете коробочку по вкусу, пихаете три диска (минимум для RAID5), собираете массив и записываете первые пару гигабайт повторяющейся регулярной последовательностью, например, 1234567890. Затем выключаете коробочку, открываете, достаёте один диск, пихаете его в виндовую машину и открываете – да хоть WINHEX’ом. Видите вашу повторяющуюся последовательность, перемежающуюся белибердой через -цать секторов, равных в сумме двум размерам страйпа рэйда. Белиберда, понятное дело, это контрольная сумма N-1 страйпов. А теперь меняете в одном секторе один из блоков 1234567890 на, к примеру, 1334567890. Имитируя тем самым ту самую 10^-14 скрытую ошибку, когда бит поменялся и в секторе, и в его контрольной сумме на диске.  Вставляете в коробочку, включаете и считываете записанное по сети. Ставлю три своих шляпы, что в 8 случаях из 10 вы получите на дешевых коробочках в считанном файле 1334567890 (просто запустите поиск в считанном файле). Потому что, как и было сказано, даже если программисты, писавшие прошивку коробочки, «не дешевые» – дешевый процессор и требования маркетологов «выдавать на гора большие числа скорости чтения» не позволяют им посчитать контрольную сумму при каждом чтении. Контрольная сумма будет использоваться только при работе коробочки после сбоя диска, и при восстановлении (ребилде) массива после его замены. С дикими штрафами к производительности, либо сильно растянутым во времени ребилдом. За это отвечает настраиваемый вами параметр «приоритет ребилда» или «приоритет фоновых операций».

Ну а теперь самое весёлое:  фоновая проверка целостности. )) Самые догадливые уже смеются тут вместе со мной; остальным объясняю: фоновая проверка массива нашла несовпадение данных и контрольной суммы. А теперь вопрос – а где произошла скрытая ошибка? В страйпе данных или в страйпе контрольной суммы? Что исправить на диске? Или, если недешёвый программист таки-умудрился впихнуть в «узкие штанишки» дешевого процессора подсчет контрольной суммы при чтении: что отдать в сеть – вычисленный из контрольной суммы блок или считанный с дисков? ) И который из вычисленных – с первым диском, или со вторым? )) Что решил программист конкретной коробочки легко проверить, запустив фоновую проверку рэйда после внесения изменений, описанных выше. И прочитав результат. HINT – можно делать массив не на всю емкость, а на десяток гигабайт, тогда он перемелет раздел быстро. Но автор уверен, что никто из читателей проверять не будет, поэтому сразу спойлер, т.е. ответ: в 100% случаев в RAID5 исправят контрольную сумму. Ибо когда один из дисков – всё, то выхода в общем-то, нет. Чтобы отдать в сеть блок при сбое диска его вычисляют из тех, что остались. А когда все диски живые, то (осторожно, немного лайтового матана инклудед; A,B – страйпы данных, С – страйп с суммой A xor B):
Читаем страйпы, A xor B = C  – всё Ок, данные целостные. И тут вдруг
A xor B != C – блжад, проблема детектед. Но:
A xor C != B, твайу-ж мать, но и B xor C != А, сцуко! И куда бежать, кому сдавацца? Делать нечего, поэтому, плюют через плечо три раза и, помолясь, что ошибка всё-таки в страйпе с четностью, исправляют страйп С. И в 33,(3)% случаев оказываются правы. Фу-х-х, пронесло…

Для тех, кому 33,(3)% и «пронесло» не подходит, придумали сначала RAID51, а потом и 6.  Особо упоровшиеся (в хорошем смысле) по матану и вероятностям словить скрытую ошибку разработчики запилили RAID 7.3, и даже RAID N+M, где M – количество страйпов четности. Но 51 – это потеря половины емкости массива, а потому жалко и редко используется. А вот 6 или прости-господи, 7.3 – это уже любопытнее. Там _больше одного_ блока с четностью. И поэтому можно попытаться задетектить, который из страйпов «икнул», и исправить конкретно его. Но когда, при чтении? Да! Хорошо бы. Как своими руками проверить, делает ли это конкретная коробочка, вы теперь уже знаете. )) И уже почти самостоятельно можете осознанно принимать решение, что перед вами – «детская» СХД или «взрослая».

Исходя из вышеизложенного:
А) Всё, что умеет RAID5 и не более – просто по определению не может носить гордое название «взрослая СХД».
Б) Всё, что умеет больше, чем RAID5, но не проверяет суммы при каждом чтении каждого блока – не может носить гордое звание «взрослая СХД».

Едем дальше, или очень короткий абзац. Система хранения, как и друг, познаются в беде. А какая беда у системы хранения? Выход из строя железа, конечно. Причем погибнуть может не только диск. Может заглючить матплата, проц, и память кэша. Выход один – дублирование контроллеров. Вывод: система без дублирования контроллеров в продакшене – это рисковая авантюра, а не «взрослая СХД». А кроилово, как известно, всегда ведет к попадалову.

Теперь диски. Ох уж эти диски… Раньше, когда я был молодым и неопытным, я ненавидел маркетологов «взрослых СХД» за вендор-локед диски в этих самых взрослых СХД. Ну какого хрена, вопил я про себя и иногда на форумах, эти пип-пип маркетологи не позволяют пихать во «взрослые» системы купленные по-дешевке Б/У диски?! Потом, понапарывавшись на разваливающиеся, на казалось бы ровном месте массивы и проведя бессонные ночи за софтварным склеиванием развалившихся RAID5, 10, 50 – стал много читать. И однажды наткнулся на https://habr.com/ru/post/92701/ которая меня весьма просветлила. Коротко – что делает «обычный» диск (пихуемый среднестатистическим админом в коробочку типа кунап или синолоджи), когда напарывается на вполне себе нескрытую ошибку, т.е. контрольная сумма сектора не совпадает с вычисленной? Ну конечно же начинает практически бесконечно «тупить». Пытаться считывать проблемный сектор снова и снова. Особо умные – уводя голову «чуть левее», или «чуть правее» от «дороги», в надежде таки-прочитать несносный сектор. А что делает raid-edition диск? Правильно, пробует сделать это 1, 2, 3 секунды, и честно говорит ERR. Потому что «знает» – он в массиве. Ну не читается сектор, «случилось дерьмо», что поделать? О, так ведь можно же вычислить целостный блок данных из страйпов четности! Что делает серьезная, взрослая СХД, увидев ERR при чтении сектора/блока? Ну, после того как вычислила и отдала блок в сеть?  Думаете, тут же зажигает диск красненьким? А вот и не всегда! ) Она-то «знает», что, возможно, просто при записи этого конкретного сектора что-то «моргнуло», и сектор «коряво» записался. И можно тут же (или чуть позже, когда нагрузка спадёт) попытаться перезаписать битый сектор правильной, вычисленной информацией. И он с высокой долей вероятности корректно запишется! И будет корректно писаться/читаться еще несколько лет (а если нет – то красненьким диск зажечь в этой ситуации еще не поздно), ибо remap секторов на HDD никто не отменял. Особенно если это и не HDD вовсе, а SSD, и контроллер носителя уже сделал ремап на резервный блок. Но «ложечки нашлись, а осадочек остался», поэтому «правильная», «взрослая СХД» уже поставила «маленький черный минусик» в свою «записную книжечку» напротив серийного номера носителя. И если таких «минусиков» вдруг начинает копиться на одном из носителей больше заданного уровня – вот тогда СХД зажжёт сначала жёлтую («не хреново было бы заменить…»), а потом и красную («меняй немедленно!») лампочку напротив слота с носителем. А если админ правильный, и позаботился о hot-spare носителях – то автоматически начнёт перестроение на них.  И это – только малая толика всего, что может должно происходить между хранилкой и носителями. К примеру, еще она может должна считывать SMART-атрибуты носителей, причем не один-два общих, а еще и кучку специализированных. И т.д. и т.п. Отсюда простой вывод: для обеспечения полноценного, грамотного хранения данных «взрослая СХД» просто обязана уметь общаться с носителями «на одном языке». И пока этот «язык» не выработан и не стандартизован (даже единого стандарта на SMART-атрибуты нет, чего уж говорить об остальном) – вендор-локед диски, разговаривающие с хранилкой на одном языке – единственный способ обеспечить ту надежность, что на полном серьёзе пишут в спецификациях «взрослых СХД». А иногда это пять девяток, а это уже совсем не хухры-мухры.

Ну а что делать, если и «взрослую СХД» хочется, и платить мегаденьги за вендор-локед носители жаба и/или бюджет не позволяют? Допустим, нашли мы недорогие диски, в которых SCT ERC можно поменять, и он даже не слетает в дефолт после отключения питания. Куда это всё запихать, чтобы и RAID 7.3, и «двухголовость», и контроль целостности и при чтении и фоновый, и чтобы медленные, «чуть-чуть» заикающиеся при чтении диски помечало сначала желтым, и только совсем мёртвенькие – красным, и на degraded массивах почти не тупило, и кое-что ещё? Хорошая новость – есть такая СХД! ) Плохая – если я её назову, то посыпятся обвинения в ангажированности, рекламе и прочем. Поэтому отделаюсь полунамёком: придумать такое могли только в одной стране. ))

Ну а что делает ваш любимый кунап с напиханными в него не raid-edition (которые, как я надеюсь к этому моменту понятно, SCT ERC disabled или =0) дисками всё это время? Да тупит он. Ибо не может решить, зажигать диск красным, или еще нет. А вслед за ним тупит, например, восстановление из бекапа, файлы которого админ положил на пресловутую недорогую коробочку. Или все виртуальные машины, попытавшиеся что-то считать или записать на «СХД». И даже если открытых ошибок на диске нет: что из-за скрытых ошибок не восстановится из бекапа емкостью в 15 Тб, записанном на RAID5 массиве из 10×2 Тб дисков – вопрос везения. Так царица наук сказала.  Ну а если админ «в порыве слабоумия и отваги» в него еще и SMR дисков напихал, то начинается совсем уж треш и угар, типа такого: https://habr.com/ru/post/497900/

Надеюсь, после этих размышлений вслух хоть немного поутихнут споры про то, что считать «недоСХД», а что СХД «взрослыми».

Считывающихся вам без ошибок бекапов, господа/товарищи!