Кластер серверов 1С собрали, базу подключили, пользователи работают. Настройки кластера, рабочего сервера и информационной базы при этом остались ровно такими, какими их создала установка: значения по умолчанию, которые никто не открывал. Это нормальное состояние большинства боевых кластеров, и оно тихо работает до первого инцидента.
Дальше разбор того, что стоит за парой десятков этих значений. Не "какое значение правильное" - на это есть методички вендора, - а что именно происходит на боевой базе, когда значение осталось дефолтным. Каждый пункт я снимал штатным объектом платформы, кое-где переключал настройку туда-обратно и смотрел, что меняется. NDA обязывает: без имён баз, серверов и заказчиков, все числа сняты на своём стенде.
Чем вообще смотреть настройки, не открывая консоль
С версии 8.3.14 у платформы есть объект АдминистрированиеСервера. Он подключается к работающему серверу администрирования (RAS) и отдаёт настройки кластера, серверов, баз и живых процессов - без rac.exe, без COM, без запуска внешних программ. Всё, что показывает консоль кластера, доступно из обычного кода на встроенном языке.
Админка = Новый АдминистрированиеСервера("localhost", 1545); Админка.ВыполнитьАутентификацию(); Кластер = Админка.ПолучитьКластеры()[0]; Кластер.ВыполнитьАутентификацию("", ""); // дальше Кластер.ПолучитьИнформационныеБазы(), .ПолучитьРабочиеСерверы() и так далее
Одна тонкость, которая стоит отдельного прогона: порт нужно передавать вторым параметром конструктора отдельным числом. Если слепить адрес и порт в одну строку - Новый АдминистрированиеСервера("localhost:1545"), - строка целиком уедет в параметр хоста, а порт останется значением по умолчанию (1545). Пока RAS у вас и правда на 1545, вы этого не заметите: подключение пройдёт. А вот если RAS поднят на нестандартном порту, скажем 19999, и вы пишете "localhost:19999" одной строкой - объект всё равно пойдёт на 1545, соединится с тем, что там окажется, и ответит "успех", хотя вы целились совсем в другой кластер. Проверять адрес после этого бесполезно - он всегда живой. Порт вторым параметром объект проверяет честно.
И второе условие: RAS должен быть запущен. Установка платформы его не стартует, сервер 1С живёт без него годами, и тогда любое подключение упирается в отказ соединения. Ставится он службой одной командой, но там есть три места, где легко промахнуться, включая несовпадение версий RAS и кластера, - я разобрал их отдельно во второй части: "Настройка кластера 1С: два диалога консоли и служба RAS". Здесь важно только то, что rac.exe заменой не является (это клиент к RAS), и что код выполняется на сервере 1С, поэтому "localhost" в конструкторе означает сервер приложений, а не машину администратора.
Замер первый: база отдаёт настройки, которых у неё нет
Начал с информационных баз. У объекта АдминистрированиеИнформационнаяБаза десяток свойств, ради которых всё и затевалось: блокировка регламентных заданий, профиль безопасности, резервирование рабочих процессов, разрешение выдачи лицензий. Прочитал их по всем базам кластера, получил таблицу - и таблица оказалась ложью.
По каждой базе выходило, что выдача лицензий сервером запрещена. Пять баз, у всех одинаково запрещена. При этом рядом, в живых сеансах, лежала выданная сервером клиентская лицензия - то есть сервер лицензии выдаёт, а свойство говорит, что нет.
Разгадка простая и неприятная. Расширенные свойства базы кластер отдаёт только тому, кто прошёл аутентификацию администратора этой самой базы. Логина администратора кластера мало. А когда прав не хватает, объект не кидает исключение и не возвращает пусто - он молча отдаёт значение по умолчанию соответствующего типа: Ложь для булева, 0 для числа, пустую строку для строки.
Вот как это выглядит на живой базе. Первый прогон - логином администратора кластера, второй - с логином администратора базы:
// без администратора базы База.РазрешитьВыдачуЛицензий // Ложь <- НЕ факт, а дефолт База.БлокировкаРегламентныхЗаданий // Ложь <- тоже дефолт База.ПользовательБазыДанных // "" <- тоже дефолт // с администратором базы (База.ВыполнитьАутентификацию(логин, пароль)) База.РазрешитьВыдачуЛицензий // Истина <- настоящее значение База.ПользовательБазыДанных // "sa" <- настоящее значение
Инструмент, который читает эти свойства и не знает про аутентификацию, врёт про каждую базу и врёт правдоподобно: таблица заполнена, значения выглядят настоящими, красных строк нет. И это опаснее пустого отчёта: пустой хотя бы виден.
Отличить дефолт от настоящего значения без пароля базы нельзя - оба это просто Ложь. Обходной признак нашёлся один: у клиент-серверной базы паспорт СУБД (тип, сервер, имя базы данных) пустым не бывает никогда. Пустой паспорт означает, что свойства нам не отдали, и тогда честный ответ по такой базе - "нет данных", а не пересказ дефолтов.
Замер второй: единицы, в которых считается память
Короткий, но за него платят дважды. У кластера есть ограничение по памяти рабочего процесса. У рабочего сервера - максимальный объём памяти процессов, критический объём, безопасный расход за вызов. Всё это про память, всё это числа, и соблазн вывести их одинаково велик. Нельзя: единицы разные.
// ограничение по памяти процесса - в КИЛОБАЙТАХ Кластер.ОграничениеПоПамятиПроцесса // 16777216 = 16 ГБ // лимиты памяти рабочего сервера - в БАЙТАХ Сервер.КритическийОбъемПамятиПроцессов // 0 = авто (по докам 95% ОЗУ) Сервер.БезопасныйРасходПамятиЗаОдинВызов // в байтах
Если посчитать лимит процесса как байты, число окажется меньше в тысячу раз, и "16 ГБ" превратятся в "16 МБ". График при этом выглядит совершенно правдоподобно - он просто врёт в 1024 раза. Поэтому единицу в подписи я ставлю только там, где точно знаю, что за числом; где сверить было не с чем, оставляю сырое значение без пересчёта.
Что из этого реально загорается на дефолтном кластере
Пока крутил настройки в обе стороны, накопился короткий список дефолтов, которые бьют больнее прочих. Это не замер распространённости по полю - для него у меня один стенд, а не выборка кластеров. Это разбор того, чем оборачивается каждое из этих значений, если оно осталось таким, каким его создала установка.
Блокировка регламентных заданий, включённая на боевой базе. Свойство булево, включается одной галкой, и его легко забыть после того, как базу разворачивали из копии для теста. Пока оно включено, обмены, отложенное проведение и закрытие месяца просто не выполняются. Ошибки при этом нет нигде: задания стоят в очереди и не запускаются. Узнают об этом в конце месяца, когда сверка не сходится, а времени пересчитывать уже нет. Именно так одна база на моём стенде и оказалась с включённой блокировкой - её когда-то поднимали как тестовую и забыли снять, а в проде такая база выглядит совершенно рабочей.
Профиль безопасности не задан. Если у базы не указан профиль безопасности, любой внешний код, выполняемый в ней, имеет полные права на внешнюю активность: запуск программ на сервере, доступ к файловой системе, COM-объекты, выход в интернет. Для базы, где открывают внешние обработки, это открытая дверь. Дефолт тут - пусто, то есть по умолчанию дверь открыта.
Список администраторов кластера пуст. Это значит, что кластером может управлять любой, кто дотянулся до порта агента по сети, - вплоть до удаления баз. Аутентификация пустым логином, которую я делал в самом первом листинге (Кластер.ВыполнитьАутентификацию("", "")), проходит именно потому, что администраторов нет. На изолированном стенде это удобно, на боевом сервере в общей сети - нет.
Резервирование рабочих процессов выключено при купленной отказоустойчивости. Речь не про резервное копирование, а про горячий резерв: при аварии рабочего процесса сеансы переезжают в заранее поднятый запасной, и человек ничего не замечает. Уровень отказоустойчивости кластера - это число серверов, потерю которых кластер переживёт: ноль означает, что резерва нет, единица - что кластер переживёт падение одного сервера. Обидный случай в том, что на уровне кластера отказоустойчивость включена, ресурсы под резерв выделены и оплачены железом, а у конкретной базы резервирование выключено отдельной галкой. При аварии процесса сеансы этой базы завершатся, вместо того чтобы переехать, - хотя всё для переезда готово. Страховка куплена и не работает именно для той базы, ради которой её покупали.
Каждый из этих пунктов - булево или короткое число, которое видно в консоли. Разница в том, что консоль показывает значение, а вопрос стоит "чем это кончится на моей базе в пятницу вечером".
Отклонённая догадка: "безопасный расход памяти за вызов лечит обрывы"
Это спорная часть, и я выношу её отдельно. У рабочего сервера есть параметр "безопасный расход памяти за один вызов". Значение -1 означает: при достижении лимита памяти любой вызов считается опасным и прерывается. Пользователи ловят обрывы на ровном месте, и первый совет, который приходит в голову, - поднять этот параметр, разрешить вызовам тратить больше.
Догадка была: подкрутить безопасный расход - и обрывы прекратятся. Она неверна, и вот почему. Обрывы происходят не потому, что параметр строгий, а потому, что сервер УЖЕ упёрся в лимит памяти. Безопасный расход - это правило поведения на краю пропасти: он решает, кого сбросить, когда памяти не осталось. Подняв его, вы не добавите памяти, вы только сдвинете момент, когда сброшенным окажется вызов побольше. Симптом уедет, причина - нехватка памяти или то, что копит процесс, которого никогда не перезапускают, - останется.
Оговорка. Значение 0 (по документации платформы это автоматический расчёт от лимита памяти процессов) для большинства баз разумнее и -1, и заданного вручную числа: маленькие вызовы доживают даже при нехватке памяти, крупные прерываются. Но это настройка порога боли, а не лечение. Лечится причина - лимитом памяти под реальный объём ОЗУ и перезапуском процессов, который действительно доезжает до работающих процессов.
Границы применимости
Чтобы никто не унёс отсюда больше, чем здесь есть.
- Всё снято клиент-серверным вариантом. Файловой базе проверять в кластере нечего, речь только про сервер 1С.
- Одна версия платформы. Стенд на 8.3.27, объект
АдминистрированиеСерверадоступен с 8.3.14. Состав свойств между этими версиями слегка менялся: на старых часть полей может не отдаться, и это надо принимать как "нет данных", а не как ошибку. - Стенд, а не прод. Числа сняты на своём кластере, где я мог крутить настройки в обе стороны. На боевом кластере переключать их ради проверки нельзя - смотреть можно, менять нужно понимая последствия.
- Сопоставление настройки перезапуска с возрастом процесса я разобрал по признаку соединений, но не по логам. Утверждение "перезапуск не отработал" верно только для процесса без соединений; на живом кластере эту развилку надо проходить до конца. Сам разбор - во второй части.
- Единицы памяти сервера я подписал по документации платформы, а не сверил с операционной системой. Память процесса rac в другом инструменте сверял с private bytes и совпало ровно; лимиты сервера сверить было не с чем, поэтому доверие к ним - на уровне документации.
Инструмент
Проверки из этого разбора собраны в отдельную обработку "Чек-ап сервера 1С: настройки кластера и рабочих процессов". Она подключается к RAS сама, снимает пять разделов настроек (кластер, рабочие серверы, информационные базы, сервисы и ресурсы, живые процессы) и по каждой печатает не значение, а последствие: не "резервирование = Ложь", а "при аварии процесса сеансы этой базы завершатся, а не переедут". Про аутентификацию баз из первого замера она знает: без пароля администратора базы честно пишет "нужен администратор этой базы", а не пересказывает дефолты. Про RAS она помнит: при отказе соединения статус направит на .bat из комплекта, который ставит RAS службой. Инструмент лежит в Чек-ап сервера 1С: настройки кластера и рабочих процессов, менять в кластере он ничего не умеет принципиально - только читает и объясняет.
Если руками, то минимальный маршрут такой. Подключиться объектом АдминистрированиеСервера, пройти в интересующую базу с её администратором, прочитать десяток свойств и на каждое ответить себе вопросом "а что это значит на моей базе, если пользователей триста и закрытие месяца в пятницу". Тот же маршрут, но с готовыми формулировками последствий и проверкой обоих исходов каждого вердикта - это Чек-ап сервера 1С: настройки кластера и рабочих процессов.
Вторая часть разбора - про то, что вписывать в поля консоли и как поднять RAS, если его нет: "Настройка кластера 1С: два диалога консоли и служба RAS".
Вопрос к тем, кто дочитал
Откройте у своей боевой базы два числа: настроенный период перезапуска рабочих процессов и время запуска самого старого живого процесса. Если процесс старше периода, посмотрите, есть ли на нём ещё живые соединения. Нет - перезапуск у вас не отрабатывает, и вопрос только в том, сколько дней уже копится то, что должно было обнуляться.
И второй, для тех, кто уверен, что у него всё настроено правильно: когда вы в последний раз читали свойства базы из-под её собственного администратора, а не из консоли под общим логином? Потому что консоль показывает то же самое, что и обработка без пароля, - и часть того, что вы там видите, может оказаться дефолтом, а не вашей настройкой.
Вступайте в нашу телеграмм-группу Инфостарт