Ускорение raid5 md-массивов на запись

RAID5/6-массивы дисков — типичное решение для файловых архивов, к которым много запросов на чтение и мало на запись. Их слабое место: медленные операции записи, в которых для расчёта контрольной суммы требуется чтение со всех томов данных массива. Это приводит не только к медленной записи на массив новых данных, но и к медленному исполнению всех операций предполагающих модификацию раздела, в частности операции удаления. А если ещё и используется дешёвый вариант рейда на основе mdadm, без всяких батареек, кешей и специализированного софта для рейдов, то удаление большого количества файлов становится ну оочень медленной задачей.

Отчасти это можно исправить. raid5 при записи много читает, читает даже больше чем пишет. При удалении модифицируемые данные это структуры затрагиваемых файлов и директорий, в общем-то небольшого количества данных, но изменяемых многократно. Учитывая, что XFS (и другие устойчивые файловые системы тоже) делают это безопасно для отключения питания, т.е. собственно коммитом и через журнал. Поэтому, хороший прирост скорости удаления даёт изменение кеша чтения mdadm:

    echo 16384 > /sys/block/md?/md/stripe_cache_size

Параметр stripe_cache_size по умолчанию имеет значение 256 (страниц по 4Kb), что в большинстве случаев достаточно мало. Максимальное значение — 32768, при этом скорость достаточно хорошая уже при значениях 8192-16384. При увеличении параметра надо учитывать, что это значение в страницах для каждого устройства в рейде и он в результате может занимать весомую часть ОЗУ. Тем не менее, даже если ОЗУ не много, увеличение чаще имеет смысл.

Кроме этого способа, можно увеличить производительность вынесением журнала на отдельный раздел (и тогда раздел данных становится несколько зависимым от другого) или включением разных опций вроде nobarrier, которые сделают ФС быстрой но потенциально нерабочей в случае отключения питания. Это скорее не для продакшн-систем.

Восстановление RAID 10 массива

Поломался однажды RAID10 массив. Как обычно, все произошло внезапно: однажды перезапустили сервер, и получили "(что-то там) … not found". С поврежденным (degraded) массивом сервер стартовать отказался. Массив работал на полусофтовом-полухардварном псевдоконтроллере материнской платы Intel. Физически все жесткие диски оказались здоровыми, хотя для нижеописанного это не критично.

Далее следует описание восстановления информации с массива из серии "с помощью швейцарского перочинного ножа", т.е. без применения изощрённых средств восстановления. Если конкретно, понадобится компьютер с любым *nix и интерпретатором python3. Можно, конечно, воспользоваться программами вроде R-Studio, однако, по-моему это слишком простая задача для них.

Итак, делаем следующее. Открываем в бинарном редакторе все 3 диска и выбираем из них пару striped дисков, т.е. на которых чередующимися блоками составляют весь массив (как RAID 0). Делаем образы обоих жестких дисков в файлы с помощью замечательной утилиты dd по типу

dd if=/dev/sdX of=/tmp/vY.hdd bs=32M

В итоге получаем два больших файла v0.hdd, v1.hdd. С самими HDD далее не работаем.

Снова открываем с помощью бинарного редактора какой-нибудь из образов и определяем размер stripe-элемента (chunk size). Сделать это не сложно даже "невооружённым взглядом": ищется несколько этих кусков с чёткими границами. Легче всего это сделать на файле с вразумительным содержимом, или даже на любом — если свободное место (почти) заполнено нулями. В нашем случае размер stripe оказался 64K. При этом на одном из образов в начальном секторе сразу обнаружился MBR, а во втором нечто совсем не похожее на MBR. Так стал понятен порядок stripe от разных дисков.

Осталось почти ничего: брать поочередно chunks куски с разных дисков, складывать их последовательно и получить образ всего массива. Пишем для этого элементарный скрипт на питоне:

#!/usr/bin/python3
"""RAID0 recovery utility."""

dev0 = '/tmp/v1.hdd'
dev1 = '/tmp/v0.hdd'

DEV_OUT = '/tmp/out.hdd'

# stripe 64k
STRIPE = 64 * 1024
	
MAX_COUNT = 500 * 2**29 // STRIPE MAX COUNT

if __name__ == '__main__':
	f0 = open(dev0, 'rb')
	f1 = open(dev1, 'rb')

	f_out = open(DEV_OUT, 'wb')

	offset = 0
	while offset < MAX_COUNT:
		d0 = f0.read(STRIPE)
		d1 = f1.read(STRIPE)

		if d0 and d1:
			f_out.write(d0)
			f_out.write(d1)

			offset += 1
		else:
			print("One of input files are finished. Read: {0} blocks.".format(offset))
			break

	f0.close()
	f1.close()
	f_out.close()

Запускаем скрипт, оставляем его на ~10 минут и на выходе получаем полный образ диска. Разделы из него успешно монтируются самостоятельно или могут быть (всем образом) записаны на физический HDD. Так, совсем несложно и без дорогого софта, можно восстановить запоротый RAID10-массив.

Полезные команды для работы с LSI raid массивами

Несколько ранее я уже писал о замене HDD в рейд-массивах контроллеров LSI с помощью оригинальной утилиты MegaCLI. Список полезных команд этой утилиты намного шире, здесь я сохраню наиболее полезные из них.

В командах используются следующие параметры:

  • Адаптер: -aN. На сервере может быть установлено несколько физических RAID-контроллеров, номер нужного указывается параметром -a. Обычно установлен только один контроллер, для этого случая будет стандартный параметр -a0. Значением ALL можно указать сразу все доступные контроллеры.
  • Логический (виртуальный) диск: -Lx. Вместо x идет номер диска (начиная с 0). Также, допустимо значение ALL, выбирающий все доступные диски контроллера.
  • Физический диск: -PhysDrv [E:S]. E (Enclosure) — это номер корзины, S (slot) — номер слота начиная с 0.

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

Информация о корзинах (Enclousure) на всех контроллерах:

./MegaCli64 -EncInfo -aALL

Просмотр всех настроек контроллера 0:

./MegaCli64 -AdpAllInfo -a0
./MegaCli64 -ShowSummary -a0
./MegaCli64 -CfgDsply -a0

Получить состояние всех логических дисков:

./MegaCli64 -LDInfo -LALL -aALL

Информация о логических (виртуальных) дисках, т.е. собственно RAID-массивах:

./MegaCli64 -LDInfo -L0 -aALL

Информация о состоянии конкретного физического диска

./MegaCli64 -pdInfo -PhysDrv [4:11] aALL

Статус ребилда

./MegaCli64 -PDRbld -ShowProg -PhysDrv [4:11] -aALL

Логи контроллера

Одна из наиболее полезных комманд, когда ничего вроде не случилось, но что-то работает не так — просмотр логов. Это делается с помощью:

./MegaCli64 -AdpEventLog -GetSinceReboot -f events.log -aALL
./MegaCli64 -AdpEventLog -GetLatest 10 -f t1.log -aALL

Проверка прошивки

./MegaCli64 -PDList -aALL | grep Firmware

Диски горячей замены [hotspare]

Назначение диском горячей замены для определенного массива:

./MegaCli64 -PDHSP -Set -Dedicated -Array0 -PhysDrv[4:2] -a0

Назначить глобальным HotSpare-диском:

./MegaCli64 -PDHSP -Set -PhysDrv[252:2] -a0

Снятие статуса диска горячей замены:

./MegaCli64 -PDHSP  -Rmv -PhysDrv[4:2] -a0

Назначение загрузочного массива

./MegaCli64 -AdpBootDrive -set -L0 -a0

Параметры HDD S.M.A.R.T.

Параметры SMART можно получить с помощью стандартной линуксовой утилиты smartctl, если явно указать контроллер и id диска. Заранее необходимо собрать id исследуемых дисков, это параметр 'Device Id' в списке физических дисков. Можно собрать и все доступные id:

./MegaCli64 -PDList -a0 | grep 'Device Id'

Теперь для искомых дисков можно запрашивать смарт-параметры, например для id=5:

smartctl -d sat+megaraid,5 -a /dev/sdb

Расширение LSI raid массива

Как и в случае замены проверяем диски:

./MegaCli64 -pdInfo -PhysDrv \[4:4\] -a0
./MegaCli64 -pdInfo -PhysDrv \[4:15\] -a0

Добавляем диски в массив:

./MegaCli64 -LDRecon -Start -r6 -Add -PhysDrv[4:4,4:15] -l2 -a0

После можно смотрим статус массива и процент завершения:

./MegaCli64 -LDInfo -LAll -aAll

Замена диска в LSI raid-массиве

Время от времени жесткие диски выходят из строя и их необходимо менять. Далее описывается алгоритм такой замены на контроллере LSI MegaRaid SAS9260-4I с помощью оригинальной от производителя утилиты MegaCli.

Жесткие диски в экспандере пронумерованы по снизу вверх, справа налево (по столбцам, т.е. первый столбец снизу вверх идут диски 0-1-2-3 и т.д.). Будем менять 15 сыплющийся диск на исправный 10 в рабочем и здоровом RAID6-массиве. Состояние SMART 15-го диска можно посмотреть командой:

smartctl -d sat+megaraid,15 -a /dev/sdc

Для заменяемого диска находим счетчик перемещенных секторов Reallocated_Sector_Ct далеким от нулевого значения, что означает, что с диском не все в порядке. Информацию об ошибках носителя также можно обнаружить и в состоянии физического диска контроллера:

./MegaCli64 -pdInfo -PhysDrv \[4:15\] -a0

,
где Media Error Count отличен от нуля. 15 в этой команде — id диска на экспандере.

Все работы проводим на исправном массиве. Проверяем, что массив здоров (Optimal):

./MegaCli64 -LDInfo -LAll -aAll | less

Отключаем и вынимаем дефектный жесткий диск:

./MegaCli64 -PDOffline -PhysDrv \[4:15\] -a0
./MegaCli64 -PDPrpRmv -PhysDrv \[4:15\] -a0
./MegaCli64 -PDMarkMissing -PhysDrv \[4:15\] -a0

С помощью -LDInfo -LAll убеждаемся, что нарушен искомый массив и с помощью ./MegaCli64 -pdInfo -PhysDrv \[4:15\] -a0, что диск действительно вне массива.

Теперь необходимо добавить исправный 10-й диск взамен неисправного. Делается это с помощью команды

./MegaCli -PdReplaceMissing -PhysDrv [E:S] -ArrayN -rowN -aN

для которой нам потребуются номера Array и row. Эти числа берутся из вывода

./MegaCli64 -PdGetMissing -a0

Запускаем команду с нужными параметрами, она добавляет диск. Подтверждаем, что диск добавился корректно

./MegaCli64 -pdInfo -PhysDrv \[4:10\] -a0

и в выводимой информации присутствуют правильный номер Disc Group.

Заключительный шаг — запуск ребилда

./MegaCli64 -PdRbld -Start -PhysDrv \[4:10\] -a0

состояние которого можно посмотреть через некоторое время

./MegaCli64 -PdRbld -ShowProg -PhysDrv \[4:10\] -a0

Все вышеприведенное справедливо и для других контроллеров LSA аналогичных моделей. Кроме этого, утилита MegaCli умеет ещё много чего полезного, что легко находится в гугле.

SSD на серверах

memory-day memory-week

Сколько было сказано о бестолковости использования SSD на серверах, народ всё равно продолжает брать. Действительно полезен SSD лишь на очень узком круге круге задач, где требуется быстрый рандомный доступ к памяти на чтение. В остальных случаях прирост лучше обеспечивается или быстрыми RAID или увеличением RAM. Кому интересно почему последнее работает  — гуглит Page Cache.

В качестве примера выше приведены графики использования памяти (день, неделя) на типичном веб-сервере. Фиолетовая часть и есть тот самый кеш, который снижает нагрузку на input-output. На недельном графике на 11 число приходится перезагрузка, после которой кеш в последующие дни медленно наполняется.