Отказоустойчивость и катастрофоустойчивость: сравнение подходов
При построении инфраструктуры одним из популярных запросов компаний становится Business continuity, то есть непрерывность бизнес-процессов. Это означает, что система должна сочетать в себе катастрофоустойчивость (Disaster Recovery) и отказоустойчивость, или высокую доступность (High Availability). Разберемся, в чем заключается разница этих подходов и какие преимущества у них имеются.
Подробнее о понятиях
IT-инфраструктура строится с учетом возможных сбоев в работе. В идеале любые критические ситуации система должна переживать с минимальными потерями или вовсе без них. И под сбоями понимаются не только аппаратные или программные неполадки, но и ураганы, пожары и любые другие стихийные бедствия, а также человеческий фактор. По сути список возможных угроз можно продолжать бесконечно.
ИТ-инфраструктура должна быть спроектирована с учетом, если не всех, то хотя бы большинства возможных угроз. Основная задача – чтобы система пережила возможные опасности и осталась в рабочем состоянии. Именно в связи с этим и звучат два термина – отказоустойчивость и катастрофоустойчивость. Рассмотрим подробнее каждый из них.
Отказоустойчивость – это определенное свойство системы сохранять свою работоспособность после отказа одного или нескольких компонентов. С его помощью удается продолжить выполнение бизнес-задач без сбоев и простоя. Это свойство характеризует два технических момента инфраструктуры, а именно – коэффициент готовности и показатели надежности. В первом случае речь идет о времени от всего срока эксплуатации системы, в котором она находится в рабочем состоянии. Второй показатель определяет вероятность безотказной работы инфраструктуры за определенный период.
Катастрофоустойчивость же определяется как способность системы продолжать запущенные задачи при выходе всего ЦОДа из строя. Например, это может потребоваться при отключении электричества или различных природных явлениях, которые влияют на работу оборудования.
Если же говорить кратко, то принцип отказоустойчивости направлен на устранение возможных точек отказа инфраструктуры, тогда как катастрофоустойчивость позволяет поддержать работоспособность системы даже после серьезной аварии.
Особенности построения отказоустойчивости
High Availability, или HA, как мы уже отметили, нацелена на избавление от отдельных точек отказа. Следовательно эта концепция подразумевает резервирование различных сведений и избыточность. Резервирование производится в области программного обеспечения, «железа» и окружения. Это требуется для того, чтобы бизнес-процессы не прерывались при выходе из строя отдельного компонента ИТ-системы.
Одним из первых способов для высокой доступности в вычислениях стали средства аппаратного резервирования. Именно их часто применяли внутри локальной сети, до использования облачных приложений. Однако только при помощи аппаратного резервирования решить проблему отказоустойчивости не удалось, поэтому дополнительно стали использоваться следующие решения:
- резервирование питания за счет подключения нескольких источников – помогло решить проблему отключения физических серверов в случае сбоя на одном из них;
- резервирование отдельных хранилищ с применением RAID – позволило устранить возможную потерю данных;
- резервирование сети при помощи подключения контроллеров – решило проблему отключения сервера от сети в случае сбоев;
- устранение ошибок системы для предотвращения повреждения файловой системы.
В дальнейшем была доработана и избыточность ПО. Многие разработчики стали учитывать этот фактор при разработке приложений, для того чтобы предотвратить ошибки в работе при аппаратных сбоях или проблемах конфигурации. Для обеспечения избыточности используются следующие средства:
- внедрение специальных технологий для масштабируемости системы;
- использование технологии кластеризации и распределение нагрузки по серверам;
- обеспечение доступности;
- мониторинг работы программ и приложений;
- использование систем, имеющих способность самовосстанавливаться.
Развитие облачных технологий подняло отказоустойчивость системы на новый уровень. Появилась концепция избыточности окружения, которая характеризуется аппаратной избыточностью в стойке. Ее цель – равномерное распределение нагрузок для устранения точек отказа.
Используемые меры позволяют решить основную проблему инфраструктуры – точки отказа. За счет этого провайдеры могут гарантировать клиентам доступность всех используемых сервисов. Доступность системы фиксируется в SLA, уровень отказоустойчивости обозначается в процентном соотношении. Он отражает время доступности системы и гарантирует максимальную длительность простоя в год. Например, при показателях 99,99% время простоя в течение календарного года не может превышать 52,6 минут.
Высокая доступность системы является результатом тщательного планирования. То есть, если какие-то факторы не будут учтены на стадии разработки инфраструктуры, то добиться полной отказоустойчивости будет практически невозможно. Обязательным является создание «сценария катастрофы», который помогает учесть последствия любых разрушительных событий и понять, как будет работать система в чрезвычайных ситуациях.
Особенности катастрофоустойчивости
Второй подход к построению ИТ-инфраструктуры – это катастрофоустойчивость, или Disaster Tolerance. Он необходим для того, чтобы спасти важные компоненты системы и сохранить ее работоспособность при серьезной аварии. Например, такая ситуация может возникнуть при пожаре, наводнении или любом другом событии, которое приведет к массовому выходу оборудования из строя.
Главный принцип обеспечения катастрофоустойчивости заключается в использовании кластерной конфигурации. Серверы геораспределяются, то есть размещаются в разных местах, при этом поддерживается единство сети хранения данных. Создается основная и резервная площадки, которые используют единую систему.
Для защиты от природных и техногенных катастроф используется резервирование основных систем размещения и обработки данных. То есть, по сути это еще одно проявление геораспределенной системы. Наличие резервного дата-центра позволяет обеспечить работу инфраструктуры в том случае, если пострадает главное здание ЦОДа.
Нередко к катастрофоустойчивости относят и такое понятие, как Disaster Recovery, или DT. Однако формально этот термин обозначает аварийное восстановление системы. Оно требуется для поддержания работоспособности корпоративной инфраструктуры после масштабного сбоя в работе.
Термин «катастрофоустойчивость» тесно связан с двумя факторами – RTO и RPO. Разберемся, что они обозначают:
- RTO – это целевое время. То есть, это тот период, за который система должна вернуться к рабочему состоянию. Для критически важных компонентов инфраструктуры RTO определяется в секундах, тогда как другие системы могут восстанавливаться в течение часов и даже дней.
- RPO – это точка восстановления. Такой параметр отображает допустимый объем потерянных данных после аварии, который измеряется во времени. Суть в том, что некоторые системы могут потерять данные за день, тогда как другие – за несколько секунд.
План создания инфраструктуры
Непрерывность бизнес-задач потребует тщательного планирования на стадии разработки и построения инфраструктуры. Для этого компании потребуется подготовить два плана:
- Business Continuity Plan. Этот документ необходим для непосредственного обеспечения непрерывности бизнеса. В нем детально описывается, что и в какой последовательности нужно сделать для восстановления текущих задач и процессов.
- Disaster Recovery Plan. Этот план содержит подробную информацию о действиях по восстановлению ИТ-инфраструктуры после катастрофы.
В первом случае может описываться принцип организации удаленной работы, перераспределение задач на другие отделы, изменение отдельных процессов и т. д. Во втором – как эффективно и быстро запустить серверы и при этом сохранить текущие процессы.
Оба плана создаются с учетом требований бизнеса, сферы деятельности, особенностей процессов и т. д. Главное условие – использовать эти схемы сразу после аварийной ситуации. В правильно составленных планах будут содержаться подробные инструкции и список сотрудников, ответственных за их выполнение.
Технологии резервирования
Как вы понимаете, для обеспечения непрерывности всех процессов обязательным является наличие резервной площадки для размещения серверов. То есть при возникновении любого форс-мажора важно развернуть инфраструктуру на новых мощностях, поэтому наличие запасного «железа» на резервной площадке окажется очень кстати.
Может использоваться несколько типов резерва:
- Холодный резерв. В этом случае потребуется наличие серверной с запасным оборудованием. Также может планироваться закупка дополнительного оборудования или хранение «железа» на складе. Основная трудность будет связана с быстрым запуском аппаратуры, особенно, в случае его закупки или аренды сразу после возникновения катастрофы. Процедура потребует времени, поэтому возможны простои в работе компании. Помимо склада с оборудованием, наиболее редкие серверы и ПК могут храниться на складах поставщиков. Восстановление инфраструктуры в таком случае может занять от нескольких дней до нескольких недель, однако такой вариант является самым дешевым.
- Теплый резерв. Этот вариант подразумевает наличие запасной площадки, на которой имеется базовая вычислительная инфраструктура, а также настроена сеть и WAN-каналы. То есть подключено базовое оборудования, что позволит сразу можно перенаправить необходимые нагрузки. По вычислительным мощностям теплый резерв будут уступать основной площадке, но зато позволит запустить систему в течение одного дня. Такое решение можно назвать самым популярным, так как оно сочетает низкую стоимость и приемлемое время ввода в эксплуатацию.
- Горячий резерв. Именно такой вариант обеспечивает наилучшую катастрофоустойчивость информационных систем. Предполагается, что у компании имеется резервная площадка, которая по производительности и мощности не уступает основной. Все данные инфраструктуры постоянно реплицируются и копируются, поэтому в запасном ЦОД хранятся актуальные копии данных. Площадка имеет готовую инфраструктуру с настроенными каналами и готова к мгновенному использованию. Этот вариант подойдет для крупных организаций, которым критически важно избежать даже минутных простоев бизнес-процессов. Минус подобного решения – простой оборудования. По сути, вам придется оплачивать сразу две площадки со всей инфраструктурой, из-за чего расходы могут значительно возрасти.
Выводы
IT-инфраструктура обеспечивает доступ сотрудников к нужной информации, именно от нее зависит скорость бизнес-процессов. В последние годы требования к информационным системам только ужесточаются, ведь каждая минута простоя может серьезно ударить по бюджету организации.
Для обеспечения непрерывной работы инфраструктуры потребуется одновременное использование принципов отказо- и катастрофоустойчивости. Эти процессы предполагают соблюдение ряда условий:
- создание плана действий в случае непредвиденных ситуаций;
- применение средств бесперебойного электроснабжения;
- наличие резервов аппаратных компонентов и сети;
- использование резервных копий данных и т. д.
Если вы не знаете, с чего начать построение собственной инфраструктуры и как обеспечить ее надежность и бесперебойность, то специалисты нашего дата-центра Xelent готовы помочь в этом вопросе. Оставляйте заявки на нашем сайте, и мы обязательно перезвоним!
Панель настройки объекта Сервис отказоустойчивости
Объект Сервис отказоустойчивости предназначен для обеспечения работы распределенной системы в отказоустойчивом режиме.
Панель настройки объекта Сервис отказоустойчивости представлена на рисунке.
Описание параметров настройки, соответствующих элементам панели настройки объекта Сервис отказоустойчивости, представлено в таблице.
п/п
Название параметра
Способ задания значения параметра
Описание параметра
Представление
Значение по умолчанию
Диапазон значений
Мониторинг компьютера
Выбор значения из списка
Задает имя Сервера, состояние которого будет отслеживаться объектом
Имена зарегистрированных в системе объектов Компьютер
Зависит от количества зарегистрированных в системе объектов Компьютер
Ожидание переподключения (секунд)
Ввод значения в поле
Задает период времени в секундах, по истечении которого после потери связи с отслеживаемым Сервером будет произведен перенос конфигурации на резервный Сервер
Натуральный числовой ряд
Да – перенос конфигурации осуществляется при отсутствии пинга.
Нет – наличие пинга не учитывается при переносе конфигурации.
Тип
Выбор значения из списка
Задает тип объекта в конфигурации отслеживаемого Сервера, который требуется перенести на резервный Сервер в случае потери связи
Типы зарегистрированных на базе основного Сервера объектов
Зависит от конфигурации, созданной на базе основного Сервера
Номер
Выбор значения из списка
Задает идентификатор объекта выбранного типа, который требуется перенести на резервный Сервер в случае потери связи
Идентификаторы объектов выбранного типа, присутствующих в конфигурации отслеживаемого Сервера
Зависит от количества объектов выбранного типа в конфигурации основного Сервера
Название
Задает имя объекта, который требуется перенести на резервный Сервер в случае потери связи
Имена объектов выбранного типа, присутствующих в конфигурации отслеживаемого Сервера
Записки IT специалиста
Настраиваем отказоустойчивый кластер Hyper-V на базе Windows Server 2012
- Автор: Уваров А.С.
- 04.03.2015
Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста Hyper-V недоступной окажется значительная часть инфраструктуры. В связи с чем резко вырастает сложность администрирования — остановить или перезагрузить хост в рабочее время практически невозможно, а в случае отказа оборудования или программного сбоя получим ЧП уровня предприятия.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Все это способно серьезно охладить энтузиазм по поводу преимуществ виртуализации, но выход есть и заключается он в создании кластера высокой доступности. Мы уже упоминали о том, что термин «отказоустойчивый» не совсем корректен и поэтому сегодня все чаще используется другая характеристика, более точно отражающая положение дел — «высокодоступный».
Для создания полноценной отказоустойчивой системы требуется исключить любые точки отказа, что в большинстве случаев требует серьезных финансовых вложений. В тоже время большинство ситуаций допускает наличие некоторых точек отказа, если устранение последствий их отказа обойдется дешевле, чем вложение в инфраструктуру. Например, можно отказаться от недешевого отказоустойчивого хранилища в пользу двух недорогих серверов с достаточным числом корзин, один из которых настроен на холодный резерв, в случае отказа первого сервера просто переставляем диски и включаем второй.
В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.
Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.
Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 — SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.
Будем считать, что на оба узла уже установлена операционная система, они введены в домен и сетевые подключения настроены. Откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V.
Следующим шагом добавим компоненту Отказоустойчивая кластеризация.
На странице настройки виртуальных коммутаторов выбираем тот сетевой адаптер, который подключен к сети предприятия.
Миграцию виртуальных машин оставляем выключенной.
Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.
Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в данной статье, но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель — это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.
Создайте новую цель iSCSI и разрешите доступ к ней двум инициаторам, в качестве которых будут выступать узлы кластера.
И сопоставьте данной цели созданные виртуальные диски.
Настроив хранилище, вернемся на один из узлов и подключим диски из хранилища. Помните, что если сервер хранилища подключен также к локальной сети, то при подключении к цели iSCSI укажите для доступа сеть хранения данных.
Подключенные диски инициализируем и форматируем.
Затем переходим на второй узел и также подключаем диски, форматировать их уже не надо, просто присваиваем им такие же самые буквы и метки тома. Это необязательно, но желательно сделать в целях единообразия настроек, когда одинаковые диски на всех узлах имеют одни и те-же обозначения запутаться и сделать ошибку гораздо труднее.
После чего откроем Диспетчер Hyper-V и перейдем к настройке виртуальных коммутаторов. Их название на обоих узлах должно полностью совпадать.
Теперь у нас все готово к созданию кластера. Запустим оснастку Диспетчер отказоустойчивых кластеров и выберем действие Проверить конфигурацию.
В настройках мастера добавим настроенные нами узлы и выберем выполнение всех тестов.
Проверки занимают ощутимое время, при возникновении каких-либо ошибок их необходимо исправить и повторить проверку.
Если существенных ошибок не обнаружено работа мастера завершится и он предложит вам создать на выбранных узлах кластер.
Однако, если проверка выдала предупреждения, мы советуем изучить отчет и выяснить на что влияет данное предупреждение и что нужно сделать для его устранения. В нашем случае мастер предупреждал нас об отсутствии избыточности в сетевых подключениях кластера, по умолчанию кластер не использует сети iSCSI, что нетрудно исправить позднее.
При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров.
На следующем шаге советуем снять флажок Добавление всех допустимых хранилищ в кластер, так как мастер не всегда правильно назначает роли дискам и все равно придется проверять и, при необходимости исправлять, вручную.
Больше вопросов не последует и мастер сообщит нам, что кластер создан, выдав при этом предупреждение об отсутствии диска-свидетеля.
Закроем мастер и развернем дерево слева до уровня Хранилище — Диски, в доступных действиях справа выберем Добавить диск и укажем подключаемые диски в открывшемся окне, в нашем случае их два.
Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия — Настроить параметры кворума в кластере.
Далее последовательно выбираем: Выбрать свидетель кворума — Настроить диск-свидетель и указываем созданный для этих целей диск.
Теперь настроим диск хранилища, с ним все гораздо проще, просто щелкаем на диске правой кнопкой и указываем: Добавить в общие хранилища кластера.
Для того, чтобы диск мог использоваться сразу несколькими участниками кластера на нем создается CSVFS — реализуемая поверх NTFS кластерная файловая система, впервые появившаяся в Windows Server 2008 R2 и позволяющая использовать такие функции как Динамическая (Живая) миграция, т.е. передачу виртуальной машины между узлами кластера без остановки ее работы.
Общие хранилища становятся доступны на всех узлах кластера в расположении C:\ClusterStorage\VolumeN. Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.
Закончив с дисками, перейдем к настройкам сети, для этого перейдем в раздел Сети. Для сети, которая подключена к сети предприятия указываем Разрешить кластеру использовать эту сеть и Разрешить клиентам подключаться через эту сеть. Для сети хранения данных просто оставим Разрешить кластеру использовать эту сеть, таким образом обеспечив необходимую избыточность сетевых соединений.
На этом настройка кластера закончена. Для работы с кластеризованными виртуальными машинами следует использовать Диспетчер отказоустойчивости кластеров, а не Диспетчер Hyper-V, который предназначен для управления виртуалками расположенными локально.
Чтобы создать виртуальную машину перейдите в раздел Роли в меню правой кнопки мыши выберите Виртуальные машины — Создать виртуальную машину, это же можно сделать и через панель Действия справа.
Прежде всего выберите узел, на котором будет создана виртуальная машина. Каждая виртуалка работает на определенном узле кластера, мигрируя на другие узлы при остановке или отказе своей ноды.
После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN.
Здесь же должен располагаться и виртуальный жесткий диск, вы также можете использовать уже существующие виртуальные жесткие диски, предварительно скопировав их в общее хранилище.
После создания виртуальной машины перейдите в ее Параметры и в пункте Процессоры — Совместимость установите флажок Выполнить перенос на физический компьютер с другой версией процессора, это позволит выполнять миграцию между узлами с разными моделями процессоров одного производителя. Миграция с Intel на AMD или наоборот невозможна.
Затем перейдите в Сетевой адаптер — Аппаратное ускорение и убедитесь, что выбранные опции поддерживаются сетевыми картами всех узлов кластера или отключите их.
Не забудьте настроить автоматические действия при запуске и завершении работы узла, при большом количестве виртуальных машин не забывайте устанавливать задержку запуска, чтобы избежать чрезмерной нагрузки на систему.
Закончив с Параметрами перейдите в Свойства виртуальной машины и укажите предпочтительные узлы владельцев данной роли в порядке убывания и приоритет, машины имеющие более высокий приоритет мигрируют первыми.
На закладке Обработка отказа задайте количество допустимых отказов для виртуальной машины за единицу времени, помните, что отказом считается не только отказ узла, но и потеря пульса виртуальной машины, например, ее зависание. На время настройки и тестов есть смысл указать значения побольше.
Также настройте Восстановление размещения, эта опция позволяет передавать виртуальные машины обратно наиболее предпочтительному владельцу при восстановлении его нормальной работы. Чтобы избежать чрезмерных нагрузок воспользуйтесь опцией задержки восстановления.
На этом настройка виртуальной машины закончена, можем запускать и работать с ней.
Теперь самое время проверить миграцию, для этого щелкните на машине правой кнопкой мыши и выберите Переместить — Динамическая миграция — Выбрать узел. Виртуалка должна переместиться на выбранную ноду не завершая работы.
Каким образом происходит миграция в рабочей обстановке? Допустим нам надо выключить или перезагрузить первый узел, на котором в данный момент выполняется виртуальная машина. Получив команду на завершение работы узел инициирует передачу виртуальных машин:
Завершение работы приостанавливается до тех пор, пока не будут переданы все виртуальные машины.
Когда работа узла будет восстановлена, кластер, если включено восстановление размещения, инициирует обратный процесс, передавая виртуальную машину назад предпочтительному владельцу.
Что произойдет если узел, на котором размещены виртуальные машины аварийно выключится или перезагрузится? Все виртуалки также аварийно завершат свою работу, но тут-же будут перезапущены на исправных узлах согласно списка предпочтительных владельцев.
Как мы уже говорили, прижившийся в отечественной технической литературе термин «отказоустойчивый» неверен и более правильно его было бы переводить как «с обработкой отказа», либо использовать понятие «высокая доступность», которое отражает положение дел наиболее верно.
Кластер Hyper-V не обеспечивает отказоустойчивости виртуальным машинам, отказ узла приводит к отказу всех размещенных на нем машин, но он позволяет обеспечить вашим службам высокую доступность, автоматически восстанавливая их работу и обеспечивая минимально возможное время простоя. Также он позволяет значительно облегчить администрирование виртуальной инфраструктуры позволяя перемещать виртуальные машины между узлами без прерывания их работы.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Что, если сервер «умрет»? Примеры реализации отказоустойчивой системы на 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 учебных часов.
Не откладывайте свое обучение!
Комментарии / обсуждение (28):
ДОбрый день.
Подскажите, для каких целей в консоли кластера может понадобиться добавлять новый кластер в рамках одного центрального сервера? На ИТС когда речь идет об отказоустойчивости и масштабируемости, то оперируют рабочими серверами. Там не нашел ответа на свой вопрос.
Добрый день!
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. В сети достаточно много подробных описаний настройки и работы данного механизма. Если будут конкретные вопросы, задавайте их рамках мастер-группы.