В текущих реалиях со сложностями в покупке новых массивов мне вспомнилась одна история, которая произошла пять лет назад. Она почти забылась, но теперь кажется вполне себе актуальной. Как-то раз к нам в компанию пришел один заказчик, который хотел СХД. Готовую СХД, попадающую в его бюджет, приобрести было нереально, а надо было не просто дешево и сердито, а дешево и нормально. Поэтому решили действовать креативно. Благо, у заказчика была некая поэтапность в развитии, и мы располагали достаточным количеством времени, чтобы постепенно наращивать объем хранилища.
Первый этап
Начальный объем удалось реализовать тогда на «старых и добрых» массивах вендора N. Важно, что заказчику требовалось место под хранение множества папок, внутри которых лежали бы файлы в видеоформате (компания работает в медиа сфере). Таким образом, нужно было построить «холодное» хранилище, не требующее особой производительности.
Далее мы спроектировали решение, базирующееся на Open Source софте GlusterFS версии 3.8, а также определились с оборудованием, в которое мы «засунули» много дисков, доступных по цене. Решение можно было горизонтально масштабировать, а также использовать еще под чьи-нибудь нужды.
Мы благополучно реализовали этот вариант и были уверены, что решение будет работать нормально. Однако, когда мы с заказчиком его протестировали, выяснилось, что открытие каждой папки занимает не менее 20 сек. А если два пользователя одновременно открывают одну и ту же папку, это время удваивается.
Медленно и печально
Мы долго не могли понять, с чем была связана такая низкая скорость. Ведь на предварительных тестах всё было в порядке! Когда начали копать глубже, поняли, что проблема не была связана с работой кластера. И проявлялась даже локально — на одной ноде.
При этом с дисками всё было ОК — они были загружены не полностью, и мы никак не могли упереться в их предельную производительность. Засада ожидала нас там, где мы могли ожидать ее меньше всего — сама файловая система XFS очень плохо работает с большим числом файлов.
Провели синтетический тест: создали скриптом папку, в которой хранилось 10 тыс. папок, и в каждой из этих папок — по миллиону небольших файлов. Всё — система сразу же легла, даже просмотр списка 10 тыс. папок был ну неприлично медленным.
Тут мы уткнулись в другое ограничение — Gluster тогда не позволял использовать никакую другую файловую систему, кроме XFS. А у нас уже готовый проект на руках. Всё пропало!
Вторая попытка
Пришлось начинать всё сначала, а также привлекать экспертов из соседнего подразделения. Для x86 сервера выбор файловых систем невелик: Linux и решения на его базе. Неужели, кроме нас, никто на рынке не сталкивался с подобной задачей?
Нашли одно недорогое коммерческое решение и стали искать более подробную информацию о нем на различных форумах и в ИТ-сообществах. Речь шла о файловой системе ZFS, созданной для ОС Solaris.
Сроки проекта уже конкретно поджимали, и времени на тесты практически не было. Выяснили, что ZFS уже портировали в Linux, и решили параллельно проверить этот вариант и какой-нибудь из форков Solaris.
На Линуксе ничего хорошего не вышло — ровно то же самое, что и было. На форке «Солярки» с драйверами под виртуализацию oVirt после нескольких попыток система заработала. Провели серию повторных испытаний на наших синтетических тестах — нормально работает, нет никаких нареканий. Файлы открываются мгновенно.
Проект, конечно, пришлось переписывать. Бэкэнд стал блочным на iSCSI, резервирование на уровне серверов удалось сохранить. Основная задача тем самым была решена — получили нужный объем для системы хранения требуемой производительности, используя при этом вычислительные ресурсы серверов для виртуализации.
На систему разработана подробная эксплуатационная документация, которой пользуется служба эксплуатации для выполнения регламентных процедур и для восстановления после типовых отказов.
Заказчик оказался доволен ☺ Созданное нами хранилище работает уже много лет, и работает корректно, без потери доступности и просадок производительности. При этом, емкость системы была увеличена в полтора раза. Если посчитать экономию — то по сравнению с СХД на одном известном производителе, мы выиграли 40 %.
История хоть и древняя, но не теряющая своей актуальности, особенно в новых условиях, когда перед компаниями стоит задача не столько в оптимизации бюджета на ИТ, а в поиске хоть какого-нибудь доступного и рабочего решения. Таким образом, применяя ИТ-смекалку, можно выйти практически из любой, даже, казалось бы, безвыходной ситуации. Делали ли вы что-то подобное? Расскажите в комментариях.