Краткий Best practice построения кластерных решений F5

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

«Непрерывность обслуживания», «всегда доступный», «согласованный уровень SLA», «единая точка отказа» — мы неоднократно сталкивались с этими условиями, когда необходимо учитывать высокую доступность веб-сайта или приложения.

Главной задачей отказоустойчивой схемы, является исключение простоя приложения. Любой инцидент, связанный с внешним вмешательством или внутренним сбоем в работе, должен оставаться незамеченным для пользователя. Для обеспечения этой «незаметности» и непрерывной работы предназначено устройство публикации и защиты от F5 которое изначально имеет все необходимые механизмы за счет использования избыточной физической и логической инфраструктуры.

За функцию высокой доступности в F5 BIG-IP отвечает служба Device service clustering (DSC), которая дает возможность:

  • добавлять программные и аппаратные ресурсы, без остановки системы и масштабных архитектурных преобразований.
  • обеспечивать бесперебойную работу системы, при выходе из строя одного или нескольких устройств.
  • синхронизировать данные между устройствами.
  • эффективно распределять клиентские запросы по устройствам.
  • выполнять регламентные работы (например обновление ПО) без простоев.
  • сохранять состояния сессий в момент переключения между устройствами в отказоустойчивой схеме.

Решения F5 еще не этапе разработки изначально спроектированы по принципу наличия избыточного сервера F5. При этом отказ любого из компонентов не прерывает работу системы. Все это работает в любое время без привязки к производителю сетевого или серверного оборудования:

  • зеркалирование сессий (MAC, TCP, SSL, привязку сессий по разным критериям). Сессии на активном устройстве F5 дублируются на standby системе. В случае сбоя standby система может начать обработку соединений немедленно, без прерывания.
  • синхронизация конфигурации (политик безопасности, политик доступа) обеспечение актуальную конфигурации на всех участниках кластера в любой время.
  • корректная обработка при сбое сети без перестроения (MAC и IP не изменяются) а также наличие резервных сетевых интерфейсов для корректной работы кластера, в случае сбоя сети.

Существует два сценария построения кластера F5

  • Active/Standby


В этом режиме одна система активна и обрабатывает весь трафик, а вторая находится в режиме ожидания (резервная не обрабатывает трафик). Если в активном устройстве F5 обнаружен сбой, весь трафик будет перемещен на резервную, поскольку резервная система уже имеет всю конфигурацию и зеркалирование сессий, резервная система становится активной.


  • Active/Active


В этом режиме оба системы могут быть активны одновременно. В полной мере используется имеющееся оборудование. Этот тип настройки в основном используется там, где ограничено аппаратное обеспечение F5, а требования к нагрузке большие. Но в данном случае при выходе из строя одного из серверов, часть сервисов станет недоступным.


В зависимости от особенностей работы приложения, требований к его публикации SLA и нагрузки выбирается схема работы устройств F5 и их количество в каждом ЦОД.

Вывод. Для обеспечения гарантированной отказоустойчивости подкрепленной SLA F5 рекомендует построение отказоустойчивых конфигураций минимум из 2-х устройств. В основном используется 2 варианта которые имеют свои преимущества и недостатки:

Подход 1. Построение кластера в двух или трех ЦОД и распределение трафика между ними при помощи DNS. Плюсом данного варианта является малое количество устройств F5 — по одному устройству в каждом ЦОД. но низкое время переключение между ЦОД которое варьируется от минут до нескольких часов в зависимости от настроек. Такое время переключение обусловлено особенностями работы протокола DNS но позволяет использовать малое количество устройств F5.

Подход 2. Создание кластера в каждому ЦОД минимум из 2-х виртуальных или аппаратных устройств F5. Плюсом данного подхода является мгновенное переключения приложения без обрывов сессии пользователя, но требует установку минимум 2-х устройств F5 в каждом ЦОД.

В зависимости от особенностей работы приложения и требований к его доступности стоит выбирать между подходом 1 или подходом 2 с учетом особенностей одного или второго варианта. В случае, когда F5 публикует и защищает приложения с требуемым уровнем SLA 99.9 (почти 9 часов простоя в год) и выше необходимо использовать эти подходы вместе. При подборе решения F5 и его внедрении также стоит учитывать режим работы active/active или active/passive. Важно отметить, что эти режимы могут быть реализованы как в одном ЦОД (разные устройства F5 для разных приложений) для максимальной утилизации устройств F5, так и между ЦОД чтобы оба ЦОД обрабатывали трафик приложений (active-active DC) или только один (Disaster DC).
Источник: https://habr.com/ru/post/546896/


Интересные статьи

Интересные статьи

В этой статье мы расскажем, как оптимизировать крупный проект в «Битрикс24» и увеличить его производительность в 3 раза, изменяя настройки MySQL и режим питания CPU. Дано Корпоративн...
Наступают длинные зимние каникулы. Во многих IT-компаниях уже объявлен режим freeze - заморозка новых активностей до конца праздников. Особенно длительной будет пауза у т...
C++ — язык запутанный, и существенным его недостатком является сложность создания изолированных блоков кода. В типовом проекте всё зависит от всего. Эта статья показывает, как писать высокоизолир...
Если Вы используете в своих проектах инфоблоки 2.0 и таблицы InnoDB, то есть шанс в один прекрасный момент столкнуться с ошибкой MySQL «SQL Error (1118): Row size too large. The maximum row si...
Реализация ORM в ядре D7 — очередная интересная, перспективная, но как обычно плохо документированная разработка от 1с-Битрикс :) Призвана она абстрагировать разработчика от механики работы с табл...