Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)

209 views

Published on

HighLoad++ 2017

Зал «Пекин+Шанхай», 7 ноября, 18:00

Тезисы:
http://www.highload.ru/2017/abstracts/2990.html

Мы ежедневно сталкиваемся с тем, что даже работающие более 15 лет в индустрии специалисты, путаются в понятиях и преимуществах и недостатках тех или иных архитектур больших СХД.

В своем докладе мы расскажем о разнице между distributed (распределенными), shared (общими) и параллельными файловыми системами, покажем, в каких задачах Scale In-системы превосходят Scale Out и наоборот.
...

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Технологии хранения для больших проектов / Сергей Платонов (RAIDIX)

  1. 1. Технологии хранения для больших проектов Сергей Платонов, «Рэйдикс»
  2. 2. Andy Нужна СХД для вычислительного кластера 0,5 ПБ + 100 ТБ Y/Y Совместное пространство имен Обрабатываемый объем данных – десятки ТБ Генерируется около 150 ТБ временных файлов 100 вычислителей Требуется максимальная пропускная способность Размер IO – 32-8096 kB Высокая интенсивность записи
  3. 3. Решение Andy DELL/EMC предложили продукт ISILON Andy решил строить строить свой ISILON * * https://www.emc.com/storage/high-performance-computing.htm#!solution_description
  4. 4. Компоненты решения Ceph c поддержкой BlueStore (дорелизная версия)  Условно бесплатно  Высокая доступность данных  Масштабируемость Node-by- Node  Гибкость
  5. 5. Результат Трехкратная репликация делает решение очень дорогим От EC пришлось отказаться Производительность записи – 4-6 GBps Еще ниже в режиме N-to-1 Предложенное решение – Flash Cache
  6. 6. Файловые системы Параллельные РаспределенныеКластерные Прозрачность Устойчивость к отказам Консистентность данных Балансировка нагрузки Масштабируемость Доступ к данным Shared Disk Shared Nothing
  7. 7. Когда плох Shared Nothing? • Стоимость хранения для вас критична • Высокая интенсивность записи (более 80% ) • Дополнительные IO загружают интерконнект • Создается много дополнительных IO на запись • Нагрузка а-ля HPC • Требуемая производительность одного приложения значительно превышает производительность подсистемы хранения узла
  8. 8. Параллельные ФС Параллельная файловая система  Доступ к одному набору данных от множества серверов  Клиентское ПО эффективно распараллеливает нагрузку  Большие размеры кластеров  Зачастую – ассиметричная архитектура
  9. 9. Пример архитектуры ПФС
  10. 10. Распределение файлов Lustre обладает двумя основными политиками: RR и QoS BeeGFS имеет API для приложений
  11. 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. 12. Результаты • Производительность: 15 GBps • Снижение стоимости инфраструктуры хранения на 65% • В дальнейшем есть планы перевода постоянной СХД на вертикально масштабируемую систему
  13. 13. Типичные ошибки использования Lustre • Использование Lustre в качестве основного хранилища • Оптимизация под высокую производительность • Ребалансировка кластера • Надежность схемы 1+1 для больших кластеров • Возможен переход к N+M • Использование Lustre для нетипичных задач (например, кластер VM или Hadoop) • Низкая производительность для 1 клиента • Ограниченная поддержка ОС • Отсутствие локальности IO
  14. 14. Jacob Расширение существующего кластера HPC 10 ПБ IBM Spectrum Scale, как основная ФС Несколько кластеров хранения (> 20 000 узлов) SGI DMF и 400 ПБ архивных данных Новая сетевая инфраструктура 100 Гбит Требуется универсальное решение для разных типов задач Требуется максимальная пропускная способность CХД Размер IO – несколько сотен килобайт/мегабайт
  15. 15. Варианты решения Ограничения по оборудованию Не рекомендуется IBM для интенсивной записи
  16. 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. 17. Shishido Расширение существующего кластера HPC 50 ПБ Общая система хранения данных Несколько разнесенных площадок Требуется единое пространство имен Требуется максимальная пропускная способность CХД
  18. 18. Существующие решение
  19. 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. 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. 21. Gabriel Нужна СХД для видеоаналитики 4 ПБ, возможен кратный рост объемов данных Совместное пространство имен 10 узлов MS Windows Требуется гарантированная пропускная способность
  22. 22. Кластерные файловые системы Небольшие кластеры имеют доступ к одному набору данных Поддерживают доступ к данным с различных ОС одновременно Часто являются надстройкой над локальной ФС 3 типа блокировок:  Том  Файл  Чанк
  23. 23. Архитектура решения
  24. 24. Kevin Медийная СХД для распределенных команд 3 ПБ 3 уровня хранения данных 1 Core ЦОД Несколько географически удаленных Edge-площадок Требуется максимальная пропускная способность в Edge Размер IO – несколько сотен kb
  25. 25. Предложенное интегратором решение Сервера хранения Сервера метаданных Удаленная площадка iSCSI over WAN MetaDataiSCSI Решение предложено производителем серверов и кластерной ФС Кластерная ФС
  26. 26. Результаты • Постоянная потеря доступа к данным • Нестабильная производительность • Высокая стоимость подключения
  27. 27. Завершение • Системы хранения данных с Shared Disk по-прежнему находят применение в масштабных проектах • Не существует универсального решения: • Погоня за масштабируемостью имеет свою цену • Производительность и стоимость хранения данных.

×