Kandidat Thomy Imbach T 0798831767 G +41 44 910 50 10 Kastanienbaumstrasse 51a, 6048 Horw Betrieb (=Durchführungsort) Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 G 044 910 50 10 M info@rafisa.ch | |
|
Verantwortliche Fachkraft Egil Rüefli Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T 078 767 84 04 (P) G 044 910 50 10 M e.rueefli@rafisa.ch | BerufsbildernIn/Lehrfirma Ruedi Wegelin Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T 0765550555 G 044 910 50 10 M r.wegelin@rafisa.ch |
|
Hauptexperte Jean-Dominique Amsler T +41 79 406 58 92 M amsler@iprolink.ch | Nebenexperte Roland Schurtenberger T +41 79 229 70 84 M rocapider@gmail.com |
Titel: Serverraum-Monitoring
Beschreibung: Im Serverraum der Rafisa Informatik GmbH soll mit Hilfe eines Embedded-Linux-Gerätes und entsprechenden Sensoren ein Raum-Monitoring eingerichtet werden.
Arbeitsgebiet: Netzwerkinfrastruktur / WLAN
Plattform: PDA-Betriebssystem / Embedded OS
Programmiersprache: andere Programmiersprache
- RaspberryPi + GrovePi HW
- Server-HW
- Firewall + Switch
- Kamera
- LAMP-System
- Debian Linux
- Programmieren (PHP, HTML, CSS, evtl. Python)
IPA-Block 10, KW17: | 23.04.2019 – 17.05.2019 |
IPA-Durchführung: | 23.04.2019 – 17.05.2019 |
Einreichung bis: | 18.02.2019 |
Serverraum-Monitoring
Die Rafisa Informatik GmbH ist ein Ausbildungsbetrieb für InformatikerInnen EFZ der Abteilungen ICT, Applikationsentwicklung, Betriebsinformatik und Systemtechnik. Die Firma beschäftigt zur Zeit 50 Lernende sowie 16 MitarbeiterInnen. Die produktiven Server sowie die kritischen Elemente des Netzwerkbackbones befinden sich in einem Serverraum im UG der Firma. Dieser Raum wird bisher nicht überwacht.
Gemäss Beschluss der Geschäftsleitung sollen mit Hilfe geeigneter Sensoren neu folgende physikalische Grössen erfasst werden:
- Temperatur
- Luftfeuchtigkeit
Zusätzlich wird eine Kameraüberwachung des Raumes installiert, die bei Wartungsarbeiten durch die Lernenden im Notfall ein schnelles Eingreifen ermöglichen soll.
Alle im Serverraum erfassten Werte werden an einen zentralen Monitoring-Server übermittelt und dort für die Anzeige auf dem Kiosk-System des Helpdesks aufbereitet. Auf dem Monitoring-Server ist zusätzlich ein Alarmsystem einzurichten, das im Fall kritischer Werte die verantwortlichen Stellen informiert.
Realisieren Sie für die Rafisa Informatik GmbH einen Prototyp für ein Serverraum-Monitoring mit Alarmsystem. Alle Komponenten des Monitoring-Systems sind in einer Testumgebung aufzubauen. Die Implementierung in das Produktivsystem erfolgt nach der IPA. Vorschläge für die endgültige Anbringung der Komponenten sind unter Teilaufgabe 1 zu machen.
Die für die Aufgabe zur Verfügung stehenden Mittel sind:
1x GrovePi+ Starter-Kit für den Raspberry Pi
1x Dexter Industries GrovePi Case (Gehäuse)
1x Grove - Temperatur- & Feuchtigkeitssensor
1x Ubiquiti UVC-G3-AF Kamera
1x Server-HW: Zentraler Monitoring-Server mit Linux
1x Arbeitsplatzrechner: für Tests
1x Firewall + Switch: für Aufbau Testumgebung
Die Aufgabe beinhaltet folgende Teilaufgaben:
1. Erheben Sie folgende IST-Informationen [I1]:
- Raumplan/Grundriss Serverraum
- Layer3-Plan des Netzwerkes der Rafisa Informatik GmbH (VLANs, Netzwerkadressen und Netzmasken, Layer3 Geräte wie Router, Firewalls od. Switches mit L3-Funktionalität, Server + Dienste, keine PCs, keine Drucker, Stockwerkinformationen)
- HW-Infos des zur Verfügung gestellten Materials: GrovePi+, Kamera, Linux-Server, Arbeitsplatzrechner, Firewall und Switch
2. Betten Sie Ihr System mit Hilfe folgender SOLL-Dokumentationen in den Aufgabenkontext ein:
- Vorschlag für die Anbringung des GrovePi (Sensoren) und der Kamera im Serverraum → Einzeichnen in Grundriss Serverraum
- Vorschlag für den Standort aller Monitoring-Komponenten im Layer3-Plan
- Netzplan der geplanten Testumgebung [I3]
3. Finden Sie mit Hilfe einer Literaturrecherche Empfehlungen für optimale Temperatur und Luftfeuchtigkeit in einem Serverraum. Bestimmen Sie für die Grössen Temperatur und Luftfeuchtigkeit die Schwellenwerte für die Statusanzeigen „Normal, Warnung, Kritisch“. Begründen Sie Ihre Entscheidungen. [I2]
4. Bauen Sie folgende Testumgebung auf:
- Subnetz: 192.168.78.0/24, GW 192.168.78.1, DHCP-Server: 192.168.78.1, DNS: 8.8.8.8
- Firewall (WAN: 192.168.77.222, LAN: 192.168.78.1, DHCP-Server mit Range 192.168.78-100-150, WAN-GW: 192.168.77.1)
- GrovePi (OS: DexterOS, LAN: 192.168.78.20)
- Kamera (LAN: 192.168.78.21)
- Monitoring-Server (OS: Debian Linux 9 Stretch, LAMP-System, 2 Partitionen: Root + Swap, LAN: 192.168.78.30)
- Arbeitsplatzrechner (OS: Windows 10 Enterprise, LAN: DHCP) → bereits vor IPA erstellt
5. Programmierung des Monitoring-Systems. Entwickeln von Skripte , die folgende Anforderungen erfüllen [I4]:
- Ablesen der Sensor-Informationen sowie des Kamera-Outputs
- Weiterleiten der Sensor-Informationen an zentralen Monitoring-Server
- Speichern der Sensor-Informationen in einer MySQL-Datenbank auf dem zentralen Monitoring-Server
- Mail-Benachrichtigungen an helpdesk@rafisa.ch bei Status-Änderungen, Eskalation bei Warnungen nach 1h, bei kritischen Zuständen nach 10min. [I5]
6. Aufbereitung der Monitoring-Daten auf einer HTML-Seite in Echtzeit [I6]
- Anzeige aller Sensor-Werte
- gängige Design-Grundlagen (Schriftgrösse, Farbe)
- übersichtlich strukturiert (Anordnung der Felder)
- Farbliche Kodierung der Sensor-Werte nach Status „Normal, Warnung, Kritisch“
- Anzeige des Kamera-Inputs
- Automatisches Seitenreload
7. Backup der Datenbank des Monitoring-Servers [I7]
Für die Monitoring Daten soll ein Backup-Konzept entwickelt werden. Die Sensor-Daten sind für mindestens 2 Jahre möglichst lückenlos zu speichern. Zur Speicherung der Daten steht eine CIFS-Freigabe auf einem NAS zur Verfügung.
- Programmieren von Python, PHP, HTML, CSS
- Linux Server
- Aufsetzen Arbeitsplatz-PC mit Windows 10
- Bestellung Material
- Aufsetzen und Üben mit RaspberryPi
IPERKA ist eine Projektmanagement-Methode und steht für:
Im Informieren-Teil von IPERKA werden folgende Themen geklärt
Im Planen-Teil von IPERKA werden folgende Dinge definiert
Beim Entscheiden werden die verschiedenen Lösungswege zusammengefasst und man entscheidet sich für eine Lösung
Beim Realisieren werden die Pläne in die Tat umgesetzt
Beim Kontrollieren überprüfen wir nochmals, ob alles erledigt wurde und ob es auch funktioniert
Zum Schluss werten wir noch aus, welche Optimierungen noch hätten vorgenommen werden können Zudem werden die Erkenntnisse der Arbeit und Reflexion werden zusammengefasst.
Ich habe mich entschieden, IPERKA in meiner IPA zu verwenden, da ich mit IPERKA schon bekannt bin und wir dies in der Schule angewendet haben.
Meine Daten werden über GitHub gesichert. Ich werde folgende Daten sichern:
Um die Daten im GitHub abzuspeichern, verwende ich PHPStorm, ein Programm, mit welchem ich meine Skripte und meine Webseite bearbeiten und im GitHub sichern kann.
Nach der Basisinstallation des Monitor-Servers wurde mit «dd» ein Image auf eine externe Festplatte gemacht.
Das obige Bild zeigt PHPStorm. Unter dem Tab Doku werden die Dokumente zu der IPA gesichert. Man kann mit PHPStorm auf das Rafisa GitHub zugreifen und Daten dort sichern. Mittels Commitwerden alle Änderungen in einer neuen Version übernommen und lokal gesichert. Mit Push werden die Dateien auf den Rafisa GitHub Server gesendet und gesichert.
Zudem hat die verantwortliche Fachkraft Zugriff auf GitHub und kann den momentanen Stand der Doku und der Skripte überprüfen.
Um die Daten zu sichern, kann man im PHPStorm mit Commit alle Daten und Änderungen suchen. Hiezu muss man auf VCS(Version Control System) und dann auf Commit klicken. Danach öffnet sich ein neues Fenster, wo im Feld Commit Message eingetragen wird, welche Änderungen vorgenommen worden sind.
Zuletzt geht man auf VCS → Git → Push klicken, um die Daten auf Rafisa GitHub zu schicken.
Nach Abschluss der Basisinstallation des Monitoring-Servers wurde der Server mit der Bootdisk GRML, einem Toolkit für Systemadministratoren, gestartet. Mit dem Befehl dd wurde ein Image der gesamten Festplatte erstellt:
dd if=/dev/sda of=/mnt/backup/MonitoringServer.20190502.bak
Auf meine Anregung wurde für die IPA ein zweiter vollständiger Satz der Sensoren bestellt, um bei einem Sensorenausfall Ersatz zu haben.
Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig.
Der Auftraggeber ist für die Formulierung des Auftrages zuständig.
Die Realisierung der IPA liegt allein in der Verantwortung des Projektleiters.
Die IPA könnte von externen Einflüssen abhängig sein, welche die planmässige Durchführung beeinflussen könnten.
Um Datenverlust zu verhindern, wird die IPA Dokumentation auf dem Rafisa GitLab gesichert und versioniert, d.h. es kann auf ältere Versionen der Dokumentation zugegriffen werden.
Um mögliche zeitliche Engpässe zu vermeiden, wurde in der Zeitplanung Zeit für Überstunden und zusätzlich Pufferzeit eingeplant.
Bei Arbeitsverhinderung wegen Krankheit / Unfall ist am selben Tag ein ärztliches Zeugnis dem Hauptexperten vorzuweisen, damit die verlorene Zeit gutgeschrieben werden kann.
| TAG 1 ||
Datum | Fr, 26.04.2019 |
Arbeitszeit | 09:00-17:00 |
Ausgeführte Aufgaben | Server-Raumplan erstellt Layer 3 Plan erstellt Hardware Info notiert Temperatur Recherche Zeitplan erstellt Kamera Raspberry Pi-Platzierung geplant Netzpläne erstellt Backupkonzept ausgearbeitet |
Aufgetretene Probleme | Keine |
Problemlösung | Keine |
Reflexion | Planung der Arbeit ging gut. |
Wissensbeschaffung | https://www.didactum-security.com/blog/optimale-temperatur-und-luftfeuchtigkeit-in-serverraum-und-rechenzentrum.html http://www.aue.bs.ch/dam/jcr:67a86c67-b105-48d9-b4c4-9acb189c6840/26_Grad_in_EDV_Raeumen.pdf http://www.itwatchdogs.com/environmental-monitoring-news/data-center/determining-the-best-server-room-temperature-546783 http://greenit.s-i.ch/de/dc/implementation |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
| TAG 2 ||
Datum | Di, 30.04.2019 |
Arbeitszeit | 09:00-17:00 |
Ausgeführte Aufgaben | Backup Konzept Datenfluss Konzept Zustandsdiagramm Programmiersprache wählen Kamera Platzierung entscheiden |
Aufgetretene Probleme | Keine |
Problemlösung | Keine |
Reflexion | Keine Probleme sind aufgetaucht |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
| TAG 3 ||
Datum | Di, 02.05.2019 |
Arbeitszeit | 09:00-17:00 |
Ausgeführte Aufgaben | Konfiguration Kamera Basiseinrichtung Monitoring-Server Einrichtung LAMP auf Monitoring-Server |
Aufgetretene Probleme | Nach Installation des Betriebssystems auf Monitoring-Server hatte ich einen Blackscreen. |
Problemlösung | Betriebssystem neu mit Rufus auf den Stick laden und neu installieren |
Reflexion | Basiseinrichtung des Monitoring-Servers ging länger als erwartet. |
Wissensbeschaffung | https://dl.ubnt.com/guides/unifivideo/UVC-G3_QSG.pdf https://www.ui.com/download/unifi-video/unifi-video-camera-g3 https://www.howtoforge.com/tutorial/install-apache-with-PHP-and-mysql-lamp-on-debian-stretch/ |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Stündlich nein / täglich ja |
| TAG 4 ||
Datum | Di, 03.05.2019 |
Arbeitszeit | 09:00-17:00 |
Ausgeführte Aufgaben | Erstellung der Datenbank Programmierung des Sender- und Receiver-Scripts |
Aufgetretene Probleme | Kleine Syntax Fehler Noch nicht ganz fertig |
Problemlösung | Korrektur der Syntax im Code |
Reflexion | Programmieren der Scripte ging länger als erwartet und bin nicht komplett fertig geworden |
Wissensbeschaffung | https://www.w3schools.com/PHP/PHP_mysql_create_table.asp https://wiki.python.org/moin/TcpCommunication |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Nein |
| TAG 5 ||
Datum | Di, 07.05.2019 |
Arbeitszeit | 09:00-17:00 |
Ausgeführte Aufgaben | Html Seite Kamerasicht auf der Html Seite PHP-Script zum Daten aus der Datenbank holen Scripte fertig programmiert |
Aufgetretene Probleme | Kleine Syntax Fehler Connection refused Mysql connector import ging auf aktueller python version nicht |
Problemlösung | Korrektur der Syntax im Code IP-Adresse im Reveicer-script auf 0.0.0.0 geändert. Mysql connector über pip runtergeladen. |
Reflexion | Connection refused Problem hat länger zum Reparieren gedauert als erwartet. Dem Zeitplan knapp hinten rein. |
Wissensbeschaffung | https://www.w3schools.com/python/python_mysql_insert.asp https://stackoverflow.com/questions/24272223/import-mysql-connector-python https://pip.pypa.io/en/stable/installing/ https://stackoverflow.com/questions/19246103/socket-errorerrno-99-cannot-assign-requested-address-and-namespace-in-python |
Beanspruchte Hilfe | Ja, bei Connection refused habe ich beim Fachverantwortlichen um Hilfe nachgefragt. |
Zeitplan eingehalten | Ja |
| TAG 6 ||
Datum | Di, 08.05.2019 |
Arbeitszeit | 09:00-17:00 |
Ausgeführte Aufgaben | 2. Expertenbesuch Css für html Seite Automatisches Seitenreload |
Aufgetretene Probleme | Hatte zu viel Zeit übrig am Ende |
Problemlösung | Zusätzliche Zeit für Doku verwendet |
Reflexion | Automatischer Seiten reload war einfacher als erwartet und dauerte kaum 10 Minuten. In Zukunft werde ich css und html gleichzeitig machen, da dies zu trennen nicht effektiv ist. |
Wissensbeschaffung | https://stackoverflow.com/questions/8711888/auto-refresh-code-in-html-using-meta-tags https://css-tricks.com/snippets/css/complete-guide-grid/ |
Beanspruchte Hilfe | Nein |
Zeitplan eingehalten | Ja |
| TAG 7 ||
Datum | DO, 09.05.2019 |
Arbeitszeit | 09:00-19:00 |
Ausgeführte Aufgaben | Test Konzept erstellt Backupscript erstellt |
Aufgetretene Probleme | Keine |
Problemlösung | Keine |
Reflexion | Hatte etwas zu viel Zeit eingeplant. Konnte daher ein gutes Stück an der Doku arbeiten. |
Wissensbeschaffung | keine |
Beanspruchte Hilfe | Nein |
Zeitplan eingehalten | Ja |
| TAG 8 ||
Datum | DO, 10.05.2019 |
Arbeitszeit | 09:00-19:00 |
Ausgeführte Aufgaben | Tests vorgenommen Email Warnung hinzugefügt |
Aufgetretene Probleme | Email Warnung im receiver-script wurde noch nicht erledigt |
Problemlösung | Email Warnung im receiver-script eingebaut |
Reflexion | Mir ist im Nachhinein eingefallen, dass ich keine Email Warnung im receiver-script eingebaut habe, daher habe ich dies noch im Nachhinein hinzugefügt |
Wissensbeschaffung | https://stackoverflow.com/questions/1841565/valueerror-invalid-literal-for-int-with-base-10 |
Beanspruchte Hilfe | Nein |
Zeitplan eingehalten | Ja |
| TAG 9 ||
Datum | DO, 14.05.2019 |
Arbeitszeit | 09:00-19:00 |
Ausgeführte Aufgaben | Anpassungen der Kommentare in den Scripts Reflexion erstellt Dokumentation überarbeitet und ausgebessert |
Aufgetretene Probleme | Keine |
Problemlösung | Keine |
Reflexion | Dank den eingeplanten Pufferzeiten hatte ich viel Zeit, die Dokumentation visuell und inhaltlich zu verbessern. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Nein |
Zeitplan eingehalten | Ja |
| TAG 10 ||
Datum | DO, 15.05.2019 |
Arbeitszeit | 09:00-19:00 |
Ausgeführte Aufgaben | Dokumentation ausgebessert Dokumentation auf Rechtschreibfehler überprüft Dokumentation gebunden Kriterien überprüft |
Aufgetretene Probleme | Keine |
Problemlösung | Keine |
Reflexion | Ich habe in der Dokumentation noch einige Lücken entdeckt und diese ausgebessert. Jetzt denke ich, dass die Dokumentation die Kriterien erfüllt. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Ja, (Maura Baumann, Deutschlehrerin. Hilfestellung bei Rechtschreibung) |
Zeitplan eingehalten | Ja |
Teil 2 – Projekt
In der Rafisa Informatik GmbH werden zurzeit rund 50 Lernende in verschiedenen Fachrichtungen ausgebildet, unter anderem Applikationsentwickler, Systemtechniker und Betriebsinformatiker. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa Informatik GmbH auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatikausbildung sowie Bewerbungs- und Job-Coaching an.
Die Rafis Informatik GmbH hat vor kurzem ihre Server im UG stationiert, und diese müssen jetzt überwacht werden. Nun muss evaluiert werden, wie dies umgesetzt werden kann, um die Sicherheit der Server zu garantieren und zu überwachen.
Es wurde entschieden, dass folgende Kriterien bei der Überwachung des Servers erfüllt sein müssen:
Um dies zu erreichen, wird ein Raspberry Pi im Serverraum platziert. Das Gerät verfügt über Sensoren, welche die Temperatur und die Luftfeuchtigkeit im Serverraum konstant überwachen. Zudem wird ein Alarmsystem eingebaut, welches den zuständigen Administrator informiert, sollten diese Werte einen kritischen Bereich erreichen.
Ebenfalls wird eine Kamera eingerichtet, welche den Serverraum konstant aufnimmt und an einen Webserver weitergibt. Im Helpdesk wird der Kamera-Stream auf einer in dieser Arbeit entwickelten Website angezeigt.
Das Aufbauen des Überwachungssystems war erfolgreich und es wurde ein umfangreiches Testkonzept erstellt. Jegliche darin beschriebenen Tests wurden durchgeführt und waren erfolgreich. Zudem gab es keine grossen Komplikationen bei der Ausführung. Nun kann das komplette System nach der IPA von der Testumgebung auf den Serverraum migriert werden.
Der Serverraum wurde vermessen und dann mittels https://planner.roomsketcher.com ein 2D Raumplan erstellt. Beim grösseren der beiden Räume handelt es sich um den Lagerraum, beim kleineren um den eigentlichen Serverraum. Im Serverraum sind zusätzlich die beiden Serverracks eingezeichnet.
Die Höhe des Serverraumes beträgt 264 cm.
Nach der Erstellung des 2D-Raumplanes wurde ein 3D-Raumplan erstellt, welcher später bei der Platzierung der Kamera und des Raspberry Pi helfen wird. Ebenso werden mit dem 3D Raum Plan Simulationen der Kameraposition erstellt, so dass eine gute Vorschau ermöglicht zu sehen, wie es mit der richtigen Kamera später aussehen wird.
Untenstehendes Bild zeigt das Rafisa-Netzwerk im Layer 3 Plan. Das Rafisa-Netzwerk erstreckt sich über vier Stockwerke. Die für die vorliegende Arbeit wichtigen Stockwerke sind zum einen das UG mit dem Serverraum, zum anderen der zweite Stock mit dem Helpdesk Office und dem Grossbildschirm für das Serverraum-Monitoring.
Im Kapitel Planen wird ein Vorschlag für die Platzierung aller relevanten Geräte gemacht.
Netzwerk Layer 3 Plan:
Die Hardwarespezifikationen der Linux Geräte wurden mit folgenden Befehlen ermittelt:
dmidecode –t processor
Gibt Prozessor-Informationen aus
dmidecode –t memory
Gibt Memory-Informationen aus
lcpci
Gibt Informationen zu PCI-Geräten, u.a. zu Netzwerkgeräten aus
Die Hardwarespezifikationen des Windows Rechners wurden über die Systeminformation ermittelt.
Die Information zur Kamera und zu Firewall wurden mit Hilfe der Hersteller-Dokumentationen ermittelt, welche hier zu finden sind:
https://cdn.competec.ch/documents/7/2/722397/EN_Quick-Start-Guide_UVC-G3-AF_QSG.pdf
PC-ZH-202-3 | ||||
Bezeichnung | CPU | Memory | Disks | Netzwerk |
1060 in den HP Pavilion p7-1020chm digitec | intel® Core™ i5-2500 CPU @ 3.30GHz, 3301MHz, 4 kerne, 4 logische crocessoren | 8 GB | 1x 1TB | Realtek PCIe GBE Family Controller |
| Monitoring server |||||
Bezeichnung | CPU | Memory | Disks | Netzwerk |
HP Campaq 6000 | Intel® Core™ 2 Duo | 2GB DDR 3 | 500GB sata | Intel 1Gbit Lan |
| Firewall ||
Bezeichnung | Netzwerk |
Zywall 5 | 4 Lan / 1 Wan 100Mb Interface |
| Raspberry Pi |||||
Bezeichnung | CPU | Memory | Disks | Netzwerk |
Raspberry Pi 3 | ARM v6 | 378 MB | 1x 8GB NOOBS Micro SD card | 100 Mbit lan |
| Grove Pi |||
Bezeichnung | Sensor | Display |
Grove Pi | Grove - Temperature&Humidity Sensor | Grove - LCD RGB Backlight |
| Kamera |||||
Bezeichnung | Stromversorgung | Auflösung | Mikrofon | Netzwerk |
Netzwerkkamera UVC-G3-AF | PoE 802.3af und passiv PoE 24V | 4-Megapixel-Bildsensor; Videoauflösung von HD 1080p (bei 30 fps) | Ja | 1 Gbit Ethernet |
In einer Internet-Recherche habe ich verschiedene Artikel zur empfohlenen Temperatur und Luftfeuchtigkeit in Server-Räumen gefunden.
| Temperatur rechersche |||
Artikel-URL | Vorgeschlagene Temperatur [°C] | Vorgeschlagene Luftfeuchtigkeit [%] |
https://www.didactum-security.com/blog/optimale-temperatur-und-luftfeuchtigkeit-in-serverraum-und-rechenzentrum.html | 18°-27° | 40%-50% |
http://www.aue.bs.ch/dam/jcr:67a86c67-b105-48d9-b4c4-9acb189c6840/26_Grad_in_EDV_Raeumen.pdf | opt: 20°-22° / max: 10°-28° | |
http://www.itwatchdogs.com/environmental-monitoring-news/data-center/determining-the-best-server-room-temperature-546783 | opt: 26° | |
http://greenit.s-i.ch/de/dc/implementation | bis 27° / max: 32°-35° |
Im URL Artikel 1 werden die möglichen Auswirkungen einer falschen Temperatur oder Luftfeuchtigkeit im Serverraum diskutiert. Kalte Luft schadet den Geräten nicht, zu warme kann zu Überhitzung und schlimmstenfalls zum Ausfall von Geräten führen. Während eine zu hohe Luftfeuchtigkeit zu Kondensation führen kann, kann eine zu tiefe Temperatur statische Aufladung und Kurzschlüsse verursachen. Empfohlen werden in Artikel 1 eine Temperatur von 18-27°C bei einer Luftfeuchtigkeit von 40%-50%. In Artikel 2 werden die Maximalschwellen von 10°-28°C und der optimale Bereich von 20°-22°C angegeben. In Artikel 3 wird gesagt, dass in internationalen Studien herausgefunden worden ist, dass man bei 26°C gegenüber 22°C den Stromverbrauch von 35% (Anteil Klimatisierung) auf unter 20% senken kann. Die Fachgruppe Green IT hat eine Umfrage bei grossen Hardware-Herstellern gemacht (Artikel 4). Die Geräte der befragten Hersteller können ohne Einschränkung mit 27°C Einlass leben. Die obere Temperaturgrenze ist heute bei 35°C und bei einigen bei 32°C.
Nach der Internetrecherche wurden folgende Werte als Warnung und kritisch festgelegt:
Sollte die Temperatur 30°C überschreiten, sendet der Raspberry pi eine Warnung an das Monitoring System im Helpdesk. Wird die Temperatur von 34°C überschritten, erhalten der Helpdesk und der Teamleiter je eine Email, damit weitere Massnahmen in die Wege geleitet werden können.
Die nachstehende Abbildung zeigt den Netzplan der Testumgebung. Die Detailinformationen zu den Geräten sind in Tabellenform wiedergegeben.
| Gerät | HW/FW | Schnittstellen | Adressierung | Örtlichkeit | Zugang | Ansprechpartner |
Firewall / Zywall 40 | v4.13 | 4x LAN (100Mbit/s) 1x WAN (100Mbit/s) | LAN: 192.168.77.1 WAN: 213.193.112.98 | UG | Lagerschlüssel + Schlüssel Ausbildner | Teamleiter Netzwerk |
Firewall / Zywall 5 | v4.13 | 4x LAN (100Mbit/s) 1x WAN (100Mbit/s) | LAN: 192.168.78.1 WAN: 192.168.77.222 | Büro 202 | Fingerprint | T. Imbach |
Monitoring-server | Debian 9 Stretch | Intel 1Gbit Lan | LAN: 192.168.78.30 | Büro 202 | Fingerprint | T. Imbach |
Kamera / UVC-G3-AF | - | 1 Gbit Ethernet | LAN: 192.168.78.21 | Büro 202 | Fingerprint | T. Imbach |
Raspberry Pi | DexterOS | 100 Mbit lan | LAN: 192.168.78.20 | Büro 202 | Fingerprint | T. Imbach |
Arbeitsplatz-PC | Win 10 Ent | Realtek PCIe GBE Family Controller | DHCP | Büro 202 | Fingerprint | T. Imbach |
F ür die drei Monitoring-Komponenten - Monitoring Server, Raspberry Pi und Kamera - wird vorgeschlagen, ein eigenes Vlan einzurichten. Im untenstehenden Layer 3 Plan ist diese Vlanmit den drei Komponenten eingezeichnet.
Der Serverraum wurde mit Blender nachgestellt, um eine gute Kamera Platzierung zu finden. Drei mögliche Kamera Platzierungen kamen infrage. Es wurde mit Blender eine virtuelle Kamera platziert sowie eine kurze Simulation erstellt, um festzustellen, ob sich diese Kamera Platzierung eignet.
Hier sind die drei Kamera Platzierungen:
Sicht Kamera_01 (linke vordere Ecke)
Sicht Kamera_02 (rechte hintere Ecke)
Sicht Kamera_03 (rechte Wand mittig)
Die Entscheidung fällt auf Kamera Platzierung 03, da bei dieser Platzierung der Raum bestmöglich abgedeckt ist und diese Platzierung auch einen guten Blick auf die Türe bietet.
Der Raspberry Pi mit den Sensoren wird im Serverraum zwischen den beiden Server Racks auf Höhe des höchsten Servers platziert, da dieser so die Temperatur auf der höchstmöglichen Stelle misst. Dies wurde so entschieden, da die Wärme nach oben steigt und es oben wärmer ist als unten und da wir die Sicherheit aller Server gewährleisten wollen.
Das rote Rechteck ist die Position des Raspberry Pi
Für das Backup müssen folgende Rahmenbedingungen abgeklärt werden: Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten und applikatorische Vorgaben.
Für den Restore werden die entsprechenden Files vom CIFS-Share auf den Debian-Server kopiert. Das MySQL-Dump-File wird zunächst ausgepackt:
Der Raspberry Pi misst die Raumtemperatur und Luftfeuchtigkeit im Serverraum und baut die Verbindung mit dem Monitoring-Server auf, um danach die Messdaten diesem weiterzusenden. Der Monitoring-Server Empfängt die Daten und legt diese in einer Datenbank ab. Zusätzlich ist auf dem Monitoring-Server ein Webserver mit einer Webseite eingerichtet.
Will nun ein User die Daten im Serverraum ablesen, so kann der User auf die Webseite zugreifen und diese wird nun mittels PHP Script die Daten aus der Datenbank holen und dem User anzeigen. Dieser kann dann auch ältere Einträge aus der Datenbank holen.
In der untenstehenden Tabelle finden sich die Meilensteine mit den zugehörigen Planungsdaten:
| Meilenstein | Datum |
Informieren | 26.04.19 |
Planen | 30.04.19 |
Entscheiden | 30.04.19 |
Realisieren | 30.04.19 |
Kontrollieren | 09.05.19 |
Auswerten | 14.05.19 |
Die Meilensteine orientieren sich an der Projektmanagementmethode IPERKA.
In der unten stehenden Tabelle befinden sich die geplanten Arbeitsschritte nach dem IPERKA Prinzip geordnet.
Arbeitsschritte | IPERKA |
Informieren | I |
Server-Raum-Plan erstellen | I |
Layer 3 Plan Netzwerk erstellen | I |
Hardware Info dokumentieren | I |
Temperatur Recherche | I |
Planen | P |
Raspberry Pi / Kamera Platzierung | P |
Vorschlag Netzplan mit Komponenten | P |
Netzplan der Testumgebung | P |
Backup-Konzept | P |
Datenfluss-Konzept | P |
Zustandsdiagramm | P |
Entscheiden | E |
Programmiersprache wählen | E |
Kamera-Platzierung entscheiden | E |
Realisiren | E |
Zusammenbauen / Installation Grove Pi | R |
Konfiguration Kamera | R |
Basiseinrichtung des Monitoring-Servers | R |
Einrichtung LAMP auf Monitoring-Server | R |
Datenbank einrichten | R |
Programmierung der Sender- / Receiver-Script s | R |
Erstellen der Html-Seite | R |
PHP Script zur Daten-Auslesung aus DB | R |
Seiten Reload einbauen | R |
CSS für Html-Seite erstellen | R |
Backup Script | R |
Kontrollieren | K |
Testkonzept erstellen | K |
Testfälle | K |
Anpassungen vornehmen | K |
Auswerten | A |
Reflexion vornehmen | A |
Die Entscheidung, mit welches Sprache die Scripte geschrieben werden sollen, fiel auf Pyhton, da der Lernaufwand nicht für den Projektleiter nicht besonders gross ist und sich gut für das Umsetzen eignet. Zudem hat Dexter Industries bereits einen Editor für Python installiert, welcher gute Vorlagen für das Auslesen der Sensoren hat.
Entscheidungsmatrizen:
Sprache: benennt die Sprache
Erfahrung: Erfahrung im Umgang mit dieser Sprache. Je mehr, desto höher der Wert. Der Wert skaliert von 1 bis 10.
Firmenstandard: Wird die Sprache für andere Projekte in der Firma verwendet? Regelmässig = 10 Punkte, gelegentlich = 5 Punkte, nie = 1 Punkt.
Lernaufwand: Der Wert wird ähnlich eruiert wie der Erfahrungswert, wird aber auch davon beeinflusst, wieviel Unterstützung durch Tutorials oder Mitarbeiter gegeben ist. Dieser Wert wurde mit der Formel (10-Wert) eingetragen, um eine einheitliche numerische Auswertung zu gewährleisten.
Eignung für Aufgabe: Wie geeignet ist die Sprache, um diesen Arbeitsschritt zu bewältigen.
| Auslesen der Sensordaten |||||
Sprache | Python | C/C++ | Java | PHP |
Erfahrung | 6 | 1 | 6 | 5 |
Firmenstandard | 5 | 5 | 5 | 10 |
Lernaufwand* | 8 | 2 | 8 | 5 |
Eignung für Aufgabe | 10 | 10 | 7 | 1 |
Summe | 29 | 18 | 26 | 21 |
| Übertragung Raspberry Pi auf DB |||||
Sprache | Python | C/C++ | Java | PHP |
Erfahrung | 6 | 1 | 6 | 5 |
Firmenstandard | 5 | 5 | 5 | 10 |
Lernaufwand* | 8 | 2 | 8 | 5 |
Eignung für Aufgabe | 10 | 5 | 5 | 8 |
Summe | 29 | 13 | 24 | 28 |
| Darstellung der Daten |||||
Sprache | Python | C/C++ | Java | PHP |
Erfahrung | 6 | 1 | 6 | 5 |
Firmenstandard | 5 | 5 | 5 | 10 |
Lernaufwand* | 8 | 2 | 8 | 5 |
Eignung für Aufgabe | 7 | 5 | 7 | 10 |
Summe | 26 | 13 | 26 | 30 |
In der untenstehenden Abbildung sieht man den gewählten IP-Range des DHCP-Dienstes auf der Firewall (192.168.78.1).
Der Raspberry Pi besteht aus zwei Teilen: dem Raspberry Pi 3 model B (Bild oben rechts) und dem GrovePI (Bild oben links). Beide werden wie auf dem rechten Bild dargestellt und so zusammengesteckt.
Danach wurde der Raspberry Pi in das für ihn zugeschnittene Gehäuse verschraubt.
Zuletzt wurde der Luftfeuchtigkeits- und Temperatursensor und noch ein LED Screen am Raspberry Pi angebracht, um auch im Serverraum die momentane Temperatur ablesen zu können.
Der Luftfeuchtigkeit- und Temperatursensor wurde an Slot D2 angebracht und der LED Screen an Slot 12C-3.
Um ein Betriebssystem auf dem Raspberry Pi zu installieren, wurde die SD Karte aus dem Raspberry Pi entfernt und mittels eines USB Adapters in den Arbeits PC eingesteckt. Danach wurde das Betriebssystem «Raspbian_For_Robots_by_Dexter_Industries-stretch» direkt von der Homepage des Herstellers heruntergeladen und mit dem Programm Rufus auf die SD Karte installiert.
Die Kamera wurde mit einem Powerover Ethernet Adapter ans Netz angeschlossen. Über einen Portscan wurde ermittelt, auf welcher IP der DHCP die Kamera platziert hat. Mit der IP kann über das Weblogininterface auf die Kamera zugegriffen werden.
Der Default Username und das Password lautet ubnt.
Benutzeranleitung: https://dl.ubnt.com/guides/unifivideo/UVC-G3_QSG.pdf
Das Passwort wurde auf Password1gesetzt.
Im Anschluss ist die UniFi Video® Software installiert worden.
Download Link: https://www.ui.com/download/unifi-video/unifi-video-camera-g3
Das untenstehende Bild zeigt das UniFi Video® Weblogin Interface an:
Mit dem Wizard wir die Installation durchgeführt und dann die Software gestartet. Mit Rechtsklick open in Browser auf das Symbolleisten Icon kann auf die Software zugegriffen werden. Alternativ kann dies auch über https://127.0.0.1:7443/camerasin einem Browser aufgerufen werden.
Nun muss noch ein Account erstellt werden. Dazu werden die folgenden Daten verwendet:
Nach dem Erstellen des Kontos gibt die Software ein Camera Recovery Password aus:
Kamera recovery Passwort: ZJDPTw46OD
Nun wird die Kamera erkannt, aber es gibt noch keinen Zugriff auf die Kamera. Um diesen zu erhalten, muss man sich unter dem Tab Kameras auf der Kamera mit dem auf der Kamera eingestellten Passwort und Username anmelden («Username: ubnt», Passwort: «Password1»).
Für das Aufsetzen und Einrichten des Monitoring-Servers wurde das debian-9.6 benutzt. Mittels dem Programm rufus wurde ein USB Stick bootbar gemacht und das debian darauf geladen.
Bei der Installation des debian auf dem Server wurden folgende Daten verwendet:
Die Einrichtung und die Konfiguration des LAMP Systems wurden mit folgender Anleitung erreicht:
https://www.howtoforge.com/tutorial/install-apache-with-PHP-and-mysql-lamp-on-debian-stretch/
Um mit der Einrichtung des LAMP Systems zu starten, wurden im Terminal folgende Befehle eingegeben:
apt-get -y install MariaDB-server MariaDB-client
Es wird nachgefragt, ob ein root Passwort einrichten werden soll:
Set root password? [Y/n]
Mit Ybestätigen.
Danach wird nach einem Passwort gefragt. Es wurde Password1benutzt.
Remove anonymous users? [Y/n]
Mit Ybestätigen, um den anonymous user zu entfernen.
Disallow root login remotely?
Mit Ybestätigen, um das remote root login zu verweigern.
Remove test database and access to it?
Mit Ybestätigen, um die Test DB zu entfernen.
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!
Sobald obiger Text erscheint, ist die Installation von MariaDB abgeschlossen.
Mit folgendem Befehl wird Apache2 auf dem Monitoring-Server installiert:
apt-get -y install apache2
Um zu überprüfen, ob die Installation erfolgreich war, wurde im Webbrowser folgender Link eingegeben: «http://192.168.78.30».Erscheint die untenstehende Seite, war die Installation erfolgreich.
Jetzt wird PHP, beziehungsweise das Apache PHP Modul installiert.
apt-get -y install PHP7.0 libapache2-mod-PHP7.0
Apache2 muss nach der Installation neu gestartet werden.
service apache2 restart
Um zu testen, ob die Installation erfolgreich war, wird im Verzeichnis /var/www/htmleine neue Datei erstellt.
nano /var/www/html/info.php
In die soeben erstellte Datei wird folgendes geschrieben:
<?PHP
PHPinfo() ;
?>
Mit PHPinfo();wird unter dem Link: http://192.168.78.30/info.php
die PHP info Seite geladen, die dann Informationen über die momentane PHP Installation ausgibt. Das nebenstehende Bild zeigt, wie es aussehen sollte, wenn diese Seite geöffnet wird.
Mit nachstehendem Befehl werden alle Pakete im PHP7 angezeigt.
apt-cache search PHP7.0
Es werden folgende Pakete installiert:
apt-get -y install PHP7.0-mysql PHP7.0-curl PHP7.0-gd PHP7.0-intl PHP-pear PHP-imagick PHP7.0-imap PHP7.0-mcrypt PHP-memcache PHP7.0-pspell PHP7.0-recode PHP7.0-sqlite3 PHP7.0-tidy PHP7.0-xmlrpc PHP7.0-xsl
Nun muss Apache wieder neu gestartet werden.
PHP –version
Mit obigem Befehl wird die momentane PHP Version ausgegeben. Wenn in der Beschreibung with zend OPcache steht, kann man den nächsten Schritt überspringen und gleich zu 11.1.7 gehen.
Sollte das OPcache Modul nicht angezeigt werden, wird folgender Befehl ausgeführt:
apt-get -y install PHP7.0-opcache
gefolgt von:
apt-get -y install PHP-apcu
Nun muss Apache2 wieder neu gestartet werden.
Wenn man nun auf http://192.168.78.30/info.phpdie Seite neu lädt, sollte man die neuen Module sehen.
Mit:
apt-get -y install PHPmyadmin
wird die PHPmyadmin Installation gestartet.
Nun wird gefragt, ob Apache2 oder Lighttbd installiert werden soll. Gewählt wird apache2.
Bei:
Configure database for PHPmyadmin with dbconfig-common?
wird Yesausgewählt.
Bei der Passwortabfrage wird das Passwort Password1benutzt. Um nun noch das root login im PHPMyAdmin zu aktivieren, wird folgender Befehl ausgeführt:
echo „UPDATE mysql.user SET plugin = 'mysql_native_password' WHERE user = 'root' AND plugin = 'unix_socket';FLUSH PRIVILEGES;“ | mysql -u root -p
Nun kann man sich auf http://192.168.78.30/PHPmyadmin/ mit dem Benutzernamen rootund dem Passwort Password1anmelden.
Bevor mit dem Schreiben des Scriptes gestartet werden kann, muss die Datenbank für die Sensor Datenablage erstellt werden.
Mit dem nachstehenden Befehl kann man auf das mysql Kommandointerface zugreifen.
mysql –u root -p
Wird das Passwort verlangt, Password1 eingeben
Die Datenbank sensors wird wie folgt erstellt:
CREATE DATABASE sensors;
Um nun in der Datenbank sensors zu arbeiten, muss diese ausgewählt werden. Dazu benutzt man folgenden Befehl:
USE sensors;
Um die Tabelle zu erstellen, wurde folgender Befehl eingegeben:
CREATE TABLE sensordatas(
ID int auto_increment,
primary key(id),
timestamp varchar(255),
temp varchar(255),
hum varchar(255)
);
Es wird eine Tabelle mit dem Namen sensordatas und den folgenden colums erstellt:
Nun wird der User helpdeskmit dem Passwort Password1erstellt, damit später die Scripte diese Login Daten für den Zugriff auf die Datenbank benutzen können.
Hierzu werden folgende Befehle ausgeführt:
CREATE USER 'helpdesk'@'localhost' IDENTIFIED BY 'Password1';
Die Zugriffsrechte werden dem Benutzer helpdesk zugeteilt.
GRANT ALL PRIVILEGES ON * . * TO 'helpdesk'@'localhost';
Mit:
select Host,User from mysql.user;
kann sichergestellt werden, dass der Benutzer auch erstellt worden ist.
Mit:
exit
wird das mysql interface verlassen.
Das Sender-Script auf dem Raspberry Pi muss folgende Kriterien erfüllen:
Wird das Sender-Script gestartet, baut dieses eine Verbindung zum Server auf. Kann keine Verbindung aufgebaut werden, wird eine Fehlermeldung ausgegeben und das Script beendet.
W ird die Verbindung erfolgreich aufgebaut, so misst das Script die Temperatur und die Luftfeuchtigkeit im Serverraum. Anschliessend überprüft es, ob die Angaben überhaupt stimmen oder ob eine Fehlermeldung bei dem Sensor entstanden ist. Sollte letzteres der Fall sein, so wird der Fehler ausgegeben und das Script gestoppt. Sollte der Sensor keinen Fehler ausgeben und stattdessen die Temperatur und Luftfeuchtigkeit ausgeben, wird das Sender-Script mit den Angaben den Farbcode des LED Displays, welches sich im Serverraum befindet, berechnen. Wie das Script diesen ausrechnet, ist im Kapitel 11.3.4beschrieben. Das LED zeigt dadurch den Zustand des Servers an. Nun wird überprüft, ob der User einen Keyboard-Input gibt, um das Script manuell zu stoppen. Sollte dies nicht der Fall sein, wird die Temperatur und Luftfeuchtigkeit als String an den Monitoring-Server gesendet.
Entlang der ursprünglichen Planung soll das Script nach einer Wartezeit von 5 Sekunden an die Stelle springen, an der die Daten gemessen werden. Nach dem Langzeittest wurde beschlossen, dass 5 Sekunden Intervall zu hoch sind und es wurde entschieden, dass 60 Sekunden besser sind. Der Grund dafür ist, dass die Informationsdichte zu hoch ist, um das Verhalten über eine Stunde übersichtlich zu bewerten.
Das Receiver-Script auf dem Monitoring-Server muss folgende Kriterien erfüllen:
Sobald das Script gestartet wird, wartet es auf den Verbindungsaufbau mit dem Raspberry Pi. Daher sollte das Receiver-Script immer als Erstes gestartet werden. Sobald der Raspberry Pi mit dem Monitoring-Server die Verbindung aufgebaut hat, empfängt das Reveicer Script die Daten, die zu diesem Zeitpunkt ein einzelner String sind,undtrennt diese in temp und hum auf, damit er diese in die Datenbank einfügen kann. Beim Einfügen in die Datenbank erstellt das Receiver-Script noch einen Timestamp mit dem Zeitpunkt, an dem die Einfügeoperation ausgeführt wird. Zudem gibt er dem Eintrag eine ID, die später helfen wird, den neusten Eintrag aus der Datenbank zu holen.
Zudem wird bei kritischen Werten eine Email an den Helpdesk gesendet, worin der Helpdesk auf die kritischen Werte aufmerksam gemacht wird. Diese Email enthält einen Link zu einer Webseite mit den Statuswerten. Dies wird mit folgenden Zeilen im Code erreicht:
Das LED Display, welches am Raspberry Pi angebracht ist, verwendet RGB Werte von 0 – 255, um die Farbe des Displays zu bestimmen. Daher muss das Script eine Farbskala erstellen, welche von grün auf gelb auf rot wechselt, je nachdem wie nahe die Temperatur im Serverraum sich der kritischen Temperatur nähert. Um dies zu erreichen, werden wir eine Variable erstellen, welche colortemp genannt wird und zwischen 0 und 510 liegt, wobei 0 eine grüne Farbe und 510 eine rote Farbe anzeigen soll.
Um die Temperatur im Serverraum auf die Variable colortemp anzupassen, müssen wir diese mit einem Faktor multiplizieren. Um diesen Faktor berechnen zu können, müssen wir die maximale Temperatur im Serverraum angeben, welche wir noch tolerieren. Danach rechnen wir 510 / (maximale Temperatur im Serverraum). Diesen Faktor multiplizieren wir mit der momentanen Temperatur im Serverraum. Sollte die Temperatur im Serverraum höher sein als die Temperatur, welche wir tolerieren, so wird die Zahl, welche aus dieser Rechnung erfolgt, 510 überschreiten.
Die Webseite dient dazu, dem Helpdesk immer einen Überblick über den Serverraum zu gewährleisten. So kann dieses reagieren, wenn im Serverraum die Temperatur und die Luftfeuchtigkeit problematische Werte erreichen.
Die Webseite wird im Helpdesk auf einem Bildschirm angezeigt. Es muss schnell ersichtlich werden, sollten die Sensoren unerwünschte Messungen aufzeigen.
Auf der Webseite sollte folgendes ersichtlich sein:
Wie das obige Bild zeigt, ist die Webseite dreiteilig aufgebaut. Dazu wurde ein CSS Grid verwendet. In Fläche (1) befindet sich die Kamerasicht, die das letzte gemachte Bild anzeigt.
Fläche (2) zeigt die aktuelle Temperatur und Luftfeuchtigkeit an. Die Anzeigen sind so programmiert, dass die Schriftfarbe rot erscheint, sollte die Temperatur über 35°Cund die Luftfeuchtigkeit über 50% steigen, und am Ende des Schriftzuges das Wort «Alarm» ausgegeben wird. Die Temperatur- und die Luftfeuchtigkeitswerte, welche in Fläche (2) angezeigt werden, werden aus der Datenbank sensorsauf dem Monitoring-Server geholt. Der Eintrag mit der grössten ID ist der aktuellste Stand der Daten. Im Nachhinein wurde ein Zeitstempel implementiert, der anzeigt, wann diese Daten gemessen worden sind (Jahr-Monat-Tag; Stunde-Minute-Sekunde).
Fläche (3) dient dazu, ältere Einträge aus der Datenbank zu holen. Hierzu kann eine bestimmte Anzahl an erfolgten Einträgen im dafür vorgesehen Fortschrittsbalken eingegeben werden, worauf die Werte in Fläche (3) erscheinen.
Um das Bild von der Kamera auf der Webseite anzeigen zu lasse, wurde folgender Code in der Webseite eingebettet:
Das Bild links zeigt, wie der Datensatz formatiert ist, wenn sich die Werte im Normalbereich befinden.
Das Bild rechts zeigt einen Warnungszustand an, bei welchem der Helpdesk genauer hinschauen aber noch nicht handelt muss.
Das Bild links zeigt die Formatierung der Anzeige bei kritischen Werten. Gleichzeitig erhält nun der Helpdesk eine Alarm Email, nach deren Empfang er sofort handeln muss.
Um die Daten aus der Datenbank auszulesen und auf der Seite anzeigen zu können, muss erst eine Verbindung mit der Datenbank hergestellt werden.
$servername = „127.0.0.1“;
$username = „helpdesk“;
$password = „Password1“;
$dbname = „sensors“;
// verbindung herstellen
$conn = new mysqli($servername, $username, $password, $dbname);
// verbindung überprüfen
if ($conn→connect_errno) {
die(„Connection failed: “ . $conn→connect_error);
} else {
//echo „success“; }
Um nun die aktuellsten Daten aus der Datenbank zu holen, wird folgende query verwendet:
$sql = „SELECT * FROM sensordatas ORDER BY ID DESC LIMIT 1; “;
Mit dieser query wird der Eintrag mit der höchsten ID genommen, welche immer der aktuellste ist.
Auf dem AD Server der Lernenden (192.168.77.31) wurde vor der IPA eine Freigabe für das Backup eingerichtet. Die Freigabe wird bei jedem Systemstart automatisch eingebunden. Diese Einbindung wird durch folgenden Eintrag in /etc/fstab erreicht:
//192.168.77.31/backup_monitor /mnt/backup CIFS username=backup_monitor,password=Password1,sec=ntlm 0 0
Auf dem System müssen die CIFS-utils vorhanden sein, ansonsten sie mit folgendem Befehl installiert werden müssen:
apt-get install CIFS-utils
Für das Backup wurden drei bash-scripts angelegt, eines für die täglichen Backups, eines für die wöchentlichen Backups und eines für die monatlichen Backups.
Unten ist als Beispiel das Script für das tägliche Backup:
#!/bin/bash
/usr/bin/mysqldump –user=helpdesk –password=Password1 sensors | gzip > /mnt/backup/daily/sensors.$(date +„%Y%m%d_%H%M%S“).gzip
find /mnt/backup/daily/ -mtime +7 -type f -delete
In der Zeile 2 des obigen Scripts erfolgt der mysql dump der Datenbank sensors und wird als zip file im Verzeichnis /mnt/backup/daily mit dem aktuellen Datum als Name abgelegt.
In Zeile 4 werden sämtliche Dateien, die älter sind als sieben Tage, aus dem Verzeichnis /mnt/backup/daily gelöscht (geforderte Aufbewahrungszeit für das tägliche Backup).
Das wöchentliche und das monatliche Backup werden genau gleich ausgeführt, der einzige Unterschied liegt in der Aufbewahrungsfrist und dem Speicherort.
Die Scripts werden in das für sie zuständige Verzeichnis gespeichert:
Die Skripte werden jeweils zu folgenden Zeiten ausgeführt.
Die Ausführungszeiten der cronjobs finden sich im file /etc/crontab.
Für den Restore werden die entsprechenden Files vom CIFS-Share auf den Debian-Server kopiert. Das MySQL-Dump-File wird zunächst ausgepackt:
cat sensors .20190410_222828.gzip | gunzip > sensors .sql
Danach wird die Datenbank wiederhergestellt mit:
mysql –user=helpdesk –password=Password1 sensors < sensors .sql
Um das Testing gut und strukturiert durchführen zu können, werden die wichtigsten Funktionen in drei Bereiche aufgeteilt und getestet:
Manche der durchgeführten Tests sind redundant aufgelistet, da diese mehrere Bereiche simultan testen und daher die gleiche Testnummer haben.
Testfall Nr. | #1 |
Beschreibung | Senden und empfangen von Daten |
Vorgehen | Sender- und Receiver-Script werden gestartet und es wird überprüft, ob der Datentransfer funktioniert |
Voraussetzungen | Raspberry Pi und Monitoring-Server im gleichen Netz |
Erwartetes Resultat | Ausgabe der beiden Scripts muss übereinstimmen |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #2.1 |
Beschreibung | Stimmt Ausgabe des Temperatursensors? |
Vorgehen | Ausgabe des Sensors wird mit der momentanen Raumtemperatur verglichen |
Voraussetzungen | Raspberry Pi muss fertig konfiguriert sein und der Sensor muss eingesteckt sein. Ein Thermometer im Raum. |
Erwartetes Resultat | Raumtemperaturen stimmen überein |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #3 |
Beschreibung | Funktioniert der Datenbankeintrag |
Vorgehen | Sender-Script sendet Daten an Receiver, Receiver empfängt diese und gibt sie in die Datenbank ein |
Voraussetzungen | Datenbank erstellt, Sender- / Receiver-Scripte fertiggestellt |
Erwartetes Resultat | Datenbankeintrag stimmt mit Ausgabe des Sender-Scriptes überein. |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #4.1 |
Beschreibung | LED Display Ausgabe |
Vorgehen | Vergleichen der LED Display Ausgabe mit Ausgabe im Sender- Script |
Voraussetzungen | LED Display eingesteckt, Sender-Script fertiggestellt |
Erwartetes Resultat | Daten auf dem LED Display stimmen mit der Datenausgabe im Sender-Script überein. |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #5.1 |
Beschreibung | LED Displayfarbe, wenn Temperatur höher ist als gewünscht |
Vorgehen | Script wird manipuliert, damit die Ausgabe auf LED Display eine zu heisse Servertemperatur anzeigt |
Voraussetzungen | LED Display eingesteckt, Sender-Script fertiggestellt |
Erwartetes Resultat | Der LED Display Hintergrund wird rot angezeigt |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #6 |
Beschreibung | LED Displayfarbe, wenn Temperatur unproblematisch ist (grün) |
Vorgehen | Script wird manipuliert, damit die Ausgabe auf LED Display eine gewünschte Servertemperatur anzeigt |
Voraussetzungen | LED Display eingesteckt, Sende-Script fertiggestellt |
Erwartetes Resultat | Der LED Display Hintergrund wird grün angezeigt |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #7 |
Beschreibung | LED Displayfarbe, wenn sich die Temperatur einem unerwünschten Wert nähert (gelb - orange |
Vorgehen | Script wird manipuliert, damit die Ausgabe auf LED Display eine etwas wärmere Servertemperatur anzeigt |
Voraussetzungen | LED Display eingesteckt, Sender-Script fertiggestellt |
Erwartetes Resultat | Der LED Display Hintergrund wird gelb bis orange angezeigt |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #8 |
Beschreibung | Einbinden des CIFS shares |
Vorgehen | Eingabe des Befehls mount –a (alles in fstab wird eingehängt) |
Voraussetzungen | Eintrag in /etc/fstab umount des backupshares mit: umont /mnt/backup |
Erwartetes Resultat | Der backupshare ist nun unter /mnt/backup gemountet, überprüft wird das mit dem Befehl df |
OK / nicht OK | Ok Ausgabe von df: //192.168.77.31/backup_monitor 419839996 45160332 374679664 11% /mnt/backup |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #9 |
Beschreibung | Test des Backups |
Vorgehen | Ausführung von /etc/cron.daily/backup_monitor_daily.sh /etc/cron.weekly/backup_monitor_weekly.sh /etc/cron.monthly/backup_monitor_monthly.sh |
Voraussetzungen | CIFS share muss eingehängt sein. |
Erwartetes Resultat | Es befindet sich jeweils ein Backupfile mit dem aktuellen Datum im Filenamen im zugehörigen Verzeichnis |
OK / nicht OK | Ok Ausgabe von /mnt/backup/daily: root@MonitoringServer:/mnt/backup/daily# ls sensors.20190510_181335.gzip Ausgabe von /mnt/backup/weekly: root@MonitoringServer:~# ls /mnt/backup/weekly/ sensors.20190510_181428.gzip Ausgabe von /mnt/backup/monthly: root@MonitoringServer: ~# ls /mnt/backup/monthly/ sensors.20190510_181539.gzip |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #10 |
Beschreibung | Test des Restores |
Vorgehen | Mit mysal –user=helpdesk –password=Password1 sensors < sensors.sql |
Voraussetzungen | Das komprimierte zip file muss ausgepackt werden, dies wird mit folgendem Befehl ausgeführt: cat sensors.20190510_181539.gzip | gunzip > sensors.sql |
Erwartetes Resultat | Momentane Daten in der sql Datenbank werden durch das Backupfile überschrieben |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #11 |
Beschreibung | Email Test bei kritischem Zustand |
Vorgehen | Der Monitoring-Server wird so manipuliert, dass ein kritischer Zustand entsteht und dann wird das Script gestartet |
Voraussetzungen | Script muss manipuliert sein, damit es einen kritischen Zustand ausgibt. |
Erwartetes Resultat | Tester erhält eine Email |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #12 |
Beschreibung | Email Test bei unkritischem Zustand |
Vorgehen | Der Monitoring-Server wird so manipuliert, dass ein normaler Zustand (d.h. keine kritischen Werte vorhanden) angezeigt wird, und dann wird das Script gestartet. |
Voraussetzungen | Script muss manipuliert sein, damit kein kritischer Zustand ausgegeben wird |
Erwartetes Resultat | Der Tester erhält keine Email |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #4.2 |
Beschreibung | LED Display Ausgabe |
Vorgehen | Vergleichen der LED Display Ausgabe mit Ausgabe im Sender- Script |
Voraussetzungen | LED Display eingesteckt, Sender-Script fertiggestellt |
Erwartetes Resultat | Daten auf dem LED Display stimmen mit der Datenausgabe im Sender-Script überein. |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #5.2 |
Beschreibung | LED Displayfarbe, wenn Temperatur höher ist als gewünscht |
Vorgehen | Script wird manipuliert, damit die Ausgabe auf LED Display eine zu heisse Servertemperatur anzeigt |
Voraussetzungen | LED Display eingesteckt, Sender-Script fertiggestellt |
Erwartetes Resultat | Der LED Display Hintergrund wird rot angezeigt |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #2.2 |
Beschreibung | Stimmt Ausgabe des Temperatursensors? |
Vorgehen | Ausgabe des Sensors wird mit der momentanen Raumtemperatur verglichen |
Voraussetzungen | Raspberry Pi muss fertig konfiguriert sein und der Sensor muss eingesteckt sein. Ein Thermometer im Raum. |
Erwartetes Resultat | Raumtemperaturen stimmen überein |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #13 |
Beschreibung | Bekommen wir ein Bild von der Kamera? |
Vorgehen | Es wird mit dem unifi video überprüft, ob die Kamera ein Bild zurück gibt. |
Voraussetzungen | Unifi video muss installiert sein |
Erwartetes Resultat | Es ist zu sehen, was sich vor der Kamera befindet |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #14 |
Beschreibung | Korrektheit der Daten auf der Webseite |
Vorgehen | Die Daten auf der Webseite werden mit den letzten Einträgen in der Datenbank verglichen |
Voraussetzungen | Es müssen mindesten zwei Einträge in der Datenbank vorhanden sein |
Erwartetes Resultat | Daten stimmen überein. |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #15 |
Beschreibung | Webseite bei Alarmzustand |
Vorgehen | Es wird überprüft, ob die Webseite eine visuelle Warnung bei Alarmzustand ausgibt |
Voraussetzungen | Daten müssen manipuliert werden, damit diese einen Temperaturzustand anzeigen, welcher die Alarmschwelle überschreitet. |
Erwartetes Resultat | Schrift ist rot und der Schriftzug Alarm wird ausgegeben |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #16 |
Beschreibung | Webseite kurz vor kritischem Zustand |
Vorgehen | Es wird überprüft, ob die Webseite eine visuelle Warnung bei kritischem Zustand ausgibt |
Voraussetzungen | Daten müssen manipuliert werde, damit diese einen kritischen Temperaturzustand anzeigen |
Erwartetes Resultat | Schrift ist orange |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #17 |
Beschreibung | Webseite bei normalem Zustand |
Vorgehen | Es wird überprüft, ob visuell sichtbar ist, dass Werte normal sind (grün) |
Voraussetzungen | Daten müssen manipuliert werden, damit diese einen normalen Temperaturzustand anzeigen |
Erwartetes Resultat | Schrift ist grün |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #18 |
Beschreibung | Webseite zwei ältere Messungen anzeigen lassen |
Vorgehen | Es wird nach zwei Einträgen aus der Datenbank verlangt |
Voraussetzungen | Zwei oder mehr Einträge müssen sich in der Datenbank befinden |
Erwartetes Resultat | Zwei Einträge aus der Datenbank werden angezeigt |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Testfall Nr. | #19 |
Beschreibung | Webseite mehr ältere Einträge anzeigen lassen als in der Datenbank vorhanden |
Vorgehen | Es wird nach 1000 Einträgen aus der Datenbank verlangt |
Voraussetzungen | Es müssen sich 100 oder weniger Einträge in der Datenbank befinden |
Erwartetes Resultat | 100 Einträge werden angezeigt, keine Fehlermeldung |
OK / nicht OK | Ok |
Aufgetretene Fehler / Bemerkungen | keine |
Insgesamt wurden in diesen Bereichen 19 Tests durchgeführt. Die Tests waren alle erfolgreich. Die technische Realisierung des Projektes kann deshalb als erfolgreich bezeichnet werden.
Bei einem Folgeprojekt würde ich im Code noch folgende Verbesserungen vornehmen:
Zur besseren Fehlererkennung und -behandlung kann in der Datenbank eine Tabelle für Fehlermeldungen angelegt werden. Je nach Art des Fehlers wird das Generieren der Nachricht im Receiver- oder Senderskript implementiert.
Mögliche Fehler, die abgefangen werden könnten, sind:
Die Fehlerauswertung wäre in «read.php» zu implementieren.
Ich bin grundsätzlich mit meiner IPA zufrieden, ich konnte viel dazulernen. Jedoch gibt es einige Punkte, bei denen ich nicht ganz zufrieden mit meiner Leistung bin und die hätten besser sein können. Ich konnte die Zeit der verschiedenen Teilpunkte nicht richtig einschätzen. So war ich an einigen Tagen mit allen Aufgaben früher fertig als erwartet und wiederum an anderen Tagen habe ich die Arbeit unterschätzt und es dauerte länger als erwartet. Zudem bin ich zwei Mal in Zeitnot gekommen wegen unerwarteter Probleme. Daher würde ich in Zukunft beim Realisieren immer etwas mehr Zeit einplanen als erwartet, damit solche Probleme gar nicht erst entstehen.
Der technische Teil meiner Arbeit hat mir wiederum seht gut gefallen. Oft habe ich mich dabei erwischt, noch kleine zusätzliche Dinge einbauen zu wollen, wie z.B. ein Thermometer aus ASCII Zeichen in der Konsolenausgabe. Jedoch wäre dies nicht nötig und würde viel Zeit in Anspruch nehmen. Daher habe ich diese Ideen gelassen und mich an den Plan gehalten.
Zudem war dies das erste Mal, wo ich an einer so grossen und komplizierten Aufgabe gearbeitet habe und dies war eine Erfahrung, welche mir in Zukunft sicher helfen wird.
http://www.aue.bs.ch/dam/jcr:67a86c67-b105-48d9-b4c4-9acb189c6840/26_Grad_in_EDV_Raeumen.pdf
http://greenit.s-i.ch/de/dc/implementation
https://dl.ubnt.com/guides/unifivideo/UVC-G3_QSG.pdf
https://www.ui.com/download/unifi-video/unifi-video-camera-g3
https://www.howtoforge.com/tutorial/install-apache-with-PHP-and-mysql-lamp-on-debian-stretch/
https://www.w3schools.com/PHP/PHP_mysql_create_table.asp
https://www.w3schools.com/python/python_mysql_insert.asp
https://stackoverflow.com/questions/24272223/import-mysql-connector-python
https://pip.pypa.io/en/stable/installing/
https://stackoverflow.com/questions/1841565/valueerror-invalid-literal-for-int-with-base-10
https://wiki.python.org/moin/TcpCommunication
https://stackoverflow.com/questions/8711888/auto-refresh-code-in-html-using-meta-tags
https://css-tricks.com/snippets/css/complete-guide-grid/
| bash | Bash ist eine Shell für Linux. Die dazugehörige Scriptsprache heisst auch Bash. |
DB | Datenbank |
DHCP | Dynamic Host Configuration Protocol ist ein Protokoll, das die Zuweisung der Netzwerkkonfiguration an Clients durch einen Server ermöglicht. |
DNS | Das Domain-Name-System ist ein Verzeichnisdienst, der die URL in eine IP umwandelt. |
GIT | Versionierungssystem |
interface | Schnittstelle zwischen Benutzer und Programm. |
IP | Die IP dient als Adresse für den Computer im Netz. |
PHP | PHP Hypertext Preprocessor ist eine Scriptsprache, die zur Generierung von Webinhalten verwendet wird. Der dazugehörige Parser heisst auch PHP. |
port | Ein Port ist der Teil einer Netzwerk-Adresse, der die Zuordnung von TCP- und UDP-Verbindungen festlegt. |
Python | Python ist eine Sprache mit dem Anspruch, möglichst universell einsetzbar und leicht verständlich zu sein. |
Raspberry PI | Kleincomputer der Marke Raspberry Pi |
TCP | Transmission Control Protocol: Protokoll auf der OSI-Schicht 4. |
image | Blockkopie einer Festplatte |
Teil 3 – Anhang
Listing des Codes befindet sich in einem separaten Anhang.