ГлавнаяБитриксБитрикс веб кластер

Установка 1С-Битрикс веб кластер. Часть 2. Битрикс веб кластер


Веб-кластер - BitrixHub

Технология Веб-кластер для неограниченной посещаемости и нагрузки

Модуль Веб-кластер – это комбинация технологических решений, которые позволяют распределить один сайт на несколько серверов, решая тем самым несколько задач: обеспечение высокой доступности сайта, его масштабирование в условиях возрастающей нагрузки, балансирование нагрузки, трафика, данных между несколькими серверами. С веб-кластером Вы повысите производительность, масштабируемость и надежность вашего проекта!

  

Для каких задач нужен веб-кластер?

Кластер необходим для гибкого решения задач увеличения нагрузки и повышения стабильности сервиса. Так, при увеличении посещаемости можно быстро добавить в кластер новые серверы. А в случае выхода из строя одного из серверов кластера система продолжает беспрерывно обслуживать посетителей / клиентов. Не менее важная задача – это балансирование нагрузки, траффика, данных между несколькими серверами. При этому система позволяет снимать резервные копии со специально выделенных узлов кластера, не влияя на работу сайта, не выключая машины и не тормозя их. Отдельно стоят задачи гео-распределения. Когда вы запускаете географический веб-кластер, он позволяет поднимать целые группы серверов. В каждой из этих групп работает свой мастер – в независимых друг от друга датацентрах. Таким образом, ваши сайты, ваш бизнес полностью защищены от недоступности самих датацентров и каналов связи.

Как работает веб-кластер 1С Битрикс?

Рассмотрим какие технологии использует веб-кластер 1С Битрикс:

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

Секреты высоких нагрузок на 1С Битрикс с веб-кластером

1. MySQL Sharding (шардинг)

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

  

В отдельные базы можно вынести следующие модули продукта: Веб-аналитика, Поисковый модуль. 

2. Репликация MySQL

Схема «master slave» реализуется средствами MySQL / MariaDB. Этот стек технологии достаточно хорошо описан и используется широко. 

3. Балансировщик для выравнивания нагрузки между серверами

Остановимся на балансировщике подробнее. Платформа «1С-Битрикс: Управление сайтом» в функционале Веб-кластер позволяет гибко балансировать нагрузку между серверами, участвующими в репликации.

 

 

Мы получаем следующие ключевые особенности: гибкая балансировка нагрузки в MySQL, простота администрирования из одного интерфейса, быстрое неограниченное масштабирование без дополнительных затрат, горячий бекап (по факту это: создание резервных копий реального состояния). Для всего этого функционала не требуется доработка логики веб-приложения, все уже работает в данной редакции. 

4. Распределенный кеш данных (под управлением: memcached)

Технология позволяет кэшировать данные в оперативной памяти множества доступных серверов. Распределение реализуется путём сегментирования данных по значению хэша ключа по аналогии с сокетами хэш-таблицы. Клиентская библиотека, используя ключ данных, вычисляет хэш и использует его для выбора соответствующего сервера.

  

Это обеспечивает высокую эффективность – за счет централизованного использования кеша веб-приложением, а также надежность – за счет устойчивости подсистемы кешировния к выходу из строя отдельных компонентов, при этом гарантируется неограниченная масштабируемость – за счет добавления новых memcached-серверов по мере роста нагрузки. 

5. Непрерывность сессий

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

  

Возможность хранения данных пользовательских сессий в базе данных обеспечивает «прозрачность» сессии для всех веб-серверов кластера, т.к. после авторизации на одном из серверов пользователь должен считаться авторизованных и для всех других серверов. И обратное, после завершения сессии на любом сервере должно означать ее окончание на всех серверах сразу.

bitrixhub.ru

Установка 1С-Битрикс веб кластер. Часть 2 / likes 1 / блог студии Клондайк!

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

Битрикс веб кластер «почему все так плохо»

Первое что хотелось отметить при написании статьи 1С-Битрикс веб кластер. Часть 1 так это то что нормально собрать кластер и запустить на нем сайт удалось только с 5 попытки. Для этого пришлось как следует поковыряться в конфигурационных файлах веб кластера, детально изучить настройки да и вообще как именно собирает сервер.

Будем считать что сам кластер уже установлен.

Начнем с того что файлы на 2 ноде в течении 5 минут не появятся в следствии неправильно сконфигурированных синхронизаторов.

Что произойдет на самом деле?

Вы синхронизируете кластер и он заработает! Вы реально множите размещать файл на любом сервере изменять их и все с виду будет работать, но!

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

При более детальном рассмотрении станут понятны причины такого действия. Синхронизатор файлов csync2 при первом старте все валидно добавил и работает очень даже пристойно. По крону раз в 5 минут запуская соответствующий каждому файлу конфиг, более подробно можно посмотреть в cron.d

*/5 * * * * root /opt/webdir/bin/csync2_full_push site

И сам конфиг

/etc/csync2/csync2_вашсайт.cfg

тоже выглядит вполне пристойно

host вашсайт

include /home/bitrix/ext_www/вашсайт.ru;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/cache;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/managed_cache;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/stack_cache;

exclude /home/bitrix/ext_www/вашсайт.ru/upload/resize_cache;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/modules/xmppd.log;

exclude /home/bitrix/ext_www/вашсайт.ru/bitrix/modules/smtpd.log;

В свою очередь демон отвечающий за синхронизацию сайтов сейчас занят одним делом, собирает гигантский список файлов со скоростью 10–20 файлов в минуту! В свою бд. После чего начнет каждый файл по отдельной сессии перекидывать на новый сервер (со скоростю копирования файлов фактически ниже чем по ftp в несколько раз) учитывая неторопливость составления самой бд и при том очень большую прожорливость к I-O время когда обычный стоковый сайт битрикса появится на второй ноде около 21 часа! Все это время csync2 будет активно работать просаживая I-O системы на 98%. Не делая фактически ничего!

Прямое копирование файлов на вторую ноду приведет к еще более печальным последствиям - кластер встанет, поскольку теперь с обоих сторон будет иметься новый файл! И csync скажет что он запутался. Да и попросту встанет колом.

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

Но не все так плохо, битрикс это учел и делает так при первой синхронизации кластера, перенося весь сайт архивом на новую ноду, ну правда он не делает это с папкой ext_ да и первый раз там просто ничего нет. Так что функция на этот момент в битриксе машине есть, но собрана она так непродумано, что при реальной синхронизации делать первую синхронизацию придется своими руками.

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

И тут понятна причина, с такой скорость копирования мелких файлов можно вообще про это забыть как про страшный сон.

Но на этом веселье не заканчивается.

Мы добавляем второй сайт скажем test.kz и тут у нас начинается совсем смешные штуки.

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

Лезем в /etc/ansible для разбора полетов

Находим вот такую замечательную штуку {{ item. SiteCsync2 }} = ваш домен до точки!

А у меня два домена test1.ru test1.kz

Следовательно проверяем догадку смотря в конфиги

/etc/ansible/roles/web/task/balancer.yml

{{ csync_configdir }}/csync2_{{ item. SiteCsync2 }}.cfg»

Следовательно, наши конфиги перетерлись, так же эта переменная используется в ряде других мест, таких как самом файле конфига, так и в кроне и т. д. и т. п. Вообще в дальнейшем были найдены такие ошибки более чем в 57 местах, фактически по всему кластеру от бд до балансера. Поднять без полного перепиливания кластера два одинаковых сайта сразницей в домене невозможно! Кстати это относится и просто к размещению двух сайтов, у них так же будут небольшие проблемы при создании бд, они так же будут идентичны, и при разворачивании второго сайта он честно скажет что бд уже занята.

На мой вопрос в службу поддержки о невозможности использовать домен с разницей на 1 уровне был дан любезный ответ, «спасибо за обращение функция мультисайтовости с кластера будет скоро удалена»

WTF?!?!?!?!

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

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

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

  1. Стандартная сборка кластера — синхронизация 879 Mb заняла 21 час, с отсутствием любого статуса в панели или на сайте.
  2. После синхронизации папка bitrix была удалена поскоку по дате создания была более новая версия папки на слейв ноде (в ней лежит только dbcon.php созданный битрикс кластером. Да-да тот который создаетя с ошибкой в префиксе бд если сайты одинаковые по домену 2 уровня.
  3. Удаление данного каталога как и index.php на слейв ноде до синхронизации привело к такому же результату csync2 просто убил эти файлы и каталоги на мастер хосте. Как и говорил до этого первую синхронизацию нужно проводить ручками, стандартный метод просто неработоспособен.
  4. Убились все конфиги для одинаковых доменов 2 уровня.
  5. Упала производительность сайта примерно в 200 раз связано это с конфигурацией мастер слейва для статического контента, в купе с динамическим.
  6. Кластер не умеет работать с кешем, уже писал выше.
  7. Кластер не может работать с CDN практически по той-же причине.
  8. Кластер не может работать с композитом.
  9. Кластер не может работать с html кешем.
  10. Кластер из коробки вообще невозможно сконфигурировать, там попросту нет ни одного меню для этого, его базовая конфигурация наихудший вариант из всех возможных.
  11. Кластер без глубоких знаний linux поднять попросту невозможно.
  12. Кластер работает только на 1с-битрикс виртуальной машине, любой другой способ его установки настолько затруднителен что в 10 раз проще собрать свой кластер без использования 1с-битрикс, в принципе это справедливо и даже с использованием виртуальной машины.
  13. Очень сырой продукт в целом, мало того еще и практически не документирован.
  14. Заявление на презентации битрикс 14 о включение «кластера» с 2 серверами во все базовые решения полное и откровенное вранье, кластер как был отдельной «старшей» редакцией так ей и остался.
  15. В балансере нет четких правил по переключению мастер слейв ноды.

Но обо всем по порядку.

Допустим мы все победили и бд и файлы у нас синхронизированы все работает, но почему так все адски медленно? Производительность в 1с-битрикс упала до 0.2 со 170!

тут причина в конфигурации кластера по умолчанию.

Все что вы читали по поводу мастер-слейв мастер—мастер и т. д. вы множите выкину в мусорку, 1с-битрикс НЕ УМЕЕТ переключать конфигурации. Это попросту вранье, в нем нет ни единой строчки кода отвечающих за это. Как и нет ни единой строчки кода указывающей на вид текущей конфигурации, ровно как и документации по этому поводу. Даже в обучении битрикс виртуальной машине вы не найдете базовое расположение базового собранного кластера.

А выглядит он примерно вот так!

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

Вот как изменилась производительность:

Было:

Стало:

Я честно не верю что среднестатистический php программист которому начальник даст задачу собрать 1с-битрикс кластер. Качественно разбирается в балансировке nginx отлично админит линукс, знает csync2 и ansible отлично разбирается в apache-nginx конфигурации.

На очень пристойном уровне умеет читать bash скрипты и т. д.

Скорее всего он просто с горем попала подняв кластер увидит производительность этого мероприятия и бросит все на этом! Поскольку документации вообще никакой нет и где ему рыть не совсем понятно.

По мне так это полный провал самой идеи!

Для тех, кто не понял ошибочности конфигурации серверов, я опишу более детально.

И так, допустим у нас расстояние между серверами 40ms поскольку мы используем разные дата центры.

Следовательно, запрос у нас идет вначале на сервер 1, потом на 2, потом на 1, притом последние запросы sql, и каждый из них будет добавлять 40ms. Причина по которой кластер при первом старте так выглядит мне не известна, но не хотелось бы верить в то, что попросту в nginx балансере человеку писавшему скрипт обломило дописать 1 строчку кода.

Фактически добавлена вторая машина идет как последняя объявленая, а следовательно все запросы по умолчанию (ибо не было указано никаких приоритетов) будут идти на нее.

Просто поменяв машины местами в 

/etc/nginx/bx/site_available/upstream.conf

и перезапустив nginx,

мы можем получить изначальную схему работы сервера, с дополнением в виде отказоустойчивости, но надо понимать что второй сервер по прежнему будет в dbcon.php иметь директиву host: server1.ru, а следовательно при падении бд на нем все равно будет не жизнеспособен.

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

Да для полной правильности я бы добавил правило переключения между серверами поскольку его фактически нет, указав полный даун тайм мастер сервера в течение 30 секунд.

В такой конфигурации на мой взгляд я бы и продавал кластер.

Да функция второго сервера выглядет при такой настройке просто дублирующим устройством. При том при явном падении первого! И все что я могу сделать это при полном падении первого (кроме балансера) получать динамику и статику со второй ноды, но собственно это и нужно мелкому бизнесу!

Ведь бизнес модель «кластер из коробки» и подразумевает мелкий и средний бизнес hh.ru и без всяких… себе поднимет кластер. А следовательно, мелкому сегменту он нужен только в двух случаях.

  1. Сайт максимальное время доступен, имеет инкрементную копию, пусть даже с переназначением слейв базы в мастер после восстановления мастер нод.
  2. Указать более детально причину получения данных с слейв ноды, но ее в админке нигде нет, по сему "сервер из коробки» должен уж если не давать настроить эти параметры при старте, то как минимум не проседать по производительности.

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

Единственное, что я хотел бы еще добавить так это как бы я действительно хотело видеть это решение:

  1. Естественно, битрикс кластер запускается исключительно с битрикс машиной, это промо ход и он удачен.
  2. Отладить все баги, а их море поскольку нет выбора способа конфигурации создать 1 единственную мастер +слейв и балансер забрать в облако битрикс. В таком случаи кластер был бы действительно отказоустойчивым и при выходе из строя полностью машины мастер ноды мог все еще продолжать работать. Да и очень важным плюсом стало бы невозможность съехать с битрикса в дальнейшем, поскольку балансер кому-то нужно держать.
  3. Также решилась бы проблема с проверкой битрикс сайта на лицензию кластера, существующая проверка настолько легко ломается что я попросту не могу ее привести в статье, будучи золотым партнером битрикс.
  4. Самое важное кластер должен быть подъемен обычным юзерам, отладить 1 единственную схему с четким действием намного легче чем хвататься за все подряд.
  5. Никто не запрещает заставить пользователя давать одинаковые мастер слейв ноды, домены 3 уровня от основного сайта и т. д., четкая последовательность действий хоть и не подойдет всем, но даст «готовое решение», а не то, что есть сейчас. Пусть оно будет не всем подходить, но будет работать!

ИТОГ с точки зрения linux администратора:

Битрикс виртуальная машина сильно скакнула по производительности на 1 сайт, сделали очень много полезного, добавили наконец возможность удалить ноду (в прошлой версии даже этого не было). Вообще тенденция есть хорошая, но если говорить о сырости, то продукт с точки зрения хостинга для нескольких сайтов вполне себе рабочий, не считая убогой идеи класть сайт в папку default. За которую я бы просто оборвал бы руки.

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

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

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

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

ИТОГ с точки зрения программиста php:

Тут все просто битрикс кластер трогает программиста только 1 строчкой возвращая с ядра ответ true проверяя наличие модуля кластер. Если же говорить с точки зрения применения, то обычный программист не может применить решение «1с-битрикс веб кластер».

ИТОГ с точки зрения менеджера

Тут все просто, решения 1С-битрикс кластер не существует!

Можно вдаваться в дальнейшую полемику, но факт остается фактом, существующее решение «продать» нельзя!

P.S отдельное спасибо коллегам с vps-server.ru которые предоставили мне на общественных началах vps серверы для первоначальных тестов, да в конечном итоге я уже работал на didicate серверах, но в любом случае они мне хорошо помогли, сэкономив кучу времени.

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

klondike-studio.ru

Установка 1С-Битрикс веб кластер. Часть 1 / likes / блог студии Клондайк!

Идея написать статью появилась в связи с тем, что материалов по этой теме фактически нет, да и существующие описывают чуть ли не версию виртуальной машины 1.6 Главным же фактором стало то, что нужно многое учесть для более или менее нормальной работы кластера. В формат статьи не сможет войти вся исчерпывающая информация по 1С-Битрикс кластеру, да и была бы она весьма массивна и трудноусваиваемая. А вот основные кейсы по битрикс машине я все-же постараюсь взять.

Задача:

Поднять отказоустойчивый кластер на основе Битрикс «Веб-кластер» с распределенными серверами по разным датацентрам. Завести несколько сайтов.

Сервер 1 Россия:
Сервер 2 Германия:
Используемые материалы:
  1. http://www.1c-bitrix.ru/products/cms/features/webcluster.php
  2. http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=41&CHAPTER_ID=04750&LESSON_PATH=3911.4750
  3. http://habrahabr.ru/post/120702/
  4. Собственные глаза

УСТАНОВКА:

В последующих пунктах особо важна последовательность, будьте внимательны!

Заказав два Dedicated Serve c двумя предустановленными дистрибутивами Linux Centos 6.6 final mini (которые все-же немного отличались).

1. Создаем домены для нодов.

Ноды кластера будут общаться через DNS имена, для них мы заводим два домена 3 уровня и прописываем соответствующие А записи каждому домену.

server1.test.ru A 1.1.1.1 server2.test.ru A 2.2.2.2
2. Hostname

Прописываем их в hostname до установки битрикс виртуальной машины, поскльку смена имени хоста в админке «1С-Битрикс виртуальной машины» не ведет к перегенерации всего мастер-нод, также в ней нет функции удаления мастер ноды. В противном случае вам придется править все конфиги и генерить все ключи заново ручками.

Вписываем на каждом сервере его доменное имя.

sudo vi /etc/sysconfig/network /etc/init.d/network restart
Проверяем:
hostname

Она должна выдавать ваш домен на каждом сервере естественно свой.

На всякий случай указываю сразу все DNS имена в hosts файле.

vi /etc/hosts
Вписываем
1.1.1.1 server1.test.ru 2.2.2.2 server2.test.ru

Данную запись дублирую на втором сервере, она потом сама бы добавилась при создание slave-node, но если честно, переустанавливая машину уже в 5 раз, желания проверять, что именно работало не так, уже не было, так что исключаю любую возможность, да и проблемы с недоступностью доменов у меня по дороге все-же встречались, хотя скорее всего по моей вине.

Обратите внимание, что при создание master-node Вы не сможете откатить изменения, и при неправильно введенном имени, вам придется переустанавливать машину.

Обновление ОС

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

Конечно все это можно пропустить и работать будет и так, но учитывая патологическое желание 1С-Битрикс виртуальной машины повесить кластер на любом доступном месте, стараюсь избегать разницы в версионности пакетов. Будем считать что я параноик.

yum update

Кстати, разница была в 200 мегабайт. (скриншот сделан на vps любезно предоставленных компанией vps-server.ru, на реальных машинах разница была)

Теперь у меня есть две чистые идентичные машины в разных датацентрах.

Но это еще не все.

3. Установка 1С-Битрикс окружения 5.2.1

Официальный вариант установки сразу пришлось немного кастомизировать.

Как я и писал в свое время в службу поддержки, такая команда сработает отнюдь не везде, так и в моем случае один из серверов попросту не имел wget.

yum install wget

Далее стандартно

wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh   chmod 777 bitrix-env.sh ./bitrix-env.sh           

Обновлять саму виртуальную машину не имеет смысла, она обновляется при установке, до последней версии.

4. Порты

Также на одной из машин были закрыты все порты, по сему рекомендую сразу открывать их.

Да, в конфигах которые я встречал далее везде есть проверка, но учитывая качество сборки битрикс виртуально машины я бы не полагался на них. Так что открываем порты принудительно на всех машинах вне зависимости от того открыты они или нет.

iptables -I INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT iptables -I INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT iptables -I INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT iptables -I INPUT -p tcp --dport 5222 -m state --state NEW -j ACCEPT iptables -I INPUT -p tcp --dport 5223 -m state --state NEW -j ACCEPT iptables -I INPUT -p tcp --dport 8090 -m state --state NEW -j ACCEPT iptables -I INPUT -p tcp --dport 8891 -m state --state NEW -j ACCEPT

Сохраняем и перезапускаем.

service iptables save /etc/init.d/iptables restart

Проверить можно просто

telnet host port
5. Дополнительное ПО

Для моего проекта потребуется еще curl, так что я дооустанавливаю его на обоих машинах.

cp /etc/php.d/curl.ini.disabled /etc/php.d/curl.ini /etc/init.d/httpd restart php -m | grep curl

Также устанавливаю программное обеспечение, которым обычно пользуюсь.

yum install htop iotop atop mc w3m multitail vim mytop
6.Перезагрузка:

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

shutdown -r now  

Дожидаюсь перезагрузки и убеждаюсь лишний раз, что пока все идет как по маслу.

Теперь консоль встречает нас приветствием 1С-Битрикс машины и требует ввести пароль Bitrix пользователя.

От данного юезра и группы bitrix:bitrix будут работать все сайты на сервере, также его удобно давать контент-менеджерам в замен ftp, поскольку сайт расположен внутри /home у контент-менеджеров не будет возможности убить ОС. Фактически пароль к этому юзеру можно всегда скинуть, НО нельзя оставлять пустым или легким! Также не забывайте о безопасности. Злоумышленник, получивший доступ к одному из сайтов, получает автоматически доступ к остальным!

Также не совсем понятна логика, ведь если говорить о валидности разделения прав, то проще это сделать на FastCGI, и в этом случае есть пара приятных плюшек. Если же говорить о реальной серьезности работы, то лучше использовать PHP-FPM, но уж никак не стандартный apache-php. В любом случае имеем что имеем.

7. Создаем ноды

В консоли:

1. Manage Hosts in the pool 1. Add new host in the pool Enter IP address or DNS name for new server: 1.1.1.1

Теперь у нас есть master-nod (на нем будет расположен балансировщик его мы не можем передвинуть)

Добавляем второй сервер

1. Manage Hosts in the pool 1. Add new host in the pool Enter IP address or DNS name for new server: 2.2.2.2 8. Manage web nodes in the pool
8. Создаем сайты

Сейчас мы создаем сайт.

НЕ ИСПОЛЬЗУЙТЕ default — /home/bitrix/www, использовать данный домен можно ТОЛЬКО в ДЕМО режиме, поскольку у него очень большие проблемы с мусорными запросами фактически в default валятся все неразобранные запросы, включая все зеркала и т. д., реальный сайт ставить в него крайне не рекомендуется! Или же очень осторожно прописать в.htacces все виды редиректов и даже в этом случае, я бы не рекомендовал вам ставить сайт в это место. Фактически оно создано для простоты установки, но никак не для безопасности и не для seo. ВСЕ сайты должны располагаться в папке ext_www

Все делаем с консоли.

6. Manage sites in the pool 1.Create site Enter site name (ex. example.org) or 0 for exit: site1.ru Enter site type (link|kernel|ext_kernel): kernel Enter site encoding (UTF-8|windows-1251): UTF-8 Do you want to specify them? (N|y) N Press ENTER for exit: Enter 0. Previous screen or exit

И так, у нас сейчас появились папки для сайтов и все конфиги необходимые для работы сервера.

Установить сайт каждый в свою директорию достаточно просто, все что для этого нужно — прописать в host файле у себя на компьютере соответствующий домен и его IP, не забудьте указать зеркало с www во избежания проблем на сайте.

По умолчанию установщик не будет спрашивать паролей к БД поскольку они прописаны в dbcon.php, находящегося в каждой папке каждого сайта, при генерации!

Если же у вас все же возникли вопросы, то есть два варианта:

  1. Посмотрите в dbcon в папке /var/www/ext_site.ru/bitrix/… и т. д.
  2. Создайте свой, используя пароль root для генерации учетной записи. User: root Pass: ПУСТО

Для простоты я развернул демо сайты. На всех доменах.

3. при создании бд для сайта через консольную админку и указать кастом, но в этом случае вы попадете на две вещи </ br> а) этот кастом будет с префиксом db, а имя бд юзера и самой бд будет отличаться от введенных вами, смотрите внимательно конечный вывод. Так же при введение бд типа site_1 site_2 возможны коллизии поскольку бд будет называться dbsite. В общем это самый не рекомендованный способ создания бд.</ br> Учтите, что заявления 1c-Битрикс «теперь любая редакция будет иметь разрешения на 2 машины в кластере» — наглое вранье, ничего не поменялось. Кластер доступен только в старшей редакции, подробней на сайте битрикс.

9. Добавляем роли

Добавляем роль apache

1. Manage Hosts in the pool 1. Add new host in the pool 0. Previous screen or exit

Добавляем роль mysql

3. Configure MySQL servers 2. Create slave MySQL server 0. Previous screen or exit

Каждое действие занимает некоторое время. Во время создания роли apache так же копируется весь контент на новый сервер, отследить что сейчас происходит достаточно легко:

iotop -oka

Также можно делать через веб панель. На сайте будет более графически отображаться, но толку не добавит особо, ошибки всеравно появляются, и каждый раз разные.

Как синхронизация прошла, у нас есть готовый кластер и мы, потирая руки, думаем что все уже хорошо, мало того, положив пару файлов на одном сервере, вы увидите что они в течение 5 минут появляются на новом. Все вроде бы хорошо и мы переходим к тестированию производительности. И тут-то начинается самое веселое.

Заходя в панель производительности, вы запускаете тест и получаете свои 0.5 попугайчика и 50 запросов в бд в секунду против только что доступных 80 и 34000 соответственно. Что мягко говоря озадачивает, сайт еле ползает.

klondike-studio.ru

Сколько стоит сделать кластер серверов для сайта с высокой нагрузкой на 1С-Битрикс

Все крупные интернет-проекты, социальные сети, федеральные интернет-магазины, SAAS-сервисы работают на нескольких серверах. Чем больше посещаемость, тем больше серверов. Давайте разберемся почему почему так происходит и как научить сайт на Битриксе работать на нескольких серверах.

В каких случаях 1 сервера становится мало?

Дополнительный сервер нужен, если:

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

    1. Нагрузка большая, ничего не помогает ( код оптимизировали, базу настроили, память и процессор — лучшее из возможного).

    2. Сайт должен открываться быстро для пользователей из разных стран

  2. Резервный сервер с проектом, на случай аварии на основном.

Если сайт на Битриксе не справляется с нагрузкой

Вы создали интернет-магазин на 1С-Битрикс. Сайт работает, приносит деньги, но — тормозит.

Вы вложили приличную сумму в разработку, рекламу и поисковое продвижение. Ваш интернет-магазин не справляется с нагрузкой, продажи падают.

Что делать? Правильный алгоритм:

  1. выполняем оптимизацию,

  2. увеличиваем ресурсы сервера,

  3. добавляем ещё серверы и строим из них кластер.

Оптимизация интернет-магазина

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

Процесс похож на постройку гоночного автомобиля. Выкидываем всё лишнее, оставляем необходимый минимум. Автомобиль должен стать легким.

Процесс оптимизации подробно описан в статье: подготовка интернет-магазина к высоким нагрузкам . Когда оптимизировать уже нечего, можно переходить к серверу.

Изменения на сервере. Масштабирование интернет-магазина

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

Масштабирование бывает 2-х видов: вертикальное и горизонтальное. Вертикальное масштабирование это увеличение ресурсов на одном сервере ( замена процессора, добавление оперативной памяти и т. д. ). Горизонтальное масштабирование это увеличение количества серверов.

Увеличение ресурсов сервера ( вертикальное масштабирование интернет-магазина)

Перед тем как что-то увеличивать, нужно понять чего нам не хватает. Для этого мы проводим нагрузочное тестирования и смотрим, что закончится раньше: процессор, память, сеть или диски.

Нагрузочные тестирование показывает, что интернет-магазин с 60 000 SKU на одном VDS сервере способен выдерживать нагрузку 300 RPS ( это 300 запросов в секунду). Это запросы, которые NGINX отправляет в APACHE, т.е. запросы к страницам сайта, а не JS/CSS и картинкам.

Если конвертировать RPS в пользователей, сайт будет работать при посещаемости 100 000 пользователей в сутки.

Добавление серверов ( горизонтальное масштабирование сайта на 1С-Битрикс)

Существуют разные способы горизонтального масштабирования. Большинство из них подробно описаны в интернете. Однако, не все совместимы с проектами на 1С-Битрикс. Кроме этого, не каждая редакция 1С-Битрикс позволяет это сделать. Например, для интернет-магазинов нужна редакция « Бизнес», т.к. в ней есть модуль « Веб-кластер».

Процедура настройки кластера из 2 серверов выглядит так:

  1. Покупаем 2 одинаковых выделенных сервера

  2. Устанавливаем на все серверы специальный софт « Битрикс Веб-окружение »

  3. Один из серверов выбираем основным, он будет называться MASTER

  4. Второй сервер будет ему подчиняться и называется SLAVE

  5. На MASTER-сервере разворачивается резервная копия сайта

  6. Битрикс веб-окружение позволяет распространить файлы и базу данных сайта на SLAVE-сервер

  7. На MASTER и SLAVE серверах настраиваем общую систему кеширования

  8. Тестируем работу сайта

На все эти процедуры уходит 16−24 часа работ.

Как работает кластер из нескольких серверов?

Важно понимать в каких отношениях находятся серверы. SLAVE полностью дублирует MASTER. Если на MASTER загружаются или удаляют файлы, эти изменения очень быстро попадают на SLAVE.

Теперь все запросы пользователей будут обслуживаться двумя серверами. Все запросы будут поступать в MASTER-сервер, который будет делегировать часть операций SLAVE-серверу.

К сожалению, Битрикс устроен так, что он не может полностью отдавать запросы SLAVE-серверу, не нагружая MASTER. Однако, даже частичное делегирование, повышает максимальное количество пользователей, которое способен обслужить ваш сайт.

Как меняется стоимость сопровождения проекта?

На стоимости и скорости разработки это никак не сказывается. Дорожает только хостинг и услуги администрирования.

Мы перевели на такую конфигурацию интернет-магазин нашего клиента 704ka.ru. После перехода, взяли на себя администрирование и мониторинг обоих серверов. Аварий нет — полет нормальный.

Запасной сервер

SLAVE-сервер может играть роль запасного или резервирующего. Поскольку на нем всегда актуальная база данных и файлы, он может заменять MASTER в случае аварии.

Предположим, в один из дата-центров бьёт молния , как это было в 2011 году с 1С-Битрикс, или начинается DDOS атака. В этот момент, ваш MASTER теряет связь с внешним миром и сайт выключается. Нам нужно 30 минут, чтобы перевести SLAVE в режим MASTER и возобновить работу вашего сайта.

Согласен, молния это экзотика. Однако, ddos атака на один из дата-центров вполне реальна.

Заключение

Как вы поняли, не бывает 100% надёжных систем. Однако, если взять ситуацию в свои руки и привлечь правильных специалистов, количеством аварий и масштабом их последствий можно будет управлять.

Порядок действий, для тех кто уже столкнулся с проблемой производительности:

  1. Провести аудит и найти источники проблем в проекте

  2. Убрать лишний и медленный код, ускорить работу базы данных

  3. Сделать апгрейд сервера

  4. Увеличить количество серверов

Если хотите привлечь нас к этому процессу — заполните форму заявки или оставьте в комментарии ваши контакты.

Оцените статью:

Спасибо, ваш голос успешно добавлен!

www.intervolga.ru

Веб-кластер своими руками – Григорий Добряков

Сегодня Битрикс презентовал своё новое решение – “веб-кластер”. Для тех кто не в курсе – поясню, что эта штука позволяет разместить высокопосещаемый проект не на одном, а на нескольких серверах, и в любой момент добавлять новые сервера для ускорения работы сайта. А так же безопасно изымать любой сервер для ремонта, апгрейда, или в случае его выхода из строя. Разумеется, мне как их первому конкуренту (в лице компании Юмисофт) в первую очередь было нужно узнать, что же они принципиально нового предлагают рынку.

А ничего. В хорошем смысле ничего. Битрикс перестал валять дурака и “изобретать велосипед” – видимо попался таки в команду умный технолог, поэтому вместо “велосипедов” они взяли и сделали всё так как принято делать у нормальных людей. В этом посте я расскажу простыми словами – что конкретно они сделали и как вам повторить то же самое в своём проекте.

Рассмотрим основные части кластера:

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 и работаете.

Коллеги, поделитесь вашим опытом настройки кластеров! Самый интересный рассказ будет опубликован в следующем посте.

www.dobryakov.com

1С-Битрикс: Веб-кластер

Модуль Веб-кластер - это комбинация технологических решений, которые позволяют распределить один сайт на несколько серверов, решая тем самым несколько задач: обеспечение высокой доступности сайта; его масштабирование в условиях возрастающей нагрузки; балансирование нагрузки, трафика, данных между несколькими серверами. Постройте свой Веб-кластер - повысьте производительность, масштабируемость и надежность вашего проекта!
Любой новый или работающий проект на «1С-Битрикс: Управление сайтом» может быть представлен как веб-кластер взаимозаменяемых серверов.

Основные задачи, которые позволяет решить подобная конфигурация проекта:

  1. При увеличении посещаемости можно быстро добавить в кластер новые сервера.
  2. В случае выхода из строя одного из серверов кластера система продолжает беспрерывно обслуживать Клиентов.
  3. Балансирование нагрузки, трафика, данных между несколькими серверами.
  4. Система позволяет снимать резервные копии со специально выделенных узлов кластера, не влияя на работу сайта.
«Географический веб-кластер»

«Географический веб-кластер» повышает отказоустойчивость проекта и обеспечивает независимость от дата-центра. В различных дата-центрах объединяются несколько групп веб-кластеров, находящихся в разных городах или странах. В случае отказа одного дата-центра, в работу мгновенно включается другой, без необходимости восстановления «бэкапа».

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

«1С-Битрикс: Веб-кластер» - это комбинация технологий:

  1. Вертикальный шардинг (вынесение модулей на отдельные серверы MySQL)
  2. Репликация MySQL и балансирование нагрузки между серверами
  3. Распределенный кеш данных (memcached)
  4. Непрерывность сессий между веб-серверами (хранение сессий в базе данных)
  5. Кластеризация веб-сервера:
  • Независимость от дата-центра (в случае отказа одного дата-центра, в работу мгновенно включается другой, без необходимости восстановления «бэкапа»)

    • Как работает

    1. Вертикальный шардинг

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

    В отдельные базы можно вынести следующие модули продукта:

    2. Репликация MySQL и балансирование нагрузки между серверами

    Схема «master - slave» реализуется средствами MySQL.

    Платформа «1С-Битрикс: Управление сайтом» позволяет гибко балансировать нагрузку между серверами, участвующими в репликации.

    Ключевые особенности:  

    3. Распределенный кеш данных (memcached)

    «1С-Битрикс: Веб-кластер» позволяет использовать пул серверов memcached для работы с кешем данных. Это обеспечивает:

    4. Непрерывность сессий между веб-серверами (хранение сессий в базе данных)

    Возможность хранения данных пользовательских сессий в базе данных обеспечивает «прозрачность» сессии для всех веб-серверов кластера:
    1. После авторизации на одном из серверов пользователь должен считаться авторизованных и для всех других серверов.
    2. И наоборот - окончание сессии на любом сервере должно означать ее окончание на всех серверах сразу.

    5. Кластеризация веб-сервера

    При разделении проекта на несколько веб-серверов необходимо решить две задачи:

    blog.orangecode.ru

    Prostoy-Site | Все права защищены © 2018 | Карта сайта