Добавляет популярности СХД сегодня и системы, подобные OpenStack – ведь приятно управлять своими серверами не заботясь о том, что в одном сервере не работает диск, что одна из стоек обесточена. Не заботиться о том, что железо на одном Самом Важном Сервере устарело и для его апгрейда необходимо деградировать ваши сервисы до минимального уровня. Конечно, такие случаи могут быть ошибкой проектирования, но будем честны – все мы можем допустить такие ошибки.
В итоге компания встаёт перед непростым выбором: создать СХД самостоятельно на основе открытого ПО (Ceph, MuseFS, hdfs – есть из чего выбрать с минимальными затратами на интеграцию, но придется потратить время на дизайн и развертывание) или купить готовую проприетарную СХД и потратить время и силы на её интеграцию (с риском того что СХД со временем достигнет лимита своей ёмкости или производительности).
Но что если взять за основу Ceph, для которого сложно придумать невыполнимую задачу в области хранения данных, заручиться поддержкой какого-нибудь Ceph-вендора (например Inktank, которые его и создали), взять современные серверы с большим количеством SAS-дисков, написать web-интерфейс для управления, добавить дополнительные возможности для эффективного развертывания и мониторинга… Звучит заманчиво, но сложно для среднестатистической компании, тем более, если это не IT-компания.
К счастью, обо всём этом уже позаботились в компании Fujitsu, в лице продукта ETERNUS CD10000 – первой enterprise-СХД, основанной на Inktank Ceph Enterprise, с которой мы вас сегодня и познакомим.
Сам ETERNUS CD10000 представляет из себя конструктор из модулей. Модули – это x86-серверы с установленным Linux, Ceph Enterprise и собственными наработками Fujitsu. Такой дизайн СХД позволяет получить необходимый объём хранилища и постепенно расширять его в будущем. Модули бывают двух типов – модуль с данными и модуль с метаданными (а точнее – management node).
Серверы-хранилища сейчас представлены тремя моделями:
- Basic (12.6 ТБ в одном модуле, 1 SSD для кэша, 2U)
- Perfomance (34.2 ТБ, 2 SSD для кэша, 4U)
- Capacity (252.6 ТБ в одном модуле, 1 SSD для кэша, 6U)
Basic и Perfomance-ноды комплектуются 2,5-дюймовыми SAS-дисками, а в capacity-модули можно установить до 14 SAS-дисков и 60 SATA-дисков одновременно. Между собой хранилища общаются по infiniband – это касается операций репликации, восстановления утерянных копий блоков, обмена другой служебной информацией. В любой момент можно установить дополнительные серверы хранения, расширив тем самым общий дисковый объем хранилища – Ceph Enterprise перераспределит нагрузку на хранилища/диски. В общей сложности можно установить 224 сервера под данные. На сегодняшний день это около 56 петабайт, но объёмы дисков растут, возможности программной начинки в теории ограничены экзабайтом на одно облачное хранилище. Плюсом в этой ситуации становится то, что в ETERNUS можно будет добавлять серверы нового поколения совместно с серверами предыдущих поколений (и они смогут работать вместе). Устаревшие же ноды хранения со временем можно будет просто отключить «из розетки» – Ceph реплицирует недостающие данные на оставшиеся ноды без дополнительного вмешательства.
Management-ноды занимаются хранением логов и событий, происходящих в хранилище. Рекомендуется поставить 2 таких сервера, но в целом система может работать и в том случае, если management-нода перестанет быть доступной.
В CD10000 есть web-интерфейс, который позволяет проводить большинство операций с хранилищем и просматривать статус отдельных нод или хранилища в целом. Никуда не делся и классический CLI-интерфейс, знакомый многим администраторам, работавшим с Ceph напрямую. Проблем с «общением» у людей с этой системой возникнуть не должно.
Теперь о том как ETERNUS может «поговорить» с другими серверами. Для начала о железе – каждый сервер хранения подключается в обычную сеть 10-гигабитными интерфейсами. Если быть уж совсем точным – то двухпортовыми карточками PRIMERGY 10Gb Modular LAN Adapter (с чипом Intel® 82599 внутри них). Бутылочным горлышком они вряд ли станут.
На программном уровне все фантазии пользователей подобных продуктов тоже учли. Есть 4 интерфейса для клиентов хранилища:
- Liberados (предназначен для прямого взаимодействия с хранилищем при помощи готовой библиотеки из приложений, написанных на C/C++/Java/Python/PHP/Ruby)
- Ceph Object Gateway (RGW – здесь вас ожидает REST API, совместимое интерфейсом с Amazon S3 и Swift)
- Ceph Block Device (RBD – интерфейс для хранения томов виртуальных машин QEMU/KVM)
- CephFS (POSIX-совместимая сетевая файловая система, с драйверами для FUSE)
- По отдельному требованию клиента в его инсталляции может появиться дополнительный интерфейс из ряда стандартных сценариев
Сердцем, мозгом и душой Fujitsu ETERNUS CD10000 стал Ceph Object Storage (или RADOS) – он занимается распределением нагрузки между нодами/дисками, репликацией блоков, восстановлением утерянных реплик, перекластеризацией хранилища. В общем всем что касается производительности и надежности. Здесь не используются RAID-массивы в обычном их сценарии применения. Сложно представить, сколько займет ребилд одного массива на десятки дисков по 6 ТБ. И как часто он будет происходить.
А если дисков несколько тысяч? RADOS же решает проблему выхода дисков из строя быстрее – ему не требуется перечитывать поверхность всех блоков массива (в том числе и пустых, если сравнивать с тем же mdadm). Ему требуется только сделать дополнительные копии тех блоков, которые хранились на диске, удаленном из хранилища. Аналогично решаются и проблемы отключенных нод-хранилищ – RADOS сможет найти те блоки, количество реплик которых не соответствуют настройкам хранилища. Само собой, реплики одного блока никогда не будут храниться на одной ноде. Для каждого набора данных на программном уровне определяется размер блока, количество копий (реплик) каждого блока, и на каком типе носителей эти реплики следует создавать (медленные, быстрые или очень быстрые носители). Для наборов данных, где основное требование лежит в области экономики, а не скорости доступа, можно создать уровень хранения, напоминающий RAID 6. Хранить несколько копий данных может оказаться слишком накладным даже в многопетабайтной системе.
Внутри RADOS используется алгоритм CRUSH (Controlled Replication Under Scalable Hashing) – строится иерархическое дерево из оборудования разного уровня (стойка, сервер, диски), в котором содержится информация о доступных объёмах, расположении и доступности дисков. Исходя из этого дерева RADOS уже решает, где можно хранить копии блоков в необходимом количестве. Кстати, системный администратор может редактировать это дерево вручную. Этот же алгоритм обеспечивает и отсутствие необходимости в едином хранилище информации о том где искать блок – любой «железный» участник RADOS способен ответить на запрос о любом блоке данных, что избавляет нас от ещё одной точки отказа СХД.
В качестве приятной особенности можно отметить возможность работы Fujitsu ETERNUS CD10000 в нескольких датацентрах. Правда, скорость света не обманешь – не стоит размещать крылья кластера дальше, чем в 80 километрах по длине оптики друг от друга (что впрочем позволяет разместить кластер в двух разных городах Подмосковья, например), иначе из-за высокого RTT хранилище может работать некорректно. В таком случае СХД будет работать в режиме split-site конфигурации, но всё же она будет оставаться одной СХД с одним и тем же набором данных внутри.
Таким образом мы имеем СХД, которая легко интегрируется в любую инфраструктуру, отказоустойчива и надёжна в достаточной степени, основана на качественном оборудовании Fujitsu, легко масштабируется под разные объёмы данных и разные требования к производительности, избавлена от узких мест в производительности, при этом имеет статус enterprise-продукта и техническую поддержку от мировой компании с богатым опытом.
» Страница продукта на сайте Fujitsu
Спасибо за внимание, готовы ответить на ваши вопросы.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий