Хранение данных — непростая задача, особенно когда к ним нужно обеспечить бесперебойный доступ. И сегодня мне хотелось бы поговорить о гиперконвергентных системах и связанных с ними программно-определяемых хранилищах, позволяющих использовать накопители в стандартных серверах х86 из того же кластера, что и вычислительные узлы. Чтобы не разводить холивара, сразу скажу, что в этом посте не будет глубокого технического разбора той или иной системы. Мы поговорим об архитектуре и особенностях ее применения в ЦОДе.

Итак, используем ли мы гиперконвергенцию в ЦОД Oxygen? Да, конечно. Будем ли мы рекомендовать ее для широкого спектра задач? Нет, не будем. Почему — подробнее разбираемся под катом.  

В прошлый раз крупными мазками я рассказал об архитектуре хранения, которую мы используем в ЦОДе Oxygen. Если коротко, то мы в основном работаем с СХД NetApp, которые позволяют кластеризовать дисковое хранилище и предоставить пользователям доступ не только к самой емкости, но также к инструментам управления и мониторинга. Подробнее — здесь.

В комментариях к посту мне попались вопросы про гиперконвергентные решения. И действительно, почему же не использовать подобные хранилища? Ведь они не требуют специализированного железа (а значит их проще реализовать), а кроме этого бывают не только чисто российскими, но и вообще бесплатными. Взять один только open-source проект Ceph…

Так что, можно все-таки решить вопрос гиперконвергентно?

Прежде чем дать ответ на этот вопрос, давайте разберемся, в чем именно заключается концепция гиперконвергентной системы. В сущности можно выделить два подхода.

Первый способ — истинная гиперконвергенция, когда в действительности для хранения данных используются ровно те же самые узлы, на которых происходят вычисления. В этом случае мы устанавливаем в серверы дополнительные диски и используем программный слой для распределения данных между ними. Тут чаще всего используется одна из разновидностей RAID, чтобы оптимизировать размещение данных. Такой подход неплохо подходит для задач, которым требуется определенный вид хранения. 

Второй способ — формирование программно-определяемого хранилища. В этом случае серверы используются специально как система хранения. В них устанавливается максимальное количество дисков, а общее хранилище используется одним или несколькими приложениями. В этом случае можно добиться большей скорости передачи данных и более высокой емкости.

3 причины, почему мы почти не используем гиперконвергенцию

Все это звучит красиво, верно? И в действительности в редких случаях мы прибегаем к организации гиперконвергентных хранилищ. Но следует учитывать ряд нюансов, которые мешают делать это повсеместно.

Емкость. В один сервер 1U, как правило, можно установить до 8 дисков (реже до 12) формата 2,5-дюйма. Таким образом, мы получаем 6 или 10 дисков (2 диска уходят на кеш) на 1U. На 2U мы получим 12 или 20 соответственно. Тем временем, дисковая полка или система хранения может вместить до 36 дисков, занимая те же самые 2U. Получается, что в той же стойке можно разместить намного больше данных при работе с СХД, чем с гиперконвергентной системой.

Стоимость. Что бы кто ни говорил о сложности ввоза хранилищ данных среднего уровня, их все равно поставляют сегодня в Россию. Можно назвать этот процесс параллельным импортом или как-то еще, но оборудование купить можно. И даже при подросших из-за сложной логистики цен, стоимость 1 Гб хранимой информации оказывается намного ниже для СХД. При этом стоимость систем SDS от VMware, NetApp, EMC и других поставщиков корпоративных систем, оказывается весьма высокой. Все это стоит денег и делает хранилище дороже по сравнению с отлаженным размещением данных в сетевых СХД.

Надежность. Если мы все же спустимся на уровень доступных и открытых SDS, не так много систем хранения позволяют изменить настройки хранилища без перезагрузки. Что уж говорить о, например, замене оборудования или обновлении версии. Тут возможны всякие неприятности, вплоть до необходимости отката, если система не будет загружаться в новой конфигурации. А что делать пользователям в это время, особенно если речь идет о mission-critical системах? В прошлом посте (ссылка) я уже рассказывал о том, что мы проводим обновление ПО и замены блоков СХД в облаке Oxygen, вообще не прерывая доступ пользователей к данным. У меня был опыт работы с целым рядом гиперконвергентных систем. Но сделать такое с ними (не буду называть имен) было практически невозможно.

Когда же все-таки нужна гиперконвергенция стораджа

Но, конечно, нельзя сказать, что гиперконвертентные хранилище вообще не нужны. Более того, мы используем их в некоторых случаях для решения задач наших клиентов. Из моего опыта, чаще всего подобные решения бывают полезны в следующих ситуациях:

Нужно организовать выделенное хранилище на 10 Тбайт. В ЦОДе находится изолированная от других систем инфраструктура одного из заказчиков. Требования к безопасности таковы, что данные не могут размещаться на одном оборудовании с другими клиентами — то есть мы не можем делить ресурсы одной СХД. Но создавать отдельное хранилище на 10 Тбайт — просто смешно! Поэтому прекрасно подойдет установка дисков в те же серверы, которые используются для вычислений…или в отдельные серверы в ту же стойку. Такой подход позволяет создать изолированное хранилище “малой кровью”. И это отличный кейс применения SDS-системы корпоративного уровня, потому что мы очень дорожим данными клиентов. 

Тестовая или любая другая среда без особых требований к доступности. Этот случай также касается изолированной инсталляции. Есть серверы, на них крутятся какие-то задачи, и при этом имеются как свободные слоты для дисков, так и неиспользованная пропускная способность сети в кластере. В этом случае для решения второстепенных задач можно использовать бесплатных или более доступных SDS (включая OpenSource). Кстати, оно может дополнять арендуемую емкость высокопроизводительных кластеризованных СХД, которая используется для критически важных задач.

Всему свое время и место

Подводя итог скажу, что использование SDS при хранении данных оказывается неоправданным для критически важных нагрузок, и поэтому мы в Oxygen используем подобные решения только для узких нишевых задач. Для других целей применяются кластеризованные СХД различного уровня. И это не приводит к росту тарифов на хостинг, в чем вы можете убедиться сами.

В следующем посте я подробнее расскажу о том, как мы решаем задачу резервного копирования в нашем ЦОД. Так что если вам интересно продолжение темы, подписывайтесь на наш блог и давайте обсуждать вопросы хранения данных дальше и глубже.