HighLoad++ 2017 Зал «Пекин+Шанхай», 7 ноября, 18:00 Тезисы: http://www.highload.ru/2017/abstracts/2990.html Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД. В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот. ...

1. Технологии
хранения для
больших проектов
Сергей Платонов, «Рэйдикс»

2. Andy
Нужна СХД для вычислительного кластера
0,5 ПБ + 100 ТБ Y/Y
Совместное пространство имен
Обрабатываемый объем данных – десятки ТБ
Генерируется около 150 ТБ временных файлов
100 вычислителей
Требуется максимальная пропускная способность
Размер IO – 32-8096 kB
Высокая интенсивность записи

3. Решение Andy
DELL/EMC предложили
продукт ISILON
Andy решил строить
строить свой ISILON
*
* https://www.emc.com/storage/high-performance-computing.htm#!solution_description

4. Компоненты решения
Ceph c поддержкой BlueStore (дорелизная версия)
 Условно бесплатно  Высокая доступность
данных
 Масштабируемость Node-by-
Node
 Гибкость

5. Результат
Трехкратная репликация делает решение очень дорогим
От EC пришлось отказаться
Производительность записи – 4-6 GBps
Еще ниже в режиме N-to-1
Предложенное решение – Flash Cache

6. Файловые системы
Параллельные РаспределенныеКластерные
Прозрачность Устойчивость к отказам
Консистентность данных Балансировка нагрузки
Масштабируемость Доступ к данным
Shared Disk Shared Nothing

7. Когда плох Shared Nothing?
• Стоимость хранения для вас критична
• Высокая интенсивность записи (более 80% )
• Дополнительные IO загружают интерконнект
• Создается много дополнительных IO на запись
• Нагрузка а-ля HPC
• Требуемая производительность одного приложения значительно
превышает производительность подсистемы хранения узла

8. Параллельные ФС
Параллельная файловая система
 Доступ к одному набору данных от множества серверов
 Клиентское ПО эффективно распараллеливает нагрузку
 Большие размеры кластеров
 Зачастую – ассиметричная архитектура

9. Пример архитектуры ПФС

10. Распределение файлов
Lustre обладает двумя основными политиками: RR и QoS
BeeGFS имеет API для приложений

11. Решение c Lustre
SASSAS SASSAS
SCALEOUT NAS
DATA
MOVERS
 Объединение OSS/OST: LSI Syncro, ZFS,
SW RAID
 Отказ от внешнего хранилища
 Active/Active OSS и Active/Passive MDS
Клиенты
MDS/MGS

12. Результаты
• Производительность: 15 GBps
• Снижение стоимости инфраструктуры хранения на 65%
• В дальнейшем есть планы перевода постоянной СХД на
вертикально масштабируемую систему

13. Типичные ошибки использования Lustre
• Использование Lustre в качестве основного хранилища
• Оптимизация под высокую производительность
• Ребалансировка кластера
• Надежность схемы 1+1 для больших кластеров
• Возможен переход к N+M
• Использование Lustre для нетипичных задач (например, кластер
VM или Hadoop)
• Низкая производительность для 1 клиента
• Ограниченная поддержка ОС
• Отсутствие локальности IO

14. Jacob
Расширение существующего кластера HPC
10 ПБ
IBM Spectrum Scale, как основная ФС
Несколько кластеров хранения (> 20 000 узлов)
SGI DMF и 400 ПБ архивных данных
Новая сетевая инфраструктура 100 Гбит
Требуется универсальное решение для разных типов
задач
Требуется максимальная пропускная способность CХД
Размер IO – несколько сотен килобайт/мегабайт

15. Варианты решения
Ограничения по оборудованию
Не рекомендуется IBM для интенсивной записи

16. Выбранное решение
…
2 x IB 100Gbit
2 x SAS 12Gbit
6xRAID(28+3)
VM (NSD Server)
SR-IOR
6xRAID(28+3)
VM (NSD Server)
SR-IOR
AA Failover
Производительность узла 17GBps
Объем 1.5 ПБ

17. Shishido
Расширение существующего кластера HPC
50 ПБ
Общая система хранения данных
Несколько разнесенных площадок
Требуется единое пространство имен
Требуется максимальная пропускная способность CХД

18. Существующие решение

19. JBOD
BBU
Storage
Controller
BBU
JBOD JBOD………
Disk Storage Cluster
Data
Server
Storage
Controller
Data
Server
Полезный объем: 4,64 ПБ / 58 RAID6(8D+2P) LUNs + 12 HDDs spare
Data Storage with Data Server Cluster #1
Login node
(100GbE x 8)
….
Administration network switch
(GbE(T) x 96)
X 11 Clusters
(Total Usable Capacity: 51.04PB)
Meta data
Server
DB
Meta data
Server
DB
WEB ConsoleIPKVM
Administration
Server
Administration
Server
Administration
Server
Administration
Server
UPSUPS
64-port 100GbE switch
Switch
(40GbE/SR4 x 3)
Login node
(100GbE x 8)
64-port 100GbE switch
Switch
(40GbE/SR4 x 3)
Сетевая коммутация
GbE switch
#1 #2 #10
LCD KB＆MS
…. …. ….
Предложенное решение

20. BBU
Storage
Controller
Cache: 64GB
Data Server
Heart-beat
100GbE x 2
Полезный объем: 4.64 PB ( (RAID6 / 8D+2P) LUN x 58) per Cluster
↓
* Суммарный объем: 51.04 PB (4.64PB x 11 clusters → 51.04PB)
Cache sync
Storage
Controller
Cache: 64GB
BBU
JBOD
10TB x 58 ~ 60
#1
EXP EXP
JBOD
10TB x 58 ~ 60
#2
EXP EXP
JBOD
10TB x 58 ~ 60
#10
EXP EXP
592 HDDs (10TB SAS/7.2k HDD) per Cluster * HDD: HGST (MTBF: 2,500,000 hrs)
Data Server
100GbE x 2
48Gbps x 40 Mesh FABRIC connection
(bandwidth: 1920Gbps)
48Gbps x 8 Mesh SAN connection (bandwidth: 384Gbps)
10 JBODs => 58 x RAID6（8D+2P）LUN (580 HDDs)
+ 12 x spare HDD (2.06%)
…………
Предложенное решение

21. Gabriel
Нужна СХД для видеоаналитики
4 ПБ, возможен кратный рост объемов данных
Совместное пространство имен
10 узлов
MS Windows
Требуется гарантированная пропускная способность

22. Кластерные файловые системы
Небольшие кластеры имеют доступ к одному
набору данных
Поддерживают доступ к данным с различных ОС
одновременно
Часто являются надстройкой над локальной ФС
3 типа блокировок:
 Том
 Файл
 Чанк

23. Архитектура решения

24. Kevin
Медийная СХД для распределенных команд
3 ПБ
3 уровня хранения данных
1 Core ЦОД
Несколько географически удаленных Edge-площадок
Требуется максимальная пропускная способность в Edge
Размер IO – несколько сотен kb

25. Предложенное интегратором решение
Сервера хранения Сервера метаданных Удаленная площадка
iSCSI over WAN
MetaDataiSCSI
Решение предложено производителем серверов и кластерной ФС
Кластерная ФС

26. Результаты
• Постоянная потеря доступа к данным
• Нестабильная производительность
• Высокая стоимость подключения

27. Завершение
• Системы хранения данных с Shared Disk по-прежнему находят
применение в масштабных проектах
• Не существует универсального решения:
• Погоня за масштабируемостью имеет свою цену
• Производительность и стоимость хранения данных.