Konfiguracja topologii burzowej

Question

W jaki sposób udostępniasz niestandardową konfigurację topologii burzowej? Na przykład, jeśli mam zbudowaną topologię, która łączy się z klastrem MySQL i chcę mieć możliwość zmiany serwerów, z którymi muszę się połączyć bez ponownej kompilacji, w jaki sposób mogę to zrobić? Moim preferencją byłoby użycie pliku konfiguracyjnego, ale moim zmartwieniem jest to, że sam plik nie jest wdrażany w klastrze, w związku z czym nie zostanie uruchomiony (chyba że rozumiem, w jaki sposób działa klaster, jest wadliwy). Jedyny sposób, jaki dotychczas widziałem, aby przekazać opcje konfiguracyjne do topologii burzy w środowisku wykonawczym, to parametr wiersza polecenia, ale jest to kłopotliwe, gdy uzyskasz dużą liczbę parametrów.

Jedna myśl polegała na wykorzystaniu skryptu powłoki, aby odczytać plik w zmiennej i przekazać zawartość tej zmiennej jako ciąg do topologii, ale chciałbym, aby było to trochę bardziej czyste, jeśli to możliwe.

Czy ktoś jeszcze to napotkał? Jeśli tak, jak to rozwiązałeś?

EDIT: Wydaje

potrzebować, aby zapewnić więcej wyjaśnień. Mój scenariusz jest taki, że mam topologię, którą chcę móc wdrażać w różnych środowiskach bez konieczności rekompilacji. Normalnie utworzyłbym plik konfiguracyjny, który zawierałby takie parametry, jak parametry połączenia z bazą danych i które zostały przekazane. Chciałbym wiedzieć, jak zrobić coś takiego w Storm.

Answer 1

To, co może ci najbardziej pomóc, to zapisanie konfiguracji w zmiennym pliku wartości kluczy (s3, redis itp.), A następnie wciągnięcie go do konfiguracji połączenia z bazą danych, z którego następnie korzystasz (zakładam, że już jesteś planowanie, aby ograniczyć częstotliwość rozmawiania z bazą danych, aby narzut związany z uzyskaniem tej konfiguracji nie był wielkim problemem). Ten projekt pozwala na bieżąco zmieniać połączenie z bazą danych, bez konieczności nawet ponownego wdrażania topologii.

Answer 2

Chodzi o to, że kiedy budujesz swoją topologię, tworzysz instancje swoich wylewek i śrub (między innymi) i te instancje są serializowane i dystrybuowane do właściwych miejsc w klastrze. Jeśli chcesz skonfigurować zachowanie dziobka lub śruby, robisz to podczas tworzenia topologii przed jej przesłaniem, a robisz to ustawiając zmienne instancji na śrubie lub wylewce, które z kolei sterują pożądanym konfigurowalnym zachowaniem.

Answer 3

Możesz określić konfigurację (zazwyczaj przez plik yaml), którą przesyłasz wraz z topologią. Jak sobie z tym radzimy w naszym własnym projekcie, mamy oddzielne pliki konfiguracyjne do rozwoju i jedno do produkcji, a wewnątrz przechowujemy nasz serwer, redis i db IPs i Porty itd. Następnie, gdy uruchomimy nasze polecenie, aby zbudować słoik i przesłać topologia do burzy zawiera poprawny plik konfiguracyjny w zależności od środowiska wdrażania. Śruby i wyloty po prostu odczytują konfigurację, której wymagają od mapy StormConf, która jest przekazywana im w metodzie prepare() śruby.

Od http://storm.apache.org/documentation/Configuration.html:

Każda konfiguracja ma domyślną wartość określoną w defaults.yaml w kodzie burzy. Możesz zastąpić te konfiguracje, definiując storm.yaml w ścieżce klas Nimbus i nadzorców. Na koniec możesz zdefiniować konfigurację specyficzną dla topologii, którą przesyłasz wraz z topologią podczas korzystania z StormSubmitter. Jednak konfiguracja specyficzna dla topologii może tylko zastąpić konfigurację z prefiksem "TOPOLOGY".

Burza 0.7.0 i kolejne pozwala zastąpić konfigurację na podstawie na śrubę/na wylewkę.

Zobaczysz również na http://nathanmarz.github.io/storm/doc/backtype/storm/StormSubmitter.html, że submitJar i submitTopology przekazuje mapę o nazwie conf.

Mam nadzieję, że to się zaczyna.

Answer 4

I twarz ten sam problem jak u zrobił, i tu jest moja skomplikowane rozwiązanie:

Użyj prostego pliku Java jako plik konfiguracyjny, powiedzmy topo_config.java, to wygląda:

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; 
    // ... 
} 

ten plik jest umieścić w folderze skonfigurować, a następnie napisać skrypt, który będzie powiedzieć compile.sh skopiować go do właściwego opakowania i robić rzeczy kompilacji, wygląda następująco:

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

Konfiguracja uzyskuje bezpośrednio:

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

Answer 5

I rozwiązać ten problem właśnie dostarczanie config w kodzie:

config.put(Config.TOPOLOGY_WORKER_CHILDOPTS, SOME_OPTS); 

starałem się zapewnić topologii specyficzne storm.yaml ale to nie działa. Popraw mnie, jeśli sprawisz, że zadziała burza.yaml.

Aktualizacja:
Dla każdego, kto chce wiedzieć, co SOME_OPTS jest, to jest od Satish Duggana na listę mailingową: Burza

Config.TOPOLOGY_WORKER_CHILDOPTS: opcje, które mogą nadpisać WORKER_CHILDOPTS dla topologii . Można skonfigurować żadnych opcji java jak pamięci, GC itp

W twoim przypadku może to być

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

Answer 6

widzieliśmy ten sam problem i rozwiązać go poprzez dodanie poniżej za topologii

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"); 

Sprawdzono również przy użyciu interfejsu Nimbus, jak pokazano poniżej.

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