Pull to refresh

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

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

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

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


Что такое flashcache


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

Flashcache был создан внутри Facebook для ускорения MySQL (и других СУБД) на своих серверах и в 2010 году выложен как open source.

Суть его проста: это прозрачный кеш на SSD. На основе двух блочных устройств (обычно hdd — «откуда» и ssd — «куда») создается еще одно, кешируемое, которое и используется системой. Прозрачный кеш на SSD позволяет соединить воедино плюсы как HDD, так и SSD.

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


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

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

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

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


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

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


Загрузка CPU



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


Загрузка HDD и SSD


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

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

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




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


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



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

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


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

Если ваш сервер еле дышит из-за большой нагрузки на i/o — не думайте. Ставьте flashcache. На странице проекта есть неплохое описание, как его и с чем готовить. Я не буду на этом останавливаться — для этого существует документация. Хочу лишь осветить некоторые трудности, с которыми я столкнулся:
  • 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-том.


На правах рекламы, актуально для хабраюзеров из Украины
У нас на сайте можно найти и заказать автомобиль из Германии, в том числе «под ключ».
Tags:
Hubs:
+16
Comments 20
Comments Comments 20

Articles