Ошибка запуска процесса менеджера кластера 1с

Решение возможных проблем с установкой

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

В случае выбора существующей учетной записи вы должны указать правильный пароль и подтверждение, иначе запуск серверной части далее приведет к ошибке.
При первом запуске Агента кластера создается кластер «по умолчанию».
Кластер по умолчанию имеет следующие характеристики:
·         номер порта – 1541;
·         диапазон IP портов – 1560:1591;
·         поддержка многих рабочих процессов – выключена;
·         один  рабочий  процесс, номер  порта устанавливается из указанного диапазона.
Если при первом запуске агента кластера возникли какие-либо проблемы, то кластер по умолчанию может быть не создан. Это проявляется в том, что при запуске агента сервера (ragent) он стартует, но не запускает другие процессы кластера (rmngr, rphost). Список кластеров srvribrg.lst при этом выглядит так:
{
{0},
В этом случае можно остановить процесс ragent, удалить список кластеров (srvribrg.lst) и запустить ragent снова.

Проверьте совпадение портов, указанного в параметре port командной строки запуска сервиса агента сервера и заданного в диалоге параметров центрального сервера консоли кластеров:

— Остановите сервис 1C:Enterprise 8.1 Server Agent.

Если Агент серверов запущен как приложение, остановка выполняется нажатием комбинации клавиш Ctrl+C.
— Убедитесь, в Диспетчере задач (Task Manager), что все процессы ragent, rmngr, rphost завершились. При необходимости завершите их при помощи Task Manager.

— Откройте свойства сервиса 1C:Enterprise 8.1 Server Agent.

— Обратите внимание на строку «Исполняемый файл» ( Path to executable). В ней имеется параметр -d, за которым следует каталог данных кластера. Все файлы, относящиеся к кластеру, находятся в этом каталоге.
— Удалите все содержимое этого каталога.
— Запустите сервис 1C:Enterprise 8.1 Server Agent.
— Убедитесь, в Диспетчере задач (Task Manager), что все процессы ragent, rmngr, rphost стартовали.
— Запустите консоль кластера и зарегистрируйте в ней центральный сервер. Консоль должна подсоединиться к центральному серверу и показать один кластер, созданный по умолчанию.
Возможными проблемы отказа работы Кластера серверов являются проблемы с ключами защиты, правами учетной записи служб, некорректными параметрами запуска.

1. Ключ защиты серверной части устанавливается ЛОКАЛЬНО на каждый сервер предприятия
2. Не задавайте учетную запись службы с пустым паролем
3. При нескольких кластерах используемые порты не должны пересекаться

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

Ошибка 1069: служба не запущена из-за ошибки входа в систему

Проблема связана с правами учетной записи на запуск от имени системной службы. Откройте утилиту Local Security Policy (Локальная политика безопасности) и добавьте пользователя (от имени которого происходит запуск Рабочих серверов Кластера) к политикам Logon as service (Работа в качестве сервиса) и Logon as batch (Работа в качестве пакетного задания) job.
При нарушении данных, хранящихся в служебных файлах,  и  запуск Рабочих серверов Кластера может оказаться неудачным. Убедитесь, что агент сервера 1С:Предприятия 8.1 запущен (процесс ragent в Task Manager).
Не забудьте, что средством анализа также является  аудит событий Windows. Для этого посмотрите, появляются ли какие-нибудь «подозрительные» сообщения в журнале событий Windows.

Ошибка 8007056B / 800708C5

The new password does not meet the password policies. The password may be too short or you have already used this password recently.
Причина: указанный пароль для учетной записи в диалоговом окне «Установка сервера 1С:Предприятие» не удовлетворяет требованиям политики безопасности.
Решение: Задать новый пароль для выбранной учетной записи, удовлетворяющий требованиям политики безопасности либо ослабить требования применяемой политики безопасности, т.е. не требовать «сложного» пароля, не ограничивать количество знаков в пароле, не проверять попыток повторения и т.д.

Ошибка 1923: нет привилегий для установки сервисом

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

Ошибка 80070056

Your password could not be changed. Each password must be used for at least x days.
Причина и Решение: Еще одна ошибка, возникающая при нарушении требований политики безопасности к используемым паролям. Решение аналогично ошибке 800708C5.

Windows Sockets — 11004(0х00002AFC)

1) Убедиться, что на Рабочем сервере кластера в Диспетчере задач (Task Manager) запущены :
Агент сервера (ragent.exe),
Менеджер Кластера (rmngr.exe),
Рабочий процесс Кластера (rphost.exe).
2) Для проверки разрешения имен  ip-адреса выполните в командной строке:
ping имя_машины
В отклике системы на команду нас интересует, определиться ли ip-адрес.
3) Если имя определилось, но Рабочий процесс по-прежнему не находится, то убедитесь, что определение Ip-адреса имени <имя машины> и <имя машины>.<имя домена> определяются не по-разному.

(Windows Sockets — 10054(0x00002746).

Удаленный хост принудительно разорвал соединение.
Такое сообщение может быть получено в случае перезагрузки сервера или принудительного удаления Рабочего процесса.
Эта ошибка обычно не появляется при повторном подключении. Если ошибка осталась, необходимо расследовать причины отказа рабочих серверов кластера.
Такая ошибка может происходить при достижении рабочим процессом использования максимального объема памяти в 32х битных системах.
Другим случаем является попытка подключения от клиента с сообщением об ошибке:

 (Windows Sockets — 10060(0x0000274C)

Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера.
Сущность этой ошибки – отсутствие отклика в течении определенного времени (таймаута).
1) Убедитесь, что брандмауэр не блокирует трафик приложения. Выключите брандмауэр.
Для этого в командной строке выполните команду (команда доступна начиная с Windows XP и Windows Server 2003, в более ранних версиях встроенного брандмауэра нет, однако может быть установлено стороннее ПО):
netsh firewall set opmode disable
Если команда будет выполнена успешно, вы получите сообщение:
Ок.
Кроме брандмауэра блокировать трафик могут сетевые фильтры. Они по умолчанию выключены. Тем не менее, убедитесь, что это так:

1. Откройте папку «Сетевые подключения».
2. Щелкните правой кнопкой мыши сетевое подключение, которое требуется настроить, и выберите команду Свойства.
3. На вкладке Общие (для подключения по локальной сети) или на вкладке Сеть (для всех остальных подключений) выберите Протокол Интернета (TCP/IP) и нажмите кнопку Свойства.
4. Нажмите кнопку Дополнительно.
5. Откройте вкладку Параметры, выберите параметр Фильтрация TCP/IP и нажмите кнопку Свойства.
6. Убедитесь,  что флажок Задействовать фильтрацию TCP/IP (все адаптеры) снят.

2) Убедитесь, что ресурсы процессора не загружены на 100% (CPU%).
3) Выполните замер сетевой активности интерфейсов клиента и сервера. Нагрузка на сетевой адаптер не должна превышать 60%.

(Windows Sockets — 10061(0x0000274D)

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

 Ответы на вопросы

Многоплатформенность 1С

Ответ тут.

Установка сервера

Q:Ошибка установки сервера 1с на MS Server 2008 R2 x64 При установке сервера 1с через командную строку, например такую, ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d «C:Program Files1cv82 (взято с диска ИТС), в командной строке пишет сообшение: «Error! OpenSCManager error!» Сервис при этом не создается. Проверялось на 8.1.15.14 и 8.2.10.77

А: Для установки из коммандной строки на ОС, где присутсвует UAC, нужно пользоваться службой RunAs, т.к. даже если пользователь входит в группу администраторов, то UAC блокирует действия, которые изменяют состояние системы.

Ключи защиты

Q: Ключ защиты от сервера 8.2 позволяет запустить Сервер 8.1?
A: Да, позволяет

Q: чтобы запустить сервер 1С мне нужны хасп-ключи какие-то серверные? Локальный, или на 5 пользователей не пойдет?

A: да, для сервера нужен свой ключ, локальный пользовательский и сетевые не подойдут. Подробнее в «Сервера 1С:Предпряитие 8.1 и 8.2 — с чем едят« , слайд № 30.

Q: допустим кластер серверов 1с стоит из 3-х физических серверов. сколько нужно ключей защиты

A: 3 ключа

Q: Имеется терминальный сервер и ключ на 5 лицензий, докупается 6-ая доп. лицензия. Возможно ли ее установить на сервер рядом с ключом на 5? И будут ли все 6 пользователей работать в теминальных сессиях или 5 — под теерминалом, а 1 в файловом варианте?
A: Нет, не будут. 6я лицензия в виде локального ключа должна быть воткнута в компьютер пользователя, но не в терминалку.

Подробней см. «Ключи защиты 1С:Предприятие 8«.

Обновления сервера 1С

Q: при выходе новой версии 8.2.xxx платформы какой порядок действий при обновлении серверов и клиентов
A: Дистрибутивы 8.2 инсталируют свои файлы в разные папки (для каждой версии своя папки), т.е. теоретически остается возможность вызова параллельно нескольких версий сервера.

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

Настройка сервера 1С

Q: В 1С 8.1, как лучше размещать информационные базы, если их несколько, в одном кластере или создавать для каждой базы отдельный кластер? A: С большим объем или нагрузкой , а также тестовые базы размещать нужно в отдельные кластера!

Q: ВОПРОС: Рабочй процесс 1С:Предприятие 8.1 является однопоточным приложением или многопоточным? Т.е. может ли загрузить много ядер при одном подключенном пользователе? При нескольких? А рабочий процесс 1С:Предприятие 8.2? Спасибо.
A: 1Сv8.exe и rphost.exe в версии 8.1 отъедали 1 ядро. По сколько в 8.1 соединение клиента находится жестко привязанным к рабочему процессу, то можно условно считать, что обработка клиентов 1С выполняется в рамках одного ядра. Исключение составляет СУБД, которая использует ядра не зависимо, как работает сервера 1С.

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

платформа 8.2 не реализует всех возмжностей многопоточной системы, но она существенно лучше использует возможности железа по сравнению с 8.1, в том числе и в плане параллельности.

Q: Необходимо ли несколько рабочих процессов 1С:Предприятие 8.1, чтобы сервер баз данных (MS SQL) нагружал несколько ядер? (Замечено, что MS SQL обычно «грузит» только одно ядро, т.е. «распараллеливание» обработки одного запроса по нескольким ядрам, как правило, не происходит.) Спасибо.
A: Специально управлять MS SQL не нужно, это достаточно самонастраивающая система, использующая ресурсы по необходимости. Управлять параллельностью исполнения можно:

EXEC sys.sp_configure N’max degree of parallelism’, N’5′
GO
RECONFIGURE WITH OVERRIDE
GO

Создавать несколько рабочих процессов на сервере 1С можно исходя из того, что один рабочий процесс не обеспечивает возможность пользователям сделать повторное подключение в случаи падения рабочего процесса. 2 процесс (на 8.2 его лучше сделать «резервным») решает эту проблему. А вот 3й и более рабочие процессы есть смысл добавлять, только если сильно загруженны (более 90%) первые два рабочих процессах. Без надобности плодить рабочие процессы не стоит, это может ухудшить производительность.

Q: Для 1С:Предприятие 8.1 прозвучала рекомендация использовать минимум
два рабочих процесса на сервере (для отказоустойчивости) или больше, если
это обусловлено загрузкой и количеством ядер. Справедливо ли это для 8.2?

A: Как минимум 1 резервный рабочий процесс в 8.2 должен быть.

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

Q: Вопрос про включении резервирования кластеров 1с 8.2. Если у нас упал сервер (уборщица выдернула провод) то сетевое имя, например «server:2540» будет недоступно. как клиент, у которого прописано в строке подключения «server:2540» узнает что нужно подключаться к резервному кластеру? откуда он возмет имя другого сервера? А если через запятую написать кластеры в строке подключения базы?
A: Несколько кластеров объединяются в «группу резервирования». Для этого в оснастке кластера есть «список резервирнования».

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

Если клиент не разу не обращался, то в этом случаи надо указать вручную адреса всех кластеров, например storm:2541,monster:2541.

Между кластерами резервирования осуществляется обмен синхронизируемых данных.

Q: Что происходит после восстановления работы основного кластера? когда пользователи переключились на резервный .

A: Возвращаются назад. Возможны паузы при переключениях на время синхронизации данных кластеров.

Фоновые задания

Q: Как удалить фоновое задание, запущенное на серверах 1С:8.1 и 1С:8.2?

A: Возможность отмены регламентного задания работает только, если код выполняется в пределах встроенного языка 1С:Предприятия. Если код выполняется во внешних библиотеках, то отменить такое задания нельзя иначе, как принудительно завершив рабочий процесс. Если в процессе блок НачатьТранзакцию() — ЗафиксироватьТранзакцию() то вряд ли. Остальные фоновые задания можно удалить через консоль заданий.

Регламентные процедуры

Q: Возможно ли разрушение базы при проведении ТиИ?

A: Мне такие случаи неизвестны, но имхо возможно все. Поэтому перед ТиИ неплохо бы делать бэкап.

Q: Вячеслав, по каким причинам вы не делаете реиндексацию средствами 1С Тестирование и Исправление?
A: Для этих целей лучше подходят возможности СУБД, так как они посути выполняют тоже перестроение индексов, но не требуют монопольного захвата базы.

Технологический журнал

Q: Добрый день. Вопрос по технологическому журналу: мне необходимо получать копии экранов рабочих станций при ошибках 1С. Нужно ли для этого настраивать технологический журнал и на рабочих станциях, либо же он только для сервера?
A: Можно настроить только получение скриншота при падении платформы, а не при любой ошибки. Впрочем, особой полезности в такой операции не много, вполне достаточно собирать с помощью технологического журнала исключительных ситуаций. При этом, большую часть ошибок можно увидеть с помощюю ТЖ на стороне сервера 1С. Исключение могут составить события вроде «ошибки потока формата», связанной с устаревшим кэшем метаданных.

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

Неполадки и ошибки

Q: Сталкивались ли вы с проблемой — пропадание настроек отчетов у пользователей при динамическом обновлении конфигураций на платформе 8.2. Есть рекомендации, как с этим бороться?
A: Проблемы связанные с динамическим обновлением отражены в «Сервера 1С:Предпряитие 8.1 и 8.2 — с чем едят«), слайд №60. Чистить кэш. Возможно в некоторых случаях надо разбираться, где конкретно храняться настройки пользователей. При необходимости хранить в качестве двоичных данных в регистре сведений.

И чистить кэш метаданных.

Q: Можно ли изменить путь кэша метаданных? Если да, то каким образом. Спасибо!
A: С помощью групповых политик (gpedit.msc) можно переопределить путь профиля пользователя целиком (не только кэш метаданных).

Или воспользоваться внешней утилитой http://infostart.ru/public/15986/.

Q: Попутный вопрос, т.к. это актуально для файлового режима: какие ошибки исправляет chdbfl.exe?
A: Это инструмент исправления ошибок структуры хранения данных. Это может быть ситуация когда например возникает «Файл базы данных поврежден …/1Cv8.1CD». Т.е. устраняет повреждения файла базы данных. Однако не выполняет функций ТиИ. Я запускаю chdbfl.exe, если «не продит успешно» ТиИ.

Q: Подскажите пожалуйста сталкнулись с такой проблемой. при нахождении в базе большого количества пользователей (около 40) при проведении больших документов например отражение ЗП в регл. учете около 8000 строк. выдается ошибка нехватает памяти на сервере 1С предприятия и пользователь инициировавший проведение этого документа отваливается. Документ потом можно провести только после перезапуска агента 1С сервера.
A: Похоже на утечки памяти:

1. Рестартовать сервер 1С, увеличить количество рабочих процессов, в кластере держать только одну эту базу.

2. Бить проведение на порции, скажем по 1000 строк за раз. Отследить с помощью ТЖ объекты занимающие память при начале операции, но не освобождающие память по завершению.

3. Поставить х64 версию, увеличить объем оперативки, перейти на 8.2.

Q: Вопрос по тестированию и справлению. Можно ли запускать «Проверка ссылочной целостности» на базе УРБД с отбором по передаваемым данным? (т.е. в некоторых узлах физически отсутствуют объекты, но ссылки на них есть). Спасибо!
A: К сожалению, пока такой возможности нет.

Q: Почему тестирование и исправление сразу не решает все вопросы, приходится запускать несколько раз?

A: Точно ответить могут только разработчики. Я запускаю ТиИ по регламенту (циклически), поэтому для меня этот вопрос не очень актуален. Делать ТиИ надо не один раз, а постоянно как «ТО для автомобиля».

Q: Есть ли разница ТиИ 8.1 и 8.2?

A: На текущий момент написания ответа и релиза 8.2.10 мне разница не известна.

Q: Нужно ли при реструктуризации делать реиндексацию?
A: Не нужно.

Прочее

Q: Уважаемы господа никто не пробовал зеркалировать базы средствами MSSql 2008 вообще это возможно ?

A: Нет, рекомендую использовать штатные средства 1С:Предприятие.

Q: Вопрос по принудительному включению shared memory на сервере 1с 8.2

A: Не надо ничего принудительно включать, сервер сам поймет.

Q: Для 1С:Предприятие 8.1 замечены ситуации, когда на одном и том же аппаратном обеспечении файл-серверный вариант с «тяжелыми» операциями и единственным пользователем работает значительно быстрее, чем клиент-серверный, когда все «звенья» (сервер БД, сервер 1С:Предприятие и клиент) установлены на одном сервере. При этом при выполнении этой «тяжелой» операции явно выраженных перегрузок аппаратной части нет (загрузка процессора, памяти, жестких дисков минимальная). То есть аппаратных ресурсов много, а работает медленно. Во что же мы можем «упираться»? Спасибо.
A: Достоинство клиент-серверной архитектуры с точки зрения производительности — возможность ПАРАЛЛЕЛЬНО обрабатывать запросы клиентов к данным. Т.е. скорость потока не тот показатель, по которому стоит делать общие выводы. Механизмы, улучшающие параллельность, все же в рамках одного потока могут несильно снижать производительность.

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

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

Q: О разнице между виндовским терминалом и тонким клиентом 1С.
A: Пока большинство решений не переведы ПОЛНОСТЬЮ под 8.2, говорить о практическом сравнении этих технологий однозначно сложно.

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

Для консервативных прагматичных руководителей проектов, конвертирующих 8.1 под 8.2- терминальное решение. Для небольших проектов с низкой стоимостью ошибок и конфигурацией сразу реализованной с управляемыми формами и СКД — тонкий клиент предпочтительней ИМХО.

Q: А как провести нагрузочное тестирование приближённое к реальным условиям? Ведь не загонишь пользователей «пощёлкать что-то».

A: 1С:Тестцентр с выбором наиболее тяжелых операций, 100% воспроизведение не обязательно, сами щелчки не тяжелы, в основном проведение и запросы отчетов. По тестированию будет отдельный вебинар. Также подробней расказываю на курсах.

Q: Не планируете ли Ваш оффлайн курс по скл в виде вебинара?
A: На текущий момент нет уверенности, что будет восстребован. Если будет получено достаточно большое количество заявок на участие в таком мероприятии, то сделать то несложно.

Одновременное использование 1С

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

И тем не менее можно сделать одновременный запуск серверов 8.2 разных версий так:

Автор Rasty, 23 ноя 2015, 14:21

0 Пользователей и 1 гость просматривают эту тему.

Время прочтения
12 мин

Просмотры 53K

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

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

Требуется:

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

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

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

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

Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «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.0.

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

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

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

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

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

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

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

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

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

Механизм работает так. Если клиентский вызов к рабочему процессу по какой-то причине не смог исполниться до конца, то клиентская часть способна, получив ошибку вызова, этот вызов повторить, переустановив соединение с тем же рабочим процессом или с другим. Но повторять вызов можно не всегда; повтор вызова означает, что мы отправили вызов на сервер, а результата не получили. Мы стараемся повторить вызов, при этом при выполнении повторного вызова мы оцениваем, каков результат на сервере был у предшествующего вызова (информация об этом сохраняется на сервере в данных сеанса), потому что если вызов успел там «наследить» (закрыть транзакцию, сохранить сеансовые данные и т.п.) – то просто так повторять его нельзя, это приведет к рассогласованию данных. Если повторять вызов нельзя, клиент получит сообщение о неисправимой ошибке, и клиентское приложение придется перезапустить. Если же вызов «наследить» не успел (а это наиболее частая ситуация, т.к. многие вызовы не меняют данных, например, отчеты, отображение данных на форме и т.п., а те, которые меняют данные – пока транзакция не зафиксирована или пока изменение сеансовых данных не отправлено в менеджер – следов вызов не оставил) — его можно повторить без риска рассогласования данных. Если рабочий процесс упал или произошел обрыв сетевого соединения – такой вызов повторяется, и эта «катастрофа» для клиентского приложения происходит полностью незаметно.

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

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

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

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

Для нашего кластера мы выбрали алгоритм, близкий по сути к Least Response Time. У нас есть механизм, собирающий статистику производительности рабочих процессов на всех серверах кластера. Он делает эталонный вызов каждого процесса сервера в кластере; эталонный вызов задействует некоторое подмножество функций дисковой подсистемы, памяти, процессора, и оценивает, насколько быстро выполняется такой вызов. Результат этих измерений, усредненный за последние 10 минут, является критерием — какой сервер в кластере является наиболее производительным и предпочтительным для отправки к нему клиентских соединений в данный период времени. Запросы клиентов распределяются таким образом, чтобы получше нагрузить наиболее производительный сервер – грузят того, кто везет.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Связь между клиентом, работающим по HTTP(S), и веб-сервером. В случае веб-клиента этот механизм стандартно реализуется веб-технологиями. В случае тонкого клиента, работающего по HTTP с веб-сервером, или мобильного клиента (мобильный клиент всегда работает по HTTP) мы используем библиотеку libcurl с открытым исходным кодом.
2. Отслеживание разрывов соединений, механизм балансировки нагрузки и механизм повторов вызовов позволяют как можно раньше узнать о возникшей проблеме и предпринять действия по её устранению.
3. Связь между ТСР-клиентом и рабочим процессом. Клиентом ТСР может выступать либо клиент 1С, либо расширение веб-сервера при работе клиента через НТТР. При выполнении каждого НТТР-вызова происходит выбор наиболее подходящего соединения с рабочим процессом и отправка этого вызова. Наиболее подходящее соединение выбирается исходя из того, в какой рабочий процесс отправлялся предыдущий вызов данного клиента. Если следующий вызов клиента можно отправить в тот же рабочий процесс, куда ушел предыдущий вызов – мы так и поступаем. Только если по какой-то причине в данный рабочий процесс вызов отправить нельзя (потому, что рабочий процесс стал недоступен, либо мы знаем, что есть другой рабочий процесс с существенно лучшей производительностью) – мы отправляем новый клиентский вызов в более подходящий рабочий процесс.
4. Связь между рабочими процессами сервисами кластера, реализованными в процессах rmngr. Сервисов кластера около 20 (в зависимости от версии платформы) — сервис сеансовых данных, сервис транзакционных блокировок и т.д. На этом уровне существенную роль играют механизм распределения сервисов по серверам и репликация данных сервисов кластера. Балансировка нагрузки на уровне 1С:Предприятия позволяет получать приблизительно одинаковую лучшую производительность от всех рабочих серверов.

В заключение

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

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

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

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

• Настройки безопасности, ограничивающие прикладному решению потенциально опасные для функционирования кластера операции. Например, можно ограничить доступ к файловой системе сервера или запретить прикладному решению запускать приложения, установленные на сервере.
• Требования назначения функциональности – механизм, позволяющий администратору указать, какие сервисы кластера, прикладные решения (или даже отдельные функции прикладных решений – отчёты, фоновые и регламентные задания и т.д.) должны работать на каждом из серверов. Например, если заранее известно, что с конкретным прикладным решением (например, бухгалтерией) будет работать существенно меньше пользователей, чем с ERP, возможно, имеет смысл настроить более мощный сервер на работу исключительно с ERP.
• Управление потреблением ресурсов – механизм, отслеживающий потребление кластером ресурсов (память, процессорное время, вызовы СУБД и т.д.). Он позволяет, в частности, выставлять пользователям квоты ресурсов, которые они не могут превысить, и прерывать операции, выполнение которых влияет на производительность сервера в целом.