Редактирование: UNИX, весна 2008, 04 семинар (от 30 мая)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 1: | Строка 1: | ||
- | + | '''Дамп карточки (временный):''' http://esyr.org/photo/uneex_08_05_30/ | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Что такое UNИX: это некое плавающее сообщество. Это уже третье публичное сборище. Псокольку, вопрос о том, что это за аббревиатура, обсуждался на ЛОРе, повторяться ГК не будет. | |
- | + | ЛВК --- бюджетная организация, и как это бывает, под новый год сказали, что есть полтора миллиона рублей, и их надо потратить. Поскольку списка, чего надо, не было, а места мало и пользоваатели любят хранить всякую мультимедию, то возникла потребность в хранилище. Поэтому пришлось покопаться в СХД. В связи с этим был сделан доклад в октябре 07 для студентов, здесь же изменённая версия, без простых вещей. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Попытаемся разобраться, для чего это надо, зачем хранить дланные. Для начала несколько простых вещей: | |
+ | * RAID | ||
+ | * LVM | ||
+ | Дальше рпо интерфейсы, протоколы, как это вылядит и что исопльзуется. | ||
- | + | Понятно, что данные растут, их нужно где-то зранить, при чём зхранить надо так, чтобы доступно былол из разны мест. При этом, нельзя решить, чколько надо хранилище. Сейчас нужен терабайт, потом понадобится 2, сейчас покупать 2 дорого, возникает вопрос масштабирования. Помимо этого, требуется, чтобы данные хранились надёжно, безопасно, и при этом надо этим управлять, чтобы это не было чёрной магией. Для решения этих задач сущ. специализ. системы, которые данных хранят, и потр. их иаспользования. | |
- | * | + | * Вопрос ГК: децентрализация какая? |
- | * | + | * GQ: и потр., и зранения. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Данные могут иметь очен высокую стоимость | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | * ГК: Сложность управления это что --- требование? | |
- | + | * GQ: Аспект? | |
- | + | * ГК: Njulf eghfdktybt xtv& | |
- | + | * GQ: Как только возникает децентрализация, есть сервер с данными, есть другие сервера, которые им польз. Сразу возн. вопрос, как этим управлять: правами доступа, ... | |
+ | * ивлад: Можно считать, что это проблемы: объём анных рос, сложность управления росла... | ||
- | * | + | Отказоусточивость. Делится на два аспеката: |
- | * | + | * Сохр. к сбоям |
+ | * Доступность. Возникает желание, чтобы система была доступна всегда. Нужно, чтобы не было слабого звена. | ||
+ | ** ГК: Проблема в другом --- проблема не в том, чтобы если отключили сервер, то доступ к нему пропал, а в том, что если там уже 180 потоков... Ивлад --- нет, это именно когда данные есть, а доступа нет. GQ --- например, контроллер сгорел | ||
+ | ** Юрий: Наверное, следует сразу разделить два вида неполадок --- штатные и нештатные ... | ||
- | + | При этом избыточность может быть на разных уровнях: | |
+ | * На накопителях тсандартных механиз дублирования --- использование RAID | ||
+ | ** JBOD | ||
+ | ** RAID 0 --- диски делятся на страйпы, что позв. делать паралл. чтение. Но это к отказ. не отн., поск. изб. тут нет | ||
+ | ** RAID 1 --- зеркалирование | ||
+ | ** RAID 2---4 --- коды хэмминга, хор, но контр. хранился на отд. диске и он становился боттлнеком | ||
+ | ** RAID 5---6 --- распределённый хор в 5, в 6 считается 2 взаимодополн. болка с чётностью | ||
+ | ** ivlad: в 4 рейде есть большой бонус --- при добавлении допдиска можно сказать, что он забит нулями, контр. сумма не изм и доп. телодвижений делать не надо | ||
- | + | Космбинирование уровней рейда: | |
- | * | + | * Можно сделать зеркало над страйпами или страйп над зеркалами. Понятно, что отказоустойчивость у них разная. В случае, если вылетает два диска... |
- | * | + | ** ivlad: Начнём с одного |
- | * | + | ** А в случае одного всё одинаково |
- | * | + | ** ivlad: Нееет, по-разному ... |
- | * | + | ** ... |
- | * | + | |
- | * | + | |
- | + | В случае, если вышел из строя один из дисков, то нужно как можно быстрее выйдет один диск, тонужно как можно быстрее вставить новые. Понятно, что на люжей нельзя надеяться, то используют горячий резерв. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Это один аспект отк., который отн. к сохр. данных, есть ещё аспект, отн. к дотупности. Дял этого есть техн., наз. MP. Есть ящик с дисками, он подключен к серверу. Есть порты ввода-вывода, которые подк. к серверу. Понятно, что они могут выйти из строя. Можно подключить два провода, тогда, если вылетает один, то всё равно они ост. соединены. И для того, чтобы это не требовало ркчных изм. и настройки, сущ. подсистема MP, которая для нашего сервера делает вид, что у нас одни канал данных, но на самом деле два, и можно по ним ещё нагрузку раскидывать, например. | |
- | === 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−1-ом, и так далее. В случае, если один из дисков выходит из строя, у нас всегда есть вся информация, чтобы все данные восстановить. Это называется '''RAID 5'''. Объединять можно любое количество дисков, больше или равное двум. В случае двух это mirror. RAID 6 это то же самое, только для каждой группы блоков два взаимодополняющих блока с чётностью. Соответственно, если два диска выходят из строя, то их также можно восстановить. | ||
- | ** ''ivlad'': Это ты тоже из Википедии взял? | ||
- | ** ''GQ'': Да. | ||
- | ** ''ivlad'': Тогда там фигня написана. Дело в том, что в шестом RAID parity считаются по-разному. | ||
- | ** ''GQ'': Ну да, два взаимодополняющих. | ||
- | ** ''ivlad'': Взаимонезависимых. Они ортогональны. | ||
- | ** ''GQ'': P и Q — они разные. Суммарный объём получается в одном случае (n−1)×(объём диска) (понятно, что диски должны быть одинаковые), и (n−2)×(объём диска). Собственно говоря, как я недавно обнаружил, в современном 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'': Ввод-вывод да, но в любом случае, я из того, что данные накроются. В одном случае, по-моему, <sup>1</sup>/<sub>6</sub>, в другом — <sup>1</sup>/<sub>12</sub> | ||
- | * ''ГК''(?): Я думаю, это зависит от количества дисков… | ||
- | * ''GQ'': В случае 4 дисков. На самом деле, если вышел из строя этот диск (один из дисков в RAID 0+1), и после этого второй какой-то диск выходит из строя. Если выйдет из строя этот диск (Второй диск в том же страйпе), то данные сможем вытащить, а если этот или этот (диски из другой половины зеркала) — уже нет, кроме как руками попытаться объединить оставшиеся диски, если вдруг получится. | ||
- | * ''ГК'': Потому что мы не знаем, симметричны они или нет. | ||
- | * ''GQ'': А в данном случае (RAID 10) вылетает вот этот диск (один из дисков), а после этого может вылетить этот или этот (диски в другом зеркале), и у нас всё останется, а если вылетит этот, тогда уже кирдык. | ||
- | * ''Из зала'': Так это же то же самое… | ||
- | * ''GQ'': Нет, здесь (RAID 0+1) если вылетел один диск, то вероятность, что мы потеряем данные <sup>2</sup>/<sub>3</sub> | ||
- | * ''ГК'': Просто из картинки это не следует… | ||
- | [[Изображение: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]] | ||
Ещё один, совсем коротко, про RAID-контроллеры | Ещё один, совсем коротко, про RAID-контроллеры | ||
- | * | + | * Сначала контр. были аппаратные, они делали вид, что к ним подкл. одни диск, на самом деле неск., платы стоят дорого, поск. дклаютмя для дорогих серверов |
- | + | * В какой-то момент решили делать прогрю. Рейд, понятно что он будет отнимать ресурсы системы, работать медленнее, зато это замечательно рабоатет. | |
- | + | * Лет 5---10 назад стало популрно в очень недорогие мат. платы нечто, что произв. называл аппаратным рейдом, но оно было только на уровне биоса, дальше на уровне ос это драйвера. Но оно отличается в худшую сторону. Если вышла из строя аппаратный рейл, то нужно купить точно такой же адаптер, но он стоит дорогих денег, давно не выпускается и так далее. Но в случае рейда 0 и 1 помогает dd и скрипт на шелле, достаточно знать, какого размера блоки и какой диск первый-второй. Понятно, что аппаратные работают быстрее | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | Понятно, что | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
* В СХД есть обычно свои средства | * В СХД есть обычно свои средства | ||
Строка 189: | Строка 64: | ||
D_1 + D_2 | D_1 + D_2 | ||
W(D_1) W(D_2) W(P) | W(D_1) W(D_2) W(P) | ||
- | Важно понимать патторны работы с дисками при проектировании RAID 5. Общий рецепт такой: потокавая запись очень быстрая, если full-/// stripe, | + | Важно понимать патторны работы с дисками при проектировании RAID 5. Общий рецепт такой: потокавая запись очень быстрая, если full-/// stripe, котрый модет делаться или очень большим кэшем, или операционная система видит, что длинная операция даписи, отключает кэш и все операции сразу идут на бэкенд-петлю. В случае же RAID 10 нужно синхронизировать ... . ... |
- | Ещё на умных, хороших аппаратный рейдах есть собственный кэш, собственная память для того, чтобы подобрать правильную посл. записи на диск. Во-вторых, там есть | + | Ещё на умных, хороших аппаратный рейдах есть собственный кэш, собственная память для того, чтобы подобрать правильную посл. записи на диск. Во-вторых, там есть дамечательное свойство, что после того, как данные сохранили в кэш, можно сказать ОС, что данные сохранены. В этом случае может быть пробелма, что делать, если ппитание отрубится. Обычно, для этого есть батарейка, которая позв. сохранить кэш.. |
- | + | LVM | |
- | * Не можем спланировать, сколько | + | * Не можем спланировать, сколько потр. места черз 3 года |
* Хотим home 300ГБ, а у нас два диска по 200 | * Хотим home 300ГБ, а у нас два диска по 200 | ||
- | * | + | * ИЛи сначала был один диск, а потом появился второй |
- | Для этого всего исп такую вещь, как LVM. У нас | + | Для этого всего исп такую вещь, как LVM. У нас етсь физ. устройства., например, два диска по 200, разбили их на 100+100 и 200, над ними указываем группы томов: sda1 и sda2+sdb1, над группами можно создать виртуальные тома. |
* Юрий: а зачем выделять группы? | * Юрий: а зачем выделять группы? | ||
- | Дальше уже выделяем | + | Дальше уже выделяем место под рут/юср/вар |
- | * ГК: я ничего не понял про то, где тут масштабируемость. Из | + | * ГК: я ничего не понял про то, где тут масштабируемость. Из данной пробелмы понятно, как решается |
* GQ: изначально выделяется по 5 гигабайт, потом увеличить тома можно, и оно изменит размер online | * GQ: изначально выделяется по 5 гигабайт, потом увеличить тома можно, и оно изменит размер online | ||
* ivlad: И это фрагментируется? | * ivlad: И это фрагментируется? | ||
- | * GQ: да, возникает | + | * GQ: да, возникает пробелма фрагментации |
* ... | * ... | ||
Далее, если купили терабайт и хотим выкинуть два по 200, то подключаем терабайт, говорим мигрировать, и отключаем старые | Далее, если купили терабайт и хотим выкинуть два по 200, то подключаем терабайт, говорим мигрировать, и отключаем старые | ||
Строка 214: | Строка 89: | ||
Свойства | Свойства | ||
- | * | + | * Снэпшоты. Хотим получим копию лог. тома, чтобы он был консистентен по времени. Для этого созд. снапшот (на самом деле, никакого копирования не проих, заводится метаинф). Если что-то пишем, то созраняем и то, и то. |
* Юрий: ... | * Юрий: ... | ||
* ivlad: ... | * ivlad: ... | ||
- | * ivlad: ещё более интересная ситуация, когда надо сделать снэпшот сырого диска. | + | * ivlad: ещё более интересная ситуация, когда надо сделать снэпшот сырого диска. Произв. ... публикуют интерфейсы, которые позв. делать снэпшот тейблспейса, и оракл дальше пишет в лог(?) ... но это решение на уровне приложения |
- | + | СХД | |
- | * DAS --- | + | * DAS --- dirrect attached storage --- ящик с дисками. Хранилище, которое подкл. непосредственно. DAS работает по принципу одного потребителя данных, и в случае децентр. потр. этого недостаточно для решения этого придумали |
- | * NAS --- ящик, к которому | + | * NAS --- ящик, к которому подкл. по сети и работает с ним |
- | * SAN --- | + | * SAN --- ... |
DAS | DAS | ||
* Работают по стандартным интерфейсам | * Работают по стандартным интерфейсам | ||
- | * Предст. либо RAW диски, либо иногда | + | * Предст. либо RAW диски, либо иногда КФШв? yj 'nj dc` ghjcnj |
NAS | NAS | ||
- | * Стандартные помойки, которые | + | * Стандартные помойки, которые подкл. по HTTP, FTP, NFS... |
** ГК: а это только файл-ориентированные доступ? | ** ГК: а это только файл-ориентированные доступ? | ||
** Да. | ** Да. | ||
SAN | SAN | ||
- | * Даёт доступ до блочного пространства (блочная семантика) и ничто не запрещает нам иметь доступ одновременно к одному блочному | + | * Даёт доступ до блочного пространства (блочная семантика) и ничто не запрещает нам иметь доступ одновременно к одному блочному устр. с неск. потреб. |
- | * В | + | * В кач. физ. инт. исп. лиюо Eth либо IP, самое быстрое и вкусчсоне это FC |
- | ** iSCSI --- | + | ** iSCSI --- |
- | ** FC --- | + | ** FC --- hish-end --- специальная технология для постр. сетей с высокой проп. способ. и низк. латент. В первую очередь FC исп в СХД. Обычно исп. оптоволокно, но можно и медь. В качестве протокола исп. FCP --- инкапсуляция низк. протокола SCSI. При этом в принципе можно исп. разл. топологии: точка-точка, каждый с каждым, switched fabric --- топология, когда есть неск. устройств, которые называются Fibre Channel Switch, они как-то соединены, мы нашего потр. подкл. к этой сети и поставщика данных, и как-то по этой сети до этих данных можнем достучаться, там досттаточно интересные способы маршрутизации, и с изб. там всё хорошо; ещё одна топология --- кольцо с арбитром. |
- | ** ivlad: фабрика устроена достаточно сложно, там свои | + | ** ivlad: фабрика устроена достаточно сложно, там свои ... |
== Подключение СХД == | == Подключение СХД == | ||
Строка 250: | Строка 125: | ||
** Из зала: есть ещё FATA --- ATA, к которому присобачен FC | ** Из зала: есть ещё FATA --- ATA, к которому присобачен FC | ||
- | == | + | == Ghbvth C{L == |
- | Та хрень, которая у нас в итоге применяется, это | + | Та хрень, которая у нас в итоге применяется, это СДФКшшЩТ 150 с двумя процессорами и И/П |
В итоге выглядит это вот так вот: | В итоге выглядит это вот так вот: | ||
- | * ivlad: в случае отказа может выйти из строя вся фабрика, поэтому делают две фабрики, но здесь | + | * ivlad: в случае отказа может выйти из строя вся фабрика, поэтому делают две фабрики, но здесь вырожд. случай. |
Крутится это на виндах ... | Крутится это на виндах ... | ||
Строка 260: | Строка 135: | ||
* ivlad: для чего на самом деле покупаются подобные системы | * ivlad: для чего на самом деле покупаются подобные системы | ||
- | PowerPath: умеет гонять служебные данные (пинг) по неактивному пути, для проверки, можно на него | + | PowerPath: умеет гонять служебные данные (пинг) по неактивному пути, для проверки, можно на него перекл или нет. |
- | В любом случае, | + | В любом случае, исп. ядерный модуль не могули, потому что Debian, а не RHEL/SLES/CentOS, и кроме того, исп. Xen. |
- | Эти самые FC-свичи это не совсем тупая вещь, в случае, когда 1 сервер, 1 хранилище, нет | + | Эти самые FC-свичи это не совсем тупая вещь, в случае, когда 1 сервер, 1 хранилище, нет необх. кому-то что-то запрещать, но когда есть несколько серверов и хранилищ, то нужно делать нечто аналогичное VLSN, в FC это называется зонинг. И несмотря на то, что инженеры говорили, что втыкаешь --- всё работает, то через свичи не работает. Оказалось, что зонинг включён и он ... |
== Enterprise-решения == | == Enterprise-решения == | ||
Строка 320: | Строка 195: | ||
Вообще говоря, избыточность может быть любой, m+n, что позволяет пережить m отказов. Но по скорости он сосёт, псокольку уже дя R6 нужно собирать квадрат, и при случайной записи надо собрать квадрат, и скорость проседает, что можно решать кэшом. Но большие кэши это техн. сложно. | Вообще говоря, избыточность может быть любой, m+n, что позволяет пережить m отказов. Но по скорости он сосёт, псокольку уже дя R6 нужно собирать квадрат, и при случайной записи надо собрать квадрат, и скорость проседает, что можно решать кэшом. Но большие кэши это техн. сложно. | ||
- | Компания | + | Компания ... предложила следующее: давайте делтаь случайную запись, но писать на диск последовательно. Что мы получили: мы получили запись быструю (потому что пишем только full-... stripe) и это очень хорошо. Но возникает проблема фрагментации. Мало того, что надо делать мэппинг, но понятно, что ни о какм префетче можно не говорить, всё врея надо перепозиц. головку. Решение тут только одно --- делать периодич. дефрагментацию. Решение делать дефр. online эта такая инж. задача, вполне себе решаемая. Теоретически эта задача разрешимая, практически её пока не решили. Есть офлайновая дефрагментация. |
- | Поэтому среди unix-гиков он очень популярен. У него хорошаяреализация nfs, он быстрее писюка. С другой стороны, у него гламурная командная строчка, и он выгядит довольно прикольно. Из success-story --- Я.Деньги | + | Поэтому среди unix-гиков он очень популярен. У него хорошаяреализация nfs, он быстрее писюка. С другой стороны, у него гламурная командная строчка, и он выгядит довольно прикольно. Из success-story --- Я.Деньги работают на них. У EMC работает на них биллинг у МТС. |
У R6 есть разные подсчёты второй parity. | У R6 есть разные подсчёты второй parity. | ||
Строка 329: | Строка 204: | ||
** Уже сейчас можно купить Symmetrix с SSD | ** Уже сейчас можно купить Symmetrix с SSD | ||
** Плюсы и минусы SSD: операции записи ползут. | ** Плюсы и минусы SSD: операции записи ползут. | ||
- | ** Надо | + | ** Надо прапильно понимать, где они нужны: если позиционирование игрвет роль, то оно актуально, там будет большой прирост. Там, где делаешь потоковую запись, то тут смысла нет. |
** В чём отличия при исп.: не сбрасывают кэш, поск. отсут. статистика по отказам | ** В чём отличия при исп.: не сбрасывают кэш, поск. отсут. статистика по отказам | ||