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

Обновлено: 06.07.2024

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

Для чего нужен кластер

Возможности Win2k3

Вообще говоря, одни кластеры предназначены для повышения доступности данных,
другие - для обеспечения максимальной производительности. В контексте статьи нас
будут интересовать MPP (Massive Parallel Processing) - кластеры, в
которых однотипные приложения выполняются на нескольких компьютерах, обеспечивая
масштабируемость сервисов. Существует несколько технологий, позволяющих
распределять нагрузку между несколькими серверами: перенаправление трафика,
трансляция адресов, DNS Round Robin, использование специальных
программ, работающих на прикладном уровне, вроде веб-акселераторов. В
Win2k3, в отличие от Win2k, поддержка кластеризации заложена изначально и
поддерживается два типа кластеров, отличающихся приложениями и спецификой
данных:

1. Кластеры NLB (Network Load Balancing) - обеспечивают
масштабируемость и высокую доступность служб и приложений на базе протоколов TCP
и UDP, объединяя в один кластер до 32 серверов с одинаковым набором данных, на
которых выполняются одни и те же приложения. Каждый запрос выполняется как
отдельная транзакция. Применяются для работы с наборами редко изменяющихся
данных, вроде WWW, ISA, службами терминалов и другими подобными сервисами.

2. Кластеры серверов – могут объединять до восьми узлов, их главная
задача - обеспечение доступности приложений при сбое. Состоят из активных и
пассивных узлов. Пассивный узел большую часть времени простаивает, играя роль
резерва основного узла. Для отдельных приложений есть возможность настроить
несколько активных серверов, распределяя нагрузку между ними. Оба узла
подключены к единому хранилищу данных. Кластер серверов используется для работы
с большими объемами часто изменяющихся данных (почтовые, файловые и
SQL-серверы). Причем такой кластер не может состоять из узлов, работающих под
управлением различных вариантов Win2k3: Enterprise или Datacenter (версии Web и
Standart кластеры серверов не поддерживают).

В Microsoft Application Center 2000 (и только) имелся еще один вид
кластера - CLB (Component Load Balancing), предоставляющий возможность
распределения приложений COM+ между несколькими серверами.

NLB-кластеры

1) unicast – одноадресная рассылка, когда вместо физического МАС
используется МАС виртуального адаптера кластера. В этом случае узлы кластера не
могут обмениваться между собой данными, используя МАС-адреса, только через IP
(или второй адаптер, не связанный с кластером);

2) multicast – многоадресная рассылка, МАС-адрес кластера назначается
физическому адресу, но не затирая его. Для реализации этого метода
маршрутизаторы должны поддерживать групповые МАС-адреса.

В пределах одного кластера следует использовать только один из этих режимов.

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

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

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

Настройка NLB-кластера

Для организации NLB-кластеров дополнительное ПО не требуется, все
производится имеющимися средствами Win2k3. Для создания, поддержки и мониторинга
NLB-кластеров используют компонент «Диспетчер балансировки сетевой нагрузки»
(Network Load Balancing Manager), который находится во вкладке
«Администрирование» «Панели управления» (команда NLBMgr). Так как компонент
«Балансировка нагрузки сети» ставится как стандартный сетевой драйвер Windows,
установку NLB можно выполнять и при помощи компонента «Сетевые подключения», в
котором доступен соответствующий пункт. Но лучше использовать только первый
вариант, одновременное задействование диспетчера NLB и «Сетевых подключений»
может привести к непредсказуемым результатам.

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

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

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

Теперь вызываем диспетчер NLB. Кластеров у нас пока нет, поэтому появившееся
окно не содержит никакой информации. Выбираем в меню «Кластер» пункт «Новый» и
начинаем заполнять поля в окне «Параметры кластера». В поле «Настройка
IP-параметров кластера» вводим значение виртуального IP-адреса кластера, маску
подсети и полное имя. Значение виртуального МАС-адреса устанавливается
автоматически. Чуть ниже выбираем режим работы кластера: одноадресный или
многоадресный. Обрати внимание на флажок «Разрешить удаленное управление» - во
всех документах Microsoft настоятельно рекомендует его не использовать во
избежание проблем, связанных с безопасностью. Вместо этого следует применять
диспетчер или другие средства удаленного управления, например инструментарий
управления Windows (WMI). Если же решение об его использовании принято, следует
выполнить все надлежащие мероприятия по защите сети, прикрыв дополнительно
брандмауэром UDP-порты 1717 и 2504.

После заполнения всех полей нажимаем «Далее». В окне «IP-адреса кластера» при
необходимости добавляем дополнительные виртуальные IP-адреса, которые будут
использоваться этим кластером. В следующем окне «Правила для портов» можно
задать балансировку нагрузки для одного или для группы портов всех или
выбранного IP по протоколам UDP или TCP, а также блокировать доступ к кластеру
определенным портам (что межсетевой экран не заменяет). По умолчанию кластер
обрабатывает запросы для всех портов (0–65365); лучше этот список ограничить,
внеся в него только действительно необходимые. Хотя, если нет желания возиться,
можно оставить все, как есть. Кстати, в Win2k по умолчанию весь трафик,
направленный к кластеру, обрабатывал только узел, имевший наивысший приоритет,
остальные узлы подключались только при выходе из строя основного.

В режиме фильтрации «Несколько узлов» можно дополнительно указать вариант
определения сходства клиентов, чтобы направлять трафик от заданного клиента к
одному и тому же узлу кластера. Возможны три варианта: «Нет», «Одно» или «Класс
C». Выбор первого означает, что на любой запрос будет отвечать произвольный
узел. Но не следует его использовать, если в правиле выбран протокол UDP или
«Оба». При избрании остальных пунктов сходство клиентов будет определяться по
конкретному IP или диапазону сети класса С.

Далее подключаемся к узлу будущего кластера, введя его имя или реальный IP, и
определяем интерфейс, который будет подключен к сети кластера. В окне «Параметры
узла» выбираем из списка приоритет, уточняем сетевые настройки, задаем начальное
состояние узла (работает, остановлен, приостановлен). Приоритет одновременно
является уникальным идентификатором узла; чем меньше номер, тем выше приоритет.
Узел с приоритетом 1 является мастер-сервером, в первую очередь получающим
пакеты и действующим как менеджер маршрутизации.

Флажок «Сохранить состояние после перезагрузки компьютера» позволяет в случае
сбоя или перезагрузки этого узла автоматически ввести его в строй. После нажатия
на «Готово» в окне Диспетчера появится запись о новом кластере, в котором пока
присутствует один узел.
Следующий узел добавить также просто. Выбираем в меню «Добавить узел» либо
«Подключить к существующему», в зависимости от того, с какого компьютера
производится подключение (он уже входит в кластер или нет). Затем в окне
указываем имя или адрес компьютера, если прав для подключения достаточно, новый
узел будет подключен к кластеру. Первое время значок напротив его имени будет
отличаться, но когда завершится процесс схождения, он будет такой же, как и у
первого компьютера.

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

После установки NLB-кластера не забудь изменить DNS-запись, чтобы
разрешение имени теперь показывало на IP-кластера.

Изменение загрузки сервера

В такой конфигурации все серверы будут загружены равномерно (за исключением
варианта «Один узел»). В некоторых случаях необходимо перераспределить нагрузку,
большую часть работы возложив на один из узлов (например, самый мощный).
Применительно к кластеру правила после их создания можно изменить, выбрав в
контекстном меню, появляющемся при щелчке на имени, пункт «Свойства кластера».
Здесь доступны все те настройки, о которых мы говорили выше. Пункт меню
«Свойства узла» предоставляет несколько больше возможностей. В «Параметрах узла»
можно изменить значение приоритета для конкретно выбранного узла. В «Правилах
для портов» добавить или удалить правило нельзя, это доступно только на уровне
кластера. Но, выбрав редактирование конкретного правила, мы получаем возможность
скорректировать некоторые настройки. Так, при установленном режиме фильтрации
«Несколько узлов» становится доступным пункт «Оценка нагрузки», позволяющий
перераспределить нагрузку на конкретный узел. По умолчанию установлен флажок
«Равная», но в «Оценке нагрузки» можно указать другое значение нагрузки на
конкретный узел, в процентах от общей загрузки кластера. Если активирован режим
фильтрации «Один узел», в этом окне появляется новый параметр «Приоритет
обработки». Используя его, можно сделать так, что трафик к определенному порту
будет в первую очередь обрабатываться одним узлом кластера, а к другому – другим
узлом.

Журналирование событий

Настраиваем IIS с репликацией

Кластер кластером, но без службы он смысла не имеет. Поэтому добавим IIS (Internet
Information Services). Сервер IIS входит в состав Win2k3, но, чтобы свести к
минимуму возможность атак на сервер, он по умолчанию не устанавливается.

Инсталлировать IIS можно двумя способами: посредством «Панели управления» или
мастером управления ролями данного сервера. Рассмотрим первый. Переходим в
«Панель управления – Установка и удаление программ» (Control Panel - Add or
Remove Programs), выбираем «Установку компонентов Windows» (Add/Remove Windows
Components). Теперь переходим в пункт «Сервер приложений» и отмечаем в «Службах
IIS» все, что необходимо. По умолчанию рабочим каталогом сервера является \Inetpub\wwwroot.
После установки IIS может выводить статические документы.

Вот, собственно, и все. Если в файл hosts, который находится в C:\Windows\System32\Drivers\Etc,
добавить запись для разрешения имени веб-сервера и IP-адрес кластера, то,
обратившись с локального узла, можно получить документ с веб-сервера. Для
репликации данных между узлами кластера используй службу DFS, о которой подробно
говорилось в последнем
номере за прошлый год.

Полную версию статьи
читай в февральском номере
Хакера!

Обычно, когда говорят о web-сервере, подразумевают решения на базе платформы Linux. Но если ваша инфраструктура развернута на основе Windows Server то логично будет использовать веб-сервер IIS. Вопреки распространенному мнению, это весьма популярная платформа, которая позволяет работать как с большинством популярных CMS, так и имеет широкий спектр систем, предназначенных для работы именно на Windows и IIS.

Для установки веб-сервера на платформе Windows перейдем в оснастку Роли в Диспетчере сервера и выберем установку ролей Веб-сервер (IIS) и Сервер приложений.

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

Теперь перейдем в к настройке сервера, для этого откроем Диспетчер служб IIS (находится в Пуск - Администрирование).

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

В открывшемся окне укажите имя сайта, путь к корневой папке (по умолчанию сайты пользователей располагаются в C:\inetpub\wwwroot), которую следует предварительно создать и укажите имя узла (доменное имя сайта), в нашем случае iissite.local

Не забудьте добавить A-запись с именем вашего сайта на DNS-сервер или пропишите необходимые строки в файлы hosts тех рабочих станций, откуда будете обращаться к сайту

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

Далее укажите привязку FTP-cлужбы к сетевым интерфейсам и портам, а также настройте параметры безопасности. Если вы собираетесь использовать SSL, то учтите что вам потребуется сертификат, хотя если вы будете использовать FTP-доступ только для собственных нужд, то можно обойтись самоподписанным сертификатом. Не забудьте поставить галочку для автоматического запуска FTP-сайта.

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

Попробуйте подключиться через FTP используя любой клиент и загрузите проверочную html страницу с именем index.html, пример такой страницы мы приводили здесь. Если все сделано правильно, то, набрав в браузере имя нашего сайта, вы увидите такую страницу:

Веб-сервер настроен и вы можете использовать его для размещения HTML-страниц, однако современные сайты используют для хранения своих данных СУБД, поэтому следующим шагом установим MS SQL Express 2012, возможностей которого с лихвой хватит для наших задач. Установка производится со значениями по умолчанию, кроме Режима проверки подлинности, который следует переключить в Смешанный режим и задать пароль суперпользователю SQL-сервера sa.

Мы будем устанавливать Orchard CMS, для получения пакета пройдите по ссылке и выберите Загрузить как zip, распакуйте полученный архив и закачайте в корень сайта содержимое папки Orchard.

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

Также не забудьте создать базу данных для сайта, для этого зайдите в SQL Server Management Studio и, щелкнув правой кнопкой на пункте Базы данных в боковом меню, создайте новую базу.

Для установки CMS наберите в браузере адрес сайта и следуйте указаниям скрипта установки. Никаких сложностей там нет, единственное затруднение может вызвать правильное указание параметров подключения к SQL-серверу. Укажите что вы используете SQL Server (или SQL Express)

server=SERVERNAME\SQLEXPRESS - имя сервера, на котором установлен SQL-сервер, и экземпляра SQL-сервера.
database=iissite - имя базы данных (в нашем случае iissite)
user=sa - пользователь СУБД (в нашем случае sa)
password=sapasswd - пароль пользователя sa.

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

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

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

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

В каждом узле должно быть не менее двух сетевых интерфейсов. Эти процедуры предполагают использование только двух сетей: публичной и частной. Если кластер имеет две сети, необходимо настроить одну из них как смешанную (общедоступную) сеть, а другую — как частную. Если имеется более двух сетей, остальные сети можно настраивать в соответствии с потребностями.

Настройка приоритета сетей кластера отличается от настройки порядка сетевых подключений в Microsoft Windows. Подробные инструкции по настройке порядка сетевых подключений в Windows см. в разделе Инструкции по настройке сетевых подключений для кластерной непрерывной репликации.

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

Дополнительные сведения о разрешениях, делегировании ролей и правах, необходимых для администрирования Exchange Server 2007, см. в разделе Вопросы, связанные с разрешениями.

Использование администратора кластера для разрешения использования сетей кластером

Необходимо открыть администратор кластера.

В дереве консоли щелкните узел Конфигурация кластера, а затем щелкните Сети.

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

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

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

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

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

Открыть администратор кластера.

В дереве консоли нажать правой кнопкой мыши Имя кластера и нажать Свойства.

Откройте вкладку Приоритет сети.

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

По завершении нажать ОК.

Настройка использования сети кластером с помощью Cluster.exe

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

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

Убедитесь, что все частные сети настроены только для внутренней связи в кластере (как частные сети), а все общедоступные сети — для всех типов связи (как смешанные типы). Для этого выполните указанные ниже команды и проверьте, установлена ли для частных сетей роль 1 (0x1), а для общедоступных (смешенных) сетей — роль 3 (0x3):

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

Настройка приоритета сети кластера с помощью Cluster.exe

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

Параметр /setnetpri зависит от порядка. При наличии нескольких общедоступных или частных сетей укажите все частные сети в начале команды, чтобы они имели наивысший приоритет (например: Priv1,Priv2,Pub1,Pub2).

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

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

По сути, данный комплекс ПО содержит в себе настроенный 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 на серверы больше ничего не устанавливалось.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Даём роль mysql_slave серверу, на который мы планируем перенести БД
На целевом сервере меняем роль mysql_slave на роль mysql_master (автоматом старый mysql_master переходит в режим mysql_slave)
Удаляем роль mysql_slave на исходном сервере, бывшем master
…
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, из коробки не работает.

Выводы

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

Читайте также: