Geekly articles weekly

Cloud Smart Home. Teil 2: Cloud-Service

Bild

Ich setze die Serie von drei Artikeln über das Cloud Smart Home fort.

In einem früheren Artikel wurden Geräte zum Erfassen eines Smart Homes sowie Algorithmen zum Umwandeln von Sensordaten in Steuerbefehle für ausführende Geräte betrachtet. Die Hauptkomponente eines Smart Homes ist ein Controller, der die meiste Zeit autonom gemäß der in der Einrichtungsphase festgelegten Logik arbeitet. An die Steuerung sind verschiedene Geräte (IP-Kameras, Sensoren, Aktoren) angeschlossen, die die von diesen Geräten empfangenen Daten an die Cloud senden.

Lassen Sie uns nun über die Architektur eines Cloud-Dienstes zum Speichern und Verarbeiten von Informationen von Sensoren und Kameras sprechen.

Vorteile des Cloud-Service


Ein Smart-Home-Cloud-Dienst bietet eine einfache, flexible und kostengünstige Möglichkeit zum Speichern und Zugreifen auf Daten, die von Smart-Home-Geräten empfangen werden. Der Benutzer des Cloud-Dienstes muss sich nicht um die Sicherheit seiner Daten kümmern. Die Funktionen eines Multiprozessor-Medienservers, der mit einem Festplattenkorb mit einem RAID-Array von mehreren 10 bis 12 TB-Laufwerken ausgestattet ist, übersteigen die Kapazität einer SD- oder Flash-Karte in einem Smart Home-Controller bei weitem. Darüber hinaus sind Speicherkarten unzuverlässig, da sie eine begrenzte Anzahl von Umschreibzyklen aufweisen und häufig ausfallen. Die Tiefe der Datenspeicherung in der Cloud wird durch den Tarif des Benutzers bestimmt und kann einfach in seinem persönlichen Konto konfiguriert werden.

Für den Zugriff auf die Daten ist keine „Portweiterleitung“ auf dem Router des Benutzers erforderlich, wenn Smart-Home-Geräte durch das NAT-Protokoll vor externen Netzwerken verborgen sind. In Ihrem persönlichen Konto, auf das Sie über mobile Geräte zugreifen können, können Sie die Konfiguration und Logik des Smart Homes einfach konfigurieren.

Es ist praktisch, Daten nicht nur in der Cloud zu speichern, sondern auch zu verarbeiten, um dem Benutzer Statistiken für verschiedene Zeiträume zur Verfügung zu stellen. Im Folgenden wird ein Beispiel für die Berechnung der durchschnittlichen Raumtemperatur pro Woche anhand von Multisensormessungen betrachtet.

Cloud-Service-Architektur


In einem früheren Artikel haben wir über einen Smart-Home-Controller gesprochen, der auf der Benutzerseite installiert ist und über verschiedene Protokolle mit einem Cloud-Dienst interagiert:

  • MQTT wird zum Austauschen von JSON-Nachrichten zwischen dem Controller und dem Business Logic Server verwendet.
  • HTTP, um die IP-Adresse des am wenigsten belasteten Medienservers vom Load Balancer des Medienserver-Clusters abzurufen.
  • RTMP zum Übertragen des H.264 + AAC-Streams auf den Medienserver.

Nun werden wir den Cloud-Service eines Smart Homes betrachten - die Hauptkomponenten, aus denen er besteht, und wie die Interaktion mit dem Smart Home-Controller erfolgt.


(Klicken Sie auf das Bild, um es in höherer Auflösung zu öffnen.)

Der Business Logic Server ist ein Schlüsselelement im gesamten Schema des Informationsaustauschs innerhalb des Cloud-Dienstes. Der Hauptzweck besteht darin, verschiedene Serversubsysteme über die RESTful-API-Schnittstellen zu verwalten. Es implementiert die Logik des Cloud-Dienstes basierend auf dem Benutzermodell : Aufzeichnen eines Videoarchivs und Sensormessungen in Abhängigkeit vom ausgewählten Tarif, Interaktion zwischen dem Benutzer und dem Smart Home-Controller usw.

Der MQTT-Broker wird für den Austausch von JSON-Nachrichten zwischen den auf der Clientseite installierten Smart Home-Controllern und dem Business Logic Server benötigt. Clients abonnieren Themen innerhalb des Brokers, die als Nachrichtenkanäle dienen. Als MQTT-Broker wird Eclipse Mosquitto verwendet .

Ein Medienserver-Cluster ist ein verteiltes System zum Speichern, Verarbeiten, Suchen und Wiedergeben von Videoinformationen für IP-Kameras eines bewölkten Smart Homes. Ein spezieller Load Balancer sammelt Informationen über die aktuelle Leistung jedes Servers im Cluster, berechnet die geringste Belastung und meldet seine IP-Adresse an den Smart Home Controller, der das Video von den Kameras an diesen überträgt.

Eine Cloud-Datenbank wird benötigt, um das Benutzermodell des Cloud-Dienstes, die Konfiguration und den aktuellen Status seiner Geräte sowie Metainformationen zu den Videoarchiveinträgen zu speichern. Als Implementierung der Cloud-Datenbank wird das MySQL-DBMS verwendet.

Touch Database ist eine nicht relationale NoSQL-Datenbank. Es speichert Ereignisse und Messungen von Smart-Home-Sensoren, geordnet nach Zeit. Die Verwendung von InfluxDB DBMS, das für die Arbeit mit dieser Art von Daten optimiert ist, verbessert die Leistung des Cloud-Dienstes erheblich.

Das Backend der Clientanwendung ist eine Serveranwendung, deren Hauptfunktion darin besteht, von der Cloud- und Touch-Datenbank empfangene Daten in einem praktischen Format für die spätere Anzeige durch die Clientanwendung auf dem Gerät des Benutzers bereitzustellen. Das Backend generiert außerdem Steuerbefehle im JSON-Format für den Smart Home-Controller. Das Backend basiert auf dem Laravel PHP Framework. Dies wird im nächsten Artikel zu einer Clientanwendung für die Interaktion mit einem Cloud-Smart-Home ausführlicher erläutert.

Der Push-Benachrichtigungsanbieter sendet Nachrichten über die Ereignisse des Smart Homes an das mobile Gerät des Benutzers, damit dieser schnell in die Situation eingreifen kann (z. B. wenn ein Wasserleck oder Rauch auftritt, rufen Sie die entsprechenden Antwortdienste an). Der OneSignal- Dienst wurde als Anbieter von Push-Benachrichtigungen ausgewählt, der über eine praktische RESTful-API-Schnittstelle und die Funktion zur Identifizierung mobiler Geräte verfügt, die für den ordnungsgemäßen Betrieb von Benachrichtigungen im persönlichen Konto des Benutzers erforderlich sind.

Geschäftslogik-Server


Wie bereits erwähnt, ist der Business Logic Server eine Schlüsselkomponente des Cloud Smart Home. Basierend auf dem Benutzermodell (Informationsbeschreibung des Systembenutzers, einschließlich System-, persönlicher, finanzieller und logischer Funktionen) verwaltet er eine Vielzahl von Diensten in der Cloud, die unterschiedliche Implementierungen und Funktionen aufweisen und über RESTful-API-Schnittstellen miteinander kommunizieren.



Das Geschäftslogikmodul im Server ist für die folgenden Vorgänge verantwortlich:

  1. Verwaltung der Speicherung von Messwerten von Sensoren und Ereignissen von Bewegungsmeldern von IP-Kameras eines Smart Homes in einer Touch-Datenbank;
  2. Verwalten der Aufzeichnung des Medienstroms der IP-Kamera, die vom Smart-Home-Controller gesendet wird, im Archiv des Medienservers (Konstante / Bewegungsmelder);
  3. Übersetzung von Befehlen von der Client-Anwendung zum Smart-Home-Controller;
  4. Broadcast der Konfiguration des Smart-Home-Controllers (angeschlossene Geräte, vom Benutzer festgelegte Produktionslogikregeln);
  5. Senden von Push-Benachrichtigungen über den Status des Smart Home-Controllers und der angeschlossenen Geräte an die Client-Anwendung.

Eine Funktion des Geschäftslogikservers ist die Interprozesskommunikation mit Remoteanwendungen, die auf mehreren Servern im Internet ausgeführt werden. Die meiste Zeit ist die Business-Logik-Server-Anwendung für E / A-Sperren inaktiv, daher basiert sie auf einer Multithread-Architektur und besteht aus einer Reihe endlicher Unteraufgaben.

Um maximale Effizienz zu gewährleisten, sollte die interne Implementierung des Business Logic Servers am einfachsten sein ( KISS-Prinzip ). Da das Benutzermodell vollständig deterministisch ist und keine sich ändernden Beziehungen zwischen Attributen enthält, ist kein flexibler Inferenzmechanismus erforderlich (wie bei einem Smart Home-Controller, bei dem die Benutzerlogik vom Benutzer konfiguriert wird). Daher kann der Betrieb des Geschäftslogikmoduls innerhalb des Servers durch ein herkömmliches algorithmisches Blockdiagramm mit bedingten Übergängen beschrieben werden.


(Klicken Sie auf das Bild, um es in höherer Auflösung zu öffnen.)

Unmittelbar nach dem Start wechselt der Business Logic Server mithilfe der MQTT-Protokolle (von Smart-Home-Controllern) und HTTP (vom Back-End der Client-Anwendung) in den Wartezustand für Nachrichten. Wenn die Nachricht über HTTP eingeht, bedeutet dies, dass der Benutzer mit der Clientanwendung interagiert und Befehle an den Smart Home-Controller sendet oder dessen Konfiguration aktualisiert. Damit die Nachricht vom Client in den Smart-Home-Controller gelangt , wird sie vom Business-Logic-Server an das entsprechende Thema des MQTT-Brokers übertragen, für den der Controller abonniert ist ( Unteraufgabe SendGatewayMessage ).

In der Initialisierungsphase wartet der Smart Home-Controller darauf, dass der Benutzer ihn in seinem persönlichen Konto registriert. Daher wird die Unteraufgabe CheckGatewayExistance ausgeführt , die den entsprechenden Status in der MySQL-Cloud-Datenbank überprüft. Um sich in Ihrem persönlichen Konto zu registrieren, sendet der Controller seine vollständige Konfiguration an den Geschäftslogikserver, der sein Backend an die Clientanwendung ( SendBackend-Unteraufgabe ) sendet , die Konfigurationsdatensätze in der Cloud und in Touch-Datenbanken erstellt und aktualisiert.

Wenn der Smart Home-Controller erfolgreich im persönlichen Konto des Benutzers registriert ist, lädt der Geschäftslogikserver das Benutzermodell aus der Cloud-Datenbank in seinen RAM und beginnt mit der Verarbeitung von Nachrichten von IP-Kameras und Z-Wave-Sensoren gemäß dem folgenden Geschäftslogik-Algorithmus.

JSON-Nachricht vom Z-Wave-Sensor mit Informationsfeldern:

{ "vendor": "*****", "version": "3.0.0", "timestampMs": "1571754749561", "clientType": "gateway", "deviceId": "c8e8de37-d301-45f4-ba01-************", "deviceType": "sensor", "protocol": "zwave", "messageType": "sensorData", "homeId": "0xefa0cfa7", "nodeId": "19", "sensorType": "SENSOR MULTILEVEL", "label": "Temperature", "sensorData": "26.1", "units": "C", "gatewayId": "6774f85a-0a5b-4059-9b68-************" }

Wenn eine Nachricht vom Z-Wave-Sensor über das MQTT-Protokoll eingeht, werden die folgenden Unteraufgaben ausgeführt:

  • StoreSensorDataMySQL aktualisiert (UPDATE) einen vorhandenen Datensatz in der MySQL-Cloud-Datenbank, in dem Informationen zum aktuellen Status und zu den Messungen des Sensors gespeichert werden. Dies ist für eine Clientanwendung erforderlich, die dem Benutzer den aktuellen Status des Smart Homes anzeigt.
  • StoreSensorDataInfluxDB fügt der InfluxDB-Touch-Datenbank einen neuen Datensatz hinzu (INSERT), in dem der Verlauf der Messungen vom Sensor gespeichert wird. Diese Informationen werden bei der Berechnung statistischer Daten für verschiedene Zeiträume (z. B. Energieverbrauch pro Tag, Monat oder Jahr) verwendet und in der Clientanwendung in Form von Grafiken und Tabellen angezeigt.
  • SendPushNotification generiert eine JSON-Nachricht mit einem Zeitstempel, einem Sensornamen , einer Textbeschreibung des Ereignisses, der Kennung des Smartphones des Benutzers, mit dem er in sein persönliches Konto gegangen ist, der internen Kennung der Anwendung im System des OneSignal-Anbieters. Darüber hinaus wird diese Nachricht über die RESTful-API https://onesignal.com/api/v1/notifications an den Push-Benachrichtigungsanbieter gesendet, der sie an das Smartphone des Benutzers übermittelt.

Ein Beispiel für eine JSON-Nachricht von einer IP-Kamera mit Informationsfeldern:

 { "vendor": "*****", "version": "3.0.0", "timestampMs": "1571753150317", "clientType": "gateway", "deviceId": "1616453d-30cd-44b7-9bf0-************", "deviceType": "camera", "protocol": "onvif", "messageType": "deviceState", "deviceState": "streamingOn", "mediaserverIp": "***.***.***.***", "applicationName": "rtp-live-iot", "gatewayId": "6774f85a-0a5b-4059-9b68-************" }

Wenn eine Nachricht über das MQTT-Protokoll von der IP-Kamera eingeht, extrahiert der Geschäftslogikserver ihren Typ aus dem Feld messageType . Abhängig vom Wert dieses Felds werden die folgenden Aktionen ausgeführt:

  • "MessageType": "deviceState" - Die Nachricht enthält Informationen zur Statusänderung der IP-Kamera. Die Unteraufgabe UpdateCameraState wird ausgeführt und aktualisiert die Informationen in der Cloud-Datenbank. Wenn das Feld deviceState entweder StreamingOn oder StreamingOff ist (die IP-Kamera sendet / stoppt den Datenstrom an den Medienserver), wird die Unteraufgabe RecordMediaStream ausgeführt , die einen Befehl zum Aktivieren / Deaktivieren des Archivaufzeichnungsmodus generiert und unter Berücksichtigung des Benutzermodells an den Medienserver sendet.
  • "MessageType": "sensorData" - Informationen zum Betrieb des Bewegungsmelders an der IP-Kamera. Wenn im Benutzermodell der Archivaufzeichnungsmodus auf "vom Bewegungsmelder" eingestellt ist, wird die Unteraufgabe RecordMediaStream ausgeführt . Als Nächstes werden die Unteraufgaben StoreSensorDataInfluxDB (Speichern des Verlaufs des Detektors in der Touch-Datenbank) und SendPushNotification (Senden von Push-Benachrichtigungen über den Anbieter) ausgeführt.
  • "MessageType": "preview" - Die Nachricht enthält einen Frame eines Miniaturbilds von der IP-Kamera, das regelmäßig an die Cloud gesendet wird. Die Unteraufgabe StorePreview speichert sie in einer Cloud-Datenbank. Dann wird es in der Client-Anwendung verwendet, wenn eine Liste von Kameras angezeigt wird.
  • "Nachrichtentyp": "Befehl" - Ein Befehl, der vom Smart Home-Controller gesendet wird, wenn der Benutzer seine Einstellungen über die Webschnittstelle ändert. Es wird die Unteraufgabe RecordMediaStream ausgeführt , die je nach Benutzermodell den Aufzeichnungsmodus auf dem Medienserver ein- und ausschaltet.


(Klicken Sie auf das Bild, um es in höherer Auflösung zu öffnen.)

Als Ergebnis der Arbeit des Geschäftslogikmoduls wird eine Aufgabenwarteschlange gebildet - eine Folge von minimalen Codeabschnitten, die unabhängig voneinander ausgeführt werden. Die Task-Warteschlange wird an den Thread-Pool übergeben , der die Tasks auf die freien Kerne des Zentralprozessors verteilt. Wenn während der Ausführung eine E / A-Sperre auftritt, wird der Thread angehalten und wechselt in den Ruhezustand. Dadurch wird der Kern des Zentralprozessors freigegeben, sodass der Thread-Pool die sofortige Ausführung der nächsten Task aus der Warteschlange starten kann. In dem Moment, in dem die E / A-Sperre aufgehoben wird, ändert der blockierte Thread seinen Status und funktioniert weiter, sobald einer der Kerne des Zentralprozessors freigegeben wird.

Durch Zerlegen der Geschäftslogikaufgabe in viele separate Unteraufgaben, die gleichzeitig ausgeführt werden, wird somit die Leistung des Geschäftslogikservers erhöht. Die Systemskalierung wird erreicht, indem die Anzahl der Kerne des Zentralprozessors und die Anzahl der Geschäftslogikserver im System erhöht werden.

Die Business Logic Server-Anwendung wurde in C ++ entwickelt und wird als systemd- Dienst des Linux Debian Sarge-Betriebssystems ausgeführt. Für die zusätzliche Leistungsüberwachung wird das Überwachungssystem zur Überwachung von Ressourcen verwendet, das den Dienst bei Leistungsproblemen neu startet.

Derzeit führt der Cloud-Dienst einen Geschäftslogikserver aus, der auf der virtuellen Yandex. Cloud-Maschine ausgeführt wird. Parameter der virtuellen Maschine - 4 vCPU-Kerne mit einem garantierten Anteil von 20%, 2 GB RAM, 100 GB Festplatte. Den Berechnungen zufolge reicht diese Leistung aus, um Nachrichten von ~ 1000 Smart Home-Controllern mit jeweils 3 IP-Kameras und 5 Z-Wave-Sensoren zu verarbeiten (die Berechnungen werden während des Systembetriebs geklärt).

Medienserver


Ein Medienserver ist ein dedizierter Server, auf dem spezielle Software installiert ist für:

  • Empfangen von Video- und Audiodatenströmen von Codiergeräten unter Verwendung spezialisierter Netzwerkprotokolle;
  • Speichern von Daten in Form von Archivdateien in seinem Dateisystem;
  • Übertragen Sie Informationen aus Archivdateien in einem Standard-Streaming-Format für die Wiedergabe auf Clientgeräten.

Die Wowza Streaming Engine 4.7.2 mit zusätzlichen Modulen, die in der Java-Sprache entwickelt wurden, wird als Medienserver im Cloud-Smart-Home-System zum Aufzeichnen von Streaming-Daten in ein Dateiarchiv und zum Arbeiten mit einer Cloud-Datenbank verwendet.


(Klicken Sie auf das Bild, um es in höherer Auflösung zu öffnen.)

Der Medienstrom vom Smart-Home-Controller im RTMP-Format gelangt in den Medienserver und wird mit Zeitstempeln im Jitterpuffer abgeglichen . Dies ist erforderlich, um den Effekt von Netzwerkpaketverzögerungen bei der Übertragung des Datenflusses über das Internet zu kompensieren.

Um den Videostream als MP4-Datei im Medienserver-Dateisystem aufzuzeichnen, sendet der Business Logic Server den folgenden Befehl über die RESTful HTTP-API an den Medienserver:

 http://<mediaserverIp>:<port>/v2/servers/_defaultServer_/vhosts/_defaultVHost_/applications/rtp-live-iot/instances/_definst_/streamrecorders/1616453d-30cd-44b7-9bf0-************ { "instanceName": "_definst_", "fileVersionDelegateName": "CustomFileVersionDelegate", "serverName": "", "recorderName": "1616453d-30cd-44b7-9bf0-************", "segmentSchedule": "", "outputPath": "", "currentFile": "", "applicationName": "rtp-live-iot", "fileTemplate": "", "segmentationType": "SegmentByDuration", "fileFormat": "MP4", "recorderState": "", "option": "", "currentSize": "0", "segmentSize": "0", "segmentDuration": "1800000", "backBufferTime": "0", "currentDuration": "0", "startOnKeyFrame": "true", "recordData": "false", "moveFirstVideoFrameToZero": "true", "defaultRecorder": "false", "splitOnTcDiscontinuity": "false" }

Im Feld recorderName wird der Name des Videostreams (IP-Kamera- ID auf dem Smart Home-Controller) im Feld fileVersionDelegateName der Name der geerbten Klasse zur Bestimmung des Ordnerpfads und des Dateinamens angegeben. Der Java-Klassencode wird in der folgenden Liste angezeigt:

 import java.io.File; import java.util.Calendar; import java.util.TimeZone; import com.wowza.wms.livestreamrecord.manager.IStreamRecorder; import com.wowza.wms.livestreamrecord.manager.IStreamRecorderFileVersionDelegate; import com.wowza.wms.logging.WMSLoggerFactory; public class CustomFileVersionDelegate implements IStreamRecorderFileVersionDelegate { @Override public String getFilename(IStreamRecorder recorder) { String sDisk = GetDisk(); if(sDisk == null) { WMSLoggerFactory.getLogger(null).error("CustomFileVersionDelegate::getFilename(): No drive chosen"); return null; } String sStreamName = recorder.getStreamName(); int nCameraId = Integer.parseUnsignedInt(ServiceQueries.GetCameraId(sStreamName)); TimeZone tz = TimeZone.getTimeZone("Europe/Moscow"); Calendar now = Calendar.getInstance(tz); String sDirPath = ServerParams.m_sServerContentPath + "/" + sDisk + "/" + Integer.toString(nCameraId / 200) + "/" + sStreamName + "/" + String.format("%1$tY/%1$tm/%1$td", now); String sFullFilePath = sDirPath + "/" + sStreamName + "_" + String.format("%1$tH_%1$tM_%1$tS", now) + ".mp4"; File dirs = new File(sDirPath); dirs.setExecutable(true); dirs.setWritable(true); dirs.mkdirs(); WMSLoggerFactory.getLogger(null).info( "CustomFileVersionDelegate::getFilename(): Filename created: " + sFullFilePath); return sFullFilePath; } }

In der CustomFileVersionDelegate- Klasse ist die virtuelle getFilename- Funktion der IStreamRecorderFileVersionDelegate- Basisklasse überladen , die vom Medienserver aufgerufen wird, bevor der Stream in die Datei geschrieben wird. Die Funktion erstellt einen Ordner auf der Festplatte mit dem Pfad sDirPath und gibt den vollständigen Pfad zur Datei sFullFilePath zurück .

Da das Volumen der Mediendaten sehr groß ist, enthält das Dateisystem mehrere physische Festplatten mit großem Volumen (8 - 12 TB), die als Unterverzeichnisse bereitgestellt werden. Die Disc mit der größten Menge an freiem Speicherplatz wird während der Aufnahme als Zieldisk ausgewählt. Für einen optimalen Betrieb des Dateisystems beim Zugriff auf die Datei wird der Pfad zum Zielordner wie folgt gebildet:

 /content/<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/

wobei diskId die Kennung der Festplatte ist (gemounteter Ordner),
cameraIdDivideBy200 - das Ergebnis einer ganzzahligen Division der Kamera- ID durch 200,
streamUuid - Medienstromkennung,
Jahr, Monat, Tag - Jahr, Monat und Tag der Aufnahme.

Dies vermeidet eine große Anzahl von Unterordnern innerhalb eines Ordners und dementsprechend einen dramatischen Leistungsabfall des gesamten Dateisystems mit einer Zunahme der Anzahl von IP-Kameras in wolkigen Smart Homes.

Informationen über die IP-Adresse des Medienservers, den Pfad zu der Datei mit den Mediendaten, den Beginn und das Ende des Schreibens in die Datei werden in der Cloud-Datenbank gespeichert und von der Client-Anwendung verwendet, um die Archivzeitachse anzuzeigen, auf der das Video ausgewählt und abgespielt werden kann.

Um den Videostream abzurufen, greift das Front-End der Clientanwendung auf den Medienserver zu und sendet die folgenden Befehle über das HTTP-Protokoll. Für einen "Live" -Videostream:

 https://<mediaserverIp>:<port>/rtp-live-iot/<streamUuid>/playlist.m3u8

Für archivierten Videostream:

 https://<mediaserverIp>:<port>/vod/_definst_/mp4:<diskId>/<cameraIdDivideBy200>/<streamUuid>/<year>/<month>/<day>/<fileName>/playlist.m3u8?wowzaplaystart=<offsetMs>&wowzaplayduration=<durationMs>

Dabei ist Dateiname der Name der Archivdatei auf der Festplatte.
offsetMs - Wiedergabeversatz relativ zum Dateianfang in Millisekunden,
durationMs - Dauer der Wiedergabe in Millisekunden.

Der Medienserver sendet einen Stream im HLS- Format, mit dem Sie H.264 + AAC-Videos in allen modernen Browsern und Mobilgeräten mit iOS- und Android-Betriebssystemen anzeigen können. Der HLS-Paketierer codiert den Stream in Form separater Chunks und sendet ihn über HTTP als Antwort auf eine Anfrage einer mobilen Anwendung.

Um die Speicherkosten und den Zugriff auf Archivdateien zu optimieren, wurde der Cloud-Smart-Home-Medienserver auf der Hardwareplattform Supermicro CSE-825TQ, Motherboard X8DT6, 2xCPU Intel Xeon E5645, 2,4 GHz, 32 GB RAM, 44 TB HDD Adaptec AAC-RAID entwickelt. Der Medienserver wird als dedizierter Server auf der Hosting-Site installiert und stellt eine Verbindung zum Internetkanal mit einer garantierten Breite von 400 Mbit / s her. Die Leistung eines Medienservers reicht aus, um Medienströme von ~ 400 IP-Kameras mit dem H.264-Codec, einer Frame-Auflösung von 720p und einer Bitrate von 1 Mbit / s zu verarbeiten.



Dementsprechend müssen 3 Medienserver installiert und die Last gleichmäßig auf diese verteilt werden, um Streams von 1000 IP-Kameras verarbeiten zu können. Hierzu wird ein Load Balancer verwendet, der als separates AddOn- Plugin für den dynamischen Lastausgleich mit dem Wowza Streaming Engine-Medienserver verbunden ist. Dies unterscheidet in der Tat den Load Balancer (oder Ursprungsserver ), der regelmäßig die Leistungsmetriken von den endgültigen Medienservern (oder Edgeservern ) empfängt und basierend auf diesen Informationen den am wenigsten belasteten Server im Cluster findet.

Der Smart-Home-Controller greift über HTTP auf den Balancer zu und empfängt daraufhin die IP-Adresse dieses Servers, an den der Controller den Medienstrom von der IP-Kamera über RTMP überträgt. Die Leistungsmetrik umfasst die Anzahl der hergestellten Verbindungen zu Quellen und Verbrauchern von Medienströmen sowie die aktuelle Bandbreite des Internetkanals auf dem Server. In den Einstellungen des Balancers können Sie auch die Auswahl des Edgeservers unter Berücksichtigung seiner räumlichen Position festlegen. Auf diese Weise können Sie Server in verschiedenen Städten und Ländern hosten, um ein verteiltes Netzwerk für die Bereitstellung von CDN- Inhalten zu erstellen.

Berühren Sie die Datenbank


Wie bereits im vorherigen Artikel erwähnt, werden die Messwerte der Z-Wave-Sensoren sowie der aktuelle Status und die Ereignisse der IP-Kameras vom Smart Home-Controller mithilfe des MQTT-Protokolls im JSON-Format an die Cloud gesendet. Der Business Logic Server decodiert diese Nachrichten und führt die StoreSensorDataInfluxDB- Subtask aus, die Daten über HTTP an die Touch-Datenbank überträgt.


(Klicken Sie auf das Bild, um es in höherer Auflösung zu öffnen.)

Die Cloud-Datenbank des Smart Home basiert auf InfluxDB 1.7.x - einem Open-Source-Datenbankverwaltungssystem für die Arbeit mit Zeitsequenzen, das in vielen Projekten des Internet der Dinge zum Speichern von Daten von Sensoren und Analysen verwendet wird. Abfragen an die Touch-Datenbank werden in der InfluxQL- Sprache ähnlich wie bei herkömmlichem SQL generiert.

Die Datenspeicherzeit im Cloud Smart Home wird durch den ausgewählten Tarif gemäß dem Benutzermodell bestimmt. Aufgrund der erheblichen Unterschiede in der Menge der Videodaten und Sensordaten ist deren Speicherzeit unterschiedlich. Die Größe des Videoarchivs wird in Tagen (7, 14, 30 Tage mit unterschiedlichen Raten) und die Größe des Sensorarchivs in Jahren (3, 5, 7 Jahre) gemessen. Daher werden für jeden Smart-Home-Controller, wenn er im persönlichen Konto des Benutzers registriert ist, zwei separate Datenbanken mit unterschiedlichen Aufbewahrungsrichtlinien in der Touch-Datenbank erstellt:

 CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras" WITH DURATION 720h SHARD DURATION 1h; CREATE DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors" WITH DURATION 61320h SHARD DURATION 24h;

Das Backend der Client-Anwendung ist für das Erstellen, Bearbeiten und Löschen der Datenbank in der Touch-Datenbank verantwortlich. Wenn beispielsweise ein Cloud-Smart-Home-Benutzer den Tarif ändert, sendet das Backend die folgenden Befehle, um Änderungen an der Speicherrichtlinie vorzunehmen:

 ALTER RETENTION POLICY "autogen" ON "gateway_6774f85a_0a5b_4059_9b68_************_cameras" DURATION 168h SHARD DURATION 1h;

Wenn Sie den Smart Home Controller aus dem persönlichen Konto des Benutzers entfernen, löscht das Backend die entsprechenden Datenbanken:

 DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_cameras"; DROP DATABASE "gateway_6774f85a_0a5b_4059_9b68_************_sensors";

Beim Empfang einer Informationsnachricht vom Smart-Home-Controller führt der Business-Logik-Server eine Anforderung zum Einfügen von Daten in die Touch-Datenbank aus:

 INSERT device_20873eb0_dd5e_4213_a175_************,class=METER,label=Energy,units=kWh value_float=0.05 1572194550125;

Ein Beispiel für eine Tabelle mit Daten von Z-Wave-Sensoren für einen Smart Home-Controller:



Eine der nützlichsten Funktionen eines Cloud-Hauses ist die Berechnung von Statistiken basierend auf den empfangenen Daten. Der Benutzer muss die durchschnittliche Temperatur im Raum kennen oder wissen, wie viel Strom er pro Monat verbraucht hat.

Mit der InfluxQL-Sprache können Sie Abfragen mithilfe von Analysefunktionen ausführen. Um beispielsweise die Durchschnittstemperatur für eine Woche zu berechnen, müssen Sie die folgende Abfrage ausführen:

 SELECT MEAN("value_float") FROM device_63c660da_f0e8_4eca_8d5f_************ WHERE label = 'Temperature' AND time >= '2019-10-21T00:00:00.000Z' AND time <= '2019-10-27T23:59:59.999Z' GROUP BY time(1d) fill(null);

Die Ergebnisse dieser Abfrage werden in der Tabelle angezeigt:



Im nächsten Artikel, der sich ausschließlich der Client-Anwendung widmet, werden wir die Berechnung von Statistiken für verschiedene Parameter und die darauf basierende Erstellung von Tabellen und Grafiken im Detail betrachten.

Im Cloud-Smart-Home-System wird das InfluxDB-DBMS auf einer virtuellen Yandex-Cloud-Maschine mit den folgenden Parametern bereitgestellt: 4 vCPU-Kerne mit einem garantierten Anteil von 20%, 2 GB RAM, 100 GB Festplatte. Nach den Berechnungen dieser Konfiguration ist es ausreichend, die Sensordaten von 3.000 IP-Kameras und 5.000 Z-Wave-Sensoren 7 Jahre lang zu speichern.

Fazit


Der Artikel untersuchte die Architektur eines Cloud-Dienstes für ein Smart Home, den Algorithmus eines Geschäftslogikservers, die Architektur eines Medienservers zum Aufzeichnen, Speichern und Wiedergeben von Medienströmen von IP-Kameras sowie die Architektur einer Touch-Datenbank zum Speichern und Analysieren von Daten von Smart Home-Sensoren. Das Cloud-Service-System funktioniert sowohl auf dedizierten als auch auf virtuellen Servern und sorgt so für mehr Stabilität auf verschiedenen Hosting-Sites. Das System wird derzeit getestet.

Je älter die in der Cloud gespeicherten Daten sind, desto seltener greift der Benutzer darauf zu. In der nächsten Version des Cloud-Dienstes wird vorgeschlagen, den Mechanismus der Ausdünnung (oder Überabtastung) von Daten mithilfe von InfluxDB Continuous Queries zu verwenden, um die mithilfe von Aggregationsfunktionen gespeicherte Datenmenge zu reduzieren und dadurch die Kapazität der Touch-Datenbank zu erhöhen.



Außerdem wird in der nächsten Version des Cloud-Dienstes ein Cluster von Business-Logik-Servern nach dem in diesem Artikel erläuterten Prinzip eines Clusters von Medienservern implementiert. Die Abbildung zeigt die Architektur eines solchen Clusters, bei dem mehrere Edgeserver (von denen jeder über einen separaten MQTT-Broker und eine Business Logic Server-Software verfügt) Leistungsmetriken an den Ursprungsserver senden, der die IP-Adresse des am wenigsten belasteten Servers berechnet. Auf diese Weise können Sie das System in größerem Umfang skalieren und die bestehende Grenze von 1000 Smart Homes überwinden.

Source: https://habr.com/ru/post/de474700/

More articles:


All Articles