Переезд Битрикс24 из облака в коробку

1. Хостинг, где будет располагаться ваш собственный портал?

Самый фундаментальный, пожалуй, это хостинг. Здесь работает правило: чем стабильнее, тем лучше. Битрикс - не самая требовательная в плане производительности платформа. Доступность и возможность выдержать постоянно высокую нагрузку - гораздо важнее. Будете выбирать между дополнительными гигабайтами ОЗУ или вторым диском, выбирайте второй диск. Если это VPS, проверьте, есть ли возможность делать бэкапы из панели управления. На счёт использования своего сервера подумайте дважды. Возможно, экономия станет не столь очевидной, когда посчитаете сколько часов квалифицированного персонала уйдёт на поддержку и мониторинг каналов связи и оборудования. Ведь портал нужен 24 часа в сутки. В среднем, можно ориентироваться на 2 000 р./мес. для обеспечения работы до 20-30 пользователей. За эти деньги вы получите одно выскопроизводительное ядро серверного процессора Intel Xeon E5-2670 v3 2.3 ГГц, 2 ГБ DDR4, 35 ГБ диска с 640/320 IOPS чтение/запись, а также, возможность делать моментальные бэкапы автоматически, хоть каждый час. Если речь идёт о аренде выделенного сервера, то тут ставки уже выше - от 8 000 р./мес. Примерная конфигурация Intel Xeon E3-1230 3.4 ГГц, 32 ГБ DDR4, 2 × 2 ТБ SATA + 2 × 240 ГБ SSD. Конечно, во втором варианте вы получите в своё распоряжение значительно больше ресурсов и их стоимость за единицу будет ниже. Только чтобы воспользоваться всеми плюсами и не сгенерировать минусы, эксплуатировать данное решение нужно соответствующим образом - тут за вас никто не подумает, как оптимизировать производительность и свести к минимуму риски сбоя оборудования. Вот набор обязательных процедур:

отключение функций энергосбережения - к отключению все C-State, ACPI и прочие ECO - чудеса, снижающие производительность минимум в 1,5 раза. Вот список на примере платформы X11SSL-F:

· Boot Performance Mode - Turbo Performance

· CPU C-States - Disabled

· Enhanced C-States - Disabled

· C-State Auto Demotion - Disabled

· C-State Un-Demotion - Disabled

· C-State Pre-Wake - Disabled

· DMI Link ASPM Control - Disabled

· intel EIST - Disabled

· intel speedstep – Disabled

подбор решения для организации RAID-массива - вообще говоря, хорошо бы использовать ZFS, но CentOS, рекомендуемая ОС для Битрикс, пока не научилась поддерживать её нативно, так что выбор прост либо md-raid, либо аппаратное решение от Broadcom (бывший LSI) или Microsemi Adaptec. Настоятельно не рекомендую использовать промежуточные решения вроде HBA адаптеров. Также, обязательно организуйте мониторинг состояния массива.

модель создания и хранения бэкапов - Битрикс-бэкапы, конечно, хорошо, но с ростом объёмов SQL-базы вы можете столкнуться с тремя неприятными вещами: (1) процедура создания завершится по таймауту из-за размера базы, (2) ошибки в структуре базы не позволят Битриксу завершить бэкап, (3) низкая скорость исполнения задания. Задача резервного копирования решается гораздо эффективнее при использовании mysqldump и rsync, причём это позволит вам избежать указанных сложностей. Ко всему прочему, на ваших же плечах останется задача по хранению бэкапов вне сервера и создание плана восстановления в случае аварии.

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

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

2. Кто управляет настройками вашего домена?

Готово, с хостингом сервера разобрались, пошли дальше. Вам понадобиться логин и пароль от панели управления DNS-записями. Сам DNS-хостинг, скорее всего, находится у одного из этих провайдеров: nic.ru, reg.ru, pdd.yandex.ru, godaddy.com. Например, так выглядит панель управления DNS у pdd.yandex.ru:

Помимо того, что эта информация необходима для расчёта ресурсов на новом сервере, так ещё это способ сэкономить. Дело в том, что пользовательский контент обычно не удаляется, требуется не всем и не часто. Скажем, скан договора, прикреплённый к задаче, как свидетельство завершения бизнес-процесса, после его загрузки может быть никто так и не откроет. А “весить” он может не один мегабайт. А если таких договоров сотни? А если вместо них фото с корпоративов за последние 3 года? Контент, бесспорно, важный, но в оперативном доступе нужен редко. Как раз его и можно разместить на “дешёвых”, объёмных дисках, где условная стоимость за 1 гигабайт данных гораздо ниже, чем на быстрых SSD дисках, где мы разместим сам портал, ядро и SQL базу. Так же учтите, что свободного места на сервере должно хватить на полный архив портала + место, которое займёт содержимое после разархивирования.

4. Активирован ли лицензионный ключ?

Постепенно подбираемся к точке невозврата. Проверить активацию ключа и сделать это, при необходимости, можно тут: http://www.1c-bitrix.ru/support/key_info.php С технической точки зрения, нас интересует только пункт “Список адресов, включая тестовые, по которым будет доступна данная копия продукта "1С-Битрикс". Как раз тут нужно указать адрес, который вы добавили в панели управления DNS. Адресов может быть несколько. Остальная информация носит административный характер и для нас ценности не представляет, хотя и обязательна к заполнению.

5. Авторизационные данные создателя (сотрудник с ID=1)?

Последним подготовительным шагом нужно получит логин и пароль создателя. Сначала узнаем, кто это. Для этого откройте ваш облачный портал, в адресной строке после .bitrix24.ru вставьте следующее значение /company/personal/user/1/ Теперь вы знаете чей логин/пароль вам нужен и вооружившись средствами криптоанализа, без промедлений направляйтесь к этому сотруднику.

Сервер арендован и установлена ОС, все данные для переноса получены. Начинаем.

Первым делом идём сюда http://www.1c-bitrix.ru/support/ и создаём обращение с произвольным текстом о том, что хотим получить бэкап (бэкап можно запросить только 1 раз!!!).
В тексте обращения, обязательно укажите 5 пунктов:

1. Лицензионный ключ с числом пользователей не меньше, чем число пользователей на Битрикс24. Если вы докупали пользователей, то также понадобится купон на дополнительных пользователей.

2. Имя портала на Битрикс24. (например, intranet.bitrix24.ru)

3. Авторизационные данные создателя (сотрудник с ID=1) облачного портала Битрикс24, логин (email) и пароль.

4. Предпочтительную дату, после которой можно приступать к подготовке бэкапа (последний день работы в облачной версии).

5. Подтверждение, что с условиями переноса ознакомлены и согласны (сошлитесь на статью https://helpdesk.bitrix24.ru/open/1272913/)

Пользователю с ID=1 придёт уведомление с запросом доступа. Его нужно будет предоставить. Когда конкретно поддержка битрикса создаст бэкап - неизвестно. Это зависит от размеров портала, количества заявок, вспышек на солнце.. Вам нужно знать лишь то, что бэкап будет актуален на 00 часов 00 минут дня создания бэкапа.

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

mkdir /service

cd /service

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

chmod u+x bitrix-env.sh

./bitrix-env.sh

Скорее всего вам будет предложено согласиться на отключение SELinux, перезагрузиться и повторить процедуру. Соглашайтесь. После повторного запуска произойдёт процедура установки. Она может занять пару минут.

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

Где 8.8.8.8 замените IP адресом с которого вы будете подключаться к серверу. Теперь только вы сможете подключиться к вэб-серверу.

Очень рекомендую для повышения безопасности, установить fail2ban. Нужен он чтобы исключить попытки подбора пароля для подключения к серверу по SSH. Установив эту службу, вы можете ограничить количество попыток ввода неправильного пароля.

yum install fail2ban

После чего нужно немного поправить его конфиг, приведя файл /etc/fail2ban/jail.d/00-firewalld.conf к виду:

banaction = firewallcmd-ipset

bantime = 86400

findtime = 3600

maxretry = 3

[sshd]

enabled = true

и перезапустить службу:

systemctl restart fail2ban

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

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

443/tcp

80/tcp

25/tcp

5222/tcp

5223/tcp

8070/tcp

8890/tcp

8891/tcp

8893/tcp

8894/tcp

Далее, запустите скрипт /root/menu.sh

Выберите пункт 1 для создания нового пула, введите полный адрес вашего сервера, например demo.saltpro.ru

На этом этапе, пока всё, выходим.

К этому времени ваш бэкап, скорее всего, готов и ждёт вас. Об этом будет свидетельствовать новый ответ в тикете службы поддержки. Внимательно прочитайте всё, что там написано. Возможно, вам будет рекомендовано использовать особенный скрипт restore.php, который нужно будет скачать и заменить им тот, что лежит по адресу /home/bitrix/www (проверьте права и владельца файла, они должны совпадать с тем, что были у старого файла).

Прочитали, применили рекомендации, теперь открываем браузер, вводим туда https://адрес_вашего_портала Выбираем восстановление из бэкапа, указываем, что бэкап доступен по ссылке, нажимаем далее и медитируем. Длится процесс будет долго. После скачивания вам потребуется ввести пароль от архива, который будет указан в тикете. Главное не закрывать вкладку браузера! В процессе восстановления вас могут поджидать два нюанса: (1) бесчисленное количество сообщений Deprecated: Function mcrypt_decrypt() is deprecated in /home/bitrix/www/restore.php on line 3451 - это не страшно и на суть вопроса не влияет; (2) восстановление бэкапа может прерваться из-за ошибки Got a packet bigger than 'max_allowed_packet' bytes. Если первое - безобидное, то со вторым нужно что-то делать. А именно отредактировать файл /etc/mysql/conf.d/z_bx_custom.cnf, привести его к виду:

[mysqld]

max_allowed_packet=100M

После чего перезапустить MySQL:

systemctl restart mysqld

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

Хорошо, с восстановлением закончили, продолжаем настраивать)

Снимайте ограничение на подключение:

iptables -D INPUT -p tcp ! -s 8.8.8.8 -m multiport --dports 80,443 -j DROP

не забываем поменять 8.8.8.8 на своё значение.

yum install python2-certbot-nginx

Чтобы сервис letsencrypt корректно определил, для кого ставим сертификат, нужно поправить конфигурацию nginx. В файле /etc/nginx/bx/site_enabled/ssl.s1.conf ищем строку server_name и задаём ей значение, например, server_name demo.saltpro.ru;

После чего, выполним

certbot --nginx

Отвечаем на вопросы и в результате получаем сертификат. На этом этапе лучше перезагрузить сервер. Это связано с поведением утилиты выдачи сертификата, которая не самым правильным образом производит перезапуск вэб-сервера. Чтобы ваше соединение всегда было защищено сертификатом, положите в директорию /home/bitrix/www пустой файл .htsecure

Сразу проверьте два значения php в конфигурационном файле, по адресу /etc/php.d/bitrixenv.ini

Нас интересуют эти:

date.timezone = Europe/Moscow

memory_limit = 512M

Для поддержки Push&Pull сервиса, вам нужно запустить скрипт по адресу /root/menu.sh, выбрать 10-ый пункт и произвести установку. Задание будет выполняться в фоне, его статус можно проверить, нажав 5 из главного меню. Выполняться будет минут 5, дождитесь завершения и выходите.

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

Для настройки мэйл-аккаунта сделайте следующее:

cd /home/bitrix

touch .msmtprc

chmod 600 .msmtprc

chown bitrix:bitrix .msmtprc

Пример файла .msmtprc, в случае если вы используете сервис Яндекс.Почта:

account default

logfile /home/bitrix/.msmtp.log

host smtp.yandex.ru

port 465

from xxx@xxx.ru

keepbcc on

auth on

user xxx

password xxx

tls on

tls_starttls off

tls_certcheck off

systemctl restart nginx

systemctl restart apache2

В разделе Панель управления - Настройки продукта - Настройки модулей - Push and Pull приведите значение элементов к следующему виду:

- Путь для публикации команд: http://127.0.0.1:8895/bitrix/pub/

- Отправлять PUSH уведомления на мобильные телефоны: убрать чкбокс

- На сервере установлен и активирован "Push server": убрать чекбокс

- Отправлять PUSH уведомления на мобильные телефоны

- На сервере установлен и активирован "Push server"

На вкладке “Настройки”, в разделе “Файлы”, включите опцию “Быстрая отдача файлов через Nginx”

На вкладке “Авторизация” выключите опцию “Продлевать сессию при активности посетителя в окне браузера”

С настройками всё, давайте проверим, что получилось. Откройте Панель управления - Инструменты - Проверка системы и нажмите “Выполнить проверку”. Если всё сделано верно, то вы увидите примерно такую картинку: