Тема облаков в последнее время становится все более популярной.
Сейчас в РФ компании все больше понимают, чем это облако может им быть полезно, и даже начинают его активно использовать.
Чем больше компаний проявляют интерес к облакам, тем больше вопросов возникает к нам, разработчикам облачного ПО, по внедрению новых трендов и технологий, а также к поставщикам услуг, обеспечивающим отказоустойчивую работу платформы в целом.
В этой статье я хотел бы поделиться своим опытом только об одном аспекте облака, но, пожалуй, самый сложный и важный — это реализация дискового пространства.
Статью подготовил Андрей Нестеренко, эксперт по облачным технологиям компании.
МИРхостинг , которая является одним из хостинг-провайдеров, использующих Jelastic PaaS, которая в прошлом месяце объявила об открытии третьего региона облачной платформы — в России.
Во-первых, некоторая справочная информация о том, как работает облачная платформа в целом.
Да, мы говорим именно об облачной платформе, а не о продаже VPS и названии этого действия Cloud. Насколько мы понимаем, ключевыми отличиями являются отказоустойчивость (которая, в частности, автоматически исключает использование локального хранилища данных), доступ к «неограниченному» пулу ресурсов в любое время и плати как сможешь этих ресурсов, а не за лимиты или тарифы.
Техническая реализация такого облака требует взаимодействия всех элементов: оборудования, сети, оркестрации, технической поддержки.
Ниже мы поговорим о том, как мы реализовали только один компонент — отказоустойчивое дисковое пространство.
Программно-определяемое хранилище (SDS)
Технологически хранилище данных работает на основе Виртуозо Хранилище .Для тех, кто незнаком, идея аналогична другим реализациям SDS, наиболее известным решением с открытым исходным кодом является Ceph. Выбор Virtuozzo Storage вместо Ceph обусловлен, прежде всего, коммерческой поддержкой и развитием, лучшими ТТХ , и «заточено» под живую миграцию контейнеров и, как следствие, отказоустойчивость этих контейнеров.
Еще одна важная причина заключалась в том, что Jelastic предлагает такую интеграцию с VZ SDS «из коробки».
Я напишу о Virtuozzo Storage, но с небольшими изменениями.
Все это можно применить к Ceph и другим подобным решениям.
Итак, архитектурно Virtuozzo Storage состоит из двух компонентов: серверов метаданных и серверов фрагментов.
Данные разбиваются на так называемые куски, т.е.
по сути двоичные «куски».
Эти «куски» разбросаны по Серверам фрагментов, которых может и должно быть как можно больше.
На практике Chunk Servers — это отдельный диск (неважно HDD или SSD или NVME), то есть если у нас один сервер с 12 дисками, то у нас будет 12 Chunk Servers, которые обеспечивают производительность RAID 0. Разумеется, таких отдельных серверов должно быть несколько, чтобы гарантировать отказоустойчивость; 5 — минимальное рекомендуемое число.
Чем больше серверов и фрагментов, тем выше производительность и быстрее репликация в случае сбоя отдельных серверов фрагментов.
Метаданные сервера, соответственно, управляют всей этой путаницей фрагментов данных, разбросанных по множеству серверов фрагментов.
Для корректной работы необходим только один сервер метаданных, но если он выйдет из строя, весь кластер станет недоступен.
С другой стороны, чем больше серверов метаданных, тем сильнее падает производительность, поскольку любое действие ввода-вывода кластера должно записываться на все большем количестве серверов.
Существует также классическая проблема с разделенным мозгом: если один или несколько серверов метаданных выходят из строя, остальные должны оставаться в «большинстве», чтобы гарантированно быть активными и единственными.
Обычно для небольших кластеров имеется 3 сервера метаданных, а для более крупных — 5.
Вот как выглядит типичный кластер: 
(картинка из блога Virtuozzo, думаю ребята не будут против)
Администратор кластера может установить в глобальных настройках, сколько реплик должно быть гарантировано доступным.
Другими словами, сколько серверов фрагментов могут выйти из строя без потери данных? Предположим, у нас физически есть 3 сервера, на каждом из которых по 3 диска (сервера фрагментов) и мы установили рекомендуемое значение: 3 реплики.
Первое, что приходит на ум: что произойдет, если выйдет из строя один целый сервер и, соответственно, 3 сервера фрагментов на нем? Если 3 реплики некоторых данных были записаны только на эти 3 сервера фрагментов в пределах одного физического сервера, то эти данные будут потеряны, несмотря на то, что у нас все еще есть 2 физических сервера онлайн с 6 серверами фрагментов на них.
Чтобы справиться с этой ситуацией, вы можете настроить разные уровни репликации: на уровне сервера фрагментов (не рекомендуется), на уровне хоста (по умолчанию) или на уровне стойки и на уровне здания/расположения.
Возвращаясь к нашему примеру выше, при использовании значения по умолчанию — на уровне хоста серверы метаданных автоматически определяют, какие серверы фрагментов расположены на одних и тех же физических серверах, и обеспечивают репликацию на разные физические машины.
Чтобы репликация работала на уровне стойки или местоположения, вам необходимо указать, какая машина находится в какой стойке и/или месте.
В этом случае отказоустойчивость будет работать на уровне разных стоек или даже дата-центров.
Именно это мы и сделали в MIRhosting: данные распределяются по 2 независимым друг от друга дата-центрам.
Хватит теории, расскажи мне что-нибудь действительно интересное.
Итак, используя такие SDS-технологии, мы получаем теоретически идеальную отказоустойчивость, но теория и официальный документ на сайте — это одно, а практика и требовательные клиенты — совсем другое.
Первое, с чем нам пришлось разобраться, это сеть.
В обычной ситуации трафик между серверами фрагментов составляет около 200 Мбит и редко превышает 500 Мбит. Чем больше серверов, тем больше трафик «размазывается» по разным серверам.
Но в случае выхода из строя сервера/серверов чанка начинается срочная репликация для восстановления правильного баланса данных.
И чем больше у нас серверов, тем больше данных теряется, тем больше данных начинает летать по сети, легко создавая 5 Гбит и выше.
Таким образом, минимальным требованием является сеть 10 Гбит, а также 9000 MTU (Jumbo-кадры).
Конечно, если мы хотим обеспечить действительно хорошую отказоустойчивость и общую стабильность, то лучше иметь два отдельных коммутатора по 10 Гбит и подключать каждое хранилище данных через 2 порта.
Кстати, это решает и такой сложный вопрос, как обновление прошивки в свитчах.
Второе, что мы решили, — это обеспечить работу кластера на базе двойных дата-центров.
Первоначально сеть хранилища данных работала на чистом уровне L2. Однако с ростом облачной платформы в целом и объёмов хранения данных как её составляющей, в частности, мы пришли к логичному решению, что нам необходимо перейти на чистый L3. Этот шаг очень сильно завязан на другую тему — работу контейнеров в условиях двойных дата-центров и живой миграции.
Сеть хранения данных была сделана аналогично внутренней и внешней сети контейнеров, для унификации.
Тема достойна отдельной статьи, надеюсь, она будет интересна сообществу.
Никакого ухудшения производительности при переходе на L3 замечено не было.
В-третьих, и, вероятно, самое важное, это производительность.
Клиенты разные, у них разные требования, разные проекты, и в контексте публичного облака это становится сложной проблемой.
Само оно разделено на две части: общая производительность кластера ввода-вывода и разная требуемая производительность для разных клиентов.
Начнем с первого.
Во многом решение вопроса с производительностью осуществлялось случайным образом, поскольку лучших практик как таковых ни в документации, ни в информации от техподдержки Виртуозо нет. Очень помог один сотрудник техподдержки Virtuozzo, он провел около 30 минут своего времени на телефоне и многое мне рассказал.
Собрав всю имеющуюся информацию, добавив немного мозгов и пропустив через дуршлаг опыта, мы пришли к следующей схеме: 
Compute Node (узел, где запускаются контейнеры) — система работает на SSD, на нем расположен pfcache. Второй SSD, а с недавнего времени NVMe — для кэша клиента.
И один или два SSD/NVMe для локальных блоков.
Использование RAID1 возможно, но нам кажется, что на данном этапе развития SSD накопителей это не имеет особого значения, учитывая автоматическое восстановление контейнеров в случае сбоя (failover) в любом случае.
Кэш клиента оказывает меньшее влияние, чем фрагмент на вычислительном узле.
Система определяет ближайший доступный фрагмент и пытается использовать его для «горячих» данных.
Узел хранения (узел, который используется только для блоков, без контейнеров), очевидно, заполнен SSD и NVMe. Фактически, жесткие диски исторически использовались для создания «холодных» реплик.
Кэширование HDD не используется, а сами HDD мы пытаемся полностью заменить на SSD. Те системы хранения, в которых еще есть жесткие диски, должны работать через хорошую рейд-карту RAID0 с кэшированием записи, что повышает производительность этих жестких дисков.
Общая доступная производительность кластера напрямую зависит от количества чанков, то есть дисков.
Вторая задача — необходимость регулирования ввода-вывода в публичном облаке и различных запросов клиентов.
На каждый контейнер в облаке распространяются определенные ограничения ввода-вывода по количеству операций (IOPS) и пропускной способности (IO Limit Throughput).
На данный момент облако MIRhosting по умолчанию обеспечивает 500 iops и пропускную способность 200 Мбит/с, что почти вдвое превышает производительность жесткого диска SATA. Для подавляющего большинства клиентов этих цифр более чем достаточно, учитывая, что данные лимиты указаны для каждого контейнера, который клиент может создать в любом количестве.
Однако некоторым клиентам требуется повышенная производительность ввода-вывода.
Очевидно, это решается разными лимитами для разных клиентов.
Но экономически невыгодно иметь кластер, способный производить, скажем, 10 000 iops на контейнер (и иметь соответствующий резерв), и продавать его ресурсы с пониженными лимитами.
Есть хорошее решение — возможность использовать разные уровни в хранилище данных.
Допустим, первый уровень будет построен на SSD+HDD, а второй уровень — на SSD+NVMe. Мы обеспечим заявленные характеристики и сделаем это экономически целесообразно (что напрямую связано со стоимостью).
Перемещение контейнеров с одного уровня на другой происходит «вживую» и реализовано в Jelastic PaaS также с почасовой оплатой, как и другие облачные ресурсы.
Предположим, у нас есть один контейнер, который расположен на первом вычислительном узле.
Его файловая система разделена на 5 частей.
Также наш кластер настроен на использование 3-х реплик, то есть каждый чанк будет располагаться на 3-х разных серверах.
На первом слайде gif-изображения показано, как будут располагаться фрагменты при размещении на уровне 0. Ниже показан процесс сканирования фрагментов на носитель уровня 1. На данный момент ресурсы облачных хранилищ работают достаточно стабильно и сложно представить, как можно жить по-другому.
Выход из строя дисков и даже целых узлов не создает видимых проблем для клиентов и требует плановых действий по замене и добавлению дисков.
P.S. Уже в процессе подготовки этого материала была опубликована статья habrahabr.ru/post/341168 , где обсуждаются схожие вопросы и темы.
Наша статья отражает несколько иной взгляд на те же задачи и проблемы, и мы надеемся, что она будет полезна сообществу.
Также было бы интересно рассмотреть упомянутые в статье недостатки отдельно, но большая часть этих недостатков связана не с хранилищем данных как таковым, а с более глобальной работой облака, в частности с вопросами миграции.
Если тема интересна, можем поделиться собственными разработками по работе контейнеров внутри облака на базе двойных дата-центров.
В частности, со стороны сети и живой миграции внутри такой схемы.
В целом вынужден согласиться с SyCraft, что баги есть, а техподдержка Virtuozzo не всегда внятно говорит, что происходит и почему.
Однако это решение, по сути, единственное в своем классе, которое предоставляет необходимый набор сервисов, активно развивается и является коммерческим, то есть поддерживается разработчиками.
Вы можете попробовать такое решение отказоустойчивого дискового пространства в сочетании с автоматическим распределением и оркестровкой контейнеров с учетом специфики конкретного приложения от Jelastic PaaS, а также производительности инфраструктуры MIRhosting. зарегистрировавшись по ссылке .
Мы приветствуем ваши отзывы.
Теги: #Хранение данных #paas #отказоустойчивость #Хранение данных #Облачные вычисления #Высокая производительность #хранилище данных #контейнеры #облачная платформа #хранилище #программно-определяемое хранилище #облачный хостинг #виртуозное хранилище #MIRhosting #Jelastic
-
Заставляйте Посетителей Возвращаться
19 Oct, 24 -
Этот Неловкий Момент: 7 Самых Смешных Ошибок
19 Oct, 24 -
Инструкции По Спецификации Smpp
19 Oct, 24 -
По Следам Интеллекта 2
19 Oct, 24 -
Google Voice Теперь Доступен Для Iphone
19 Oct, 24 -
Несколько (Полезных) Советов Для Windows 7
19 Oct, 24 -
Что Такое Безопасность
19 Oct, 24 -
Zap-Ридер
19 Oct, 24
