Создаем отказоустойчивый кластер и сервер лицензирования 1С Предприятие 8.3
База данных - Администрирование СУБД
Есть 3 (srv1, srv2,srv3)сервера на 2 мы располагаем сервера приложений 1С(srv1,srv2),а на третьем будет сервер клиентских лицензий.
- На всех трёх серверах мы устанавливаем Cервер 1С:Предприятия (64-bit) для Windows.
- Затем на srv1 запускаем консоль администрирования, она обычно расположена c:\Program Files\1cv8\common\1CV8 Servers (x86-64).msc
- Там уже существует Локальный кластер созданный по умолчанию. Переименовываем его в CLASTER1C
- В консоли добавляем центральные сервера srv2 и srv3.(для того чтобы их видеть в одной консоли)
- В консоли выбираем srv2 и удаляем локальный кластер.
- Далее выбираем srv1 открываем CLASTER1C - Рабочие сервера и добавляем 2 рабочих сервера srv2 и srv3.
- затем там же выбираем Properties у рабочего сервера srv2 и ставим галочку центральный сервер.
- В консоли выбираем srv2 и там у нас должен появиться CLASTER1C.
- выбираем Properties у CLASTER1C и ставим уровень отказоустойчивости 1 (вычисляется по формуле Кол-во Центральных серверов= уровень отказоустойчивости +1).
- Далее выбираем в консоли srv1 открываем рабочие сервера и у srv3 открываем Требования назначения функциональности. Добавляем две функциональности Любой объект требования - Не назначать - Для всех баз и Сервис лицензирования - Назначать - Для всех баз.(для всех баз означает что в поле Имя ИБ оставляем пустым)
- Далее выбираем CLASTER1C открываем рабочие сервера и у srv1 и srv2 открываем Требования назначения функциональности. Добавляем две функциональности Клиентское соединение с ИБ - Назначать - Для всех баз и Сервис лицензирования – не назначать - Для всех баз.
- Далее выбираем CLASTER1C и на кластере щелкнув правой кнопкой мыши выходит список нажимаем Применить Требования назначения функциональности(Полное).
- Устанавливаем лицензии на сервера(ВСЕ ЛИЦЕНЗИИ УСТАНАВЛИВАЮТСЯ НА SRV3)
UPD. Рекомендую выделить отдельный Сервер лицензирования и сервер под ЖР - они серверной лицензии не требуют( сервер под ЖР делается аналогично серверу лицензирования). И в этой схеме должен быть ещё один рабочий сервер. Последний вариант статьи которой нашел выложил по просьбе трудящихся))).
Вступайте в нашу телеграмм-группу Инфостарт
Отказоустойчивый кластер сервер лицензий 1С:Предприятие 8.3
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)
После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.
19.10.2026 956 Tantor 0
Администрирование СУБД Сервера Системный администратор Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
Примеры скриптов для работы с автономным сервером (ibsrv).
09.10.2026 1063 hexhoc 6
Администрирование СУБД HighLoad оптимизация Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Россия Бесплатно (free)
Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.
01.10.2026 1443 Tantor 6
DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)
В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.
1 стартмани
10.09.2026 1521 Ninel_S 0
HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)
В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.
31.08.2026 6117 Tantor 3
Администрирование СУБД Системный администратор Разработчик 1С 8.3 Бесплатно (free)
Мы подготовили для сообщества Infostart.ru практическое занятие, в котором каждый желающий сможет: научиться собирать реальные данные о процессах кластера 1С; выявлять «перестарков» — процессы старше периода и без соединений; выполнять безопасный перезапуск (с dry-run и подтверждением); настраивать автоматическую проверку через systemd на Linux; отправлять уведомления (Telegram, почта) при обнаружении проблем; работать с логами, ротацией, профилями кластеров и конфигурацией; развернуть полноценный учебный проект AdminClusterMonitor у себя в тестовой среде.
30.08.2026 1730 Ninel_S 2
Администрирование СУБД Системный администратор 1С:Предприятие 8 Бесплатно (free)
На infostart.ru вышел разбор Ивана Недомолкова «Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку» - это хорошая инструкция, как ловить и разбирать падение rphost постфактум: logcfg.xml, procdump, анализ дампа. Но там нет ответа на вопрос «а почему кластер вообще прибил процесс сам, ещё до всякого краша». Мы дополняем разбор тремя сводными таблицами лимитов памяти и автомасштабирования кластера - и заодно фиксируем, чем в этой части лицензия ПРОФ урезана относительно КОРП.
12.08.2026 2371 Ninel_S 5
Администрирование СУБД Системный администратор Разработчик Бесплатно (free)
5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.
11.08.2026 3405 jul.dolganova 9
Ну и не дано обоснование - для какой конкретной цели сие собиралось? Зачем вообще кластер? Почему приводится "уровень отказоустойчивости = 1"?..
2) Участвуют в работе srv1 и srv2,а srv3 -мелкая виртуалка которая раздаёт лицензии(серверные и клиентские)
3)под Linux можно но это не проверялось.
4) Под большой проект порядка (1500 пользователей)
5)Смысл если первый сервер упал все кто был на первом перетекают на 2 сервер(пользователи замечают только одномоментное замедление).
6) "уровень отказоустойчивости = 1" потому до версии 8.3.5.1119 при работе на 3 серверах в кластере и 1 сервере лицензий устойчиво работает только при "уровень отказоустойчивости = 1" хотя должно быть 2.
7)как распределяется нагрузка хорошо написано на ИТС, а вот как создать кластер и сервер лицензий нет.
и не понятно, что значит "вернули" - их никто вроде не забирал - хотите - пользуйтесь, а в некоторых случаях с программной лицензией намного удобнее. да, есть глюки, но что теперь, в целом то механизм работает, и на том спасибо.
Задача была "пробросить" на ВМ ключ лицензии сервера 1с в локальной сети.
Все бесплатные и условно бесплатные были забракованы. Т.к. либо не работали вообще, либо могли "пробросить" только USB-накопитель.
Платные, на пробном периоде, тоже в большинстве не справлялись, с такой же статистикой, как в случае с бесплатными.
Т.е. либо не работали, либо "пробрасывали" только накопитель.
Позже выяснилось что те, что "не работают" предназначены для "проброса USB" с целью задействовать специфические устройства (сканеры и т.д.) или принтер.
Нашел одну, реально работающую, которой пользуюсь уже с 2020. "USB Redirector". Только вот автор из UA. И с 2022 года не отвечает на сообщения. А программа платная.
Ещё был найден девайс для проброса USB через сеть. Но, увы, попробовать не получилось, бюджет не позволил. Там около 700$.
(1) теперь на ПРОФ лицензиях вся эта схема рухнула? Требования назначения функциональности теперь не назначить...
(2) получается узкое место - третий сервер с лицензиями. Если третий сервер падает, то все перестает работать. Поделитесь, кто как решал этот вопрос? Делал виртуалку?
1. Нет не рухнуло, онраничения ПРОФ в тнф только на имена баз и на виды клиентов
2. Или двойной набор лицензий или реплика виртуалки между полностью идентичными хостами
Писатель, пиши еще... в этом куске тексту не хватает знаков препинания, переносов и другого форматирования тексту.
В общем чтиво на "От_вяж_ись" ... не читабельно :)
Пробовал у второго сервера (Slave) менять диапазон портов на 1660:1691, не помогло, ошибка та же.
Подскажите пожалуйста в чем причина данной ошибки? И стоит ли на данной версии использовать несколько центральных серверов?
Коллега, поясните, пожалуйста, что вы подразумевали под:
Два безотказных сервера, один для лицензирования, а четвертый что за сервер?
Коллега, подскажите, пожалуйста, как рассчитывается количество серверных лицензий? Предположим: 5 серверов, три из них центральных, на одном располагаются лицензии. Я верно понимаю, что серверных лицензий мне потребуется 4?
в режиме отказоустойчивости надо мин 2 центральных и один рабочий. Для сервера лицензий не требуется лицензии.
Но пока по рекомендации саппорта 1с мы отказались от отказоустойчивого сервера до выхода 8.3.8, там обещали исправить.
Сейчас у нас 1 центральный,два рабочих и сервер лицензий (исп 3 серверных лицензии и 1500 клиентских).
Для повышения устойчивости разнес базы на разные кластера (т.е. по протам 1541, 2542, 3542.....). Этим добились того, что если что-то надо остановить останавливается одна база, а не все.( лицензии на все выше написанные, если на одном сервере не сколько кластеров то используется 1 лицензия(т.к. она дается на сервер, а не на кластер))
1. При штатно работающем кластере производительность почти не проседает, потери не более 10%.
2. Кластер отработал выходные без нагрузки, потерял файл лицензий, пришлось рестартовать службы затем устранять ошибку совместного доступа.
3. Оборвавшиеся соединения, так и остаются висеть на сервере приложений и их надо убивать вручную.
4. При имитации неисправности(положил службу 1С на одном узле кластера srv1 по статье) соединения остались, но производительность упала на порядки(реакция на обращения к серверу замедлились с десятых секунды до минут). При остановке службы на srv2 кластер теряет лицензии, обрываются существующие сессии и нельзя подсоединиться система запрашивает установку лицензий.
Соответственно вопрос и промежуточный вывод:
1. Подскажите может надо сделать какие-то настройки кластера, чтобы при упавшем одном узле он нормально работал?
2. Если такое поведение побороть не получится, то пока этот функционал бесполезен, поскольку не выполняет основные задачи кластера.
2. Замедление есть минут 10 пока он обрабатывает свалившиеся сессии.Потом приходит в норму.
если остановить службу на первой машине, то при подключении пришет:
Платформа: 1С:Предприятие 8.3 (8.3.5.1443)
Ошибки:
--------------------------------------------------------------------------------
31.01.2015 14:18:42
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
по причине:
Ошибка при выполнении операции с информационной базой
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Сетевые интерфейсы SQL Server: Не удается обнаружить указанный сервер/экземпляр [xFFFFFFFF].
HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, state=1, Severity=10, native=4294967295, line=0
по причине:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: Сетевые интерфейсы SQL Server: Не удается обнаружить указанный сервер/экземпляр [xFFFFFFFF].
HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, state=1, Severity=10, native=4294967295, line=0
Я по вашей инструкции настроил все.
в то время когда оба сервера работоспособны зашел в 1С - тут без проблем.
Далее вырубил первый и попытался зайти в 1С, вот тогда и вышла такая ошибка.
проверил наличие базы на втором сервере и вообщем то ее нет, репликация не работает.
1 на srv1 снять галочку Центральный сервер
2 удалить все чтобы сделать,как на картинке
3 на srv1 заново поставить галочку Центральный сервер
и про файрвол не забудь - открытыми должны быть порты 1540,1541,1560-1591(если у тебя все по умолчанию)
отказоустойчивость заработает с 8.3.8 на данном этапе работа не стабильно(в ваше случае скорее всего блокировка файрвола)
на данный момент проходим тестирование совместно с 1с по отказоустойчивому серверу (2 недели полет нормальный)
есть и свои плюсы очень много узнал, о том что есть и как реализовано. по очень многим аспектам есть статьи предназначенные только для внедренцов.если таки в январе закончим проект буду просить опубликовать их статьи и рекомендации. А так больше смотрю на 8.4 она обещает быть более продвинутой для корп.
Не приходилось ли сталкиваться с таким симптомом: периодически начинают очень долго (несколько минут) открываться списки сеансов и соединений в консоли?
При этом сеансов может быть не много, менее 10. Останавливаю службы, удаляю сеансовые данные - может улучшиться, а может и нет.
Нет ли информации - о чем, о каких проблемах может говорить такое поведение ? Диск с сеансовыми данными, сеть, ... ?
Подскажите столкнулся с такой проблемой(платформа 8.3.8.1675). В сети есть три рабочих сервера и сервер лицензий. На двух настроено получение пользовательских лицензий через сервер лицензий, на третий установлен аппаратный ключ. У пользователей на первых двух серверах отключена возможность использования аппаратных ключей и прописано в nethasp.ini NH_USE_BROADCAST = Disabled.
Но бывают такие ситуации, что сервер раздает пользователям аппаратную лицензию, при этом программные ключи еще есть. С чем это связано, как победить?
Этот может немного не в тему, но я правильно понимаю, что вы на serv1 запустили несколько Агентов 1с 8.3(как запустить 8.1, 8.2, 8.3 на одном сервер это понятно), на разных портах или применили другие настройки? Подскажите, пожалуйста, где можно почитать на эту тему.
меняешь название сервиса и импортируешь.
затем меняешь в нём ключ ImagePath пример("C:\Program Files\1cv8\8.3.8.2156\bin\ragent.exe" -srvc -agent -debug -regport 2541 -port 2540 -range 2560:2591 -debug -d "C:\Program Files\1cv8\srvinfo2")
и все
информации по 8.3 не встречал офиц.
а так проделываешь на всех серверах и затем подключаешь их согласно выше на писаному.
для всех доп. агентах меняешь порты и путь к логам(C:\Program Files\1cv8\srvinfo2).
А при установке новой версии тех. платформы галочку создания службы убираешь и сам в реестре меняешь номер тех. платформы(вернее путь к ней) и перезапускаешь сервисы.
Угу. Опять же отлаживать в продакшене очень удобно становится. Красота со всех сторон. Одна манююуууусенькая проблемка - производительность "почему-то" просаживается.
За отладку на продакшен базе надо бить по рукам или по карману. А вот реальное ускорение работы, в некоторых сценариях, с включённой отладкой - это факт. Другое дело, что надо хорошо понимать что делаешь и правильно оценивать возможные негативные последствия подобной настройки.
1. центральный рабочий сервер кластера (с сервисом сеансовых данных)
2. один дополнительный рабочий сервер лицензирования (с сервисом лицензирования)
Работает стабильно.главное на сервере лицензий локальный кластер удалите. И когда его добавляете на нем ставим только одну функцию лицензирования,а все остальное запрещаем.(согласно инструкции) и все будет ок. нужна будет помощь обращайтесь)
PS: Сервер лицензирования у нас виртуальный всегда можно быстро восстановить копию.
Если "да", то правильно ли я поняла, что уровень отказоустойчивости в этом случае ставим 2?
Если в кластере "живые" все узлы, то у одинэсников есть какие-нить зачатки балансировки нагрузки в кластере? Иными словами, когда все узлы кластера живые, то банальный простой остального железа(работает один, а остальные ждут, когда он упадет)?
Спасибо.
Упдате: движок 8.3.8, если чё(8.3.9 не предлагать - глючит под УПП)
(59)
Да. Правда "отказоустойчивый", при текущей архитектуре кластера, понятие достаточно условное. Можно смоделировать ряд ситуаций когда система всё равно рухнет.
8.4 дальнейшее развитие в этом направлении, но когда она выйдет - ещё ждать и ждать.
Кстати, начиная с 8.3.9, сервер 1С начинает нормально поддерживать технологию MS SQL AlwaysOn, правда в документации это не отражено.
(59)
Да, правильно.
(59)
Есть. Узлы не простаивают. Кстати, полезная фича - выделить отдельный сервер для регламентных и фоновых заданий - во многих случаях, прилично снимает нагрузку с основного сервера.
Спасибо.
От целей зависит. В общем случае просто выбрать сервис заданий, в частном - можно только одно конкретное задание вынести.
2.два главных работают параллель, а вот с третим будет перераспределять нагрузку
3.есть вероятность что ключей usb потребуется в 2 раза больше
4.8.3.9 с упп работает нормально там проблема с rphost это у всех( у нас конфа на основе упп)
5.я бы подождал бы когда они это исправят. У нас назначено тестирование безотказного кластера на конец февраля с 1С
ключи USB на сервер1С. купят сколько надо.
мне чисто академически интересно: три железки в кластере, будет толк? сервера не будут драться за рабочие процессы/сеансы/блокировки друг с другом?
Если есть хотя бы небольшая вероятность того, что будет использоваться отдельный сервер лицензирования, то серверные ключи лучше взять программные. Лицензии с аппаратных серверных ключей сервис лицензирования раздавать не умеет.
Если пользовательские, то в принципе ничто Вам не мешает определить сервисы лицензирования на каждом сервере, а их загнать сервера в кластер. Но при этом при падении одного из серверов будут отваливаться сессии, которые шли через сервис лицензирования упавшего сервера.
Этим только фоновые задания причешем или регламентные тоже?
А чем просто выбрать сервис заданий не устраивает, как предлагает ув. h00k?
1.если человек вылетел не всегда ключ освобождается.(при большом кол-во значительные проблемы)
2. очень сложно установить на 1 машину в 2 ключа одной серии(2 по 50 например)
"Железо часто мигрирует туда-сюда."- это как раз не проблема
А сервер лицензий ставишь на отдельную виртуалку которая не изменяется и все. а как меняются сервера приложений всё равно, хоть другие серваки ставь.Главное чтобы их было по кол-во лицензий.
(вслух): если не рассуждать об отказоустойчивости, а конкретно по масштабированию(предоставление ресурсов "он деманд - по требованию"). Что я имею ввиду? Предположим мы собрали файловер кластер из 3х узлов(железок/виртуалок - неважно). Выставили уровень отказоустойчивости 2, ТНФ оставляем по-дефолту(вопросы лицензирования ща не рассматриваем). Всё чики-брики. Далее гасим 2 узла из 3х и ждем прихода сотрудников. Подгребли манагеры, кладовщики - начали стряпать первичку. Возросла нагрузка на базу. Кто-то начал скулить и хныкать, что доки проводятся долго. Тупо включаем второй узел. Бухгалтера начали сооружать тяжёлые отчеты, проводить расчеты себестоимости и прочую ресурсоёмкую белиберду - добавили третий узел... К вечеру по-тихоньку гасим узлы, когда почти весь пипл разбежался по домам. Такой подход имеет право на существование или мне пора менять поставщика травы? Спасибо.
"Пляски с бубном" - это не столько от лукавого, сколько от конкретного релиза платформы. Если сразу стартануло нормально, фоновые процессы не "сыпятся" и т.п., то пляски, обычно, откладываются до следующего обновления платформы. А вот если начались проблемы, то эти пляски могут помочь выправить ситуацию, изолировать глючное фоновое задание, переназначить его на сервак, периодическое падение которого не так критично.
Чем хорош вынос регламентных и фоновых заданий на отдельный сервер - можно между серверами распределить нагрузку по типам, на отказоустойчивый кластер из двух серверов перенаправить oltp-нагрузку (открытие форм, работа с документами и т.п.), на второй сервер olap (все отчёты, не критичные к оперативности данных обработки и т.п.).
(77)
Зачем менять?! Возьми побольше и мне отправь пакетик ;)
Уровень отказоустойчивости 2 предполагает одновременную работу минимум двух серверов в кластере между которыми балансируется нагрузка.
Три узла; на третьем стоит ТНФ Сервис заданий(впрочем, если его поменять на Клиентское соединение с ИБ и доп. параметр BackgroundJob.CommonModule - монофиолетово), на первых 2х эта фича задизаблена. Всё равно количество пользователей поделено между всеми 3мя узлами по 33%, а не по ~50%(на 1й и 2й), как я ожидала. Какого овоща юзеры подсасываются на 3й узел, если мы его заточили на реглафоны? Что не так и где обещанный "парад планет"?
Печалька... Обиделась и пошла сажать печень. :(
1. на Серв1 и Серв2 разные наборы сервисов (см. вложение)
2. при отключении на Серв1 службы Агента 1С
- уже подключенные к База1 могут работать
- все подключенные к База2 отваливаются
- ни одно новое подключение к любой базе не возможно
3. при отключении на Серв2 службы Агента 1С
- все работает без проблем
Что не так в кластере 1С? Или это не описанное нигде поведение - фича 1С?
(Уровень отказоустойчивости = Кол-во Центральных серверов - 1)
у меня "Один" и стоит.
Попробую добавить "Требования" руками....
Попробовал - без результата. Сервисы не поменялись. Во вложении "Требования назначения функциональности" на Серв1 и Серв2.
у всех так же отваливаются? И по факту "отказоустойчивости" в кластере 1С 8,3,8 нет?
В настройках соединения пользователя надо перечислять сервера(если надо, то какой формат ключей) или достаточно прописать первый сервер(в нашем случае srv1)? А если в момент запуска 1С сервер кластера srv1 недоступен(т.е. лежит)?
Я ща не про окно запуска 1С(ibases.v8i), где сервера можно перечислить, а про Remote App.
Hyper-V или VMware vSphere
Начиная с 8.3.9.1818 сервер 1С понимает технологию отказоустойчивости MS SQL сервера "AlwaysOn".
У нас работает отказоустойчивый кластер, состоящий из трёх серверов - два рабочих и сервер лицензирования. В ближайшее время будем запускать Документооборот, который связан с бухгалтерией. На вкладке "Интеграция с 1С Документооборотом" прописан адрес веб сервиса. Он ссылается на один сервер. В случае падения этого сервера в кластере адрес станет недоступен.
Как надо опубликовать базу документооборота, чтобы она была доступна в случае падения любого из серверов кластера?
Хотелось бы получить совет если возможно: мы планируем создание резервного ЦОДа, территориально удаленного от основного. В качестве сервера приложения используется 1С. Был ли у вас опыт построения подобной архитектуры? Мы планируем на стороне основного ЦОДа кластер 1С из минимум 3-х виртуальных машин, репликация - средствами Hyper-V по 1 Гб/с каналу. Либо как вариант, можно сделать единый кластер, состоящий из виртуальных машин 1С основного и резервного ЦОДа. При этом SQL-сервер остается на отдельном физическом сервере и БД реплицируется на резервный (в резервном ЦОДе) средствами SQL (always on).). Также виртуализируются и реплицируются серверы DNS, Active Directory и терминальный сервер. При выходе из строя любого одного из компонентов системы основного ЦОДа (1С-кластера, либо SQL-сервера, либо каналов связи) все пользователи переключаются на работу с системой в резервном ЦОДе (резервный 1С-кластер, резервный SQL-сервер и резервные серверы). Мы планируем переключение пользователей делать аппаратным способом: маршрутизаторы, которые мониторит работоспособность каналов связи и компонентов основного ЦОДа и при падении одного из компонентов всех пользователей переключают на аналогичную структуру резервного ЦОДа.
Вопросы: 1. Будет ли работоспособна подобная схема (при условии обновления платформы до 8.3.9)? 2. Поддерживает ли кластер 1С автоматическое переключение всех пользователей на кластер 1С резервного ЦОДа без остановки их работы в автоматического режиме, или требуется переподключение пользователей. 3. Возможно ли осуществление обновления конфигурации 1С (в том числе при изменении структуры таблиц) без отключения пользователей от кластера 1С ?
Если сервер отдельный, то понятно что будет. Но он тоже может выйти из строя и тогда всё тоже самое. Кластер как раз и создаём для резервирования, а по факту получается сервер лицензирования отдельный, сервер для публикации отдельный и где отказоустойчивость?
А именно на серверах кластера публиковать базу не пробовали?
У Вас используется 1 сервер лицензирования (а больше и невозможно из-за ограничений платформы).
Получается если он ляжет, то и все ляжет.
Я рассматриваю вариант размазать лицензии (2500 пользователей) по серверам приложений.
Но тут есть минусы:
1. лицензий надо в полтора раза больше, чем количество пользователей (Вместе с сервером потеряется и часть лицензий)
.2. не проверял как поведет себя система если сервер ляжет, сессия начнет мигрировать на второй сервер, а лицензия? есть подозрение, что она отвалится и пользователь все-равно вылетит.
1) Лучше всего это все настраивать что б сервера были разные (физически). Т.к. если настроить на виртуальных( на одном физическом сервере), то при отказе самого железа, вся система не имеет смысла?!
2) На каждом настраевом сервере у меня должна быть полна копия той базы для которой настраивается отказоустойчивая система?
2. Нет. Сервер баз данных тоже лучше поднять на отдельной машине и там будет база. Далее на любом из серверов кластера прописываете существующую базу или создаёте новую и она через непродолжительное время будет видна со всех серверов кластера. Реплицируется её описание.
1. В последних версиях 8.3 стабильно всё работает?
2. После 150 пользователей уже рассматривать создание кластера? Конфиг стандартный, 16 гиг, 8 ядер.
И второй вопрос, а есть подобные темы с описанием как эта, по настройке отказоустойчевого кластера в MS sql?
2. В кластере на 8.3. работают сразу одновременно все центральные сервера и сеансы распределяются между ними либо по производительности, либо по оперативной памяти. Т.е. так называемого горячего резерва нет.
1. Если у меня 2 центральных сервера, то куда пишется журнал регистрации (на одном сервере размер файла журнала 600 мб, на другом - 4 мб)
2. В журнале регистрации появляются записи о том что транзакция не завершена, хотя на самом деле все ок и объект записан успешно)
3. С полнотекстовым поиском тоже какая-то беда: файлы создаются то на одном сервере то на другом, в результате в результатах поиска иногда отсутствуют некоторые объеты.
Может нужно настраивать функциональности, только потом непонятно что будет если один из серверов действительно упадет.
На молчат как рыба об лед.
Платформа: 1С:Предприятие 8.3 (8.3.10.2252)
В одном сообщении было сказано что нельзя ставит 2 сервера лицензирования, из-за ограничений платформы. Есть об этом какая-нибудь официальная информация?
И еще момент как настраивать по данной инструкции пути к базам у клиентов. Ведь если мы укажем конкретный сервер, то при его падении новые пользователи не смогут войти.
Присоединяюсь к вопросу. Откуда ветер дует? На ИТС ничего про это нет.
на 8.3.12 побывал отрабатывало, но нормально не протестировал(могут быть глюки) на ИТС ни чего официального не нашел
Собрав воедино всё, что здесь написано, не получил ответов на некоторые вопросы:
1. В версии 8.3.9 кластер умеет нормально работать с MS SQL AlwaysOn High Availability Group? Не будет ли требоваться перезапуск службы 1С на серверах кластера, если было переключение на другой сервер БД с MS SQL AlwaysOn High Availability Group?
2. Каким образом распределяются сервисы 1С по серверам кластера 1С (имеется в виду JobService, TimestampService, NumerationService и др.)
3. При подключении пользователя к базе создаётся 2 абсолютно идентичных сеанса, причем на одном рабочем сервере. Это нормально? Не должен ли "двойник" формироваться на любом другом сервере кластера, как раз для обеспечения высокой доступности? Уровень отказоустойчивости кластера выставлен 1.
4. Насколько хорошо происходит перетекание сеансов с остановленного сервера в ваших конфигурациях? Я получаю регулярно зависшие сеансы, их приблизительно 10-15% от общего количества "перетекших".
5. Как правильно указывать на клиентских приложениях строку подключения?
Перечислять все центральные серверы через запятую без пробелов?
Заранее прошу прощения за отнятое время и благодарю за помощь.
Например, я указывал в подключении "Srvr=serv1, serv2", а надо было "Srvr=serv1,serv2".
Поставил платформу 8.3.10.2505 и столкнулся с тем что перечисление в таком формате Srvr="SRV1,SRV2" перестало работать. Пишет что база не существует. По отдельности с каждым сервером соединение есть. Написал в следующем виде: Srvr="SRV1;SRV2" соединение проходить стало, но при этом соединяется только с тем сервером, который первым указан. Проверил следующим образом - положил сервер, который указан первым и соединение не стало проходить. Кто-нибудь с этим сталкивался? Изменился формат? На ИТС ничего не нашёл, может плохо искал. Подскажите.
Заранее спасибо
как увидеть процессы второго центрального сервера? в рабочих процессах показывает, что соединений нет. Хотя в кластере сейчас 480 сеансов, под каждое соединение 2 сеанса. На втором сервере ragent достаточно нагружен по CPU.
То что рагент нагружен это неправильно, он вообще не нагружется в процессе работы.
Приведите скриншоты настроек кластера, рабочих серверов и их требований назначения функциональности
А так же скриншот рабочих процеесов с консоли
А так же скриншот рабочих процеесов с консоли
прикрепил, в основном все по умолчанию
На всех серверах в файерволе разрешить порты сервера 1с на вход, ну или временно отключить его, как посоветовали в (159)
Сервис лицензирования Не назначать
Клиентское соединение Назначать
Нет, в них нет смысла.
Сервер лицензий может участвовать в нескольких кластерах?? - да
есть два сервера приложений, на каждом свой серверный ключ.
Необходимо на третьем серваке развернуть программные клентские лицензии.
Вопрос: если третьему серваку через требования назначения функциональности назначу роль сервиса лицензий, а с первых двух серваков эту роль "сниму", то не отвалятся ли серверные лицензии с этих двух серваков?
Подскажите пожалуйста, при использовании отдельного сервера лицензирования и подключении его к кластеру программные лицензии на конфигурации(и на пользователей тоже) с 1С Предприятия надо активировать с указанием сервера лицензирования или с указанием центрального сервера кластера к которому подключен сервер лицензирования?
Так понимаю что в случае сервера лицензирования - лицензии раздаются сервером 1С?
То есть если пользователей задет на терминальный сервер и запустит 2 сеанса базы, то сколько израсходуется лицензий?
Речь про программные лицензии конечно
Почитав все выше изложенное, ну и попробовав воспроизвести кое-что, а именно:
Развернул на трех серверах 1С по следующей схеме
Сервер1 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - Не назначать; Сервис полнотекстового поиска - НЕ назначать)
Севвер2 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - назначать; Сервис полнотекстового поиска - НЕ назначать)
Сервер3 - Рабочий сервер (ТНФ сеансовые данные - НЕ назначать; Журнал регистрации - НЕ назначать, Сервис полнотекстового поиска - назначать).
Отказоустойчивость - 1
И осталось несколько (может вопросов будет больше) вопросов:
1. Без журнала регистрации работа с БД невозможна, (упал Севвер2 и все соединения отвалились) как можно добиться того что бы запись журнала велась в единое место как для Севвер2 так и для Сервер1 , можно ли два центральных сервера натравить на скажем сетевой каталог и будет ли при этом достигнута отказоустойчивость и масштабируемость?
2. Если явно не указывать сервис журнала регистрации записи всегда будут производиться на разные центральные сервера?
Не совсем верная настройка у Вас, правильно сделать так: Сервер1 - Журнал регистрации - Назначать, приоритет 99 Сервер2 - Журнал регистрации - Назначать, приоритет 100
Тогда при падении Сервера2 ЖР начнёт писаться на Сервер1 (Сетевой каталог для ЖР - неверное решение)
(143)
В этом случае ЖР будет писаться в случайном порядке на сервера где не запрещен ТНФ ЖР
Получится так что часть (до падения сервера2) будет записана на него, вторая часть (после падения сервера2) запишется на Сервер1 и третья часть (после восстановления работы сервера2) продолжит записываться на сервер2 ТАК? Не возникнет ли проблем при работе с Журналом при таких разрывах?
Но это ничто по сравнению с тем что база продолжит работать.
Сильно нужен ЖР - пишите его в СУБД.
(147)
Ситуация: один сервер физический, на нём развернули сервер 1с, есть рагент(1540), рменеджер(1541), рпхост(ы) (1560:1591).
Подскажите, для каких целей в консоли кластера может понадобиться добавлять новый кластер? На ИТС когда речь идет об отказоустойчивости и масштабируемости, то оперируют рабочими серверами. Там не нашел ответа на свой вопрос.
В рамках одного центрального сервера
Имеются два сервера 1с платформа 8.3.17.1851, территориально в разных зданиях, офисах. Планируется создать отказоустойчивый кластер. Но что бы один из них работал как основной и всегда принимал подключений только он, а второй был в резерве на случай отказа основного.
На данный момент оба сервера назначены центральными, уровень отказоустойчивости = 1.
В требованиях назначений функциональности задавались разные варианты по приоритетам:
Первый сервер «Любой объект требования» назначить Приоритет 100
Второй сервер «Любой объект требования» назначить Приоритет 1
Итог подключения происходят на разные сервера
Первый сервер «Любой объект требования» назначить Приоритет 100
Второй сервер «Любой объект требования» авто Приоритет 1
Итог подключения происходят только на первый сервере, но стоило его выключить и все сеансы оборвались, переключение на 2й не произошло…И даже не удается подключиться заново.
Бы ли у кого опыт по настройка кластера в режиме только резервирования?
Актуальна ли данная инструкция?
На практической реализации, сервер 2 не выполняет своей функции при выходе из строя сервера 1.
То есть, сессия работает пару секунд после отключения и полностью отключается с ошибкой, в которой пишет о том, что сервер 2 не имеет данных.
Так же репликация не работает, может время нужно было для цели появления бд в реплике, но спустя сутки они не появились.
Плюс так же было выяснено следующие, что сервер лицензирования(сервер 3), работает по раздаче лицензий без надобности добавления напрямую в каждый кластер, хватает только того, что он добавлен как общий центральный сервер, то есть на уровне равном среди остальных.
Имеет смысл разрабатывать такую схему(прикреплённый рисунок), вопрос почему именно так поставлен, дело в том, что не явно понятно как работает взаимодействие между платформами сервер 1 и 2, то есть первый падает второй должен подхватывать. Но на практике так не сработало и понять почему? Не удалось, так как не понятен механизм, к примеру в системе "" используется техническое решение виртуальных адресов и понятен работы механизма, то есть виден путь исследования проблемы с 1с нет.
И можно придти к выводу, что тогда лучше делать между двумя платформами как и на схеме выполнено обращение с PG, посредством HAproxy, но останется проблема с журналом регистрации, они будут разные и получается если сервер 1 физически не присутствует и не доступен, то мы остаёмся без актуального ЖР. Какие могут быть соображения по этим мыслям? Стоит ли сочинять свой велосипед или можете пожалуйста помочь, штатными средствами понять как работает кластер в случае настройки его по инструкции, сообщение в котором мною опубликовано.
Вопрос в ИТС задал, мне прислали просто мета представление о том как работает кластер в теории и конкретику по гибким настройкам, но не о том как создать/построить отказоустойчивый кластер
Платформа 8.3.16.1814
Кто сталкивался с проблемой следующего характера :
"8. В консоли выбираем srv2 и там у нас должен появиться CLASTER1C" -- у меня просто не появляется на srv2 кластер.
По теме был одно упоминание , что может влиять брендмауэр\фаервол, но они все отключены.
Платформа 8.3.19
поставил 2 службы 1с на один сервер, на разные порты, и в обоих создал базу 1с с указанием подключения к одной и той же базе в MS SQL. надо ли службы объединять в кластер?
можно ли часть людей рассадить на первый порт ,а часть на второй для распределения нагрузки.Не предлагайте поменять параметр количество ИБ на процесс- не работает если число отличается от 8.
Рейтинг: 117
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 307973
Создание 17.10.14 12:12
Обновление 17.06.24 17:16
Просмотры 184033
Загрузки 0
Рейтинг
118
Комментарии 193
Код открыт Да
Рубрики Администрирование СУБД
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
