vSAN — Выбор SSD и контроллеров
Судя по телеграм чату о vSAN, бóльшая часть вопросов идет про попытки сэкономить и собрать vSAN дендрофекальным методом, а следом получить проблемы с использованием этой отличной технологии.
Зачем соблюдать HCL? Почему токсичный чатик все время тыкает в этот HCL? Черт побери, кто такой HCL Джон Голт? Давайте по порядку.
HCL — Hardware Compatibility List, документ, по которому нужно выбирать железо (в нашем случае) под vSAN. Посмотреть его можно здесь по HDD, здесь по SSD, а здесь по контроллерам.
0. Порядок
- Cache and Capacity Endurance (TBW / DWPD)
- Drive Performance
- PMR / SMR HDD
- Drive Reliability (MTBF / AFR / UER)
- SATA / NL-SAS / SAS
- Требования к HBA / RAID контроллерам
- Queue Depth
- Surprise Power Removal Protection / Power Loss Protection
1. Cache and Capacity Endurance (TBW / DWPD)
Есть пара основных показателей по выносливости (endurance) диска. Формула их соотношения ниже по тексту.
DWDP — Disk Write per Day. Допустимое количество перезаписей всего объема накопителя в день.
TBW — Total Bytes Written. Cуммарный объем данных, который гарантированно можно записать на накопитель.
| Endurance Class | TBW | Hybrid Caching | All-Flash Caching | All-Flash Capacity |
|---|---|---|---|---|
| Class A | >= 365 | No | No | Yes |
| Class B | >= 1825 | Yes | No | Yes |
| Class C | >= 3650 | Yes | Yes | Yes |
| Class D | >= 7300 | Yes | Yes | Yes |
Однако, различные модели SSD основаны на разных контроллерах, в которых, в свою очередь, применяются разные схемы балансирования нагрузки (вместо «изношенных» ячеек памяти контроллер использует ячейки с небольшим «пробегом»), призванные продлить время жизни устройства. Поэтому на данный момент ключевой характеристикой надежности SSD является TBW и DWPD. TBW для пользовательского SSD (Client) и для SSD корпоративного класса (Enterprise) характеризуют накопители в разных условиях и определены стандартом JEDEC. Корпоративный SSD должен обеспечивать запись заявленного количества данных в режиме 24/7 при более высокой (по сравнению с пользовательским SSD) температуре и с гарантией на порядок более низкого уровня ошибок.
Больше информации по Endurance тут
Больше информации по типам и различию Tiers vSAN тут
2. Drive Performance
Чем отличается домашний диск от enterprise? Домашние рассчитаны на короткие всплески нагрузки, а потом длительный простой. В vSAN (да и вообще в энтерпрайзе) такого паттерна нагрузки не будет, поэтому всякие ухищрения типа SLC-Cache (про это в статье ниже) просто не работают, так как, диск всегда заполнен на 70-80%, никаких пауз в обработке IO тоже нет, поэтому надо всегда в фоне под нагрузкой активно заниматься Garbage Collection.
Технология TRIM. Технология нужна для «уборки мусора». ОС передаёт информацию о том, какие сектора выводятся файловой системой из обращения, контроллер SSD должен консолидировать эти сектора и очистить освобождающиеся страницы флеш-памяти для выполнения будущих операций. Такие действия требуют перезаписи и очистки областей памяти, и это не только занимает заметное время, но и серьёзно нагружает контроллер работой. В результате после удаления с диска больших объёмов данных могут быть замедления SSD или даже подвисания диска.
У SSD всегда есть резерв — OverProvisioning. Две ключевых точки, в которых самая большая от него польза — это 7% и 28%. Поэтому, например, диски с 512GB flash памяти продаются как 480GB (7%) и 400GB (28%). Это свободное место позволяет легче находить чистые блоки для записи и ускоряет Random Write и снижает износ диска.
Если у вас диск уже с 28% OverProvisioning, я бы дополнительно не стал оставлять места, там уже процент пользы небольшой. Если диск с 7%, то, в зависимости от желаемого использования, может иметь смысл увеличить до 28%.
На SATA дисках это можно сделать через hdparm, установив HPA (Host Protected Area).
На SAS — через sg_format.
На NVME — через resize.
TRIM занимается тем, что помечает блоки, из которых все удалено, как чистые. Для Enterprise SSD, TRIM не нужен — им хватает резерва, чтобы самим справиться с нагрузкой. TRIM нужен, в основном, на Consumer SSD с малым OverProvisioning (типа 500GB). В Enterprise SSD за очистку отвечает FTL на низком уровне. Про Flash Translation Layer можно почитать вот тут.
Т.к. SSD пишет страницами по 4KiB или 8KiB внутрь 256KiB блока (только страницы и блоки от модели к модели разные, но смысл один), а удаляется только блоком целиком, то пока все страницы внутри блока не будут помечены на удаление, блок не будет отмечен готовностью для очистки TRIM’ом, и будет в статусе partially filled, вместо free.
Из-за этого появляется такая вещь как Write Amplification. В идеале, если сервер хочет записать 1 МБ данных, SSD должен записать 1 МБ. Это происходит редко из-за особенностей описанных выше, и в итоге SSD записывает больше данных, чем предполагалось изначально. Этот физический акт многократного перемещения данных может привести к износу изоляционного слоя с течением времени. Возможность стирания замедляется. Когда блок не стирается, используется запасной блок. В конце концов запасные блоки заканчиваются, и SSD выходит из строя.
Классы производительности флэш-устройств, указанные в HCL VMware, следующие:
| Performance Class | Writes Per Second |
|---|---|
| Class A | 2,500–5,000 |
| Class B | 5,000 – 10,000 |
| Class C | 10,000–20,000 |
| Class D | 20,000–30,000 |
| Class E | 30,000 – 100,000 |
| Class F | 100,000 + |
Больше информации по Performance тут
3. PMR / SMR HDD
Из-за технических проблем особенностей технологии «черепичной» записи (SRM) не рекомендуется использовать такие диски в vSAN. Более подробно — ниже.
Перпендикулярная магнитная запись (PMR)
PMR, также известный как традиционная магнитная запись (CMR), выравнивает полюса магнитных элементов, которые представляют собой биты данных, перпендикулярно поверхности диска. Магнитные дорожки записываются бок о бок без перекрытия. Поскольку записывающая головка обычно больше, чем считывающая, производители жестких дисков стараются максимально уменьшить ее размер.
Черепичная магнитная запись (SMR)
SMR является расширением PMR и обеспечивает улучшенную плотность записи. Вместо того, чтобы записывать каждую магнитную дорожку без перекрытия, SMR перекрывает каждую новую дорожку с частью ранее записанной дорожки, очень похоже на черепицу на крыше. Из -за перекрытия дорожек записывающие головки становятся тоньше, что увеличивает плотность записи.
Независимо от того, использует ли жесткий диск PMR или SMR, для считывающей головки требуется только небольшая часть записанной магнитной дорожки. Когда новые данные записываются на диск SMR, дорожки полностью читаются без ущерба для производительности.
Однако если данные на диске SMR редактируются или перезаписываются, записывающая головка не перезаписывает данные на существующую магнитную дорожку. Вместо этого новые данные будут записаны на пустую область диска, а исходная дорожка со старыми данными будет временно сохранена. Когда жесткий диск переходит в режим ожидания, он переходит в режим реорганизации, в котором старые биты данных на исходной дорожке будут удалены и полностью доступны для дальнейшего использования.
Этот режим реорганизации необходим для полного удаления дорожек, поэтому время простоя диска SMR является существенным. Если диск SMR интенсивно используется для чтения и записи, у него не будет достаточно времени для реорганизации магнитных дорожек, в результате чего дорожки со старыми данными временно останутся на месте. В результате этого, на диске SMR может потребоваться одновременная запись новых данных и реорганизация старой дорожки, что отрицательно скажется на общей производительности чтения/записи. Для борьбы с этой проблемой производители дисков SMR разработали микропрограммное обеспечение, которое оптимизирует производительность чтения/записи во время перезаписи данных.
В 2020 вскрылось, что много производителей используют SMR и была поднята большая буча по этому поводу.
Комментарии от Seagate
Комментарии от WD
Почитать на русском на 3DNEWS
4. Drive Reliability (MTBF / AFR / UER)
Есть несколько основных показателей по ошибкам дисков.
MTBF — Mean Time Between Failures. Это более актуально для жестких дисков где много механического всего что может сломаться, но для понимания, опишу. Для примера возьмем, диск c MTBF равным 1 000 000 часов. Исходя из описания может показаться, что производитель гарантирует работу диска в течение 1000000/8760 = 114 лет. Это означает, что не один диск отработает 114 лет, а в партии из 114-ти дисков за 1 год можно ожидать выхода из строя одного диска.
AFR — Annualized Failure Rate. Годовая интенсивность отказов серии дисков. AFR=1/(MTBF/8760).
UER — Unrecoverable Error Rate. Вероятность появления невосстановимой ошибки чтения, по различным причинам: дефект поверхности, сбой в работе головки, контроллера и т.д.
Отличная статейка про ячейки памяти в SSD. Как работают, почему ломаются? SLC, MLC, TLC, QLC
Почитать больше про Hard disk drive reliability and MTBF / AFR от Seagate
5. SATA / NL-SAS / SAS
Вот такой интересный документик есть от Seagate по SAS vs. SATA Flash Devices.
Список отличий SAS от SATA:
- Full-duplex transmission (bidirectional or 2x unidirectional)
- Two concurrent channels (ports)
- Wide ports (x2 and x4)
- Available speed: 12Gb/s, up to 48Gb/s with two full-duplex ports
- End-to-end data integrity
- Full IOECC (input/output error correction)
- Hot-plug
- More than 32 queue depth (SATA maximum = 32)
- Enterprise-type command queuing (128 to 256)
- Full SCSI command set
- Variable sector size
- High-voltage signal level (1.2V)
- Write Cache
- Write Failure Notification
- SAS Log Pages
Главной причина, почему в HCL нет SATA HDD кроется в Full SCSI command set. В рамках SATA не стандартизировано жесткое требование команды выключить кэш на запись в DRAM. Поэтому SATA диск может смело проигнорировать команду с контроллера на выключение кэша.
И в отличии от SATA SSD в которых есть конденсаторы, в SATA HDD нет батареек, то при потере питания (power loss) все 64-256 MB (или сколько у этого HDD есть кэша) на каждом диске легко иcчезнут, с полной потерей данных.
6. Требования к HBA / RAID контроллерам
| Storage Controller Feature | Storage Controller Requirement |
|---|---|
| Required mode | Review the vSAN requirements in the VMware Compatibility Guide for the required mode, passthrough or RAID 0, of the controller. If both passthrough and RAID 0 modes are supported, configure passthrough mode instead of RAID0. RAID 0 introduces complexity for disk replacement. |
| RAID mode | In the case of RAID 0, create one RAID volume per physical disk device. Do not enable a RAID mode other than the mode listed in the VMware Compatibility Guide. Do not enable controller spanning. |
| Driver and firmware version | Use the latest driver and firmware version for the controller according to VMware Compatibility Guide. If you use the in-box controller driver, verify that the driver is certified for vSAN. OEM ESXi releases might contain drivers that are not certified and listed in the VMware Compatibility Guide. |
| Queue depth | Verify that the queue depth of the controller is 256 or higher. Or 512 if you have 2 disk groups Higher queue depth provides improved performance. |
| Cache | Disable the storage controller cache, or set it to 100 percent read if disabling cache is not possible. |
| Advanced features | Disable advanced features, for example, HP SSD Smart Path. |
Каждому хосту ESXi в кластере vSAN требуется дисковый контроллер который умеет работать в Passthru (pass-through) режиме, режиме HBA или режиме JBOD. Другими словами, дисковый контроллер должен уметь прокидывать диски «как есть» без слоя RAID. Это нужно, чтобы ESXi смог выполнять операции I/O без вмешательства контроллера диска. Термин Passthru просто означает карту RAID, которая не выполняет никаких операций RAID на диске и часто также известна как режим HBA. Многие современные контроллеры поддерживают Passthru mode / HBA / JBOD режим, но есть еще те, которые не умеют в такие режимы, и для использования их в vSAN есть обходной путь через создание RAID-0 из одного диска.
Также, если кэш контроллера нельзя полностью отключить в конфигурации RAID-0, следует настроить кэш контроллера на 100% операции чтения, фактически, отключив кэш записи. Но это наследие времен vSAN 5.5, забудьте про это. Все современные контроллеры умеют нативно прокидывать диск без этих извращений с RAID-0 из одного диска.
| IO Controller Mode | Drive Assignments | vSAN supported | Caveats |
| RAID | Every drive assigned as single drive RAID-0 | Yes, Tested | Must use RAID-0 and assign just a single drive per volume All drives on this IO controller must be assigned to either vSAN OR vSphere and not utilized for other actions. Write caching must be disabled on the controller. You are strongly urged to use Passthru/HBA mode if available |
| Passthru/HBA | Every drive visible as a raw device | Yes | All drives on this IO controller must be assigned to either vSAN OR vSphere and not utilized for other actions |
| Mixed | Every drive assigned as single drive RAID-0 | Yes | Must use RAID-0 and assign just a single drive per volume All drives on this IO controller must be assigned to either vSAN OR vSphere and not utilized for other actions. Write caching must be disabled on the controller. You are strongly urged to use Passthru/HBA mode if available |
| Mixed | Every drive visible as a raw device | Yes | All drives on this IO controller must be assigned to either vSAN OR vSphere and not utilized for other actions. Write caching must be disabled on the controller. |
| Mixed | Some devices assigned as single drive RAID-0, some as raw (Passthru) HBA devices | No | All the devices must be assigned for vSphere usage regardless of mapping as RAID or non-RAID. Be careful not to create an imbalance in your storage as RAIDed devices may exhibit a different performance profile that Passthru/HBA ones |
И небольшое отступление про необходимый объем кэш диска. В документах можно найти упоминание про 10%. Так вот, эти 10% считать надо от полезного записанного объема (не выделенный, а реальный) VMDK в capacity-tier, а не от объема дисков + не забывать про ограничение в 600 GB на кэш диск. Т.е. все что выше этого объема, как кэш использоваться не будет, а будет оставлен под замену вышедших из строя ячеек памяти.
Потому что 10% — это расчёт, что 10% от записанных данных идёт активное обращение гостевой ОС. Сколько там копий на бекенде совершенно не принципиально в случае vSAN, ибо чтение идёт со всех копий и требования к объёму, который надо хранить в горячей области не меняется при различном FTT (от х1 до х3 в разных зеркалах).
И не забываем, что чем больше дисковая очередь контроллера, тем быстрее выполняются задачи reconfiguring или resynchronizing.
Больше информации по контроллерам тут
И еще информация про выбор размера SSD под кэш
7. Queue Depth
Примеры глубины очереди контроллеров:
- LSI 2008 — 25
- Intel C602 AHCI — 31 (на порт)
- HP Smart Array P420i — 1020
- LSI 2308 — 600
vSAN Compatibility Guide можно глянуть тут
vSAN HCL viewer по которому тоже можно глянуть совместимость оборудования
Еще отличная статейка от наших коллег по чатикам, с чего начинать при подходе к vSAN.
8. Surprise Power Removal Protection / Power Loss Protection
Ну, тут все просто, если у диска нет защиты от потери питания, то есть приличный шанс, что данные превратятся в тыкву, т.к. не успеют записаться на диск.
Итоги
Если вкратце, vSAN может работать практически на любой дичи, но гарантированно стабильно, без потери данных при отключении питания, под нагрузкой 24\7, при записи не 10 гигов в сутки, без затупов при resync и прочее прочее. Оно будет работать хорошо только на нормальных контроллерах и дисках.
Надеюсь, данная статья закроет наконец вопросы на тему «почему стоит использовать серверные SSD, а не домашний SSD за ценник в 10 раз меньше и зачем мне такой дорогой контроллер».