Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

[fadade]

Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Servus,

in meiner bisherigen Laufbahn hatte ich noch nie mit Details der Netzwerkkonfiguration zu tun, deshalb hoffe ich, dass mir hier vielleicht jemand weiterhelfen kann. Ggf. sind die Formulierung an einigen Stellen unklar/undeutlich, da es doch sehr spezifisch ist - verzeiht mir das bitte

Ich arbeite zur Zeit an einem Projekt bei dem mehrere Raspberry Pis gemeinsame Aufgaben erledigen sollen, indem sie über Ethernet kommunizieren, wobei sich die Netzwerktopologie verändern kann (bzw. möglichst können sollte ...). Die folgende Abbildung zeigt das mal schematisch.

Zur Zeit besitzen die Raspberrys eine eindeutige statische IP und benachbarte Boards werden durch eine statische Datei mit dem Netzwerkaufbau identifiziert (irgendwie funktioniert das - haben die Vorgänger eingerichtet). Die entwickelten Java-Anwendungen kommunizieren dann per TCP miteinander.

Softwareseitig ist nun gewünscht die benachbarten Boards dynamisch zu erkennen bzw. mit ihnen kommunizieren zu können. Am liebsten würde ich jedes Board und das Gerät drumherum mit einem 5-Port-Switch ausstatten (Geld ist eher Nebensache), an dem einmal das lokale Board und die vier möglichen Nachbarn (vorne, hinten, links, rechts) hängen. In der Software würde ich dann gerne einfach ein mapping von IP-Adressen auf die Ports am Switch haben, also 192.168.1.1 ist die Verbindung nach "vorne", 192.168.1.2 nach "hinten" usw. --> unabhängig davon, ob ein benachbartes Gerät angeschlossen ist und was es für eine IP besitzt. Wichtig ist hier eigentlich nur die jeweilige Verbindung zwischen benachbarten Boards (ohne auf globales DHCP angewiesen zu sein).

Ideal wäre, wenn ich die IP aller Boards statisch auf denselben Wert (z.B. 192.168.1.1) festlege und Datenverkehr an die vier benachbarten Boards ebenfalls über feste IPs erledigen kann, sodass die Kommunikation mit dem "vorderen Nachbarn" vielleicht wie folgt aussieht (vgl. schematische Idee in obiger Abbildung):

------------- Gerät-A-------------------------Verkabelung---------------------------------Gerät-B--------
---Lokal-A-------Ziel-Adresse-------OS-Konfig/Kabel/unklar---------Quell-Adresse------Lokal-B-
192.168.1.1 ----> 192.168.1.2 ----> Port/Interface/Kabel XY ----> 192.168.1.4 ---->192.168.1.1

Damit soll erreicht werden, dass A das Gerät "vorne" über 192.168.1.2 erreichen kann und der eingehende Verkehr aus B's Sicht bspw. von "links" per 192.168.1.4 kommen kann. Mir ist unklar, ob man dafür einen Managed Switch o.ä. einsetzen und konfigurieren kann, oder ob ich den Rasbperry auch um Ethernet-Anschlüsse (Boards, USB-Adapter) erweitern könnte und dieses IP-Interface-Mapping dann irgendwie in einer Konfigurationsdatei festlegen kann (mit hosts etc. hatte ich mich bisher nie beschäftigen müssen).
Hat hier vielleicht jemand eine Idee dazu?


Schöne Grüße

 

[Eldiabolo]

AW: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Ggf. sind die Formulierung an einigen Stellen unklar/undeutlich, da es doch sehr spezifisch ist - verzeiht mir das bitte

Der war gut Ohne es jetzt gemein zu meinen, aber das ist wirklich sehr konfus. Vllt beschreibst du mal eine eben hoere, was die Raspis denn ueberhaupt machen sollen? Momentan ist der Aufabu so wie du ihn gezeichnet hast naemlich, wie man mehrere netzwerkgeraete miteinander kommunizieren laesst. Was du dir da gedacht hast weiss ich nicht genau, und funktioniert auch nicht, zumal der Raspi nur einen RJ-45 Port hat (hier koennen man noch mit einem USB-Dongel abhilfe schaffen), aber zweimal der gleiche IP-Range UND Adresse an dann unterschiedlichen Interfaces mit beim gleichen Geraet kann nicht gut gehen.

Also, schreib mal, was ihr genau plant, und dann kann man sagen, wie das Netzwerktechnisch umzusetzen ist.

 

[bingo88]

AW: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Eine IP für mehrere Geräte geht schon mal nicht. Was man relativ leicht softwareseitig lösen könnte, wäre ein Autodiscovery der anderen Knoten. Das funktioniert so, wie früher LAN-Spiele einen Server im LAN finden konnten: Man schickt ein UDP-Packet an die Broadcastadresse (192.168.1.255) und einen bestimmten Port und guckt, wer sich meldet. In der Meldung steht dann beispielsweise die IP-Adresse und die Kennung des Knotens, darüber kann man dann eine TCP-Verbindung mit dem jeweiligen Knoten aufbauen. Damit das funktioniert, müssen aber alle Knoten im selben Netz liegen (192.168.1.0/24 ), da kann man aber irgendwo einen DHCP-Server laufen lassen. Oder man nimmt halt eine Fritzbox o.ä. als Switch.

 

[fadade]

AW: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Moin,

danke schonmal für die Anteilnahme
Also es geht darum, das kleine stationäre Robotikeinheiten (gesteuert durch C++ und Java-Komponenten auf den Raspberrys) Bauteile bearbeiten sollen. Vereinfacht also z.B. Raspberry A macht Stempel, Rasbperry B bohrt ein Loch usw.

Diese Produktionskette soll flexibel gestaltet werden können, also statt A->B->C->D soll auch A->C->D->B möglich sein. Physikalisch sind auch Verzweigungen (durch maximal 4 Nachbarn) möglich. An sich läuft das auch alles schon, und wenn ich jetzt von A->B->C->D auf eine andere Kette umstellen möchte, müssen die Einheiten umgestellt werden und die Konfigurationsdatei mit allen IPs angepasst werden - läuft auch.

Allerdings sollte das alles auch dezentral ohne einen Switch als globalen Verteiler laufen. Im ersten Fall A->B->C->D muss B zum Beispiel mit den linken und rechten Nachbarn A und C über TCP kommunizieren. Das geht, weil diese Konfigurationsdatei die IPs enthält und die Softwarekomponenten dann einfach dahin verbinden. Der dezentrale Fall ist in meiner Ansicht aber anders: Einheit B wird nun mit irgendwelchen Einheiten verbunden (z.B. über einen Switch auf jeder Einheit oder eben über USB-Dongles o.ä. - mir ist noch nicht klar was sich da eignet) und soll dann "einfach" in den Softwareteilen wie gewohnt TCP-Verbindungen aufbauen können. Also Verbindung mit <ip1:port1> ... ok .. linker Nachbar. Verbindung mit <ip2:port2> ... fehlgeschlagen .. ok .. kein Nachbar vorne und so weiter.
Deswegen dachte ich, dass auf einem Raspberry z.B. 192.168.1.1 immer mit dem jeweils "linken" Nachbarn assoziiert werden könne und ein OS-Mapping dann alles "funktionierend macht". Wichtig ist nur, dass über die TCP-Verbindungen die physikalischen Nachbarn identifiziert werden, da einige Nachbarn Bauteile liefern und andere Bauteile entgegennehmen. Ob man dafür technisch einen Switch pro Einheit oder jeweils 4 Punkt-zu-Punkt Verbindungen zu den Nachbarn umsetzt (und wie teuer das wäre) ist egal. Es kann nur nicht auf eine zentrale DHCP-Verwaltung o.ä. zurückgegriffen werden - das ganze sollte eben dezentral zwischen den einzelnen Verbindungen verwaltet/ausgehandelt werden, damit diese beliebig umgestöpselt werden können (dann ggf. neu booten - auch egal - und alles läuft wieder in der Produktionskette).


Ich hoffe es ist ein wenig klarer geworden
Wenn das immer noch vollkommen "unrealistisch" erscheint, wäre das nun auch kein Weltuntergang, da es zur Zeit über die Änderung der Konfigurationsdatei mit einem zentralen Switch auch läuft, so aber eigentlich nicht den angestrebten Projektzielen entspricht ...

Schöne Grüße,

 

[fadade]

AW: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Hi,

gibt nochmal eine weitere Abbildung mit etwas konkreteren Überlegungen/Darstellungen:

 

[Lagi]

AW: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Hallo,

ich beschreibe Dir mal meine Sicht als Netzwerktechniker, sorry falls sich die Fragen manchmal doof anhören, das ist aber auch täglich mein Job
Grundsätzlich: JEDER Port den du mit einer IP besetzen willst, braucht hier in dem Fall eine eigene IP.
Warum? Weil es das ARP Protokoll gibt welches ein IP zu MAC Adress-Mapping regelt, wenn jetzt mehrere Geräte oder Ports die gleiche IP haben, kann dein ARP Protokoll mal Gerät A zurückbekommen mit MAC Adresse oder Gerät C, je nach dem welches nach längerer Zeit zuerst antwortet. Und das möchtest du ja nicht.
Also: Jeder Port eine IP, dabei kannst du Dir aussuchen, ob du in einem Subnetz fortlaufende IPs vergibst z.B. 192.168.1.1-3 Gerät A, 4-6 Gerät B etc. oder ein großes Subnetz anlegst und dann sowas machst wie Gerät A 192.168.1.1-3, Gerät B 192.168.2.1-3 ...
Das Schema bleibt Dir überlassen du musst es nur einmal definieren.

Was ich nicht ganz verstehe: Du schreibst, dass das ganze dezentral ohne Switch funktionieren soll, ein paar Sätze danach aber "irgendwelchen Einheiten verbunden (z.B. über einen Switch[...]" - da kommen meine doofen Fragen als Netzwerktechniker, ohne das ich die Hintergründe deines Projektes kenne:
Warum dezentral? Welchen Vorteil hast du davon bzw. welche Anforderung muss erfüllt werden die einen Switch verbietet? -> Das ist alltägliche und gängige Topologie
Wenn wie beschrieben jeder Rasperry eine Aufgabe erledigt, warum braucht er mehrere Ports und mehrere IPs?

Ich sehe im Prinzip zwei Topologien die du aufbauen kannst:
1) Die Rasperrys an einem Switch, einfache und gängige Topologie, theoretisch brauchst du auch nur einen Port und eine IP pro Rasperry und kannst sie damit eindeutig identifizieren und ansprechen, jeder Rasperry ist immer ansprechbar und somit ist die Produktionskette komplett dynamisch.
Wie gesagt ich kenne die Hintergründe und Details deines Projektes nicht, daher erscheinen mir die Ports "links","rechts","vorn","hinten" merkwürdig und überflüssig (aus Netzwerksicht ergibt sich mit Switch kein Sinn dies so zu tun).

2) Wenn du eine dynamische Produktionskette ohne Switch willst, brauchst du Vollvermaschung, d.h. jeder Rasperry muss mit jedem anderen Verkabelt werden. Dann brauchst du keinen Switch, dafür aber viele IP Adressen, viele Kabel und viele Ports und musst Dir dazu noch viele Teilstrecken merken welche Teilstrecke jetzt welche Geräte miteinander verbinden. Ist meiner Ansicht nach als Netzwerker unnötig kompliziert und liegt komplett neben dem, was gängige Topologien darstellt.
Produktionsketten können sich zudem auch verändern oder entwickeln, wenn jetzt noch Rasperry X später in die Kette aufgenommen werden soll, musst du für jeden Rasperry wieder neue Ports schaffen um alle mit allen zu verbinden.
Das ist aufwendig, teuer und skaliert sehr schlecht.

Also ich persönlich rate Dir zu dem Ansatz "Keep it simple" - Nimm einen Switch, hänge jeden Rasperry mit einem Port dran, vergib für jeden Rasperry EINE eindeutige IP und schon hast du eine simple aber gängige Topologie die auch super skaliert - wenn ein neuer Rasperry dazu kommen müsste, hängst du den eben mit an den Switch und gibst dem eine IP - zack.
Wenn du für eingehende und ausgehende Teile andere Verbindungen nehmen möchtest, häng meinetwegen jeden Rasperry mit zwei Ports an den Switch und gib jedem Port eine IP. Auch gut.
Allerdings hast du ja geschrieben das ein zentraler Switch nicht die Projektziele erfült - wie sind diese denn gesetzt? Das ist ja auch entscheidend dafür, wie deine Topologie aussehen muss/sollte.

VG Lagi

 

[fadade]

AW: Netzwerktopologie und -konfiguration für Forschungsprojekt - Raspberry Pi technisch und softwareseitig verbinden

Hallo Lagi,

danke schonmal für deine Anteilnahme. Um dir etwas mehr Details zu vermitteln ist der Text ein wenig länger geworden .. sorry dafür schonmal, aber vielleicht klärt das nochmal ein paar weitere Dinge.

Wie von einem anderen Forenmitglied schon festgestellt wurde ist dieser dezentrale Ansatz nicht ganz im Sinne von TCP/IP und deswegen erscheint das Vorhanben an einigen Stellen sonderbar. Eigentlich sollte ein Projektpartner ein entsprechendes Vernetzungsgerät bauen, was die "Produktionsstationen" miteinander verbindet, aber das wurde dort inzwischen abgesagt und da ich selbst keinen E-Technik-Hintergrund habe, wollte ich das Kommunikationsproblem eben über Ethernet lösen.

Vielleicht vorab:

Ich sehe im Prinzip zwei Topologien die du aufbauen kannst:
1) Die Rasperrys an einem Switch, einfache und gängige Topologie, theoretisch brauchst du auch nur einen Port und eine IP pro Rasperry und kannst sie damit eindeutig identifizieren und ansprechen, jeder Rasperry ist immer ansprechbar und somit ist die Produktionskette komplett dynamisch.
Wie gesagt ich kenne die Hintergründe und Details deines Projektes nicht, daher erscheinen mir die Ports "links","rechts","vorn","hinten" merkwürdig und überflüssig (aus Netzwerksicht ergibt sich mit Switch kein Sinn dies so zu tun).

Genauso ist es aktuell umgesetzt. Alle Raspberrys hängen an einem Switch, besitzen eine eindeutige IP und können miteinander reden - alles läuft wunderbar. Auf jedem Raspberry ist noch eine JSON-Topologie-Datei hinterlegt, in der festgehalten ist, dass Raspberry A bspw. die IPs 192.168.1.2/...15/...26 als linken, rechten und vorderen Nachbarn hat. Sprich wenn A ein Produkt verarbeitet und es dabei physisch(!) von vorne nach links transportiert werden soll, werden Daten mit 192.168.178.2 und 192.168.178.26 ausgetauscht. Läuft auch alles.

Wenn nun aber eine weitere Produktionsmaschine in die Kette eingefügt werden soll (oder B als linker Nachbar von A ausgetauscht werden soll o.ä.), dann geschieht aktuell folgendes:
1) passe die Topologie-Datei an
2) verteile diese Datei auf alle Raspberrys
3) Systeme ausschalten
4) Produktionsstationen verändern (also umschieben der Stationen und ggf. anders verkabeln)
5) Systeme anschalten --> alle kennen sich, dank der Topologiedatei

In den Projektzielen ist eigentlich von Plug&Play die Rede, also bspw.
1) Ausschalten
2) Umstellen/Verkabeln
3) Anschalten --> alle wissen welche Nachbarstationen vorhanden sind (Netzwerktopologie der direkten Nachbarn wird automatisch erfasst, bzw. ist lokal immer "fix" vorgegeben)

Deswegen beharre ich so ein bisschen auf dem dezentralen Ansatz. Im Projekt ist es aktuell auch nur notwendig mit den direkten Nachbarn zu kommunizieren - also eigentlich würde eine rieseige Ansammlung aus Punkt-zu-Punkt-Verbindungen ausreichend sein. Denn Nachrichten werden nicht über direkte Adressierung von z.B. A nach C getätigt, sondern sie laufen über Zustandsveränderungen von A, die allen Nachbarn mitgeteilt werden und dann wieder allen Nachbarn mitgeteilt werden, bis sie bei C ankommen. Für einen Raspberry reicht es also, wenn er mit seinen 4 Nachbarn kommunizieren kann. Mit einem zentralen Switch (wie aktuell vorhanden) geht das natürlich auch.

Einen "Switch" hatte ich jetzt nur als Alternative für z.B. 4 USB-to-Ethernet-Adapter gesehen, um benachbarte Produktionsstationen miteinander verbinden zu können, da ein Raspberry ja nur einen LAN-Port hat. Also

[Raspberry-A]---[Switch-A]---[Switch-B]---[Raspberry-B]---[Switch-B]---[Switch-D]---[Raspberry-D] ...
-----------------------------|-------[Switch-C]---[Raspberry-C]


für die einfache Kette:
- A ist Wareneingang
- B Stempeln
- C Ausschuss
- D und "..." Produktionskette

Ob das nun Switches oder USB-to-LAN-Adapter, wäre egal. Da ginge es mir nur um das Konzept, dass das "lokale IP-Koordinatensystem" eines Raspberrys bei der Verbindung zum Nachbarn in "verbindungslokale IPs" übersetzt wird (klingt wieder sehr sonderbar - also aus Sicht von A hätte der linke Nachbar immer 192.168.178.2 und auf der Verbindung von A zum linken B würde daraus irgendwie eine eindeutige Verbindungs-IP ... oder so. Das ist eine der relevantesten Unklarheiten bei mir ).

In der Software baue ich pro Rasbperry wirklich nur 4 TCP-Verbindungen zu den direkten Nachbarn auf. Durch die Topologie-Datei, weiß ich, welche IPs ich dazu ansprechen muss. Genau das soll nun irgendwie umgangen werden. Am liebsten indem ich für meinen linken physischen Nachbarn mit Java z.B. immer "SocketChannel.open(192.168.1.1);" ausführe und das Betriebssystem oder die Verbindungstechnik, diesen IP-Verkehr dan irgendwie auf den entsprechenden physischen linken LAN-Port umleitet. Bei USB-LAN-Adaptern können wir z.B. immer sagen, das Linux-Interface usb0 mit 192.168.1.1 ist links, usb1 mit 192.168.1.2 ist rechts, usw.
Soweit war ich schon, aber dann kommt wieder das von dir erwähnte Problem eindeutiger IP-Adressen auf, da der benachbarte Raspberry (in meiner Vorstellung) aktuell noch die gleiche Konfiguration hat. Und ausgehender Verkehr auf 192.168.1.2 geht dann womöglich an den Nachbarn, wenn der richtige Port angeschlossen ist, oder wieder zurück an den lokalen Port mit 192.168.1.2 ?!?!

Jetzt nochmal zu deinen anfänglichen Anmerkungen.

Zu Subnetzen:
Verschieden Subnetze pro Station o.ä. zu definieren ginge natürlich auch, unterscheidet sich vom Konzept her aber nicht unbedingt vom aktuellen aufbau (globale eindeutige IP pro Raspberry).

Zu "dezentral":
Vielleicht ist es oben schon klarer geworden. Dezentral meint hier die Verbindungsverwaltung zwischen Raspberrys. Ob diese phyisch nun über Switches laufen, oder WLANs oder Rauchzeichen ist vollkommen egal.
Dezentral ist wie oben für den Vorgang der "Layoutveränderung" (3 Schritte statt 5 Schritte) nötig. Die Nachbarn sollen sich bei Veränderung der Produktionsketten selbstständig erkennen (ob nun über lokal feste IPs und ein dynamisches Mapping auf eine physischen Verbindung, oder ob durch DHCP auf jeder physischen Punkt-zu-Punkt-Verbindung o.ä. ist irrelevant). Hauptsache man stöpselt die Stationen um, startet neu und das neue Layout kann direkt verwendet werden.

Zu "mehrere Ports/IPs pro Raspberry":
Ist hoffentlich auch schon im Text oben abgedeckt. Ein Raspberry bietet die Möglichkeit 4 Nachbarstationen zu besitzen. Diese könnten nun durch 4 USB-LAN-Adapter verbunden werden oder über jeweils einen 5-Port-Switch pro Rasberry (4x mögliche Nachbarn, 1x Raspberry).

2) Wenn du eine dynamische Produktionskette ohne Switch willst, brauchst du Vollvermaschung, d.h. jeder Rasperry muss mit jedem anderen Verkabelt werden. Dann brauchst du keinen Switch, dafür aber viele IP Adressen, viele Kabel und viele Ports und musst Dir dazu noch viele Teilstrecken merken welche Teilstrecke jetzt welche Geräte miteinander verbinden. Ist meiner Ansicht nach als Netzwerker unnötig kompliziert und liegt komplett neben dem, was gängige Topologien darstellt.
Produktionsketten können sich zudem auch verändern oder entwickeln, wenn jetzt noch Rasperry X später in die Kette aufgenommen werden soll, musst du für jeden Rasperry wieder neue Ports schaffen um alle mit allen zu verbinden.
Das ist aufwendig, teuer und skaliert sehr schlecht.

Jeder mit jedem ist wie im obigen Text unnötig - wichtig ist nur die TCP/IP-Kommunikation mit den direkten Nachbarn.

[...] Also ich persönlich rate Dir zu dem Ansatz "Keep it simple" - Nimm einen Switch, hänge jeden Rasperry mit einem Port dran, vergib für jeden Rasperry EINE eindeutige IP und schon hast du eine simple aber gängige Topologie die auch super skaliert - wenn ein neuer Rasperry dazu kommen müsste, hängst du den eben mit an den Switch und gibst dem eine IP - zack.
Wenn du für eingehende und ausgehende Teile andere Verbindungen nehmen möchtest, häng meinetwegen jeden Rasperry mit zwei Ports an den Switch und gib jedem Port eine IP. Auch gut.
Allerdings hast du ja geschrieben das ein zentraler Switch nicht die Projektziele erfült - wie sind diese denn gesetzt? Das ist ja auch entscheidend dafür, wie deine Topologie aussehen muss/sollte.

Vgl. oben - ist quasi so umgesetzt, aber die Veränderung der Produktionskette entspricht so noch nicht den Projektzielen. "Keep it Simple" ist hier glaube ich nicht ungebdingt möglich aber dennoch danke für den Rat