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

Материал из eSyr's wiki.

Что такое 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-контроллеры

• Сначала контр. были аппаратные, они делали вид, что к ним подкл. одни диск, на самом деле неск., платы стоят дорого, поск. дклаютмя для дорогих серверов
• В какой-то момент решили делать прогрю. Рейд, понятно что он будет отнимать ресурсы системы, работать медленнее, зато это замечательно рабоатет.
• Лет 5---10 назад стало популрно в очень недорогие мат. платы нечто, что произв. называл аппаратным рейдом, но оно было только на уровне биоса, дальше на уровне ос это драйвера. Но оно отличается в худшую сторону. Если вышла из строя аппаратный рейл, то нужно купить точно такой же адаптер, но он стоит дорогих денег, давно не выпускается и так далее. Но в случае рейда 0 и 1 помогает dd и скрипт на шелле, достаточно знать, какого размера блоки и какой диск первый-второй. Понятно, что аппаратные работают быстрее
• В СХД есть обычно свои средства

У рейд 5 есть большой недостаток --- для записи 1 байта приходится прочитать два блока, чтобы вычислить блок чётности.

• ivlad: Для записи требуется:

R(D), R(P)
P - D
D_n + P
W(P), W(D_n)

Если надо прочитать D_1 + D_2

D_1 + D_2
W(D_1) W(D_2) W(P)

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

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

LVM

• Не можем спланировать, сколько потр. места черз 3 года
• Хотим home 300ГБ, а у нас два диска по 200
• ИЛи сначала был один диск, а потом появился второй

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

• Юрий: а зачем выделять группы?

Дальше уже выделяем место под рут/юср/вар

• ГК: я ничего не понял про то, где тут масштабируемость. Из данной пробелмы понятно, как решается
• GQ: изначально выделяется по 5 гигабайт, потом увеличить тома можно, и оно изменит размер online
• ivlad: И это фрагментируется?
• GQ: да, возникает пробелма фрагментации
• ...

Далее, если купили терабайт и хотим выкинуть два по 200, то подключаем терабайт, говорим мигрировать, и отключаем старые

Логические тома

• Физ. том
• Группа лог. томов
• Лог. том

Свойства

• Снэпшоты. Хотим получим копию лог. тома, чтобы он был консистентен по времени. Для этого созд. снапшот (на самом деле, никакого копирования не проих, заводится метаинф). Если что-то пишем, то созраняем и то, и то.
• Юрий: ...
• ivlad: ...
• ivlad: ещё более интересная ситуация, когда надо сделать снэпшот сырого диска. Произв. ... публикуют интерфейсы, которые позв. делать снэпшот тейблспейса, и оракл дальше пишет в лог(?) ... но это решение на уровне приложения

СХД

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

DAS

• Работают по стандартным интерфейсам
• Предст. либо RAW диски, либо иногда КФШв? yj 'nj dc` ghjcnj

NAS

• Стандартные помойки, которые подкл. по HTTP, FTP, NFS...
  • ГК: а это только файл-ориентированные доступ?
  • Да.

SAN

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

Содержание 1 Подключение СХД 2 Типы дисков, исп. в СХД 3 Ghbvth C{L 4 Enterprise-решения

Подключение СХД

Следующий вопрос, как система подкл. к потреб. Если у нас инкапс. SCSI over IP, то можно прогр. решение организовать, в принципе, для SCSI исп. карточки, которые наз. host bus adapteer. В системе они видны как контроллеры, а диски, которые доступны с SAN, видны как разные SCSI-диски.

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

Типы дисков, исп. в СХД

• В NAS/DAS --- IDE-SCSI-SATA-SAS
• В SAN исп. в дешёвых SATA, в подороже либо SAS, либо FC, они работают по FCP
  • Из зала: есть ещё FATA --- ATA, к которому присобачен FC

Ghbvth C{L

Та хрень, которая у нас в итоге применяется, это СДФКшшЩТ 150 с двумя процессорами и И/П

В итоге выглядит это вот так вот:

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

Крутится это на виндах ...

Процессорам в итоге видны 8 томов, которые объединены линуксовым MP, у EMC есть свои драйвера, но вот ...

• ivlad: для чего на самом деле покупаются подобные системы

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

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

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

Enterprise-решения

Понятно, что можно поставить писюк, поставить харды, и всё настроить. Но в этом случае нужно всё настраивать руками, тут необзодимо добиваться произв, и так далее.

Вопросы:

• Балансировка --- осущ. dev. mapper ---
  • ivlad: ... В системах нач. уровня только так и делается, в более крутых системах может осущ дин. нагрузка, ...

ivlad:

Речь в итоге идёт о деньгах. Домашние решения против вендорских. Понятно, что вендорские будут дороже. Но люди, которые их покупают, полагаются, вот на что:

• Всё завязывается на людей. Если человек собрал решение, то на него всё завязывается, в случае с вендором это перекладывается на вендора.

• GQ: Говорят, что диски, которые в кларионах, тестируются неск. дней в гермокамерах
• ivlad: так и есть, потому они таких денег и стоят
• GQ: и они несовместимы с другими...
• ivlad: да, и это понятно,почему. Как минимум, нои отформатированы под 520, а не 512 байт. ... В итоге, тут нет ни одной критичной точки, во вторых, ошибки обнаруживаются до того, как они станут критичными.

Symmetrix: там всего по много и всё симметрично.

Есть фронтэнд процессоыр (до 16), етсь кэши (по 256G), есть бэкенды (до 16),

Каждый диск обслуживается как минимум двусмя процессорами. В таком случае балансировка сделается более эффективной. Тут можно играться с QoS.

Потоковая запись происходит совсем по-разному. Кларион, когда видит, что поток, он ничего не пишет в кэш, он сразу пишет на диск. Если дисков много, то такую операцию выгодно делать. А в случае симметрикса, топология такова, что кэш пробить нельзя, и работать он всё равно будет работать черз кэш. И вопросы произв. не то, чтобы оченнь сложные, но очень много тонких моментов. Нужно подобрать такой паттерн, чтобы забить 256Г кэша, то будет скорость работы с дисками. Если писать только на опр. диски

Префетч: бывет выгодно прочитать вместе с 3 блоком 4,5,6,7 и 8. Прочитав в кэш, мы натыкаемся на баланс, мы с одной стороны забиваем кэш и замедл. запись, но с другой стороны ускоряем чтение, если угодали.

Поэтому от адм. стораджа требуется внимание к тому, какие паттерны в его системе.

В симметриксе есть специальная тулза для performance monitoring. В Симметриксе он даже может автоматически решить задачу по некоторым метрикам так, чтобы произв. повысилась. В кларионе эта задача ложится на администратора.

• Вопрос: вы сказали про рейд 5 из 15 дисков, там что, действительно 14+1?
• ivlad: да
• Но это понижает надёжность
• Да, здесь вопрос в балансе

...

Вообще гворя, все конструкции по поводу постр. дисков, постр. рейдов...

Если вернутьтся от 5 рейда до 6, то в 6 считаются две чексуммы --- одна поперёк, вторая диагонально. Пример на 5 дисках:

Что здесь хорошо: чёткость размазана и всё работает при выходе из строя двух дисков.

Как работает parity в RAID5: P = d1 xor d2.

Когда К6 стал актуален --- когда диски стали настолько большие, что вероятность вылета второго диска во время ребилда стала актуальной.

Распространённая ситуация на тот момент: интерфейс хоста --- для FC на тот момент 1Гбит, будем считать что это 100МБайт. Если надо ребилднуть 100-гиговый диск, то 1000 секунд, если учеть реальную эффективность, то это порядка 1/8 суток. Плюс реальная нагрузка бегает...

В кларионах диск ребилдится сутки. Кларион может поставить приоритет на процесс ребилда.

Вообще говоря, избыточность может быть любой, m+n, что позволяет пережить m отказов. Но по скорости он сосёт, псокольку уже дя R6 нужно собирать квадрат, и при случайной записи надо собрать квадрат, и скорость проседает, что можно решать кэшом. Но большие кэши это техн. сложно.

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

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

У R6 есть разные подсчёты второй parity.

• Вопрос: про SSD
  • Уже сейчас можно купить Symmetrix с SSD
  • Плюсы и минусы SSD: операции записи ползут.
  • Надо прапильно понимать, где они нужны: если позиционирование игрвет роль, то оно актуально, там будет большой прирост. Там, где делаешь потоковую запись, то тут смысла нет.
  • В чём отличия при исп.: не сбрасывают кэш, поск. отсут. статистика по отказам

Паттерн работы с БД: записи накапливаются в лог потом оно