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

    Наверное, все уже в курсе, что одно из главных узких мест серверов — дисковая подсистема. Особенно это заметно на 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-том.


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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 20

      +2
      Спасибо. Я пробовал его в начале года, он почему-то заполнил SSD до конца на стресс-тесте и покораптился, данные спасти не удалось. Слава богу это была тестовая система, разбираться не стал. На боевом в итоге использовал ZFS (новый нативный под Linux) с L2ARC.
        +1
        Странно. Полгода уже в продакшене, полёт нормальный. А разве у ZFS на Linux нет проблем с лицензией?
          +2
          Его просто переписали с нуля, поэтому нет.
        +5
        Опередили. У меня в черновиках развёрнутая статья по использованию flashcache.

        Впрочем, у статьи ещё есть шансы, т.к., собственно, особенности работы с flaschace (например, управление размерами блока для кеширования, разницы между режимами кеширования и т.д.) нет.
          +1
          Это всё есть в документации, я не стал переписывать. Я делал больше упор на опыт использования.
            0
            Да? Всё в документации? Ну, расскажите, на что влияет смена though на around?
              +3
              Choice of Caching Modes:
              =========================
              Writethrough — safest, all writes are cached to ssd but also written to disk
              immediately. If your ssd has slower write performance than your disk (likely
              for early generation SSDs purchased in 2008-2010), this may limit your system
              write performance. All disk reads are cached (tunable).

              Writearound — again, very safe, writes are not written to ssd but directly to
              disk. Disk blocks will only be cached after they are read. All disk reads
              are cached (tunable).

              Writeback — fastest but less safe. Writes only go to the ssd initially, and
              based on various policies are written to disk later. All disk reads are
              cached (tunable).

              Cache Persistence:
              =================
              Writethru and Writearound caches are not persistent across a device removal
              or a reboot. Only Writeback caches are persistent across device removals
              and reboots. This reinforces 'writeback is fastest', 'writethrough is safest'.
                0
                Это из FlashCache System Administration Guide, если что.
                  +1
                  О, они это описали. Помню, на этапе внедления у нас этого абзаца не было и я по сырцам выяснял разницу.
                    +1
                    В любом случае, с удовольствием прочту ещё и Вашу статью. Доки много не бывает :).
                      0
                      А вы flashcache где-то используете?
                        0
                        да мелочи какие-то, типа облачного хранилища для облачного хостинга.
                          0
                          Ну я в курсе что Селектел, да. Вот и спрашиваю — используется оно там или нет.
                            0
                            многократно описывалось (возможно, только в комментах), многоуровневую систему кеширования. в том числе — flashcache.
                          +1
                          Да, используем.
                  0
                  Давайте развернутую. Данная упоминает описание на странице проекта, которго кроме краткого РИДМИ не видно.
                +1
                Какие отличные шаблоны для заббикса. Поделитесь, пожалуйста.
                  +2
                  Это Zabbix Template Collection (ZTC) от Владимира Русинова. Кроме последнего графика.
                    0
                    Спасибо. Невнимательно я ZTC в последний раз просмотрел. Гляну еще раз.

                Only users with full accounts can post comments. Log in, please.