ЛР4_1С_83_тонкий_и_WEB-клиент (1031817), страница 4

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

Текст из файла (страница 4)

// в кластере 1541 центрального сервера TestSrv

СоединениеСРабочимПроцессом = COMСоединитель.ConnectWorkingProcess("tcp://TestSrv:1562");

Системное фоновое задание

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

Соединение фонового задания существует до тех пор, пока выполняется фоновая реструктуризация.

Подробнее о фоновом обновлении конфигурации базы данных см. книгу «1С:Предприятие 8.3. Руководство разработчика».

2.1.4.2. Виды сеансов

Возможны следующие виды сеансов:

• ● Толстый клиент,

• ● Тонкий клиент,

• ● Веб-клиент,

• ● Конфигуратор,

• ● COM-соединение,

• ● WS-соединение,

• ● Фоновое задание,

• ● Консоль кластера,

• ● Сервер администрирования,

• ● COM-администратор.

Описание сеансов в общем соответствует описанию соответствующего соединения. Описание сеанса веб-клиента приведено ниже.

Веб-клиент

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

Сеанс Веб-клиент создается в результате интерактивного запуска веб-клиента и существует до тех пор, пока не будет завершен сеанс интерактивной работы с информационной базой (закрыто последнее окно веб-браузера).

1.4.3. Внешнее управление сеансами

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

• ● Ограничить количество одновременно работающих пользователей с одной информационной базой.

• ● Обеспечить некоторый гарантированный запас лицензий при работе с информационной базой, например, при наличии 100 лицензий обеспечить гарантированную возможность доступа к информационной базе двух пользователей с фиксированными именами.

• ● Другие аналогичные задачи.

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

Предполагается следующая схема работы механизма:

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

• ● Web-сервис принимает решение о разрешении или запрещении создания сеанса и возвращает управление кластеру серверов. При необходимости, Web-сервис должен вести учет созданных сеансов в необходимых разрезах.

• ● При завершении сеанса, кластер серверов также информирует Web-сервис о том, что сеанс завершается.

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

Описание Web-сервиса, который используется в механизме внешнего управления сеансами, и пример реализации см. здесь.

1.5. Отказоустойчивый кластер

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

• ● перезапуск рабочих процессов и менеджеров кластера (как плановый, так и аварийный);

• ● выход из строя сервера, входящего в состав кластера.

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

1.5.1. Транзакционность сеансовых данных

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

• ● в процессе вызова сервера, после фиксации первой за этот вызов транзакции, аварийно завершился рабочий процесс;

• ● при возврате управления клиенту произошла ошибка передачи данных.

1.5.2. Повтор последнего вызова

Если в процессе вызова сервера произошла ошибка передачи данных, то это может означать, что:

• ● произошел обрыв канала связи,

• ● произошло аварийное завершение рабочего процесса сервера.

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

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

1.5.3. Повтор интерактивного действия

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

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

1.5.4. Уровень отказоустойчивости

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

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

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

Уровень отказоустойчивости связан с количеством центральных серверов в кластере. Количество центральных серверов определяет возможность создания новых соединений. Если, например, в кластер входит два центральных сервера при общем количестве 3 рабочих сервера, то пользователи смогу подключаться к информационным базам в случае аварийного завершения одного центрального сервера. При этом остается два работающих рабочих сервера: один центральный и один рабочий. Если в кластере будет только один центральный сервер, то аварийное завершение этого сервера приведет к тому, что кластер станет недоступен пользователям, несмотря на то, что в нем сохранили работоспособность еще 2 рабочих сервера.

Если в кластере присутствует 3 рабочих сервера (из них один центральный) и установлен уровень отказоустойчивости равный 1, то могут наблюдаться различные ситуации. Рассмотрим их.

Выход из строя одного рабочего сервера

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

Рис. 7. Аварийное завершение одного рабочего сервера

Выход из строя центрального сервера

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

Рис. 8. Аварийное завершение центрального сервера

Выход из строя двух рабочих серверов

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

Рис. 9. Аварийное завершение двух рабочих серверов

Таким образом, можно вывести следующую формулу, связывающую количество центральных серверов в кластере и уровень отказоустойчивости:Количество центральных серверов = Уровень отказоустойчивости+1. При этом надо понимать, что буквальное следование этой формуле приведет к некоторому снижению производительности кластера, т. к. на синхронизацию реестра кластера будет тратиться некоторая часть мощности системы. При определении количества центральных серверов и уровня отказоустойчивости следует соблюдать баланс между отказоустойчивостью и приемлемым уровнем производительности кластера серверов, учитывая при этом характеристики оборудования компьютеров, входящих в состав кластера.

1.6. Масштабируемость кластера серверов

Масштабируемость кластера серверов обеспечивается несколькими способами:

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

• ● Возможностью включения в состав кластера серверов одного или нескольких новых рабочих серверов.

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

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

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

Характеристики

Список файлов книги