Hallo,
ich habe in letzter Zeit ein kleines Projekt angefangen und habe jedoch ein paar Probleme, alles zu lösen bzw. wahrscheinlich Denkfehler.
Was habe ich: Ein Python Skript, welches Messdaten von Sensoren empfängt. Jeder Sensor ist an eine Internetverbindung angeschlossen und kann Daten ins Internet senden. Die Daten werden dann mit Hilfe von Flask visualisiert.
Jetzt habe ich folgende "Denkblockade": In einem lokalen Netzwerk ist das ja scheinbar kein Problem. Eindeutige IP-Adressen, etc.
Wenn ich mein Skript jetzt auf einem Server laufen lasse, möchte ich dort die Daten einsammeln und visualisieren. Das sollte auch noch funktionieren, da immer noch eindeutige IP-Adressen etc.
Wie kann man seine Struktur gestalten, wenn man mehrere Instanzen des Skripts parallel laufen lassen möchte.
Sozusagen folgende Struktur:
Python inkl. Flask Skript 1 ---> Server 1
Sensor 1 --> sendet Daten an Server 1 -> Skript 1
Sensor 2 --> sendet Daten an Server 1 -> Skript 1
Python inkl. Flask Skript 2 --> Server 1
Sensor 3 --> sendet Daten an Server 1 -> Skript 2
Sensor 4 --> sendet Daten an Server 1 -> Skript 2
Wie kann ich die Daten ordentlich verteilen, wenn mir nur 1 IP-Adresse des Servers zur Verfügung steht?
Hat das überhaupt etwas mit Cloud Programmierung zu tun? Wie sind die Vorgehensweisen bei solch einem Problem?
Würde mich freuen, wenn jemand eine tolle Idee hat oder mir kurz erläutern kann, wie man die (Daten-)Netzwerkstruktur aufbaut.
Beste Grüße und schon mal vielen Dank!
homerunjack
"Cloud"-Programmierung in Python
@homerunjack: Visualisierung und Messdatenempfang sind ja zwei unabhängige Vorgänge. Jeder Flask-Server muß die Empfangenen Daten in *eine* Datenbank schreiben, und aus der kann dann jeder Flask-Server wieder die Daten zur Visualisierung lesen. Was das mit IP-Adressen zu tun hat, verstehe ich nicht.
-
homerunjack
- User
- Beiträge: 24
- Registriert: Donnerstag 21. Juli 2016, 12:12
Hallo Sirius3,
bis jetzt arbeite ich an nur "einer Instanz" des Skripts. Ich habe einen Thread, der den Socket für den Datenempfang öffnet/empfängt/bearbeitet und einen Thread für Flask. Die Daten werden an Flask beim Routing aus Python übergeben.
Wenn ich jetzt aber mehrere Instanzen des Skripts starte, müssen die Sensoren wissen, an wen sie ihre Daten senden sollen bzw. welches Skript der Empfänger ist.
Jetzt kann man natürlich alle Daten in einer DB separat und unabhängig von den Hauptskripten empfangen, und jedes Skript holt sich seine Daten ab, hierfür wird wohl eine Empfangskennzeichnung nötig sein. Ich weiß aber nicht, ob das die eleganteste Lösung ist.
Kann man die Daten direkt an die richtige Stelle des Skripts "routen" lassen?
Mein Ziel ist es, X-Instanzen zu starten, ohne viel drum herum zu programmieren. Jedoch müssen die Daten aller Sensoren natürlich in dem vorher definierten Skript ankommen. Und da hapert es noch bei mir.
Daher die Frage, gibt es ein Workaround, wie man sich eine solche "Cloud"-Datenstruktur schaffen kann, wo sozusagen viele identische Dienste (Skripte) parallel laufen, die Datenquellen jedes Dienstes aber individuell sind? Wie bekommt man die Daten am sinnvollsten in das vorgegebene Skript, sodass das Skript trotzdem skalierbar bleibt?
Beste Grüße
homerunjack
bis jetzt arbeite ich an nur "einer Instanz" des Skripts. Ich habe einen Thread, der den Socket für den Datenempfang öffnet/empfängt/bearbeitet und einen Thread für Flask. Die Daten werden an Flask beim Routing aus Python übergeben.
Wenn ich jetzt aber mehrere Instanzen des Skripts starte, müssen die Sensoren wissen, an wen sie ihre Daten senden sollen bzw. welches Skript der Empfänger ist.
Jetzt kann man natürlich alle Daten in einer DB separat und unabhängig von den Hauptskripten empfangen, und jedes Skript holt sich seine Daten ab, hierfür wird wohl eine Empfangskennzeichnung nötig sein. Ich weiß aber nicht, ob das die eleganteste Lösung ist.
Kann man die Daten direkt an die richtige Stelle des Skripts "routen" lassen?
Mein Ziel ist es, X-Instanzen zu starten, ohne viel drum herum zu programmieren. Jedoch müssen die Daten aller Sensoren natürlich in dem vorher definierten Skript ankommen. Und da hapert es noch bei mir.
Daher die Frage, gibt es ein Workaround, wie man sich eine solche "Cloud"-Datenstruktur schaffen kann, wo sozusagen viele identische Dienste (Skripte) parallel laufen, die Datenquellen jedes Dienstes aber individuell sind? Wie bekommt man die Daten am sinnvollsten in das vorgegebene Skript, sodass das Skript trotzdem skalierbar bleibt?
Beste Grüße
homerunjack
@homerunjack: meine bisherige Vorstellung war, dass alles über einen Reverse-Proxy läuft, der sich um die Verteilung auf die parallelen Instanzen kümmert. Aber Du willst sie ja tatsächlich unabhängig haben. Dann mußt Du ja auch jedem einzelnen Sensor die IP und den Port des jeweiligen Servers nennen.
-
homerunjack
- User
- Beiträge: 24
- Registriert: Donnerstag 21. Juli 2016, 12:12
Man kann natürlich beide Varianten bauen. Die Frage ist nur, welche Struktur ist sinnvoller, skalierbarer?
Ein Master-Server, die alle Daten einsammelt und dann an die Instanzen verteilt, ist vielleicht doch nicht so schlecht. Jedoch muss dann jede Nachricht eine eindeutige Kennung für das Ziel haben.
Gibt es nicht irgendwo ein Leitfaden zur Cloud-Programmierung? Wenn ich bei Google Suche, stoße ich nur auf Dropbox und Co.?
Ein Master-Server, die alle Daten einsammelt und dann an die Instanzen verteilt, ist vielleicht doch nicht so schlecht. Jedoch muss dann jede Nachricht eine eindeutige Kennung für das Ziel haben.
Gibt es nicht irgendwo ein Leitfaden zur Cloud-Programmierung? Wenn ich bei Google Suche, stoße ich nur auf Dropbox und Co.?
@homerunjack: ich verstehe Dein Problem nicht wirklich. wenn Du Skalierbarkeit anspricht, geht es normalerweise darum, dass man mehrere exakt gleiche Instanzen hat, um mehr Anfragen pro Sekunde abarbeiten zu können. Das widerspricht der Aussage, dass Du verschiedene "Ziele" hast, also unabhängige Instanzen, die automatisch skalieren, weil, das was Du auf Deinem Server machst, interessiert ja meinen nicht.
Kannst Du nochmal genauer beschreiben, was Du machen willst, und welche Probleme Du irgendwo vermutest.
Kannst Du nochmal genauer beschreiben, was Du machen willst, und welche Probleme Du irgendwo vermutest.
-
homerunjack
- User
- Beiträge: 24
- Registriert: Donnerstag 21. Juli 2016, 12:12
Hallo Sirius3,
mit Skalierbarkeit meine ich einfach nur, dass es möglich ist, das Skript mehrfach laufen zu lassen. Dabei ist dann jede Instanz sein eigenes System.
Am Ende soll es so aussehen:
Wie gesagt geht es zunächst erstmal um Sensoren, die Daten senden.
Skript 1 wird ausgeführt und empfängt Daten von Sensor 1, 2 und 3 von Haus 1. Haus 1 hat mit dem Skript 1 sozusagen sein eigenes "Projekt" und seine eigene Flask Oberfläche.
Skript 2 wird ausgeführt und empfängt Daten von Sensor 4, 5, 6 und 7 von Hause 2. Haus 2 hat mit Skript 2 auch sein eigenes, von Skript 1 unabhängiges Projekt.
Skript x....Haus x...Sensor x+...
Jetzt könnte man es so gestalten, dass jedes Skript sich einen "Datensammler"-Server erstellt, somit ein Port belegt wird und ein Flask Port bereitstellt. Somit müsste man 2 Ports pro Skript/Instanz zur Verfügung stellen. D.h. IP.IP.IP.IP:8080 (Flask) und IP.IP.IP.IP:8081 (Daten)
Was ich mir vorstelle, ist aber eventuell ein Port für alle Daten auf allen Instanzen. Z.B. Sensor 1 und auch Sensor 4 schicken Daten an den Datenport (XYZ) und ein weiteres Skript verteilt anhand einer Kennung in der Nachricht an die richtige Instanz.
Jetzt sind das 2 Vorgehensweisen. Was mich nun interessiert: gibt es da einen "richtigen" Weg? Wie programmiert man solche Anwendungen in der Cloud? Wie ist die richtige oder auch eleganteste Lösung, die Daten einzusammeln?
Das ist sozusagen meine Hauptfrage. Wie geht man bei solch einem Problem vor? Programmieren kann man ja beides...doch welche Variante macht Sinn? Gibt es noch andere Varianten?
Beste Grüße
homerunjack
mit Skalierbarkeit meine ich einfach nur, dass es möglich ist, das Skript mehrfach laufen zu lassen. Dabei ist dann jede Instanz sein eigenes System.
Am Ende soll es so aussehen:
Wie gesagt geht es zunächst erstmal um Sensoren, die Daten senden.
Skript 1 wird ausgeführt und empfängt Daten von Sensor 1, 2 und 3 von Haus 1. Haus 1 hat mit dem Skript 1 sozusagen sein eigenes "Projekt" und seine eigene Flask Oberfläche.
Skript 2 wird ausgeführt und empfängt Daten von Sensor 4, 5, 6 und 7 von Hause 2. Haus 2 hat mit Skript 2 auch sein eigenes, von Skript 1 unabhängiges Projekt.
Skript x....Haus x...Sensor x+...
Jetzt könnte man es so gestalten, dass jedes Skript sich einen "Datensammler"-Server erstellt, somit ein Port belegt wird und ein Flask Port bereitstellt. Somit müsste man 2 Ports pro Skript/Instanz zur Verfügung stellen. D.h. IP.IP.IP.IP:8080 (Flask) und IP.IP.IP.IP:8081 (Daten)
Was ich mir vorstelle, ist aber eventuell ein Port für alle Daten auf allen Instanzen. Z.B. Sensor 1 und auch Sensor 4 schicken Daten an den Datenport (XYZ) und ein weiteres Skript verteilt anhand einer Kennung in der Nachricht an die richtige Instanz.
Jetzt sind das 2 Vorgehensweisen. Was mich nun interessiert: gibt es da einen "richtigen" Weg? Wie programmiert man solche Anwendungen in der Cloud? Wie ist die richtige oder auch eleganteste Lösung, die Daten einzusammeln?
Das ist sozusagen meine Hauptfrage. Wie geht man bei solch einem Problem vor? Programmieren kann man ja beides...doch welche Variante macht Sinn? Gibt es noch andere Varianten?
Beste Grüße
homerunjack
@homerunjack: Du hast mehrere Möglichkeiten:
1. Die Skripte fragen gezielt die Sensoren ab, die für das jeweilige Skript von Interesse sind. D.h. die Sensoren senden nur nach Aufforderung an die ip, von der die Anfrage kam. Dann hast Du eine klare Trennung.
2. Die Sensoren senden unaufgefordert an eine definierte ip. Das lässt sich prima skalieren und die Daten werden in irgendeinem Datastore gesammelt. Dort holen sich dann andere Prozesse das ab, was sie jeweils interessiert.
3. Die Sensoren senden unaufgefordert an unterschiedliche dedizierte ips, je nach Projekt. Das aber lässt sich auf Punkt 2 zurückführen.
Möglicherweise ist das, was Du willst, ein Messagebroker.
1. Die Skripte fragen gezielt die Sensoren ab, die für das jeweilige Skript von Interesse sind. D.h. die Sensoren senden nur nach Aufforderung an die ip, von der die Anfrage kam. Dann hast Du eine klare Trennung.
2. Die Sensoren senden unaufgefordert an eine definierte ip. Das lässt sich prima skalieren und die Daten werden in irgendeinem Datastore gesammelt. Dort holen sich dann andere Prozesse das ab, was sie jeweils interessiert.
3. Die Sensoren senden unaufgefordert an unterschiedliche dedizierte ips, je nach Projekt. Das aber lässt sich auf Punkt 2 zurückführen.
Möglicherweise ist das, was Du willst, ein Messagebroker.
@homerunjack: also willst Du keine Skalierung, sondern Multimandantenfähigkeit: Du willst die gleiche Resource (Server) von mehreren Sensorguppen nutzen. Wenn Du also eine REST-artige Schnittstelle hast, sendet jeder Sensor an eine individuelle URL: http://<your ip>:8080/<project_id>/<sensor_id>. So weiß ein Server, wohin er jeden Sensor zuordnen soll.