Flashcache, или I/O на стероидах

Наверное, все уже в курсе, что одно из главных узких мест серверов — дисковая подсистема. Особенно это заметно на web-серверах и больших СУБД. Производители жестких дисков находятся в постоянной гонке за производительность, но против физики не попрешь — головка жесткого диска не может болтаться со скоростью света :).

Приходят SSD, казалось бы, вот оно — счастье! Нет механики, не надо ждать, пока головка доедет до нужной точки (особенно если данные фрагментированы или ОС пытается считать много всего сразу). Ан нет — дорого, ненадежно, места мало — в общем, на сервер не поставишь.

Какое решение? Правильно, совместить! Задача — получить скорость и время доступа SSD и надежность и обьем HDD. Существуют аппаратные решения, но мы же бедные экономически подкованные — поэтому будем делать программно.

Как все начиналось

Где-то с года два назад один мой друг ^[1] всерьёз занялся проектом сайта с подбором и продажей автомобилей из Германии. Сайт до этого жил на shared-хостинге и ужасно тупил — движок был написан непонятно когда и непонятно кем, главная страница генерировалась около 2-3 секунд. Быстрый рост посещаемости привел к переезду на отдельный, на котором он и живет до сих пор — акционный i7 от fastvps (реселлер hetzner). Через некоторое время load average в районе 8-10 стал почти нормой — стало понятно, что надо проводить ревизию кода.

Над одним моментом я смеялся довольно-таки долго — на главной странице был include, который работал около 3 секунд и непонятно что делал, но без него не работает. Результаты ревизии хоть и предсказуемы, но все равно печальны: оказалось, что проще всё переписать с нуля (чем мы сейчас и занимаемся), чем править то, что есть. Немного помогло вынесение некоторых блоков в SSI с кешированием (тогда там уже крутился nginx + php-fpm), но надо было что-то делать. Писать всё заново — долго (да и владелец до сих пор не совсем рад такому решению — привет, дядь Саш! :) ), стали искать альтернативные решения. Краешек сознания вытолкнул на поверхность где-то услышанную мысль — можно кешировать на SSD. Мысль покрутилась и утонула.

Полгода назад наступил переломный момент — улетели в Страну Мальборо сразу два (shit happens) жестких диска ^[2] в составе RAID-1. Пока hetzner менял HDD, решили — умирать, так с музыкой! И заказали в дополнение еще и SSD.

Что из этого получилось

Мы используем flashcache ^[3] от facebook, о котором на Хабре почему-то почти нет упоминаний.

Настраивалось всё полгода назад, делалось сразу с flashcache, поэтому для построения графиков «до» и «после» мне пришлось всё останавливать.

Итак, на графиках, кусками слева направо:

• работа с flashcache
• перерыв на отключение
• работа без flashcache напрямую с HDD (бедный zabbix из-за нагрузки не успевал сохранять данные — давайте его поймем и простим)
• перерыв на включение всего назад (тут я сделал ошибку, о которой позже)
• работа с flashcache
• перерыв на исправление ошибки
• нормальная работа в штатном режиме (с flashcache)

Загрузка CPU

Возвращаемся в старые добрые времена огромного LA:

Загрузка HDD и SSD

Здесь sda — HDD в составе RAID (mdadm), sdc — SSD, работающий как кеш. sdb — второй HDD из рейда, я не стал приводить график — там все очень похоже на sda.
Загрузка HDD:

Как видим, HDD становится очень плохо — время отклика доходит до 1 секунды.

SSD, здесь всё просто и понятно:

Время загрузки сайта

Замерялось время загрузки главной страницы ^[4] сайта. Там несколько SSI с блочным кешированием. Это мой любимый график:

По-моему, результаты очевидны.

Итоги и подводные камни

Наш сервер стал намного более отзывчивым, MySQL — шустрей (замеры не проводились), а волосы — более мягкими и шелковистыми.

Если ваш сервер еле дышит из-за большой нагрузки на i/o — не думайте. Ставьте flashcache. На странице проекта ^[3] есть неплохое описание, как его и с чем готовить. Я не буду на этом останавливаться — для этого существует документация. Хочу лишь осветить некоторые трудности, с которыми я столкнулся:

• Flashcache не работает на 32-битных системах. Там какая-то дурацкая ошибка в коде, которую никто не спешит исправлять — у Facebook всё окружение 64-битное.
• В комплекте есть hook и скрипты в initramfs для инициализации flashcache-томов в Debian при запуске, но он не работает для томов поверх lvm (т.к. в момент запуска lvm ещё не инициализирован). Я решил хаком — /sbin/vgchange -ay в начале скрипта. Неправильно, конечно, но тогда надо было сделать быстро.
• Категорически нельзя монтировать и использовать том, поверх которого работает flashcache (даже если он отключен). Ну то есть, конечно, можно, но flashcache тогда не будет знать о изменениях. Для меня это закончилось слегка побитой ФС после повторного запуска (третий провал на графиках). Правильно — останавливаем flashcache, отключаем его (dmsetup remove), делаем с томом все что надо, удаляем flashcache-том на SSD (flashcache_destroy), создаем flashcache заново. Для операций вроде проверки fs это всё делать необязательно — просто проверяем уже flashcache-том.

Автор: Obramko