Дмитрий Лазаренко, Директор R&D, Jelastic Выступление на hpc4.itmozg.ru (25 апреля 2013, Санкт-Петербург)

1. Install&Update Processes
Dmitry Lazarenko,
Director of R&D, Russia
dl@jelastic.com

2. PaaS
• Глобальная автоматизация
• Простота управления
приложениями
• Масштабирование приложения в
зависимости от нагрузки
• Целостность и безопасность
данных приложения
PaaS значительно снижает
затраты времени и денег на
обслуживание

3. Jelastic is the next generation of cloud
hosting which can run and scale
ANY Java & PHP applications
with no code changes required

4. Easy to Create
 Set up your cloud
environment in seconds
 No extra installation or
configuration
 No APIs to code to
 Wide range of software
stacks that you need

5. Easy to Deploy
 One-click deployment
 Application version
control
 Git & SVN support
 Maven, Ant & Jenkins
support

6. Easy to Scale
 Vertical & Horizontal scaling
 Fast resource changes
Easy to Manage
 Managing application
lifecycle
 Control and analyze

9. Вычислительные Контейнеры
• Каждый элемент окружения – отдельный
контейнер(REC)
• Все контейнеры типизированы
• Для каждого метатипа определен свой протокол по
которому ядро взаимодействует с ним
• Взаимодействие ядра и конкретного контейнера
происходит по SSH
• Все контейнеры динамически оптимизируются для
оптимальной утилизации ресурсов

10. Окружения

11. Окружения

12. Системная архитектура

13. Архитектура развертывания

14. Platform
Install&Update

15. Сложная инфраструктура
Resolver
Database server
Jelastic Core
Hivext Core
Awaikener
Zabbix app server
Zabbix db server
Logging server
RPM repositoryAutotests server

16. Большое количество площадок

17. Проблемы
Исторически платформа устанавливалась и
обновлялась вручную:
• Разработчики патчили наживую продакшены
• Доработка напильником и «Уникальная»
конфигурация
• Состав патча/инсталлятора распределен
между головами 3-4 человек

18. Результат проблем
• Установка с 0 растягивается на неделю
• Более суток на непрерывное
обновление
• Очень большой Downtime
• Невозможность предсказать все
проблемы и затраченное время
• Про тиражирование можно забыть

19. Что было нужно?
• Управление разворачиванием сложной
конфигурации
• Полная автоматизация установки и
обновления
• Простая параметризация под конкретную
площадку

20. Чего пытались добиться?
• Дешевое тиражирование платформы
• Ускорение процессов установки и
обновления
• Минимизация Downtime
• Минимизация рисков от человеческого
фактора

21. Выбор системы автоматизации
• Puppet
• Chef
• Cfengine
• Self-made

22. Структура Puppet
Классы инфраструктурных
харднод
Классы инфраструктурных
приложений
Классы инфраструктурных
контейнеров
Классы общих
приложений
Конфиги хостера
Объявление объектов
Манифесты(Классы) РесурсыОбьекты
Артефакты
Динамические данные
(параметризированные
конфигурации и скрипты )
Статические данные
(файлы конфигураций и
скрипты)

23. Содержимое инсталлятора
• Инфраструктурные приложения
• Клиентские приложения
• Базы данных
• RPM-Пакеты
• Конфигурации

24. RPM
• Из них формируются шаблоны
контейнеров:
•Tomcat
•MySQL
•Nginx…
• Собираются с помощью maven
• Сохраняются с помощью Jenkins в
центральный RPM-репозиторий

25. Workflow установки
Puppet Master node
Jem managing application
GITGIT
RepositoryRepository
GITGIT
RepositoryRepository
R&D
Department
Operations
Department
Install config
Hosters config
Objects declaration
NexusNexus
JenkinsJenkins
RPM repoRPM repo

26. Установка платформы
1. Заранее подготавливается инфраструктура:
•Сеть
•Делегируется корневая Dns-зона
•SSL-сертификаты
2. Нужные параметры зашиваются в скрипт, который:
•Устанавливает систему виртуализации
•Создает и конфигурирует все инфраструктурные
контейнеры
3. Установка полностью автоматизирована ~ 3 часа

27. Обновление БД
• Икрементальные шаблонизированные SQL
скрипты
• Специальный менеджер обновления,
который обеспечивает правильный
порядок и правильность выполнения
скриптов
• Поддержка обратной совместимости

28. Проблема
• Во время обновление БД заблокирована
• Много Alter на больших таблицах занимает много
времени (на практике до 2х часов)
Следствие
• Downtime инфраструктурных приложений и БД
может достигать нескольких часов

29. Кластерный режим обновления
• Перекидывание виртуальных IP (VIP)
• Смена DNS - A записей
• Смена точки входа в платформу
• Поочередное обновление каждого экземпляра:
1. Active-Active
2. Active-Standby (Updating)
3. Standby (Updating)-Active
4. Active-Active

30. Обновление без Downtime

31. Обновление БД
Multi-Master Replication Manager for MySQL :
1.Останавливаем репликацию
2.Запоминаем номер транкзакции T1 (checkpoint)
3.Данные пишутся только на первый узел
4.Обновляем второй узел
5.Включаем репликацию
6.Новые данные копируются с узла 1 на узел 2
7.Меняем роли между 1м и 2м узлом
8.Обновляем первый узел, так же как и второй
9.В итоге кластер БД полностью синхронизирован

32. Проверка
1. CI на нескольких STAGED-площадках:
1. Установка с 0
2. Обновление с одной на другую версию
3. Автотесты
2. CI на нескольких SuperSTAGED-
площадках:
1. Обновление на следующую версию
2. Автотесты
3. Только потом обновление Production

33. Continuous Integration
Скачивание конфиговСкачивание конфигов
хостера с репозиторияхостера с репозитория
OPSOPS
Скачивание конфиговСкачивание конфигов
хостера с репозиторияхостера с репозитория
OPSOPS
Установка и запуск JemУстановка и запуск Jem
приложенияприложения
Установка и запуск JemУстановка и запуск Jem
приложенияприложения
Скачивание манифестовСкачивание манифестов
нужной версиинужной версии
с репозитория R&Dс репозитория R&D
Скачивание манифестовСкачивание манифестов
нужной версиинужной версии
с репозитория R&Dс репозитория R&D
Скачивание собраныхСкачивание собраных
артефактов нужнойартефактов нужной
версии с Nexusверсии с Nexus
Скачивание собраныхСкачивание собраных
артефактов нужнойартефактов нужной
версии с Nexusверсии с Nexus
Сборка элементовСборка элементов
инфраструктуры черезинфраструктуры через
jem + puppetjem + puppet
Сборка элементовСборка элементов
инфраструктуры черезинфраструктуры через
jem + puppetjem + puppet
Запуск тестов базовойЗапуск тестов базовой
проверки установкипроверки установки
Запуск тестов базовойЗапуск тестов базовой
проверки установкипроверки установки
Запуск тестов проверкиЗапуск тестов проверки
всего фунционала, уже навсего фунционала, уже на
уровне пользователяуровне пользователя
Запуск тестов проверкиЗапуск тестов проверки
всего фунционала, уже навсего фунционала, уже на
уровне пользователяуровне пользователя
Отправка результатовОтправка результатов
тестирования на почтутестирования на почту
Отправка результатовОтправка результатов
тестирования на почтутестирования на почту
Удаление виртуальныхУдаление виртуальных
серверов и приложениясерверов и приложения
JemJem
Удаление виртуальныхУдаление виртуальных
серверов и приложениясерверов и приложения
JemJem

34. Containers
patching

35. Задача
• Применять патчи безопасности на все окружения
всех пользователей
• Давать пользователям возможность
самостоятельно обновить компоненты их
окружений в случае выхода их новой версии

36. Реалии
• Каждый контейнер – отдельная монолитная ОС
• Применение 1 патча для одного контейнера
(yum update) занимает от 30 секунд до 10 минут:
1. Подключение ко всем репозиториям
2. Проверка зависимостей
3. Загрузка RPM-пакета и его зависимостей
4. Установка пакета
• Среднее количество виртуальных контейнеров на
сервер – 200
• Количество серверов 10-40

37. Проблемы
• Установка security-патча на все контейнеры
занимает очень много времени
• Многократная дупликация данных (70%
одинаковых данных)
• Создание и особенно восстановление из backup
достаточно затратны
• Пользователь не может влиять на процесс и
расписание обновлений

38. Решение
• Ушли от монолитной архитектуры контейнеров
• Разделили контейнеры на:
• Общие данные/движки: Java, Tomcat, MySQL…
• Приватные данные(специфичные конфигурации):
• Приложений(настройки, дистрибутивы)
• ОС

39. Решение
• Все версии движков находятся на каждом
физическом сервере в специальном каталоге
• На всех физических серверах всегда одинаковый
набор версий всех движков
• В контейнерах множественные mount points на
конкретные версии движков
• В контейнерах находятся только приватные
данные

40. Решение

41. SpaceWalk

42. Результат
• Обновление движкаприменение security path:
• Remount
• Мгновенно 
• Значительно сэкономили место и время
обновления
• Можно переключиться на любую версию движка
– процесс полностью безопасен
• Пользователи могут выбрать применять или нет
обновления движков

43. Обновление физического сервера
• Если требуется перезагрузка – применяем kexec
Обновление ОС в контейнерах
• Заливаем новый Virtuozzo template на сервер
• Меняем template у каждого контейнера
• Быстро, но с Downtime 

44. Спасибо!
Jelastic.com
dl@jelastic.com