На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений. В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание. В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).

1. Эволюция программно-аппаратного
обеспечения хранения фотографий в Badoo
Какое ПО и “железо” использует Badoo,
для хранения фотографий и видео более
300 млн пользователей

2. Вступление
Мы храним много фото:
• Количество пользователей - более 320 млн.
• Число стран и регионов - 237?
• Общий объем хранимых фотографий и видео ~ 3 PTiB

3. Производительность, стоимость,
надежность. Поиск компромисса.
Сочетание
производительности,
надежности и стоимости -
определяет то как будет
выглядеть ваша СХД

4. Первый рабочий вариант СХД - 2009

5. Использование классических
мультиконтроллерных СХД
Основные компоненты:
• SAN - Fibre Channel
• Коммутаторы Qlogic/Brocade (4/8 Gbit)
• Адаптеры шины HBA (Emulex/Qlogic)
• Хранилища на базе LSI Engenio - Active-Passive
• Хранилища на базе Hitachi AMS 2500/2300 - Active-Active (ALUA)
• Вычислительные узлы - Oracle SunFire / HP ProLiant

6. Хранилищесдвумя
контроллерами

7. Проблемы в ходе эксплуатации
Технические:
• Переполнение очереди (512/число хостов/число lun <=32)
• Десинхронизация контроллеров
• Одновременный сбой носителей
• Ограничение числа конфигураций LUN-Masking
• Недостаточный инструментарий мониторинга

8. Проблемы в ходе эксплуатации
Организационные:
• Сложность резервирования и восстановления конфигураций
• Отсутствие документации
• Затянутые сроки ремонта и закупки компонентов
• Отсутствие оборудования на рынке

9. Доработка системы хранения и
кэширования фотографий
• Кэширование чтений на отдельной ферме машин.
• Унификация узлов. Отказ от Polyserve и переход на Ext3
• Замена RDAC на Linux MP/IO
• Реконфигурация SAN - Zoning, Fabric Interconnect.
• Ограничение зон видимости LUN - LUN Masking
• Введение кэширующего слоя на вычислительных узлах
• (flashcache/dm-cache)
• Увеличение объема ОЗУ на узлах
• Увеличение объема хранилищ - замена накопителей и
подключение новых дисковых полок

11. СХД после доработки
● Все узлы - bphotos
● FS - ext3
● Кэш на SSD
● Уточнен Lun-masking

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

13. Переходный
вариант.

14. Проектирование новых хранилищ
• Прогнозирование роста объемов данных на ближайшие два
года, на основе накопленной статистики.
• Сравнительная оценка производительности (IO Capacity)
• Составление требований к функционалу.
• Обзор существующих решений и технологий.
• Выбор наиболее доступных и способных к быстрому введению
в эксплуатацию

15. Требования к функционалу - 1
• Узлы и SAN остаются прежними
• ПО - доступно, документировано и желательно открытым
• Знакомый инструментарий отладки и мониторинга
• Аппаратные компоненты - стандартны и доступны из разных
источников, с возможностью замены на другую модель
• Высокая дисковая плотность
• Данные доступны при замене компонентов системы.
• Конфигурация воспроизводима, изменения протоколируются

16. • Данные дублируются на двух хранилищах и доступны
одновременно
• изменять уровень RAID(Raid Level Migration)
• создавать снимки томов (snapshots)
• клонировать тома
• замены носителей на более емкие
• изменение объема тома “на лету”
• Хранилище модифицируемо, tiered storage, кэширование на
высокопроизводительных носителях.
• Поддержка Multipath IO.
• Различные транспорт - FC/FCOE/iSCSI/SRP и пр

17. Физическая
компоновка
хранилищ

18. Выбор аппаратных компонентов
Носители
Носитель информации используемый в СХД является расходным
материалом, а его тип - одним из определяющих условий, того
какова будет ее цена/надежность/производительность

19. Выбор носителей
Тип носителя (Media): SSD/HDD
SSD: - малое время доступа/высокая производительность, низкое
энергопотребление, толерантность к вибрации, малые объемы,
небольшое время наработки на отказ (MTBF) , высокая цена
HDD: умеренная цена, большой объем, долгий период наработки
на отказ, низкая производительность

20. Форм-фактор - 2.5” или 3.5”?
2.5”:
• Pro: малые физические
размеры, высокая плотность,
низкая вибрация, высокие
скорости вращения, малое
время доступа
• Contra: малый объем, высокая
цена за 1Mb.
3.5”:
• Pro: большой объем, низкая
цена, широкая доступность на
рынке
• Contra: большой размер-
низкая плотность per unit,
высокая вибрация, низкие
скорости вращения, большое
время доступа

21. Выбор интерфейса - SATA или SAS
SATA - широко доступны и имеют низкую цену, SATA может работать поверх
SAS, одноканальный доступ к диску (от одного Initiator-а), а так же имеют
меньший буфер под очередь команд (NCQ). Система внутреннего
мониторинга SMART сильно различается между моделями и
производителями
SAS - позволяет организовать двухканальный доступ к диску, имеет более
изощренные методы коррекции ошибок и позиционирования, традиционно
считаются более надежными и имеющими больший ресурс

22. SAS-SATA MUX (Интерпозер)
Мультиплексор SAS-SATA,
позволяет использовать SATA
диски в HA-конфигурациях

23. Схема работы SAS-SATA MUX

24. Дисковые полки - JBOD
Две основные составляющие стоимости СХД:
1.Стоимость носителя - цена за Mb
2.Стоимость размещения - цена за слот
Размещение в дисков в расширениях JBOD, позволяет получить
высокую плотность компоновки и сравнительно небольшую цену
за один дисковый слот. В настоящее время доступны JBOD
высокой плотности - 90x3.5” на 4U, т.е более 22 дисков в 1U

25. Компоненты JBOD:
• Корпус, дисковые слоты
• Источники питания (PSU)
• Контроллер питания (PDB)
• Система охлаждения, вентиляторы и датчики
• Бэкплейны
• Экспандер - один или несколько
• Интерфейсные кабели и разъемы

26. Экспандер - LSI SAS2x36
Экспандер - SAS-
коммутатор.
Осуществляет
контроль и
мониторинг
питания и
охлаждения.
Управляет LED.

27. Управляющий блок. Компоненты.
• CPU
• Mainboard
• RAM
• SAS HBA-адаптеры шины
• FibreChannel/IB/10GigE-контроллеры
• Локальный RAID (OS/Support Tools)

28. Программное обеспечение.
• OS - SLES 11.3/12
• DeviceMapper - Multipath I/O
• MDRaid - программный RAID
• LVM - менеджер томов
• Утилиты: sg3_utils, smp_utils
• SCSI Target - LIO, SCST или иное ПО, реализующее Target
• Smartmontools - мониторинг состояния носителей
• Puppet Agent - управление конфигурациями
• Zabbix Agent - агент системы мониторинга
• Набор хелперов для конфигурации

29. Логика работы хранилища
Для балансировки нагрузки на ядра CPU и
поддержки HA, используется DM Multipath
t3d11 (35000c5005050c73a) dm-31
ATA,size=1.8T features='0' hwhandler='0' wp=rw
`-+- policy='queue-length 0' prio=2 status=active
|- 6:0:36:0 sdal 66:80 active ready running
`- 8:0:61:0 sded 128:80 active ready running

30. Конфигурация SCSI Target (SCST)
HANDLER vdisk_fileio {
DEVICE private30170 {
filename /dev/lv0/private30170
usn private30170
nv_cache 1
threads_pool_type shared
}
TARGET_DRIVER qla2x00t {
TARGET 21:00:00:1b:32:89:00:1c {
HW_TARGET
enabled 1
GROUP dphotos30 {
INITIATOR 21:00:00:1b:32:1f:14:b5
INITIATOR 21:01:00:1b:32:3f:14:b5
LUN 0 private30170
Конфигурация бэкенда - устройства
хранения
Конфигурация драйвера FC HBA и
lun-masking

31. Подключение хранилищ к хостам
Конфигурация multipath.conf
device {
vendor "SCST_FIO"
product "*"
path_grouping_policy group_by_prio
path_checker tur
uid_attribute "ID_SCSI_SERIAL"
path_selector "round-robin 0"
rr_weight uniform
rr_min_io 2
failback manual
}
Атрибут агрегации путей
scsi_id --export --whitelisted /dev/sdc
ID_SCSI_SERIAL=private30170
scsi_id --export --whitelisted /dev/sdbk
ID_SCSI_SERIAL=private30170
Отображение путей
private30170 dm-4 SCST_FIO,private30170
size=510G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 3:0:0:0 sdc 8:32 active ready running
|- 3:0:1:0 sdbk 67:224 active ready running
|- 4:0:1:0 sdga 131:96 active ready running
`- 4:0:0:0 sdds 71:160 active ready running

32. Тестирование перед вводом в
эксплуатацию.
Нагрузочный тест для CPU/RAM: - Linpack
Внутренний тест SMART - Long Offline Test
Запись значений SMART - A
Синтетический тест чтения/записи: - IOZONE
Запись значений SMART - B и их сравнение с A
Нагрузочный тест FIO - выполняется одновременно на всех
подключенных узлах

33. Регламент действий при устранении сбоев
1.Отключение нагрузки, остановка записи
2.Демонтаж разделов. При невозможности - отключение
вычислительного узла
3.Проведение расследования, поиск и установка причины
4.Устранение
5.Проверка целостности данных, HDD -> RAID -> Volume -> FS
6.Синхронизация разницы

34. Расследование причин сбоев и обработка
нештатных ситуаций
1)Получение системных журналов с узла, записей контроллера
BMC, крашдампов ядра ОС, логирование через
последовательную консоль
2)Выяснение какие версии ПО/Firmware были активны на момент
сбоя
3)Определение порядка сбоя - (Order of Failure), какой именно
компонент, в каком хронографическом порядке вышел из строя

35. Типовые ошибки и проблемы ведущие к
сбоям
• Некорректная настройка Time Long Error Recovery у HDD
• Некорректная настройка DM Multipath (queue_if_no_path)
• Неверное сочетания драйвера-прошивки HBA
• Ошибка адресации памяти, неверная настройка NUMA
• Отключение питания, выход из строя PSU
• Перегрев носителей, выход из строя вентиляторов
• Переполнение очередей, настройки Queue Depth
• Использование нестабильных версий ПО, баги
• Компоненты низкого качества, (экономия на мелочах)

36. Возможности для изменения и
модернизации
Добавление кэширующего уровня - установка PCIe SSD и решения
на базе dm-cache/lvmcache/bcache
Замена транспортного протокола (FC/FCOE/iSCSI/iSER/SRP): -
установка адаптера и реконфигурация SCST
Увеличение объемов и увеличение производительности -
масштабирование: установка более емких носителей и модулей
расширения JBOD

37. Статистика по отказам носителей
Seagate
Toshiba
Hitcachi
HGST SATA
HGST SAS
WDC Green

38. Статистика по производительности

39. Некоторые данные по известным ценам
на компоненты (GPL)

40. Заключение