В новой серии уроков мы наглядно покажем возможности отказоустойчивости клиент-серверной платформы «1С:Предприятие 8.3».
Кластер серверов 1С позволяет выполнять горизонтальное масштабирование. Также в него заложены возможности по обеспечению отказоустойчивости системы.
В отличие от платформы 8.2, в 8.3 нет групп резервирования кластеров.
Вместо этого появилась возможность создавать несколько центральных серверов и настраивать уровень отказоустойчивости.
В данных уроках мы рассмотрим, как работает отказоустойчивость в платформе 8.3. Для этого проведем ряд экспериментов – будем выводить из строя различные серверы кластера и проанализируем работоспособность системы.
Видео 01:
Отказоустойчивость центральных серверов
Что будет, если центральный сервер кластера выйдет физически из строя? В 8.2 это бы означало полную остановку системы.
В 8.3 появилась возможность создавать несколько центральных серверов.
В видео показан пример выхода из строя центрального сервера. При этом реальные пользователи даже не замечают, что они переключились на другой сервер.
Видео 02:
Настройка уровней отказоустойчивости
В платформе 8.3 в кластере появился параметр «Уровень отказоустойчивости».
В этом уроке показано в теории, как будет влиять настройка этого параметра на работу кластера.
Видео 03:
Выход из строя всех центральных серверов
В уроке смоделирована ситуация выхода из строя всех центральных серверов.
Независимо от уровня отказоустойчивости и доступности рабочих серверов результат будет один…
Видео 04:
Авария на одном рабочем сервере
В уроке рассмотрена ситуация выхода из строя рабочих серверов с разными настройками уровня отказоустойчивости.
Один из рассмотренных сценариев работы показывает, что поведение работы кластера не всегда соответствует документации на платформе 8.3.6.
Отметим, что с релиза 8.3.8 разработчики поменяли поведение платформы. Теперь оно приведено в соответствие с документацией.
Видео 05:
Выход из строя всех рабочих серверов
Ситуация – авария случилась сразу на всех рабочих серверах, при этом один центральный сервер остался доступен.
В теории такая система не должна работать, однако на практике получаем иной результат…
Видео 06:
Формула расчета уровня отказоустойчивости
В уроке показана методика (совершенно не очевидная) расчета уровня отказоустойчивости для кластера серверов.
Видео 07:
Отказоустойчивость и производительность
Желание сделать систему максимально отказоустойчивой приводит к негативным последствиям – система начнет медленнее работать.
Рассмотрим этот момент в данном видео.
Смотрите еще:
Эта тема детально раскрыта в курсе:
Поддержка – 3 месяца. Объем курса – 35,5 учебных часов.
Не откладывайте свое обучение!
Добрый день! Есть такая ситуация что заказчик хочет разделить кластер физически по разным площадкам. Т.е. всего два центральных, два рабочих сервера 1С. На каждой из площадок находится один центральный и один рабочий. Как поведет себя кластер 1С если пропадет связь между центральными серверами(не будет репликации служб Блокировок объектов, нумерации и т.д.), а доступ от клиентов будет к центральным серверам. И не понятно что будет с сервисом Транзакционных блокировок – в описание написано что он вроде не реплицируется
День добрый
Если у вас 2 центральных сервера, то при падении одного из них клиент получит ошибку, перезапустит приложение и попадет на второй центральный сервер, после чего продолжит работу. Это наиболее оптимальный, надежный и быстрый вариант т.к. клиент не будет ждать по несколько минут с эффектом зависания пока система переключится на другой сервер как это было бы при использовании уровня отказоустойчивости.
ДОбрый день.
Подскажите, для каких целей в консоли кластера может понадобиться добавлять новый кластер в рамках одного центрального сервера? На ИТС когда речь идет об отказоустойчивости и масштабируемости, то оперируют рабочими серверами. Там не нашел ответа на свой вопрос.
Добрый день!
1.Второй сервер на может потребоваться например для учебных целей или разделить ресурсы одного сервера для 2 кластеров (так несколько надёжнее).
2.Фактическая отказоустойчивость и то, что про неё пишут на ИТС несколько отличается, например: уровень отказоустойчивости = 1 согласно ИТС достаточно 2 рабочих сервера один из которых центральный… фактически требуется 2 центральных сервера пусть даже оба и рабочие, т.к. если в первом случае падает центральный сервер – падает всё, а во втором случае падение любого из серверов не приводит к фатальным последствиям.
Мне кажется вы меня не поняли. Чуть подробнее опишу.
Есть один сервер физический, на нем развернут сервер 1С, в таскменеджере 3 процесса:
1 ragent,
1 rmngr,
1 rphost.
В консоли кластера я добавляю в этом центральном сервере еще один кластер, не рабочий сервер, а именно кластер. В таскменеджере теперь:
1 ragent
2 rmngr
2 rphost
Или вы так и поняли мой вопрос?
просто чтобы собирать отказоустойчивый кластер надо как минимум 2 рабочих сервера. а тут он один
Укажите к какому видео вопрос или к какой статье, хотя-бы контекст вопроса станет понятен.
к сожалению, тут нет возможности прикрепить картинку из курса со схемой о которой я пишу.
я не знаю как еще спросить, но попробую так:
в чем преимущество когда на одном центральном сервере больше одного кластера?
если в процессах:
рагент:1540, рменеджеры 1541 и 2541, рпхосты 1560-1591 и рпхосты 2560-2591
в чем преимущество перед схемой
рагент:1540, рменеджер:1541, рпхосты 1560-1591
?
Ну наконец-то понял. Центральный сервер в терминах 1С совсем не то, что вы имеете в виду. У вас фактически на 1 физическом сервере функционируют в рамках 1 кластера центральный сервер (с функционалом рабочего сервера, ragent-1540/ rmngr-1541/rphost:1560-1591), для краткости сервер А и рабочий сервер(ragent-2541/rphosts:2560-2591) – сервер Б. Эта схема суть надёжнее чем просто один центральный(и он-же и рабочий) сервер на 1 физическом сервере. В случае падения сервера Б – его процессы будет подхватывать сервер А, кластера серверов 1С. На практике такая схема используется не часто, чаще в учебных целях.
Так-же возможно вам будет полезно.
Проверил вариант из двух центральных серверов 1С srv1 и srv2 + сервер лицензирования.
Добавив в рабочие сервера дополнительный центральный сервер srv2 и установил отказоустойчивость в 1. Отключил службу 1с на дополнительном центральном сервер srv2 – сеансы перекинулись на сервер srv1 – вроде работает. (обратно не пробовал отключить srv1 – так как среда продакшен).
Обратил внимание, что:
1) Журнал регистрации 1с – пишется для проверяемой базы только на srv1 (хоть и все сеансы 1с на базе работают с srv2).
2) Сеансовые данные 1с – пишутся для проверяемой базы на оба сервера (но судя по времени это не синхронные записи, а разные).
3) Полнотекстовый поиск – пока не понял где пишется…
Так вот вопрос: надо ли дополнительно в какой то последовательности приоритетов настраивать требования назначения функциональности в отказоустойчивом кластере 1С для журналов регистрации, сеансовых данных и полнотекстовому поиску?
Хороший вопрос, на курсе есть отдельный урок где это разбирается.
Если у вас более одного сервера в кластере, то 1С рекомендует с помощью ТНФ явно явно закрепить за каким-то одном сервером следующие сервисы:
– сервис журнала регистрации
– сервис полнотекстового поиска
– сервисы работы с внешними источниками данных.
Это может быть один сервер для всех сервисов или разные, важно что эти сервисы должны быть явно закреплены.
Сервис сеансовых данных нужно явно указать на каждом из серверов кластера.
Добрый день. Подскажите, можно ли настроить отказоустойчивость кластера 1с8.3 с лицензиями ПРОФ?
Здравствуйте!
Вы имеете ввиду настройку Уровень отказоустойчивости?
Если да, то в описании функционала КОРП сайте 1С https://v8.1c.ru/overview/corp/ не указана настройка “Уровень отказоустойчивости”, значит исходя из документации, она может быть использована для лицензии ПРОФ.
Доброго времени суток.
Вопрос по первому видео.
Попробовали на практике отказоустойчивый кластер на два центральных сервера – srv1;srv2
Платформа 8.3.8.1933.
Если отключить сервер srv1 и в подключениях базы будет srv1;srv2
тогда подключается к базе нормально.
Но если в подключении указать только srv1 и srv1 отключить, то сервер по сети не находится.
Денис, здравствуйте.
А вы хотя бы 1 раз подключились успешно под этим пользователем к кластеру, когда у вас уже было настроено 2 центральных сервера?
“УО = Количество центральных серверов – 1”
Если в системе три рабочих сервера и только два из них центральных, то вывод из строя не любых двух серверов окажется отказоустойчивым. Т.е. да, можно подобрать частый случай (один центральный, один рабочий), когда система не упадёт после вывода из строя двух серверов, но это не означает, что вывод ЛЮБЫХ двух серверов будет отказоустойчивым. Поэтом я не могу считать, что УО = 2. В данном случае гарантированно допускается вывод ЛЮБОГО только одного сервера для обеспечения отказоустойчивости. В этом смысле формула “для экзамена” верна, просто не хватает математического понятия “любой”
Если считать так, тогда получается что документация написана неверно, т.к. там сказано, что УО это то количество серверов которые могут выйти из строя и при этом приведены конкретные примеры.
Я предлагаю ориентироваться не на документацию и формулировки, а на поведение системы на практике.
Во всех видео для имитации аварии выполняется остановка службы агента.
А что будет происходить с пользовательскими сеансами, если принудительно завершить рабочий процесс, который их обслуживает?
Насколько помню, в 8.2 за это отвечала группа резервирования и там сеансы “перетекали” (при отсутствии незавершенных транзакций).
А что в 8.3? Я правильно понял, что содержимое видеороликов применимо к принудительному завершению любого процесса ОС, участвующего в обслуживании сеанса (ragent, rmngr, rphost)?
> А что будет происходить с пользовательскими сеансами, если принудительно завершить рабочий процесс, который их обслуживает?
Если у пользователя этого рабочего процесса была открыта транзакция, тогда он получит сообщение об ошибке и завершит работу.
Если пользователь в этот момент ничего не делал, то он даже не заметит что процесс упал, т.к. упавший процесс сразу же перезапускается.
> Насколько помню, в 8.2 за это отвечала группа резервирования
Группа резервирования применима если упадет не процесс, а весь сервер.
В 8.3 для этого используются уровни отказоустойчивости.
> правильно понял, что содержимое видеороликов применимо к принудительному завершению любого процесса ОС, участвующего в обслуживании сеанса (ragent, rmngr, rphost)?
Нет, это применимо только к процессам rphost
В Видео 02 на слайде написано “Уровень отказоустойчивости (УО)” – количество РАБОЧИХ серверов”
Вот выделил специально слово РАБОЧИХ, то есть не ЦЕНТРАЛЬНЫХ.
То есть или есть разница в понятиях, или это ошибка в голове диктора?
Все центральные сервера являются рабочими, но не все рабочие сервера являются центральными.
Андрей, скажите, при использовании оказоустойчивого кластера, где правильно расположить ключи защиты клиентских лицензий? Ведь их реплицировать или дублировать мы не можем? Если упадет именно тот сервер, где они были установлены, то наличие остальных серверов в рабочем состоянии, увы, будет бесполезно…
Тут есть несколько вариантов:
1. В 8.3 можно перенести сервис лицензирования на отдельный компьютер, пока этот компьютер работает, лицензии будут выдаваться, даже если один из серверов выйдет из строя.
2. Если используются программные лицензии, тогда можно переактивировать лицензии на другом сервере используя один из 3х пин-кодов.
3. Если используются аппаратные ключи и сервера находятся в одном здании, тогда можно просто переставить ключ.
4. Для обеспечения самой высокой скорости переключения, можно иметь в запасе дополнительные лицензии на отдельном сервере. Этот вариант предпочтителен если стоимость простоя очень высока, тогда лучше закупить 2 комплекта лицензий, один для постоянной работы и одни резервный.
Ни хочу никого обижать но почему видео записан картавым голосом? Что нет других людей.
Конечно можно было бы подключить профессионального диктора.
Но мы считаем, что в разы ценнее, если курс ведет сам эксперт.
Если его будет читать сторонний человек, я уверен, результаты будут хуже (хотя сам контент останется тем же самым).
Курс этого автора прошло более 1500 человек и никто не предал этому факту существенного значения.
Тоже отмечу, что качество дикции последнее время стало гораздо хуже. Во всех новых курсах. Если Евгений и, особенно, Фарит читали весьма хорошо, и даже эмоционально, то материал гораздо лучше усваивался и запоминался. Евгений не ленился чертить кучу слайдов “карандашом”. Сейчас имеем забыстренный темп увы с дефектами речи, мелькание слайдов. Жаль :(
Добрый день!
Как говориться на вкус и цвет все фломастеры разные :)
А если серьезно, то главное в наших курсах – контент. Приведу пример.
У Бурмистрова Андрея не идеальная дикция. Но я вижу более 200 отзывов клиентов, которые прошли его курс и у них есть реальные результаты. То есть не просто “курс понравился”, а есть реальный “выхлоп” – или экзамен сдан, или на практике примели или успешно прошли собеседование на интересную должность.
Более того внимальные слушатели знают, что Фарит писал некоторые видео в аэропорту под звуки взлетающих самолетов :)
Над подачей мы конечно же будем работать, но контент первичен.
“Ни хочу никого обижать…”
Я ни какого отношения к команде проекта не имею, простой слушатель. И вот с этой точки зрения скажу: не хочешь обижать – лучше промолчи.
Без обид, если что.
Так обычно делают люди у которых цель как раз обидеть человека)
Здравствуйте, Андрей!
У меня два вопроса:
1. по видео 6, вы разделили практику и экзамен. Что из этого следует, экзамены составляют неграмотные люди, которые не являются экспертами и даже специалистами? Или в то время когда они их составляли, платформа работала по другому? или др. причина?
2. Я как из старой версии курса, так из видео, до конца не понимаю, для чего вообще нужно заполнять свойство “Уровень отказоустойчивости”. На подсознательном уровне, понимаю только следующее: чем больше центральных серверов, тем больше элементов кластера одновременно могут обслуживать не зависимо друг от друга определённую задачу. А для чего вообще это свойство заполнять, так и не понимаю. Объясните пожалуйста по понятнее…
3. Почему не в курсе и нигде вы не упоминаете, про то, что отказать могут не только сервера приложений, а ещё и сервера с СУБД. Может для них тоже следует, что-то типа зеркала организовать? А как правильно это сделать, не покажите (хотя бы в рамках курса)?
1. Из этого следует только то, что теория отличается от поведения на практике. Если вы работаете с 1С давно, то это не должно быть для вас откровением, такое случается довольно часто.
2. Получается что на практике этот механизм сейчас не отлажен. На данный момент его работа не соответствует документации. Сейчас получается что неважно заполняете ли вы это свойство или нет, отказоустойчивость все равно будет зависит от числа центральных серверов. Надеюсь что скоро либо исправят документацию, либо исправят сам механизм.
3. Если используется MS SQL версии 2012 и выше, то для этой цели можно использовать механизм Always on. В сети достаточно много подробных описаний настройки и работы данного механизма. Если будут конкретные вопросы, задавайте их рамках мастер-группы.