Забавный факт: многие весьма продвинутые системные администраторы, специализирующиеся на свободном ПО (Open Source) имеют довольно приблизительное представление об основах производительности дисковых систем для серверов.
Возможно причина в том, что от одной крамольной мысли — о надежности СПО недалеко до другой — о надежности китайского «писюка» в серверных задачах. А поскольку, если разобраться, мысль эта часто бывает не так уж далека от истины, то и выходит, что администраторам, которые не сталкиваются с действительно серьезной дисковой нагрузкой удается творить чудеса на паре дисков SATA, объединенных в программный RAID. И это пользуется определенным спросом.
Между тем, любая конструкция имеет пределы нагрузки, и не лишним будет знание того, чем эти пределы определяются и как можно масштабироваться при их достижении.
Для начала немного теории
Производительность жесткого диска характеризуется двумя основными праметрами:
- скоростью линейного чтения/записи
- числом операций ввода-вывода в секунду, IOPS (I/O per second)
С линейным чтением/записью все, вроде бы, понятно: головка встает на трек, диск крутится, данные передаются со скоростью его вращения.
Для ширпотребного 7,200 RPM SATA-устройства скорость линейного чтения составляет порядка 50Мб/с. Причем, на внешней стороне блинов (в младших секторах данных) эта скорость заметно выше, чем на внутренней (порядка 15%).
А вот второй параметр — IOPS, часто ускользает из внимания. С точки зрения механики диска, операция ввода/вывода состоит из однократного позиционированиея головок и последующей передачи данных. Иными словами, ко времени линейного чтения данных прибавляется время на поиск трека и время на поворот диска до нужного сектора (в среднем — половина периода вращения).
И если если присмотреться к IOPS повнимательнее, можно обнаружить, что диск 7,200 RPM SATA способен совершить всего лишь около 80 операций в секунду.
Цифра поражает воображение? Если вдуматься, еще больше поражает воображение то, что подобный диск способен обслуживать центральную файлопомойку в организации на 100 активных пользователей с изрядным количеством автоматических информационных систем пилящих этот же файловый ресурс.
И тем не менее, на таком диске достаточно легко получить перегрузку (впрочем, экстремалы смогут еще изрядное время поотбиваться делая renice на непослушные smbd процессы ;)
Как выглядит перегрузка?
Изначально перегрузку можно обнаружить, контролируя параметр iowait (wio, wa), который выводтся командами top, vmstat, sar:
(распечатки в тексте получены с не нагруженной системы)
$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 475800 59484 116120 303464 1 2 4 153 18 38 13 7 78 2 1 1 475800 59400 116120 303476 0 0 0 532 314 774 4 5 91 0 1 0 475800 59544 116124 303476 0 0 0 192 341 770 2 6 89 3 0 0 475800 59524 116124 303476 0 0 0 0 274 564 0 3 97 0
Параметр wa (iowait) — это часть процессорного времени, а в целом, процессорное время складывается из user, system, idle и iowait, выраженных в %.
Ненулевой wa означает, что в течение этого времени процессор совсем ничего не делал (и не мог), поскольку все активные процессы пребывали в ожидании завершения запрошенных операций ввода-вывода.
Таким образом, если чудесная 4-процессорная система показывает wa 25%, то ее можно с уверенностью рассматривать уже как 3-процессорную :)
Более подробную информацию о вводе-выводе можно получить командой iostat:
$ iostat -kx 1 avg-cpu: %user %nice %system %iowait %steal %idle 12,51 0,10 6,51 2,39 0,00 78,49 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0,53 62,64 0,53 7,77 6,69 281,61 69,51 0,33 39,30 6,83 5,67 avg-cpu: %user %nice %system %iowait %steal %idle 1,50 0,00 4,00 0,00 0,00 94,50 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
r/s и w/s — это как раз IOPS на чтение и запись, а rkB/s, wkB/s — линейная скорость, которая будет тем больше, чем большие отрезки данных запрашиваются в рамках каждой операции.
Тем, кто интересуется подробностями, рекомендую почитать, к примеру, вот тут: http://www.ufsdump.org/papers/io-tuning.pdf.
Как масштабироваться?
Следует отметить, что перед тем, как масштабировать железо, обычно не грех провести оптимизацию операционной системы и приложений. Настройка kernel i/o subsystem, выбор подходящей файловой системы и ее параметров, настройка параметров баз данных, плановая дефрагментаця данных и оптимизация создающего нагрузку ПО способны натурально творить чудеса.
Тем не менее, данная статья об аппаратных возможностях — их и рассмотрим.
RAID
Все знают слово RAID, и что лучшие характеристики производительности можно получить, собрав RAID 5, 6, 10. Тут, правда, есть свои нюансы. Например, дешевые RAID-контроллеры работают гораздо медленнее, чем software RAID, поскольку упраляются лишь небольшой микросхемой, которой далеко до производительности современного центрального процессора. Да и программный Linux I/O scheduler, который умеет компоновать близкие дисковые запросы, после должной настройки, вроде бы, тоже не плох. В то же время, профессиональные контроллеры со специализированными процессорами и кэшом способны дать реальный прирост производительности за счет целого комплекса факторов.
В целом, апгрейд RAID-1 (2диска) до RAID-10 (4 диска) поднимет и линейную скорость и IOPS приблизително вдвое. Производительность RAID10 симметрична по скорости чтения и записи. RAID5 и RAID6 дают деградацию записи по отношению к чтению, связанную с необходимостью предварительного чтения блоков с контрольными суммами (это несколько упрощенно).
Характерно, что нагрузка большинства отдельных информационных систем вполне соответствует характеристикам RAID5,6: число запросов на запись в них меньше, чем запросов на чтение. А вот при конкурентной нагрузке на один массив от нескольких подобных систем можно ожидать мерзких нестабильных флуктуаций производительности.
Более подробную информацию о нюансах выбора и настройки RAID-систем можно поискать в сети.
SAS
В то же время, если в настоящий момент в Вашей системе используются SATA-диски, не стоит упускать еще одну возможность увеличить роизводительность дисковой системы — переход на серверные диски стандарта SAS (Serial Attached SCSI).
Чем SAS отличается от SATA?
- скоростю вращения: SATA — 7,200 RPM, SAS — 10k и 15k RPM,
- качеством механики: SAS имеет лучшее время поиска, чем SATA,
- наличием у SAS очереди команд TCQ, оптимизирующей физический i/o (до 15%),
- более высокой надежностью механики SAS,
- наличием двух интерфейсов к хост-контроллеру, позволяющих повысить надежность при подключении нескольких устройств на одну шину.
По производительности: диск 15k RPM SAS выдаст более 100Mб/с линейную скорость и порядка 180 IOPS, что более чем в двое превышает характеристики диска SATA.
Для подключения дисков SAS требуется специализированный контроллер.
Таким образом, применение дисков SAS для достжения повышенной производительности позволяет вдвое сократить число дисков, по сравнению с использованием SATA. Иногда это имеет большое значение.
Минусом такого перехода является стоимость: 15k RPM SAS 146Gb (не брендованый) стоит порядка $190, 300Gb — $270 против порядка $50 за 7,200 RPM SATA-II 300-500Gb (февраль 2011).
Еще порядка $150 придется отдать за SAS-контроллер (если нет встроенного).
SAS или SATA?
Во многих случаях применение SAS будет единственно верным решением. Например — использование в 1U серверах, способных вместить всего 2-4 диска, в прочих случаях, когда имеет значение 2-кратное сокращение физических размеров дисковой системы, в «тяжелых» серверах с растущими, высоконагруженными базами данных, а также в любых случаях когда технические риски и затраты на обслуживание менее надежного парка техники оцениваются дороже, чем возможная экономия бюджета.
С другой стороны, если факторы, которые изначально вынудили к применению для серверов не-серверных технологий (вроде дисков SATA) все еще сохраняются в бизнесе, то затраты на переход SATA -> SAS выглядят не столь оправданными — проще и дешевле до определенного момента масштабировать SATA RAID10 (конечно принимая повышенные риски, которые изначально несет данная конструкция).
P.S.
Автор статьи никаким образом не склоняет читателей к использованию не-серверных компонентов в серверных задачах. Подобный подход в большинстве случаев будет недальновиден или даже вреден с точки зрения перспектив развития бизнеса.
Однако, на данный подход существует определенный спрос и приведение сравнения SATA и SAS технологий видится полезным для тех, кто уже имеет SATA-системы в своем в хозяйстве.
http://www.fontanka.ru/2011/03/01/126/
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 475800 59484 116120 303464 1 2 4 153 18 38 13 7 78 2 1 1 475800 59400 116120 303476 0 0 0 532 314 774 4 5 91 0 1 0 475800 59544 116124 303476 0 0 0 192 341 770 2 6 89 3 0 0 475800 59524 116124 303476 0 0 0 0 274 564 0 3 97 0
А как же battery-backed write cache на аппаратном RAID-контроллере? А SSD? Или Flash-драйвы с кастомным (более быстрым чем SATA) итерфейсом? Или даже storage tiering (bbwc->ssd/flash->hdd)? Как-то тема не раскрыта.
storage tiering — это для SAN, дешевым тазикам это не к лицу :)
А вот о чем стоило рассказать — о полочках.
Попробую по порядку…
В случае линукса, работа BBWC дублируется механизмом i/o scheduler, который тоже достаточно эффективно дефрагментирует write-операции. Где-то (кажется, в комментариях, идущих с ядром) обсуждаются случаи, когда BBWC вообще лучше отключать.
SSD — это совсем отдельная тема. Все-таки, SAS и SATA это более-менее схожие компоненты — и по конструкции и по надежности (на фоне SSD). У SSD, пока что, все-таки несколько другое поле применения, хоть и смежное — оно, безусловно, представляет интерес, но в рамки этой статьи ИМХО не вписывается :)