Disk crossing и Partition Alignment

Проблема, описанная в данном посте, является общей для достаточно большого количества дисковых массивов различных производителей и моделей. Однако, для большей наглядности я поговорю о ней на примере конкретного хранилища EMC Clariion. Итак, как я уже писал в посте об организации RAID в массивах Clariion, по умолчанию размер Stripe element равен 64KB.

При выполнении операции ввода-вывода, оптимальным вариантом будет чтение или запись, зависящая от минимально возможного количества шпинделей. Очевидно, что для операций блоками <=64KB это будут обращения только к одному физическому диску.

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

При блоках <=64KB это приводит к удвоению количества требуемых операций. Особенно это критично при записи данных в RAID 5, когда и без того высокое значение Write Penalty=4 увеличится до 8.

Ситуация, когда одна операция ввода-вывода требует обращения к данным (Parity не считается) на нескольких физических накопителях называется пересечение границы диска (Disk Crossing). При анализе статистических данных о производительности дисковых массивов Clariion, необходимо учитывать, что метрика Disk Crossing инкрементируется на 1 при выполнении всей операции, не зависимо от количества “пересекаемых” шпинделей.

Пересечение границ страйпа Stripe Crossing также может негативно влиять на производительность. Так, высокоэффективный Full Stripe Write может “превратиться” в медленную запись нескольких независимых блоков.

Чаще всего причиной Disk Crossing является отсутствие выравнивания разделов в серверах архитектуры x86. Давайте рассмотрим это более подробно. Дело в том, что первый сектор диска (LBA 0) всегда содержит обязательную запись MBR (Master Boot Record), которая хранит таблицу разделов диска (partition table) и крохотную область кода, при необходимости используемую для передачи управления загрузчику ОС (boot loader) с активного раздела.

Новые разделы (partitions) на жестком диске по умолчанию создаются по границам треков. Но т. к. в первом треке уже записаны данные MBR, то раздел 0 приходится создавать с начала следующего трека, пропустив 63 блока LBA (32256 Bytes) Это мы уже видели здесь. Получается, что данные, записанные в раздел всегда будут смещены на 32256 Bytes относительно начала страйпа, что приводит к сдвигу адресации.

Естественно, такое смещение не всегда будет приводить к появлению Disk Crossing. Его вероятность зависит от размера операций, которыми записываются данные. Так, при записи 4KB, вероятность Disk Crossing будет равна 5,5% (4KB это 8 блоков по 512KB, (7/128)*100=5.5%. А при записи 16KB уже 24%. Конечно, запись данных размером >64KB будет приводить к инкрементации метрики Disk Crossing при любых обстоятельствах.

Для оптимизации производительности необходимо выровнять раздел (Partition Alignment) по границам 64KB Stripe Element. Для этого необходимо использовать утилиты, описанные в таблице.

Утилита	ОС	Параметры	Комментарии
diskpar	Windows NT и выше	Starting Offset in sectors = 128	не входит в дистрибутив ОС, можно установить из Microsoft Windows 2000 Resource Kit
diskpart	Windows 2003 SP1 и выше	Primary Align = 64	входит в дистрибутив ОС с Windows 2000, но начала поддерживать partition alignment только с версии 5.2.3790, которая появилась в Win 2003 SP1
fdisk	Linux	adjust starting block number = 128	в expert mode
	VMware ESX	adjust starting block for partition = 128	в expert mode

В идеале, неплохо было бы избежать Stripe Crossing и выравнивать раздел не на 64KB, а сразу на размер всего страйпа.

Добавлено
При создании разделов в Windows 2008, Vista и Windows 7 разделы создаются по границе 1MB и в выравнивании не нуждаются.

Тома VMware VMFS-3 при создании через vClient также автоматически выравниваются по границе 64KB. И их тоже выравнивать не надо. Однако, это не относится к томам на уровне самих виртуальных машин. Каждую ВМ придется выравнивать внутри .vmdk файлов

Случаи создания томов средствами LVM без использования стандартных разделов ОС необходимо рассмотривать индивидуально. Так, при использовании Physical Volumes в LVM ОС Linux выравнивание не нужно. Это связано с тем, что размер метаданных PV сам по себе кратен 64KB.

О Morley Parity здесь...