Программно-определяемые СХД, или Что погубило динозавров?



    Когда-то они занимали вершину пищевой цепочки. Тысячелетиями. А потом случилось немыслимое: небо закрыли облака, и они перестали существовать. На другом конце света произошли события, изменившие климат: увеличилась облачность. Динозавры стали слишком большими и медленными: их попытки выжить были обречены на провал. Высшие хищники правили на Земле 100 миллионов лет, вырастая всё больше и становясь всё сильнее. Они эволюционировали в то, что казалось идеальным существом, находящимся на вершине пищевой цепочки, но Вселенная вмиг изменила облик нашей планеты.

    По иронии судьбы именно облака стёрли с лица земли динозавров 66 миллионов лет назад. Точно так же облака сегодня уничтожают классические системы хранения данных, находящиеся «на вершине пищевой цепочки». В обоих случаях проблема была не в самих облаках, а в способности адаптироваться к изменяющемуся миру. В случае с динозаврами всё случилось быстро: губительный эффект облаков наступил в течение дней или недель с момента падения метеорита (или извержения вулкана – выбор теории остаётся за вами). В случае с классическими хранилищами данных процесс занимает годы, но он, конечно же, необратим.

    Триасовый период: век большого железа и появление мигрирующих приложений


    Так что же произошло? В сложившейся экосистеме существовали СХД начального и среднего уровней, системы корпоративного уровня и СХД с прямым подключением (DAS). Эти категории были определены аналитиками, имели свои объёмы рынков, показатели стоимости, надёжности, производительности, масштабируемости. А потом случилось нечто странное.

    Появление виртуальных машин означало, что на одном сервере одновременно могло работать множество приложений, вероятно, нескольких владельцев – такие изменения сразу поставили под вопрос будущее СХД с прямым подключением. Затем владельцы крупнейших гипермасштабируемых инфраструктур (гиперскейлеры): Facebook, Google, eBay и т.д., уставшие платить огромные деньги за СХД, разработали собственные приложения, обеспечивавшие доступность данных на обычных серверах вместо больших «железных» СХД. Потом компания Amazon представила рынку нечто странное, именуемое Simple Storage Service (простая служба хранения данных) или S3. Не блок, не файл, а что-то принципиально новое: купить систему стало невозможно, появилась возможность купить только услугу. Погодите-ка, что это за яркий свет виден в небе? Ещё один астероид?

    Юрский период: эра «достаточнохорошезавров»


    Мы вошли в фазу развития СХД с идеологией «достаточно хорошо». Заказчики, использующие СХД, заметив, что сделали гиперскейлеры, начали ставить под сомнение справедливость десяти-, а то и стократной добавочной стоимости сверх железа, которую они платили за свои корпоративные СХД. Массивы среднего уровня начали отвоёвывать долю рынка у систем высшего звена. Такие продукты как HPE 3PAR показали быстрый рост. EMC Symmetrix, доминирующий когда-то массив (от слова «массивный») корпоративного класса, всё ещё удерживал какую-то территорию, но она стремительно уменьшалась. Многие пользователи стали переносить свои данные в AWS.

    С другой стороны инноваторы СХД стали заимствовать идеи у гиперскейлеров, используя технологии распределённых горизонтально масштабируемых систем – идеологии, противоположной вертикальному масштабированию. Ожидается, что новое ПО СХД сможет работать на обычных серверах, точно так же, как у гиперскейлеров. Больше никаких 10-100 кратных цен сверх стоимости самого оборудования. В теории можно использовать любые серверы – выбор зависит от ваших предпочтений. Эра программно-определяемых СХД (SDS) началась: облака закрыли небо, температура упала, и популяция высших хищников начала сокращаться.

    Меловой период: начало эволюции программно-определяемых СХД


    Ранние дни программно-определяемых СХД были бурными. Обещалось очень много, но поставлялось мало. Одновременно произошёл важный технологический сдвиг: флэш-память стала современной альтернативой «вращающейся ржавчине» (HDD). Это был период появления множества СХД-стартапов и легко раздаваемых венчурных денег. Всё было бы отлично, если бы не одна проблема: хранение данных требует серьёзного отношения. Оказалось, клиентам нравятся их данные. Если они теряют доступ к ним, или в терабайтах данных обнаруживается пара неправильных битов, они беспокоятся и беспокоятся очень сильно. Большинство стартапов не выжили. Заказчики получали крутой функционал, но не всё было хорошо с базовыми инструментами. Плохой рецепт.

    Кайнозойский период: массивы СХД доминируют


    Мало кто говорит о том, что случилось после, потому что это не очень интересно – клиенты продолжают покупать всё те же классические массивы СХД. Конечно, те, кто переместили свои приложения в облака, переместили туда же и данные. Но для подавляющего большинства заказчиков, которые не хотят переходить в облако полностью, или не хотят переходить совсем, та же Hewlett Packard Enterprise продолжила предлагать классические массивы.

    Мы живем в 2019 году, так почему же до сих пор существует многомиллиардный бизнес СХД, основанный на технологиях времен Y2K? Потому что они работают! Попросту говоря, требования критически важных приложений не реализовывались продуктами, создаваемыми на волне хайпа. Такие продукты как HPE 3PAR оставались наилучшими вариантами для корпоративных заказчиков, и новый виток эволюции архитектуры HPE 3PAR – HPE Primera – это только подтверждает.

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

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

    Третичный период: появление новых форм жизни


    Давайте попробуем разобраться, как одному из новичков на рынке СХД – компании Datera – удалось совладать с такой непростой смесью исторически устоявшихся и новых требований к СХД. Прежде всего за счёт реализации архитектуры, ориентированной на решение описанной выше дилеммы. Невозможно модифицировать старую архитектуру для решения задач, стоящих перед современным ЦОД, точно так же, как невозможно модифицировать архитектуру средней программно-определяемой СХД для удовлетворения требований, предъявляемым к системам корпоративного класса: динозавры не стали млекопитающими, потому что упала температура.

    Построение решения, соответствующего требованиям СХД корпоративного уровня и одновременно учитывающего всю ценность динамичности современного ЦОД, является непростой задачей, но это было именно то, что намеревалась сделать компания Datera. Специалисты Datera работали над этим пять лет и нашли рецепт «приготовления» программно-определяемой СХД класса предприятия.

    Главная трудность, с которой столкнулась Datera, заключалась в том, что приходилось использовать логический оператор «AND» вместо заметно более простого «OR». Стабильная доступность, «AND» предсказуемая производительность, «AND» архитектурная масштабируемость, «AND» оркестрация-как-код, «AND» стандартизованное оборудование, «AND» реализация политик управления, «AND» гибкость, «AND» управление на основе аналитики, «AND» безопасность, «AND» интеграция с открытыми экосистемами. Логический оператор «AND» на один символ длиннее, чем «OR» – в этом и заключается главное отличие.

    Четвертичный период: современные ЦОД и резкое изменение климата предопределяют развитие программно-определяемых СХД


    Так как же Datera создала архитектуру, отвечающую требованиям традиционных СХД корпоративного класса и удовлетворяющую запросам современного ЦОД одновременно? Всё опять сводится к этому надоедливому оператору «AND».

    Не было смысла решать одну за одной задачи по удовлетворению отдельным требованиям. Сумма таких элементов не станет единым целым. Как и в любой сложной системе тут была важна тщательная проработка всего комплекса сбалансированных компромиссов. При разработке специалисты компании Datera ориентировались на три основных принципа:

    • управление с учётом специфики приложений;
    • единый механизм обеспечения гибкости данных;
    • высокая производительность за счёт сниженных накладных расходов.

    Общее свойство этих принципов – простота. Простое управление системой, простое управление данными с помощью единого элегантного механизма и обеспечение предсказуемой (и высокой) производительности за счёт уменьшения расходов. Почему простота так важна? Опытные мастера из мира СХД знают, что невозможно обеспечить выполнение требований к СХД для современного динамичного ЦОД при помощи лишь гранулярного управления, множества инструментов по управлению данными и гипероптимизации для роста производительности. Комплекс таких методик нам уже знаком как СХД-динозавр.

    Знакомство с этими принципами сослужило хорошую службу для Datera. Разработанная ими архитектура обладает с одной стороны доступностью, производительностью и масштабируемостью современной СХД корпоративного класса, а с другой – гибкостью и скоростью, необходимыми для современного программно-определяемого центра обработки данных.

    Доступность Datera в России


    Datera является глобальным технологическим партнером компании Hewlett Packard Enterprise. Продукты Datera протестированы на совместимость и производительность с различными моделями серверов HPE ProLiant.

    Подробнее об архитектуре Datera вы сможете узнать на вебинаре HPE 31 октября.
    Hewlett Packard Enterprise
    88,03
    Компания
    Поделиться публикацией

    Комментарии 9

      0
      нестабильная доступность, непредсказуемая производительность и специфичные правила масштабируемости

      Я думал это нормальная статья, а не рекламная брошюра. Расскажите это S3 с durability в 9 девяток и доступностью в 2.

      Логический оператор «AND» на один символ длиннее, чем «OR» – в этом и заключается главное отличие.

      А тут вообще куда-то не туда вас понесло. В чем приемущества решения по сравнению с SDS? Где вообще описание решения? Я вижу только воду с «быстрее выше сильнее» и «пока корабли бороздят...» Или весь текст можно сократить до одной фразы?
      Подробнее об архитектуре Datera вы сможете узнать на вебинаре HPE 31 октября.
        0
        Не думаю, что Вы оценили бы сухой DataSheet. Про S3 как-нибудь расскажем, благо есть наработанный опыт внедрения объектных хранилищ, в том числе в РФ. Но упор сделаем на коммерческий продукт типа Scality. Будете читать? :)
        0

        У sds вижу 2 проблемы
        1 сплитбреин при 2х нодах
        2 непонятное поведение при выходе 50+% при большем кол-ве нод
        В рамках одной стойки что выбрать?

          0
          1. Минимальное количество узлов кластера – 3.

          2. Вопрос не совсем понятен. Что значит «выход 50+%»? Если имеется в виду выход из строя 50%+ количества узлов кластера, то здесь к Datera применяются те же правила, что и к любым другим распределённым системам. Например, если в кластере 18 узлов по 6 узлов в каждой стойке (3 стойки) выйдет из строя 2 стойки (12 из 18 узлов – 2/3 ёмкости), при тройной репликации все данные будут доступны, но нагрузка будет обеспечиваться оставшимися 6 узлами. Естественно, на время простоя 2 стоек это практически может означать снижение производительности, а если кластер находится под минимальной нагрузкой, то такой сбой может пройти вообще незаметно. Всё зависит от конкретных условий, но поведение прогнозируемо в зависимости от того, как конкретно используется кластер: какой-то «непонятности» здесь нет.

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

          Эти правила применимы практически к любым распределённым системам. Это означает в том числе то, что при планировании архитектуры с клаcтерами Datera могут быть использованы те же принципы и методы, что и для «обычных» распределённых приложений, каких-то специальных знаний не требуется. Это же касается и планирования кластера с одной стойкой.
            0
            при выходе из строя 2/3 узлов разве должно произойти самостоятельное отключение (отказ в обслуживанит) оставшихся 1/3? если нет, то как защититься от сплитбрейн?
              0
              Механизм синхронизации реплик Datera поддерживает консистентность данных в Read/Write режиме и при одной сохранившейся реплике. На практике случаи с одной сохранившейся репликой из трёх при одновременном отказе двух узлов случаются, это заложено на уровне базовой архитектуры, всё откатано в production, и проблем split brain не возникает.

              При возобновлении работы вышедших из строя узлов происходит автоматическая синхронизация устаревших реплик, до этого момента устаревшие реплики не будут использоваться при обслуживании запросов. Можно ещё заметить, что модификации (операции записи) в наборе реплик, формирующие отдельный том или volume, контролируются одной софтверной компонентой на одном узле с возможностью failover в случае выхода узла из строя.
                +1
                меня больше интересует сценарий не отказа 2 нод — тут все просто, а разрыва сети между нодами кластера — то есть кластер разделен на 2 части — в одной 1 нода, в другой — 2 — это и есть сплитбрейн. Исходя из того что вы написали, 1 нода будет продолжать обслуживать запросы на чтение/запись? Но в таком случае гарантии консистентности нет и быть не может — те самые файлы могли быть уже изменены в другой части кластера которые, с которой связи нет. Проясните этот момент, пожалуйста.
                  0
                  Теперь ясно, какой отказ имелся в виду изначально…

                  В случае кластера из 3 узлов А, Б, В и разрыва сети на сегменты (А) и (Б, В) произойдет следующее:

                  • модификация реплик обслуживаемых узлом А прекратится, т.к. активные реплики на узлах (Б, В) станут недоступны узлу А;
                  • успешная модификация всех в данный момент логически активных реплик является необходимым условием успешного завершения операции записи. Модификации реплик блоков отдельно взятого тома данных проходят через и управляются одним узлом. Поэтому параллельные модификации в части кластера (Б, В) или split brain невозможны в принципе и консистентность гарантирована;
                  • узел А будет выведен из кластера, новый список активных реплик будет состоять из (Б, В);
                  • клиентские точки соединений, управляемые до этого узлом А, будут подняты на узлах Б и В (failover).

                  Длительность описанного выше полностью автоматического процесса имеет секундный порядок. Это стандартный тест-кейс PoC.

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

                  Евгений, раз вас так интересует данная тема, пожалуйста, направьте свои контакты в личку. Обсудим интересующие Вас детали.
                    0
                    Спасибо за пояснение!

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое