через 1 месяц совместно с НПЦ 1С будет тестировать безотказный кластер скорее всего на 8,3,9,2170.Отпишусь о результатах(Будет тестироваться и на толстом и на тонком клиенте)
(98) Сергей, как прошло тестирование отказоустойчивого кластера на 8,3,9,2170? Вы не сообщили результаты.
Хотелось бы получить совет если возможно: мы планируем создание резервного ЦОДа, территориально удаленного от основного. В качестве сервера приложения используется 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С:Эксперта по технологическим вопросам" изд 2. Многие вещи освещены(правда некоторые вещи только по верхам и не все(в части OS Windows и MS SQL)).
Добрый день.
Если сервер отдельный, то понятно что будет. Но он тоже может выйти из строя и тогда всё тоже самое. Кластер как раз и создаём для резервирования, а по факту получается сервер лицензирования отдельный, сервер для публикации отдельный и где отказоустойчивость?
А именно на серверах кластера публиковать базу не пробовали?
(100)а причем здесь безотказный сервер.Ведь публикуешь ты не 1с-ом, а апачи или IIS.можно сделать публикации и на обоих и чтобы переключалось но уже настройки домена, а не 1с.Т.е. безотказность работы сторонних программ у IIS есть свои решения.Но публиковать на том же сервере, по моему мнению не правильное решения так тяжелее будет идентифицировать проблему при возникновении.А 1С только обещают что ресурс к которому будет обращаться IIS или апач будет работать.
Как я понимаю - схема не является 100% отказоустойчивой.
У Вас используется 1 сервер лицензирования (а больше и невозможно из-за ограничений платформы).
Получается если он ляжет, то и все ляжет.
Я рассматриваю вариант размазать лицензии (2500 пользователей) по серверам приложений.
Но тут есть минусы:
1. лицензий надо в полтора раза больше, чем количество пользователей (Вместе с сервером потеряется и часть лицензий)
.2. не проверял как поведет себя система если сервер ляжет, сессия начнет мигрировать на второй сервер, а лицензия? есть подозрение, что она отвалится и пользователь все-равно вылетит.
Ребят, я совсем новенький во всем этом, так что извините за совсем глупые вопросы. У меня тут не сколько вопросов возникло.
1) Лучше всего это все настраивать что б сервера были разные (физически). Т.к. если настроить на виртуальных( на одном физическом сервере), то при отказе самого железа, вся система не имеет смысла?!
2) На каждом настраевом сервере у меня должна быть полна копия той базы для которой настраивается отказоустойчивая система?
1. Конечно при отказе железа если сервера приложений созданы все на нём, то всё и рухнет.
2. Нет. Сервер баз данных тоже лучше поднять на отдельной машине и там будет база. Далее на любом из серверов кластера прописываете существующую базу или создаёте новую и она через непродолжительное время будет видна со всех серверов кластера. Реплицируется её описание.
Спасибо за статью. Подскажите:
1. В последних версиях 8.3 стабильно всё работает?
2. После 150 пользователей уже рассматривать создание кластера? Конфиг стандартный, 16 гиг, 8 ядер.
Еще вопросик, а можно все тоже самое но без сервера лицензий. Т.е. как в 8.2 просто отказоустойчивую систему получить, в том плане, если один падает (например служба отвалилась) все процессы перекидывались на другой? Если да, то со всей этой схемы выпадает 3 сервер и все? И не совсем понял про "Центральный сервере" он у меня должен быть только тот который основной работает?
И еще 2 вопроса которые больше всего интересует. Все пишут что система проседает примерно на 10% при настройки отказоустойчивого кластера, а в чем она проседает? В оперативке, в ЦП или как это вообще понять.
И второй вопрос, а есть подобные темы с описанием как эта, по настройке отказоустойчевого кластера в MS sql?
1. Сервер лицензий необходим для того чтобы не дублировать лицензии на центральных серверах. Без сервера лицензий Вам придётся иметь лицензии на каждом центральном (рассмотрим случай когда центральных два) чтобы в случае падения центрального сервера система оставалась работоспособной.
2. В кластере на 8.3. работают сразу одновременно все центральные сервера и сеансы распределяются между ними либо по производительности, либо по оперативной памяти. Т.е. так называемого горячего резерва нет.
Здравствуйте, коллеги. Сделал все по инструкции, но появилось несколько вопросов:
1. Если у меня 2 центральных сервера, то куда пишется журнал регистрации (на одном сервере размер файла журнала 600 мб, на другом - 4 мб)
2. В журнале регистрации появляются записи о том что транзакция не завершена, хотя на самом деле все ок и объект записан успешно)
3. С полнотекстовым поиском тоже какая-то беда: файлы создаются то на одном сервере то на другом, в результате в результатах поиска иногда отсутствуют некоторые объеты.
Может нужно настраивать функциональности, только потом непонятно что будет если один из серверов действительно упадет.
На Конференция "1С:Предприятие 8 молчат как рыба об лед.
Добрый день, коллеги.
В одном сообщении было сказано что нельзя ставит 2 сервера лицензирования, из-за ограничений платформы. Есть об этом какая-нибудь официальная информация?
И еще момент как настраивать по данной инструкции пути к базам у клиентов. Ведь если мы укажем конкретный сервер, то при его падении новые пользователи не смогут войти.
В одном сообщении было сказано что нельзя ставит 2 сервера лицензирования, из-за ограничений платформы. Есть об этом какая-нибудь официальная информация?
Присоединяюсь к вопросу. Откуда ветер дует? На ИТС ничего про это нет.
Собрав воедино всё, что здесь написано, не получил ответов на некоторые вопросы:
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. Как правильно указывать на клиентских приложениях строку подключения?
Перечислять все центральные серверы через запятую без пробелов?
Заранее прошу прощения за отнятое время и благодарю за помощь.
При организации отказоустойчивого кластера, состоящего из двух центральных серверов столкнулся с нюансом на выявление которого потратил много сил и времени. Нюанс заключается в том, что когда прописываете несколько серверов приложений в списке баз, необходимо указывать без "пробелов", иначе "пробел" не исключается и как следствие, 1с не может найти указанный сервер приложения и соответственно подключиться к базе.
Например, я указывал в подключении "Srvr=serv1, serv2", а надо было "Srvr=serv1,serv2".
Присоединяюсь к предыдущему автору. Планируется развернуть аналогичную инфраструктуру. За исключением того, что вместо Hyper-V планируем использовать VMware
Добрый день коллеги.
Поставил платформу 8.3.10.2505 и столкнулся с тем что перечисление в таком формате Srvr="SRV1,SRV2" перестало работать. Пишет что база не существует. По отдельности с каждым сервером соединение есть. Написал в следующем виде: Srvr="SRV1;SRV2" соединение проходить стало, но при этом соединяется только с тем сервером, который первым указан. Проверил следующим образом - положил сервер, который указан первым и соединение не стало проходить. Кто-нибудь с этим сталкивался? Изменился формат? На ИТС ничего не нашёл, может плохо искал. Подскажите.
Заранее спасибо
как увидеть процессы второго центрального сервера? в рабочих процессах показывает, что соединений нет. Хотя в кластере сейчас 480 сеансов, под каждое соединение 2 сеанса. На втором сервере ragent достаточно нагружен по CPU.
157.
a.doroshkevich
49731.10.19 16:55 Сейчас в теме
(156)если всё работает корректно, то рабочие процессы всех серверов кластера видно в консоле администрирования
То что рагент нагружен это неправильно, он вообще не нагружется в процессе работы.
Приведите скриншоты настроек кластера, рабочих серверов и их требований назначения функциональности
А так же скриншот рабочих процеесов с консоли
Есть кто нибудь, кто юзает кластер на последних версиях платформы, как оно себя ведет? Этот зверь работает так как положено работать безотказному кластеру? Или же все как описано, типа перезагрузка каждую ночь )))))))) ну или еще какие костыли!
Коллеги, подскажите:
есть два сервера приложений, на каждом свой серверный ключ.
Необходимо на третьем серваке развернуть программные клентские лицензии.
Вопрос: если третьему серваку через требования назначения функциональности назначу роль сервиса лицензий, а с первых двух серваков эту роль "сниму", то не отвалятся ли серверные лицензии с этих двух серваков?
Нет всё будет хорошо, только на том сервере, где развёрнуты программные клиентские лицензии лучше все остальные требования, кроме сервиса лицензирования поставить не назначать, ну или однозначно Клиентское соединение с ИБ поставить не назначать, а на серверах с серверными ключами поставить Клиентское соединение с ИБ назначить, а Сервис лицензирования поставить не назначать.
131.
user655163_msn25
26.09.18 11:13 Сейчас в теме
Подскажите, как обновлять конфигурацию на отказоустойчивом кластере. Или они могут с разными конфигурациями работать? т.е. пока я один обновляю, запретив к нему подключение, все на втором, и на оборот?
Добрый день.
Подскажите пожалуйста, при использовании отдельного сервера лицензирования и подключении его к кластеру программные лицензии на конфигурации(и на пользователей тоже) с 1С Предприятия надо активировать с указанием сервера лицензирования или с указанием центрального сервера кластера к которому подключен сервер лицензирования?
А как в этом случае будут раходоваться клиентские лицензии? Расточительно?
Так понимаю что в случае сервера лицензирования - лицензии раздаются сервером 1С?
То есть если пользователей задет на терминальный сервер и запустит 2 сеанса базы, то сколько израсходуется лицензий?
Вопрос возник. Есть база на сервере srv1, добавил второй сервер srv2 в кластер, меняю подключение вместо srv1 пишу srv1,srv2. База открывается, но спрашивает - база перемещена или скопирована, это нормально??
Привет коллеги.
Почитав все выше изложенное, ну и попробовав воспроизвести кое-что, а именно:
Развернул на трех серверах 1С по следующей схеме
Сервер1 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - Не назначать; Сервис полнотекстового поиска - НЕ назначать)
Севвер2 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - назначать; Сервис полнотекстового поиска - НЕ назначать)
Сервер3 - Рабочий сервер (ТНФ сеансовые данные - НЕ назначать; Журнал регистрации - НЕ назначать, Сервис полнотекстового поиска - назначать).
Отказоустойчивость - 1
И осталось несколько (может вопросов будет больше) вопросов:
1. Без журнала регистрации работа с БД невозможна, (упал Севвер2 и все соединения отвалились) как можно добиться того что бы запись журнала велась в единое место как для Севвер2 так и для Сервер1 , можно ли два центральных сервера натравить на скажем сетевой каталог и будет ли при этом достигнута отказоустойчивость и масштабируемость?
2. Если явно не указывать сервис журнала регистрации записи всегда будут производиться на разные центральные сервера?
1. Без журнала регистрации работа с БД невозможна, (упал Севвер2 и все соединения отвалились) как можно добиться того что бы запись журнала велась в единое место как для Севвер2 так и для Сервер1 , можно ли два центральных сервера натравить на скажем сетевой каталог и будет ли при этом достигнута отказоустойчивость и масштабируемость?
Не совсем верная настройка у Вас, правильно сделать так: Сервер1 - Журнал регистрации - Назначать, приоритет 99 Сервер2 - Журнал регистрации - Назначать, приоритет 100
Тогда при падении Сервера2 ЖР начнёт писаться на Сервер1 (Сетевой каталог для ЖР - неверное решение)
(144) Я про приоритеты понял, но тогда неясно как поведет себя журнал в момент падения сервера.
Получится так что часть (до падения сервера2) будет записана на него, вторая часть (после падения сервера2) запишется на Сервер1 и третья часть (после восстановления работы сервера2) продолжит записываться на сервер2 ТАК? Не возникнет ли проблем при работе с Журналом при таких разрывах?
146.
a.doroshkevich
49701.10.19 16:19 Сейчас в теме
(145) Возникнут проблемы с чтением такого журнала и его придётся склеивать.
Но это ничто по сравнению с тем что база продолжит работать.
Сильно нужен ЖР - пишите его в СУБД.
(146) А можете подсказать про склеивание журнала какими методами это лучше делать? И какие есть механизмы по отслеживанию выхода из строя одного из центральных серверов?