Комментарии
Избранное
Подписка
Сортировка:
Древо
(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С. Был ли у вас опыт построения подобной архитектуры? Мы планируем на стороне основного ЦОДа кластер 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С ?
Добрый день.
Если сервер отдельный, то понятно что будет. Но он тоже может выйти из строя и тогда всё тоже самое. Кластер как раз и создаём для резервирования, а по факту получается сервер лицензирования отдельный, сервер для публикации отдельный и где отказоустойчивость?
А именно на серверах кластера публиковать базу не пробовали?
Если сервер отдельный, то понятно что будет. Но он тоже может выйти из строя и тогда всё тоже самое. Кластер как раз и создаём для резервирования, а по факту получается сервер лицензирования отдельный, сервер для публикации отдельный и где отказоустойчивость?
А именно на серверах кластера публиковать базу не пробовали?
(100)а причем здесь безотказный сервер.Ведь публикуешь ты не 1с-ом, а апачи или IIS.можно сделать публикации и на обоих и чтобы переключалось но уже настройки домена, а не 1с.Т.е. безотказность работы сторонних программ у IIS есть свои решения.Но публиковать на том же сервере, по моему мнению не правильное решения так тяжелее будет идентифицировать проблему при возникновении.А 1С только обещают что ресурс к которому будет обращаться IIS или апач будет работать.
Как я понимаю - схема не является 100% отказоустойчивой.
У Вас используется 1 сервер лицензирования (а больше и невозможно из-за ограничений платформы).
Получается если он ляжет, то и все ляжет.
Я рассматриваю вариант размазать лицензии (2500 пользователей) по серверам приложений.
Но тут есть минусы:
1. лицензий надо в полтора раза больше, чем количество пользователей (Вместе с сервером потеряется и часть лицензий)
.2. не проверял как поведет себя система если сервер ляжет, сессия начнет мигрировать на второй сервер, а лицензия? есть подозрение, что она отвалится и пользователь все-равно вылетит.
У Вас используется 1 сервер лицензирования (а больше и невозможно из-за ограничений платформы).
Получается если он ляжет, то и все ляжет.
Я рассматриваю вариант размазать лицензии (2500 пользователей) по серверам приложений.
Но тут есть минусы:
1. лицензий надо в полтора раза больше, чем количество пользователей (Вместе с сервером потеряется и часть лицензий)
.2. не проверял как поведет себя система если сервер ляжет, сессия начнет мигрировать на второй сервер, а лицензия? есть подозрение, что она отвалится и пользователь все-равно вылетит.
Ребят, я совсем новенький во всем этом, так что извините за совсем глупые вопросы. У меня тут не сколько вопросов возникло.
1) Лучше всего это все настраивать что б сервера были разные (физически). Т.к. если настроить на виртуальных( на одном физическом сервере), то при отказе самого железа, вся система не имеет смысла?!
2) На каждом настраевом сервере у меня должна быть полна копия той базы для которой настраивается отказоустойчивая система?
1) Лучше всего это все настраивать что б сервера были разные (физически). Т.к. если настроить на виртуальных( на одном физическом сервере), то при отказе самого железа, вся система не имеет смысла?!
2) На каждом настраевом сервере у меня должна быть полна копия той базы для которой настраивается отказоустойчивая система?
1. Конечно при отказе железа если сервера приложений созданы все на нём, то всё и рухнет.
2. Нет. Сервер баз данных тоже лучше поднять на отдельной машине и там будет база. Далее на любом из серверов кластера прописываете существующую базу или создаёте новую и она через непродолжительное время будет видна со всех серверов кластера. Реплицируется её описание.
2. Нет. Сервер баз данных тоже лучше поднять на отдельной машине и там будет база. Далее на любом из серверов кластера прописываете существующую базу или создаёте новую и она через непродолжительное время будет видна со всех серверов кластера. Реплицируется её описание.
Еще вопросик, а можно все тоже самое но без сервера лицензий. Т.е. как в 8.2 просто отказоустойчивую систему получить, в том плане, если один падает (например служба отвалилась) все процессы перекидывались на другой? Если да, то со всей этой схемы выпадает 3 сервер и все? И не совсем понял про "Центральный сервере" он у меня должен быть только тот который основной работает?
И еще 2 вопроса которые больше всего интересует. Все пишут что система проседает примерно на 10% при настройки отказоустойчивого кластера, а в чем она проседает? В оперативке, в ЦП или как это вообще понять.
И второй вопрос, а есть подобные темы с описанием как эта, по настройке отказоустойчевого кластера в MS sql?
И второй вопрос, а есть подобные темы с описанием как эта, по настройке отказоустойчевого кластера в MS sql?
1. Сервер лицензий необходим для того чтобы не дублировать лицензии на центральных серверах. Без сервера лицензий Вам придётся иметь лицензии на каждом центральном (рассмотрим случай когда центральных два) чтобы в случае падения центрального сервера система оставалась работоспособной.
2. В кластере на 8.3. работают сразу одновременно все центральные сервера и сеансы распределяются между ними либо по производительности, либо по оперативной памяти. Т.е. так называемого горячего резерва нет.
2. В кластере на 8.3. работают сразу одновременно все центральные сервера и сеансы распределяются между ними либо по производительности, либо по оперативной памяти. Т.е. так называемого горячего резерва нет.
Здравствуйте, коллеги. Сделал все по инструкции, но появилось несколько вопросов:
1. Если у меня 2 центральных сервера, то куда пишется журнал регистрации (на одном сервере размер файла журнала 600 мб, на другом - 4 мб)
2. В журнале регистрации появляются записи о том что транзакция не завершена, хотя на самом деле все ок и объект записан успешно)
3. С полнотекстовым поиском тоже какая-то беда: файлы создаются то на одном сервере то на другом, в результате в результатах поиска иногда отсутствуют некоторые объеты.
Может нужно настраивать функциональности, только потом непонятно что будет если один из серверов действительно упадет.
На молчат как рыба об лед.
Платформа: 1С:Предприятие 8.3 (8.3.10.2252)
1. Если у меня 2 центральных сервера, то куда пишется журнал регистрации (на одном сервере размер файла журнала 600 мб, на другом - 4 мб)
2. В журнале регистрации появляются записи о том что транзакция не завершена, хотя на самом деле все ок и объект записан успешно)
3. С полнотекстовым поиском тоже какая-то беда: файлы создаются то на одном сервере то на другом, в результате в результатах поиска иногда отсутствуют некоторые объеты.
Может нужно настраивать функциональности, только потом непонятно что будет если один из серверов действительно упадет.
На молчат как рыба об лед.
Платформа: 1С:Предприятие 8.3 (8.3.10.2252)
Добрый день, коллеги.
В одном сообщении было сказано что нельзя ставит 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. В версии 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".
Например, я указывал в подключении "Srvr=serv1, serv2", а надо было "Srvr=serv1,serv2".
Добрый день коллеги.
Поставил платформу 8.3.10.2505 и столкнулся с тем что перечисление в таком формате Srvr="SRV1,SRV2" перестало работать. Пишет что база не существует. По отдельности с каждым сервером соединение есть. Написал в следующем виде: Srvr="SRV1;SRV2" соединение проходить стало, но при этом соединяется только с тем сервером, который первым указан. Проверил следующим образом - положил сервер, который указан первым и соединение не стало проходить. Кто-нибудь с этим сталкивался? Изменился формат? На ИТС ничего не нашёл, может плохо искал. Подскажите.
Заранее спасибо
Поставил платформу 8.3.10.2505 и столкнулся с тем что перечисление в таком формате Srvr="SRV1,SRV2" перестало работать. Пишет что база не существует. По отдельности с каждым сервером соединение есть. Написал в следующем виде: Srvr="SRV1;SRV2" соединение проходить стало, но при этом соединяется только с тем сервером, который первым указан. Проверил следующим образом - положил сервер, который указан первым и соединение не стало проходить. Кто-нибудь с этим сталкивался? Изменился формат? На ИТС ничего не нашёл, может плохо искал. Подскажите.
Заранее спасибо
(156)если всё работает корректно, то рабочие процессы всех серверов кластера видно в консоле администрирования
То что рагент нагружен это неправильно, он вообще не нагружется в процессе работы.
Приведите скриншоты настроек кластера, рабочих серверов и их требований назначения функциональности
А так же скриншот рабочих процеесов с консоли
То что рагент нагружен это неправильно, он вообще не нагружется в процессе работы.
Приведите скриншоты настроек кластера, рабочих серверов и их требований назначения функциональности
А так же скриншот рабочих процеесов с консоли
(157)
прикрепил, в основном все по умолчанию
настроек кластера, рабочих серверов и их требований назначения функциональности
А так же скриншот рабочих процеесов с консоли
А так же скриншот рабочих процеесов с консоли
прикрепил, в основном все по умолчанию
Прикрепленные файлы:
1с-app центральные сервера, lic1C- сервер лицензий.pdf
Есть кто нибудь, кто юзает кластер на последних версиях платформы, как оно себя ведет? Этот зверь работает так как положено работать безотказному кластеру? Или же все как описано, типа перезагрузка каждую ночь )))))))) ну или еще какие костыли!
Коллеги, подскажите:
есть два сервера приложений, на каждом свой серверный ключ.
Необходимо на третьем серваке развернуть программные клентские лицензии.
Вопрос: если третьему серваку через требования назначения функциональности назначу роль сервиса лицензий, а с первых двух серваков эту роль "сниму", то не отвалятся ли серверные лицензии с этих двух серваков?
есть два сервера приложений, на каждом свой серверный ключ.
Необходимо на третьем серваке развернуть программные клентские лицензии.
Вопрос: если третьему серваку через требования назначения функциональности назначу роль сервиса лицензий, а с первых двух серваков эту роль "сниму", то не отвалятся ли серверные лицензии с этих двух серваков?
Нет всё будет хорошо, только на том сервере, где развёрнуты программные клиентские лицензии лучше все остальные требования, кроме сервиса лицензирования поставить не назначать, ну или однозначно Клиентское соединение с ИБ поставить не назначать, а на серверах с серверными ключами поставить Клиентское соединение с ИБ назначить, а Сервис лицензирования поставить не назначать.
Добрый день.
Подскажите пожалуйста, при использовании отдельного сервера лицензирования и подключении его к кластеру программные лицензии на конфигурации(и на пользователей тоже) с 1С Предприятия надо активировать с указанием сервера лицензирования или с указанием центрального сервера кластера к которому подключен сервер лицензирования?
Подскажите пожалуйста, при использовании отдельного сервера лицензирования и подключении его к кластеру программные лицензии на конфигурации(и на пользователей тоже) с 1С Предприятия надо активировать с указанием сервера лицензирования или с указанием центрального сервера кластера к которому подключен сервер лицензирования?
А как в этом случае будут раходоваться клиентские лицензии? Расточительно?
Так понимаю что в случае сервера лицензирования - лицензии раздаются сервером 1С?
То есть если пользователей задет на терминальный сервер и запустит 2 сеанса базы, то сколько израсходуется лицензий?
Так понимаю что в случае сервера лицензирования - лицензии раздаются сервером 1С?
То есть если пользователей задет на терминальный сервер и запустит 2 сеанса базы, то сколько израсходуется лицензий?
Привет коллеги.
Почитав все выше изложенное, ну и попробовав воспроизвести кое-что, а именно:
Развернул на трех серверах 1С по следующей схеме
Сервер1 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - Не назначать; Сервис полнотекстового поиска - НЕ назначать)
Севвер2 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - назначать; Сервис полнотекстового поиска - НЕ назначать)
Сервер3 - Рабочий сервер (ТНФ сеансовые данные - НЕ назначать; Журнал регистрации - НЕ назначать, Сервис полнотекстового поиска - назначать).
Отказоустойчивость - 1
И осталось несколько (может вопросов будет больше) вопросов:
1. Без журнала регистрации работа с БД невозможна, (упал Севвер2 и все соединения отвалились) как можно добиться того что бы запись журнала велась в единое место как для Севвер2 так и для Сервер1 , можно ли два центральных сервера натравить на скажем сетевой каталог и будет ли при этом достигнута отказоустойчивость и масштабируемость?
2. Если явно не указывать сервис журнала регистрации записи всегда будут производиться на разные центральные сервера?
Почитав все выше изложенное, ну и попробовав воспроизвести кое-что, а именно:
Развернул на трех серверах 1С по следующей схеме
Сервер1 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - Не назначать; Сервис полнотекстового поиска - НЕ назначать)
Севвер2 - Центральный сервер (ТНФ сеансовые данные - назначать; Журнал регистрации - назначать; Сервис полнотекстового поиска - НЕ назначать)
Сервер3 - Рабочий сервер (ТНФ сеансовые данные - НЕ назначать; Журнал регистрации - НЕ назначать, Сервис полнотекстового поиска - назначать).
Отказоустойчивость - 1
И осталось несколько (может вопросов будет больше) вопросов:
1. Без журнала регистрации работа с БД невозможна, (упал Севвер2 и все соединения отвалились) как можно добиться того что бы запись журнала велась в единое место как для Севвер2 так и для Сервер1 , можно ли два центральных сервера натравить на скажем сетевой каталог и будет ли при этом достигнута отказоустойчивость и масштабируемость?
2. Если явно не указывать сервис журнала регистрации записи всегда будут производиться на разные центральные сервера?
(143)
Не совсем верная настройка у Вас, правильно сделать так: Сервер1 - Журнал регистрации - Назначать, приоритет 99 Сервер2 - Журнал регистрации - Назначать, приоритет 100
Тогда при падении Сервера2 ЖР начнёт писаться на Сервер1 (Сетевой каталог для ЖР - неверное решение)
(143)
В этом случае ЖР будет писаться в случайном порядке на сервера где не запрещен ТНФ ЖР
1. Без журнала регистрации работа с БД невозможна, (упал Севвер2 и все соединения отвалились) как можно добиться того что бы запись журнала велась в единое место как для Севвер2 так и для Сервер1 , можно ли два центральных сервера натравить на скажем сетевой каталог и будет ли при этом достигнута отказоустойчивость и масштабируемость?
Не совсем верная настройка у Вас, правильно сделать так: Сервер1 - Журнал регистрации - Назначать, приоритет 99 Сервер2 - Журнал регистрации - Назначать, приоритет 100
Тогда при падении Сервера2 ЖР начнёт писаться на Сервер1 (Сетевой каталог для ЖР - неверное решение)
(143)
2. Если явно не указывать сервис журнала регистрации записи всегда будут производиться на разные центральные сервера?
В этом случае ЖР будет писаться в случайном порядке на сервера где не запрещен ТНФ ЖР
(144) Я про приоритеты понял, но тогда неясно как поведет себя журнал в момент падения сервера.
Получится так что часть (до падения сервера2) будет записана на него, вторая часть (после падения сервера2) запишется на Сервер1 и третья часть (после восстановления работы сервера2) продолжит записываться на сервер2 ТАК? Не возникнет ли проблем при работе с Журналом при таких разрывах?
Получится так что часть (до падения сервера2) будет записана на него, вторая часть (после падения сервера2) запишется на Сервер1 и третья часть (после восстановления работы сервера2) продолжит записываться на сервер2 ТАК? Не возникнет ли проблем при работе с Журналом при таких разрывах?
(147)
(147)
А можете подсказать про склеивание журнала какими методами это лучше делать
скорее всего выгрузкой в таблицу данных за время аварии и добавления этих записей в основной ЖР, вроде как есть прям типовые методы в коде
(147)
И какие есть механизмы по отслеживанию выхода из строя одного из центральных серверов?
События ADMIN, ATTN, CLSTR в техжурнале, ну и просто телент на порт рагента для отслеживания самого факта отказа, а не причин
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.