Мы спрашивали некоторых постоянных клиентов о том, почему они выбрали VPSville - https://vpsville.ru. Оказывается, большинство представителей малого и среднего бизнеса среди них при выборе площадки для хостинга сайта и других элементов it-инфраструктуры компании опираются на обещанные провайдером показатели безотказной работы и производительность.
Для тех клиентов, кто совсем не разбирается в цифровых технологиях, выбирать хостинг легко: если обещают, что всё будет работать, и просят за это адекватные деньги, то нам этот вариант подходит. На стороне провайдера всё не так просто, чтобы сохранить баланс между качеством услуг и их стоимостью нам нужно быть хотя бы на полшага впереди рынка — следить за инновациями и внедрять те, которые принесут выгоду и нам, и нашим клиентам. Использовать то, что будет просто дешевле, не сработает, может подорожать поддержка или просесть производительность. Поэтому, прежде чем VPSville перевел всех клиентов на NVMe, мы много пробовали, считали, анализировали.
Раньше все использовали SDS, мы тоже хотели
SDS — программно-определяемая система хранения данных — вариант для построения экосистемы без привязки к оборудованию. Когда мы ее внедрили, то оказалось, что очевидные на первый взгляд экономичность, отказоустойчивость и гибкость подхода на практике выливаются колоссальными расходами и адскими муками при администрировании.
Несколько лет назад SDS использовали все. У нас не было цели выделяться и становиться инноваторами, поэтому взяли курс на стандарт отрасли и занялись подбором оптимального программного решения для построения программно-определяемой системы хранения данных.
Оказалось, что когда речь не идёт об оборотах масштаба Amazon Web Services или Облаков от Google, возможность включать в систему хранения сравнительно недорогие серверы не даст никакой экономии. Дело в том, что не проприетарное программное обеспечение с достаточным для задач провайдера набором функциональных возможностей стоит настолько дорого, что нам бы пришлось поднять цены на услуги для клиентов в несколько раз. На такой шаг мы не были готовы, поэтому идея использовать SDS с треском провалилась.
Справедливости ради нужно добавить, что в 2021 программно-определяемые системы хранения данных строить дешевле, особенно если использовать комплексные решения от крупных вендоров. Но в нашем случае, реши провайдер сегодня радикально изменить модель хранения данных, переход на SDS будет невыгодным из-за необходимости перестраивать работающую экосистему, вплоть до переквалификации сотрудников.
Хранилище Ceph оказалось более выгодным, но временным
Ceph — тоже программно-определяемое хранилище, но с более гибкой архитектурой. Хотя и не без подводных камней. Когда мы взяли курс на Ceph, он еще не был так популярен среди провайдеров, тогда подход был уделом преимущественно частных ЦОД крупных компаний. Буквально, решение для внутренней инфраструктуры. Теперь уже нет, Ceph выбирают не меньше половины небольших провайдеров, нам бы он тоже подошел, если бы не появилось лучшего. Но давайте по порядку — тогда ВПСвилль экспериментировал с Ceph.
Из практического опыта, который, впрочем, далеко не уникален, нам удалось собрать собственный топ недостатков Ceph. Как оказалось позже, наши коллеги из Resellers Panel уже успели рассказать о похожем опыте у себя в блоге в статье The NVMe revolution. Тем не менее, мы своими тоже поделимся, кому-то обязательно пригодится.
1. Катастрофическое количество уязвимостей
Казалось бы, технология не новая и о ней всем всё известно. Но на практике всё не так просто. Когда мы начали использовать Ceph о подходе говорили мало и только хорошее. Мода делиться фейлами только зарождается, а в 2010-е вообще был период повального самолюбования, в айто тоже, так что при внедрении нам казалось — наши специалисты не допустят сбоев. Они и не виноваты, просто у Ceph слишком много уязвимостей и потенциальных проблем.
<iframe width="560" height="315" src="https://www.youtube.com/embed/_fWYUl2QsoI" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
Очень доступно и детально о том, что с Ceph практически не бывает всё гладко, рассказывал в своем выступлении «Ceph. Анатомия катастрофы» на DevOpsConf системный архитектор RCNTEC Артемий Капитула.
2. Скорость работы не пропорциональна размеру кластера
Простыми словами, правило — больше кластер даст выше скорость — с Ceph не работает. Мы убедились в этом на своем опыте. При достижения некоторого предела задержка становится настолько большой, что скорость обработки колоссально проседает.
3. Для работы с Ceph нужны профильные специалисты
Понятно, что специалисты нужны для любых задач. Но в случае с Ceph найти толковые кадры оказалось невероятно сложно, непонятно, то ли они все в DevOps ушли, то ли работать с этим видом хранилища настолько сложно, что мало кто решается развиваться в этом направлении. Но на деле, даже если предлагать зарплату выше рынка и рассылать офферы всем мало-мальски подходящим по набору компетенций кандидатам, укомплектовать штат достаточным количеством экспертов будет сложно. Растить своих тоже можно, но долго и дорого. Учитывайте это, когда решите строить экосистему на Ceph.
Стоимость Ceph с учетом всех его недостатков для того времени была приемлемой — наши клиенты получали качественный сервис за вменяемые деньги и даже не догадывались, чего нам стоила поддержка инфраструктуры и обеспечение бесперебойного доступа к данным. Впрочем, клиентам вообще лучше не знать таких нюансов, пускай в их мире провайдер остается всемогущим магом, способным обеспечивать 100% uptime в любых условиях.
Какие еще есть варианты хранилищ
Хранилище с прямым подключением, оно же — DAS, в определенных условиях удобнее, практичнее и дешевле Ceph. Такой тип хранилища экономичнее, потому что для обслуживания его не нужны кары с особыми навыками и тонкая экспертиза в улавливании малейших предпосылок к падению.
Ключевой недостаток подхода при всех его достоинствах — гибкости, скорости, масштабируемости, — сложное аварийное переключение. Справиться нажатием пары кнопок тут не получится. Вышедший из строя сервер нужно чинить буквально руками. Диски с данными из пережившего серьезный сбой DAS следует отключить от сломанной машины и подключить в исправную. Когда серверы стоят далеко в ЦОД, то скорость такого вынужденного переезда не зависит непосредственно от реселлера услуг хостинга. Это очень рискованно. Да и когда оборудование под рукой, всё равно такие сложности — это дополнительное время простоя, а в наше время это мало кто будет готов простить.
NVMe на JBOF — оптимальный вариант для провайдера в начале 2020-х
NVMe на JBOF оказалось тем самым важным звеном, вокруг которого в начале 2020-х проще всего провайдеру поставить работающую экосистему it с максимально возможной отказоустойчивостью и производительностью. В какой-то мере решения на базе NVMe на JBOF сочетают в себе лучшие качества SDS и DAS.
Вариант аппаратной стойки, который можно считать неким золотым стандартом для среднего по масштабам провайдера хостинговых услуг. Учтите сразу, что у решения есть минус — строгая привязка к вендору. Но если вас этом не смущает, то читайте дальше — чем так хороши NVMe на JBOF.
Начнем с большого минуса. SuperMicro предполагают возможности только для установки Linux и Windows. Если нужно что-то другое, то вариант не подходит, нужно искать что-то другое. Впрочем, рынок от недостатка предложений не страдает, включая самостоятельные продукты.
Плюсов больше. Забудем на минуту о привязке к конкретному вендору. Твердотельные накопители на базе флеш-памяти способны выдавать колоссально высокую по современным меркам производительность. Что касается JBOF, то это технология, обеспечивающая доступ к накопителю с других серверов так, будто они установлены на запрашивающем устройстве. Реализовать это проще всего на базе сети с RDMA. На этапе построения инфраструктура может показать довольно дорогой, но эксплуатационные расходы довольно скромные и скорострельность также нивелирует необходимость изначальных крупных вложений.
Еще о плюсах. В хранилище с использованием NVMe на JBOF нет необходимости в физической замене неисправных накопителей для восстановления работоспособности, что спасает от длительных простоев. В целом система оказывается стабильнее любых аналогов. Поэтому пока мы остановились именно на ней.
Статья во многом написана для тех, кому интересно заглянуть за кулисы работы провайдера услуг хостинга. Новички рынка тоже могут почерпнуть их неё кое что полезное, чтобы не наступать на уже опробованные нами грабли. Остальным же советуем почитать, хотя бы по диагонали, чтобы быть осведомленным о реалиях рынка аппаратных решений для построения it-инфраструктуры. В свете последних мировых событий очень полезно держать руку на пульсе трендов инноваций, так или иначе относящихся к удаленной работе.