Obecnie szukam dobrego oprogramowania pośredniego, aby zbudować rozwiązanie dla systemu monitorowania i konserwacji. Mamy zadanie polegające na monitorowaniu, gromadzeniu danych i utrzymywaniu rozproszonego systemu składającego się z maksymalnie 10 000 pojedynczych węzłów.

System jest zgrupowany w grupy po 5-20 węzłów. Każda grupa tworzy dane (jako zespół), przetwarzając przychodzące dane z czujników. Każda grupa ma dedykowany węzeł (niebieskie pola) działający jako fasada / proxy dla grupy, eksponujący dane i stan z grupy na świat zewnętrzny. Klastry te są geograficznie oddzielone i mogą łączyć się ze światem zewnętrznym za pośrednictwem różnych sieci (jedna może działać na światłowodzie, a druga na 3G / satelita). Prawdopodobnie wystąpią zarówno krótsze (sekundy / minuty), jak i dłuższe (godziny) przestoje. Dane są przechowywane lokalnie przez każdy klaster.

Dane te muszą być gromadzone (w sposób ciągły i niezawodny) przez zewnętrzne i scentralizowane serwery (zielone pola) w celu dalszego przetwarzania, analizy i przeglądania przez różnych klientów (pomarańczowe pola). Ponadto musimy monitorować stan wszystkich węzłów za pośrednictwem węzła proxy każdej grupy. Nie jest wymagane monitorowanie każdego węzła bezpośrednio, nawet jeśli byłoby dobrze, gdyby oprogramowanie pośrednie mogło to obsługiwać (obsługiwać komunikaty pulsu / stanu z ~ 10 000 węzłów). W przypadku awarii serwera proxy dostępne są inne metody do wskazania poszczególnych węzłów.

Ponadto musimy mieć możliwość interakcji z każdym węzłem w celu dostosowania ustawień itp., Ale wydaje się, że jest to łatwiejsze do rozwiązania, ponieważ w większości przypadków jest obsługiwane ręcznie przez węzeł. Może być potrzebne pewne ulepszenie wsadowe, ale wszystko w całości wygląda jak standardowa sytuacja RPC (usługa sieciowa lub podobne). Oczywiście, jeśli oprogramowanie pośrednie może sobie z tym poradzić, za pośrednictwem mechanizmu żądania / odpowiedzi, który byłby plusem.

Wymagania:

1000+ publikowanie węzłów / oferowanie ciągłych danychDane muszą być niezawodnie (w pewien sposób) i stale gromadzone na jednym lub kilku serwerach. Prawdopodobnie zostanie to zbudowane na oprogramowaniu pośrednim przy użyciu pewnego rodzaju wyraźnego żądania / odpowiedzi, aby poprosić o utratę danych. Jeśli może to być obsługiwane automatycznie przez oprogramowanie pośrednie, jest to oczywiście plus.Więcej niż jeden serwer / subskrybent musi być w stanie połączyć się z tym samym producentem / wydawcą danych i otrzymać te same daneSzybkość transmisji danych wynosi maksymalnie 10-20 na sekundę na grupęRozmiary wiadomości wahają się od może ~ 100 bajtów do 4-5 kilobajtówWęzły wahają się od wbudowanych systemów ograniczonych do normalnych skrzynek COTS Linux / WindowsWęzły zazwyczaj używają C / C ++, serwerów i klientów zazwyczaj C ++ / C #Węzły nie powinny (najlepiej) nie muszą instalować dodatkowego oprogramowania lub serwerów, tj. Jeden dedykowany broker lub dodatkowa usługa na węzeł jest kosztownaBezpieczeństwo będzie oparte na wiadomościach, tzn. Nie będzie potrzebne zabezpieczenie transportu

Szukamy rozwiązania, które może obsłużyć komunikację między głównie węzłami pośredniczącymi (niebieski) i serwerami (zielony) dla publikowania / pobierania / pobierania danych oraz od klientów (pomarańczowy) do poszczególnych węzłów (styl RPC) dla ustawień szczypania.

Wydaje się, że jest wiele dyskusji i zaleceń dotyczących odwróconej sytuacji; rozpowszechnianie danych z serwera (serwerów) do wielu klientów, ale trudniej było znaleźć informacje związane z opisaną sytuacją. Ogólnym rozwiązaniem wydaje się być użycie SNMP, Nagios, Ganglia itp. Do monitorowania i modyfikowania dużej liczby węzłów, ale trudną częścią dla nas jest gromadzenie danych.

W skrócie przyjrzeliśmy się rozwiązaniom takim jak DDS, ZeroMQ, RabbitMQ (potrzebny broker na wszystkich węzłach?), SNMP, różne narzędzia do monitorowania, usługi sieciowe (JSON-RPC, bufory REST / Protocol) itp.

WięcCzy masz jakieś zalecenia dotyczące łatwego w użyciu, niezawodnego, stabilnego, lekkiego, wieloplatformowego, międzyjęzykowego rozwiązania pośredniego (lub innego), które pasowałoby do rachunku? Tak proste, jak to możliwe, ale nie prostsze.