О дисках для серверных систем начального уровня

Забавный факт: многие весьма продвинутые системные администраторы, специализирующиеся на свободном ПО (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
Системы хранения данных

3 comments


  1. iliya peregoudov

    А как же battery-backed write cache на аппаратном RAID-контроллере? А SSD? Или Flash-драйвы с кастомным (более быстрым чем SATA) итерфейсом? Или даже storage tiering (bbwc->ssd/flash->hdd)? Как-то тема не раскрыта.

    • G0LDEN_key

      storage tiering — это для SAN, дешевым тазикам это не к лицу :)

      А вот о чем стоило рассказать — о полочках.

  2. dmi

    Попробую по порядку…

    В случае линукса, работа BBWC дублируется механизмом i/o scheduler, который тоже достаточно эффективно дефрагментирует write-операции. Где-то (кажется, в комментариях, идущих с ядром) обсуждаются случаи, когда BBWC вообще лучше отключать.

    SSD — это совсем отдельная тема. Все-таки, SAS и SATA это более-менее схожие компоненты — и по конструкции и по надежности (на фоне SSD). У SSD, пока что, все-таки несколько другое поле применения, хоть и смежное — оно, безусловно, представляет интерес, но в рамки этой статьи ИМХО не вписывается :)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

captcha

Please enter the CAPTCHA text