Менеджеры томов - часть 1 общие принципы

Основной задачей менеджеров томов (Volume Managers, VM) является расширение возможностей подсистемы управления дисками сервера. В стеке протоколов операционной системы они обычно встраивается между драйверами SCSI и файловой системой. Поэтому верхние уровни ОС воспринимают тома, формируемые Volume Manager, как обычные жесткие диски, напрямую подключенные к серверу. Их можно использовать и в качестве сырых устройств.

Базовым элементом, на котором строится вся конфигурация, является LUN дискового массива. Обращаю ваше внимание, что ни операционная система, ни менеджер томов ничего не знают о способе подключения дискового массива или используемых уровнях RAID. Более того, в документации на Volume Manager могут даваться рекомендации, не совместимые с используемой конфигурацией комплекса хранения данных. Потому решаясь на использование VM, системный администратор должен иметь полную информацию о характеристиках нагрузки приложений и четко осознавать все плюсы и минусы, которые он получит при использовании этого промежуточного ПО. Неграмотное использование Volume Manager может очень сильно ухудшить производительность доступа к ресурсам хранения. В случае сомнений, следует провести дополнительные исследования на тестовых системах.

В базовые операции, поддерживаемые большинством VM, входят:

• разделение (partitioning) LUN на логические тома меньшего размера
• объединение (aggregation) нескольких LUN в тома большего размера
• организация защиты данных посредством RAID
• распределение (distribution) нагрузки между несколькими LUN за счет страйпинга (striping)

Все эти операции поддерживаются любыми современными дисковыми массивами (неинтеллектуальные полки JBOD в данном документе я не рассматриваю). Естественно, что на уровне массива такие действия не потребляют ресурсов сервера и требуют значительно меньших усилий по управлению. В тоже время, возможности распределения нагрузки между несколькими дисковыми массивами, а также их контроллерами, в некоторых случаях позволяют улучшить производительность доступа к данным.

При использовании Volume Manager с дисковыми массивами следует придерживаться следующих достаточно жестких запретов:

• Никогда не использовать VM для организации parity RAIDs (RAID 3, RAID 5 и RAID 6)
• Никогда не использовать VM для страйпинга LUNs из одной и той же RAID Group дискового массива
• Никогда не делать размер VM stripe element меньше LUN stripe дискового массива
• Воздержаться от использования VM для страйпинга LUNs на RAID Groups различных типов RAID, размеров stripe elements или с различным количеством дисков. Устранение неполадок, а также анализ и настройка производительности в таких системах может стать настоящим кошмаром.

Часть 2 о Plaids

Заметки на полях (файловые системы)

• Буферизация файловых систем является одной из причин небольших значений hit on reread.
• Некоторые системы, например, VxFS или AIX, реализуют механизм предшествующего чтения (Read-ahead). Это приводит к увеличению Request Size на чтение.
• В NTFS любые IO больших размеров все равно передаются блоками по 512K.
• Если NTFS переформатирована с экстентами не-default размера, то дефрагментировать ее уже нельзя (добавлено:  гуру утверждают, что давно можно).

Уровень файловых систем

На уровне файловой системы последовательный поток байтов, следующий от приложения, организуется в блоки. Именно здесь определяются нижняя и верхняя границы Request Size.

Минимально возможный Request Size задается размером блока файловой системы. Правда, в некоторых системах метаданные могут записываться порциями меньшими, чем размер блока, но их общий объем не велик и обычно не влияет на характер I/O. Размер блока зависит от типа и параметров файловой системы. Он обычно задается одним из трех способов:

• Фиксированный размер, по умолчанию или заданный явно при создании файловой системы. Например, default block size в Solaris UFS = 8K.
• Фиксированный размер, определяемый по величине создаваемой файловой системы (file system size). Так в NTFS при размерах тома 513MB - 1,024GB block size = 1KB, при 1,025GB – 2GB block size = 2KB, а при 2 – 4GB block size = 4KB.

Многие файловые системы поддерживают оба способа, например, при создании ext2 можно либо явно задать размер блока 1KB, 2KB или 4KB (mke2fs –b), либо позволить утилите mk2fs самой определить требуемый block size, исходя из величины файловой системы (по умолчанию).

• Размер, динамически изменяемый в процессе записи данных на файловую систему. Например, ZFS в зависимости от текущих параметров ввода-вывода позволяет записывать данные блоками различных размеров (до 128KB).

При настройке block size не стоит забывать, что все файловые системы буферизуют данные в системной области оперативной памяти сервера. Поэтому больший размер блока приведет к уменьшению объема RAM, доступного для приложений.

Несколько последовательных блоков в буфере могут быть объединены в единый запрос. Каждая файловая система имеет параметр, определяющий, какое максимальное количество блоков может быть объединено. Зная этот параметр, мы можем легко вычислить максимальный размер запроса к дисковому массиву. Например, если файловая система позволяет объединять не более 128 блоков размером 8KB, то максимальный размер Request Size равен 1MB (128 * 8KB).

Во вновь созданной файловой системе блоки данных файлов имеют последовательно идущие LBA. Фрагментация файловой системы приводит к тому, что даже если с точки зрения приложений операции чтения и записи производятся последовательно, то на уровне файловой системы они все равно не могут эффективно объединяться в большие запросы. Таким образом, sequential операции превращаются в random, что увеличивает накладные расходы на их обработку и очень заметно сказывается на общей производительности. Поэтому, если файловая система предполагает наличие значительного количества последовательных запросов (например, резервное копирование данных), необходимо регулярно проводить ее дефрагментацию.

Базы данных обычно имеют свою собственную буферизацию. Для того чтобы избежать неэффективного использования ресурсов за счет двойной буферизации, в некоторых случаях резонно не использовать дополнительную прослойку файловой системы, а передавать данные напрямую на сырые устройства (raw devices).

Raw devices не имеют ограничений на размер блока и поэтому позволяют варьировать размеры Request Size в более широком диапазоне. В силу своей организации они также не подвержены фрагментации на уровне блоков.
В тоже время, использование сырых устройств усложняет управление, а также резервное копирование и восстановление данных. В современных системах с большим объемом оперативной памяти, файловые системы часто показывают более высокое быстродействие, чем сырые устройства.

По бразильской системе...

Из Книги Кэри Миллсапа и Джеффа Хольта “Oracle оптимизация производительности”

"Гэри Гудман, рассказывал о проектах внедрения приложений, которыми он руководил во время работы в Oracle Corporation. Один из приемов, практикуемых им в процессе внедрения, состоял в отключении всех прикладных отчетов в системе. Когда пользователи приходили с просьбой о недостающем отчете, специалисты подключали его обратно. По опыту Гэри, ни разу не пришлось подключить больше 80% отчетов, первоначально имевшихся в системе."

Другие замечательные цитаты из книги здесь и здесь

Заметки на полях (базы данных)

Скорее не полноценный пост, а памятка самому себе...

• Стоит всегда стараться изолировать log-файлы от данных СУБД на отдельном RAID10.
• Если Response Time файлов данных СУБД <6ms – отлично, 6-20ms – приемлемо, >20ms – плохо.
• Если Response Time log-файлов СУБД <2ms – отлично, 2-6ms – приемлемо, 6-15ms – скоро начнутся проблемы, >15ms – проблемы уже начались.

Уровень приложений

Существует великое множество разнообразных комбинаций приложений и способов их использования. Казалось бы, это ведет к бесконечному количеству различных типов ввода-вывода. Соглашусь с этим только отчасти. Конечно, детально рассматривая производительность дискового массива, мы увидим совершенно уникальное сочетание значений метрик. Но, в тоже время, по неким общим чертам и схожестям характеристик, можно выделить общие I/O паттерны приложений.

Обычно приложения группируются на основе следующих характеристик нагрузки:

• особенностей доступа к данным логических томов – выборки информации последовательным (sequential) или произвольным (random) образом.
• соотношения количества запросов на чтение (read) и запись (write)
• среднего размера блоков данных (Request Size)
• стабильности (steady) или наличия пиков (bursty)

При sequential доступе обрабатываются блоки данных, логические адреса (logical block address, LBA) которых расположены близко друг к другу и могут составлять последовательную цепочку (например, блоки 105, 106, 107, 108 или 23, 27, 25, 24, 26). Напротив, при random доступе адресуются LBA, которые не являются смежными и произвольным образом разбросаны по адресному пространству LUN. Конечно, эти определения являются достаточно общими и не описывают степень случайности или локализации требуемых данных, но для качественного описания I/O паттернов вполне годятся.

В таблице приведены характеристики для наиболее распространенных типов приложений.

Приложение	Тип доступа	Request Size	Интенсивность записи	Стабильность нагрузки
MS Exchange	Очень произвольный	4KB	Относительно высокая	Пики
MS Exchange Backup	Произвольный	64KB	Очень низкая	Стабильна
SAP/Oracle	Очень произвольный	4KB	Зависит от приложения	Пики
СУБД файлы данных/ OLTP	Очень произвольный	Page size	Относительно высокая	Пики
СУБД файлы данных/ DSS	Частично последовательный	64KB - 1MB	Низкая	Стабильна
СУБД online (transaction) logs	Последовательный	512bytes+	Высокая (за исключением archiving)	Пики
СУБД temp space	Произвольный	Page size	Очень высокая	Пики
Потоковое мультимедиа	Частично произвольный	64KB - 128KB	Низкая	Пики
Потоковое видео	Последовательный	64KB+	Высокая	Стабильна

Более детальная информация об основных типах I/O содержит данные о значениях Random Read Hit (RRH), Random Read Miss (RRM), Sequential Read (SR) и Writes (WRT). Надеюсь, позднее я уделю этим характеристикам отдельное внимание.

Средние значения Request Size для операций чтения и записи показаны на следующем графике. Хочу обратить внимание, на то, что реальные показатели Request Size будут колебаться вокруг этих усредненных значений.

Уровни обработки и хранения данных

В рамках классической модели хранении и обработки данных, информация перемещаются между различными уровнями (layers) технологического стека, выступающими в роли потребителей ресурсов и поставщиков услуг. Часто рассматривается упрощенный стек, который формируется из 9 основных уровней.

Реальный опыт показывает, что наиболее эффективным направлением анализа производительности комплекса является сверху вниз. Чаще всего, максимальный эффект дает оптимизация верхних уровней. Ведь именно они формируют все запросы, которые в дальнейшем обрабатываются остальными подсистемами. Зачастую, добавление дополнительных индексов таблиц, использование более эффективного алгоритма сортировки или изменение размера буферов и Shared Memory дают просто ошеломляющий прирост производительности. К сожалению, многие организации не имеют возможности, а подчас, и просто не заинтересованы в оптимизации приложений и баз данных.

Подсистемы хранения данных находятся в самом низу стека. Поэтому анализ различных метрик производительности на уровне дискового массива позволяет только выдвигать гипотезы о характеристиках ввода-вывода на верхних уровнях. Знание требований и специфики приложений, менеджеров томов и файловых систем позволит либо подтвердить эти гипотезы, либо выявить определенные несоответствия. Это еще раз подтверждает важность того, что анализировать комплекс всегда следует начинать сверху.

Немного особняком стоит уровень инфраструктуры сети хранения данных. Как я уже говорил, его влияние на общую производительность при передаче данных на небольшие расстояния (до 100км.) обычно не велико, т. к. вносимые задержки обычно не превышают нескольких десятков µs. В тоже время при значительном удалении устройств комплекса друг от друга, скорость распространения данных в сетях FC и IP SAN становится одним из основных факторов, ограничивающих производительность. В том и в другом случаях, при проектировании сетей хранения стоит учитывать требования к доступности данных.

Уровень приложений обсуждается здесь. Уровень файловых систем здесь. менеджеры томов здесь и здесь. Виртуальная память здесь. Уровни драйверов и HBA здесь. инфраструктура SAN здесь, здесь и здесь.

Теория Массового Обслуживания

В предыдущих постах мы обсуждали зависимости, которые были получены экспериментальным путем. К слову сказать, существует и теоретическая база для всего этого наукообразия. Она называется Теория Массового Обслуживания (Queuing Theory). Первые задачи данной теории были рассмотрены сотрудником Копенгагенской телефонной компании Агнером Эрлангом (Agner Krarup Erlang 1878-1929) еще в начале прошлого века. Этот в высшей степени выдающейся человек решил задачу упорядочивания работы телефонной станции, рассчитав параметры качества обслуживания потребителей в зависимости от количества используемых устройств.
В наше время Теория Массового Обслуживания активно используется для решения широкого спектра задач. С ее помощью можно достаточно точно оценить необходимое количество кассиров, требуемых в разное время для обслуживания посетителей супермаркета, или требования к производительности работы международного аэропорта.

Как и любая другая математическая теория, Queuing Theory требует основательного знания математики. Я не буду утомлять себя и читателя выкладками серьезных формул. Для тех, кто хочет глубоко в этом разобраться существуют многочисленные специализированные книги и статьи. Да и с прикладной точки зрения необходимости в этом нет. На широких просторах сети не сложно найти уже готовые таблицы Excel, которые очень удобно использовать для простых оценок. Расчеты и графики из этого поста можно взять здесь.

Все же вкратце хочется пояснить основные положения и следствия этой теории. Одна из сложностей работы с реальными системами очередей, будь то пакеты данных, обрабатываемых системой хранения, или телефонные звонки, приходящие на коммутатор, состоит в том, что невозможно точно предсказать время поступления этих запросов. Они случайным образом распределены во времени. Для большого количества таких запросов можно использовать статистические методы анализа и оценивать некие усредненные характеристики. Эрланг доказал, что интенсивность поступления вызовов в телефонной системе характеризуется распределением Пуассона. Основываясь на этом факте, была построена простая модель теории обслуживания М/М/т.

Одним из очень упрощенных следствий модели является следующая формула:

Т. е. мы видим все ту же нелинейную зависимость, при которой время отклика системы достаточно постоянно при небольшой нагрузке, но очень сильно зависит от нее при высоких показателях Utilization. помните, мы обсуждали это здесь? Высокими показателями можно считать значения правее точки перегиба, начиная с которого кривая начинает расти быстрее вверх, чем уходить вправо.
Обращаю ваше внимание, что эта теоретическая формула ни в коей мере не претендует на точность, но все же в общих чертах объясняет форму графиков, полученных в ходе замеров производительности реальных устройств.

Интересны еще несколько зависимостей, следующих из модели M/M/m. При постоянном Service Time увеличение количества каналов обслуживания очереди (m) ведет к “сдвигу” точки перегиба в право. Это означает, например, что увеличение пунктов досмотра багажа пассажиров, стоящих в единой очереди терминала аэропорта, при возрастании общего пассажиропотока позволит заметно увеличить эффективную утилизацию этих пунктов.

С другой стороны, графики, соответствующие малым количествам каналов обслуживания, более плавные. Утилизация таких систем при достижении критических значений изменяет Response Time менее резко. Поэтому такие системы в большей степени толерантны к резким нетипично высоким повышениям нагрузки.

А вот уменьшение самого Service Time системы всего лишь сжимает график, тем самым сокращая общий Response Time, но не изменяя точки перегиба. Т. е. рост производительности пунктов досмотра багажа из предыдущего примера, конечно, в какой-то мере уменьшит общее время прохождения досмотра, но не позволит заметно повысить их утилизацию.

Внимательный читатель скажет: “А ведь я уже видел такие сдвиги и растяжения графиков", и будет прав. Посмею сделать утверждение, доказательство которого оставлю на совести гуру Теории Массового Обслуживания. Добавление кэша или количества дисковых накопителей в определенных случаях можно промоделировать при помощи увеличения количества каналов обслуживания. А уменьшение Request Size опосредованно ведет к снижению Service Time и также, с некоторыми оговорками, вписывается в рамки модели M/M/m.

Для желающих подробнее познакомиться с Теорией Массового Обслуживания предлагаю несложную задачку с решением.
Администрация вокзала решила внедрить новую систему обслуживания пассажиров и установить автоматические кассы-терминалы по продаже билетов. Количество пассажиров, встающих в очередь, - в среднем 3 чел./мин. Максимальное время, которое пассажир готов стоять в очереди, а не дождавшись поехать без билета - 5 мин. Рассматривается вопрос о приобретении 4 касс. На выбор есть кассы с производительностью обслуживания 1 чел./мин. и 1,3 чел/мин..
Необходимо выбрать наиболее оптимальный из двух вариантов, который поможет сократить количество тех, кто не дождался своей очереди и поехал без билета. Вариант I - организовать в каждую кассу отдельную очередь. Вариант II - организовать единую очередь ко всем кассам. Причем, во втором варианте для интереса мы будем учитывать использование более производительных касс. Решение задачки можно проанализировать все в той же таблице.

Даже несмотря на то, что в варианте II предполагается использование более производительных касс, вариант I все же будет лучше. Интересно отметить, что если количество пассажиров, встающих в очередь, уменьшится до 0,5 или увеличится до 4, более предпочтительным станет второй вариант (см. график). Вот такие интуитивно-непонятные выводы... :)

Обратная связь

Давайте немного поговорим о сложных процессах взаимного влияния инициатора нагрузки и поставщика сервисов хранения. С точки зрения сервера существует понятная зависимость между Response Time, ожидаемым приложением, и требуемой для этого Throughput. Есть даже емкий английский термин для такой формы зависимости – anticipating demands. Что бы записать или получить данные с дискового массива за меньшее время, серверу необходимо просто увеличить количество соответствующих запросов, т. е. повысить Throughput.
Хочу обратить ваше внимание, что этой зависимостью управляет именно ожидание сервера, т. е. ось ординат Response Time на графике anticipating demands.

Что же в это время происходит на дисковом массиве? Предположим, что он имеет достаточное количество свободных ресурсов для того, чтобы выполнить I/O операций в рамках ожидаемого Response Time. Более того, у него есть дополнительные невостребованные мощности и поэтому массив обработает запросы с Throughput, которая даже больше требуемой. Хранилище просто “проглотит” данные быстрее, чем того ожидает сервер. В таком случае, приложение имеет возможность уменьшить Response Time, ужесточив требования к Throughput. Увеличение пропускной способности может (но, конечно, не обязательно) происходить до тех пор, пока требования сервера не подойдут к пределу возможностей дискового массива, т. е. до пересечения их кривых.

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

Таким образом, происходит взаимное давление с обеих сторон взаимодействия. Этот механизм обратной связи приводит к адаптивной регуляции нагрузки.
“Если все так самоорганизуется, то откуда же тогда берутся проблемы с производительностью?”, спросит пытливый читатель. Все дело в требованиях конечных пользователей приложений. Если результирующее Response Time дискового массива будет высоким, то это приведет к увеличению времени отклика приложений. Его несоответствие формальным требованиям или даже просто субъективным ожиданиям потребителей, будет являться поводом для оптимизации использования ресурсов или модернизации не справляющегося со своей работой оборудования.

Стоит отметить, что описанный выше механизм прост только в рассмотрении результатов синтетических тестов. Ведь в реальных условиях, как требования приложений, так и характеристики дискового массива постоянно изменяются. Это приводит к непрерывной трансформации обеих зависимостей. Как следствие, точки пересечения кривых буквально мечутся по плоскости графиков. Анализировать такое поведение практически не возможно.