Производительность СХД. Часть третья

Пару лет назад на западных блогах, специализирующихся на технологиях VMware, было очень популярно писать как важно выравние (или же alignment), и как вредит производительности отсутствие оного. До нас эта тенденция особо не дошла, но периодически эта тема опять всплывает без ясного объяснения, что же это такое.

Физическая адресация

В первой части говорилось о подноготной жёстких дисков - какие факторы внутри самих дисков влияют на их производительность, при этом упустив вопрос строения и адресации данных на диске при низкоуровневом форматировании.
Изначально использовалась система CHS - цилиндр-головка-сектор. Рассматривать схему будем снизу вверх. Сектор - минимальный блок или, если угодно, квант информации, с которым работает жесткий диск (чтение или запись всегда происходит целым сектором). Стандартный размер сектора - 512байт. Сейчас на смену этому стандарту пришла новая технология Advanced Disk Format, которая позволяет использовать размер сектора 4096байт (4кб). Результатом использования ADF стало то, что доступный для использования объём пространства после низкоуровневого форматирования повысился с 87% до 96%, что очень полезно для современных дисков, учитывая их ёмкость. Несмотря на то, что физических ограничений на количество секторов в дорожке отсутствует - CHS, в силу особенностей кодирования, ограничивает их количество 63.

Головка - устройство, которое производит запись или чтение данных с диска. На каждую пластину приходится по две штуки - с каждой стороны пластины по головке.

Дорожка - концентрическая последовательность секторов на одной пластине. Отличие между дорожкой и цилиндром следующее: цилиндр это совокупность всех дорожек с одинаковыми номерами на всех пластинах.

Нынче эта схема уже устарела, и не используется - на её место пришла технология LBA. Не смотря на это все файловые системы опрашивают BIOS о геометрии жёсткого диска для того, чтобы посчитать его объём и разбить на предопределённые адресуемые блоки.

Вот тут и начинаются проблемы: данные которые получает ВМ от своего BIOS о физической геометрии диска никак не соответствуют действительности. Даже если Вы используете RDM, так как в этом случае геометрия LUN эмулируется прошивкой СХД.

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

От физических дисков данные отделяют два слоя - файловая система виртуальной машины и VMFS. В ESXi 3 и 4 размер блока, который использовался для обращения к диску, равен 64кб, а с версии 5 – 16кб. Маленькое отступление: размер блока в vSphere влиял на то, какой размер блока использовался при выделении пространства и определения максимального размера датастора. Все операции внутри блока проводились суб-блоками по 64кб. При создании VMFS раздела через VIClient раздел автоматически создаётся выровненным. Если же размер блока на RAID массиве у вас меньше 64кб, то выравнивание тут не работает, так как VMFS будет обращаться к диску последовательно. В общем, VMFS в любом случае будет выровнена.

Со вторым уровнем – NTFS всё сложнее. Во всех версиях Windows до Windows Server 2008 R2 NTFS раздел всегда создавался не выровненным. По умолчанию данные начинались писаться с 32 килобайта. Самый простой способ выровнять новые виртуальные диски – вручную выставить выравнивание на 128 секторов (64кб).

Всё это проще понять на картинке:

В данном случае оба уровни чётко выровнены, и, таким образом, при обращении NTFS даже к нескольким секторам – RAID контроллеру будет необходимо прочитать всего один блок данных.

Второй вариант, когда не выровнены ни NTFS, ни VMFS. В таком случае для чтения одного NTFS блока гипервизору приходится считывать один или даже два блока VMFS, но так как VMFS тоже не выровнена, то обращение к каждым 64кб VMFS будет требовать обращения к двум блокам данных на физическом RAID. Такая ситуация может серьёзно понизить общую производительность. Как уже говорилось – VMFS автоматически выравнивается при создании раздела из графического интерфейса, начиная с версии VI3, но не делает при форматировании через CLI, где необходимо это делать «ручками».



Третий вариант встречается чаще всего – VMFS выровнена, но NTFS внутри виртуальной машины нет. Для ВМ с WS2003 это стандартная ситуация. Собственно, пока размер блока на RAID массиве больше, чем размер блока ФС внутри виртуальной машины это не сильно страшно, так как в большинстве случаев все запросы от ВМ будут попадать в один блок данных на RAID массиве. На примере выше только два NTFS блока влияют на производительность, так RAID массиву необходимо прочитать два блока данных с жёстких дисков, чтобы предоставить эти данные. А вот что будет, если вы будете использовать 4кб блоки и на RAID массиве?

В таком случае vSphere будет генерировать запросы с максимальной эффективностью. Например, представим, что у Вас в ВМ работает база данных, которой, как я уже писал, свойственно случайное обращение к диску блоками по 4кб. В таком случае, vSphere тоже будет генерировать запросы по 4кб, и каждый такой запрос вызовет чтение двух блоков на RAID массиве, так как ФС не выровнена.

Почему бы не использовать только большие блоки?

Итак, почему бы не использовать только большие блоки на RAID, допустим по 256кб, и не забыть про выравнивание? Ну, во-первых, допустим EMC Clariion жёстко завязаны на использование 64кб, а NetApp – 4кб. Во-вторых, каждый раз, когда вам необходимо прочитать 4кб данных с диска будут прочитаны 256кб – а это огромная лишняя нагрузка.