Сегодня Битрикс презентовал своё новое решение – “веб-кластер”. Для тех кто не в курсе – поясню, что эта штука позволяет разместить высокопосещаемый проект не на одном, а на нескольких серверах, и в любой момент добавлять новые сервера для ускорения работы сайта. А так же безопасно изымать любой сервер для ремонта, апгрейда, или в случае его выхода из строя. Разумеется, мне как их первому конкуренту (в лице компании Юмисофт) в первую очередь было нужно узнать, что же они принципиально нового предлагают рынку.
А ничего. В хорошем смысле ничего. Битрикс перестал валять дурака и “изобретать велосипед” – видимо попался таки в команду умный технолог, поэтому вместо “велосипедов” они взяли и сделали всё так как принято делать у нормальных людей. В этом посте я расскажу простыми словами – что конкретно они сделали и как вам повторить то же самое в своём проекте.
Рассмотрим основные части кластера:
0. Cloud – облако, набор серверов, на котором всё это будет крутиться.
1. Load balancer – балансировщик входящей нагрузки.
2. MySQL replication – популярный вид кластеризации баз данных.
3. Network file system – распределённое файловое хранилище.
Как было сказано выше, кластер – это набор из произвольного количества веб-серверов. Они могут выполнять одну и ту же задачу, либо разные в зависимости от целей. Начнём с серверов: тут для них предлагается использовать виртуальные машины aws.amazon.com. Я не сказал бы, что это разумное решение: виртуалки априори медленные, но здесь ключевой момент – простота их создания. Нажал на кнопку – создалась. Причём не дефолтная машина, а настроенная конкретно под ваши нужды. Можно создавать по расписанию или вообще динамически при росте нагрузки. Попал ваш сайт под мощный поток посетителей – оно р-р-р-аз и создало несколько новых машин. Кончилась нагрузка – машины отключились. Красота.
Разумеется, в качестве серверов кластера могут выступать любые сервера в интернете: хоть виртуальные, хоть железные. Для справки: свой личный “амазоновский” кластер бесплатно может сделать себе любой человек, который не поленится запустить установку свежего дистрибутива Ubuntu Server.
Балансировщик нужен для того, чтобы распределять входящие запросы посетителей сайта между серверами кластера. В качестве него предлагается использовать nginx, гуглите “nginx load balance” и получаете кучу ссылок на готовые примеры.
Репликация баз данных нужна для того, чтобы записывать данные на одном сервере (он называется master – мастер), а читать их со всех остальных (соответственно slave – слейв). Так как обычно операций записи мало, а операций чтения много, то путём простого увеличения количества слейвов можно неограниченно наращивать “мощность” проекта. Данные с мастера на слейвы перетекают в фоновом режиме чисто средствами MySQL, причём слейвы можно добавлять и убирать в любой момент. Гуглите “mysql replication” и получаете инструкции.
Распределённое файловое хранилище нужно для того, чтобы все сервера имели один и тот же набор файлов. Если пользователь загрузил картинку “куда-то” на один из серверов, то она должна появиться везде. Почему? Потому что другим пользователям информация может быть отдана с другого сервера. Для реализации товарищи из Битрикса рекомендуют “csync2” – оно работает в фоновом режиме и тупо синхронизирует файлы между серверами, чтобы везде всё было одинаково.
Всё. Вот вы и сделали кластер. А теперь – файн-тюнинг:
Первый же камень преткновения, на который вы наткнётесь при переводе своего проекта (я имею в виду проект на другой CMS или самописный) на такую модель – будет в операциях с базой данных. Суть в том, что приложение должно уметь отличать “пишущие” запросы от “читающих”. Другими словами, INSERT, UPDATE, DELETE, а так же CREATE, ALTER и DROP нужно выполнять только на мастере. Запросы SELECT в принципе можно выполнять везде. Чтобы переучить ваш движок на такой способ мышления, потребуется весьма ощутимое время.
Кроме того, битриксоиды придумали интересную штуку: так как данные с мастера на слейвы утекают с некоторой задержкой, они приучили систему распознавать “критические” пишущие запросы. После такого запроса все данные до самого конца выполнения php-скриптов берутся (SELECT) только с мастера во избежание ошибок из-за той самой задержки.
Вторая мысль, которую нужно рассмотреть – это выделение серверов под задачи. Не обязательно делать все сервера одинаковыми и поручать им одинаковые задачи. Пусть часть из них обслуживают, например, интернет-магазин, а другая часть – собирает статистику.
Третья мысль – кластеризация memcached. Битрикс вынес его в начало своей презентации, но вы можете запустить его и позже. Его преимущество в том, что он напрямую вяжется с nginx (помните первый пункт?) и позволяет тому отдавать закэшированные страницы (или блоки) фактически напрямую из оперативной памяти. Ваша задача – точнее задача ваших скриптов – помещать кэшируемый контент в memcached.
Как разрабатывать проект на кластере? Частый вопрос для представителей веб-студий. Да точно так же, как на обычном сервере. Кластер для вас будет всего лишь одним большим компьютером, на который вы точно так же заходите по ssh и работаете.
Коллеги, поделитесь вашим опытом настройки кластеров! Самый интересный рассказ будет опубликован в следующем посте.