Конфигурация топологии шторма

Как вы предоставляете настраиваемую конфигурацию топологии шторма? Например, если у меня есть топология, которую я построил, которая подключается к кластеру MySQL, и я хочу иметь возможность изменять, какие серверы мне нужно подключить без перекомпиляции, как бы я это сделал? Мое предпочтение будет заключаться в использовании файла конфигурации, но я беспокоюсь, что сам файл не развертывается в кластере, поэтому он не будет запущен (если мое понимание того, как работает кластер, является ошибочным). Единственный способ, с помощью которого я до сих пор видел варианты конфигурации в топологии шторма во время выполнения, - это параметр командной строки, но это бесполезно, когда вы получаете большое количество параметров.

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

Кто-нибудь еще столкнулся с этим? Если да, то как вы его решили?

EDIT:

Кажется, необходимо предоставить больше разъяснений. Мой сценарий заключается в том, что у меня есть топология, которую я хочу развернуть в разных средах, не перекомпилируя ее. Обычно я создаю файл конфигурации, который содержит такие параметры, как параметры подключения к базе данных, и передал их. Я хотел бы знать, как сделать что-то подобное в Storm.

Ответ 1

Вы можете указать конфигурацию (обычно с помощью файла yaml), который вы отправляете с вашей топологией. Как мы справляемся с этим сами в нашем собственном проекте, у нас есть отдельные файлы конфигурации для разработки и один для производства, а внутри него мы храним наши серверы, redis и db IPs и порты и т.д. Затем, когда мы запускаем нашу команду, чтобы построить банку и отправить топология для штурма включает правильный файл конфигурации в зависимости от среды развертывания. Болты и носики просто считывают конфигурацию, которую они требуют от карты stormConf, которая передается им в методе bolt prepare().

Из http://storm.apache.org/documentation/Configuration.html:

Каждая конфигурация имеет значение по умолчанию, определенное в defaults.yaml в кодовой базе Storm. Вы можете переопределить эти конфигурации, указав storm.yaml в пути классов Nimbus и супервизоров. Наконец, вы можете определить конфигурацию, специфичную для топологии, которую вы отправляете вместе с вашей топологией при использовании StormSubmitter. Однако конфигурация, зависящая от топологии, может только переопределять конфигурации с префиксом "ТОПОЛОГИЯ".

Storm 0.7.0 и далее позволяет вам переопределить конфигурацию на основе каждого затвора/на носик.

Вы также увидите на http://nathanmarz.github.io/storm/doc/backtype/storm/StormSubmitter.html, что submitJar и submitTopology передается карта с именем conf.

Надеюсь, вам это поможет.

Ответ 2

Я решил эту проблему, просто указав конфигурацию в коде:

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, SOME_OPTS);

Я попытался предоставить топологию storm.yaml, но она не работает. Исправьте меня, если вы заработаете, чтобы использовать storm.yaml.

Update:
Для тех, кто хочет знать, что такое SOME_OPTS, это от Satish Duggana в списке рассылки Storm:

Config.TOPOLOGY_WORKER_CHILDOPTS: параметры, которые могут отменяться WORKER_CHILDOPTS для топологии. Вы можете настроить любые параметры java как память, gc и т.д.

В вашем случае это может быть

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, "-Xmx1g");

Ответ 3

Что может на самом деле служить вам лучше всего - сохранить конфигурацию в хранилище измененных ключей (s3, redis и т.д.), а затем потянуть это, чтобы настроить соединение с базой данных, которое вы затем используете (я предполагаю, что вы уже планируете чтобы ограничить, как часто вы разговариваете с базой данных, чтобы накладные расходы на получение этой конфигурации не было большим делом). Эта конструкция позволяет вам менять соединение с базой данных "на лету", не требуя даже перераспределения топологии.

Ответ 4

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

Ответ 5

я также столкнулся с тем же issue.I решить ее путем настройки NFS в моем кластере и я поставил этот конфигурационный файл в общей папке, так что он будет доступен для всех кластерных machines.Its очень просты в настройке NFS в системе Linux <а href= "https://www.digitalocean.com/community/articles/how-to-set-up-an-nfs-mount-on-centos-6" rel= "nofollow" > .

Ответ 6

Я сталкиваюсь с той же проблемой, что и у, и вот мое сложное решение:

Используйте простой файл java в качестве файла конфигурации, скажем topo_config.java, он выглядит так:

package com.xxx
public class topo_config {
    public static String zk_host = "192.168.10.60:2181";
    public static String kafka_topic = "my_log_topic";
    public static int worker_num = 2;
    public static int log_spout_num = 4;
    // ...
}

Этот файл помещается в мою папку конфигурации, а затем записывает script, скажем compile.sh, который скопирует его в нужный пакет и сделает материал компиляции, выглядит так:

cp config/topo_config.java src/main/java/com/xxx/
mvn package

Конфигурация достигается напрямую:

Config conf = new Config();
conf.setNumWorkers(topo_config.worker_num);

Ответ 7

мы видели ту же проблему и решили ее, добавив ниже для топологии

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, "-Xmx4096m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSConcurrentMTEnabled -Djava.net.preferIPv4Stack=true");

Также проверяется с помощью Nimbus UI, как показано ниже.

topology.worker.childopts   -Xmx4096m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewSize=128m -XX:CMSInitiatingOccupancyFraction=70 -XX:-CMSConcurrentMTEnabled -Djava.net.preferIPv4Stack=true

Ответ 8

Вы можете передать переменные окружения в команде storm jar, которые вы можете использовать в конфигурации шторма времени выполнения

Config remoteClusterTopologyConfig = new Config();
remoteClusterTopologyConfig.setNumWorkers(System.getProperty("num_workers"));