|
ScaleIO: заоблачные перспективы
29, июнь 2016 — С момента своего появления в 2010 г. облако КРОК претерпело две значительные модернизации. Первая – в 2015 г. – связана с началом использования AFA-массивов Violin и продвижением сервисов с гарантированной производительностью. Вторая модернизация пришлась на 2016 г., когда был осуществлен переход с СХД на базе корпоративной файловой системы на гиперконвергентные SDS с использованием ПО ScaleIO, а также развертыванием файловой системы Ceph для объектного доступа вместо “рукописной”.
Предыстория развития облака Публичные облачные инфраструктуры по мере своего развития нуждаются в модернизации программно-аппаратной базы. Это может быть обусловлено, например, стартом крупных проектов, реализация которых требует более гибкого и быстрого масштабирования инфраструктуры. Как показал наш опыт, работоспособным инструментом для эффективного апгрейда облака в текущих условиях может стать внедрение программно-определяемых хранилищ. В частности, такое решение на базе свободно распространяемой системы Ceph было использовано нами при модернизации объектного хранилища, применяемого для хранения файлов, образов виртуальных машин, статистического контента. Это позволило упростить управление хранилищем, обеспечить бОльшую надежность и гибкость работы с данными. Несмотря на то, что теоретически Ceph позволяет поддерживать блочный, объектный и файловый доступ к данным, после тестирования решения мы выявили два важных для нас недостатка: Ceph дает меньшую производительность при работе с высокопроизводительными SSD дисками в сравнении с обычными СХД. Кроме того, чем сильнее нагружается общее кластерное решение, тем больше утилизируются серверы, на которых развернута Ceph. В результате при достижении определенного уровня нагрузки целесообразность использования Ceph сводится на нет. Поэтому в настоящее время в составе облака КРОК Ceph используется только в качестве объектного хранилища. По мере увеличения количества облачных заказчиков и усложнения сервисов, предоставляемых на базе облака, появляется острая необходимость усовершенствовать блочное хранилище, которое у нас развернуто с использованием кластерной системы GPFS. Ее эксплуатация стала слишком дорогостоящим удовольствием, т.к. отнимает очень много ресурсов на поддержание надежной работы и тестирование. В настоящее время на рынке наблюдается рост количества гиперконвергентных решений, в которых подсистема хранения данных представляет собой программно-определяемую СХД (SDS), распределенную по вычислительным узлам. При этом в качестве носителей используются встроенные диски. Такой подход к построению подсистемы хранения отлично вписывается в концепцию облачного сервиса – с ростом количества вычислительных узлов растет объем и производительность СХД. Чтобы окончательно определиться с поставщиком требуемого для нас решения для блочного хранилища, мы приступили к масштабному тестированию гиперконвергентных SDS-решений. Сравнительное тестирование SDS-решений Назначением всех представленных на рынке программно-определяемых решений является оптимизация инфраструктуры хранения. Вопрос состоял только в выборе наиболее подходящей системы, отвечающей нашим техническим требованиям (табл. 1). Табл. 1. Требования к системе хранения, предъявленные в рамках тестирования КРОК.
В частности, для нас было важно, чтобы решение, во-первых , поддерживало нагрузку, генерируемую виртуальными машинами. Во-вторых , данное ПО не должно сильно влиять на производительность узлов, на которых оно размещается. В поиске оптимального варианта мы протестировали возможности восьми кластерных файловых систем. Для этого развернули стенд из 6 серверов (6 SAS + 6 SSD дисков), 36 SATA и 36 SSD дисков по 12 дисков на сервер, использующих среду передачи данных на базе Infiniband (IPoIB). Некоторые из тестируемых решений были «отметены» сразу, другие проверялись достаточно долго в условиях разных нагрузок. Особое внимание уделялось также масштабируемости и отказоустойчивости. Из всего набора тестов особое внимание было уделено производительности. СХД, созданная на базе локальных дисков физичес-ких серверов под управлением EMC ScaleIO, «выдала» наилучшие результаты. Она была отказоустойчивой, в наименьшей мере нагружала серверы, что для нас было крайне важным, т.к. это предоставляло возможность запустить на тех же серверах максимальное число виртуальных машин. Как видно из табл. 2, работа Ceph занимает в подсистеме виртуализации от четверти до половины ресурсов CPU, что может быть приемлемо только при использовании этого решения на выделенных под нужды хранения серверах. Оба решения использовали в тестировании менее 1 Гбайт памяти, что является приемлемым при использовании современных конфигураций узлов кластера (256+ГБ). Табл. 2. Сравнение результатов тестирования ScaleIO и Ceph при нагрузке тестом FIO (3000IOPS 4k) по загрузке системных ресурсов узлов.
Важные архитектурные особенности решения на базе EMC ScaleIO В настоящее время дедупликация, компрессия, шифрование в составе решения EMC ScaleIO не поддерживается и не используется (при этом не следует забывать, что поддержка и криптографии, и дедупликации – это ресурсоемкие операции, прим. ред. ). Одним из важных преимуществ программно-определяемых СХД является возможность получения новых функциональных возможностей – в классических СХД, как правило, появление нового функционала, в лучшем случае, требует замены контроллеров. Например, во второй версии ScaleIO была добавлена возможность использования SSD дисков для кэширования данных, хотя это можно было реализовать и ранее с помощью аппаратной поддержки функции кэширования в контроллерах. Заказчики, которые сильно беспокоятся за безопасность данных, по-прежнему могут воспользоваться программными средствами шифрования на уровне ОС. Все процедуры/сервисы данных, связанные с поддержанием доступности данных (например, репликация) реализуются в рамках одного кластера на одной площадке с использованием коммутаторов 56 Гбит/с Infiniband. Защита данных в кластере осуществляется путем дублирования данных между узлами кластера с фактором репликации 2 (единственный доступный вариант). При этом процесс репликации, очистки и равномерного перераспределения данных осуществляется автоматически, без вмешательства администратора. Роль управляющего кластера распределена как минимум между тремя серверами (выделенные серверы метаданных не используются). Настройки ScaleIO позволяют создавать так называемые домены доступности – мы можем настроить репликацию данных внутри кластера таким образом, чтобы блок данных и его копия никогда не находились в одной серверной стойке или одном машинном зале, что позволяет дополнительно увеличить доступность данных. Теоретически данный функционал может быть использован для репликации между ЦОДами, однако такая модель использования приведет к катастрофическому росту задержек внутри кластера, поэтому производитель рекомендует использовать для такой репликации специальное решение – RecoverPoint. Антон Семчишен, компания КРОК |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
