• Like
«Механизмы обновления платформы и окружений пользователей в Jelastic»
Upcoming SlideShare
Loading in...5
×

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

  • 113 views
Uploaded on

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

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
113
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • В двух словах Platform as a Service - это множество серверов с программной оболочкой, заточенной для обслуживания приложений своих пользователей. Пользователями PaaS могут быть как разработчики SaaS -приложений, так и предприятия со своими корпоративными приложениями. При этом PaaS берет на себя такие задачи как простоту администрирования приложений, выделение приложениям требуемых вычислительных ресурсов (память, процессор, биски и т.п.) и обеспечение целостности и безопасности данных. Тем самым использование PaaS позволяет владельцам существенно сэкономить время и деньги на обслуживании своих приложений.

Transcript

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