Борис Павлович - Производительность и масштабируемость OpenStack
0 likes2,690 views
Документ описывает OpenStack, его архитектуру, компоненты и проблемы производительности и масштабируемости. Рассматривается проект Rally, предназначенный для автоматизации тестирования и профилирования OpenStack. Выделены узкие места в производительности и предложены подходы к их устранению через бенчмаркинг и оптимизацию.
Борис Павлович - Производительность и масштабируемость OpenStack
- 1. © MIRANTIS 2013 PAGE 1 © MIRANTIS 2013 OpenStack Scalability & Performance Boris Pavlović Tech Lead at Mirantis
- 2. © MIRANTIS 2013 PAGE 2 Содержание • Что такое OpenStack и зачем он нужен? • Что такое «производительность» и «масштабируемость» OpenStack-а? • Как “гонять” OpenStack ручками? • Цель: полностью автоматизировать тестирование. (описание проекта Rally) • Проблемы с которыми мы столкнулись при разработке Rally • Результаты: Houston we have a problem
- 3. © MIRANTIS 2013 PAGE 3 Что такое OpenStack и зачем он нужен? OpenStack сделаете из ваших серверов
- 4. © MIRANTIS 2013 PAGE 4 Что такое OpenStack облако? • Позволяет работать с ресурсами, а не железом • Управляет: • Виртуальными Машинами • Блочными устройствами • Образами • Сетями • Физическими серверами
- 5. © MIRANTIS 2013 PAGE 5 Компоненты OpenStack • Nova –Виртуальные машины • Glance – Образы • Cinder – Блочные устройства • Neutron – Сети • Keystone – Аутентификация/Авторизация • Ironic – Физические серверы • Ceilometer - Мониторинг
- 6. © MIRANTIS 2013 PAGE 6 Сферический компонент в вакууме
- 7. © MIRANTIS 2013 PAGE 7 Архитектура OpenStack • Куча взаимодействующий компонентов, которые в основном состоят из трех сервисов: • API – как точка входа компонента (Nova, Cinder, …) • Работает на управляющем сервере • Выполнить все, что можно без участия ресурсных серверов • Вызвать нужный метод Manager-a на нужном сервере • Manager – делает всю работу вокруг ресурсов • DB – полное хранение состояния системы
- 8. © MIRANTIS 2013 PAGE 8 OpenStack Deployment • Как правильно OpenStack деплоить? • Нет никаких правил! • Нет никаких советов! • Нет никаких ограничении!
- 9. © MIRANTIS 2013 PAGE 9 OpenStack Deployment: Simple no HA
- 10. © MIRANTIS 2013 PAGE 10 OpenStack Deployment: Full HA
- 11. © MIRANTIS 2013 PAGE 11 OpenStack Deployment: HA Compact
- 12. © MIRANTIS 2013 PAGE 12 OpenStack Deployment: HA в деталях
- 13. © MIRANTIS 2013 PAGE 13 OpenStack Deployment: Еще Гибкости! • DB: MySQL or PostgresSQL? • AMQP: RabbitMQ or Qpid? • Network: Nova Network or Neutron? • Virtualization • +1 billion configurable parameters
- 14. © MIRANTIS 2013 PAGE 14 OpenStack Performance & Scalability Начнем!
- 15. © MIRANTIS 2013 PAGE 15 OpenStack Performance & Scalability Нас интересует несколько проблемных зон: 1) Как влияет deployment на производ.? 2) Влияние конфигурации на производ.? 3) Влияние количества вычислительных узлов на производительность? 4) Влияние активных объектов (виртуальных машин, дисков, проектов, пользователей, образов и т.п.) на производительность
- 16. © MIRANTIS 2013 PAGE 16 OpenStack Performance & Scalability А есть ли собственно проблема?
- 17. © MIRANTIS 2013 PAGE 17 OpenStack Performance & Scalability А есть ли собственно проблема? Короткий ответ: Да есть.
- 18. © MIRANTIS 2013 PAGE 18 OpenStack Performance: Длинный ответ (очевидные узкие места): • Централизованное хранение состояния системы в реляционной БД • Постоянное выкачивание целой ДБ • Постоянный update целой ДБ • Использование JOIN везде • Случайным образом выставленные Index-ы
- 19. © MIRANTIS 2013 PAGE 19 OpenStack Performance: Цифры • Алгоритм работы Nova Scheduler: 1. Выкачать из БД все данные о вычислительных узлах (services X compute_node X compute_node_stats) ( 1 X 1 X 25 ) 2. Применить фильтры к этим данным 3. Взвесит все хосты 4. Найти лучший хост и запустить ВМ
- 20. © MIRANTIS 2013 PAGE 20 OpenStack Performance: Цифры Проблемы Scheduler-a (для 10к серверов): • На каждый запрос к Scheduler-у создать ВМ: • ДБ возвращает 250к строк! (25мб в несжатом виде) • Scheduler использует >500 мб оперативной памяти, чтобы обработать этот результат.. • Запрос к ДБ и обработка результата занимают 15сек! • Каждые 60 секунд обновляется полностью вся информацию о всех вычислительных узлах: • Минимум 4к update в секунду!
- 21. © MIRANTIS 2013 PAGE 21 OpenStack Performance: Цифры Создание ВМ-a и синхронизация с ДБ (для 10к серверов, 100к ВМ): • Создание ВМ 20-30 DB updates • Информация об ВМ хранится в двух табличках 100к и 1.2kk записей. • Каждые 6 секунд выкачиваются полностью эти две таблички делая 10к запросов к БД (в случае 10к серверов)
- 22. © MIRANTIS 2013 PAGE 22 Ха узкое место! • Хорошо, что делать если нам попадается узкое место? • Вариант 1: • Написать фикс и сделать патч • Сделать синтетические тесты и собрать результаты • Отправить на ревю • … • И вы получите в ответ несколько вопросов: • Почему ваши синтетические тесты релевантные? • Почему вы считаете, что это будет первым узким местом? • Почему вы считаете, что оно не ухудшит производительность в других use cases?
- 23. © MIRANTIS 2013 PAGE 23 Как доказать,что стало лучше? • Вариант 2: • Раздеплоить OpenStack на большом кластере • Сделать соответствующую нагрузку • Собрать результаты • Показать комюниты! • … • И вы получите в ответ несколько вопросов: • Такие результаты наверное связаны с вашим специфичным деплойментом! • Вы неправильно настроили БД! • Ваша синтетическая нагрузка не релевантная! • …
- 24. © MIRANTIS 2013 PAGE 24 Как доказать,что стало лучше? Вариант 3: • Сделать простую в использовании benchmark систему которая: • Умеет автоматический продеплоить OpenStack в разных окружения (на железе или виртуальных серверах) • Имеет удобный фреймворк для написания тестовых сценариев • Профилирует OpenStack • Предоставляет результаты пользователю в удобном виде • Имеет простой интерфейс =)
- 25. © MIRANTIS 2013 PAGE 25 Убить двух зайцев одним выстрелом • Уменьшаем время затрачиваемо на объяснение почему данное изменение исправляет проблему • Возможность эффективно заниматься бенчмаркингом: • Поиск узких мест • Легкий способ проверки, что изменение помогает • Оптимизация
- 26. © MIRANTIS 2013 PAGE 26 Описание Rally
- 27. © MIRANTIS 2013 PAGE 27 Rally На самом деле задача сводится к компоновке уже существующих элементов в одну систему: 1. Deploy OpenStack with Fuel or DevStack 2. Verify deployment with Temptest 3. Profile with Tomograph & Zipkin 4. Test framework based on pytest
- 28. © MIRANTIS 2013 PAGE 28 Rally deployment • Just returns information about existing cloud • Deploy non HA deployment using DevStack. • Deploy complex HA deployments using FUEL.
- 29. © MIRANTIS 2013 PAGE 29 Rally deployment 3 scenarios • Простой: • Получить N серверов (возможно виртуальных) • Используя один из deploy engines раздеплоить OpenStack на них • Сложный • Получить серверы для control node • Создать ВМ в котором запустим много внутренних контейнеров в которых продеплоим OpenStack • Создать Snapshot • Стартовать серверы с данного Snapshot
- 30. © MIRANTIS 2013 PAGE 30 Спасибо за внимание! Вопросы?
- 31. © MIRANTIS 2013 PAGE 31 Boris Pavlovic bpavlovic@mirantis.com