Казалось бы, что про диски Advanced Format за последние 4 года успели узнать все. Публикаций действительно много, но настало время рассмотреть все технические подробности и подводные камни в одной большой статье. Речь пойдёт об использовании AF-дисков в серверах, и я заметил, что для большинства администраторов даже в крупных компаниях знание предмета в большинстве случаев сводится к «это как-то связано с современными дисками, но у меня всё работает».
Что такое Advanced Format
Advanced Format — новый формат разметки секторов, используемый в некоторых жёстких дисках. Вместо традиционного сектора размером 512 байт используется 4096 байт. Некоторые диски SCSI/SAS/FC могут использовать 520- и 528-байтные «толстые» сектора для дополнительного контроля целостности данных, но это не относится к теме данной статьи.
Увеличение размера сектора в 8 раз связано с необходимостью повышения эффективности размещения данных на современных дисках. Накладные расходы, связанные с 512-байтной разметкой, начинают мешать дальнейшему увеличению ёмкости HDD. Помимо служебных полей в каждом 512-байтном секторе присутствует поле с кодом коррекции ошибок (ECC) длиной в 50 байт. В 4096-байтном секторе длина ECC-поля составляет 100 байт. Общее эффективность хранения данных удалось улучшить примерно на 10%.
Естественно, поддержка нестандартных секторов требуется со стороны дисковых контроллеров и операционных систем. Для решения проблем с совместимостью был ввёден дополнительный стандарт 512E, который обозначает диски с физическим размером сектора 4096 байт, но при этом эмулирующие обычный размер сектора в 512 байт. Advanced Format диски без эмуляции обозначаются 4KN. Таким образом, сейчас существует три варианта разметки:
Формат | Логический размер сектора | Физический размер сектора |
512N | 512 байт | 512 байт |
512E | 512 байт | 4096 байт (4КиБ) |
4KN | 4096 байт (4КиБ) | 4096 байт (4КиБ) |
Совместимость
Операционные системы
На первый взгляд кажется, что использование эмуляции 512-байтного сектора снимает все проблемы с совместимостью, но это не так. Во-первых, сразу же возникает проблема с производительностью. Что произойдет при записи блока размером 512 байт на диск с размером сектора 4096 байт (пусть и эмулирующий наличие секторов 512 байт)? Произойдёт классический процесс read-modify-write, вместо одной операции понадобится две: прочитать сектор 4096 байт, поменять в нём 512 байт (записываемый блок) и записать 4096 байт обратно. Аналогичная проблема проявляется и при отсутствии выравнивания, когда записываемый блок данных может быть достаточно большим и даже кратным 4096 байт, но при этом сдвинут относительно границ реальных секторов:
В современных условиях операции записи блоками меньше 4096 байт встречаются крайне редко, а вот проблема с выравниванием остаётся. Например, в старых Windows (до Windows Server 2008) при установке загрузочный раздел создаётся со смещением в 63 сектора. Так уж исторически сложилось с тех времён, когда BIOS использовал реальную геометрию диска вместо LBA. Разумеется, смещение в 63x512 не делится на 4096, что приводит к нарушению выравнивания для всех последующих разделов и снижению производительности. Впервые на данную проблему обратили внимание в связи с использованием RAID-контроллеров и необходимостью выравнивания разделов по границам страйпа и она была решена в Windows Vista/ Windows Server 2008 (и примерно в то же время — в других ОС) введением выравнивания по границам в 1024КиБ (1МиБ), т.е. первый раздел создается со смещением в 2048 512-байтных секторов.
Почему именно 1МиБ, если подойдёт меньшее смещение (главное — чтобы делилось на 4096 байт)? Просто потому, что нужен запас, ведь помимо физического диска в качестве блочного устройства могут выступать тома на RAID-контроллерах (с размером страйпа по умолчанию, например, у Adaptec в 256КиБ), SSD (с большим размером страниц) или образы дисков при использовании виртуализации, рекомендуемый размер NTFS-кластера для SQL или Exchange равен 64КиБ и т.д.
Проблема номер два — возможная потеря данных для сценариев с синхронной записью. Для ситуаций с записью блока меньше 4096 байт или невыравненного блока синхронной записи по факту не получится. Остаётся «научить» ОС не использовать при записи блоки меньше 4096 байт на диски 512E, но с этим есть определённые проблемы.
Microsoft
Для ОС Microsoft есть следующие официальные (первоисточник) данные:
Формат | Логический размер сектора | Физический размер сектора | Совместимые ОС |
512E | 512 байт | 4096 байт (4КиБ) |
|
4KN | 4096 байт (4КиБ) | 4096 байт (4КиБ) |
|
Обратите внимание на дополнительное напоминание о том, что Windows Server 2003 R2, Windows XP и другие ОС, основанные на кодовой базе XP (например, Windows Home Server 1.0, Windows Small Business Server 2003, 2003 R2), хоть и могут функционировать в связке с 512E дисками, но Microsoft предостерегает от использования таких дисков: если проблему с выравниванием ещё можно решить, то проблемы с производительностью или с потенциальной потерей данных при потере питания во время read-modify-write никак не обойти.
Проверить выравнивание существующих разделов и задать смещение для новых разделов в Windows можно при помощи diskpart. Пример (раздел на диске 0 со смещением в 1024КиБ или 2048 512-байтных секторов):
select disk 0 create partition primary align=1024
Проверить проще всего через WMI (пример):
wmic partition get Blocksize,StartingOffset, Name BlockSize Name StartingOffset 512 Диск #0, раздел #0 1048576 512 Диск #0, раздел #1 368050176 512 Диск #2, раздел #0 135266304 512 Диск #1, раздел #0 1048576
В колонке StartingOffset должно быть 1024КиБ для первого раздела, для остальных — должно делиться на 1024КиБ, это означает, что и на 4096 байт и все другие «хорошие числа» (размеры страйпов и NTFS-кластеров) всё будет делиться.
Напомню, что в современных Windows смещение в 1024КиБ и так используется по умолчанию, так что проверять/выставлять его вручную нужно лишь для ОС из «63-секторной» эпохи. При автоматическом создании GPT-разметки (через Disk Management) на 512N или 512E диске вы увидите смещение для первого раздела в 17КиБ. Это не повод для тревоги, так как это служебный раздел MSR. Первый стандартный раздел будет создан со смещением в 135266304 байт (129МиБ) — прекрасно делится на любое из наших «хороших чисел».
Linux
Таблица совместимости для Linux (приведены только распространённые серверные дистрибутивы):
Формат | Логический размер сектора | Физический размер сектора | Совместимые ОС |
512E | 512 байт | 4096 байт (4КиБ) |
|
4KN | 4096 байт (4КиБ) | 4096 байт (4КиБ) |
|
Для других дистрибутивов можно ориентироваться на версию ядра (>2.6.31) и версии утилит для разбивки диска: GNU Fdisk >1.2.3 или GNU Parted >2.1
Посмотреть размеры физического и логического блоков можно в /sys/block/sdX/queue/physical_block_size и в /sys/block/sdX/queue/logical_block_size соответственно.
GNU Fdisk будет автоматически использовать смещение в 1МиБ при запуске с ключами -c и -u (отключить режим совместимости с DOS и использовать сектор в качестве единицы измерения). Обычный Fdisk не умеет работать с GPT, так что он бесполезен для дисков >2ТиБ, и нужно использовать Parted или GPT Fdisk. Последний по умолчанию использует для 512N/512E дисков нужное нам смещение в 2048 секторов:
Disk /dev/sde: 7814037168 sectors, 3.6 TiB Logical sector size: 512 bytes Disk identifier (GUID): BE7D7D71-F6ED-4371-ACFE-B04819A4DDC2 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 7814037134 Partitions will be aligned on 2048-sector boundaries Total free space is 7814037101 sectors (3.6 TiB)
Пример для GNU Parted (для 512N/512E дисков):
# создаём новую GPT разметку mklabel gpt # создаём раздел на всё свободное пространство со смещением в 2048 секторов (parted) mkpart part1 2048s 100% (parted) print Model: ATA WDC WD40EFRX-68W (scsi) Disk /dev/sde: 7814037168s Sector size (logical/physical): 512B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 2048s 7814035455s 7814033408s part1
В LVM всё хорошо: смещение по умолчанию равно 1МиБ и размер PE (physical extent) кратен 1МиБ.
# проверяем смещение #pvs /dev/sde -o+pe_start PV VG Fmt Attr PSize PFree 1st PE /dev/sde VolRed lvm2 a-- 3.64t 3.64t 1.00m # проверяем размер PE #pvdisplay /dev/sde --- Physical volume --- PV Name /dev/sde VG Name VolRed PV Size 3.64 TiB / not usable 3.84 MiB Allocatable yes PE Size 4.00 MiB Total PE 953861 Free PE 953861 Allocated PE 0 PV UUID 9AfJr9-OOtC-PB34-dUnq-kCDK-L1fN-aTAxus
VMware
Статья в базе знаний VMware утверждает, что ни 512E, ни 4KN диски не поддерживаются. Поддержка дисков 4KN заявлена в vSphere 6.0.
С появлением VMFS-5 мы получили единый размер блока — 1МиБ и правильное 1МиБ-смещение для первого раздела. Раньше использовалось не всегда подходящее смещение в 64КиБ. Но всё это не отменяет заявления VMware о том, что 512E диски не поддерживаются. Видимо, это связано с тем, что формат VMDK хранит данные с гранулярностью 512 байт.
Прочие ОС
Mac OSX поддерживает Advanced Format начиная с Tiger. Остаются ещё FreeBSD и прочие *BSD, Oracle Solaris и множество других ОС, но детальное рассмотрение ситуации с Advanced Format дисками в них выходит за рамки данной статьи.
Сервисы Microsoft
Hyper-V
Несмотря на то, что диски 512E поддерживаются в Windows Server 2008 и 2008 R2 (см. в таблице требования по установленным KB), в Hyper-V появляется проблема: формат файлов виртуальных дисков VHD использует 512-байтные структуры для динамических («тонких») и дифференциальных VHD, что, естественно приводит к регулярным read-modify-write. Ситуация усугубляется тем, что для гостевой ОС виртуальный диск выглядит как имеющий физические сектора 512 байт. Используйте фиксированные VHD, но по-возможности не используйте диски 512E для размещения VHD-файлов.
В Windows Server 2012 появился формат VHDX, который не имеет вышеописанных проблем.
Exchange Server
Есть особенности, связанные с репликацией в DAG:
- Все диски, используемые в группе обеспечения доступности (Database Availability Group, DAG) Exchange для хранения баз и логов, должны использовать одинаковый физический размер сектора.
- Диски 4KN не поддерживаются
- Диски 512E поддерживаются начиная с Exchange 2010 Service Pack 2
SQL Server
Ситуация та же, что и для Exchange Server — в отказоустойчивых конфигурациях для баз и логов на всех узлах должы использоваться диски с одинаковым физическим размером сектора.
При использовании Storage Spaces возникает интересная ситуация: презентуемый размер физического сектора оказывается равным 4КиБ вне зависимости от того, из каких дисков собран Storage Spaces (том Storage Spaces можно создать из разных дисков — 512N и 512E, смешивать с 4KN, естественно, нельзя). Формат VHDX (виртуальный диск) всегда выглядит как 512E. В этом можно убедиться, запустив fsutil fsinfo ntfsinfo <имя диска>:
Bytes Per Sector : 512 Bytes Per Physical Sector : 4096
Безопасно ли это для SQL и других приложений, использующих синхронную запись? Ответ — да, так как большая гранулярность хранения не нарушает целостности данных, на производительность это тоже не влияет, так как 4096 делится на 512.
Сервисы, использующие ESENT
Не совсем актуальная проблема в Windows Server 2008. Сервисы, использующие в работе Extensible Storage Engine API (AD, WINS, DHCP) могут упасть при изменении размера физического сектора (например, при миграции с 512N-диска на 512E). Подробное описание и хотфикс смотрите тут.
Прочее ПО
Очевидно, что софт, предназначенный для управления разделами (клонирования, перемещения, изменения размеров) и для автоматизации резервного копирования должен учитывать особенности работы с дисками Advanced Format. Вот как обстоят дела:
- Продукты Acronis.
- Symantec Backup Exec поддерживает диски Advanced Format (512E и 4KN) начиная с версии 2012 revision 1798 Service Pack 2. Более ранние выпуски могут работать с дисками 512E, но Symantec утверждает, что подобное сочетание не поддерживается официально.
- Symantec Norton Ghost не поддерживает диски 4KN.
Контроллеры
Универсальные правила для всех контроллеров:
- Диски 4KN и 512N/512E смешивать в одном массиве нельзя.
- У контроллеров Adaptec и LSI метаданные размещаются в конце диска, пользовательское пространство доступно с LBA0. Это означает, что проблем с выравниванием для 512E дисков не будет.
- Массив из 4KN дисков так же будет иметь физический/логический размер сектора 4КиБ, т.е. для загрузки с них нужны GPT и UEFI.
- Не забывайте вместе с прошивкой обновлять утилиты управления и драйверы.
- Как будет презентоваться LUN, созданный на 512E дисках — 512N или 512E? Из того, что удалось проверить: контроллеры LSI 9260, Adaptec 6-й серии, СХД Infortrend ESDS сообщают 512N (логический/физический блоки 512 байт), т.е. проблема с синхронной записью остаётся. Обязательно используйте write-back кэш (естественно, с защитой) и UPS. Причём не исключено, что при смене прошивки СХД и контроллер могут внезапно повести себя «правильно», и LUN'ы превратятся в 512E со всеми вытекающими последствиями для совместимости.
Adaptec by PMC
- SAS HBA серий 5 и 6: поддерживают 512E, не поддерживают 4KN
- SAS HBA серий 6H и 7H: поддерживают 512E, 4KN — начиная с прошивки 10467.
- RAID контроллеры серий 7 и 8: поддерживают 512E, 4KN — начиная с прошивки 30862.
Списки совместимости для контроллеров Adaptec.
LSI/Avago
Контроллеры на базе чипов LSI используют Dell, IBM, Lenovo, Fujitsu, Intel и Supermicro. Соответствие между моделями от LSI и OEM-вариантами можно установить по чипу.
- Старые контроллеры на базе LSI1078: не поддерживают диски Advanced Format совсем
- LSI 3ware серии 9750 на базе LSI2108 и более ранние 3ware: не поддерживают диски Advanced Format совсем.
- LSISAS2108 (LSI 9260/61/80): поддерживают 512E начиная с прошивки MR4.8, 4KN не поддерживают. Список совместимости (4KN диски присутствуют, но, видимо, относятся к LSI 2208, см. ниже).
- LSISAS2208 (LSI 9265/66/71/85/86): поддерживают 512E начиная с прошивки MR5.5, поддерживают 4KN начиная с прошивки MR5.8. Список совместимости.
- LSISAS3108 (LSI 9361/80): поддерживают 512E и 4KN. Список совместимости.
- SAS HBA на базе LSISAS2008 и LSISAS2308 (LSI 9211/9200/9207): поддерживают 512E и 4KN. Список совместимости.
- SAS HBA на базе LSISAS3008 (LSI 9311/9300): поддерживают 512E и 4KN. Список совместимости.
- RAID на базе LSISAS2008 (LSI 9240, прошивка iMR): поддерживают 512E, 4KN не поддерживают. Список совместимости.
- RAID на базе LSISAS3008 (LSI 9340, прошивка iMR): поддерживают 512E, 4KN не поддерживают. Список совместимости.
Программный RAID в чипсетах Intel (RST/RSTe)
4KN не поддерживается совсем, Intel RST на дисках 512E требует свежих драйверов.
Advanced Format в дисках корпоративного класса. Что нас ждёт?
Речь пойдёт о дисках корпоративного класса последний серий. Десктопные HDD и позиционируемые для NAS или видеонаблюдения сюда не попали.
Вендор | Серия | Форм-фактор | Интерфейсы | Скорость вращения шпинделя, об/мин | 512N | 512E | 512KN | Дополнительно |
Seagate | Enterprise Performance 10K HDD (10k.8) | 2.5" | SAS | 10000 | Y | Y | Y | для 512N ёмкость ограничена: 600/1200ГБ |
Seagate | Enterprise Performance 15K HDD (15k.5) | 2.5" | SAS | 15000 | Y | Y | Y | 32ГБ встроенного SSD-кэша |
Seagate | Enterprise Capacity 2.5 HDD (V.3) | 2.5" | SAS, SATA | 7200 | Y | Y | ||
Seagate | Enterprise Capacity 3.5 HDD (V.4) | 3.5" | SAS, SATA | 7200 | Y | |||
Seagate | Archive HDD | 3.5" | SATA | 7200 | Y | Позиционируются для архивного применения, меньше MTBF и хуже BER | ||
Seagate | Terascale HDD | 3.5" | SATA | 5900/7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
HGST | Ultrastar C10K1800 | 2.5" | SAS | 10000 | Y | Y | Y | для 512N ёмкость ограничена: 300/600/900/1200ГБ |
HGST | Ultrastar C15K600 | 2.5" | SAS | 15000 | Y | Y | Y | |
HGST | Ultrastar C7K1000 | 2.5" | SAS | 7200 | Y | |||
HGST | Ultrastar He8 | 3.5" | SAS, SATA | 7200 | Y | Y | ||
HGST | Ultrastar He6 | 3.5" | SAS, SATA | 7200 | Y | |||
HGST | Ultrastar 7K6000 | 3.5" | SAS, SATA | 7200 | Y | Y | ||
HGST | MegaScale DC 4000.B | 3.5" | SATA | 5400 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
WD | Xe | 2.5"/3.5" | SAS | 10000 | Y | |||
WD | Re | 3.5" | SATA | 7200 | Y | |||
WD | Se | 3.5" | SATA | 7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
WD | Ae | 3.5" | SATA | 5760 | Y | ? | Позиционируются для архивного применения, меньше MTBF и хуже BER | |
Toshiba | AL13SE | 2.5" | SAS | 10000 | Y | |||
Toshiba | AL13SX | 2.5" | SAS | 15000 | Y | |||
Toshiba | AL13SEL | 3.5" | SAS | 10000 | Y | |||
Toshiba | MG03ACA/MG03SCA | 3.5" | SAS, SATA | 7200 | Y | |||
Toshiba | MG04ACA | 3.5" | SATA | 7200 | Y | Y | ||
Toshiba | MG04SCA | 3.5" | SAS | 7200 | Y | Y | ||
Toshiba | MC04ACA | 3.5" | SATA | 7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER |
Тенденцию вы видите сами — Advanced Format окончательно проник из десктопного сегмента в корпоративный. Быстрые SAS диски 10/15 тыс. об/мин ещё выпускаются в варианте 512N, но наращивание плотности заставляет производителей использовать 4КиБ-сектора: Seagate 10k.8 и HGST Ultrastar C10K1800 ёмкостью 1800ГБ доступны только в вариантах 512E и 4KN. Все диски объёмом больше 5ТБ за исключением HGST Ultrastar He6 — только Advanced Format.
SSD
SSD имеют свои особенности. Читать и записывать данные можно страницами, размер которых составляет 2–4–8–16КиБ в зависимости от архитектуры SSD. При этом для записи нужно обеспечить предварительное стирание ячеек, которое осуществляется не постранично, а блоками по несколько сотен страниц. Например, Samsung 840 EVO имеет блоки по 2МиБ, каждый из которых состоит из 256-ти страниц по 8КиБ. При этом, естественно, любой презентуемый хосту размер блока — 512 или 4096 байт — будет абстракцией.
Некоторые из современных SAS/SATA SSD эмулируют 512E-диск, но большая часть из соображений совместимости — 512N. Каких-либо особых мер в связи с этим предпринимать не требуется, так как в SSD корпоративного класса содержимое кэша обязательно защищается от потери питания. Достаточно обеспечить выравнивание по размеру страницы.
Некоторые PCI-E SSD, например, производства Fusion IO дают возможность при помощи фирменных утилит изменить при форматировании размер логического сектора, т.е. переключаться между 512E и 4KN режимами. Для некоторых SSD с интерфейсом SAS это тоже возможно, например, Seagate 1200 поддерживает изменение размера сектора обычным sg_format. Переход на 4КиБ сектор в некоторых сценариях может существенно поднять производительность.
Выводы
- Диски 512E не подходят для использования в серверах с устаревшими ОС, которые игнорируют размер физического сектора. В десктопных применениях это не имеет большого значения, так никто синхронную запись как правило не использует.
- Внимательно изучите свою инфраструктуру: ОС, используемые сервисы, контроллеры, СХД, режимы кэширования на контроллерах и СХД. При наличии потенциальных проблем с производительностью и/или целостностью данных примите необходимые меры.
- Проблемы с устаревшими ОС можно обойти при помощи виртуализации, но по-прежнему нужно обращать внимание на выравнивание разделов.
Ссылки
- IBM DeveloperWorks: Linux on 4 KB sector disks: Practical advice
- Документация RHEL6: IO limits и IO hints в Linux
- Выравнивание в fdisk, LVM и MD
- Поддержка дисков с большим размером сектора в Hyper-V
- Группы обеспечения доступности Exchange Server 2010 и размер сектора
- Использование Hyper-V на дисках с большим размером сектора в Windows Server 2008 и 2008 R2
- SQL Server и новые диски с размером сектора 4K
- Ошибка «Windows Setup could not configure Windows on this computer’s hardware» при установке Windows 7 или Windows Server 2008 R2
- Проблемы в приложениях, использующих Extensible Storage Engine API (ESENT), при изменении размера физического сектора
- Understanding 4KB Sector Support for Oracle Files
- Effect from innodb log block size 4096 bytes
Автор: quartz64