...

пятница, 5 декабря 2014 г.

[Из песочницы] Диски, контроллеры, ОС и Advanced Format

imageКазалось бы, что про диски 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КиБ)


  • Windows 8, 8.1

  • Windows Server 2012, 2012 R2

  • Windows 7 w/ MS KB 982018

  • Windows 7 SP1

  • Windows Server 2008 R2 w/ MS KB 982018

  • Windows Server 2008 R2 SP1

  • Windows Vista w/ MS KB 2553708

  • Windows Server 2008 w/ MS KB 2553708



4KN
4096 байт (4КиБ)
4096 байт (4КиБ)


  • Windows 8, 8.1

  • Windows Server 2012, 2012 R2




Обратите внимание на дополнительное напоминание о том, что 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КиБ)


  • RHEL 6.1

  • SLES 11 SP2

  • Ubuntu 13.10

  • Ubuntu 12.04.4



4KN
4096 байт (4КиБ)
4096 байт (4КиБ)


  • RHEL 6.1

  • SLES 11 SP2

  • Ubuntu 13.10

  • Ubuntu 12.04.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 Дополнительно
SeagateEnterprise Performance 10K HDD (10k.8) 2.5"SAS10000Y Y Y для 512N ёмкость ограничена: 600/1200ГБ
SeagateEnterprise Performance 15K HDD (15k.5) 2.5"SAS15000Y Y Y 32ГБ встроенного SSD-кэша
SeagateEnterprise Capacity 2.5 HDD (V.3) 2.5"SAS, SATA7200 Y Y
SeagateEnterprise Capacity 3.5 HDD (V.4) 3.5"SAS, SATA7200 Y
SeagateArchive HDD 3.5"SATA7200 Y Позиционируются для архивного применения, меньше MTBF и хуже BER
SeagateTerascale HDD 3.5"SATA5900/7200 Y Позиционируются для облачного применения, меньше MTBF и хуже BER
HGSTUltrastar C10K1800 2.5"SAS10000Y Y Y для 512N ёмкость ограничена: 300/600/900/1200ГБ
HGSTUltrastar C15K600 2.5"SAS15000Y Y Y
HGSTUltrastar C7K1000 2.5"SAS7200Y
HGSTUltrastar He8 3.5"SAS, SATA7200 Y Y
HGSTUltrastar He6 3.5"SAS, SATA7200Y
HGSTUltrastar 7K6000 3.5"SAS, SATA7200 Y Y
HGSTMegaScale DC 4000.B 3.5"SATA5400 Y Позиционируются для облачного применения, меньше MTBF и хуже BER
WDXe 2.5"/3.5"SAS10000Y
WDRe 3.5"SATA7200Y
WDSe 3.5"SATA7200 Y Позиционируются для облачного применения, меньше MTBF и хуже BER
WDAe 3.5"SATA5760 Y ? Позиционируются для архивного применения, меньше MTBF и хуже BER
ToshibaAL13SE 2.5"SAS10000Y
ToshibaAL13SX 2.5"SAS15000Y
ToshibaAL13SEL 3.5"SAS10000Y
ToshibaMG03ACA/MG03SCA 3.5"SAS, SATA7200Y
ToshibaMG04ACA 3.5"SATA7200 Y Y
ToshibaMG04SCA 3.5"SAS7200 Y Y
ToshibaMC04ACA 3.5"SATA7200 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КиБ сектор в некоторых сценариях может существенно поднять производительность.


Выводы





  1. Диски 512E не подходят для использования в серверах с устаревшими ОС, которые игнорируют размер физического сектора. В десктопных применениях это не имеет большого значения, так никто синхронную запись как правило не использует.

  2. Внимательно изучите свою инфраструктуру: ОС, используемые сервисы, контроллеры, СХД, режимы кэширования на контроллерах и СХД. При наличии потенциальных проблем с производительностью и/или целостностью данных примите необходимые меры.

  3. Проблемы с устаревшими ОС можно обойти при помощи виртуализации, но по-прежнему нужно обращать внимание на выравнивание разделов.




Ссылки




This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий