Выполняя вышеуказанную настройку, мы обеспечиваем отказоустойчивость и полную HA?
Конечно, но только для каждого центра обработки данных.
В AWS (и других облаках, я полагаю) у вас дополнительно были бы зоны доступности (AZ), которые географически близки центрам обработки данных, но все еще достаточно изолированы друг от друга, так что отключение от одной зоны не повлияетприложения распределены по нескольким зонам.Чтобы получить действительно высокую доступность, в лучших практиках говорится , что вы бы растянули кластер по AZ *
Кроме того, предпочтительнее было бы 5 Zookeepers, так как вы можете потерять 2 машины и все будет в порядке.
Желательно ли иметь активную активную настройку или активную пассивную настройку и почему?
Если вы активно зеркалируете данные Kafka во вторичный кластер,тогда это не совсем «пассивно», IMO
Я не знаю, как «плавно» перенести клиента Kafka в «отказоустойчивый кластер», фактически не редактируя конфигурации клиента для использования этого «резервного» наборазагрузочных серверов.Кроме того, если данные отправляются в один кластер, но другой недоступен в течение некоторого времени, а затем возвращается, вам необходимо, чтобы ваши приложения-потребители согласовали эти различия в данных тем.
как асинхронно зеркально отображать данные между дата-центрами?
Встроенный в Kafka, есть MirrorMaker.Существуют и другие инструменты, такие как Confluent Replicator, который добавляет дополнительные функции высокой доступности, которые MirrorMaker (и аналогичные инструменты зеркального отображения Kafka) в настоящее время не предлагают.
Confluent недавно обновил свой технический документ, который описывается как
- практическое руководство по настройке нескольких кластеров Apache Kafka, чтобы в случае возникновения сценария бедствия у вас был план восстановления после сбоя, восстановления после сбоя,и в конечном итоге успешное восстановление
Вы можете скачать его здесь