Live migration

Облачная PaaS платформа

• Автоматизированная платформа, позволяющая запускать и масштабировать любое приложение на Java, PHP, Python, Ruby и Node.JS

• SQL и NoSQL СУБД, серверы приложений, балансировщики нагрузки, очереди сообщений

• Высокий уровень автоматизации сложных DevOps-сценариев, автоматическое масштабирование, высокую доступность и отказоустойчивость

• Используем контейнеры Virtuozzo с 2011• Клиенты – хостинг-провайдеры(Datahata) и

Корпоративные пользователи• Конкуренты – OpenShift, CloudFoundry

Jelastic PaaS

Платформа PaaS как коробочный продукт

Конструктор облачных топологий

Вычислительные контейнерыКаждый элемент окружения – отдельный виртуальный контейнер Virtuozzo• Все контейнеры типизированы• Для каждого метатипа (App server/DB, и.т.д.) определен

свой протокол по которому ядро взаимодействует с ним• Для БД можно снять/накатить дамп. Для сервера

приложений – настраивать репликацию при горизонтальном масштабировании

• Все контейнеры динамически оптимизируются для максимальной утилизации ресурсов

• В качестве шаблонов поддерживаются OpenShift Cartridges и Docker

Virtual Machines vs Containers

Умное распределение контейнеровAnti-Affinity• Для высокой

доступности• Для защиты от

неравномерной загрузки серверов

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

Cluster

Типичная конфигурация• 10-50 физических серверов

• 32 – 256 GB RAM каждый• На каждом сервере

• 250-2000 контейнеров• Итого в кластере

• 8000 – 64000 контейнеров

Фича: Вертикальное масштабирование

Проблема: Неконтролируемое масштабирование

Server2

vm4

vm2

vm6

vm1 vm3

vm5

Server1

vm3

vm2vm1

• Контейнеры не резервируют RAM при старте (OverProvisioning)

• Контейнеры могут затребовать ресурсов больше, чем сейчас свободно на физической машине

• Облако не статично: количество компонент постоянно меняется

Чего хочется добиться?

• Непрерывная балансировка нагрузки кластера

• Защита от паразитного роста контейнеров

Distributed Resource Scheduler/Smart Live Migration

Умная миграция - Постановка задачи

• Непрерывность работы приложений• Состояние кластера должно действительно

оптимизироваться• Обеспечение HA/Anti-Affinity• Минимальное время• Защита от зацикливания• Защита от сбоев

Архитектура

Resource consumption

analyser

Hardware node

Inventory

Container metrics

historical storage

Migration task queue

List of available hardware

Hardware capabilities

Resource usage

Сontainer inventory

Takes migration tasks from the queue according to the priority

Sends the migration command to PVA

Updates the container locations

How much resources of each type are consumed by each container

Historical metric values to determine trends

Pluggable decision

making engine

Container location Container type Container status Maximum resource

consumption for a container

Container HA placement restrictions

Simple (aggregate estimates with weighs)

Drools planner based

Collects the required data Periodically requests

migrations proposals from decision making engine

Pushes migration tasks to the queue Distributed

coordination engine

Watch for failed migrations

Watch for hardware failures

Fixes errors

`

Migration task worker

Migration task worker

Migration watcherMigration

watcher

CRIU – Checkpoint/Restore In Userspace

Физическая миграция контейнеров

Возможности миграции в Virtuozzo1. Processes2. Multithreading apps3. Virtual memory4. Opened files5. Shared file descriptors6. TCP connections7. UNIX Sockets

Алгоритмы миграции в Virtuozzo

1. Offline2. Simple Online3. Iterative online4. Lazy online5. Iterative lazy online

Математическая модель• Многомерная оптимизация задачи о

упаковке в контейнеры• RAM, CPU, Storage, LA, Network• упаковка объектов предопределённой формы• в конечное

число контейнеров предопределённой формы, таким способом, чтобы:

• число использованных контейнеров было наименьшим

• или количество или объём объектов были наибольшими

Bin Packaging

Математическая модель - Проблема

NP – полная задача:• Решение можно очень быстро проверить• Нет «Серебрянной пули», которая позволяет найти

оптимальное решение в приемлемое время

Простой алгоритм

1. Ищем наиболее загруженный сервер(RAM в приоритете)

2. Выбираем на нем самый оптимальный для перемещения контейнер:• Больше всего потребляющий RAM, CPU • Меньше всего HDD

3. Проблема – локальные минимумы

OptaPlanner (ex. Drools Planner)• Employee shift rostering: timetabling nurses, repairmen, • Agenda scheduling: scheduling meetings, appointments• Educational timetabling: scheduling lessons, courses, exams,

conference presentations• Vehicle routing: planning vehicles (trucks, trains, boats,

airplanes) with freight and/or people• Financial optimization: investment portfolio optimization, risk

spreading• Bin packing: filling containers, trucks, ships and storage

warehouses, but also cloud computers nodes

Правила Drools - Жесткие ограничения

1. На Целевом сервере должно хватать ресурсов для перемещения(RAM, HDD)

2. Контейнер не может мигрировать на свой же сервер3. На этой Целевом сервере не должно быть контейнеров

того же окружения того же типа (Anti-affinity)

Правила Drools – Мягкие ограничения

1. Мигрировать наиболее загруженные по памяти и cpu контейнеры

2. Мигрировать наиболее легкие контейнеры (HDD)3. Целевой сервер должен быть наименее нагруженным

по LA и memUsed

Кластеризация - Hazelcast

• Migration Queue• Migration Task Worker• Migration Watcher

Тестирование - Создали симулятор облака

• 10-100 Серверов• 2000-100000 Контейнеров• 31 sec max

• Drools Benchmarking• https://github.com/Cloudslab/cloudsim/

Тестирование – реальный Benchmark

• Контейнер• 32 GB RAM• 1 TB Storage

• «Замерзание»• 0.5-2 секунд• В зависимости от интенсивности записи

Pets (Stateful) vs. Cattle (Stateless)

Высокая доступность и отказоустойчивость

HA на базе Микросервисов (Stateless)

HA между несколькими ЦОД• Anycast IP – дорого и привязано к

конкретным ЦОД• Global IP/Failover IP – доступно у некоторых

крупных игроков• Global DNS – можно реализовать где угодно

HA между несколькими ЦОД• Глобальное

неизменное DNS-имя, независимо от ЦОД

• Уникальное DNS-имя для адресации внутри ЦОД

HA и Гео-балансировка

Живая миграция между ЦОД

• «Замерзание» 2-9 секунд

Эвакуация в другой ЦОД

Отказоустойчивость для Stateful приложений

1. Как гарантированно сохранить и восстановить самые важные данные?

2. Что делать, если выйдет из строя 1,2,3…N серверов?

3. Что делать, если выпадет одна или несколько стоек?

4. Возможна ли отказоустойчивость, если у меня нет денег на SAN, который стоит как чугунный мост?

Решение1. Software-defined storage,

интегрированный с системой виртуализации

2. Обеспечивает непрерывную репликацию данных между физическими серверами

3. Обеспечивает сборку всех виртуальных машин / контейнеров в случае падения 1 или более физических серверов

Преимущества

1. Работает поверх 1Gbps Ethernet2. Работает на commodity – железе3. Обеспечивает скорость, сравнимую с

SAN, особенно на чтение4. Поддерживает geo-распределенную

конфигурацию5. Можно использовать объектное

хранилище. Совместимо с API S3

Недостатки1. Полезный объем сокращается в 3

раза (как минимум)2. Сеть – bottleneck. Нужна выделенная

сеть для данных с неблокирующим switch

3. Сетевые задержки критичны (8 сек. максимум)

4. Скорость записи – bottleneck, поэтому нужны небольшие SSD для кэширования

Компоненты

1. Сервисы хранения данных (chunks)2. Сервисы метаданных - арбитры3. Клиенты (система виртуализации)

Роли

Выделенные роли Совмещаемые роли

Архитектура развертывания в ЦОД

Неблокирующий switch

Уровни репликации

1. Необходимо нечетное количество сервисов метаданных для арбитража

2. Кластер из 3 серверов переживает потерю 1 сервера

3. Кластер из 5 серверов переживает потерю 2 серверов, и.т.д.

Выживаемость

Особенности развертывания1. Система заточена по умолчанию

только для работы в L22. Для работы в L3 пришлось

допиливать1. Актуализацию IP-адресов в новом

сегменте2. Актуализацию DNS-имен

1 ЦОД. Потеря одного сервераRegion A

10.0.0.0/16

Local Replica Set

HW1

CT1

CT2

CT3

HW2

CT3

HW3

CT1

CT2

2 ЦОД с L3. Потеря нескольких серверов

Выводы1. Overprovisioning контейнеров можно

вылечить с помощью DRS, но нужна Live Migration (нет в LCX)

2. Live Migration можно использовать для построение гибридного облака на базе контейнеров

3. Для HA между ЦОД лучше всего подходит ориентация на DNS, а не на IP

4. SDS помогает автоматизировать DR для контейнеров с важными данными

Dmitry Lazarenkodl@jelastic.com

@lazarenkod