Проблема распределения нагрузки в кластере 1С #784239

Здравствуйте. Был кластер 1С, 8.3.7.2008, клиент-сервер: - Джва виртуальных (HyperV) одинаковых сервера 1С (16 логических процессоров, 30GB оперативы), - Физический сервер БД (одно лезвие, 32 логич. процессора, 256GB оперативы, MS SQL 2012, tempdb вынесена на RAM-диск для увеличения скорости работы с ней), - Одна база 106GB, ранее среднее кол-во активных пользователей в течение дня 1100-1200, у утренний пик активности до 1500. Настройки кластера до проблемы в основном умолчательные: С началом осени народ повыходил из отпусков и активно взялся за работу, и к прошлой неделе среднее кол-во активных пользователей выросло до 1500-1600, в пике до 2000. Нагрузка по ЦП на серверах 1С уперлась в 100%. Клиенты 1С начали тормозить. Тогда в кластер добавили еще один сервер (виртуальный, 16 процов, 24GB оперативы). До добавления нового сервера нагрузка примерно поровну распределялась между первыми двумя. После добавления первые два начали отдыхать, а 90% сеансов распределялись на новый сервер, завалив его полностью. Картина нагрузки на сервера на следующий день после добавления сервера: Пока решения нет, чтобы пережить утренний пик нагрузки, когда народ запускает клиенты, вручную балансируем соединения, отключая/включая распределение соединений на новый сервер с помощью требований назначения функциональности. Когда распределение на новый сервер убирается, то два первых нагружаются равномерно. Игры с настройками кластера не привели к каким-либо изменениям, но перерыв много интернетов изменили следующие настройки для рабочих серверов: - кол-во ИБ на процесс = 1 (вроде как добавляет стабильности, даже если ИБ всего одна) - кол-во соединений на процесс - для дополнительных серверов = 60, для центрального оставили 128 (при 128 соединениях процесс ест 2.5-4 GB оперативки, в нескольких местах нашли инфу, что если процесс отъедает больше двух гигов, то может работать нестабильно). На новом сервере установили значение параметра "Объем памяти рабочих процессов, до которого сервер считает производительным" = 17GB (всего на сервере 24GB). Если я правильно понял суть этого параметра, когда объем рабочих процессов достигнет этого значения, на сервер не должны назначаться новые сеансы. Однако это не помогло - сеансы назначаются на сервер даже после превышения этого порога. Мысли/вопросы: 1. Не пробовали пока менять настройку кластера "Режим распределения нагрузки", потому как не нашли толковой информации, чем эти варианты отличаются. 2. На центральном сервере существует "главный менеджер кластера", а на старом дополнительном - "дополнительный менеджер кластера". Оба они были созданы самим 1С автоматически при построении кластера. А вот на новом сервере дополнительный менеджер не создался. Вручную ни создать, ни удалить менеджеры утилита администрирования не позволяет. Может ли отсутствие менеджера на новом сервере повлиять на такое неравномерное распределение нагрузки? Можно ли все таки добавлять новые менеджеры вручную? 3. Не является ли такая ситуация известной проблемой данной версии платформы?

напишите в 1С. С таким количеством пользователей, на ваше обращение откликнуться сразу :-)

таким предлагают ЦКТП заключать

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

добавить еще один сервер можно? новый сервер можно ли сделать основным?

У нас три аппаратно идентичных сервера в такой же конфигурации тоже вели себя странно при распределении нагрузки. По какой-то одному серверу ведомой причине он вдруг занижал доступную производительность для двух из 3-х серверов и подавляющее количество соединений шло на 1 сервер который вешался. Причем даже в рамках процессов одного сервера был перекос. В итоге после полугода экспериментов убрали кластер, распределили базы на 3 сервера и забыли о проблеме. Кстати, тоже замечено что установка кол-во ИБ на процесс = 1 повышает стабильность. Сейчас идем немного по другому пути - с помощью требований назначения функциональности выносим обработку веб-сервисов, COM-ов и рег заданий на отдельный сервер в кластере. Получается значительно эффективнее. Нагрузка на ЦП на сервере где работают пользователи стала плавная без резких скачков а вот фоновые и ком-ы порой грузят второй сервер до 100%, но! эта нагрузка не создает дискомфорта на основной сервер. Это так, на заметку.

Про "Режим распределения нагрузки" есть тут: Про доп. менеджер кластера смотрите требования к назначению функциональности, скорее всего у вас на 2-й сервер назначен какой-то сервис которого на 3-м сервере нет.

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

грамотное решение одно не пойму - зачем делать кластер из виртуалок, надежности нет... кластер все равно упрется в блокировки на мастере... кроме того замечено, что основные тормоза одиночной базы 1с дают логи 1с (ЖР), по этому подумайте на предмет выноса каталога службы 1с на SSD

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

Насколько я знаю, потроха всех серверов одинаковые. У нас используется конфигурация ITIL. Не знаю как в других конфигурациях, но в этой фоновые задания работают под клиентскими сеансами. Мы пробовали разделять фоновые задания и человеков, но не вышло. Делали по статье от самого 1С, указывали в назначениях функциональности, что тип соединения - "фоновое задание", пробовали указать конкретные задания - не помогло. Все равно клиентские сеансы распределялись на оба сервера кластера. Может быть это заскок имеено этой версии платформы, сейчас потихоньку тестируем конфу под 8.3.8.2167, может на ней сработает. Спасибо, почитаем. С очередью сейчас вроде нормально, с дисковой подсистемой уже были проблемы (NetUp), но сейчас с этой стороны проблем нет. Я не специалист по хардам, но насколько я слышал у SSD сравнительно небольшой ресурс на запись. Имеет ли смысл ставить SSD для ЖР, в который пишется очень много и часто?

за ssd уже не так

Насчет виртуалок. У нас под задачу стоит шкаф с лезвиями, каждое по 32 проца и 256GB ОЗУ. Начальство сказало, что на сервера 1С это жирно. Кстати, вопрос: на чем 1С будет лудше работать - на 1 могучем сервере или на 3 послабее?

после установки каталога 1с на SSD скорость работы ЗАМЕТНО увеличивается вопрос сложный, думаю много зависит как от конкретики базы так и от релиза платформы... но общий подход 1с заключается в том, что кластер делается не для ускорения а для масштабируемости, по этому в общем случае до тех пор пока сервак имеет 20..30% запаса (запас нужен для гашения непрогнозируемых пиков нагрузки) по основным характеристикам (ЦП, Память, Диск) никакие кластеры делать не стоит, исключением можно считать когда на отдельный сервер вынесли что-то конкретное обеспечив основному серверу большую отказоустойчивость от пиковых нагрузок (так сказать сделали "балансировку нагрузку на основании функционального разделения")