FT & HA Rails приложений —

это просто

Ричард Шевел

Look At Me Engineering

Увеличение отдачи от существующих ресурсовОбъединение общих ресурсов инфраструктуры в пулы и уход от устаревшей модели «один сервер

- одно приложение» с помощью консолидации серверов.

Повышения коэффициента использования серверов60-80% (по сравнению с 5-15% с невиртуализированными серверами).

Повышение отказоустойчивости

Масштабирование инфраструктурыВозможность плавного обновления и наращивания аппаратной платформы, удобный перенос

сервисов.

Распределение ресурсов

Каждая машина получает столько ресурсов, сколько ей необходимо.

Гибкое распределения ресурсов между службами

Изоляция службВеб-сервер отдельно, База данных отдельно и тд.

Отличное решение для создание 3х компонентного ландшафтаПродуктивная среда, среда контроля качества, среда разработки.

Виртуализация VS все…

Продуктивная

средаСреда

разработки

РепозитарийРазработчики Пользователи

Администраторы

1 2

Распространенное решение :

2x компонентный Ландшафт

— Организация продуктивной среды

— Организация среды разработки

Продуктивная

среда

Среда контроля качества

Среда разработки

Репозитарий

Система

тестирования,

избранные

пользователи

Разработчики Пользователи

Администраторы

1 2 3

3х компонентный Ландшафт

— Организация продуктивной среды

— Организация среды контроля качества

— Организация среды разработки

NginX

FrontEnd +

Reverse Proxy

Apache + mod_rail

BackEnd

Users

MemCached

NginX

FrontEnd

Apache + mod_rail

BackEnd

MemCached

NginX

BackEnd

Varnishd

FrontEnd

MySQL

Server 1 Server 2Server 3

Минусы

— Множество зависимых сервисов на одном сервере

— Низкая масштабируемость

— Не оптимальное использование ресурсов

— Плохая отказоустойчивость

— Ограничения на количество соединений

Невиртуализированная архитектура

VM APP

NginX + passenger+

memcached

Users

VM DB

MySQL

Server 1

Server 2

Server 3

Плюсы

— Изолированные сервисы

— Гибкое разграничение прав

— Высокая масштабируемость

— Оптимальное использование ресурсов

— Высокая отказоустойчивость

VM LB

Load Balance

VM LB

Load Balance

VM APP

NginX + passenger+

memcached

VM APP

NginX + passenger+

memcached

VM STATIC

Varnish + nginx

VM QC

NginX + passenger+

memcached

VM STATIC

Varnish + nginx

VM DB

MySQL

VM DEV

NginX + passenger+

memcached

Виртуализированная архитектура

Front End

Engine XUsers

Back End

(httpd, thin,

mod_rails, etc)

Back End

(httpd, thin,

mod_rails, etc)

Необходимо стороннее решение по

резервированию

Малое количество алгоритмов

планировщика нагрузки

Единая точка входа и

выхода

Ограниченное число портов на

сервере для осуществления

проксирования

Балансировка нагрузки

Reverse – Proxy (Nginx, Apache mod proxy, etc)http://sysoev.ru/nginx/

http://httpd.apache.org/

Распространенное решение :

Вариант исполнения

LVS Active

RouterUsers

Back End

(httpd, thin,

mod_rails, etc)

Back End

(httpd, thin,

mod_rails, etc)

LVS

Backup

RouterЕдиная точка

входа

Резервирование

в комплекте

Множественные точки выхода

heartbeat

IP Тунель

Балансировка нагрузки

LVS (Piranha Configuration Tool — Часть RHEL/CentOS)http://www.linuxvirtualserver.org/

http://www.redhat.com/support/wpapers/piranha/

Вариант исполнения

Наиболее оптимальное решение:

NginxApache +

mod_rails

Запрос

Nginx Thin

Запрос

Server

Server

Слишком много надо

ресурсов для

поддержания 2х HTTP

серверов.

Необходимо дополнительно

настраивать мониторинг на

утечки памяти и т.д.

Apache +

mod_rails

Server

Запрос

Слишком много

ресурсов для Apache.

При большой

нагрузке.

Нет контроля за количеством

работающих воркеров

Back End

Распространенное решение :

Nginx +

passenger

Запрос

VM

Rewrite rules

Файловый upload, модуль nginx_upload_module http://www.grid.net.ru/nginx/upload.ru.html

— Загрузка файла — медленные запрос и его необходимо уводить в сторону

— Снижение или экономия потребления памяти

—Высвобождение процессов обработчика

Алгоритм работы:

1) Nginx обрабатывает загрузку

2) процессы обработчика свободны, а значит могут обрабатывать быстрые запросы

3) Nginx обработал загрузку

4) в приложение передается локальный путь к файлу и приложению нужно провести только

манипуляцию с файлом

Тест : 10 файлов по 100MB

Без nginx_upload_module расход памяти на загрузку +200MB

С nginx_upload_module расход памяти на загрузку +5MB

Тюнинг GC (passenger_ruby)

export RUBY_HEAP_MIN_SLOTS=100000

export RUBY_HEAP_SLOTS_INCREMENT=50000

export RUBY_HEAP_SLOTS_GROWTH_FACTOR=1

export RUBY_GC_MALLOC_LIMIT=30000000

export RUBY_HEAP_FREE_MIN=20000

http://www.rubyenterpriseedition.com/documentation.html#_garba

ge_collector_and_object_space

Проброс на среду контроля качества по куке.

if ($cookie_qc = "1")

{

proxy_pass http://192.168.1.15;

break;

}

Back End

Основные проблемы при большой нагрузке:

I. Контента не бывает мало и он лежит обычно на HDD

II. Большие HDD по определению медленные, много маленьких в

сервер не вставишь

III. Хорошие дисковые полки – дорогое удовольствие

IV. Возможно использовать SSD диски, под отдачу контента, но

технология еще не обкатана, и SSD предельно дороги

Что можно сделать:

1. Закэшировать часто запрашиваемый статический контент в

оперативной памяти (использование varnishd)

http://www.varnish-cache.org/

1. Распределить контент по разным серверам, использовать

распределенные файловые системы такие как pohmelfs

http://www.ioremap.net/projects/pohmelfs/, mogilefs

http://www.danga.com/mogilefs/ для быстрого доступа к ним.

2. Создание большого количества Виртуальных Машин с кэшем для

равномерного распределения отдачи контента

Отдача статического контента

NGINX

Front EndHDD

Запрос

Распространенное решение :

Количество файлов ~ 10 Миллионов

Количество папок ~ 1,5 Миллионов

Уровень вложенности ~ 6-7Упираемся в скорость

дисков

Растет wait

производительность

падает

NGINX

Front EndHDD

Server 1

Server 1

NGINX

Front EndHDD

Server 2

Запрос

Load

Balance

Упираемся в скорость

дисков

Отдача статического контента

Content-Type: image/jpeg

Last-Modified: Tue, 26 Apr 2011 19:36:38 GMT

Expires: Thu, 26 May 2011 19:39:21 GMT

Cache-Control: max-age=2592000

82+11:01:23

Hitrate avg: 0.9773 0.9792 0.9292

VARNISHD

Front End

NGINX

Back End

HDDRAM

Заголовок

Статистика кэша

Запрос

Virtual Machine

VARNISHD

Front End

RAM

NGINX

Back End

HDD

NGINX

Back End

HDD

VARNISHD

Front End

RAM

VARNISHD

Front End

RAM

Load Balance

VM 1 VM 2 VM 3

VM 4 VM 5

Запрос

Реплика

Количество файлов ~ 10 Миллионов

Количество папок ~ 1,5 Миллионов

Уровень вложенности ~ 6-7

Отдача статического контента

Для чего нужен и как помогает :

1. Слежение за доступностью и работоспособностью проекта.

2. Выявление тонких мест в технической реализации ландшафта.

3. Возможность увидеть Boost приложений.

4. Возможность увидеть проблемы в кодовой базе.

5. Возможность увидеть динамику нагрузки на сайт.

6. Повышение шансов вовремя распознать атаку типа ДДоС.

3 вида мониторинга : Внешний, Внутренний, Приложения

Nginx + HttpStubStatusModule

Active — Количество всех открытых соединений включая соединения типа proxy_pass

Read — Количество запросов на чтение

Write — Количество чтений тела запроса , запись ответа клиенту

Wait — Количество соединений типа keep-alive connections

Мониторинг по логам :

log_format upstream_response '"$uri" $status $request_time $upstream_response_time';

$request_time — это время обработки запроса. Считается от получения первых

данных от клиента до оправления последних данных для клиента в ядро.

$upstream_response_time - это время, которое прошло с того момента, как nginx

отправил бэкенду запрос и до того момента, когда бэкенд ему полностью ответил.

Мониторинг

Мониторинг (на примере одной из нод)

До изменений

Время отработки бэкенда 350мс (±50мс)

Полное время загрузки страницы с выключенным кэшом (30+)сек

Полное время загрузки страницы с включенным кэшом (15+)сек

Нагрузка дисковой подсистемы на сервер статики (93%)

Коэффициента использования серверов - 15 %

Не масштабируемая архитектура

Низкая отказоустойчивость

Отсутствия как класс continuous deployment

После изменений

Время отработки бэкенда 200мс (±20мс)

Полное время загрузки страницы с выключенным кэшом (4-6)сек

Полное время загрузки страницы с включенным кэшом (4-6)сек

Нагрузка дисковой подсистемы на ноде сервера статики (20%)

Коэффициента использования серверов - 70 %

Высоко масштабируемая архитектура

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

На текущий момент внедрен mini-continuous deployment

Итоги (на примере Look At Me)

Вопросы?