1С 8.2 отказоустойчивый кластер #505631

Есть два 1С 8.2 сервера, настроил резервирование кластеров. см. Строка подключения выглядит так: Srvr="1C1:1641;1C2:1641";Ref="upp_test"; Допустим все сервера перезагрузились, а сервер 1С1 не поднялся. SQL сервера работают, 1С2 работает. Запускаем 1С базу, получаем сообщение ---- Информационная база не обнаружена! Создать новую? ---- Как же обеспечить резервирование 1С серверов?

сделай зеркалирование в ms sql и забудь про отказоустойчивую хрень по имени кластер

например имеем 6 серверов.  два терминала, два 1С сервера, два SQL. Один "1С сервер" вылетел. Как от этого подстраховаться? Если бы он вылетел во время работы, то думаю второй 1С подстраховал бы. А если допустим на пару часов выключали свет. Значит 1С сервера не помнят настройки...

почитать доки=) кластеров должно быть несколько. типа один рабочий - второй резервный. ну и консоль открыть.

Прочитано и сделано как в доках поправка к  строка примерно такая: Srvr="1C1:1641,192.168.0.2:1641";Ref="upp_test"; Вопрос. Откуда второй 1Ссервер знает о списке баз другого 1С сервера, если первый выключить, а второй перезагрузить.

На сколько я понимаю в кластере 1с всегда есть ГЛАВНЫЙ сервер, падение которого приведет к отказу всей системы в целом. А вот например  падение любого НЕ ГЛАВНОГО сервера будет не заметным. Опять же на сколько я понимаю, тут все упирается во внутрений кеш сервера, который не может кластеризоваться из-за проблем с актуализацией. Тоесть дополнительные сервера - это тупые расчетчики и не более, а главный - это координатор. Спасает класторизация мелкомягких (или аналог), только стоит денег не слабо...

судя по докам, есть активный и резервный кластер. Со списком зарегистрированных информационных баз не совсем понятно. У каждого сервера 1с до объединения в группу резервирования может быть свой список. ------- Кластеры, перечисленные в списке резервирования, и имеющие одинаковые списки резервирования, образуют группу резервирования. Пользователей обслуживает только один кластер из группы. Он считается активным. Остальные кластеры группы считаются резервными и обеспечивают синхронизацию наиболее важных данных в актуальном состоянии: · список зарегистрированных информационных баз, · список резервирования, · сеансовые данные, · оперативную отметку времени. Активным всегда является первый в группе работоспособный кластер. При выходе из строя активного кластера активным становится следующий работоспособный кластер группы. При восстановлении работоспособности кластера, который находится в группе резервирования раньше активного, после синхронизации данных активность передается ему.

У кого-нибудь два 1С сервера работают вместе? Довольны? ;)

1С 8.2 сервер без перезагрузки долго проживёт?

так вот что б такого небыло, в кластере устанавливается отдельный накопитель скази дисков, тогда кластер будет так сказать полноценным, а все остальное, это балансировка нагрузки

Очень доволен. Прямо как слон. Только я отключил отказоустойчивость и распределил нагрузку между 2-мя серверами, т.к. несколько минут простоя ни чего не решат. Ооооочень долго. Только нормально отлажу периодическую перезагрузку процессов и будет вообще сказка

>Откуда второй 1Ссервер знает о списке баз другого 1С сервера... Нашел ошибку у себя в настройках. На обоих серверах пара служб Агент сервера 1С на разных портах. Рабочий и тестовый. При резервировании кластеров напутал с портами. Проверил настроил, список баз появился в обоих серверах. Утечка памяти есть? Побаловался я со свойствами кластера, группа параметров "Перезапускать рабочие процессы", поле "Интервал перезапуска". Перезапускает, с выбрасыванием пользователей из базы. Что-то мне это не понравилось. Пробовал когда был один 1С сервер. отдельное сетевое хранилище для SQL серверов есть. как сделать? работать с 1С сервером будет?

это две отдельных базы - на разных скл серваках как сделать..

Т.е. так, чтобы как в примерах - уборщица дернула кабель( на самом деле админ решил перезагрузить SQL сервер), а 1С продолжила бы работать через второй SQL сервер, можно? Судя по ссылкам, копать туда?: >ориентированный на отказоустойчивость (high-availability) — для этого режима обязательно использование следящего сервера. Третий, что-ли сервер нужен?

нет, будет перезапуск

база на втором серваке актвируется - станет доступной. нет, третий(следящий) - не обязателен. оказывается уже на русский перевели

Вместо перезагрузки с выкидыванием надо делать отключение процессов по одному, дожидаться когда сервер все перекинет на другие процессы и включать. Вообще не понимаю идеологию, когда надо кого-то выкидывать из базы

>надо делать отключение процессов по одному Вручную? Лучше уж тогда настроить автоматическую полную перезагрузку 1С серверов в разное время ночью, чем полагаться на человеческий ресурс, который должен что-то периодически настраивать. Я бы рад настроить всё один раз и чтобы всё потом само работало годами и никого не выкидывало. ;)

вножную... автоматом конечно :) Сейчас отлажу все баги и выложу инструмент в виде фонового задания на общую скачку. Нет, примерно раз в месяц я минут на 20 всех выгоняю, т.к. злой админ ставит обновления винды и вношу изменения в метаданных

у тебя обновление конфигурации 1 раз в месяц?

Метаданных да. Иногда реже иногда чаще. В основном со стандартными обновлениями. Все остальное динамическими обновлениями. Это плохо?

я хз. я раз в неделю. через месяц не могу вспомнить, что тут и как уже динамическими.... а база распределенная ??

неееее, распределенки почти нет, она как резервный канал, исли все каналы терминалки отвалятся. А что бы ни чего не забыть использую хранилище.

ты не путай сетевое хранилище и внешний RAID массив это немного чем полность разные веши, и задачи у них разные на них, как раз и строится отказоустойчивый кластер

Это мне? Вообще-то это был ответ на фразу: "я раз в неделю. через месяц не могу вспомнить, что тут и как уже" из А СХД это само собой, почти начало построения системы (если что, то это гораздо больше, чем просто RAID-массив)! В продолжении могу отметить, что хранилище конфигурации, как и многие мелочи, очень сильно могут повлиять на стабильность работы всей системы

Что-то не нашел в литературе. Допускается ли в консоли 1С сервера в "Резервирование кластеров" и в "Рабочие серверы"  добавить одни и те же компьютеры? Или нужно на каждом компьютере делать пару Агентов сервера (кластеров) на разные порты.  Один кластер только для резервирования, другой только для рабочих серверов.

Может я сильно туплю, но и на сайте 1С и у Гилева, как то опущено в умолчание как организованно железо+ПО для создания отказоустойчивого кластера. 1. Если 2 сервера в кластере, на одном и 1С-server и SQL-server. Какой минимум оборудования+ПО нужен чтобы организовать ОТКАЗОУСТОЙЧИВЫЙ кластер. Ну понятно что на втором физическом сервере надо как минимум 1С-server. А дальше начинаются умолчания: На том же сервере нужен ли SQL-server или он должен будет вынесен на третью машину к которой оба 1С-servera будут обращаться, или достаточно 2 компа с 1С+SQL и одинаковыми копиями баз на собственных винтах (базы будут синхронизироваться). То есть при отключении 1 компа 2 полностьью его заменит без выключения? Если база одна и кластер это - лишь 2 компа обращающиеся к физически единственной базе то где же отказоустойчивостьь на случай исчезновения доступа к базе (допустим диски посыпались). Гилев хитро обошел этот момент в выключением процесса rphost, понятно что дисковая и SQL продолжала нормально работать, а если полностью сервак вырубить?  Надо четко пояснить где лежит база и есть ли её синхронизированная полная копия. Если база внешняя одна на два сервера, то вся эта отказоустойчивость маркетинговый обман.

отказоустойчивость сервера приложений != отказоустойчивость сервера СУБД. Ставьте кластерный инстанс SQL Server'a - кто вам не дает?

!= - не равно имелось ввиду, видимо. Ну ладно сейчас уже виден свет в конце тоннеля. Хороше тогда вариант 2 компа: 2. 1C-server, SQL-server Сервера приложений в кластере (Платформа 8.2),СУБД также обьединены в кластер средствами SQL, но в любом случае нужна общая база, и она не должна лежать на этих серверах, а на внешней СХД. Опять уперлись в незаменимое звено, отказ которого приведет к остановке всего, конечно скажут поставь вторую СХД и делай на неё зеркало, но есть ведь соотношение цена качество. Финансовое ограничение не позволяет приобрести СХД. При этом имеется очень мощный сервер который сейчас крутит и СУБД и СП. Денег хватит либо на запасной сервер на котором восстанавливать базу из бэкапов вслучае падения основного либо на СХД. Слышал что SQL 2005 SE в кластере не требует покупки второй лицензии если втоорой экземпляр пассивный (и тоолько на случай сбоя держится), может кто точно знает.