Skip To Content

Стратегии для масштабируемости, надежности и отказоустойчивости

Стратегия Silo (изоляции)

Стратегия Silo заключается в том, чтобы разделить рабочую нагрузку и распределить ее на несколько разных компьютеров ArcGIS GeoEvent Server. На основе этой стратегии с использованием загрузки потока событий, исторической зависимости событий и метода доставки событий для каждого силоса определяется конфигурация с ограниченным набором задач. В Silo ни один компьютер GeoEvent Server ничего не знает о других компьютерах, и каждый компьютер обрабатывает события, которые он получает, отдельно. Как правило, стратегия Silo используется в ситуациях, когда основной задачей является надежность и/или масштабируемость. Кроме того, стратегия Silo сама по себе не подразумевает какой-либо стратегии балансировки нагрузки (см. Ниже Стратегия маршрутизации событий).

Репликация Silo: active-passive

В архитектуре Silo active-passive конфигурируются два или более идентичных компьютеров. Один компьютер определяется как активный, в то время как другие, пассивные компьютеры либо выключены, либо каким-то образом изолированы. Если активный компьютер выходит из строя, выбирается пассивный компьютер и активируется в качестве новой активной системы. Механизм администрирования аварийного переключения в случае отказа в данном документе не рассматривается, но перехват управления может быть выполнен вручную или автоматизированным способом, как это обычно делается в большинстве виртуальных сред.

Репликация Silo: active-active

В архитектуре Silo active-active конфигурация группы компьютеров идентичная, и компьютеры могут работать параллельно. Ни один компьютер не идентифицируется как активный или пассивный, и вся группа компьютеров работает одновременно. Стратегия отработки отказа не требуется, поскольку все компьютеры работают параллельно, однако мониторинг отказа компьютеров по-прежнему необходим для контроля работы компьютеров должным образом.

Особую озабоченность в среде active-active вызывает дублирование данных. Если группа, состоящая из N компьютеров, будет настроена одинаково, то можно ожидать, что каждое событие будет обрабатываться параллельно N раз. Эта дополнительная нагрузка может создать нагрузку на связанные системы, такие как базы данных и сети. Ключом к решению задачи, чтобы по прибытии в пункт назначения данные не дублировались, могла бы стать методология идентификации записей уникальным образом, однако это не снижает общую нагрузку на систему.

Стратегия маршрутизации событий

Стратегия маршрутизации событий строится поверх стратегии силоса путем добавления в систему дополнительного компонента – балансировщика, обычно балансировщика нагрузки или маршрутизируемой очереди сообщений. Когда в архитектуру перед группой идентично настроенных компьютеров GeoEvent Server будет включен балансировщик нагрузки, события можно будет по отдельности направлять на компьютеры с одинаковыми сервисами. При таком подходе компьютеры будут работать как группа с балансировщиком нагрузки, который отвечает за отправку событий на каждый отдельный компьютер. Как правило, стратегия силоса используется в ситуациях, когда основной задачей является надежность и/или масштабируемость. Эта стратегия требует, чтобы данные о событиях выталкивались (а не вытягивались) на сайт.

Примечание:

Развертывания GeoEvent Server, которые вытягивают события, не могут использовать первые две стратегии маршрутизации событий, полагаясь на внешний балансировщик нагрузки или очереди сообщений. Если развертывание GeoEvent Server вытягивает (опрашивает) данные, см. представленный ниже раздел Репликация силоса с помощью разбиения событий.

Балансировщик нагрузки

Использование балансировщика нагрузки позволяет набору вытолкнутых событий балансироваться по всему массиву одинаково настроенных и активно отслеживаемых компьютеров GeoEvent Server. По мере поступления событий балансировщик нагрузки назначает каждое событие другому компьютеру в кластере. По сути, эта конфигурация сайта состоит из балансировщика нагрузки спереди и находящейся за ним группы изолированных компьютеров GeoEvent Server в конфигурации active-active (причем каждый компьютер настроен одинаково).

Кластер очереди сообщений

Добавление кластера Kafka в эту архитектуру позволяет сбалансировать набор выталкиваемых событий по массиву активно отслеживаемых компьютеров GeoEvent Server, где у каждого компьютера может быть разная конфигурация. По мере поступления событий кластер Kafka назначает каждое отдельное событие разным темам сообщений в зависимости от уникального идентификатора(-ов) события(-ий). Каждый компьютер GeoEvent Server отслеживает одну или несколько тем сообщений и обрабатывает эти события.

По сути, эта конфигурация сайта состоит из кластера Kafka спереди и находящейся за ним группы изолированных компьютеров GeoEvent Server в конфигурации active-active. Эта конфигурация отличается от приведенного выше решения с балансировщиком нагрузки тем, что здесь каждое событие может быть направлено на определенную конфигурацию и/или определенный компьютер GeoEvent Server. Это решение выигрывает при обработке событий с исторической зависимостью.

Репликация Silo с помощью разбиения событий

Разбиение событий с использованием репликации Silo – это особый подход, который может использоваться при масштабировании (увеличении) производительности архитектуры Silo. Это особенно полезно, когда GeoEvent Server вытягивает события, а не выталкивает.

Каждый отдельный компьютер настроен идентично по отношению к рабочему процессу обработки, но для обработки каждому назначается определенное подмножество событий. Как правило, это достигается путем изменения конфигурации каждого отдельного компьютера для запроса или принятия настроенного подмножества данных событий, что обычно зависит от Track ID данных этих событий или от какого-либо другого глобального уникального идентификатора. В этом случае требуется разбиение потока событий, например, с помощью условия WHERE в запросе.