Меню Рубрики

Установка bitrix env на centos

Битрикс24 установка на CentOS

Установим коробочную версию Битрикс24 на операционую система CentOS 7 используя скрипт от разработчика. Выполним все первоночальные настройки которые дадут возможность произвести полноценое тестирование продукта. CRM система удобна и весьма попалярна среди бизнеса.

Введение

В этой статье вы узнаете как установить коробочную версию Битрикс24 на систему CentOS 7. Варианты установки могут быть разные, но мне больше нравится именно такой способ о котором и поведаю.

Устанавливать будем тестовую версию на 30 дней и в последствии преобретём лицензию.

Сколько стоит и какие варианты коробочной версии можно посмотреть по ссылке https://www.bitrix24.ru/prices/self-hosted.php

Установка Битрикс24 производится в 2 этапа:

  1. Запустить скрипт bitrix-env.sh который подготовит веб-окружение на предварительно подготовленной системы CentOS 7 установив все необходимое;
  2. Открыть в браузере http://адрес сервера и произвести непосредственую установку указав все необходимые данные.

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

Предварительная подготовка

Скрипт автоматической подготовки веб-окружения расчитан на 7-ую версию CentOS.

Более подробно о том как установить и сделать первоночальные настройки можно из статьи «CentOS 7 установка и настройка«.

Настоятельно рекомендую ставить минимальную версию.

Вот список моих действий после установки минимальной версии CentOS 7:

  1. Подключаю SWAP файлом;
  2. Отключаю SELinux;
  3. Открываю в Брандмауэр FirewallD порты для http и ssh (можно не настраивать ниже поймете почему);
  4. Настраиваю отображение приглашения в консоли bash и хранения истории bash;
  5. Устанавливаю wget, mc, vim, tmux.

Этих действий вполне достаточно для дальнейшей установки Битрикс24.

Установка веб-окружения

Даем права скрипту на выполнение и запускаем его:

Скрипт должен быть запущен от пользователя root.

Мы увидим приветствие, в котором говорится, что на все вопросы по умолчанию будет ответ «Да» (Yes) и при необходимости ответить «Нет» нужно ввести n.

Если на сервере работает SELinux, первый вопрос — согласны ли мы его отключить. Отвечаем утвердительно, нажав Enter:

Скрипт вернет ответ, что SELinux выключен и потребует перезагрузки сервера:

В нашем случае мы уже отключили SELinux ранее и мы просто не увидим это сообщение. Если мы не отключали его рание надо перезагрузить сервер и запустить скрипт снова.

В конце установки при успешной установке увидем следующее:

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

Смотрим что сделал скрипт

В выводе конечно многое показывало, но проверим что произошло по факту.

Скрипт удалит FirewallD и настроил iptables.

Посмотрим какие используються правила iptables можно выполнив необходимую команду:

Параметры настройки находятся в файле /etc/sysconfig/iptables.

Были устанолены основные пакеты для работы веб сервера:

  • PHP7.2 из репозитория Remi’s PHP 7.2 RPM repository for Enterprise Linux 7;
  • Nginx 1.16.1;
  • Apache 2.4.6.
  • MySQL 5.7.28-31.

Основные настройки находятся в следующих местах:

  • Файлы лежат по пути /home/bitrix/www/;
  • Настройки Nginx находяться по пути /etc/nginx/bx;
  • Настройки Apache находяться по пути /etc/httpd/bx.

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

Установка Битрикс24

Если ресур работает напрямую без использования проксирования переходите к следующуму разделу статьи.

Работа сайта через Nginx proxy

По умолчанию считается что сервер имеет свой белый IP и это понятно. Часто коробочную версию Битрикс24 устанавливают в своей локальной сети где имеется один белый ip на котором работают разные ресурсы по протаколам http или https.

Для решения задачи размещения на одном IP адресе разных ресурсов работающих по протаколу http(s) давно и успешно используется Nginx работающий в режиме прокси сервера.

На практике удобно настроить на Nginx получение сертификатов SSL и дальше проксировать сигнал до нужного сервера по протоколу http.

Узнать более подробно как делается подобное проксирование можно из статьи «Nginx установка и настройка«.

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

Где выделеные части имеют следующий смысл:

  • crm.sevo44.ru — поддомен на катором будет работать Битрикс24;
  • http://192.168.0.44:80 — адрес на котором будет установлен Битрикс24;
  • client_max_body_size 10m — параметр который позволит передавать на ресурс файлы больше 10 Мбайт.

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

Непосредственая установка Битрикс24

Открываем браузер и переходим по ссылке http://IP-адрес сервера.

Увидим окно привествия и на каждом этипе вносим всю необходимую информацию.

Процедура не сложная и описывать её не вижу смысла. Гораздо интересней дальнейшая настройка без которой не возможно начать полноценое тестирование работы ресурса.

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

После установки произведем проверки которые покажут нам все проблеммы из за которых работа ресурса просто не возможна на первоночатьном этапе.

Тестирование конфигурации

Первое что надо сделать это произвести «Тестирование конфигурации». Находится это по пути: Панель управления (меню пользователя) -> Настройки (слева внизу) -> Инструменты -> Проверка системы -> Тестирование конфигурации.

В нашем случае было несколько ошибок и не одном из них покажу общий принцип решения проблеммы.

Расмотрим на ошибке не позволяющей загрузки файла больше 4 Мб:

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

Из описания вроде всё понятно что делать и где смотреть, но везде вы увидите что параметр стоит верный:

В начале статьи я говорил что ресурс работает через Nginx прокси и именно параметр в настройке client_max_body_size 10m; позволит нам не увидеть данную ошибку.

Не забывайте что ресурс работает через прокси.

В случае успеха вы должны увидеть:

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

Настройка работы почты

Настройка почты сильно меня не удивила, но заставила немного повозиться. Ровно одни сутки (1С) 🙂

Вот что будет показывать в выводе при тестировании конфигурации:

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

Для себя я решил так, если разработчики не стали использовать стандартный FirewallD который идет по умолчанию в CentOS 7 (не думаю что отказ от использования был реально необходим с технической точки зрения) а стали использовать iptable, то и я могу с легкостью отказатся от их механизма отправки почты и настроить надежный и стабильный Postfix.

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

Мой пример рабочий на все 100% и успешно работает на нескольких серверах.

Читайте также:  Установка лицензии на ips

Более подробно о настройке можно почитать в статье «CentOS 7 установка и настройка SMTP«.

Настройка и проверка Postfix

Если Postfix не установлен то производим установку выполнив команду:

Запускаем и добавляем в автозагрузку командами:

Чтобы отправлять письма с консоли необходимо установить пакет mailx:

После этого можно отправлять с консоли сервера сообщения на свою почту:

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

Для начала надо в настройках /etc/php.d/bitrixenv.ini поменяь значение:

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

В выводе отправляемого письма вы увидите:

В даннном случае письма сразу попадают в спам.

Теперь настроим отправку почты через стороний SMTP сервер.

Настроить через mail.ru не выйдет, так как будет ругатся что поле from не совпадает.

(host smtp.mail.ru[94.100.180.160] said: 550 Message was not accepted – it contains invalid headers. More specially, ‘From:’ header must match user you are sending mail from.

Будем настраивать используя Yandex, так как при тестовых отправках с почтового ящика mail, yandex.ru и gmail письма пиьсма благополучно уходят и проходят успешную проверку у получателя.

Настройка через SMTP Yandex

В примере будет использована почта noreply@sevo44.ru которая обслуживается Yandex.

Переименуем дефолтный конфиг Postfix. После этого, создадим рабочий и добавим необходимые настройки:

Создаем файл с информацией об имени пользователя и пароле для авторизации на сервере SMTP:

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

Выделеные параметры смотрим исходя из вывода команды: tail -n 10 /var/log/maillog в которой вы увидите информацию об отправленом сообщении.

При получении ошибки при проверке: «warning: SASL authentication failure: No worthy mechs found»

Необходимо установить еще несколько пакетов для работы SASL.

Установим необходимые пакеты:

Перезапустим Postfix и проверим работу:

Отправляем тестовое письмо через консоль:

В заключение, осталось добавить к стандартному алиасу для root в /etc/aliases, внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку:

Обновляем базу сертификатов:

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

При подключении к консоли сервера вы увидете сообщение:

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

Вводим 0 нажимаем Ентер и проболжаем работать дальше с имеющейся системой.

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Понравилась статья? Поделитесь ей с друзьями!

Похожие по теме записи

Пожалуйста, оставляйте свои комментарии

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

источник

Установка CRM Битрикс24 на Linux CentOS

Есть несколько способов установить CRM Битрикс24 — развернуть готовую виртуальную машину BitrixVM или установить коробку с помощью готового веб окружения. В данной инструкции мы будем использовать второй метод.

Установка веб-окружения

Битрикс24 является веб приложением и для своей работы требует установленного и настроенного веб-сервера. Для этого у 1С есть готовый скрипт — нам просто нужно его загрузить и запустить.

* первая команда установит утилиту wget, если ее нет.

Даем права скрипту на выполнение:

Мы увидим приветствие, в котором говорится, что на все вопросы по умолчанию будет ответ «Да» (Yes) и при необходимости ответить «Нет» нужно ввести n. Также скрипт должен быть запущен от пользователя root:

====================================================================
Bitrix Environment for Linux installation script.
Yes will be assumed as a default answer.
Enter ‘n’ or ‘no’ for a ‘No’. Anything else will be considered a ‘Yes’.
This script MUST be run as root, or it will fail.
====================================================================

. и следом, если на сервере работает SELinux, первый вопрос — согласны ли мы его отключить. Отвечаем утвердительно, нажав Enter:

You have to disable SElinux before installing Bitrix Environment.
Do you want to disable SELinux?(Y|n)

Скрипт вернет ответ, что SELinux выключен и потребует перезагрузки сервера:

SELinux status changed to disabled in the config file /etc/selinux/config.
SELinux status changed to disabled in the config file /etc/sysconfig/selinux.
Please reboot the system! (cmd: reboot)

. перезагружаем (если отключали SELinux):

После перезагрузки снова запускаем скрипт:

* перед этим необходимо перейти в каталог, куда мы его скачивали.

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

В конце мы должны увидеть следующее:

Bitrix Environment bitrix-env has been installed successfully.

Смотрим пароль для подключения к базе mysql:

Мы увидим что-то на подобие:

L8F7 — пароль для подключения к базе данных.

Установка Битрикс24

Открываем браузер и переходим по ссылке http:// — откроется окно приветствия. Меняем язык на русский и кликаем по кнопке Установить:

В открывшемся окне выбираем дистрибутив 1С-Битрикс24 и демонстрационную версию (если у нас есть ключ, то можно выбрать коммерческую лицензию и ввести его), после нажимаем по кнопке Загрузить:

. начнется процесс загрузки дистрибутива. После его окончания откроется мастер установки — на первой странице принимаем лицензионное соглашение и нажимаем Далее:

На странице «Регистрация продукта» можно снять галочку для заполнения формы регистрации:

Начнется процесс установки Битрикс24. Ждем — откроется окно создания учетной записи администратора. Заполняем веб-формы и кликаем Далее.

Откроется страница настройки портала. Кликаем Далее до пункта «Настройка Битрикс24» — отмечаем нужные нам галочки и кликаем Установить:

Читайте также:  Установка предпускового подогревателя аллион

Откроется последняя страница — нажимаем по Перейти в Битрикс24. Установка завершена.

источник

“Битрикс: Веб-окружение” – установка и настройка

В начале этого года Битрикс выпустили новую, седьмую, версию своего “Веб-окружения”. Самое главное – теперь официально поддерживается установка на CentOS 7 и php 7. Небольшое пояснение, если вы не в курсе. «1С-Битрикс: Веб-окружение» – это готовая среда с предустановленным рекомендуемым набором программного обеспечения, необходимого для корректной работы CMS 1С-Битрикс. Поставляется как в большом многообразии – есть готовые образа для различной виртуализации (подробнее см. на официальном сайте) и установочный скрипт для установки на сервер. Вот работу с последним мы и рассмотрим.

Что получим

Веб-окружение позиционируется, как лучшее решение для всей линейки продуктов Битрикс – как для всех редакций “1С-Битрикс: Управление Сайтом” так и для коробки Битрикс24. Давайте посмотрим, что нам предлагают использовать в качестве рекомендуемой связки.
Сама схема традиционна: Apache+nginx. Для текущей 7.0.1 версии веб-окружения используются стабильные Apache 2.4 и nginx 1.10.2. Самое главное нововведение, переход на php 7. Про официальную поддержку nginx+php-fpm пока даже слухов нет, так что данный вариант по прежнему придется собирать руками.
Версия MySQL, а точнее форка MariaDB, по прежнему 5.5, в соответствии с официальными репозиториями CentOS. Хотя, если вы обновлялись до последних версий Битрикс, наверняка встречали предложение выполнить в консоли БД некий sql-запрос для модуля “Веб-мессенджер”, который можно провернуть только с версией 5.6. Про переход на 5.6, так же как нибудь расскажу.
Что еще входит в пакет:

  • memcached – сервис обеспечивающий кеширование данных в ОЗУ, при правильном использовании дает значительное ускорение работы. По умолчанию не используется;
  • stunnel – для организации шифрованных ssl-тунелей;
  • catdoc – библиотека для работы с форматами MS Office. В частности используется для поиска по документам;
  • xpdf – задачи те же что и пунктом выше, только для PDF;
  • munin и nagios – мониторинг состояния сервера. По умолчанию не используется;
  • sphinx – полнотекстовый поиск. На данный момент наилучшее решение по удобству, качеству и скорости поиска. По умолчанию не используется.

Само собой все это уже настроено на корректную работу друг с другом. Давайте ставить.

Установка «1С-Битрикс: Веб-окружение» на сервер

Качаем скрипт установки – актуальную ссылку на скачивание можно поглядеть на оф. сайте. Запускать надо root’ом и далее подразумевается, что мы находимся в /root . Если нет, перейдите выполнив:

источник

Переезд на кластер под управлением «1С-Битрикс: Веб-окружение»

Собственно, если мы обратимся на сайт вендора, то там увидим что:

«1С-Битрикс»: Веб-окружение» — Linux служит для быстрой и простой установки всего ПО, необходимого для работы продуктов и решений «1С-Битрикс» на Linux-платформах CentOS 6 (i386, x86_64) и CentOS 7 (x86_64). Устанавливать необходимо на «чистый» CentOS, без уже установленного веб-сервера.

В состав «1С-Битрикс: Веб-окружение» — Linux входят: mysql-server, httpd, php, nginx, nodejs push-server, memcached, stunnel, catdoc, xpdf, munin, nagios, sphinx.

По сути, данный комплекс ПО содержит в себе настроенный LAMP, консольную панель управления сервером, плюс дополнительные, необходимые для работы некоторых модулей 1C-Bitrix, пакеты. Весь софт настроен с учётом особенностей 1C-Bitrix, а именно:

  • установлены необходимые расширения (gd, zip, socket, mbstring)
  • включена поддержка short-тегов
  • заданы необходимые значения для параметров memory_limit, max_input_vars, safe mode, opcache.validate_timestamps, opcache.revalidate_freq, mbstring.func_overload, default_charset, display_errors и др.
  • установлен одинаковой часовой пояс для БД, php и на самом сервере
  • и др.

Это позволяет в большинстве случаев не заниматься настройкой сервера и его тюнингом.

Итак, у нас было 2 app сервера (назовём их app01 и app01), 2 db сервера (db01, db02), 1 сервер под кэширование (cache01, ну вы поняли), точнее была идея реализовать структуру кластера подобным образом. Под этот план были получены 5 серверов, с установленными на них последними версиями centos7 (к сожалению, debian, ubuntu, fedora, rhel и др. не подходят), кроме os на серверы больше ничего не устанавливалось.

Т.к. мы собираем кластер, то необходимо определить, какой из серверов будет основным. Из-за особенностей балансировки запросов к приложению, один из серверов, где будет работать httpd, будет также содержать nginx. Все входящие запросы будет принимать также он, и после этого перенаправлять запрос на одну из доступных web-нод. Мы выбрали основным сервер app01.

В дальнейшем работа пошла по следующему плану:

1. Установить bitrixenv

Установка не подразумевает сверхъестественных знаний linux или администрирования. Заходим на каждый сервер через ssh и выполняем такие команды:

Ставить bitrixenv необходимо на все серверы, которые планируется использовать в кластере. Даже если сервер будет работать только как инстанс memcached, bitrixenv необходим, т.к. позволяет управлять всем кластером из основного сервера.

2. Настроить bitrixenv

Т.к. использовать весь этот зоопарк мы будем как кластер, то производить настройку серверов можно через меню окружения на app01. Для этого заходим на сервер через ssh, и запускаем файл /root/menu.sh. При первом запуске необходимо задать пароль для пользователя bitrix (аналогичную операцию необходимо провести на всех серверах, где планируется запуск сайта):

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

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

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

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

Теперь нам необходимо добавить в созданный пул все доступные серверы. Для этого воспользуемся первым пунктом меню и увидим такие варианты:

Опять выбираем первый пункт меню, и указываем ip нового сервера, его имя в кластере (те самые app02, db01, db02, cache01) и root-пароль от подключаемого сервера. Таким образом, поочерёдно добавляем каждый имеющийся сервер. После того, как все серверы зарегистрированы в кластере, мы должны получить примерно такой список на главном экране окружения:

Настройку ролей серверов пока отложим на следующий шаг.

3. Перенос проекта

Т.к. наше приложение изначально работает на одном сервере, то модуль масштабирования и управления кластером отключены, база не реплицирована. Сам перенос ничего сверхъестественного из себя не представляет — упаковали папки bitrix и upload, сняли дамп БД.

Читайте также:  Установка профнастила на мягкую кровлю

После того, как архивы и дампы готовы, заходим на app01, и тянем через git код проекта в дефолтную папку сайта в bitrixenv — /home/bitrix/www, скачиваем wget-ом или curl-ом архивы и дамп БД, распаковываем архивы и заливаем дамп в БД на app01, переносим записи cron.

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

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

4. Включение кластерного режима работы

После того, как приложение было перенесено на app01, и мы проверили корректность его работы, пришла пора заняться самым интересным — масштабированием. Для начала необходимо установить модули scale и cluster в админ-панели 1C-Bitrix. Во время установки ничего особо делать не нужно, вся работа происходит далее.

Как только модули установлены, переходим в ssh-соединение с основным сервером, а это app01, и открываем меню bitrixenv (лежит тут /root/menu.sh). Прежде чем приступить к дальнейшей настройке, необходимо выяснить один важный момент — bitrixenv оперирует понятием “роль сервера”. Не имеет особого значения, как называется сервер в пуле, т.к. каждый сервер содержит весь софт, который входит в пакет bitrixenv, мы всегда можем назначить ему одну или несколько ролей, а можем снять их с него или поменять на другие. Основные роли это — mgmt (балансировщик, т.е. nginx), web (т.е. httpd/apache), mysql_master и mysql_slave (инстанс БД, slave появляется уже когда начинаем делать репликацию), memcached (сервер с memcached). Общая картина теперь понятна, и мы решили начать с memcached-сервера. Для этого заходим в пункт

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

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

Пришло время добавить второй app-сервер. Для этого переходим по пути

где нам необходимо указывать имя сервера и способ синхронизации между основной и новой web-нодой. Исходя из документации bitrixenv и предварительных испытаний, нашему проекту было достаточно выбрать первый вариант (за один шаг происходит и копирование проекта и настройка конфигов ноды). После того, как фоновые работы закончатся, мы должны увидеть в главном меню примерно такую картину:

Обратим внимание на то, что в колонке Roles напротив сервера app02 указана роль web.
Осталось разобраться с БД, её настройка занимает больше всего времени. Для начала вкратце объясню, как раздаются роли mysql в контексте bitrixenv. По-умолчанию на основном сервере кластера стоит master версия БД. В нашем случае необходимо было вынести БД на отдельный сервер и добавить ещё один сервер с slave-версией БД. В bitrixenv нельзя просто так взять и перенести master с одного сервера на другой)

  1. Даём роль mysql_slave серверу, на который мы планируем перенести БД
  2. На целевом сервере меняем роль mysql_slave на роль mysql_master (автоматом старый mysql_master переходит в режим mysql_slave)
  3. Удаляем роль mysql_slave на исходном сервере, бывшем master
  4. PROFIT.

Мы последовали этой логике таким образом:

Указали сервер, которому хотим дать роль mysql_slave — db01. Дожидаемся окончания фоновых работ и видим такой результат:

Отлично, теперь переходим в

Указываем app01 и ждём. В итоге должны увидеть примерно такой результат:

Медленно и неотвратимо мы подошли к установке последней роли — mysql_slave. Для этого необходимо повторить действия, которыми мы устанавливали такую роль для db01, но указать уже db02.

Наконец, все серверы подключены и настроены.

5. Тюнинг производительности

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

  • Прокачиваем работу с сессиями. Подробно описано здесь. Вкратце — переключаем хранение сессий в memcached.
  • Удаляем файлы /bitrix/php_interface/after_connect_d7.php и /bitrix/php_interface/after_connect.php, т.к. команды из них обрывают конвейер кластера (если не используется bitrixenv, то их лучше оставить).
  • Увеличиваем количество памяти, выделяемое memcached, и устанавливаем процент использования серверов с ролью memcached до 100%.
  • Отключаем модули php: apcu, ldap
  • Отключить модули БУС «Компрессия», и “Веб-аналитика” (по возможности).
  • Рассмотреть вариант использования локального кэша. Подробнее описано тут. В нашем случае прироста не было, но идея интересная. Решение имеет пару особенностей:

  • Количество инстансов memcached должно равняться количеству web-нод.
  • Для отдачи композитного кэша nginx-ом напрямую из локального memcached придётся поковырять конфиг nginx, из коробки не работает.

  • Перенести выполнение всех агентов на cron.
  • Выводы

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

    Плюсы bitrixenv

    Минусы bitrixenv

    • Балансировщик всегда вместе с основной web-нодой
      Т.к. у нас уже был свой балансировщик, мы столкнулись с тем, что невозможно отказаться от встроенного в bitrixenv балансировщика. Нельзя в т.ч. разместить его отдельно от основной web-ноды.
    • Много лишнего софта для некоторых ролей
      Т.к. каждый сервер в пулле содержит полную версию окружения, то получается что на db-нодах стоят httpd, memcached, sphinx, пусть они и не используются. Аналогично можно встретить MySQL на сервере, который занимается только кэшированием, но в этом случае MySQL можно остановить в меню окружения или админ.панели сайта.
    • Php работает в режиме apache2handler
      Нет возможности безболезненно включить php в работу в режиме fcgi, не говоря уже о режиме nginx+php-fpm. Так же не получится поменять версию php, без танцев с бубном.

    Источники:

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

    источник

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *