Skip to content

Latest commit

 

History

History
116 lines (89 loc) · 8.98 KB

disks.rst

File metadata and controls

116 lines (89 loc) · 8.98 KB
Raw

Диски

Неразобранные мысли

  • Не имеет никакого смысла использовать рэйды как хранилище для Ceph. Здесь имеется в виду какой-либо способ программного или аппаратного объединения дисков в один виртуальный. Потенциальные проблемы:
    • Опасность обмана команд по сбросу кеша. Например, включенный Writeback на аппартаном RAID без BBU.
    • Программный RAID (mdadm, зеркало) ПОВРЕЖДАЕТ данные при записи в режиме O_DIRECT если в процессе записи страница меняется в параллельном потоке. В этом случае ПОДТВЕРЖДЁННЫЕ данные будут различаться в половинках зеркального рэйда. При следующем (scrub?) рэйда будут проблемы. TODO: Нужен proof.
    • Программные рэйды не защищают от сбоя питания -- да, разумеется вышестоящие FS/БД должны быть готовы к повреждению неподтверждённых данных, но при проверке (scrub?) различие данных на репликах приведёт к проблемам.
    • Во время смерти диска RAID находится в состоянии degraded пока не добавят новый диск. Либо нужен spare-диск который в случае с Ceph глупо не использовать. Degraded RAID внезапно для Ceph будет давать худшие характеристики пока не восстановится. RAID не знает какие данные нужны а какие -- нет, поэтому процесс восстановления реплик -- долгий -- синхронизирует мусор либо нули.
    • Для RAID нужны диски одинакового размера. Для Ceph это не требуется.
    • Аппаратные рэйды нужно отдельно мониторить и администрировать.
    • Зеркало не нужно потому что Ceph сам сделает столько реплик сколько требуется. Страйпинг не нужен потому что повышение производительности делается другими способами (с помощью SSD). Raid 5,6 в случае дегрейда причиняет боль.
    • В общем и целом, Ceph можно рассматривать как огромный распределённый RAID. Зачем делать RAID состоящий из RAID не понятно.
  • Акустик, хпа, паверсейвинг, настроить автотесты по смарту.
  • отдискардить ссд перед использованием.
  • fstrim -v -a (filestore on ssd), blkdiscard on LVM/Partition.
  • мониторить смарт
  • как бенчить - ссд и разного рода коммерческий обман. деградация изза недискарда - надо дать продыхнуть, некоторое количество быстрых ячеек и тиринг на них. суперкапазиторы. перегрев ссд и тхроттлинг
  • бенчмаркинг несколько дисков одновременно ибо контроллеры.
  • на ссд обновлять прошивки критично важно. ещё про блеклисты в ядрах насчёт багов.
  • дискард на них медленный, поэтому лучше оставить продискарденную область и этого достаточно.
  • жеоательно не ставить одинаковые диски с одинаковым юсаджем - ибо умрут скорее всего одновременно ибо нагрузка примерно одинаковая.
  • Диск шедулеры
  • имхо магнитные сас-диски не нужны. их возможности не будут задействованы для получения преимущества перед сата. Сата 12 гбит для магнитных дисков не нужен. Для магнитных (7200 оборотов) даже сата2 (3 гбит ~ 300 МБ/сек) хватит.
  • убедиться что диски подключены как сата6.
  • чего ожидать от бенчмаркинга. реальная таблица с реальными моделями.
  • при бенчмаркинге ссд может оказаться что уперлись в контроллер а не в диск.
  • NCQ, 7200 и 180 IOPS. 32 для большей возможности выбора в диске. Также как посчитать теоретические иопсы.

Типы SSD

Все SSD условно можно разделить на категории:

  • Consumer SATA (потребительские). Их ставят в ноутбуки и обычные компьютеры. Такие диски под нагрузкой могут вести себя непредсказуемо. Показатели могут меняться внезапно. Некоторые имеют производительность сравнимую с HDD или даже USB-flash.
  • Enterprise SATA (серверные). С защитой от сбоев по питанию и проверкой целостности данных. Например, линейка Intel DC имеет поддержку технологий power loss protection и end-to-end data protection. Такие диски производят только Intel, Fujitsu, и немного Samsung. Эти диски дают стабильные и предсказуемые показатели под нагрузкой.
  • NVMe SSD. Вставляются в PCIe разъемы и позволяют обойти ограничение SATA интерфейса в 6 Gbit/s ( ~500-550 MB/s ). NVMe SSD по сравнению с SATA SSD дают лучшие результаты в плане задержек и IOPS.

Планировщики IO

Планировщик -- это подсистема ядра, которая отвечает за обработку запросов IO и их передачу драйверу устройства. Планировщик задумывался как "умная" прослойка между софтом и железом, которая бы упорядочивала хаотичный поток запросов от приложений и делала бы его оптимальным для обработки на стороне устройства хранения. Для классических SAS/SATA дисков есть несколько планировщиков:

  • cfq -- планировщик, предназнaченный для десктопной нагрузки, по умолчанию имеет 64 очереди с разными классификаторами и весами. НЕ РЕКОМЕНДУЕТСЯ для SSD. (А ПОЧЕМУ?)
  • deadline -- планировщик с 4 очередями, 2 для запросов на чтение и 2 для запросов на запись. Рекомендуется для аппаратных RAID (ПОЧЕМУ?).
  • noop -- планировщик с 2 очередями, не имеет алгоритмов сортировки и слияния запросов. Рекомендуется для SSD, так как для SSD не нужно двигать головку и оптимизировать ее перемещение. Рекомендуется включать в виртуальных машинах.

С развитием SSD/NVMe появилась технология blk-mq (Multi-Queue Block IO Queueing Mechanism). Она позволяет обрабатывать IO запросы паралелльно в несколько очередей. По сути blk-mq не является планировщиком, а является частью драйвера (КАКОГО?). Рекомендуется для серверных SSD и NVMe.

  • Начиная с ядра Linux 4.12, для blk-mq появились свои планировщики:
    • bfq -- аналог cfq для десктопных ворклоадов.
    • mq-deadline -- аналог deadline.
    • kyber -- аналог noop.