Как превратить Openstack Swift в хранилище для высоких нагрузок разных типов, Николай Двас (Webzilla)

Openstack Swift у
высоконагруженного
провайдера
Николай Двас, Webzilla

О чем этот доклад
• О том, ЧТО мы сделали, чтобы мы
сделали, чтобы получить работающий
сервис.
• О том, что мы узнали про его
эксплуатацию.

Устройство доклада
1. Зачем нужно хранилище;
2. Как устроен Openstack Swift;
3. Как его устройство ложится на цели;
4. Что пришлось сделать, чтобы наше
желания лучше совпадали с нашими
возможностями.

Кто я?
• Менеджер
продукта
• Забираю счастье у
разработчиков и
раздаю его
клиентам.

Кто мы?
> 1000
международных
клиентов
1.5 Тбитсек
пропускной cпособности
> 1000
используемых
серверных
стоек
7
Tier 1 провайдеров
13
точек присутствия
5
дата-центров
700+ Гбитсек
трафика
> 18’000
серверов
> 1000
частных стыков с
партнерами

Зачем нам хранилище?
• Источник данных для CDN;
• Бэкапы: сервис и инфраструктура;
• Раздача статики без CDN;
• Непредсказуемые клиентские задачи.

Текущая нагрузка
• Петабайты данных хранения
• > 50 Гбит/сек трафик (не включая
CDN)
• 30% данных в репликации
• Резервное копирование тысяч
серверов

CDN origin
• Продавая CDN, мы продаем скорость и
беспроблемность;
• Для глобального CDN важно не только
распределенное кеширование, но и
распределенное хранение;
• Мы берем на себя ответственность –
значит, нам нужен контроль.

CDN origin
• Репликация данных между очень
удаленными хранилищами;
• Удобные инструменты управления
контентом;
• Защита от хотлинкинга;
• Надо быть готовым к псевдостримингу.

Раздача статики
Copyright by http://flickr.com/olly247,
Creative Commons CC-BY-SA LICENSE

Раздача статики
• CDN нет, а горячий контент все равно есть
– было бы глупо его не кешировать;
• Есть понятный субститут – «собственный
сервер с дисковой полкой и nginx». Надо
быть не только лучше, но и не дороже;

Резервное копирование
Copyright by http://flickr.com/smemon,
Creative Commons CC-BY LICENSE

• Надо принимать много данных
одновременно;
• Надо иметь хороший инструмент для
резервного копирования;
• Защита от «опытного пользователя»;

Достоинства Swift
• Хороший популярный API, много
разработчиков;
• Горизонтальная масштабируемость;
• Все заявленные функции работают.

Недостатки Swift
• Никакого кеширования;
• Управление работает там же, где могут
оказаться высокие нагрузки;
• Многие возможности не тестируются на
нагрузках: разрабатывается «на
ноутбуках»;

Обзор архитектуры Swift

Имплементация в Webzilla

Партиции
• Их число фиксируется при создании
кольца;
• Может быть степенью двойки;
• Рекомендация: 100 – 1000 партиций на
диск (минимизация загрузки CPU)
• Вывод: рост возможен в 5-10 раз.

Расширяемость
• Рост в 5-10 раз по количеству дисков;
• Рост – не очень быстрый (добавление сотни
Тб в работающий под нагрузкой сегмент
может занять пару недель) – надо
заниматься наращиванием заранее.

Реакция на отказ железа
• Если потерять зону, производительность
части запросов падает; если потерять две,
она падает еще сильнее.
• Перестроение кольца – снижает падение
производительности, но не может делаться
слишком часто.

Реакция на отказ железа
Среднее 95 перцениль
Операций в секунду (чтение) 100/88/65 48/38/9
Операций в секунду (запись) 100/76/36 24/18/7
Среднее Число интервалов с более
чем 0.05% неуспеха
Неуспешное чтение, % 0/0/0.03 0/0/45%
Неуспешная запись, % 0/0/0.04 0/0/63%
5 зон / 4 зоны / 5 зон и ребалансировка при потере одной зоны
При ребалансировке все запросы обслужатся в 3 раза медленнее.
Без нее, 20% запросов обслужатся медленнее (настраиваемо)

Архитектурные странности

SQLite
• Используется для хранения данных о контейнерах и
аккаунтах;
• Дергается каждый раз, когда надо что-то посмотреть
про объект – получаем Highload SQLite 
• SSD позволяет работать с 100 млн. объектов в одной
сущности (коллеги с SATA жаловались на проблемы
начиная с 1 млн);
• Наш опыт: на 1 Пб данных – 1 Тб метаданных точно
хватает;

Сети
• Трафик репликации и клиентский трафик живут в
одной сети;
• Защита от race condition (записали в одно место из
трех, попытались прочитать из другого – ничего не
получилось) сделана методом безусловного чтения из
двух мест. Это двойной трафик;
• С первым – смириться, от второго – отказаться.

Синхронизация
• Синхронизация между контейнерами осуществляется
в один поток на всю инсталляцию;
• Пришлось переписать и сделать ее многопоточной;
• А потом еще добавить мониторинг задержки
синхронизации (посредством большого количества
запросов к API Swift – небыстро, но терпимо);

Раздача статики vs. заливка бэкапов
• Веб-сервер (swift-proxy) высоко нагружены и GET-
ами, и PUT-ами (к счастью, не совсем одновременно);
• Есть еще CDN, про который мы уже предполагаем,
что он решил задачу кеширования оптимально; его
запросы кешировать не надо.

Раздача статики vs. заливка бэкапов

Инвалидация кеша
• Ненужный кеш
инвалидируется сам по себе
• Можно избавиться от возни
с purge API

FTP
• FTP очень любят клиенты. А мы любим клиентов.
Кажется, любовь нетранзитивна;
• ftp-cloudfs – живой, развивающийся проект;
• Пришлось добавить удаление больших объектов, их
переименование, и возможность «прятать» файлы
частей от пользователя;
• Заставить отработать ls в контейнере с 3 млн. файлов,
кажется, нельзя – но удалось заставить не падать.

Резервное копирование: duplicity
• Если индексный файл больше 5 Гб – надо
использовать FTP;
• «Размер тома» имеет значение: чем он меньше, тем
больше overhead на создании, и тем быстрее
восстановление.

Что мы получили
• Swift можно успешно использовать для всех целей,
для которых мы хотели – для раздачи статики с и без
CDN, и для бэкапов;
• Сервису год, и доработка не собирается
останавливаться;

Как превратить Openstack Swift в хранилище для высоких нагрузок разных типов, Николай Двас (Webzilla)

Как превратить Openstack Swift в хранилище для высоких нагрузок разных типов, Николай Двас (Webzilla)

More Related Content

What's hot (20)

Similar to Как превратить Openstack Swift в хранилище для высоких нагрузок разных типов, Николай Двас (Webzilla) (20)

More from Ontico (20)

Как превратить Openstack Swift в хранилище для высоких нагрузок разных типов, Николай Двас (Webzilla)

Editor's Notes