1️⃣🔤 Неправильные подходы к отказоустойчивости кластера 1С со стороны клиентского подключения

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

Сценарий будет очень простым: есть два боевых сервера 1С, оба центральные + сервер 1С с ТНФ - Сервис лицензирования - Назначать (будем называть его Сервером лицензирования, хоть это и неправильно), хотим из них сделать отказоустойчивый кластер 1С.
Уровень отказоустойчивости в кластере = 1.

▫️Первый вариант - DNS.
Берём и прописываем IP адреса обоих Центральных серверов 1С под одним DNS-именем.
Например: Server1c - 192.168.0.1, 192.168.0.2
И соответственно в стартере 1С прописываем: Srvr="server1c";Ref="erp";

Казалось бы - всё прекрасно, и действительно - всё работает!
НО, до того момента пока "живы" оба наших Центральных сервера 1С,
Когда же выйдет из строя или просто станет недоступен по сети один из серверов, то пользователи начнут в случайном порядке получать ошибки работы в 1С (кто в ней уже был) и ошибки входа в 1С.
Так как DNS не анализирует доступность IP адресов, а просто выдаёт их по запросу в случайном порядке, а операционная система берёт первый из выданных адресов и пытается обратиться по нему, не пытаясь перебирать эти адреса.

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

▫️Второй вариант - разные proxy (nginx, haproxy, citrix и т.д.).
Тут в целом очень похоже на первый вариант, но немного сложнее.
Сложность в том что proxy подменяют IP адреса наших Центральных серверов 1С своим IP адресом.
И мы получаем, что клиент 1С общается с сервером 1С не по прямому IP что помимо задержек в общении может приводить вообще к неработоспособности 1С с очень "волшебными" ошибками сетевой недоступности серверов 1С.

Основная мысль в том, что не надо ничем заменять встроенную в Лучшую в мире платформу 1С отказоустойчивость!

А как же тогда правильно делать отказоустойчивость со стороны клиентского подключения?

Всё очень просто - нужно в адресе базы указать два наших центральных сервера: Srvr="server1c-1,server1c-2";Ref="erp";
При такой настройке сам клиент 1С, будет им Тонкий или Толстый клиент, либо Веб-браузер обратится сначала к server1c-1 для подключения и если он недоступен, то к server1c-2.

❗️При этом это не означает, что теперь все клиенты будут работать на server1c-1, просто сами подключения будут приниматься этим сервером и дальше уже назначаться на рабочие сервера и процессы согласно механике кластера 1С.

Напоминаю, что резервная копия канала есть в MAX.

1️⃣🔤 По предыдущему посту поступил сразу от нескольких подписчиков вопрос:

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

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

Но мало кто замечает что снизу справа есть кнопка Ещё, а там галка "Проверять имя сервера".
❗️Так вот, при работе в кластере с несколькими центральными серверами 1С эту галку нужно снять.

Хорошо, сделали, но тогда возникает следующий вопрос: Что делать когда мы действительно восстановили базу в тестовую среду или среду разработки?
Ведь теперь у нас не будет задан такой вопрос и мы не отключим опасные регламенты!

Отвечаю: на средах разработки и тестирования, да и вообще при любом случае создания копии рабочей базы, она должна быть зарегистрирована в кластере 1С с установленной в ОБЯЗАТЕЛЬНОМ порядке галкой "Блокировка регламентных заданий включена" в свойствах базы в кластере 1С.

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

Ну а если всё таки вам необходимо какие-то из них включить, то сначала нужно в самой базе выключить все ненужные регламенты, оставить только нужные.
Затем из нужных надо отключить опасные, которые являются заданиями интеграции.
Проанализировать эти опасные операции, поменять все адреса на тестовые и только потом включить обратно это регламентное.
❗️И после того как вы точно уверены что с этой копии базы никакие данные никуда не полетят в ненужном направлении можно снять в свойствах базы галку "Блокировка регламентных заданий включена".

1️⃣🔤 Нужно ли менять параметры ограничения потребления оперативной памяти Рабочим сервером 1С и если нужно, то в каких случаях?

Что это за параметры:
▫️Безопасный расход памяти за один вызов (КОРП)
▫️Критический объём памяти процессов (ПРОФ)
▫️Временно допустимый объём памяти процессов (ПРОФ)
▫️Интервал превышения допустимого объём памяти (ПРОФ)

Значения по умолчанию:
▫️Безопасный расход памяти за один вызов = 0 (10% от Временно допустимого объёма памяти процессов)
▫️Критический объём памяти процессов = 0 (95% от объёма памяти в ОС)
▫️Временно допустимый объём памяти процессов = 0 (80% от объёма памяти в ОС)
▫️Интервал превышения допустимого объём памяти = 300 сек

❗️Объём памяти в ОС считывается только один раз при старте службы 1С и затем не обновляется. Это очень важно понимать в случае работы с виртуализацией - крайне не рекомендую работать с динамическим объёмом оперативной памяти ОС или менять её объём "налету" без перезапуска службы 1С.

Когда стоит оставить настройки по умолчанию?
Если у вас в Операционной системе кроме сервера 1С больше ничего не работает и соответственно не потребляет большой (более 5%) оперативной памяти ОС.

Когда стоит менять значения по умолчанию?
Если у вас есть другие потребители большого объёма оперативной памяти на этой же ОС.

Например на одной ОС у нас работают:
▫️Сервер 1С и сервер СУБД
▫️Несколько служб 1С
▫️Несколько кластеров в одной службе 1С

На какие значения менять?
Тут всё достаточно просто и сложно одновременно))

Из простого:
Лучше всего соблюсти те же пропорции параметров Критического и Временного объёма от оперативной памяти ОС для этой службы/этого кластера 1С что и по умолчанию, т.е. 80% и 95%

Из сложного:
Определить какой объём памяти ОС вы выделяете службе/кластеру 1С.

Рассмотрим на простом примере "Сервер 1С и сервер СУБД на одной ОС"
Если мы можем ограничить сервер СУБД в потреблении оперативной памяти (в случае с MS SQL), то тогда -
Память для 1С = Память ОС - Память для SQL
Допустим у нас на ОС 128ГБ, серверу СУБД мы выделили 48ГБ, тогда Память для 1С = 80ГБ

Соответственно устанавливаем:
▫️Критический объём памяти процессов = 0 (95% от объёма Память для 1С), в нашем примере это 76ГБ
▫️Временно допустимый объём памяти процессов = 0 (80% от объёма Память для 1С), в нашем примере это 64ГБ
▫️Безопасный расход памяти за один вызов = 0, я не вижу особого смысла трогать этот параметр. так как он зависит от Временно допустимого объёма памяти процессов

Если же у нас вариант, когда на одной ОС несколько служб 1С или внутри одной службы несколько кластеров 1С, то тут только вы сами можете определить какой объём оперативной памяти вы выделяете каждой службе/кластер 1С и уже от этого значения посчитать %% для Критического и Временного ограничений.

У нас остался ещё один параметр "Интервал превышения допустимого объём памяти".
Этот параметр стоит менять только если ваш сценарий использования 1С подразумевает более долгое чем на 5 минут превышение 80% оперативной памяти и при этом оно не достигает 95%, тогда смело меняйте этот параметр в бОльшую сторону.

Что будет, если "побочный" потребитель оперативной памяти есть, а мы не учли это в настройках?
❗️Возможна ситуация, полной остановки ОС или прихода OOMKiler в случае Linux, например когда кто-то запустил в 1С процедуру с огромным потреблением оперативной памяти.
Кластер 1С не сможет вовремя защитить себя и ОС от перерасхода оперативки, так как не знает что она уже кончилась считая что вся оперативка ОС была отдана ему одному.

🔤🔤🔤 Журнал транзакций в PostgreSQL и MS SQL

Во время обучения по PostgreSQL часто встречаю заблуждения по поводу лога транзакций (в PostgreSQL это Журнал предзаписи (Write-Ahead Logging) - что гораздо точнее отражает его суть.

Давайте попробуем прояснить главные отличия этого механизма у двух СУБД.

1. Как хранится журнал транзакций
MS SQL - по умолчанию хранит в одном файле на каждую базу
PostgreSQL - по умолчанию хранится в файлах по 16МБ на весь сервер

2. Нужен ли журнал транзакций для "отката" транзакции
MS SQL - да
PostgreSQL - нет

❗️Тут давайте остановимся чуть подробнее.
"Откат" транзакции в MS SQL происходит с помощью чтения Журнала транзакций с момента начала "отката" до момента начала транзакции в обратном хронологическом порядке и в базе "отыгрываются" все произведённые этой транзакцией изменения.
Соответственно, чтобы обеспечить возможность "отката" транзакции СУБД обязана сохранять весь журнал транзакций с момента её начала.
Из-за этого в MS SQL журнал может неожиданно неконтролируемо вырасти и либо занять всё место на диске либо упереться в максимальный размер файла, заданный в настройках базы.

"Откат" транзакции в PostgreSQL происходит путём смены одного бита в служебной таблице pg_xact, где для каждой транзакции есть запись со статусом committed или aborted.
Поэтому "откат" транзакции в PostgreSQL происходит мгновенно и не требует хранения журнала транзакций (WAL).
Соответственно и роста каталога с WAL по причине долгой транзакции происходить не может.

3. На что влияет операция checkpoint
MS SQL - именно эта операция делает сброс всех "изменённых" страниц с кэша в базу и ставит "метку" в файле Журнала транзакций об этом факте. Теперь журнал транзакций "левее" этой метки может быть заархивирован либо перезаписан новыми данными. (Если нет реплик)
PostgreSQL - Так же делает сброс всех "изменённых" страниц с кэша в базу и ставит "метку" в файле Журнала транзакций об этом факте. Теперь файлы в каталоге с WAL "левее" этой метки могут быть заархивированы либо удалены. (Если нет реплик)

4. Реплики и их влияние на журнал транзакций
MS SQL - будет сохранять журнал пока реплика его весь не заберёт себе. В случае если журнал прирастает быстрее чем его забирает реплика может произойти переполнение диска или максимального размера журнала транзакций и остановка сервера СУБД
PostgreSQL - будет сохранять файлы журнала предзаписи пока реплика созданная со слотом репликации не заберет себе эти файлы. Помним что файлы по 16 МБ, т.е. они и удаляться будут постоянно со скоростью, с которой реплика успевает их себе забрать.
Таким образом даже если общий объём журнала предзаписи за промежуток времени превышает объём диска по WAL, то всё равно место скорее всего не закончится.
Но, если реплика не успевает катастрофически или вообще отключилась, то у нас есть риск переполнения диска.
Для избегания этого риска в PostgreSQL есть настройка: max_slot_wal_keep_size - задаёт максимальный размер файлов WAL, который может оставаться в каталоге pg_wal для слотов репликации после выполнения контрольной точки.
Если объём файлов в каталоге превысит это значение, то слот репликации, которому нужны самые старые файлы WAL будет выключен и каталог будет очищен максимально для продолжения безопасной работы СУБД.

5. Архивирование журнала транзакций
MS SQL - заархивировать можно только журнал "левее" последнего checkpoint. Если у нас не происходит checkpoint или не работает/"завис" процесс архивирования, то сервер будет накапливать журнал и мы упрёмся или в место на диске или в ограничение размера файла журнала транзакций.
PostgreSQL - заархивировать можно любой файл WAL, кроме текущего. НО если у вас по какой-то причине процесс архивирования не работает или "завис", то сервер будет копить файлы WAL и мы придём опять к ситуации окончания места на диске.

Понимание этих основных отличий работы СУБД с журналами транзакций (предзаписи) поможет в понимании механизмов и разборе ситуаций с окончанием места на дисках СУБД.

❗️Место на дисках - САМАЯ ЧАСТАЯ проблема остановки или неадекватного поведения продуктивных серверов как СУБД так и 1С!

🔤🔤🔤 OOMKiller - страшный сон Администратора баз данных.

Попробуем выяснить основные причины, неочевидные особенности работы Лучшей в мире платформы 1С и возможно ли с этим что-то сделать…
OOMKiller –система защиты Linux от перерасхода памяти.
Срабатывает, убивая самый «толстый» по памяти процесс в Операционной системе при приближении расхода памяти к 95%

Итак, в чём же вообще проблема?

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

В итоге, при планировании запроса, планировщик уверен что сортировку можно произвести в памяти, так как по его прикидкам она влезет в параметр work_mem (например 256MB), так как получит на вход небольшое количество строк для сортировки и их размер тоже будет небольшим (например 100 строк, размером по 30КБ каждая). Эти данные планировщик получает из статистики.

Начав выполнение запроса СУБД уже не может ослушаться этой декларации планировщика и выполняет сортировку в памяти.
НО вместо предполагаемых 100 строк по 30КБ, что спокойно вмещается в 256МБ нам для сортировки прилетело 1,5млн строк по 30КБ, что уже занимает 42ГБ!
В итоге в процессе сортировки такого объёма в памяти, эта самая память или совсем закончится или её расход приблизится к уровню сработки OOMKiller-а.

Ситуацию усугубляется следующим:
❗️Убивать процессы нельзя! Это приведет к перезапуску всего PostgreSQL!
▫️work_mem устанавливается на каждое соединение. Т.е. у нас может сложится ситуация когда сразу несколько пользователей 1С сделают запрос к СУБД на такого рода сортировку…
▫️ Каждое соединение в PostgreSQL работает в отдельном процессе и при этом процесс не умеет худеть по памяти, он просто убивается как становится никому не нужным.
▫️ Платформа 1С удерживает idle соединения при необходимости (например в нём создавалась временная таблица и её можно будет переиспользовать) . Т.е. у нас может сложится ситуация, когда запрос выполнился, заняв 20ГБ RAM, при этом соединение удерживается и используется для других запросов, которым столько RAM не нужно.

Методы борьбы с этими негативными моментами:
❗️Убивать процессы нельзя! Это приведет к перезапуску всего PostgreSQL! А значит увидев что процесс работает (не idle) наш единственный шанс корректно завершить этот запрос, это отменить его выполнение на сервере 1С вычислив его по номеру соединения с СУБД.
▫️Необходимо содержать статистику в максимально актуальном состоянии. Настраивая агрессивный autovacuum, устанавливая нестандартные значения сработки autovacuum на больших таблицах, проводить vacuum analyze как регламентную операцию и т.д.
▫️Уменьшить work_mem, отслеживая как это повлияет и на план и на работу дисков
▫️Настроить OOMKiller. Чтобы он не убивал, а замораживал процесс OOMPolicy=continue, но это опасно, так как в итоге вся память может быть поглощена и работы вообще остановится.
▫️Отдельный пункт для борьбы с толстыми idle.
Мы можем вычислить ТОП-3 процессов, потребляющих память

ps -eo pmem,vsize,pid,cmd | sort -k 1 -nr | head -3

и увидеть такую картину:

6.6 12095572 2380533 postgres: postgres erp 10.27.24.1(64722) idle
6.6 12015844 2380844 postgres: postgres erp 10.27.24.1(64837) idle
6.4 12091534 2380682 postgres: postgres erp 10.27.24.1(64735) SELECT

Видим что в топе процессы с idle и только 1 с select.
В PostgreSQL есть параметр idle_session_timeout, по умолчанию 0.
Но мы можем выставить его в 3 сек, подождать 7 сек и обратно убрать в 0.

ALTER SYSTEM SET idle_session_timeout = 3000;
'select pg_reload_conf();
'ALTER SYSTEM RESET idle_session_timeout;

Таким образом мы корректно прервём соединения с 1С и СУБд сама корректно завершит наши объевшиеся процессы.
Негативный побочный эффект – временные таблицы платформе 1С придётся создать заново, но по сравнению с перезапуском СУБД это допустимо

1️⃣🔤 Почему может не формироваться Технологический журнал 1С?

ТехЖурнал лучшей в мире платформы 1С (ТЖ) - это реальное отражение работы 1С с объективными цифрами и данными.

Он давно стал одним из основных инструментов в работе Экспертов, а уж при работе с КОРП клиентами по линии РКЛ это вообще незаменимая вещь!

При этом достаточно часто встречаемся с ситуацией, когда ТЖ "не хочет" формироваться и начинаются танцы с бубнами...

Ниже опишу основные причины этих танцев:

▫️Права на каталог сбора ТЖ.
Проблема проявляется когда есть процессы 1С, работающие из под разных пользователей операционной системы.
Например:
- Служба агента кластера (ragent, rmngr, rphost) 1С работает из под v81cuser, а служба Удаленного сервера администрирования (ras) работает под другим пользователем ras1c.
- Процессы кластера 1С (ragent, rmngr, rphost) работают под разными пользователями, каждый под своим
- Вместе с кластером 1С установлен также web-сервер с модулем публикации 1С, который тоже работает под своим пользователем

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

Рецепт: Необходимо заранее создать все каталоги размещения файлов ТЖ ( например log location="C:\TJ\RKL") и выдать им права на изменение всем пользователям всех процессов системы, которые могут писать ТЖ.

Ну и если уж совсем ничего не помогает, то создайте заранее каталог (C:\TJ), дайте на него все права всем и потом настройте сбор ТЖ в этот каталог.

▫️В файле conf.cfg текущей версии платформы прописали ConfLocation

Тогда система будет искать файл настройки ТЖ (logcfg.xml) именно в этом каталоге, а не каталогах по умолчанию %PROGRAMFILES%\1cv8\conf, /opt/1cv8/conf

Рецепт: либо расположить файл logcfg.xml в каталоге указанном в ConfLocation либо убрать эту строку из файла conf.cfg

▫️И наверное самое неочевидное – в файле logcfg.xml есть более одного тега log location и в одном из них указан несуществующий диск в системе Windows либо примонтированный каталог Linux

Тогда рандомно будет то записываться ТЖ, то нет, то от одних процессов, то от других.

Рецепт: во всех тегах log location файла logcfg.xml должны быть указаны существующие в операционной системе диски Windows либо примонтированный каталог Linux

▫️В каталоге сбора ТЖ находятся посторонние файлы

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

🔤🔤🔤 8.5.1.1150 Толстый клиент

Новая мини-рубрика - срочно в канал!)))
В ней буду освещать критичные на мой взгляд ошибки, которые ещё не зарегистрированы.

Вот и пришло время обновиться на 8.5...

И поймали ошибку на скриншоте

Условие ошибки:
В конфигурации должен быть добавлен хотя бы один Элемент стиля
Подключаемся к ней на платформе 8.5.1.1150 в клиент-серверном режиме (в файловом всё работает)
Запускаем Толстый клиент
Авторизация 1С

❗️При этом конфигуратор запускается

Рецепты:
1. Не обновляться на 8.5, если используете Толстые клиенты
2. Перейти на прозрачную авторизацию AD, если давно собирались, но никак не находили для этого время
3. Указать логин и пароль в параметрах запуска, если это позволяет ваш сценарий

❗️Ну и главное - перед обновлением платформы максимально тестируйте все варианты запуска и работы 1С всех видов конфигураций, который у вас используется.