Публикации
Защита высокоскоростного Ethernet WAN, статья
Pure Storage: платформа хранения для клауд эры, статья
Резервное копирование как основной компонент информационной безопасности, статья
Гиперконвергентная система AERODISK vAIR, статья
Big Data Flash – новый сектор AFA, статья
AI – следующая волна компьютеризации, статья
Veritas Access: программно-определяемое хранилище для неструктурированных данных, статья
Brocade Fabric Vision: новые возможности , статья
Cisco: машинное обучение для ИБ, статья
Toshiba представляет однокорпусные SSD-диски на основе 64-слойной 3D флеш-памяти, новость
 
Обзоры
Все обзоры в Storage News
 
Тематические публикации
Flash-память
Облачные вычисления/сервисы
Специализ. СХД для BI-хранилищ, аналитика "больших данных", интеграция данных
Современные СХД
Информационная безопасность (ИБ), борьба с мошенничеством
Рынки
ScaleIO: заоблачные перспективы

29, июнь 2016  — 

С момента своего появления в 2010 г. облако КРОК претерпело две значительные модернизации. Первая – в 2015 г. – связана с началом использования AFA-массивов Violin и продвижением сервисов с гарантированной производительностью. Вторая модернизация пришлась на 2016 г., когда был осуществлен переход с СХД на базе корпоративной файловой системы на гиперконвергентные SDS с использованием ПО ScaleIO, а также развертыванием файловой системы Ceph для объектного доступа вместо “рукописной”.

Антон Семчишен – менеджер по продвижению комплексных решений департамента вычислительных систем компании КРОК.

Предыстория развития облака

Публичные облачные инфраструктуры по мере своего развития нуждаются в модернизации программно-аппаратной базы. Это может быть обусловлено, например, стартом крупных проектов, реализация которых требует более гибкого и быстрого масштабирования инфраструктуры.

Как показал наш опыт, работоспособным инструментом для эффективного апгрейда облака в текущих условиях может стать внедрение программно-определяемых хранилищ. В частности, такое решение на базе свободно распространяемой системы Ceph было использовано нами при модернизации объектного хранилища, применяемого для хранения файлов, образов виртуальных машин, статистического контента. Это позволило упростить управление хранилищем, обеспечить бОльшую надежность и гибкость работы с данными.

Несмотря на то, что теоретически Ceph позволяет поддерживать блочный, объектный и файловый доступ к данным, после тестирования решения мы выявили два важных для нас недостатка: Ceph дает меньшую производительность при работе с высокопроизводительными SSD дисками в сравнении с обычными СХД. Кроме того, чем сильнее нагружается общее кластерное решение, тем больше утилизируются серверы, на которых развернута Ceph. В результате при достижении определенного уровня нагрузки целесообразность использования Ceph сводится на нет. Поэтому в настоящее время в составе облака КРОК Ceph используется только в качестве объектного хранилища.

По мере увеличения количества облачных заказчиков и усложнения сервисов, предоставляемых на базе облака, появляется острая необходимость усовершенствовать блочное хранилище, которое у нас развернуто с использованием кластерной системы GPFS. Ее эксплуатация стала слишком дорогостоящим удовольствием, т.к. отнимает очень много ресурсов на поддержание надежной работы и тестирование. В настоящее время на рынке наблюдается рост количества гиперконвергентных решений, в которых подсистема хранения данных представляет собой программно-определяемую СХД (SDS), распределенную по вычислительным узлам. При этом в качестве носителей используются встроенные диски. Такой подход к построению подсистемы хранения отлично вписывается в концепцию облачного сервиса – с ростом количества вычислительных узлов растет объем и производительность СХД. Чтобы окончательно определиться с поставщиком требуемого для нас решения для блочного хранилища, мы приступили к масштабному тестированию гиперконвергентных SDS-решений.

Сравнительное тестирование SDS-решений

Назначением всех представленных на рынке программно-определяемых решений является оптимизация инфраструктуры хранения. Вопрос состоял только в выборе наиболее подходящей системы, отвечающей нашим техническим требованиям (табл. 1).

Табл. 1. Требования к системе хранения, предъявленные в рамках тестирования КРОК.

Требования Пояснение
Производительность

Система должна иметь примерно следующую производительность c одного хоста (3 сервера с 4 флеш-дисками на каждом):

  • последовательное чтение —100к IOPs;
  • рандомное чтение — 40к IOPs;
  • последовательная запись — 20к IOPs;
  • рандомная запись — 10к IOPs.

*Данные взяты из максимума, полученного при тестировании

Отказоустойчивость Наиболее важные компоненты системы (серверы метаданных, серверы мониторинга и управления кластером) должны быть задублированы (active-active, active-standby). В случае active-standby важно время переключения на резервный сервис, просадка производительности (примерно в %) и время недоступности системы, если таковое будет
Надежность Все данные и метаданные должны иметь реплику и находиться на разных хостах кластера
Документированность Система должна иметь полную, подробную и поддерживаемую в актуальном виде документацию по архитектуре и управлению.
Управление Кластер должен управляться либо через web-интерфейс, либо через cli
Мониторинг

Желательно, чтобы система имела свои собственные утилиты мониторинга, которые можно привязать к существующим системам мониторинга.

В случае отсутствия таковых необходимо проработать возможность и методы мониторинга кластера самописными скриптами и привязки их к существующим системам мониторинга

Support or community Решение должно иметь профессиональный саппорт для заведения заявок или большое комьюнити для выяснения вопросов в случае необходимости
Масштабируемость Система должна понятно и прозрачно масштабироваться. При этом скорость ребалансинга системы должна контролироваться и изменяться в зависимости от нужд
Затраты ресурсов

Система должна затрачивать минимальное количество ресурсов как с серверной стороны, так и клиентской:

  • затраты CPU на серверной стороне;
  • затраты memory на серверной стороне;
  • затраты CPU на клиентской стороне;
  • затраты memory на клиентской стороне.
Поддержка с клиентской стороны Решение на клиентской стороне должно поддерживаться нативно, без использования fuse.

В частности, для нас было важно, чтобы решение, во-первых , поддерживало нагрузку, генерируемую виртуальными машинами. Во-вторых , данное ПО не должно сильно влиять на производительность узлов, на которых оно размещается.

В поиске оптимального варианта мы протестировали возможности восьми кластерных файловых систем. Для этого развернули стенд из 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) по загрузке системных ресурсов узлов.

ScaleIO
Ceph
write
read
mix (70R/30W)
write
read
mix (70R/30W)
mem_serv
750M
750M
750M
300M
300M
350M
cpu_serv
<10%
<10%
<10%
25-45%
25-47%
20-60%

Важные архитектурные особенности решения на базе EMC ScaleIO

В настоящее время дедупликация, компрессия, шифрование в составе решения EMC ScaleIO не поддерживается и не используется (при этом не следует забывать, что поддержка и криптографии, и дедупликации – это ресурсоемкие операции, прим. ред. ). Одним из важных преимуществ программно-определяемых СХД является возможность получения новых функциональных возможностей – в классических СХД, как правило, появление нового функционала, в лучшем случае, требует замены контроллеров. Например, во второй версии ScaleIO была добавлена возможность использования SSD дисков для кэширования данных, хотя это можно было реализовать и ранее с помощью аппаратной поддержки функции кэширования в контроллерах. Заказчики, которые сильно беспокоятся за безопасность данных, по-прежнему могут воспользоваться программными средствами шифрования на уровне ОС.

Все процедуры/сервисы данных, связанные с поддержанием доступности данных (например, репликация) реализуются в рамках одного кластера на одной площадке с использованием коммутаторов 56 Гбит/с Infiniband. Защита данных в кластере осуществляется путем дублирования данных между узлами кластера с фактором репликации 2 (единственный доступный вариант). При этом процесс репликации, очистки и равномерного перераспределения данных осуществляется автоматически, без вмешательства администратора. Роль управляющего кластера распределена как минимум между тремя серверами (выделенные серверы метаданных не используются). Настройки ScaleIO позволяют создавать так называемые домены доступности – мы можем настроить репликацию данных внутри кластера таким образом, чтобы блок данных и его копия никогда не находились в одной серверной стойке или одном машинном зале, что позволяет дополнительно увеличить доступность данных. Теоретически данный функционал может быть использован для репликации между ЦОДами, однако такая модель использования приведет к катастрофическому росту задержек внутри кластера, поэтому производитель рекомендует использовать для такой репликации специальное решение – RecoverPoint.

Антон Семчишен,

компания КРОК

Публикации по теме
Центры обработки данных
Современные СХД
 
Новости КРОК

© "Storage News" journal, Russia&CIS
Редакция: 115516, Москва, а/я 57; тел./факс - (495) 233-4935;
www.storagenews.ru; info@storagenews.ru.