Flashcache — дёшево и сердито или альтернатива HW RAID 10 SAS
До 2014 года на серверах FirstVDS мы использовали промышленные HDD-накопители с
SAS-интерфейсом и аппаратными контроллерами, собранные в RAID 10. Это решение полностью устраивало нас в плане надёжности и производительности. Проблемы с частичной потерей клиентских данных были 3 раза за 12 лет использования. Два раза выгорали аппаратные контроллеры. Один раз вышла из строя батарейка и при аварийном отключении питания встроенная кеш-память рейда очистилась.
Однако SAS HDD дорогие. Для одного сервера мы брали комплект из 4 дисков по 600 Гб, аппаратного RAID-контроллера с батарейкой. Всё решение обходилось в 44 806 руб. за 1 Тб. Повышать цены на VDS мы не хотели. Нужно было найти более дешёвое решение, при этом не потерять в скорости и надёжности. А в идеале и увеличить предоставляемое для VDS место.
Только SSD — ещё дороже. На тот момент диски по 240 Гб стоили от 8000 руб. Дешевле было остаться на Raid 10 SAS, чем использовать SSD суммарным объёмом в 1 Тб. А увеличить хранилище и того дороже. Поэтому мы рассмотрели несколько программных решений и включили SSD в тесты, чтобы сравнить скорость. Таблица с результатами ниже.
Альтернативные решения
zfs — файловая система и менеджер логических разделов с адаптивным замещающим кешем, разработанная компанией Sun Microsystems. Zfs нельзя включить в оригинальную версию ядра Linux из-за несовместимости лицензий (CDDL vs GPL). Систему можно прикрутить DKMS-модулями, но усилия не стоят того – судя по публичным тестам скорость записи/чтения была невысока. Тестировать сами не стали.
bcache — разработка Google, в 2013 году была ещё сырой — не использовалась в продакшене. Работала только с CentOS 7, а мы использовали CentOS 6. Bcache тоже не стали тестировать.
lvm cache — технология Linux сообщества. Тоже работала только с CentOS 7, но публичных тестов на тот момент не было — решили провести сами. Цифры не понравились.
flashcache — разработан Facebook: компания внушает доверие, и технология уже была проверена в продакшене.
Flashcache работает в 3 режимах:
Так как write back — самый быстрый режим, выбрали для тестов его.
MD — software raid. Flashcache работает в паре с MD и Raid 1. Мы включили в тестирование MD без Flashcache, чтобы проверить, как он работает отдельно.
Итоги тестирования
Чтобы максимально приблизить условия исследования к реальным, запустили рандомную запись и чтение в файл 32 Гб (примонтированную файловую систему).
Flashcache в режиме writeback обошёл lvmcache и обогнал software raid. Сильно проиграл дорогим SSD, но главное, flashcache превзошёл наше решение на SAS HDD.
Новое решение с flashcache
По результатам исследования в январе 2014 года мы внедрили flashcache на SSD + SATA HDD.
С тех пор на одном сервере стоит 1 SSD и 2 SATA HDD по 4ТБ в зеркале. Технология работает в режиме writeback: быстро записывает данные в кеш и медленно скидывает на основной носитель.
При внедрении и обслуживании flashcache мы столкнулись с некоторыми особенностями технологии.
Особенности flashcache
1) SSD изнашивается
Из-за превышенного количества записей/перезаписей SSD перестаёт записывать новые данные. Чтобы этого не произошло мы мониторим SMART-атрибуты:
Программа мониторинга следит за этими значениями в автоматическом режиме и уведомляет сотрудников о проблемных дисках. Нам остаётся только вовремя их менять.
Раньше мы использовали диски 240 Гб, они работали меньше года. Сейчас технология over-provisioning позволяет нам увеличить резервную область диска и за счёт этого продлить срок жизни SSD. Диск объёмом 1 Тб мы режем до 240 Гб, это рабочая область, остальные 760 Гб – резерв на износ. Сейчас SSD в среднем работает 1 год.
2) Сбои, когда сгорает SSD и теряются несинхронизированные (грязные) данные
В режиме writeback данные сначала попадают в кеш SSD и только потом в память SATA HDD. Данные, которые не успели скинуться на SATA HDD, называются грязными. При сбое они безвозвратно сгорают вместе с SSD. При экстренном отключении питания SSD тоже может выйти из строя с потерей данных.
К счастью, сбои происходят не так часто. За 2,5 года у нас произошло два случая с потерей клиентских данных, которые не успели записаться в хранилище.
Уменьшить количество сбоев можно двумя способами:
3) Долго чистить кеш
Поменять SSD и настроить flashcache – 5 минут. Но перед этим нужно очистить кеш – скинуть все грязные данные на диски.
В среднем у нас 30% грязных данных на SSD, максимум – 70%. Очистка кеша занимает до 4 часов.
В это время система работает медленнее, потому что обращается к медленным носителям. Мы всегда предупреждаем клиентов о падении скорости, но форсировать процесс не можем. Скорость записи на SATA HDD зависит от того, насколько интенсивно клиенты используют диск. Чем интенсивнее используют, тем больше нагрузка и медленнее скорость записи.
4) Кеш может переполниться
Часто используемые данные находятся в кеше и называются горячими. На наших серверах их примерно 13%, максимум 62%. Такого объёма достаточно для быстрого чтения/записи всех VDS на сервере. Но переполнить кеш и снизить производительность может недоверие всего одного клиента.
Допустим, клиент захочет протестировать дисковую подсистему. Запустит программу рандомной записи файлов. Если диск клиента по объёму больше кеша, все плохо. Кеш переполнится и всё скатится в низкую производительность. Пострадают все VDS на сервере.
Если вздумаете провести такой тест, не ждите актуальных результатов. Мы программно ограничиваем нарушителю количество обращений на диск, это снижает скорость.
5) Flashcache не работает на Centos 7
После обновления ядра flashcache стал несовместим с Centos 7. Так как эта версия дистрибутива стоит на 50% наших серверов, проблема острая. Сейчас Centos 7 используется с sw raid1 с SSD. На трёх кластерах мы тестируем enhanceio — другую технологию кеширования — но пока не готовы озвучить результаты.
С 2013 года доллар подорожал в 2 раза. Поэтому решение с flashcache в рублях стоит почти также, как RAID 10 SAS, а в долларах в 2 раза дешевле.
Увеличив объём хранилища в 4 раза, мы сократили цену 1 Тб. Теперь он дешевле в 4 раза в рублях и в 8 раз в долларах.
Вывод
В 2014 году мы внедрили flashcache — увеличили предоставляемое для VDS место в 4 раза, и повысили скорость взаимодействия с дисковой подсистемой. Это решение вышло дешевле предыдущего, позволило нам снизить затраты и не повышать цены на VDS.
Под вопросом осталась надёжность, всё-таки с HW RAID 10 SAS было меньше сбоев. В мае 2015 для людей, которым принципиально важна надёжность и скорость мы ввели тарифы с SSD в качестве основного носителя.
SAS-интерфейсом и аппаратными контроллерами, собранные в RAID 10. Это решение полностью устраивало нас в плане надёжности и производительности. Проблемы с частичной потерей клиентских данных были 3 раза за 12 лет использования. Два раза выгорали аппаратные контроллеры. Один раз вышла из строя батарейка и при аварийном отключении питания встроенная кеш-память рейда очистилась.
Однако SAS HDD дорогие. Для одного сервера мы брали комплект из 4 дисков по 600 Гб, аппаратного RAID-контроллера с батарейкой. Всё решение обходилось в 44 806 руб. за 1 Тб. Повышать цены на VDS мы не хотели. Нужно было найти более дешёвое решение, при этом не потерять в скорости и надёжности. А в идеале и увеличить предоставляемое для VDS место.
Только SSD — ещё дороже. На тот момент диски по 240 Гб стоили от 8000 руб. Дешевле было остаться на Raid 10 SAS, чем использовать SSD суммарным объёмом в 1 Тб. А увеличить хранилище и того дороже. Поэтому мы рассмотрели несколько программных решений и включили SSD в тесты, чтобы сравнить скорость. Таблица с результатами ниже.
Альтернативные решения
zfs — файловая система и менеджер логических разделов с адаптивным замещающим кешем, разработанная компанией Sun Microsystems. Zfs нельзя включить в оригинальную версию ядра Linux из-за несовместимости лицензий (CDDL vs GPL). Систему можно прикрутить DKMS-модулями, но усилия не стоят того – судя по публичным тестам скорость записи/чтения была невысока. Тестировать сами не стали.
bcache — разработка Google, в 2013 году была ещё сырой — не использовалась в продакшене. Работала только с CentOS 7, а мы использовали CentOS 6. Bcache тоже не стали тестировать.
lvm cache — технология Linux сообщества. Тоже работала только с CentOS 7, но публичных тестов на тот момент не было — решили провести сами. Цифры не понравились.
flashcache — разработан Facebook: компания внушает доверие, и технология уже была проверена в продакшене.
Flashcache работает в 3 режимах:
- Write through — данные сначала пишутся на диск, а потом сбрасываются в кеш. Кешируется только запись.
- Write back — данные сначала пишутся в кеш, потом сбрасываются на диск. Кешируется запись и чтение.
- Write around — данные пишутся на диск, а в кеш попадают после первого чтения. Кешируется только чтение.
Так как write back — самый быстрый режим, выбрали для тестов его.
MD — software raid. Flashcache работает в паре с MD и Raid 1. Мы включили в тестирование MD без Flashcache, чтобы проверить, как он работает отдельно.
Итоги тестирования
Чтобы максимально приблизить условия исследования к реальным, запустили рандомную запись и чтение в файл 32 Гб (примонтированную файловую систему).
Flashcache в режиме writeback обошёл lvmcache и обогнал software raid. Сильно проиграл дорогим SSD, но главное, flashcache превзошёл наше решение на SAS HDD.
Новое решение с flashcache
По результатам исследования в январе 2014 года мы внедрили flashcache на SSD + SATA HDD.
С тех пор на одном сервере стоит 1 SSD и 2 SATA HDD по 4ТБ в зеркале. Технология работает в режиме writeback: быстро записывает данные в кеш и медленно скидывает на основной носитель.
При внедрении и обслуживании flashcache мы столкнулись с некоторыми особенностями технологии.
Особенности flashcache
1) SSD изнашивается
Из-за превышенного количества записей/перезаписей SSD перестаёт записывать новые данные. Чтобы этого не произошло мы мониторим SMART-атрибуты:
- Media_Wearout_Indicator – это время жизни или износ диска: значение для нового диска – 100, со временем оно уменьшается. Минимально допустимое – 10, при достижении этого значения диск становится пригодным только для чтения.
- Reallocated_Sector_Count – количество переназначенных секторов – должно быть меньше 100.
Программа мониторинга следит за этими значениями в автоматическом режиме и уведомляет сотрудников о проблемных дисках. Нам остаётся только вовремя их менять.
Раньше мы использовали диски 240 Гб, они работали меньше года. Сейчас технология over-provisioning позволяет нам увеличить резервную область диска и за счёт этого продлить срок жизни SSD. Диск объёмом 1 Тб мы режем до 240 Гб, это рабочая область, остальные 760 Гб – резерв на износ. Сейчас SSD в среднем работает 1 год.
2) Сбои, когда сгорает SSD и теряются несинхронизированные (грязные) данные
В режиме writeback данные сначала попадают в кеш SSD и только потом в память SATA HDD. Данные, которые не успели скинуться на SATA HDD, называются грязными. При сбое они безвозвратно сгорают вместе с SSD. При экстренном отключении питания SSD тоже может выйти из строя с потерей данных.
К счастью, сбои происходят не так часто. За 2,5 года у нас произошло два случая с потерей клиентских данных, которые не успели записаться в хранилище.
Уменьшить количество сбоев можно двумя способами:
- Использовать качественные серверные SSD. Что мы и делаем – покупаем диски Intel, Hitachi, Toshiba и др.
- Настроить репликацию кеша (зеркальный рейд). Решение предусматривает установку второго SSD, но из-за редких сбоев деньги на него мы зажали.
3) Долго чистить кеш
Поменять SSD и настроить flashcache – 5 минут. Но перед этим нужно очистить кеш – скинуть все грязные данные на диски.
В среднем у нас 30% грязных данных на SSD, максимум – 70%. Очистка кеша занимает до 4 часов.
В это время система работает медленнее, потому что обращается к медленным носителям. Мы всегда предупреждаем клиентов о падении скорости, но форсировать процесс не можем. Скорость записи на SATA HDD зависит от того, насколько интенсивно клиенты используют диск. Чем интенсивнее используют, тем больше нагрузка и медленнее скорость записи.
4) Кеш может переполниться
Часто используемые данные находятся в кеше и называются горячими. На наших серверах их примерно 13%, максимум 62%. Такого объёма достаточно для быстрого чтения/записи всех VDS на сервере. Но переполнить кеш и снизить производительность может недоверие всего одного клиента.
Допустим, клиент захочет протестировать дисковую подсистему. Запустит программу рандомной записи файлов. Если диск клиента по объёму больше кеша, все плохо. Кеш переполнится и всё скатится в низкую производительность. Пострадают все VDS на сервере.
Если вздумаете провести такой тест, не ждите актуальных результатов. Мы программно ограничиваем нарушителю количество обращений на диск, это снижает скорость.
5) Flashcache не работает на Centos 7
После обновления ядра flashcache стал несовместим с Centos 7. Так как эта версия дистрибутива стоит на 50% наших серверов, проблема острая. Сейчас Centos 7 используется с sw raid1 с SSD. На трёх кластерах мы тестируем enhanceio — другую технологию кеширования — но пока не готовы озвучить результаты.
С 2013 года доллар подорожал в 2 раза. Поэтому решение с flashcache в рублях стоит почти также, как RAID 10 SAS, а в долларах в 2 раза дешевле.
Увеличив объём хранилища в 4 раза, мы сократили цену 1 Тб. Теперь он дешевле в 4 раза в рублях и в 8 раз в долларах.
Вывод
В 2014 году мы внедрили flashcache — увеличили предоставляемое для VDS место в 4 раза, и повысили скорость взаимодействия с дисковой подсистемой. Это решение вышло дешевле предыдущего, позволило нам снизить затраты и не повышать цены на VDS.
Под вопросом осталась надёжность, всё-таки с HW RAID 10 SAS было меньше сбоев. В мае 2015 для людей, которым принципиально важна надёжность и скорость мы ввели тарифы с SSD в качестве основного носителя.
KERNELCARE
