Сразу стоит оговориться, что данная статья написана скорее не для того, чтобы показать возможность работы данного продукта на Google Cloud Platform (GCP), он и без этого будет на ней работать. Bitrix был взят для опытов просто как популярная платформа. Он и сам умеет строить пулы, ноды и прочее в своем “веб окружении”, правда со своими грабельками. И именно поэтому были взяты даже машины на Debian для тестов, а не любимый всеми CentOS.
На самом деле материал применим ко многим веб-проектам. Точнее это простенький гайд по построению отказоустойчивых и распределенных приложений на базе виртуальных машин Google Compute Engine, баз Google Cloud SQL и балансировщика нагрузки Google.
Уважаемые знатоки и профессионалы Bitrix, вариантов реализации данного решения очень много, тут приведен лишь один. Можно рассматривать и виртуальные машины, и контейнеры, и Google App Engine в виде облачной платформы. Плюсом ко всему будет возможность подключения хранилища Google Storage, которая была включена в движок уже достаточно давно. Вообще, буду рад обсудить возможность совместного пилота Bitrix на GCP, возможно именно ваш опыт будет описан в следующий раз, как применимый именно к Bitrix.
Приступим
Что такое Bitrix, мы объяснять долго не будем. Это профессиональная система управления веб-проектами и огромное количество корпоративных сайтов, интернет-магазинов, порталов и сообществ работают именно на нем.
Несмотря на объем текста с картинками, у меня вся процедура развертывания заняла около двух часов с учетом выловленных грабелек.
Начнем с создания базы данных
Меню → Cloud SQL → Создать экземпляр
Выбираем MySQL, «Дальше», «Создать базу второго поколения».
Указываем имя базы, местоположение, зону, размер машины, тип диска, объем хранилища, расписание резервного копирования, пароль root, время перерыва на тех. Обслуживание, добавляем сеть. Я для теста выбрал машину 1vCPU, 1,7Gb RAM и 200Гб обычного HDD хранилища, потом можем изменить. При создании базы, обращаем внимание на зону, в ней-же расположится виртуальная машина.
Разрешенную сеть для тестов можно поставить 0.0.0.0/0 (все) и подключаться напрямую. Но мы поступим правильно и сделаем по-человечески, не будем тут ничего указывать, безопасность важнее.
Далее нам потребуется настроить сервисный аккаунт. Сразу оговорюсь для чего он нужен. Если Вы подключаетесь к базе данных прямо по ее IP-адресу, то этот шаг можно пропустить. Аккаунт нам потребуется для безопасного подключения через прокси. Иначе, машина создастся с записью по умолчанию, которая не имеет доступа к другим службам.
Итак, открываем меню, переходим в IAM и администрирование → Сервисные аккаунты → Создать сервисный аккаунт. Название и ИД указываем на свой вкус, выбираем роль Cloud SQL → Клиент Cloud SQL. OK, закончили.
С базой разобрались.
Создаем виртуальную машину
Жмем на «бутерброд» (Меню) → Compute Engine → Экземпляры ВМ → Создать экземпляр.
Возьмем образ Debian 8 или любой другой, на вкус. Берем для старта простую машину: 1 ядро, 3,5Гб RAM.
Изменяем сервисный аккаунт машины на тот, который мы создали на предыдущем шаге (для связи с нашим Cloud SQL. Ставим галки «разрешить HTTP» и «разрешить HTTPS» в зависимости от планируемого протокола.
Далее нам нужно слегка автоматизировать нашу машину, точнее запускать на ней SQL-прокси. Для этого раскрываем параметры «Настройка параметров управления, диска, сети и SSH-ключей» и в разделе Автоматизация → Сценарий запуска пишем:
sudo wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64
sudo mv cloud_sql_proxy.linux.amd64 cloud_sql_proxy
sudo chmod +x cloud_sql_proxy
sudo ./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306 &<INSTANCE_CONNECTION_NAME> — берем из свойств нашей базы данных, это «Название соединения с экземпляром». Статья по подключению через прокси
Почему так? На самом деле для запуска нужна только последняя строчка, все остальное достаточно выполнить один раз при настройке машины. Это пример, чтобы не разбивать на всю статью по кусочкам.
Далее важный момент. Идем на вкладку «Диски» и снимаем галку «Удалить загрузочный диск при удалении экземпляра». Да, мы будем удалять нашу машину после ее настройки.
С созданием машины закончили, нажимаем «создать» и ждем.
По завершении создания, подключаемся по SSH к нашей виртуалке и настраиваем ее. Про настройку самой машины под Bitrix я писать много не буду, материалов полно и на Хабре и в Интернете. Есть даже готовый скрипт “Веб окружение”, но я его не использовал по религиозным убеждениям. Мне было проще все запустить руками, чем разбираться в чужом бутерброде. Опишу только то, что делал я для запуска. Причем без какой-либо оптимизации и тюнинга, иначе меня могут завалить комментариями гуру оптимизации PHP, Zend, NGINX и прочего, без обид.
Для начала обновим:
sudo apt-get update
sudo apt-get upgradeMySQL-клиент:
sudo apt-get install mysql-clientApache:
sudo apt-get install apache2PHP:
sudo apt-get install php5 libapache2-mod-php5 php5-mysqlРестартуем Apache:
sudo systemctl restart apache2Далее нам для «пряморукого» подключения к базе данных потребуется Cloud SQL прокси. Скрипт его запуска мы писали при создании машины, он срабатывает при каждом ее запуске. Проверим работает-ли:
mysql -u root -p --host 127.0.0.1Вводим пароль рута от базы, наслаждаемся строчкой:
mysql>Если с первого раза не сработает, то проверяем стартовый скрипт машины и перезагружаем ее.
Разворачиваем Bitrix
Обычным wget загружаем прямо с сайта:
Wget https://www.1c-bitrix.ru/download/start_encode_php5.tar.gzСсылка указана для примера на стартовую версию. Далее распаковываем файлы в каталог веб-сервера, я оставил по-умолчанию.
С машиной вроде закаончили, переходим к списку виртуальных машин на Google Cloud и открываем нашу машину по HTTP (или HTTPS, если настроили):
В процессе установки указываем MySQL сервер 127.0.0.1, логин и пароль root от нашей базы Cloud SQL и далее идем по нужному нам пути в мастере до окончания установки. Когда все готово, можем проверить производительность конфигурации. Что у меня получилось:
Я, конечно, обратил внимание на производительность MySQL и по началу был удивлен. Но, как выяснилось позднее, это вполне адекватные данные, база в реальности выдает нормальную производительность, просто она у нас все-таки облачная.
Все работает, перейдем к следующему этапу.
Создадим масштабируемую группу машин и поставим ее за балансировщик нагрузки
Я сделаю это в одном регионе, в Европе. Но для понимания сервис все-таки возможно разнести и по регионам (например, если у нас есть партнеры в Азии). Принцип работы похож, только создавать нужно будет две группы в двух регионах и реплику базы там-же.
Для начала нужно создать образ диска. Удаляем нашу виртуальную машину. Да-да, именно удаляем. Тут важно вспомнить, сняли ли мы при ее создании галку «Удалить загрузочный диск при удалении экземпляра». Если забыли, то клонируем (при открытии машины кнопка сверху) и снимаем ее в параметрах. После удаления машины, нам будет доступен ее диск для создания образа.
Идем в раздел Compute Engine → Образы, нажимаем “создать образ”. При создании ничего хитрого нет, указываем наш освободившийся диск и все готово.
Далее создаем шаблон наших будущим машин с Bitrix.
Идем в Compute Engine → Шаблоны экземпляров. Создаем шаблон по аналогии с нашей виртуалкой, но уже из нашего образа.
Указываем:
- Имя
- Размер (нужный нам размер одной ВМ, далее они будут «размножаться»)
- Образ (в разделе «Пользовательские образы» указываем созданный ранее)
- Сервисный аккаунт (созданный нами ранее с правами «Клиент Cloud SQL»)
- Разрешаем трафик по настроенным протоколам HTTP/HTTPS
- Раскладываем «Настройка параметров управления, диска и SSH-ключей» и пишем сценарий запуска:
sudo ./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306 &Повторюсь, этот сценарий включался при создании машины, теперь достаточно только последней строчки. Шаблон настроен. Помним про то, что <INSTANCE_CONNECTION_NAME> берем с свойствах нашей PaaS базы данных.
Создадим группу экземпляров:
Открываем Compute Engine → Группы экземпляров → Создать группу экземпляров.
Указываем:
- Имя,
- Зону (я указывал зону расположения базы),
- Шаблон (который мы только что создали),
- Включаем автомасштабирование,
- Основа для автомасштабирования — балансировщик
- Минимальное и максимальное количество экземпляров указываем как нам нужно
- Можем создать проверку состояния. Укажем путь HTTP и, если машина не ответит, то будет прибита и запустится другая.
Создали.
Балансировщик нагрузки
Жмем на «бутерброд» слева сверху, Сеть → Балансировка нагрузки → Создать балансировщик нагрузки.
Балансировка нагрузки HTTP/HTTPS -> Начать настройку.
Указываем:
- Назание, как нам удобно
- Конфигурация серверной ВМ -> Серверные службы и сегменты -> (раскладываем) Серверные службы -> Создать Серверную службу. Указываем группу экземпляров, которую создавали. Включаем нужный нам режим балансировки (я включал по частоте запросов), указываем значения показателей, Готово. Тут же указываем проверку состояния машин, которую мы создавали, или создаем новую. Можем включить CDN.
- Конфигурация интерфейсной ВМ. Это то, то будет смотреть во внешний мир из нашего решения. Указываем название, протокол HTTP/HTTPS, тип адреса (статика конечно же), подгружаем сертификат (если нужен).
Готово, создать. Работать начинает практически сразу, можно не ждать.
После создания балансировщика, открываем вкладку «интерфейсные ВМ» и видим его внешний адрес. По нему наш Bitrix и будет работать в Google Cloud Platform. Переходим по адресу, наслаждаемся. Этот адрес можем писать в DNS.
Напоследок пара тестов производительности и масштабирования
Сначала, что мы имеем:
- Cloud SQL база — 1vCPU, 1,7Gb RAM
- Группа виртуальных машин с масштабированием от одной до семи, каждая 1vCPU, 3,5Gb RAM (можете подобрать оптимальную для вашего проекта, я взял стандартные машины)
- Балансировщик нагрузки с одним внешним IP-адресом
Запуск дополнительных экземпляров машин я настроил сначала при 100 одновременных соединениях, чтобы показать как работает. Для боевого решения можете использовать собственные параметры. Тестирование проводилось в пробном периоде GCP с ограничением на количество ядер для всех машин всего в восемь штук, потому восьмое ядро заняла машина с которой непосредственно запускался тест.
Сначала получился такой график теста:
Стало понятно, что машины не успевают запускаться. Потому их минимальное количество было увеличено до двух, количество соединений на машину уменьшено до 50, а предельная нагрузка снижена до 80%. В итоге получилось:
В итоге все взлетело, автоматическое масштабирование заработало как надо.
Конечно много чего можно еще добавить к нашему решению. Например, тюнинг сервера под сам Битрикс, копирование и репликацию базы, отработку отказа и пр. Это тема уже для других материалов. Данная статья написана скорее не для того, чтобы показать возможность работы Bitrix и других веб- и мобильных проектов на Google Cloud. Это простенький гайд по построению отказоустойчивых и распределенных приложений на базе виртуальных машин с применением балансировщика нагрузки Google.
Чтобы организовать распределенное приложение, нам понадобится просто реплицировать базу в другой регион, создать еще одну группу виртуальных машин в другом регионе и включить машины в наш глобальный балансировщик. Google сам будет выбирать оптимальных маршрут и направлять пользователей к приложению в ближайшую локацию.
Чуть позже будет опубликована еще одна статья, как запустить Bitrix на Google App Engine. Думаю, что это будет уже интереснее.
В последнюю очередь коснемся стоимости сервисов:
- В минимальной конфигурации — 2 VM веб-сервера (1 vCore, 3,5 Gb RAM), 1 VM MySQL (1 vCore, 1,7 Gb RAM), load Balancer) ~100$/мес
- В максимальной конфигурации (7 VM веб-сервера, 1 VM MySQL, load Balancer) ~230$/мес
Цены естественно приблизительные, для конкретного боевого решения может потребоваться мощная БД, распределение по регионам и прочее. Тут все рассчитано для расположения в европейском ЦОДе без излишеств.
Кроме скромного прайса за впечатляющие ресурсы, радует еще и то, что Google Cloud Platform стала наконец то доступна и в России для безналичной оплаты организациям.
Автор: RomanGN
