Обновлено: 07.07.2024

Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие

Ниже приводится инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие.

Рекомендуется при настройке рабочего сервера пройти указанный ниже сheck-лист и продумать, нужна ли указанная ниже настройка в вашем конкретном случае.

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

1. Определить, сколько информационных баз будут использоваться в кластере для работы пользователей

Существует несколько вариантов развертывания:

• в продуктивной среде и подготовительной зоне;
• в тестовой зоне;
• в зоне разработки.

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

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

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

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

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

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

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

2. Определить, сколько пользователей будет работать одновременно

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

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

• Конфигурации системы;
• Сценария работы пользователей;
• Числа одновременно работающих пользователей;
• Используемых версий программных продуктов.

3. Настроить профили пользователей ОС, от которых будут запускаться процессы кластера

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

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

Для этого нужно:

Для того, чтобы создать профили пользователей ОС достаточно один раз войти от их имени в ОС Windows.

4. Настроить логирование и дампы

Для этого необходимо настроить:

• Технологический журнал
• Сбор дампов процессов кластера средствами Платформы (указнием в logcfg.xml секции dump) либо Windows Error Reporting Services

Хорошей практикой будет настроить сбор WER для rmngr и ragent, но не указывать rphost.

5. Проверить настройки операционной системы

5.1. Настроить рабочий сервер

5.2. Настроить рабочий сервер

Необходимо настроить рабочий сервер в соответствии с инструкцией, которая позволяет избежать ошибки "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"

5.3. Убедиться, что брадмауэр операционной системы настроен таким образом, что не запрещает процессам кластера взаимодействовать корректно.

Информация по клиент-серверному варианту работы здесь;

Обратите внимание на используемые порты, которые указываются в параметрах центрального сервера,

в свойствах кластера серверов,

и рабочих серверов кластера.

Также необходимо открыть порт для указания сетевого порта для ras в случае использования. --port или -p указывает сетевой порт, по которому утилита администрирования будет взаимодействовать с сервером администрирования. Значение по умолчанию равно 1545.

5.4. Убедиться, что на рабочих серверах кластера одновременно не используется IPv4 и IPv6.

5.5. Убедиться, что схема управления питанием - "Высокая производительность".

5.6. Убедиться, что установлены компоненты Microsoft Data Access Components

Этот пункт нужен для настройки с СУБД MS SQL Server.

В противном случае будете получать ошибку вида: "Компоненты OLE DB провайдера не найдены".

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

Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):

• Запустить regedit и в ветке HKLM\System\CurrentControlSet\Services\Tcpip\Parameters указать
  • MaxFreeTcbs= 100000
  • TcpTimedWaitDelay= 30
  • MaxUserPort= 65535
  • EnableDynamicBacklog= 1
  • MinimumDynamicBacklog= 20
  • MaximumDynamicBacklog= 20000
  • DynamicBacklogGrowthDelta= 10
  • Выполнить: netsh int ipv4 set dynamicport tcp start=10000 num=55536
  • Выполнить: netsh int ipv4 set dynamicport udp start=10000 num=55536

  7. Настроить кластер серверов

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

  7.2. Настроить условия перезапуска

  Настроить условия перезапуска по превышению порога памяти.

  7.3. Настроить расположение каталога кластера

  Необходимо убедиться, что

  • на дисках достаточно места;
  • сеансовые данные расположены на быстрых дисках;

  
  

  7.4. Настроить число соединений и информационных баз на процесс

  Настройку необходимо выполнить с учетом конфигурации системы

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

  Не стоит просто так уменьшать параметр "Число соединений на процесс" или "Число информационных баз на процесс".

  Если у вас нет технического обоснования, почему именно так лучше, рекомендуем оставить значения по умолчанию

  
  

  7.5. Выполнить настройки для случая нескольких рабочих серверов в кластере.

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

    8. Первый запуск

    На этом этапе следует выполнить следующие шаги:

    • Запустить кластер серверов, создать информационную базу;
    • Зарегистрировать программные лицензии;
    • Убедиться, что пользователь может войти в информационную базу без ошибок.

    9. Отказоустойчивость

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

    9.1. Проверить лицензии.

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

    9.2. Установить флаг "Центральный сервер".

    Установить флаг как на рисунке ниже.

    
    

    9.3. Установить флаг "Уровень отказоустойчивости"

    Установить параметр, пример на рисунке ниже.

    
    

    Подробную информацию про уровень отказоустойчивости вы можете прочитать в статье

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

    9.4. Скорректировать строку соединения

    Необходимо скорректировать строку соединения с информационной базой.

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

    Список указывается в формате Server1, Server2:Port, Server3.

    10. Замечания

    10.1. Не настраивайте exec backup (или аналогичные утилиты) на директории кластера серверов

    Причина в том, что в этих директориях могут располагаться хранилища с сеансовыми данными, выполнять backup которых не нужно, а создание backp-а которых будет приводить к избыточным накладным расходам.

    10.2. Не настраивайте сжатие данных дисков с директорией кластера

    
    

    10.3. Не забывайте про периодическое выполнение дефрагментации дисков ОС Windows.

    10.4. Настроить защиту от вирусов.

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

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

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

    Для начала вкратце рассмотрим существующие технологии высокой доступности баз данных Microsoft. Одним из решений по отказоустойчивости является использование Windows Server Failover Cluster (WSFC). Рассмотрим его на примере:

    
    

    WSFC использует общее сетевое хранилище (SAN). При установке SQL в отказоустойчивом кластере на общем хранилище размещаются системные и пользовательские базы данных. На приведенной схеме два узла (SQLCLU01NODE01 и SQLCLU01NODE02) объединены в отказоустойчивый кластер SQLCLUSTER01A. При этом SQL установлен именованным экземпляром (instance), т.е. кластеризованный адрес подключения SQL-сервера выглядит так SQLCLUSTER01A\SQL. При штатной работе один из узлов кластера (сервер) является активным (в примере — SQLCLU01NODE01), а второй находится в горячем резерве. Когда происходит отказ активного сервера SQLCLU01NODE01, служба кластеров осуществляет переключение (прозрачное для пользователей) на резервный узел SQLCLU01NODE01.

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

    Решение давно существует (по-моему, начиная с Windows Server 2000 и SQL Server 2000) и не должно вызывать сложностей при развертывании.

    С выходом SQL2005SP1 появилась возможность зеркалирования (mirroring) баз данных. Основной принцип зеркалирования — создание горячей резервной копии базы данных на другом сервере (хранилище).

    
    

    На основном сервере (Primary) располагается база данных (principal database), с которой в обычном режиме работают пользователи.
    На резервном сервере (Mirror) располагается зеркальная копия базы данных (mirror database).

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

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

    Необходимо отметить, что подключение к зеркальной базе данных клиентским приложением, не получится в связи с тем, что эта база всегда находится в режиме восстановления. В этом случае можно использовать снимок (snapshot) зеркальной базы. Об этой и о других технологиях Microsoft можно прочитать, например, тут

    Новые возможности MS SQL 2012

    
    Помимо всего вышеописанного в SQL 2012 появилась новая функциональность — группы доступности AlwaysOn. Что нам пишет Microsoft:
    

    Availability Groups is an enterprise-level high-availability and disaster recovery solution introduced in SQL Server 2012 to enable you to maximize availability for one or more user databases.

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

    Попробуем разобраться в особенностях. На первый взгляд группы доступности AlwaysOn – это развитие зеркалирования. В сети есть много инструкций по развертыванию и настройке AlwaysOn, поэтому я расскажу только о сути. Чтобы развернуть AlwaysOn, необходим отказоустойчивый кластер WSFC. Для включения поддержки AlwaysOn необходимо установить MS SQL на экземпляр отказоустойчивого кластера и в свойствах службы SQL (оснастка SQL Server Configuration Manager) включить высокий уровень доступности AlwaysOn. Естественно, что это необходимо сделать на всех серверах, которые планируем задействовать для AlwaysOn.

    На следующем рисунке представлен кластер WSFC с узлами Node01-Node05. На каждом узле установлен экземпляр SQL сервера с поддержкой AlwaysOn. В рамках SQL-серверов создана группа доступности MyAg с максимально возможным количеством реплик (рабочая база – Primary Replica и 4-е копии – Secondary Replica).

    
    

    Группа доступности — это совокупность реплик доступности, их режимы работы, совокупность баз данных и слушатель группы (listener). На рисунке ниже показан вид утилиты MS SQL Management Studio с группой доступности.

    
    

    Тут мы видим подключение к экземпляру SQL-сервера с именем ARSHAD-PC. На этом сервере создана группа доступности AlwaysOnDemo-AG, в которую добавлены две реплики (сервера, на которых располагаются реплики) ARSHAD-PC и ARSHAD-LP. Причем, в данный момент, основная реплика группы доступности расположена на сервере ARSHAD-PC и с этого же сервера происходит управление данной группой. Так же в группу доступности включены две базы данных AdventureWorks и AdventureWorksDW. У данной группы доступности есть слушатель (listener) с именем AlwaysOnDemo-L. По сути это отказоустойчивый адрес подключения к виртуальному серверу группы доступности.

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

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

    Преимущества и недостатки у AlwaysOn в основном такие же как у зеркалирования, но есть и особенности. Как я понял, основные отличия AlwaysOn от mirroring – возможность создания реплик read-only, возможность создания более одной копии, простота настройки, большая гибкость, отсутствие Whitness-сервера (вместо этого listener в группе доступности).

    По причине наличия некоторого опыта с 1С возникло желание проверить работу AlwaysOn совместно с 1С: Предприятие. Тем более что при построении WSFC для 1С не должно возникнуть каких-либо проблем или особенностей. По сути, AlwaysOn должен обеспечить отказоустойчивость выше, чем WSFC (если использовать разные хранилища), при этом появится возможность разгрузить основную базу от пользователей отчетов (реплика ReadOnly) и еще мы сможем распределить нагрузку по серверам путем создания нескольких рабочих групп.

    Работа 1С: Предприятие и MS SQL 2012

    Платформа 1С: Предприятие, начиная с версии 8.2.17, официально поддерживает работу с MSSQL 2012 (до этого необходимо было переносить с SQL2008 хранимую процедуру sp_dboption).

    В связи с появлением AlwaysOn в SQL дополнился синтаксис строки подключения ODBC, появились параметры: ApplicationIntent — позволяет определить тип рабочей нагрузки (ReadOnly / ReadWrite), MultiSubnetFailover — ускоренное обнаружение активного сервера и др. Эти новые возможности 1С не поддерживает. Есть выход — указывать при подключении к рабочей базе адрес listener-а, а к базе данных в режиме чтения подключаться напрямую к серверу реплики ReadOnly (более подробно см. в эксперименте).

    Эксперимент

    Итак, сам эксперимент. Ранее мы договорились, что будем исследовать AlwaysOn SQL 2012 применительно к 1С. Для начала опишу конфигурацию серверов.

    В нашем распоряжении 4-е сервера: один сервер приложения 1С и три сервера SQL в кластере.

    
    

    Эксперимент будем проводить в два этапа. На первом этапе опробуем возможность работы информационной базы 1С с использованием AlwaysOn SQL 2012 и проверим отработку отказа. На втором этапе исследуем работу реплики ReadOnly. Для простоты ограничимся двумя базами данных.

    В качестве информационной базы 1С возьмем типовую кофигурацию «1С: Бухгалтерия предприятия». Проведем подготовительную работу и выполним настройку серверов, групп доступности и баз данных. Итак, создаем на сервере ServerSQL2 базу данных Dbtest2, затем на этом же сервере создаем группу доступности AG_test2, куда помещаем эту же базу:

    
    

    Аналогично поступаем с базой данных Dbtest1 на сервере ServerSQL1. Теперь на сервере приложений «Server1C» регистрируем две информационные базы:

    
    

    
    

    Ну и приступем к самому эксперименту, подключившись с клиентского компьютера с помощью 1С: Передприятия к обеим информационным базам. Запустим в обоих сеансах 1С: Предприятие формирование какого-либо долгоиграющего отчета, и не дожидаясь заверешния его формирования промоделируем отказ сервера в группе доступности AGtest2:

    
    

    И тут же получаем ошибку в информационной базе, которая размещена в группе доступности, где моделировали отказ:

    
    

    Подключение к другой информационной базе (по понятным причинам) остается работающим. Перезапускаем на клиенте приложение 1С «аварийной» информационной базы, программа работает корректно. При этом в SQL Management Studio можем наблюдать, что теперь основоной репликой в этой группе доступности становится сервер ServerSQL1.ё

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

    Теперь попробуем работу с базой ReadOnly. Для того, чтобы подключиться из 1С к такой базе необходимо сделать две вещи: доработать конфигурацию 1С таким образим, чтобы из нее не выполнялась запись в базу данных во время работы, и настроить подключение информационной базы.

    Примеры доработки конфигурации 1С приведены выше. Что касается подключения к базе SQL, то тут все гораздо проще. Т.к. платформа 1С: Предприятие не поддерживает новый синтаксис строки подключения к MSSQL 2012, пропишем подключение к базе данных в режиме ReadOnly напрямую:

    
    

    Так же необходимо указать возможность подключения к ReadOnly реплике для всех клиентов. Для этого в SQL Management Studio открываем свойства группы доступности и для реплики меняем свойство «Вторичная реплика для чтения» со значения «Только для чтения» на «Да»:

    
    

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

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

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

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

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

    Выводы

    К сожалению, в СУБД Microsoft отказоустойчивость есть, а балансировки по-прежнему нет. Огорчает так же отработка отказа в AlwaysOn: активные соединения с базой отваливаются. Ожидания, исходя из общего описания технологии на ресурсах Microsoft и по выступлениям на различных конференциях, были несколько другими. Но порывшись на ресурсах Microsoft, нашел вот что.

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

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

    Кластер — это разновидность параллельной
    или распределённой системы, которая:
    1. состоит из нескольких связанных
    между собой компьютеров;
    2. используется как единый,
    унифицированный компьютерный ресурс

    Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.

    1. Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
    2. Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
    3. Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
    4. Сделать систему простой в развертывании и администрировании.

    К желаемому результату мы пришли не сразу.

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

    
    

    
    
    Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
    Традиционно различают следующие основные виды кластеров:

    1. Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
    2. Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
    3. Вычислительные кластеры (High performance computing clusters, HPC)
    4. Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.

    Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.

    1С:Предприятие 8.0

    Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».

    
    

    Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
    

    1С:Предприятие 8.1

    В следующей версии мы захотели:

    • Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
    • Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.

    Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.

    На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:

    • rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
    • ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
    • rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).
    Под катом – схема работы этих трёх процессов в составе кластера.

    
    
    

    
    

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

    1С:Предприятие 8.2

    В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.

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

    Отказоустойчивость

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

    Балансировка нагрузки

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

    – серверам присваиваются порядковые номера, первый запрос отправляется на первый сервер, второй запрос – на второй и т. д. до достижения последнего сервера. Следующий запрос направляется на первый сервер и всё начинается с начала. Алгоритм прост в реализации, не требует связи между серверами и неплохо подходит для «легковесных» запросов. Но при балансировке по этому алгоритму не учитывается производительность серверов (которая может быть разной) и текущая загруженность серверов. – усовершенствованный Round-Robin: каждому серверу присваивается весовой коэффициент в соответствии с его производительностью, и сервера с бо́льшим весом обрабатывают больше запросов.
    • Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
    • Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.

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

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

    Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:

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

    Резервирование кластеров

    Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.

    
    

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

    1С:Предприятие 8.3

    В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:

    • Новая настройка кластера «Уровень отказоустойчивости»: число, указывающее, сколько серверов может выйти из строя без последствий в виде аварийного завершения сеансов подключенных пользователей. Исходя из этой настройки кластер будет тратить определённый объём ресурсов на синхронизацию данных между рабочими серверами, чтобы иметь всю необходимую для продолжения работы клиентов информацию на «живых» серверах в случае выхода из строя одного или нескольких серверов.
    • Количество рабочих процессов не задается вручную, как раньше, а автоматически рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
    • Появился ряд настроек, связанных с максимальными объемами памяти, которые разрешается потреблять рабочим процессам, а также настройки, определяющие что делать, если эти объемы превышены:

    
    

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

    
    

    Три звена отказоустойчивости

    Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:

    В заключение

    Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.

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

    Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.

    В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):

    Чтобы ответить на поставленный вопрос, необходимо в принципе разобраться с тем, что такое «автономная конфигурация 1С». Для этого нужно понимать, как происходит работа с информационными базами в системе. После чего можно будет перейти к раскрытию темы статьи.

    Содержание:

    1. Клиентские приложения 1С

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

    
    

    На сегодня применяют несколько клиентских приложений:

    • Конфигуратор,
    • Мобильный клиент,
    • Веб-клиент
    • Тонкий и толстый клиент.

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

    Необходимо отметить, что до появления редакции 8.2 единственное клиентское приложение, которое использовалось продуктами 1С, было Толстый клиент. Для чего применялся файл 1cv8.exe.

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

    Благодаря тонкому клиенту пользователь через приложение может взаимодействовать с системой. Все работы выполняются на самом сервере, сам пользователь видит только итоговую информацию, которая появляется после обработки. За счет этого заметно снижаются требования, предъявляемые к самой системе и каналам связи, ПК необходимо меньше ресурсов для хранения и обработки информации. Таким образом, запуск выполняется одним файлом 1cv8c.exe.

    При сравнении приложений можно выделить следующие моменты:

    -работа по сети может поддерживаться любым клиентом, кроме мобильного, при работе через Интернет может использоваться, как тонкий и мобильный клиент, так в веб;

    -для возможности работать, как с тонким, так и толстым клиентом необходимо выполнить предварительную установку;

    -здесь строго обозначены отличия между размерами используемого дистрибутива;

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

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

    2. Преимущества и недостатки толстого и тонкого клиентов

    В файловом варианте используется уникальная среда, где и выполняются все загрузки, в клиент-серверном все осуществляется за счет протокола TCP/IP. Именно в это и выражается явное преимущество тонкого клиента перед толстым. Однако, данный момент не освобождает от предварительной установки на ПЭВМ клиента.

    
    

    Большой плюс использования толстого клиента заключается в полном исполнении прикладного кода. Хотя этот же фактор является и минусом. Так как для его реализации требуется большой объем дистрибутива. Потому что взаимодействие через интернет не предусмотрено, следовательно, все информационные базы загружаются на ПК.

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

    Есть следующие варианты:

    -Клиент-сервер, используется за счет подключения по локальной сети используя протокол TCP/IP;

    -Файловый, обмен информацией осуществляется через сеть.

    В обоих вариантах возможно взаимодействие с базами данных, расположенных на том же ПК, где расположены кластер или файловая база данных.

    3. Плюсы и минусы других приложений

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

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

    
    

    Веб-клиент отличается тем, что исполняется не на компьютере пользователя, а в интернет-браузерах, таких как Safari, Mozilla Firefox, Google Chrome, Internet Explorer. Соответственно снижаются требования к ресурсам персонального компьютера, к количеству пользователей. Вся работа осуществляется просто запуском браузера. В нем следует ввести адрес web-сервера. После его загрузки происходит доступ к содержащимся там информационным базам.

    Соответственно следует отметить, что не имеет значения какое клиентское приложение используется: веб-клиент, толстый или тонкий клиент, непосредственно разработка прикладного решения производится в конфигураторе 1С: Предприятие 8.3. А серверные и клиентские коды пишутся на встроенном языке 1С: Предприятие 8.

    4. Автономный сервер в 1С

    У данной автономной конфигурации отсутствуют следующие возможности:

    5. Установка АС

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

    
    

    В итоге образуется два файла в каталоге под названием \bin:

    • непосредственно автономный сервер – ibsrv.exe
    • и утилита администрирования – ibcmd.exe.

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

    C:\Program Files\1cv8\8.3.14.1494\bin>ibsrv.exe help

    1C:Enterprise 8.3 Stand-alone Server с 1С-Soft LLC 1996-2020

    Автономный сервер 1С:Предприятия 8

    C:\Program Files\1cv8\8.3.14.1494\bin>ibcmd.exe help

    1C:Enterprise 8.3 Stand-alone Server and Infobase Management Utilite с 1С-Soft LLC 1996-2020

    Инструменты управления автономным сервером и информационной базой 1С:Предприятия 8

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

    6. Запуск АС

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

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

    
    

    В консоли текст конфигурационного файла отразится:

    
    

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

    
    

    В итоге получится:

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

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

    Для это нужна команда:

    Затем через интернет можно посмотреть саму базу:

    localhost:8314/ru_Ru/

    7. Что такое «Пересоздание автономной конфигурации»?

    В 1С на платформе 8.3.16 появилась возможность пересоздания автономной конфигурации. Чтобы осуществить этот процесс, нужно перейти в раздел «Тестирование и исправление». Внизу списка «Проверки и режимы» поставить галочку возле «Пересоздание автономной конфигурации». Затем поставить маркер «Тестирование и исправление», выбрать действия при наличии ссылок на несуществующие объекты и при частичной потере данных объектов. После этого нажать кнопку «Выполнить».

    
    

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

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

    Параметр MobileStandalone был создан для запуска конфигуратора CheckConfig в пакетном режиме. Данный критерий дает возможность проверять конфигурацию для работы в автономной конфигурации.

    Параметр RebuildStandaloneCfg был создан для запуска конфигуратора IBCheckAndRepair в пакетном режиме. Данный критерий дает возможность пересоздать автономную конфигурацию.

    8. Заключение

    Таким образом, создание автономного сервера 1С:Предприятие предоставило возможность обслуживания некоторых клиентских приложений. А именно тех, которые работают с информационными базами через интернет. Для работы такого сервера не требуется выделение веб-сервера. Следовательно, происходит значительная экономия компьютерных ресурсов, в частности, объема памяти и производительной мощности.

    
    

    При этом следует помнить, что

    • один автономный сервер может взаимодействовать только с одной ИБ;
    • управление осуществляется утилитой командной строки;
    • невозможно взаимодействие АС и конфигуратора;
    • при этом возможна работа как с клиент-серверным, так и с файловым вариантами ИБ.

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

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

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

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

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

      
    • Выполнение измерений характеристик кода в среде visual studio практическая работа
      
    • Как сделать в ворде маленькие буквы снизу
      
    • Pycharm typo in word что это
      
    • Настройка bios insydeh20 setup utility
      
    • 1с запрет на проведение документов в 1с