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

* '''Докладчик:''' Александр Герасёв

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

* '''Дамп карточки (временный):''' http://esyr.org/photo/uneex_08_05_30/

* '''Презентация:''' [[:Изображение:Storage.odp|ODP]], [[:Изображение:Storage.pdf|PDF]]

* '''Презентация с комментариями на основе конспекта (in progress):''' [[:Изображение:Storage_commented.odp|ODP]], [[:Изображение:Storage_commented.pdf|PDF]]

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

Изображение:Uneex 08 05 30 frbrgeorge.jpg|Георгий Курячий (ГК)

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

<div class="comment">''ГК'': Давай мы сделаем маленькое объявление, я тут вижу много разного народу, некоторые знакомые лица, некоторые — нет. Что такое UNИX: эта аббревиатура имеет отношение к некоторому плавающему собранию людей, непрерывно обновляемому. Я так думаю, что некоторые из здесь присутствующих просто не знают о существовании этого мероприятия по причине того, что последние года два оно не проводилось вообще: последний семинар был ровно два года назад из тех, что проводились давно. Задача очень простая — делиться информацией в режиме реального времени. Я сказал, что сообщество плавающее, одно время я был активным инициатором этого безобразия, потом работа меня съела и появились студенты ответственные, которые взяли на себя всю организационную часть. Это уже третье публичное сборище. Я не знаю, сколько мы выдержим стиль две недели летом, следите за объявлениями. Поскольку, вопрос о том, что означает эта аббревиатура, обсуждался на ЛОРе, повторяться я не буду.</div>

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

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

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

Попытаемся разобраться, для чего это надо, зачем хранить данные, откуда всё это взялось. Для начала несколько простых вещей, которые, тем не менее необходимы:

* Что такое RAID

* Про СХД, какие они бывают, какие там интерфейсы, протоколы используются, как всё это выглядит. В частности, расскажу, как мы это используем

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

Понятно, что данных много, они всё время растут, их надо где-то хранить, при чём хранить надо так, чтобы они были доступну было из разны мест. При этом, мы не можем сразу решить, какой необходим объём дискового хранилища: сейчас нужен терабайт, через год надо будет два терабайта, сразу покупать 2 терабайта бессмысленно и дорого, поэтому возникает задача масштабирования, в итоге всё упирается в вопрос денег — мы не сразу можем приобрести большое хранилище. Помимо этого, требуется, чтобы данные хранились надёжно, безопасно, и чтобы всем этим можно было как-то управлять так, чтобы это не было чёрной магией. Для решения этих задач используют специализированные системы, которые занимаются как раз тем, что хранят данные, и дальше есть всевозможные потребители этих данных, которые их по-разному используют.

* ''ГК'': Децентрализация чего: пользования или хранения?

* ''GQ'': В принципе, возникает децентрализация и потребителей, и хранилищ

Отдельно отметим пункт с надёжностью, поскольку данные имеют очень высокую стоимость: это могут быть финансовые данные, данные по проектам, которые выполняются для того дяди, и если всё накроется, будет очень грустно.

* ''GQ'': Нет, это различные аспекты, на которые нам приходится обращать внимание, почсему, собственно, у нас возникают такие специализированные системы, системы хранения данных

* ''ГК'': Про данные я понимаю, про задачи децентрализации хранения и потребеления я понимаю. А вот… чем управления? Нечем управлять: просто свалка и всё, зачем ей управлять?

* ''GQ'': Как только возникает децентрализация, есть сервер к которому подключен жёсткий диск, есть другие сервера, которые хотят использовать эти данные, которые хранятся централизованно на этом сервере. Сразу возникает вопрос, как этим управлять: как управлять правами доступа, как настраивать этот доступ… Поэтому, одна из задач создания специализированных СХД — решение этого вопроса, то есть снижение сложности управления такими…

* ''ivlad'': Можно считать, что это проблемы до того, как специализированную СХД купили: объём данных рос, сложность управления росла...

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

** ''ГК'': Проблема в другом — проблема не в том, чтобы случайно выключится какой-то сервер, который потом не отдаст данные, хотя это тоже. Проблема в том, чтобы данные были доступны в режимное время, при том, что 180 потоков уже идут. То есть, есть неки график потребления…

** ''ivlad'', ''GQ'': Нет.

** ''ivlad'': Проблема в том, что данные, как таковые, целостные, а доступа к ним по какой-то причине нет

** ''GQ'': Например, сгорел порт на сервере, к которому подключена СХД. Сервер есть, данные есть, доступа к ним нет

** ''Юрий'': Вопрос по поводу отказоустойчивости, возможно, необходимо разделить постановку. Есть вопросы, связанные с отказом оборудования, это нештатные ситуации. И здесь вопрос отказоустойчивости — обеспечить максимально возможный доступ к данным за какое-то разумное время. В частности, система бэкапов может быть тоже системой обеспечения отказоустойчивости.

** ''ivlad'': Нет. Бэкапы обеспечивают сохранность данных.

** ''Юрий'': Ну, скажем, так, не средства бэкапа, а средства восстановления данных из бэкапа

** ''Юрий'': Я хотел бы разделить два вида отказов: отказ, связанный с нештатной ситуации работы оборудования и ПО, и есть отказы вида штатной работы: когда всё есть, все программы работают, а вот доступа к данным нет

** ''GQ'': Можно, всё-таки конкретизирую. У нас есть в лаборатории люди, которые занимаются отказоустойчивостью. На самом деле, с точки зрения теории, есть понятие ''неисправности'' — это когда что-то где-то не работает. Неисправность может приводить к ошибке. Ошибка — обнаруженная неисправность, которую система обнаружила. А ''отказ'' — такая ошибка, которую мы никак не можем предотвратить или исправить, которая приводит к тому, что система перестаёт выполнять те требования, которые на неё наложены. Собственно, отказ, это когда система перестаёт работать.

** ''Юрий'': Так вот, дублирование узлов, избыточность и так далее — к какому виду избыточности это относится? Дублирование узлов используется, когда целиком узлы дублируются, это обеспечение доступности. А избыточность обычно для задач сохранности данных.

При этом избыточность может применяться на разных уровнях.

=== RAID ===

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

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

<gallery>

Изображение:Uneex 08 05 30 slide7.png|JBOD

Изображение:Uneex 08 05 30 slide8.png|RAID 0, RAID 1

Изображение:Uneex 08 05 30 slide9.png|RAID 3, RAID 4

Изображение:Uneex 08 05 30 slide10.png|RAID 5, RAID 6

</gallery>

В базовом случае, когда речь идёт именно о самих накопителях, на которых хранятся данные — использование технологии RAID. Что такое RAID, все знают, подробно про это объяснять не надо.

* '''JBOD''' (Just Bunch Of Disks). Есть просто много дисков, разных размеров, а надо одно большое пространство, мы все вместе объединяем и получается один виртуальный диск большого размера

** ''ivlad'': Ты как-то подменяешь понятие, как мне кажется. JBOD это полка с дисками, которая не несёт в себе никакого интеллекта. Если есть 14 дисков, они как 14 дисков видны хосту. В отличие от более полноценной системы RAID, когда эти 14 дисков видны как-то по-другому, и над ними появляется какая-то логика

** ''GQ'': Значит, мы в терминологии немного расходимся, то, что я читал, там всё-таки JBOD это…

** ''ivlad'': Если объединяем все диски в один поток, то это конкатенация, concat. Solaris Disk Suite мы презренно отметаем сейчас.

: Понятно, что объединять много дисков последовательно неинтересно, потому что когда данные читаются, они читаются последовательно, и всё читается с одного диска

* Но дисков много, их можно читать параллельно. Тогда и придумали '''RAID 0''', когда диски делятся на страйпы, и подряд идущие данные лежат часть на одном, часть на другом, на третьем, и так далее. Это к обеспечению отказоустойчивости никак не относится, поскольку избыточности там нет никакой. Избыточность появляется дальше.

* Полное зеркалирование всех данных. Это '''RAID 1'''.

* Дальше начали применять коды Хэмминга (RAID 2). Когда есть несколько дисков, можно данные так распределить, чтобы избыточность образовалась.

* Сейчас наиболее используемые RAID 5—6, где данные блоками распределены между несколькими дисками

** ''ivlad'': Все знают, что такое RAID? Кто не знает?

** ''Из зала'': Я не знаю, что такое RAID 5 и RAID 6. Всю свою несознательную жизнь я использовал 0+1. [[Image:Uneex 08 05 30 raid 0+1 man.jpg|thumb|Человек из зала, использующий RAID 0+1]]

** ''ivlad'': Замечательно. На самом деле не факт, что она несознательная…

** ''ГК'': А то есть мнение, что «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'': Это ты тоже из Википедии взял?

** ''GQ'': Да.

** ''ivlad'': Тогда там фигня написана. Дело в том, что в шестом RAID parity считаются по-разному.

** ''GQ'': Ну да, два взаимодополняющих.

** ''ivlad'': Взаимонезависимых. Они ортогональны.

** ''GQ'': P и Q — они разные. Суммарный объём получается в одном случае (n&minus;1)&times;(объём диска) (понятно, что диски должны быть одинаковые), и (n&minus;2)&times;(объём диска). Собственно говоря, как я недавно обнаружил, в современном Linux RAID 5 и RAID 6 удачно масштабируются, то есть можно добавить ещё один диск, сказать «измени-ка мне RAID 5, чтобы он был не из 4 диско, а из 5»

** ''ГК'': Он будет долго мучиться…

** ''GQ'': Да, он будет долго мучиться, двое суток, а потом объём увеличится.

** ''ivlad'': У 4-го RAID есть небольшое достоинство, когда к нему диски добавляешь: дело в том, что по умолчанию у четвёртого RAID при добавлении нового диска считается, что он заполнен нулями. Поскольку контрольная сумма плюс ноль есть контрольная сумма, то общая контрольная сумма у тебя не изменяется, и ничего делать не надо, и это есть большой бонус.

=== Комбинирование уровней RAID ===

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

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

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

Соответственно, уровни можно замечательно комбинировать. Классический пример: можно построить страйп, и поверх страйпа пустить зеркало, а можно построить зеркало, а поверх зеркала пустить страйп. Все понимают, какой из вариантов более отказоустойчивый? Есть люди, которые не могут ответить?

* ''ГК'': Нет, ты расскажи, расскажи

В случае, если вылетает два диска подряд, какая вероятность, что данные накроются?

* ''ivlad'': Почему у меня должны вылетить два диска подряд? Давай с начала разберёмся с ситуацией с одним диском.

* ''GQ'': Нет, если вылетает один диск, то всё замечательно. От одного диска…

* ''ivlad'': Когда вылетает один диск, на самом деле, всё не замечательно. Мы можем разобрать эти две ситуации: со страйпом над зеркалами и зеркалом над страйпами. И посмотри, пожалуйста, внимательно. Если у тебя вылетает в первом случае один диск, то у тебя целиком выходит из строя весь нулевой RAID, и это значит, что весь дисковый ввод-вывод у тебя упадёт на вторую половину зеркала, первую половина зеркала у тебя ... целиком. Если у тебя у тебя страйп над миррорами, то у тебя отвалился только один маленький миррор, и всё остальное дисковое I/O во всех остальных случаях у тебя будет размазано по паре

* ''GQ'': Ввод-вывод да, но в любом случае, я из того, что данные накроются. В одном случае, по-моему, ¹/₆, в другом — ¹/₁₂

* ''ГК''(?): Я думаю, это зависит от количества дисков…

* ''GQ'': В случае 4 дисков. На самом деле, если вышел из строя этот диск (один из дисков в RAID 0+1), и после этого второй какой-то диск выходит из строя. Если выйдет из строя этот диск (Второй диск в том же страйпе), то данные сможем вытащить, а если этот или этот (диски из другой половины зеркала) — уже нет, кроме как руками попытаться объединить оставшиеся диски, если вдруг получится.

* ''ГК'': Потому что мы не знаем, симметричны они или нет.

* ''GQ'': А в данном случае (RAID 10) вылетает вот этот диск (один из дисков), а после этого может вылетить этот или этот (диски в другом зеркале), и у нас всё останется, а если вылетит этот, тогда уже кирдык.

* ''Из зала'': Так это же то же самое…

* ''GQ'': Нет, здесь (RAID 0+1) если вылетел один диск, то вероятность, что мы потеряем данные ²/₃

* ''ГК'': Просто из картинки это не следует…

[[Изображение:Uneex 08 05 30 01.jpg|thumb|240px|Владимир Иванов рассказывает про разницу между RAID 0+1 и RAID 10]]

* ''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 быстрее…

 

Важно понимать патторны работы с дисками при проектировании RAID 5. Общий рецепт такой: потокавая запись очень быстрая, если full-/// stripe, который может делаться или очень большим кэшем, или операционная система видит, что длинная операция записи, отключает кэш и все операции сразу идут на бэкенд-петлю. В случае же RAID 10 нужно синхронизировать ... . ...

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

=== LVM ===

* Не можем спланировать, сколько потребуется места через 3 года

* Или сначала был один диск, а потом появился второй

Для этого всего исп такую вещь, как LVM. У нас есть физ. устройства, например, два диска по 200, разбили их на 100+100 и 200, над ними указываем группы томов: sda1 и sda2+sdb1, над группами можно создать виртуальные тома.

Дальше уже выделяем root/usr/var

* ГК: я ничего не понял про то, где тут масштабируемость. Из проблемы понятно, как решается

* GQ: да, возникает проблема фрагментации

* Snapshot. Хотим получим копию логического тома, чтобы он был консистентен по времени. Для этого создаётся снэпшот (на самом деле, никакого копирования не происходит, заводится метаинформация). Если что-то пишем, то сохраняем и то, и то.

* ivlad: ещё более интересная ситуация, когда надо сделать снэпшот сырого диска. Производители ... публикуют интерфейсы, которые позволяют делать снэпшот тейблспейса, и оракл дальше пишет в лог(?) ... но это решение на уровне приложения

=== СХД ===

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

* NAS --- ящик, к которому подключаются по сети и работает с ним

* SAN --- Storage Area Network

* Предст. либо RAW диски, либо иногда RAID, но это всё просто

* Стандартные помойки, которые подключаются по HTTP, FTP, NFS...

* Даёт доступ до блочного пространства (блочная семантика) и ничто не запрещает нам иметь доступ одновременно к одному блочному устройству с нескольких потребителей

* В качестве физического интерфейса используется либо Ethernet либо IP, самое быстрое и вкусное это Fibre Channel

** iSCSI --- инкапсуляции SCSI команд в IP сети

** FC --- high-end --- специальная технология для построения сетей с высокой пропускной способностью и низк. латент. В первую очередь FC исп в СХД. Обычно используется оптоволокно, но можно и медь. В качестве протокола используется FCP --- инкапсуляция низк. протокола SCSI. При этом в принципе можно использовать различные топологии: точка-точка, каждый с каждым, switched fabric --- топология, когда есть несколько устройств, которые называются Fibre Channel Switch, они как-то соединены, мы подключаем потребителя и поставщика данных к этой сети, и как-то по этой сети до этих данных можно достучаться, там достаточно интересные способы маршрутизации, и с избыточностью там всё хорошо; ещё одна топология --- кольцо с арбитром.

** ivlad: фабрика устроена достаточно сложно, там свои алгоритмы маршрутизации, всё это очень интересно..

== Пример СХД ==

Та хрень, которая у нас в итоге применяется, это EMC Clarion AX150 (но под брендом Aquarius) с двумя процессорами и И/П

* ivlad: в случае отказа может выйти из строя вся фабрика, поэтому делают две фабрики, но здесь вырожденный случай.

PowerPath: умеет гонять служебные данные (пинг) по неактивному пути, для проверки, можно на него переключиться или нет.

В любом случае, использоывать ядерный модуль мы не могли, потому что Debian, а не RHEL/SLES/CentOS, и кроме того, использовался Xen.

Эти самые FC-свичи это не совсем тупая вещь, в случае, когда 1 сервер, 1 хранилище, нет необходимости кому-то что-то запрещать, но когда есть несколько серверов и хранилищ, то нужно делать нечто аналогичное VLAN, в FC это называется зонинг. И несмотря на то, что инженеры говорили, что втыкаешь --- всё работает, то через свичи не работало. Оказалось, что зонинг включён по умолчанию, и он блокировал всё.

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

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

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

<div class="comment">Тюнить работу с дисками можно вечно, как PS1 в баше.</div>