Что такое кластер горячего резервирования
Криптошлюз Vipnet Failover или как не надо реализовывать отказоустойчивость
Отмечу, что сам по себе Vipnet Coordinator Linux неплох, и всё портит сама схема горячего резервирования.
Весь кластер, с точки зрения других компьютеров сети, имеет один IP-адрес на каждом из своих сетевых интерфейсов. Этим адресом обладает сервер, находящийся в данный момент в активном режиме. Сервер, находящийся в пассивном режиме, имеет другой IP-адрес, который не используется другими компьютерами для связи с кластером. В отличие от адресов активного режима, в пассивном режиме каждый из серверов имеет свой собственный адрес на каждом из интерфейсов, эти адреса для двух серверов не совпадают.
В конфиге failover.ini содержатся 3 типа разделов параметров. В разделе [channel] описываются IP-адреса резервируемых интерфейсов:
В разделе [network] описываются параметры резервирования:
В [sendconfig] прописывается адрес сетевого интерфейса второго сервера, по которому будет синхронизироваться работа кластера:
Опять же приведу алгоритм резервирования из документации:
Алгоритм работы на активном сервере следующий. Через каждые checktime секунд проводится проверка работоспособности каждого из приведенных в конфигурации интерфейсов. Если параметр checkonlyidle установлен в yes, то анализируется входящий и исходящий сетевой трафик, прошедший через интерфейс. Если разница в количестве пакетов между началом и концом интервала положительна, то считается, что интерфейс функционирует нормально, и счетчик отказов для этого интерфейса обнуляется. Если в течение данного интервала не было послано и принято ни одного пакета, то включается дополнительный механизм проверки, заключающийся в посылке эхо-запросов до ближайших маршрутизаторов. Если параметр checkonlyidle установлен в no, то механизм дополнительной проверки используется вместо основного, то есть каждые checktime секунд посылаются пакеты до адресов testip. Затем в течение времени timeout ожидаются ответы. Если на каком-либо интерфейсе ответа нет ни от одного адреса testip, то его счетчик сбоев увеличивается на единицу. Если хотя бы на одном интерфейсе счетчик сбоев не равен нулю, то немедленно посылаются новые пакеты до всех testip и ожидается ответ в течение timeout. Если в процессе новых посылок на интерфейс, счетчик сбоев которого не равен нулю, приходит ответ, его счетчик сбоев обнуляется. Если после какой-либо посылки счетчики сбоев на всех интерфейсах становятся равны нулю, то происходит возврат в основной цикл, новое ожидание в течение checktime и так далее. Если же после какого-то числа новых посылок счетчик сбоев хотя бы одного интерфейса достигнет значения channelretries, то фиксируется полный отказ интерфейса и начинается перезагрузка системы. Таким образом, максимальное время неработоспособности интерфейса до того, как система защиты от сбоев сделает вывод об этом, равно checktime + (timeout * channelretries).
На пассивном сервере алгоритм немного отличается. Раз в checktime секунд производится удаление записей в системной ARP-таблице для всех activeip. Затем посылаются UDP-запросы со всех интерфейсов на адреса activeip, в результате чего система сначала посылает ARP-запрос и только в случае получения ответа посылает UDP-запрос. После окончания интервала ожидания ответа timeout проверяется наличие ARP-записи для каждого activeip в системной ARP-таблице, по наличию которой делается вывод о работоспособности соответствующего интерфейса на активном сервере. Если ни от одного интерфейса не был получен ответ, счетчик сбоев (он один на все интерфейсы) увеличивается. Если хотя бы от одного интерфейса ответ был получен, счетчик сбоев обнуляется. Если счетчик сбоев достигает значения activeretries, то производится переключение в активный режим. Максимальное время, проходящее от перезагрузки активного сервера до обнаружения пассивным сервером этого факта, равно checktime + (timeout * activeretries).
Общее время неработоспособности системы при сбое может быть немного больше, чем checktime * 2 + timeout * (channelretries + activeretries). Это связано с тем, что после начала перезагрузки сбойного сервера система переводит его интерфейсы в нерабочее состояние не сразу, а через некоторое время, после остановки других подсистем. Поэтому, например, если проверяются два интерфейса и только на одном произошел сбой, то адрес второго интерфейса будет доступен еще некоторое время, в течение которого пассивный сервер будет получать от него ответы. Обычно время от начала перезагрузки до выключения интерфейсов не превышает 30 секунд, однако оно может сильно зависеть от быстродействия компьютера и количества работающих на нем сервисов.
На первый взгляд всё верно, как только с активным сервером неполадки, он перезагружается, а его место занимает пассивный. Что же мы имеем на практике?
Получается, что отказоустойчивость файловера возможна лишь в сферическом вакууме, где вся сетевая инфраструктура работает без сбоев. Кто-то может сказать, что это вынужденная мера, но если что-то случиться с одним из серверов, например, вылетит сетевой интерфейс, то он перезагрузится, его работоспособность восстановится и алгоритм резервирования докажет свою полезность. Однако, на практике был случай когда один из интерфейсов файловера действительно заглючил, и он стал перезагружаться согласно описанной выше схеме, при этом проблема после перезагрузки никуда не делась. Чтобы избавиться от глюка пришлось вручную отключить питание, так что и в этом случае отказоустойчивость видна лишь на бумаге.
Всё это можно было исправить, если бы алгоритм включал в себя ещё одно условие: активный сервер не должен перезагружаться, если пассивный выключен. Вроде бы нехитрое условие, обеспечивающее реальную отказоустойчивость, так и не было добавлено разработчиками. Я могу лишь предполагать, что это связано с необходимостью внесения изменений в ядро и его повторной сертификации.
В случае же исправного сетевого окружения и серверного оборудования аптайм серверов был практически непрерывным. Один из первых файловеров, который мне пришлось установить работает уже 3 года и за это время схема горячего резервирования отрабатывала только во время модернизации ПО или из-за общих технических работ в ЦОДе. В общем реальная польза от такой схемы возможна лишь в случае аппаратного сбоя в одной из нод кластера, чего в моей практике ещё не случалось.
Была надежда, на Vipnet Cluster Windows, но Инфотекс, к сожалению, его не осилил, а жаль, схема резервирования была очень многообещающей.
В общем, мой совет таков, если вам не нужен отказоустойчивый криптошлюз для галочки, то с файловером лучше не заморачиваться, а пользоваться обычным Vipnet Linux координатором, он сам по себе достаточно надёжен, особенно если его не трогать 😉
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂
Вариант №1. Подключение с помощью кластера горячего резервирования
Для организации подключения кластера горячего резервирования ViPNet следует:
1. Обеспечить выделение IP адресов в сети, в соответствии с типовой схемой и таблицей (нумерация в таблице соответствует нумерации в типовой схеме):
IP адрес/маска
Назначение
Активный и физические адреса внешних интерфейсов кластера. Могут быть как из частного, так и из публичного адресного пространства, но должны принадлежать одной подсети.
Активный и физические адреса внутренних интерфейсов кластера. Должны принадлежать одной подсети, но ip ext и ip int обязательно должны принадлежать разным подсетям.
Адрес шлюза по умолчанию в сети, в которую включаются внешние интерфейсы кластера.
Публичный транслируемый адрес, через который осуществляется доступ к активному внешнему адресу кластера.
Указывается в случае использования частных адресов на внешних интерфейсах кластера.
Адрес шлюза для доступа к внутренним ресурсам.
Указывается в случае нахождения ресурсов и внутренних интерфейсов кластера в разных сетях.
Адрес АРМа взаимодействующий с серверами ИС ГИС ГМП/КЭП.
При подключении нескольких АРМов ip res транслирует ресурсы до активного внутреннего адреса кластера.
2. Обеспечить физическое размещение 2-х мест размером 19 дюймов Rack 1U глубиной не менее 480 мм, на площадке.
3. Обеспечить подключение оборудования максимальной потребляемой мощностью 200 Вт (каждый) к сети гарантированного электропитания питания 220 В с помощью кабеля типа С13 – СЕЕ7/7 (евровилка).
4. Обеспечить возможность подключения интерфейсов Ethernet Base T 100/1000 ПАКов к сетевому оборудованию.
5. Обеспечить связность на втором уровне модели OSI/ISO внутренних, отдельно внешних и отдельно, интерфейсов горячего резервирования ПАКов, другими словами, размещение двух физических внутренних интерфейсов в одном широковещательном сегменте, внешних в другом, интерфейсов горячего резервирования в третьем.
6. Обеспечить отсутствие логических препятствий для прохождения трафика по протоколу UDP и порту 55777 между внешним активным адресом кластера (ip ext active) и адресами криптошлюзов ИС ГИС ГМП/КЭП.
7. При использовании частных адресов на внешних интерфейсах кластера – обеспечить статическую трансляцию адреса частного внешнего активного адреса кластера (ip ext active) в публичный адрес (ip fw) и трансляцию публичного адреса (ip fw) в частный внешний активный адрес кластера (ip ext active) по протоколу UDP и порту 55777.
9. Обеспечить маршрутизацию пакетов АРМов через внутренний активный адрес кластера (ip int active) для адресов:
10. Обеспечить выделение на внешних и внутренних интерфейсах адресацию, не пересекающуюся с сетью Электронного Правительства.
ViPNet CLUSTER
Програмнный комплекс ViPNet Cluster
Следуя современным потребностям бизнеса и, используя свой опыт в разработке и построении решений информационной безопасности, компания ИнфоТеКС разработала программный комплекс ViPNet Cluster, решающий проблему организации высоконадежных защищенных каналов связи.
Что такое ViPNet Cluster
Обеспечение высокой доступности
ПК ViPNet Cluster способен обрабатывать сетевой трафик, поступающий из нескольких сетей, непосредственно подключенных к нему. Количество сетей, подключаемых к ПК ViPNet Cluster, не ограничено. Все элементы кластера представлены в каждой из подключенных сетей одним и тем же IP-адресом, который одновременно активен на всех элементах кластера. Это обеспечивает моментальное перераспределений функций в кластере в случае отказа одного из элементов.
ПК ViPNet Cluster позволяет создать инфраструктуру, которая гарантирует бесперебойность передачи данных, до тех пор, пока хотя бы один из элементов кластера работоспособен.
Рекомендуется иметь в составе кластера не менее трех элементов кластера. В этом случае достигается максимальная эффективность контроля работоспособности каждого из элементов кластера.
Обеспечение высокой надежности посредством распределения нагрузки
Все элементы (серверы), входящие в состав ПК ViPNet Cluster, постоянно являются активными. Обработка трафика выполняется всеми элементами ПК ViPNet Cluster одновременно. Такой подход является наиболее надежным решением, потому что выход из строя одного или более элементов из состава ПК ViPNet Cluster не приводит к потере соединения, т.к. функции отказавшего элемента перераспределяются на оставшиеся элементы и ПК ViPNet Cluster в целом продолжает выполнять свои функции.
Обеспечение производительности кластера
Распределение нагрузки по шифрованию (расшифрованию) трафика на несколько элементов кластера снижает нагрузку с процессоров каждого из элементов, что позволяет использовать в составе ПК ViPNet Cluster серверы невысокой производительности и добиваться даже в этом случае практически абсолютной надежности и высокой производительности кластера в целом.
Архитектура текущей версии ПК ViPNet Cluster предполагает балансировку трафика в каждый данный момент только одним элементом кластера для всех подключенных сетей. В связи с этим суммарная пропускная способность текущей версии ПК ViPNet Cluster ограничивается пропускной способностью балансировщика (один из элементов кластера выполняет функции балансировщика нагрузки) и в зависимости от производительности элемента-балансировщика может достигать для TCP-трафика 250 Мбит/сек.
Как работает ПК ViPNet Cluster
В состав ПК ViPNet Cluster Windows входит следующее программное обеспечение:
В архитектуре ПК ViPNet Cluster используются следующие понятия:
Архитектура ПК ViPNet Cluster
Роли элементов кластера:
Конфигурация кластера:
Система горячего резервирования
Система горячего резервирования, реализованная в ПК ViPNet Cluster,предназначена для непрерывного поддержания работоспособности кластера в случае сбоя или отказа любого из элементов кластера, а также автоматического подключения элемента в случае его восстановления.
Высокая отказоустойчивость кластера достигается благодаря следующему набору свойств:
Сценарий использования ПК ViPNet Cluster
ПК ViPNet Cluster разработан для организации круглосуточного бесперебойного защищенного доступа к ресурсам компании. Поэтому мы предлагаем использовать данное решение для защиты больших локальных сетей, серверов баз данных, online сервисов, банковских систем, автоматизированных систем класса CRM, ERP и т.д., т.е. тех сетей и отдельных систем, доступ к которым необходим пользователям круглосуточно.
Преимущества
Сертификация
Отказоустойчивость
Отказоустойчивость системы обеспечивается при работе в клиент-серверном варианте с использованием кластера серверов. Система обеспечивает бесперебойную работу пользователей при программных и аппаратных сбоях в кластере серверов.
Такие события, как выход из строя рабочего сервера (в том числе и центрального сервера), аварийное (или плановое) завершение рабочего процесса или менеджера кластера не влияют на работу пользователей. Пользователи продолжают работать так, как будто ничего не произошло.
В случае физического разрыва соединения пользователя с кластером (например, уборщица выдернула провод) и последующего его восстановления пользователь может продолжить работу без повторного соединения с информационной базой и без потери своих текущих данных.
Резервирование кластера
Несколько кластеров могут быть объединены в группу резервирования. Кластеры, находящиеся в одной группе резервирования синхронизируются автоматически.
При выходе из строя активного кластера активным становится следующий работоспособный кластер группы. При восстановлении работоспособности кластера, который находится в группе раньше активного, активность передается ему после автоматической синхронизации данных.
Резервирование рабочих серверов
Можно задавать уровень отказоустойчивости кластера как количество рабочих серверов, которые могут одновременно выйти из строя, и это не приведет к аварийному завершению работы пользователей. Резервные сервисы запускаются автоматически в количестве, необходимом для обеспечения заданной отказоустойчивости; в реальном режиме времени выполняется репликация активного сервиса на резервные.
Резервирование рабочих процессов
Каждому рабочему процессу можно указать вариант его использования: Использовать, Использовать как резервный, Не использовать.
Если какой-либо рабочий процесс завершился аварийно, кластер запускает вместо него один из неактивных резервных процессов и автоматически перераспределяет имеющуюся нагрузку на него.
Устойчивость к обрыву канала связи
Кластер «запоминает» подключившихся пользователей и состояние выполняемых ими действий благодаря тому, что для каждого пользователя создается собственный сеанс.
В случае потери физического соединения кластер будет ожидать восстановления соединения с этим пользователем. В подавляющем большинстве случаев после восстановления соединения пользователь сможет продолжить работу с того «места», на котором она была прекращена. При этом не потребуется повторное подключение к информационной базе.