Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

«Механизмы обновления платформы и окружений пользователей в Jelastic»

336 views

Published on

Дмитрий Лазаренко, Директор R&D, Jelastic

Выступление на hpc4.itmozg.ru (25 апреля 2013, Санкт-Петербург)

  • Be the first to comment

  • Be the first to like this

«Механизмы обновления платформы и окружений пользователей в Jelastic»

  1. 1. Install&Update ProcessesDmitry Lazarenko,Director of R&D, Russiadl@jelastic.com
  2. 2. PaaS• Глобальная автоматизация• Простота управленияприложениями• Масштабирование приложения взависимости от нагрузки• Целостность и безопасностьданных приложенияPaaS значительно снижаетзатраты времени и денег наобслуживание
  3. 3. Jelastic is the next generation of cloudhosting which can run and scaleANY Java & PHP applicationswith no code changes required
  4. 4. Easy to Create Set up your cloudenvironment in seconds No extra installation orconfiguration No APIs to code to Wide range of softwarestacks that you need
  5. 5. Easy to Deploy One-click deployment Application versioncontrol Git & SVN support Maven, Ant & Jenkinssupport
  6. 6. Easy to Scale Vertical & Horizontal scaling Fast resource changesEasy to Manage Managing applicationlifecycle Control and analyze
  7. 7. Вычислительные Контейнеры• Каждый элемент окружения – отдельныйконтейнер(REC)• Все контейнеры типизированы• Для каждого метатипа определен свой протокол покоторому ядро взаимодействует с ним• Взаимодействие ядра и конкретного контейнерапроисходит по SSH• Все контейнеры динамически оптимизируются дляоптимальной утилизации ресурсов
  8. 8. Окружения
  9. 9. Окружения
  10. 10. Системная архитектура
  11. 11. Архитектура развертывания
  12. 12. PlatformInstall&Update
  13. 13. Сложная инфраструктураResolverDatabase serverJelastic CoreHivext CoreAwaikenerZabbix app serverZabbix db serverLogging serverRPM repositoryAutotests server
  14. 14. Большое количество площадок
  15. 15. ПроблемыИсторически платформа устанавливалась иобновлялась вручную:• Разработчики патчили наживую продакшены• Доработка напильником и «Уникальная»конфигурация• Состав патча/инсталлятора распределенмежду головами 3-4 человек
  16. 16. Результат проблем• Установка с 0 растягивается на неделю• Более суток на непрерывноеобновление• Очень большой Downtime• Невозможность предсказать всепроблемы и затраченное время• Про тиражирование можно забыть
  17. 17. Что было нужно?• Управление разворачиванием сложнойконфигурации• Полная автоматизация установки иобновления• Простая параметризация под конкретнуюплощадку
  18. 18. Чего пытались добиться?• Дешевое тиражирование платформы• Ускорение процессов установки иобновления• Минимизация Downtime• Минимизация рисков от человеческогофактора
  19. 19. Выбор системы автоматизации• Puppet• Chef• Cfengine• Self-made
  20. 20. Структура PuppetКлассы инфраструктурныххарднодКлассы инфраструктурныхприложенийКлассы инфраструктурныхконтейнеровКлассы общихприложенийКонфиги хостераОбъявление объектовМанифесты(Классы) РесурсыОбьектыАртефактыДинамические данные(параметризированныеконфигурации и скрипты )Статические данные(файлы конфигураций искрипты)
  21. 21. Содержимое инсталлятора• Инфраструктурные приложения• Клиентские приложения• Базы данных• RPM-Пакеты• Конфигурации
  22. 22. RPM• Из них формируются шаблоныконтейнеров:•Tomcat•MySQL•Nginx…• Собираются с помощью maven• Сохраняются с помощью Jenkins вцентральный RPM-репозиторий
  23. 23. Workflow установкиPuppet Master nodeJem managing applicationGITGITRepositoryRepositoryGITGITRepositoryRepositoryR&DDepartmentOperationsDepartmentInstall configHosters configObjects declarationNexusNexusJenkinsJenkinsRPM repoRPM repo
  24. 24. Установка платформы1. Заранее подготавливается инфраструктура:•Сеть•Делегируется корневая Dns-зона•SSL-сертификаты2. Нужные параметры зашиваются в скрипт, который:•Устанавливает систему виртуализации•Создает и конфигурирует все инфраструктурныеконтейнеры3. Установка полностью автоматизирована ~ 3 часа
  25. 25. Обновление БД• Икрементальные шаблонизированные SQLскрипты• Специальный менеджер обновления,который обеспечивает правильныйпорядок и правильность выполненияскриптов• Поддержка обратной совместимости
  26. 26. Проблема• Во время обновление БД заблокирована• Много Alter на больших таблицах занимает многовремени (на практике до 2х часов)Следствие• Downtime инфраструктурных приложений и БДможет достигать нескольких часов
  27. 27. Кластерный режим обновления• Перекидывание виртуальных IP (VIP)• Смена DNS - A записей• Смена точки входа в платформу• Поочередное обновление каждого экземпляра:1. Active-Active2. Active-Standby (Updating)3. Standby (Updating)-Active4. Active-Active
  28. 28. Обновление без Downtime
  29. 29. Обновление БДMulti-Master Replication Manager for MySQL :1.Останавливаем репликацию2.Запоминаем номер транкзакции T1 (checkpoint)3.Данные пишутся только на первый узел4.Обновляем второй узел5.Включаем репликацию6.Новые данные копируются с узла 1 на узел 27.Меняем роли между 1м и 2м узлом8.Обновляем первый узел, так же как и второй9.В итоге кластер БД полностью синхронизирован
  30. 30. Проверка1. CI на нескольких STAGED-площадках:1. Установка с 02. Обновление с одной на другую версию3. Автотесты2. CI на нескольких SuperSTAGED-площадках:1. Обновление на следующую версию2. Автотесты3. Только потом обновление Production
  31. 31. 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
  32. 32. Containerspatching
  33. 33. Задача• Применять патчи безопасности на все окружениявсех пользователей• Давать пользователям возможностьсамостоятельно обновить компоненты ихокружений в случае выхода их новой версии
  34. 34. Реалии• Каждый контейнер – отдельная монолитная ОС• Применение 1 патча для одного контейнера(yum update) занимает от 30 секунд до 10 минут:1. Подключение ко всем репозиториям2. Проверка зависимостей3. Загрузка RPM-пакета и его зависимостей4. Установка пакета• Среднее количество виртуальных контейнеров насервер – 200• Количество серверов 10-40
  35. 35. Проблемы• Установка security-патча на все контейнерызанимает очень много времени• Многократная дупликация данных (70%одинаковых данных)• Создание и особенно восстановление из backupдостаточно затратны• Пользователь не может влиять на процесс ирасписание обновлений
  36. 36. Решение• Ушли от монолитной архитектуры контейнеров• Разделили контейнеры на:• Общие данные/движки: Java, Tomcat, MySQL…• Приватные данные(специфичные конфигурации):• Приложений(настройки, дистрибутивы)• ОС
  37. 37. Решение• Все версии движков находятся на каждомфизическом сервере в специальном каталоге• На всех физических серверах всегда одинаковыйнабор версий всех движков• В контейнерах множественные mount points наконкретные версии движков• В контейнерах находятся только приватныеданные
  38. 38. Решение
  39. 39. SpaceWalk
  40. 40. Результат• Обновление движкаприменение security path:• Remount• Мгновенно • Значительно сэкономили место и времяобновления• Можно переключиться на любую версию движка– процесс полностью безопасен• Пользователи могут выбрать применять или нетобновления движков
  41. 41. Обновление физического сервера• Если требуется перезагрузка – применяем kexecОбновление ОС в контейнерах• Заливаем новый Virtuozzo template на сервер• Меняем template у каждого контейнера• Быстро, но с Downtime 
  42. 42. Спасибо!Jelastic.comdl@jelastic.com

×