20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов",

Несколько кейсовиз жизни "больших" проектов

Виталий Гаврилов

Технический директор «Ленвендо»

[email protected]

www.lenvendo.ru

2013 dev.it-portfolio.net

«Ленвендо» в приближении

тел.: +7 (812) 322-95-87 [email protected]

Профессионал в области разработки сложных Интернет - решений и высоконагруженных проектов

О чем мы сегодня поговорим?


Управляемое статическое кеширование√ nginx + embed perl√ Redis√ RabbitMQ

Где и когда нужно использовать СУБД Oracle

Хитрости проекта с использованием СУБД PostgreSQL, оптимизированного под высокие нагрузки

√ pl_proxy√ embed perl

Резервное копирование высоконагруженного проекта: проблемы и решения

Особенности построения проекта, распределенного на 2 и более датацентрах,

√ round-robin DNS√ csync2√ mysql multimaster replication√ Memcached

Хитрости проекта с использованием СУБД PostgreSQL, оптимизированного под высокие нагрузки

Раздел 1.


Масштабирование проекта с использованием pl_proxy

в каждой БД - полная копия всех данных

использование встроенной WAL-PITR нативной репликации

всего два кластера master и slave

в кластере master: 2 сервера (можно больше). Основной сценарий использования: RUN ON ALL

в кластере slave: 4 сервера (можно больше, но должно быть кратно двум). Основой сценарий использования: RUN ON ANY

Хитрости проекта с использованием СУБД PostgreSQL

Pg-DB-Master1

Pg-DB-Master2

Pg-DB-Slave1-1

Pg-DB-Slave1-2

Pg-DB-Slave2-1

Pg-DB-Slave2-2

Replication

Replication

Replication

Replication

WEB-Application

WEB-Application

WEB-Application

WEB-Application

SQL RW

SQL RW

SQL

SQL

SQL RO

SQL RO

SQL RO

SQL RO

pl_proxy connection








Доступ к сессии пользователя через embed perl

хранение сессий в memcached

передача ключа сессии через сессию PostgreSQL

доступ в систему полнотекстового поиска Sphinx через mysql интерфейс непосредственно из plperl



Pg-DB-Master1WEB-Application

Memcached server

Sessions data Read session data

Sphinx Full Text search RT indes

MySQL APIRead data

Update Data





Хитрости при использовании СУБД PostgreSQL


Раздел 2.


Типы контента:

Файлы проекта

Статический контент проекта

База данных проекта

Настройки виртуальных (и хостовых) машин или образы виртуальных машин




Много задач? Инструмент один – bacula

Файлы сайта: полная резервная копия - 1 раз в 1-2 недели, дифференциальная копия - 1 раз/день

Cтатические файлы: полная резервная копия - 1 раз/месяц, дифференциальная копия – 1 раз в 3-7 дней, инкрементальная копия – 1 раз/день

резервная копия БД (бизнес-критичные таблицы) не реже 1 раз/день

полная целостная резервная копия - не реже 1 раз/нед.

(http://www.bacula.org/en/)


Резервная копия БД – о чем надо помнить?

должна выполнятся в наименее загруженное время со slave сервера, на котором нет продуктивной нагрузки во время снятия копии

должна быть логически целостной

помните, резервная копия - это не спасение

и дублирующий slave сервер тоже

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

Дублирующий slave сервер с отставанием во времени от 15 минут до часа (зависит от квалификации службы поддержки)



Полная резервная копия конфигурационных файлов всех узлов системы

Копия нужна после каждого внесения изменений

Резервное копирование образов виртуальных машин

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



Наличие резервной копии не гарантирует оперативное восстановление


необходимо регулярно проводить процедуры тестового восстановления системы

процедура должна выполняться как минимум после каждого внесения изменений в конфигурацию

Особенности построения проекта, распределенного на 2 и более датацентрах

Раздел 3.



Причины особенностей

Скорость взаимодействия внутри датацентра гораздо выше, чем между датацентрами

Если взаимодействие между датацентрами идет по публичным сетям, трафик должен цифроваться

В общем случае невозможно предугадать в какой из датацентров придет следующий запрос посетителя, поэтому каждый датацентр должен содержать достаточно данных для подготовки ответа, либо запрос должен быть прозрачно проксирован в датацентр, где есть необходимые данные

Датацентр 2

Датацентр 1

VPN tunnelor internal network

Master-2

Master-1

Slave 1.1

Slave 2.1

Multi-master replication

Master-Slavereplication


Slave 2.2


Slave 1.2


web-server 1.1

Read/Write

HA Read/Write

Read only

Read only

web-server 2.1

HA Read/Write

Read only

Read onlyRead/Write

Read only

Read only

Read only

Read only

CS1

CS2

web-client

Static FE1

StaticFE2

ACTIVE Connection

ACTIVE Connection

NFS Read only

NFS Read only

Bidirectional synchronization

FE 1

FE2

ACTIVE Connection

ACTIVE Connection

NFS RO

NFS RO

VPN tunnelor internal network

NFS RW

NFS RW


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

встроенная поддержка шифрования продуманные механизмы определения «кто прав» в случае

конфликтов синхронизации понятная структура конфигурационного файла

Недостатки

критичен к стабильности соединения (может зависнуть, нужен контроль)

недостаточно документирован синхронизация требует большого числа дисковых операций и

достаточно много времени (до 15 минут на 50 Гб данных), при этом одновременная двусторонняя синхронизация хотя и возможна, но не рекомендуется

Синхронизация файлов – csync2


Основные настройки

server_id = N

log-bin = <путь к файлу журнала транзакций>

relay-log = <путь к файлу журнала транзакций мастер-сервера>

relay-log-index = <путь к индексному файлу журнала транзакций мастер-сервера>

auto_increment_increment определяет шаг изменения AUTO_INCREMENT

auto_increment_offset определяет начальное значение инкремента

log_slave_updates логирует обновления с мастера

slave_net_timeout таймаут получения данных с мастера перед сбросом соединения

Multimaster репликация MySQL


Основные команды

START SLAVE [IO_THREAD | SQL_THREAD]

STOP SLAVE [IO_THREAD | SQL_THREAD]

SET GLOBAL sql_slave_skip_counter=<N>

CHANGE MASTER TO …

RESET SLAVE

Multimaster репликация MySQL


Где хранить сессии? Конечно, в memcached

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

общее хранилище для всех виртуальных машин кластера позволяет получить доступ к сессии достаточно быстро

Недостатки

требует кастомных инструментов поддержания актуальности данных между ДЦ

нагружает канал большим числом мелких пакетов в случае падения службы все сессионные данные могут

оказаться потерянными


http://www.memcached.org/

Управляемое статическое кеширование, как способ снижения нагрузки

Раздел 4.




Способы снижение нагрузки

Разделение контента на полностью динамический и условно статический контент

Перекомпоновка страниц для оптимального использования AJAX

Статическое кеширование условно-статического контента



Использование заголовков “Cache-Control” и “Expires”(дает разрешение браузеру не перезапрашивать содержимое страницы, не спасает от «скачков» посещаемости)

Использование кеширующего прокси сервера в связке с заголовками “Cache-Control” и “Expires”(дает устойчивость к «скачкам» посещаемости, не позволяет оперативно управлять обновлением кеша)

Использование управляемого статического кеширования(решает все поставленные задачи)



Посетитель

Internet

FE 1

FE 2

FE K




BE 1

BE 2

BE N

DB1

DB2

DB3


Сервера FE

Принимают все входящие подключения

Фактически самое ненагруженное звено в обработке запроса посетителя

Не обладает информацией о связи запроса с элементом динамической информации

В большинстве случаев это nginx (www.nginx.ru)



Nginx умеет

Сохранять полученный ответ в файлах по заранее определенному пути (директива proxy_store)

Определять наличие сохраненной копии файла

Отдавать готовые ответы из сохраненных копий

Nginx не умеет

Отслеживать корректность отдаваемых данных



За ведение статического кеша отвечает nginx

Из nginx на уровень приложения (в случае если запрос посетителя обрабатывается приложением, а не берется из закешированной копии, передается путь к файлу, в который будет сохранен ответ (файл кеша))

На уровне приложения информация о связке информационных элементов и файла кеша сохраняется в БД (лучше всего подходят NoSQL базы данных)

При обновлении элемента информации на уровне приложения отдается команда на удаление файлов кеша по обновленному информационному элементу (можно делать это как прямой командой в nginx, который посредством встроенного perl сможет удалять файлы, так и через диспетчер очереди, в случае нескольких FE серверов)




FE 1

Локальный кешЛокальный кеш

BE 1


Redis

Контент-менеджер

FE 2BE 2

AMQP

Обработчик очереди заданий

Удаление файлов


А как же поисковые системы?

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

У копии страницы есть время жизни, после которого она удаляется (что приводит к перестроению страницы, и, следовательно, к обновлению данных для поисковых систем)

Необходимо помнить об альтернативных способах передачи информации в поисковые системы (RSS ленты и т.д.)


Где и когда нужно использовать СУБД Oracle?

Раздел 5.

Где и когда нужно использовать СУБД Oracle?


Требования заказчика по безопасности и надежности хранения данных (при условии поддержки проекта квалифицированным DBA)

Специфика проекта, требующая тесного взаимодействия с внутренними системами заказчика, построенными на продуктах Oracle

Наличие у заказчика развернутого RAC и команды администраторов Oracle


Если масштабы проекта не смогут окупить трудозатрат на его поддержание

Если желание сделать проект на Oracle вызвано тем, что «Это же круто!», «А почему бы и нет?», «А вот у них Oracle, а мы что хуже?»

Заказчик не имеет возможности поддержки Oracle и не представляет во что это выльется

У вас в штате нет ни одного сотрудника, способного сделать резервную копию БД Oracle

Когда не стоит переходить на Oracle?

www.lenvendo.ru

[email protected]


III место в рейтинге Best in digital 2013

в номинации «Разработка Highload систем»

С удовольствием отвечу на ваши вопросы!

Technology

20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов",