В текущем разделе, посвещается основные выдержки по настройке кластера. Естественно они не являются полными, поскольку все это зависит от тонкости настройки каждой платформы. Но все-же хотчеться не искать в торопях, а где-же я это искал, или как я это когда-то делал?
- Отказоустойчивый кластер
Масштабируемость кластера серверов
- Требования назначения функциональности
Отказоустойчивый кластер
Уровень отказоустойчивости
Уровень отказоустойчивости определяет максимальное количество рабочих серверов, входящих в состав кластера, одновременный выход из строя которых не приведет к аварийному завершению сеансов подключенных пользователей. Надо понимать, что «выход из строя» подразумевает ситуации, подобные следующим: отключение питания компьютера, разрыв сетевого кабеля, проблемы с операционной системой, не позволяющие запустить процесс и т. д.
Таким образом, если в кластер серверов входит только один рабочий сервер, то максимальный уровень отказоустойчивости будет 0,т. к. выход из строя единственного рабочего сервера приведет к аварийному завершению всех подключенных пользователей. Если в кластер входит 4 рабочих сервера, то уровень отказоустойчивости может изменяться от 0 до 3. При этом 0 означает, что фатальным считается выход из строя любого рабочего сервера, а значение 3 означает, что кластер сохранит работоспособность даже в том случае, если выдут из строя 3 из 4 рабочих серверов.
Следует понимать, что увеличение уровня отказоустойчивости выполняется ценой некоторого падения производительности кластера, т. к. кластер будет тратить некоторые ресурсы на синхронизацию данных между рабочими серверами.
Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогу подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям, несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.
Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.
2.1.6. Масштабируемость кластера серверов
Масштабируемость кластера серверов обеспечивается несколькими способами:
● Наращиванием вычислительных мощностей компьютера, на котором развернут единственный рабочий сервер кластера.
● Возможностью включения в состав кластера серверов одного или нескольких новых рабочих серверов.
Все необходимые действия по обеспечению масштабируемости кластер серверов выполняет автоматически. Администратор кластер может влиять на действия кластера серверов с помощью изменения свойств рабочего сервера.
В список рабочих серверов кластера можно добавлять новые сервера и менять свойства существующих (см. здесь). Измененные значения свойств действуют только на новые соединения и сеансы. Удаление рабочего сервера следует проводить особым образом, чтобы не допустить аварийного отключения пользователей, которых обслуживает удаляемый сервер. Подробнее порядок удаления рабочего сервера см. здесь. Невозможно удаление последнего рабочего сервера в кластере с установленным признаком Центральный сервер. При создании кластера по умолчанию, рабочий сервер того компьютера, на котором создается кластер серверов, автоматически включается в список рабочих серверов и для этого рабочего сервера устанавливается флажок Центральный сервер.
Во время работы кластер серверов автоматически распределяет нагрузку между рабочими серверами таким образом, чтобы обеспечить минимальное время обслуживания клиентских приложений. Сервисы кластера (см. здесь) равномерно распределяются по рабочим серверам по типам сервисов, информационным базам и сеансам.
Во время установки соединения с информационной базой, кластер серверов выбирает рабочие сервера с максимальной доступной производительностью (на момент выбора рабочего сервера). Существующие соединения могут быть перемещены на другой рабочий сервер. Более подробное описание этого механизма см. здесь.
Описание других свойств, управляющих работой рабочего сервера, см. здесь.
2.1.7. Балансировка нагрузки в кластере
2.1.7.1. Доступная производительность рабочего процесса
Каждый рабочий процесс имеет свойство Доступная производительность. Оно определяет, насколько быстро данный рабочий процесс способен выполнить эталонный вызов сервера по сравнению с другими рабочими процессами. Эталонный вызов включает в себя следующие операции:
● Операция с памятью: выделение массива, заполнение массива, освобождение массива.
● Операция с файлами: создание, запись, удаление.
● Выполняется определение степени загрузки процессоров компьютера, на котором работает рабочий процесс и количество потоков, ожидающих исполнения. Это значение корректирует время выполнения эталонного вызова в сторону увеличения. Если пользователь, от имени которого работает сервер, не входит в группу Пользователи журналов производительности (Performance Log Users), то определение степени загрузки процессора не выполняется.
Значение свойства Доступная производительность вычисляется делением числа 10 000 на среднее (за 5 минут) время выполнения эталонного вызова текущим рабочим процессом. Эталонный вызов выполняется каждые 2 секунды в том случае, если в кластере присутствует несколько рабочих серверов. Если кластер серверов состоит из одного рабочего сервера – все рабочие процессы считаются равноправными.
Клиенты распределяются между рабочими процессами так, чтобы сделать доступную производительность всех рабочих процессов примерно одинаковой. Существенным считается отличие доступной производительности более чем на 25%.
При изменении соотношения между доступной производительностью рабочих процессов клиенты динамически в течение не более 10 минут перераспределяются между рабочими процессами.
При выключении рабочего процесса его клиенты динамически перераспределяются между оставшимися включенными рабочими процессами.
2.1.7.3. Требования назначения функциональности
2.1.7.3.1. Общая информация
Кластер серверов предоставляет некоторый набор функциональных возможностей (называемые объекты требований), распределением которых между рабочими серверами внутри кластера можно управлять. Например, можно указать, что все фоновые задания в кластере будут выполняться на выбранном рабочем сервере.
Для того чтобы поместить соединение или сервис кластера на какой-либо рабочий сервер, необходимо для выбранного рабочего сервера создать требование назначения функциональности. Это требование определяет возможность или невозможность конкретного сервера выполнять ту или иную работу. Рассмотрим более подробно, что собой представляет требование назначения функциональности.
Требование назначения функциональности определяет:
● Для какого объекта требования создается требование. В качестве объекта требования могут выступать некоторые сервисы кластера (см. здесь), клиентские соединения (см.здесь) и произвольный объект требования. В качестве объекта требования могут выступать следующие сервисы кластера:
● Блокировок объектов.
● Времени.
● Журналов регистрации.
● Заданий.
● Нумерации.
● Полнотекстового поиска.
● Пользовательских настроек.
● Сеансовых данных.
● Транзакционных блокировок.
● Работы с внешними источниками данных через ODBC.
● Работы с внешними источниками данных через XMLA.
● Сервис лицензирования.
● Сервис фонового обновления конфигурации базы данных.
● Сервис тестирования.
● Сервис внешнего управления сеансами.
● Определяет тип требования. Тип требования определяет, каким образом будет выполняться использование рабочего сервера:
● Не назначать – означает, что рабочий сервер, для которого создано данное требование, не будет назначен для обслуживания объекта требования, подходящего под условия, заданные в требовании.
● Назначать – означает, что рабочий сервер, для которого создано данное требование, будет являться одним из кандидатов на обслуживание данного объекта требования (если рабочих серверов будет несколько).
● Авто – означает, что рабочий сервер может быть использован для обслуживания объекта требования в том случае, если нет рабочего сервера с явным указанием необходимости использования.
СОВЕТ. Тип требования Авто имеет смысл использовать тогда, когда в списке требований рабочего сервера есть требование с более широким набором условий, и необходимо иметь требование для более узкого набора условий. Например, данный сервер не может обслуживать соединения клиентских приложений для всех информационных баз, кроме одной информационной базы, для которой такое обслуживание разрешено.
● Дополнительные параметры, необходимые кластеру серверов для принятия решения в ряде случаев:
● Имя информационной базы. Используется для уточнения требования для формирования требований для клиентских соединений и всех сервисов кластера, которые могут выступать в качестве объекта требования, кроме сервиса лицензирования.
● Дополнительные параметры. Используются для уточнения требований при размещении клиентского соединения или сервиса сеансовых данных. Дополнительный параметр проверяется на совпадение с началом соответствующего параметра объекта требования. Дополнительный параметр может принимать одно из следующих значений:
● Для указания конкретного фонового задания: BackgroundJob.CommonModule.<Имя модуля>.<Имя метода>;
● Для указания всех фоновых заданий: BackgroundJob.CommonModule;
● Для указания всех отчетов: BackgroundJob.Report. Указание имени отчета не поддерживается;
● Ввод по строке или поиск в списке: BackgroundJob.SystemBackgroundJob;
● Для указания фоновой реструктуризации: SystemBackgroundJob;
● Для клиентского приложения:
● 1CV8 – толстый клиент;
● 1CV8CDirect – тонкий клиент в случае прямого подключения к серверу «1С:Предприятия»;
● Designer – конфигуратор;
● COMConnection – COM-соединение;
● WebServerExtension – соединение с информационной базой через веб-сервер: веб-клиент, тонкий клиент в случае подключения через веб-сервер, Web-сервис.
Рассмотрим, как работает кластер серверов при обработке требований.
В случае необходимости выполнить размещение объекта требования, кластер выполняет следующие действия:
● На всех серверах, входящих в состав кластера, выполняется обработка заданных для этих серверов требований назначения функциональности. Обход серверов и требований выполняется в порядке следования этих объектов в консоли кластера.
● В каждом списке требований определяется первое требование, которое удовлетворяет размещаемому объекту: по собственно объекту, информационной базе и дополнительному параметру.
● Затем полученный список рабочих серверов сортируется по признаку типа требования так, что первыми оказываются рабочие сервера с явным указанием использования. Рабочие сервера, для которых подходящее требование содержит явный запрет на использование – исключаются из списка доступных рабочих серверов. При этом назначение выполняется следующим образом:
● Есть рабочие сервера с явным указанием использования: в этом случае объект требования будет обслужен одним из этих рабочих серверов.
● Нет рабочих серверов с явным указанием использования: происходит попытка использовать рабочие сервера с автоматическим указанием использования или те рабочие серверы, для которых не указано требований.
● Подробное описание правил выбора рабочего сервера для обслуживания объекта требования см. здесь.
● При размещении клиентского соединения, из списка доступных серверов будет выбран тот, в состав которого входит рабочий процесс с наивысшей доступной производительностью (см. здесь). Подробное описание правил выбора рабочего процесса в конкретном рабочем сервере см. здесь.
Клиентское приложение, инициировавшее размещение объекта требования, будет завершено аварийно в одном из следующих случаях:
● Если для объекта требования список рабочих серверов оказывается пустым – нет ни одного рабочего сервера, который может обслужить объект. При этом объект требования не будет размещен и будет вызвано исключение.
● Если невозможно выполнить размещение на выбранном рабочем сервер, например, если выбранный сервер вышел из строя, и нет альтернативных рабочих серверов.
2.1.7.3.2. Назначение объектов требований
Более подробно рассмотрим алгоритм назначения рабочего сервера для обслуживания сервиса кластера.
Для сервисов кластера (см. здесь) объектом требования может выступать:
● Сервис одного типа, если сервис не делится по информационным базам.
● Сервис одного типа для одной информационной базы, если сервис делится по информационным базам.
● Сервис сеансовых данных.
● Сервис лицензирования.
Сервисы распределяются между подходящими рабочими серверами следующим образом:
● Из перечня выбранных для назначения рабочих серверов выбираются те, которые в данный момент работоспособны. Среди оставшихся рабочих серверов выбираются те сервера, у которых свойство Приоритет содержит максимальное значение.
● Среди отобранных рабочих серверов сервисы распределяются равномерно.
● Сервисы, поддерживающие репликацию, могут назначаться на несколько рабочих серверов. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь). При этом один сервис будет являться активным, а с другими сервисами (резервными) будет поддерживаться репликация служебных данных сервиса. Репликация выполняется асинхронно. Синхронизация выполняется каждую секунду.
● Сервисы, которые не поддерживают перенос данных, назначаются на все рабочие серверы кластера с установленным флажком Центральный сервер (см. здесь).
● Для каждого сеанса, который обслуживает кластер серверов, создается свой экземпляр сервиса сеансовых данных. При отборе рабочих серверов, которые могут обслужить данный экземпляр сервиса, учитываются дополнительные параметры требования. Из списка доступных выбираются сервера с минимальным количеством обслуживаемых сервисов кластера. Количество используемых рабочих серверов равно уровню отказоустойчивости кластера плюс один (см. здесь).
● В случае необходимости использования сервиса лицензирования следует явно выбрать рабочий сервер, к которому будет выполняться привязка программной лицензии и явно описать в требованиях размещение сервиса на выбранном рабочем сервере.
● Остальные сервисы назначаются в единственном экземпляре.
Переназначение сервисов кластера между рабочими серверами может выполняться в следующих случаях:
● При добавлении рабочего сервера выполняется частичное переназначение сервисов. Данное переназначение выполняется автоматически.
● При удалении рабочего сервера из состава кластера или недоступности рабочего сервера выполняется переназначение только тех объектов требований, которые обслуживал удаляемый рабочий сервер. Данное переназначение выполняется автоматически.
● При удалении или добавлении информационной базы в кластер выполняется частичное переназначение. Данное переназначение выполняется автоматически.
● Переназначение происходит также в том случае, если администратор кластера выполнит операцию полного или частичного применения требований из консоли кластера (см.здесь).
2.1.7.3.3. Назначение рабочих процессов
При запуске кластера на каждом рабочем сервере запускается по одному рабочему процессу и начинается процесс вычисления доступной производительности для каждого рабочего сервера (см. здесь).
Установка соединения клиентского приложения с кластером серверов «1С:Предприятия» выполняется по следующим правилам:
● В соответствии с требованиями назначения и ограничениями по использованию оперативной памяти отбирается необходимый рабочий сервер.
Ограничения по использованию оперативной памяти учитываются в том случае, если запрос на установку соединения выполняется к информационной базе, к которой нет установленных соединений на выбранном рабочем сервере. В случае превышения лимита использования оперативной памяти рабочий сервер исключается из списка, если существует другой рабочий сервер, который не превысил лимит. Также исключаются рабочие сервера, которые не могут обработать требуемое соединение исходя из требований назначения.
● Для выбранного сервера определяется список рабочих процессов, которые доступны и могут обслужить запрашиваемое соединение. Рабочий процесс относится к списку доступных рабочих процессов в следующих случаях:
● Для рабочего процесса не достигнуто максимальное количество обслуживаемых информационных баз (свойство рабочего сервера Количество ИБ на процесс).
● Для рабочего процесса не достигнуто максимальное количество обслуживаемых соединений (свойство рабочего сервера Количество соединений на процесс).
● Рабочий процесс не находится в состоянии подготовки к автоматическому перезапуску.
● Из выбранных рабочих процессов предпочтение отдается тем рабочим процессам, которые уже обслуживают соединения информационной базы, соединение с которой необходимо обслужить. Если такого рабочего процесса нет – выбирается рабочий процесс с максимальным количеством обслуживаемых соединений.
● Если не удалось выбрать ни один рабочий процесс, то на данном рабочем сервере запускается новый рабочий процесс, который и будет обслуживать запрошенное соединение.
При установке соединения от лица существующего сеанса (если не удалось повторно использовать соединение предыдущего вызова сервера) предпочтение отдается рабочему процессу, который обслуживал предыдущее соединение этого сеанса. При этом возможен выбор другого рабочего процесса, если доступная производительность другого рабочего процесса выше доступной производительности текущего рабочего процесса не менее чем на 25%.
Если на одном рабочем сервере в течении 20 минут существуют 2 рабочих процесса, для которых суммарное количество обслуживаемых соединений и различных информационных баз меньше, чем значения, указанные в свойствах рабочего сервера (свойства Количество соединений на процесс и Количество ИБ на процесс), то процесс, который обслуживает меньшее количество соединений, будет помечен как устаревший и будет остановлен после разрыва последнего соединения. Существующим соединениям с «устаревшим» рабочим процессом будет «предложено покинуть» рабочий сервер при ближайшем серверном вызове через данное соединение. При этом «устаревший» рабочий процесс не участвует в распределении запросов на обслуживание новых объектов требований.
При подсчете количества обслуживаемых соединений учитываются соединения, которые создаются отладчиком для проверки прав доступа на предмет отладки.
ВНИМАНИЕ! Приведенные ниже примеры не являются законченными решениями какой-либо проблемы, а служат только для демонстрации принципов работы механизма размещения объектов требований по рабочим серверам в кластере.
2.1.7.4.1. Размещение всех фоновых заданий на одном рабочем сервере
Если необходимо разместить все фоновые задания на рабочем сервере SRV1, то для этого необходимо для рабочего сервера SRV1 задать следующее требование назначения функциональности:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.CommonModule.
2.1.7.4.2. Размещение сервиса лицензирования на выделенном рабочем сервере
Необходимо многопользовательскую клиентскую лицензию активировать для компьютера, на котором функционирует рабочий сервер SRV2, разместить на этот компьютер сервис лицензирования и не размещать на этот компьютер больше никаких сервисов. Тогда для рабочего сервера SRV2 следует указать следующие требования:
● Требование 1:
● Объект требования: Сервис лицензирования.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: не указывается.
● Требование 2:
● Объект требования: Любой объект требования.
● Тип требования: Не назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: не указывается.
Требование 1 обеспечит функционирование сервиса лицензирования на сервере SRV2, а Требование 2 обеспечит функционирование на сервере SRV2 только сервиса лицензирования (на сервере SRV2 не будут функционировать другие сервисы кластера).
При активации программной лицензии с помощью сервера «1С:Предприятия» следует указывать имя SRV2, в противном случае активированная лицензия не сможет быть использована кластером серверов, т. к. программная лицензия будет активирована для другого компьютера.
2.1.7.4.3. Запрет размещения сервиса работы с внешними источниками данных на одном рабочем сервере
Необходимо разрешить работу сервиса работы с внешними источниками данных на рабочих серверах SRV1 и SRV3, и запретить – на рабочем сервере SRV2. Для этого следует для рабочего сервера SRV2 указать следующее требование:
● Объект требования: Сервис работы с внешними источниками данных.
● Тип требования: Не назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: не указывается.
2.1.7.4.4. Один рабочий процесс обслуживает одну информационную базу
Необходимо настроить кластер серверов таким образом, чтобы каждая информационная база обслуживалась одним рабочим процессом. Для этого необходимо для каждого рабочего сервера установить свойство Количество ИБ на процесс в значение 1.
В результате на каждом сервере будет создано по два рабочих процесса (всего – 6, по 2 рабочих процесса на каждый из 3 рабочих серверов). При этом обслуживанием одной информационной базы будет заниматься 3 рабочих процесса на 3 рабочих серверах.
2.1.7.4.5. Назначение рабочих серверов для обслуживания выбранных информационных баз
Необходимо настроить кластер серверов таким образом, чтобы информационную базу DemoDB обслуживал только рабочий сервер SRV3, а информационную базу WorkDBобслуживали оба рабочих сервера: SRV1 и SRV2. Для этого необходимо настроить следующие правила:
● Для рабочего сервера SRV3:
● Объект требования: Любой объект требования.
● Тип требования: Назначать.
● Имя ИБ: DemoDB.
● Значение дополнительного параметра: не указывается.
● Для рабочих серверов SRV1 и SRV2:
● Объект требования: Любой объект требования.
● Тип требования: Назначать.
● Имя ИБ: WorkDB.
● Значение дополнительного параметра: не указывается.
Указанные правила «разнесут» по рабочим серверам все механизмы кластера серверов: соединения, фоновые задания, сервисы сеансовых данных и т. д.
2.1.7.4.6. Назначение конкретных фоновых заданий на конкретный рабочий сервер
Необходимо настроить кластер серверов таким образом, чтобы на рабочем сервере SRV1 выполнялись только отчеты, на рабочем сервере SRV2 выполнялись только регламентные задания ОбновлениеИндексаППД и ОбновлениеАгрегатовПродаж, а остальные фоновые задания должны выполняться на рабочем сервере SRV3. Для этого необходимо настроить следующие правила:
● Для рабочего сервера SRV1:
● Требование:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.Report.
● Для рабочего сервера SRV2:
● Требование:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.CommonModule.РаботаСПолнотекстовымПоиском.ОбновлениеИндексаПолнотекстовогоПоиска.
● Требование:
● Объект требования: Клиентское соединение с ИБ.
● Тип требования: Назначать.
● Имя ИБ: не указывается.
● Значение дополнительного параметра: BackgroundJob.CommonModule.РегламентныеЗаданияАгрегатов.ОбновлениеАгрегатовПродаж.
Комментариев нет:
Отправить комментарий