суббота, 12 сентября 2009 г.

Линейное наращивание емкости и организация ZFS-пулов

Однажды на курсах мне задали интересный вопрос. Звучал он так:

При аттаче устройств в пул они добавляются в зеркало. А какую команду использовать, чтобы просто присоединить к пулу еще одно устройство? Как при конкатенированных RAID-томах?

Очень просто (значительно проще, чем сделать то же самое с Solaris Volume manager):

server5# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors

server5# zpool create data c0t0d0s6

server5# zfs list data
NAME USED AVAIL REFER MOUNTPOINT
data 89.5K 39.6G 1K /data

server5# zpool add data c0t1d0s6

server5# zfs list data
NAME USED AVAIL REFER MOUNTPOINT
data 110K 79.2G 18K /data

server5# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors
server5#

Недостатком подобных томов, как и в случае конкатенированных RAID-0, разумеется, будет невысокая производительность и полное отсутствие отказоустойчивости. Зато - полная емкость дисковых устройств. ;)

Не поможет ли гигантам мысли RAID-Z?

Попробуем:

server5# zpool create data raidz c0t0d0s6 c0t1d0s6

server5# zpool status data
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
raidz1 ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0

errors: No known data errors
server5# zfs list data
NAME USED AVAIL REFER MOUNTPOINT
data 89.5K 39.6G 1K /data

Нет. Не помог. Емкость не удвоилась.

Что до скорости, то давайте, пожалуй, оценим - что быстрее.

Вот результаты RAID-Z:

server5# date; mkfile 1g /data/test.file; date
Saturday, September 12, 2009 4:54:08 PM ALMT
Saturday, September 12, 2009 4:54:32 PM ALMT

26 секунд создавался файл 1 Гб.

Создадим снова конкатенированный ZFS-пул и посмотрим на его скорость:

server5# zpool create data c0t0d0s6 c0t1d0s6

server5# zfs list data
NAME USED AVAIL REFER MOUNTPOINT
data 1.00G 78.2G 1.00G /data

server5# zpool status data
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0

errors: No known data errors

server5# date; mkfile 1g /data/test.file; date
Saturday, September 12, 2009 4:56:10 PM ALMT
Saturday, September 12, 2009 4:56:20 PM ALMT

10 секунд создавался файл 1 Гб.

Создадим для сравнения зеркало ZFS и померяем скорость:

server5# zpool create data mirror c0t0d0s6 c0t1d0s6
server5# zpool status data
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0

errors: No known data errors

server5# date; mkfile 1g /data/test.file; date
Saturday, September 12, 2009 4:59:10 PM ALMT
Saturday, September 12, 2009 4:59:30 PM ALMT

20 секунд создавался файл 1 Гб.

А теперь вопрос - почему зеркало оказалось медленней, и неожиданно вырвался вперед конкатенированный пул?

Ответ очевиден. Взгляните на слайсы, образующие пул. Они сидят на одном контроллере.

Вот и весь ответ.

При подключении дисков на разные контроллеры скоростной перевес был бы у зеркала, а конкатенированный пул, напротив, проиграл бы при однопоточной записи (и чтении).

В данном случае против нас играет однопоточная запись и два диска на одном контроллере - и кэширование ZFS не играет никакой роли:

server5# date; mkfile 1g /data/test.file; date
Saturday, September 12, 2009 4:59:10 PM ALMT
Saturday, September 12, 2009 4:59:30 PM ALMT

server5# date; mkfile 1g /data/test.file; date
Saturday, September 12, 2009 5:06:32 PM ALMT
Saturday, September 12, 2009 5:06:52 PM ALMT

server5# date; mkfile 1g /data/test.file; date
Saturday, September 12, 2009 5:07:02 PM ALMT
Saturday, September 12, 2009 5:07:21 PM ALMT

Учтите одну вещь. Производительность дисковой системы - вещь сильно зависящая от физической топологии сториджа (контроллеры-шлейфы-диски), от количества шпинделей и, самое главное, от характера ввода-вывода.

В принципе, наш тест некорректен. Однопоточная запись одного файла - не тест.

Как практик, однако, могу заметить, что данная тенденция сохраняется почти всегда в реальных системах.

Говоря другими словами, и RAID-Z, и его родственник RAID-5 проигрывают в скорости зеркалу, причем тем сильнее, чем большее количество шпинделей при большем количестве контроллеров используется в массиве. И уж, разумеется, всяко больше, чем показали наши тесты.

Резюмируя вышесказанное и проделанное. ZFS-не чудотворная икона. Да, она масштабируемая и распараллеливаемая. Но - по-прежнему важна топология сториджа, по-прежнему важен адекватный выбор организации массивов соответственно задаче, по-прежнему родня RAID-5 в пролете по скорости.