Посмотрим, как можно перераспределить функции Главного менеджера кластера 1С на соседние серверы 1С.
Имеем серверы 1Csrv06 и 1Csrv07. Пусть на сервере 1Csrv07 будет Главный менеджер кластера 1С. Сервер 1Csrv06 сделаем дополнительным рабочим сервером 1С в помощь серверу 1Csrv07. Все манипуляции проделываем в консоли 1С сервера 1Csrv07. На сервере 1Csrv06, в секции Менеджеры кластера создаем Дополнительные менеджеры кластера. (все понятно из рисунка).
Здесь просто указываем название и нажимаем ОК.
Перед перераспределением сервисов между менеджерами кластера необходимо удалить все рабочие процессы на всех рабочих серверах. Либо открыть Свойства каждого Рабочего процесса…
… и перевести все имеющиеся на кластере рабочие процессы на всех рабочих серверах в неактивное состояние. Иначе будет выдаваться сообщение, что при работающихрабочих процессах ничего поменять не удастся.
Манипуляции по перераспределению сервисов между менеджерами кластера производятся на уровне кластера, где все Менеджеры кластера расположены на одном уровне. Там, где манипуляции с сервисами невозможны — помечены красным крестимом.
Встаем на нужный нам Менеджер кластера, вызываем по правой кнопке мыши контекстное меню, и выбираем пункт «Переместить сервис с другого менеджера кластера«.
В открывшемся окне из списка выбираем нужный для перемещения на другой кластер сервис…
… и нажимаем кнопку ОК:
Видим, что в дополнительном менеджере кластера появился один сервис, который мы переместили с другого менеджера кластера.
Перенос служб на другой менеджер кластера как и создание такового — зло, кроме вырожденных индивидуальных случаев. Индивидуальные случаи не написали, людей плохому учите. Очень хочется поставить «-«…
Если возможность такая есть, то лучше знать как её можно реализовать. То, что чего-то не работает нормально — это перманентное состояние/поведение платформы 1С. Поэтому эксперименты с 1С — обычное явление!
(1) comol, (2)
Вы оба правы, каждый по-своему.
Однако,если есть такой опыт — хотелось бы понять, для каких ситуаций этот метод полезен.
(3) itar59, ЖР и полнотекстовый поиск выносить иногда нужно, но только в высоконагруженных системах…. с большой опаской и если это реальная необходимость… Да и то лучше полнотекстовый поиск в нормальных системах не использовать, а ЖР заменять версионированием и регистрировать только ошибки и события аудита.
(4) comol, а как же события доступа к объектам? Как их кроме журнала то получить…
p.s. прошу прощения, не дочитал сообщение до конца. Можно удалить.
(4) comol, но ведь именно разделение (подобное описанному) чуть ли не главное достоинство (как описывают) в платформе 8.3
http://v8.1c.ru/overview/release_8_3_1/
см.
(6) itar59, Что-то не нашел в описании где это как главное достоинство. нашел конфигуратор под Linux и READ_COMMITED_SNAPSHOT 🙂 только. да и фича эта в 8.2 уже есть… что в этом хорошего не знаю. Если когда либо доживём до подобия RAC в 1C то такое разделение потерят свою актуальность…
Собственно, да — как это сделать можно прочитать и в документации.. А вот где и как это применять — вот что было бы неплохо узнать.