Борис Павлович - Производительность и...

© MIRANTIS 2013 PAGE 1 © MIRANTIS 2013

OpenStack Scalability & Performance

Boris Pavlović

Tech Lead at Mirantis

© MIRANTIS 2013 PAGE 2

Содержание

• Что такое OpenStack и зачем он нужен? • Что такое «производительность» и

«масштабируемость» OpenStack-а? • Как “гонять” OpenStack ручками? • Цель: полностью автоматизировать тестирование.

(описание проекта Rally) • Проблемы с которыми мы столкнулись при разработке Rally • Результаты: Houston we have a problem


Что такое OpenStack и зачем он нужен?

OpenStack

сделаете из ваших серверов


Что такое OpenStack облако?

• Позволяет работать с ресурсами, а не железом

• Управляет: •  Виртуальными Машинами •  Блочными устройствами •  Образами •  Сетями •  Физическими серверами


Компоненты OpenStack

• Nova –Виртуальные машины

• Glance – Образы

• Cinder – Блочные устройства

• Neutron – Сети

• Keystone – Аутентификация/Авторизация

•  Ironic – Физические серверы

• Ceilometer - Мониторинг


Сферический компонент в вакууме


Архитектура OpenStack

• Куча взаимодействующий компонентов, которые в основном состоят из трех сервисов: •  API – как точка входа компонента (Nova, Cinder, …)

•  Работает на управляющем сервере •  Выполнить все, что можно без участия ресурсных серверов

•  Вызвать нужный метод Manager-a на нужном сервере

•  Manager – делает всю работу вокруг ресурсов •  DB – полное хранение состояния системы


OpenStack Deployment

• Как правильно OpenStack деплоить? •  Нет никаких правил! •  Нет никаких советов! •  Нет никаких ограничении!


OpenStack Deployment: Simple no HA


OpenStack Deployment: Full HA


OpenStack Deployment: HA Compact


OpenStack Deployment: HA в деталях


OpenStack Deployment: Еще Гибкости!

• DB: MySQL or PostgresSQL?

• AMQP: RabbitMQ or Qpid?

• Network: Nova Network or Neutron?

• Virtualization

• +1 billion configurable parameters


OpenStack Performance & Scalability

Начнем!



Нас интересует несколько проблемных зон: 1)  Как влияет deployment на производ.? 2)  Влияние конфигурации на производ.? 3)  Влияние количества вычислительных узлов на производительность?

4)  Влияние активных объектов (виртуальных машин, дисков, проектов, пользователей, образов и т.п.) на производительность



А есть ли собственно проблема?



А есть ли собственно проблема?

Короткий ответ: Да есть.


OpenStack Performance:

Длинный ответ (очевидные узкие места):

• Централизованное хранение состояния системы в реляционной БД

• Постоянное выкачивание целой ДБ

• Постоянный update целой ДБ

• Использование JOIN везде

• Случайным образом выставленные Index-ы


OpenStack Performance: Цифры

• Алгоритм работы Nova Scheduler: 1.  Выкачать из БД все данные о вычислительных узлах

(services X compute_node X compute_node_stats) ( 1 X 1 X 25 )

2.  Применить фильтры к этим данным 3.  Взвесит все хосты 4.  Найти лучший хост и запустить ВМ



Проблемы Scheduler-a (для 10к серверов): • На каждый запрос к Scheduler-у создать ВМ: •  ДБ возвращает 250к строк! (25мб в несжатом виде) •  Scheduler использует >500 мб оперативной памяти, чтобы обработать этот результат. . •  Запрос к ДБ и обработка результата занимают 15сек!

• Каждые 60 секунд обновляется полностью вся информацию о всех вычислительных узлах: •  Минимум 4к update в секунду!



Создание ВМ-a и синхронизация с ДБ (для 10к серверов, 100к ВМ):

• Создание ВМ 20-30 DB updates

• Информация об ВМ хранится в двух табличках 100к и 1.2kk записей.

• Каждые 6 секунд выкачиваются полностью эти две таблички делая 10к запросов к БД (в случае 10к серверов)


Ха узкое место!

• Хорошо, что делать если нам попадается узкое место? • Вариант 1: •  Написать фикс и сделать патч •  Сделать синтетические тесты и собрать результаты •  Отправить на ревю •  … •  И вы получите в ответ несколько вопросов:

•  Почему ваши синтетические тесты релевантные? •  Почему вы считаете, что это будет первым узким местом? •  Почему вы считаете, что оно не ухудшит производительность в других use cases?


Как доказать, что стало лучше?

• Вариант 2: •  Раздеплоить OpenStack на большом кластере •  Сделать соответствующую нагрузку •  Собрать результаты •  Показать комюниты! •  … •  И вы получите в ответ несколько вопросов:

•  Такие результаты наверное связаны с вашим специфичным деплойментом!

•  Вы неправильно настроили БД! •  Ваша синтетическая нагрузка не релевантная! •  …


Как доказать, что стало лучше?

Вариант 3: • Сделать простую в использовании benchmark систему которая: •  Умеет автоматический продеплоить OpenStack в разных окружения (на железе или виртуальных серверах) •  Имеет удобный фреймворк для написания тестовых сценариев •  Профилирует OpenStack •  Предоставляет результаты пользователю в удобном виде •  Имеет простой интерфейс =)


Убить двух зайцев одним выстрелом

• Уменьшаем время затрачиваемо на объяснение почему данное изменение исправляет проблему

• Возможность эффективно заниматься бенчмаркингом: •  Поиск узких мест •  Легкий способ проверки, что изменение помогает •  Оптимизация


Описание Rally


Rally

На самом деле задача сводится к компоновке уже существующих элементов в одну систему:

1.  Deploy OpenStack with Fuel or DevStack

2.  Verify deployment with Temptest

3.  Profile with Tomograph & Zipkin

4.  Test framework based on pytest


Rally deployment

•  Just returns information about existing cloud

• Deploy non HA deployment using DevStack.

• Deploy complex HA deployments using FUEL.


Rally deployment 3 scenarios

• Простой: •  Получить N серверов (возможно виртуальных) •  Используя один из deploy engines раздеплоить

OpenStack на них

• Сложный •  Получить серверы для control node •  Создать ВМ в котором запустим много внутренних контейнеров в которых продеплоим OpenStack •  Создать Snapshot •  Стартовать серверы с данного Snapshot


Спасибо за внимание!

Вопросы?


Boris Pavlovic

[email protected]

Борис Павлович - Производительность и...

Documents

Transcript of Борис Павлович - Производительность и...