Редактирование: UNИX, весна 2008, 04 семинар (от 30 мая)

* '''Официальная страница:''' http://uneex.ru/Events/Storage

Изображение:yrii.jpg|Юрий Рязанцев

Дело в том, что мы, то есть ЛВК — бюджетная организация, и как это бывает, внезапно под новый год сказали, что есть полтора миллиона рублей, и их надо срочно потратить. Поскольку списка, чего надо, не было, решили, что места мало и пользователи любят хранить всякую мультимедию, в итоге возникла потребность во внешнем хранилище. Поэтому пришлось окунуться в то, что такое СХД, конкретно SAN, и очень много было вопросов, потому что господа, которые при ..., у них немножко другая терминология, а нас интересовали больше всякие разные технические вещи, как оно работает и как его использовать в той инфраструктуре, которую мы себе видели. Поэтому пришлось покопаться. Некоторое время назад лектор делал доклад на ЛВКшном студенческом семинаре о том, что он узнал, а это такая, изменённая версия, без совсем простых вещей, но, тем не менее, версия того доклада.

** ''ГК'': А то есть мнение, что «raid» это «набег» (''отсылка к одной из лекций ГК, где к нему после лекций подошли с распечаткой переведённой PROMT'ом документации по установке Rad Hat, в которой упоминание RAID было переведона именно таким образом'')

** ''GQ'': Понятно, что самый тупой способ хранить данные на нескольких дисках так, чтобы была устойчивость: первый байт записываем на первый диск, второй на второй, третий на третий, а на четвёртый XOR этих байт. Так работает '''RAID 3''', если не ошибаюсь. <!-- 31:00 --> Но это неэффективно, поскольку всё равно обмены с дисками идут блоками, поэтому решили, что хранить надо блоками, и этот XOR хранить для блока. И использовали один диск, на котором хранили контрольные суммы. Это '''RAID 4'''. Это опять же не очень эффективно, поскольку диск с контрольными суммами получается bottleneck'ом, следственно, все операции завязаны на этот диск. Поэтому придумали распределить эту контрольную сумму по всем дискам, то есть в начале для первой группы блоков она на n-ном диске, для второй — на n&minus;1-ом, и так далее. В случае, если один из дисков выходит из строя, у нас всегда есть вся информация, чтобы все данные восстановить. Это называется '''RAID 5'''. Объединять можно любое количество дисков, больше или равное двум. В случае двух это mirror. RAID 6 это то же самое, только для каждой группы блоков два взаимодополняющих блока с чётностью. Соответственно, если два диска выходят из строя, то их также можно восстановить.

** ''ivlad'': Это ты тоже из Википедии взял?

[[Изображение:Uneex 08 05 30 slide12.png|thumb|left|240px]]

* ''ivlad'': Если у тебя здесь (RAID 0+1) вылетел вот этот диск, то в RAID у тебя отвалилась эта половина зеркала целиком. Если у тебя дальше вылетел один из этих дисков (в другой половине зеркала), то у тебя отвалилось уже всё, вторая половина зеркала отвалилась, всё умерло. А вот в этой ситуации (RAID 10), если у тебя отвалился вот этот диск, то RAID 0 целиком продолжает работать, единственное что у тебя отвалилась половина зеркала, но второй диск отдаёт все свои данные. Если в этом случае отвалится любой из этих двух (в другом зеркале), то оно будет продолжать работать, а если отвалится этот (второй диск зеркала), то не будет. На деле, проблемная ситуация состоит в чём: диски делают одни и те же производители, диски в дисковые системы идут из одной партии, наблюдение за их отказами — это вещь нетривиальная. Есть некая статистика у дисковых вендоров, которая очень закрытая, она говорит о том, что диски выходят из строя одновременно, пачками. Поэтому, скорее всего, в этой ситуации выйдет из строя этот вот этот диск (второй диск зеркала). Потому что... ну, потому что тебе вообще не повезло. <!-- 40:39 -->

<!-- тут наверное что-то смешное, но я ничего разобрать не могу :( -->

Таким образом можно не только 0+1 и 1+0 объединять, но и 5+0, 1+0+0, и так далее. В случае, если вышел из строя один из дисков, возникает проблема как можно быстрее выйдет один диск, вдруг второй выйдет из строя. Так как на человека надеяться небезопасно, то для этого придумали добавлять hot spare диски, на которых ничего не хранится, и если один из дисков в RAID выходит из строя, то диск hot spare встаёт на его место.

=== MultiPath ===

<!-- Слайд 13 -->

[[Изображение:Uneex 08 05 30 slide13.png|thumb|left|240px]]

Это один аспект отказоустойчивости, тот, который относится к сохранности данных, а есть ещё задача обеспечения доступности. В современных системах хранения данных для этого используется технология, которая называется MultiPath. Вот у нас есть некоторый ящик с дисками, и он подключен к серверу. Вот он подключён при помощи какого-то провода, и какие-то порты ввода/вывода на этом ящике, на этом сервере. Соответственно, это узлы, которые могут выйти из строя. Во-первых, ящик можно подключить двумя проводами, тогда, если вылетает один из портов или уборщица задевает шваброй один из проводов, то всё равно они остаются соединены. И для того, чтобы это не требовало ручных изменений и настройки, существует подсистема MultiPath, которая для нашего сервера делает вид, что у нас один канал данных, а под ней же лежат эти два канала, которые, во-первых, в случае выхода одного из строя можно использовать другой, во-вторых, если у нас слабое место по скорости эти каналы, то можно и нагрузку раскидывать по ним. В частности, мы это тоже используем.

=== RAID-контроллеры ===

<!-- Слайд 14 -->

[[Изображение:Uneex 08 05 30 slide14.png|thumb|left|240px]]

* ''ximaera'': Тут коротко не получится [https://imap.cs.msu.su/pipermail/uneex/2008-May/002326.html] [[Изображение:Ximaera.jpg|thumb|240px|Антон Гавриченков (ximaera)]]

 

Сначала контроллеры были аппаратные, такие платы, которые делали вид, что к ним подключён одни диск, а на самом деле дисков было подключено несколько, и они сами как-то все синхронизации выполняли. Платы стоят дорого, особенно, когда они производятся не на потоке, а только для дорогих серверов. Поэтому придумали, почему бы программно, на уровне системы не эмулировать то же самое. И придумали программный RAID. Понятно, что он будет требовать ресурсы нашего сервера, ЦП будет задействоваться, будет, возможно, работать медленно, из-за того, что там пока вычислитель общего назначения это посчитает, плюс ему самому приходиться распараллеливать обмены по нескольким дискам. Но, тем неменее, зато это более-менее замечательно работает. И не так давно, лет 5 назад…

Ну, хорошо, может и десять. Стало очень популярно в недорогие материнские платы встраивать нечто, что производитель гордо называл аппаратным RAID'ом, но на самом деле это не является аппаратным RAID'ом, это нечто, способное работать как RAID на этапе загрузки, на этапе BIOS, а когда загружается операционная система, там реально драйверами реализуется все эти функции, то есть ничем в лучшую сторону это от программного RAID не отличается. Зато это отличается в худшую сторону. Когда у нас программный RAID, если вышла из строя железка, к которой подключены диски, мы можем подключить их к любой другой железке, нам же нужен физический доступ только до независимых дисков, дальше оно уже само. <!-- 47:00 --> В случае же, если вышел из строя аппаратный RAID…

Да, в случае, если вышел из строя аппаратный RAID, то мы можем столкнуться с тем, что нужно купить точно такой же адаптер, чтобы получить доступ до наших данных, а точно такой же адаптер стоит больших денег, давно не продаётся, потому что давно вышло новое поколение, его надо заказывать из Штатов и ждать две недели и так далее.

* ''Юрий'': На самом деле, это достаточно легко происходит, необязательно даже это знать, потому что сама файловая система, она имеет достаточно чёткое определение начальных блоков. И … понять, в какой последовательности они лежать, проблемы не представляет. <!-- конспект с места: Но в случае рейда 0 и 1 помогает dd и скрипт на шелле, достаточно знать, какого размера блоки и какой диск первый-второй. -->

 

Понятно, что аппаратный RAID быстрее…

 

=== LVM ===

=== СХД ===

* DAS --- direct attached storage --- ящик с дисками. Хранилище, которое подкл. непосредственно. DAS работает по принципу одного потребителя данных, и в случае децентрализации потребителя этого недостаточно для решения этого придумали

* SAN --- Storage Area Network

Компания NetApp предложила следующее: давайте делтаь случайную запись, но писать на диск последовательно. Что мы получили: мы получили запись быструю (потому что пишем только full-... stripe) и это очень хорошо. Но возникает проблема фрагментации. Мало того, что надо делать мэппинг, но понятно, что ни о какм префетче можно не говорить, всё врея надо перепозиц. головку. Решение тут только одно --- делать периодич. дефрагментацию. Решение делать дефр. online эта такая инж. задача, вполне себе решаемая. Теоретически эта задача разрешимая, практически её пока не решили. Есть офлайновая дефрагментация.

Поэтому среди unix-гиков он очень популярен. У него хорошаяреализация nfs, он быстрее писюка. С другой стороны, у него гламурная командная строчка, и он выгядит довольно прикольно. Из success-story --- Я.Деньги по слухам работают на них.

** Надо правильно понимать, где они нужны: если позиционирование игрвет роль, то оно актуально, там будет большой прирост. Там, где делаешь потоковую запись, то тут смысла нет.