Ein kleiner Exkurs zu SNMP

Wer sich schon einmal mit SNMP beschäftigt hat, der weiß, dass das Verarbeiten sowie Auswerten von SNMP-Traps eine wichtige Rolle beim Monitoring spielt. Eine fast genauso große Rolle spielt hierbei das oft mühselige „ergoogeln“ der MIBs und OIDs. Für diesen Fall kann ich folgende Webseite empfehlen. Das eigentliche Problem ist allerdings, wenn man, wie in meinem Fall, einen Check entwickeln möchte, aber sich auf Grund von COVID-19 im Homeoffice befindet. Nicht ein Jeder hat bspw. Cisco Supervisor Module bei sich zu Hause stehen, die für das Testen benötigt werden. Nun, wie kann man sich dabei helfen? Man benutzt die override Option in snmpd.conf .

Ich gehe bei den weiteren Schritten davon aus, dass SNMP bereits auf dem System richtig konfiguriert wurde

Im Folgenden werde ich zeigen wie man beispielhaft den „Redundanz-Status“ eines Cisco-Gerätes mit selbst eingetragenen Werten überprüfen kann. Es handelt sich genauer gesagt um folgende OID.

Wenn ich versuche diese OID auf meinem lokalen Gerät auszulesen, stelle ich fest das diese unbekannt ist:
# snmpwalk -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
SNMPv2-SMI::enterprises.9.9.176.1.1.2 = No Such Object available on this agent at this OID

Das heisst, man muss zunächst dem lokalen System die entsprechende MIB zur Verfügung stellen. Ich speichere die MIB also in den Pfad der konfiguriert ist und “aktiviere” diese anschließend:

Auslesen des Standardpfades:
# net-snmp-config --default-mibdirs
/root/.snmp/mibs:/usr/share/snmp/mibs

Herunterladen der benötigten MIBs:
# wget -O .snmp/mibs/CISCO-RF-MIB.mib http://www.circitor.fr/Mibs/Mib/C/CISCO-RF-MIB.mib
# wget -O .snmp/mibs/CISCO-SMI.my https://www.cisco.com/iam/PGW_MIBS/973/CISCO-SMI.my

Laden bzw. “aktivieren” der MIBs:
# cat .snmp/snmp.conf
mibs +CISCO-RF-MIB
mibs +CISCO-SMI

Nun kann man ein weiteres Mal testen ob die MIBs korrekt geladen wurden und ob das lokale System diese auch benutzt:
snmpwalk -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
CISCO-RF-MIB::cRFStatusUnitState = No Such Object available on this agent at this OID

Wie in der oberen Ausgabe zu erkennen, kann mein lokales System nun die OID verarbeiten und erkennt diese auch. Das Problem an dieser Stelle ist aber nun, dass es sich bei meinem System nicht um ein CiscoGerät mit dem Redundancy-Feature handelt, Daher auch die Meldung No Such Object available on this agent at this OID.
Das können wir beheben, indem man dem SNMP-Daemon mitteilt, welchen Status das Objekt haben soll:
# cat /etc/snmp/snmpd.conf
override 1.3.6.1.4.1.9.9.176.1.1.2 integer 14

Nach einem Neustart des Dienstes wird nun der “gewollte” Wert vom SNMP-Daemon zurück geliefert:
# systemctl restart snmpd
# snmpget -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
CISCO-RF-MIB::cRFStatusUnitState = INTEGER: active(14)

Wie man sieht kann diese manuelle Überschreibung von einzelnen OIDs sehr hilfreich bei einer Pluginentwicklung sein. Dadurch hat man die Möglichkeit verschiedene Zustände zu prüfen, ohne das man diese extra herbeiführen muss.

Bildquelle: https://pixabay.com/photos/cup-of-coffee-laptop-office-macbook-1280537/

Philipp Dorschner
Philipp Dorschner
Consultant

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kollegen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Alles neu macht der Mai: NETWAYS Trainings – Online und vor Ort

Alles neu macht der Mai. Und nicht nur der! Wir haben in den kommenden Monaten jede Menge neuen Input in spannenden NETWAYS Trainings für Dich. Online oder vor Ort: Das entscheidest Du. Wir haben aktuell beide Varianten im Portfolio. So kannst Du Dir das Wissen zu Deinem Open Source-Tool entweder ganz bequem und auf dem schnellen Weg zu Hause im Online Training aneignen. Oder Du kommst nach Nürnberg, Hamburg, München oder Berlin, um Dir gemeinsam mit anderen vor Ort neuen Input abzuholen.

Wir bringen Dir das state-of-the-art Praxiswissen bei!

MONITORING TRAININGS

Ein leistungsstarkes Tool zur Überwachung der Verfügbarkeit und Leistung aller Teile Deines Systems: Icinga zeigt Dir alle relevanten Daten an und gibt Warnmeldungen aus, um Dich auf dem Laufenden zu halten. Lerne Icinga von der Pike auf in unseren Schulungen und setze mit unseren Icinga Workshops noch eine Portion Profiwissen drauf!

Icinga 2 Fundamentals
Online | 7.–10. Juli 2020
Nürnberg | 22.–25. September 2020
Icinga 2 Advanced
Online | 21.–23. Juli 2020
Berlin | 6.–8. Oktober 2020
Icinga & Puppet Workshop
Nürnberg | 22.–23. September 2020
Icinga Director Workshop
Nürnberg | 20.–21. Oktober 2020

AUTOMATION TRAININGS

Der Trend zur Virtualisierung nahezu aller IT-Plattformen und Umgebungen erhöht den Bedarf an flexibler und vor allem schneller Verwendung der verfügbaren Ressourcen. Wir helfen Dir dabei, mit dieser Geschwindigkeit nicht nur Schritt zu halten, sondern ihr sogar einen Schritt voraus zu sein.

Ansible
Nürnberg | 21.–23. Juli 2020
Hamburg | 13.–15.Oktober 2020
Ansible AWX (Tower)
Nürnberg | 24. Juli 2020
Hamburg | 16. Oktober 2020
Icinga & Puppet Workshop
Nürnberg | 22.–23. September 2020
Fundamentals for Puppet
Online | 30. Juni – 2. Juli 2020
Nürnberg | 20.–22. Oktober 2020
Foreman
Nürnberg | 8.–9. September 2020

LOGGING & METRICS TRAININGS

Für Sammler und Sondierer: Hier erfährst Du, wie Du Log-Daten von Anwendungen, Betriebssystemen oder Netzwerkinfrastrukturen zentral sammelst, verarbeitest, verwaltest, analysierst und visualisierst. Mehrwertgenerierung garantiert!

Elastic Stack
Online | 23.–25. Juni 2020
München | 15.–17. September 2020
Graphite & Grafana
Online | 26.–27. Mai 2020

Berlin | 29.–30. September 2020
Graylog
Nürnberg | 30. Juni – 1. Juli 2020
Nürnberg | 27. – 28. Oktober 2020

ADMINISTRATION TRAININGS

Geballte Admin-Power: Hier lernst Du ein unabhängiges Linux-System zu administrieren und wiederkehrende Aufgaben zu automatisieren oder die Vorzüge unserer liebsten, flexiblen und erweiterbaren relationalen Datenbank kennen. Das und noch viel mehr. Jetzt anmelden!

Linux Basics
Nürnberg | 27.–29. Oktober 2020

PostgreSQL Fundamentals
Nürnberg | 14.–16. Juli 2020
PostgreSQL Advanced
Nürnberg | 8.–11. September 2020

DEVELOPMENT TRAININGS

Softwareentwicklung bedarf heute mehr denn je einer ganzheitlichen Betrachtung des DevOps-Lifecycles. Reine Source Code-Verwaltung wird dem nicht mehr gerecht und der gesamte Prozess von Planung bis hin zu Continuous Integration und Deployment benötigt eine technische Abbildung. GitLab ist das Tool dafür!

GitLab
Online | 14.–15. Juli 2020
Nürnberg | 15.–16. Dezember 2020

Das sagen unsere Teilnehmer*innen

“Man hat auf jeden Fall gemerkt, dass der Trainer sehr viel praktische Erfahrung mit der Software hat und weiß, wo er ansetzen muss.” – Feedback Ansible Online Training

“Eine neue Erfahrung, etwas anstrengender als in einer Präsenzschulung, aber mit viel technischem Hintergrund. Hat Spaß gemacht.” – Feedback Ansible Online Training

“Sehr gute Umsetzung einer neuen Schulungsmöglichkeit, auf jeden Fall für die Zukunft sehr interessant.” – Feedback GitLab Online Training

“Sehr gut organisiertes Online-Training, kompetenter und sympathischer Trainer. Alle Fragen wurden beantwortet. Absolut zu empfehlen!” – Feedback GitLab Online Training

Und was sagst Du? Wir freuen uns, Dich bald bei uns zu begrüßen! Virtuell oder vor Ort.

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Kubernetes Nginx Ingress Controller – So gelingt Dein einfacher Start!

This entry is part 4 of 5 in the series Kubernetes - so startest Du durch!

Kubernetes LogoMit den ersten Schritten mit Kubernetes weißt Du bereits, wie Du Anwendungen in Deinem Kubernetes Cluster startest. Nun exponieren wir Deine Anwendung online. Wie das Ganze funktioniert und wie Du mit einem Kubernetes Nginx Ingress Controller am besten selbst direkt loslegen kannst, erläutere ich Dir im Folgenden an einem Beispiel.

Um in einem Kubernetes Cluster Anwendungen von außen erreichbar zu machen, kann man einen Service vom Typ Loadbalancer verwenden. In der NETWAYS Cloud starten wir hier im Hintergrund ein Openstack Octavia LB mit öffentlicher IP und leiten den eingehenden Traffic an die Pods weiter (Bingo). Somit benötigen wir für jede Anwendung einen eigenen Loadbalancer mit öffentlicher IP. Um in einem Fall wie diesem etwas ressourcen- und somit kosteneffizienter arbeiten zu können, hat man vor Langem named-based virtual hosts und server name indication (sni) erfunden. Der altbekannte NGINX-Webserver unterstützt beides und als Kubernetes Ingress Controller kann dieser, mit nur einer öffentlichen IP-Adresse, all unsere http/s-Anwendungen schnell und einfach erreichbar machen.

Die Installation und die Aktualisierung des Ningx Ingress Controllers ist dank eines Helm Charts sehr vereinfacht. Mit K8s Ingress Objekten konfiguriert man die Zuordnung von vHosts, URI-Pfaden und TLS-Zertifikaten zu K8s Services und somit zu unseren Anwendungen. Damit die Buzzwords Dir nicht den Blick aufs Wesentliche verhindern, hier ein kleiner Überblick, wie die HTTP-Anfragen an unsere Anwendungen weitergeleitet werden:

 

Installation Kubernetes Nginx Ingress Controller

Helm Logo

Zur einfachen Installation des Kubernetes Nginx Ingress Controllers solltest Du Helm verwenden. Helm bezeichnet sich selbst als Paketmanager für Kubernetes-Anwendungen. Neben der Installation bietet Helm auch einfache Updates seiner Anwendungen. Wie auch bei kubectl brauchst Du nur die K8s-Config, um direkt loszulegen:

$ helm install my-ingress stable/nginx-ingress

 

 

Mit diesem Befehl startet Helm alle nötigen Komponenten im default Namespace und gibt diesen das Label my-ingress. Für den Nginx Ingress Controller wird ein deployment, ein replicaset und ein pod erstellt. Alle http/s-Anfragen müssen an diesen pod weitergeleitet werden, damit dieser anhand von vHosts und URI-Pfaden die Anfragen sortieren kann. Dafür wurde ein service vom Typ loadbalancer erstellt, welcher auf eine öffentliche IP lauscht und den ankommenden Traffic auf den Ports 443 und 80 an unseren pod weiterleitet. Ein ähnliches Konstrukt wird auch für das default-backend angelegt, auf welche ich hier aber nicht näher eingehe. Damit Du den Überblick nicht verlierst, kannst Du Dir alle beteiligten Komponenten mit kubectl anzeigen lassen:

$ kubectl get all -l release=my-ingress  #mit default-backend

$ kubectl get all -l release=my-ingress -l component=controller #ohne default-backend

NAME                                                             READY    STATUS      RESTARTS
pod/my-ingress-nginx-ingress-controller-5b649cbcd8-6hgz6         1/1      Running     0       

NAME                                                             READY    UP-TO-DATE  AVAILABLE
deployment.apps/my-ingress-nginx-ingress-controller              1/1      1           1        

NAME                                                             DESIRED  CURRENT     READY
replicaset.apps/my-ingress-nginx-ingress-controller-5b649cbcd8   1        1           1    

NAME                                              TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)
service/my-ingress-nginx-ingress-controller       LoadBalancer   10.254.252.54    185.233.188.56   80:32110/TCP,443:31428/TCP

 

Beispielanwendungen: Apache und Nginx

Als nächstes starten wir zwei einfache Beispielanwendungen. Im Beispiel verwende ich Apache und Nginx. Ziel ist es, beide Anwendungen unter eigenen name-based virtual hosts verfügbar zu machen: nginx.nws.netways.de und apache.nws.netways.de. Damit die beiden Deployments innerhalb des K8s Clusters erreichbar sind, müssen wir diese noch jeweils mit einem Service verbinden.

K8s Deployments

Nginx Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Apache Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  labels:
    app: apache
spec:
  replicas: 3
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
      - name: apache
        image: httpd:2.4
        ports:
        - containerPort: 80

K8s Service

Nginx Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: nginx
Apache Service

apiVersion: v1
kind: Service
metadata:
  name: apache-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: apache

 

Virtual Hosts ohne TLS

Um nun die Anfragen vom Nginx Controller zu unseren Anwendungen weiterzureichen, müssen wir ein passendes Kubernetes Ingress Objekt ausrollen. Im spec Bereich des Ingress Objekts können wir unterschiedliche Pfade und virtuell Hosts definieren. Im Beispiel sehen wir vHosts für nginx.nws.netways.de und apache.nws.netways.de. Für jeden der beiden vHosts ist im Bereich backend natürlich der entsprechende service eingetragen.

Die öffentliche IP findet man im service des Nginx Ingress Controllers und kubectl describe zeigt alle wichtigen Details zum Service (siehe unten). Zum Testen manipulierst Du am besten seine /etc/hosts Datei und trägst dort die IP von LoadBalancer Ingress ein.

K8s Ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: apache.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: apache-svc
            servicePort: 80
  - host: nginx.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: nginx-svc
            servicePort: 80

$ kubectl describe service/my-ingress-nginx-ingress-controller

$ kubectl get service/my-ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[].ip}’

 

Virtual Hosts mit TLS

Natürlich bietet man selten Anwendungen ohne Verschlüsselung öffentlich erreichbar an. Speziell für TLS-Zertifikate hat Kubernetes einen eigenen Typ tls innerhalb des secret Objekts. Alles was man benötigt ist ein TLS-Zertifikat und den dazugehörigen Schlüssel. Mit kubectl kannst Du das Pärchen in Kubernetes speichern:

$ kubectl create secret tls my-secret –key cert.key –cert cert.crt

Das angelegte secret kann dann durch den angegebenen Namen my-secret in spec des Ingress Objekts referenziert werden. Dazu gibst Du im Array hosts innerhalb von tls unser virtual host und das dazugehörige TLS-Zertifikat an. Ein automatischer Redirect von http auf https ist von Anfang an aktiviert.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  tls:
    - hosts:
      - apache.nws.netways.de
      - nginx.nws.netways.de
      secretName: my-secret
  rules:
  - host: apache.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: apache-svc
            servicePort: 80
  - host: nginx.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: nginx-svc
            servicePort: 80

Fazit

Mit dem Nginx Ingress Controller ist es eine Leichtigkeit, Deine webbasierten Anwendungen öffentlich erreichbar zu machen. Die angebotenen Features und Konfigurationsmöglichkeiten sollten die Anforderungen aller Anwendungen abdecken und sind im offiziellen User Guide zu finden. Neben der eigenen Anwendung benötigst Du nur ein Helm Chart und ein K8s Ingress-Objekt. Kubernetes schafft es auch hier, mit nur wenigen abstrakten Objekten wie deployment und ingress viele komplexe Ebenen und Technologien zu verstecken. Mit einer NETWAYS Managed Kubernetes Lösung kannst Du die Vorteile dieser Abstraktion voll ausnutzen und Dich auf die eigene Anwendung konzentrieren. Na also: Leg los!

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Evolution of a Microservice-Infrastructure by Jan Martens | OSDC 2019

This entry is part 1 of 6 in the series OSDC 2019 | Recap

 

At the Open Source Data Center Conference (OSDC) 2019 in Berlin, Jan Martens invited to audience to travel with him in his talk „Evolution of a Microservice-Infrastructure”. You have missed him speaking? We got something for you: See the video of Jan‘s presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place from June 16 to 18, 2020. Join us, live online! Save your ticket now at: stackconf.eu/ticket/


 

Evolution of a Microservice-Infrastructure

Jan Martens signed up with a talk titled “Evolution of a Microservice Infrastructure” and why should I summarize his talk if he had done that himself perfectly: “This talk is about our journey from Ngnix & Docker Swarm to Traefik & Nomad.”

But before we start getting more in depth with this talk, there is one more thing to know about it. This is more or less a sequel to “From Monolith to Microservices” by Paul Puschmann a colleague of Jan Martens, but it’s not absolutely necessary to watch them in order or both.

 

So there will be a bunch of questions answered by Jan during the talk, regarding their environment, like: “How do we do deployments? How do we do request routing? What problems did we encounter, during our infrastructural growth and how did we address them?”

After giving some quick insight in the scale he has to deal with, that being 345.000 employees and 15.000 shops, he goes on with the history of their infrastructure.

Jan works at REWE Digital, which is responsible for the infrastructure around services, like delivery of groceries. They started off with the takeover of an existing monolithic infrastructure, not very attractive huh? They confronted themselves with the question: “How can we scale this delivery service?” and the solution they came up with was a micro service environment. Important to point out here, would be the use of Docker/Swarm for the deployment of micro services.

Let’s skip ahead a bit and take a look at the state of 2018 REWE Digital. Well there operating custom Docker-Environment consists of: Docker, Consul, Elastic Stack, ngnix, dnsmasq and debian

Jan goes into explaining his infrastructure more and more and how the different applications work with each other, but let’s just say: Everything was fine and peaceful until the size of the environment grew to a certain point. And at that point problems with nginx were starting to surface, like requests which never reached their destination or keepalive connections, which dropped after a short time. The reason? Consul-template would reload all ngnix instances at the same time. The solution? Well they looked for a different reverse proxy, which is able to reload configuration dynamically and best case that new reverse proxy is even able to be configured dynamically.

The three being deemed fitting for that job were envoy, Fabio and traefik, but I have already spoiled their decision, its treafik. The points Jan mentioned, which had them decide on traefik were that it is dynamically configurable and is able to reload configuration live. That’s obviously not all, lots of metrics, a web ui, which was deemed nice by Jan and a single go binary, might have made the difference.

Jan drops a few words on how migration is done and then invests some time in talking about the benefits of traefik, well the most important benefit for us to know is, that the issues that existed with ngnix are gone now.

Well now that the environment was changed, there were also changes coming for swarm, acting on its own. The problems Jan addresses are a poor container spread, no self-healing, and more. You should be able to see where this is going. Well the candidates besides Docker Swarm are Rancher, Kubernetes and Nomad. Well, this one was spoiled by me as well.

The reasons to use nomad in this infrastructure might be pretty obvious, but I will list them anyway. Firstly, seamless consul integration, well both are by HashiCorp, who would have guessed. Nomad is able to selfheal and comes in a single go binary, just like traefik. Jan also claims it has a nice web UI, we have to take his word on that one.

Jan goes into the benefits of using Nomad, just like he went into the benefits of ngnix and shows how their work processes have changed with the change of their environment.

This post doesn’t give enough credit to how much information Jan has shared during his talk. Maybe roughly twenty percent of his talk are covered here. You should definitely check it out the full video to catch all the deeper more insightful topics about the infrastructure and how the applications work with each other.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.
NEU im Shop: AKCP LoRaWan Geräte für wireless Sensoren

NEU im Shop: AKCP LoRaWan Geräte für wireless Sensoren

Unser Shop ist schon lange eine Bezugsquelle für AKCP Produkte – viele unserer Kunden betreiben Geräte aus den Reihen sensorProbe, sensorProbe+ und securityProbe. Nun wollen wir Euch eine weitere AKCP-Serie anbieten, nämlich die LoRaWAN Gateways, mit denen die Nutzung von Funk-Sensoren umgesetzt wird.

L-DCIM Desktop-Version

Was ist LoRa™ Funktechnologie?

LoRaWAN ist die Abkürzung für Long Range Wide Area Network. Der Netzaufbau ist hierbei sternförmig und Endgeräte senden asymmetrisch an das entsprechende Gateway. Trotz höchster Energieeffizienz – Endgeräte können mit klug gewählten Standbyzeiten mehrere Jahre ohne Batteriewechsel auskommen – können Distanzen zwischen 2 und 40 km erzielt werden, letztere vor allem im ländlichen Bereich. Flächendeckende LoRaWAN-Netze wurden bereits in den Niederlanden, der Schweiz und Südkorea aufgebaut. Berlin hingegen ist laut wikipedia.org die Großstadt mit den weltweit meisten LoRaWAN-Installationen, aber auch Zürich, Bern und Amsterdam gehen hier stark in die Konkurrenz.

 

AKCP LoRa L-DCIM: Das Gateway für AKCP Funk-Sensoren

Das AKCP LoRa L-DCIM ist das Gateway, mit dem die Funk-Sensoren kommunizieren, um Werte zu übertragen. Diese Werte laufen in den integrierten AKCPro Server, die hauseigene Überwachungsplattform von AKCP. Mithilfe von Adaptern kann das L-DCIM auch herkömmliche, verkabelte Sensoren von AKCP nutzen oder aber auch mit Drittanbieter-Sensoren per SNMP oder Modbus kommunizieren. Weiterhin können auch binäre Detektoren wie Rauchmelder über Funkadapter mit potentialfreien Kontakten angeschlossen werden.

L-DCIM Rack-Version

Das AKCP LoRa L-DCIM ist bei uns in folgenden Varianten erhältlich:

  • als Desktopversion, die sich auch zur Wand- oder Hutschienenmontage eignet
  • als Desktopversion mit Material zur Hutschienenmontage
  • als Rack-Version mit 1HE für den Einbau in Standard-19″-Schränke
  • beide Geräte können mit 3G- oder 4G-Modem ausgestattet werden. Bitte kontaktiert uns in diesem Fall.

 

Was kann mit dem AKCP LoRa L-DCIM überwacht werden?

Für das AKCP LoRA L-DCIM gibt es Funk-Sensoren für folgende Anwendungsfälle:

  • Überwachung von Temperatur und Luftfeuchtigkeit
    • Hier wird ein Kombisensor angeboten, diesen gibt es optional auch mit einem zusätzlichen Kontakt, der das Öffnen und Schließen von Türen erkennen kann. Auch gibt es hier die Möglichkeit, den Kombisensor mit einem Verlegeradius von 1,5m zu beziehen.
  • Thermal Map und Cabinet Thermal Map
    • Diese bilden eine Sensorkette, die mit 3 bzw. 6 Kombisensoren zur Messung von Temperatur und Luftfeuchtigkeit ausgestattet ist.
  • Potentialfreie Eingänge
    • Dieser Adapter bietet 5 potentialfreie Eingänge, so dass entsprechende Geräte mit dem wireless Gateway gekoppelt werden können.
  • Sensor-Adapter
    • Dieser eignet sich zum Koppeln eines AKCP Detektors wir Rauchmeldern, Wasserleackagesensoren, Türkontakten, Wechselstromsensoren und Bewegungsmeldern.
  • Tank-Füllstand
    • Hier bietet AKCP einen Sensor zur Überwachung von Tank-Füllständen für Tanktiefen von 2 / 5 / 10 / 15 / 20 Metern.
  • Wassereinbruch und -leckage
    • Erkennung von Wassereinbrüchen und -leckage, auch erhältlich mit einem Verlegeradius von 1,5m für den Sensor.
  • Konvertierung von Analog auf Digital
    • Hiermit können analoge Sensor-Signale digital aufbereitet an das L-DCIM Gateway weitergegeben werden (zum Anschluss von bis zu 2 Sensoren für die Bereiche 4 – 20 mA oder 0 – 10 VDC).
  • Cabinet Analysis
    • Für den Rundumüberblick über Serverschränke: Es können pro Cabinet Analysis Sensor maximal 2 Thermal Map Sensoren und 2 Luftstromsensoren angeschlossen sowie 2 potentialfreie Eingänge für Türöffnungssensoren genutzt werden.
  • Modbus-Adapter
    • Insbesondere im IoT-Bereich kann dieser Adapter eingesetzt werden.

AKCPro Server

Durch die integrierte AKCPro Server Software, die selbstverständlich auch unabhängig vom L-DCIM Gateway genutzt werden kann, bleibt der Nutzer nicht beschränkt auf den Einsatz der obigen Sensoren und Anschlussmöglichkeiten. Es können folgende Sensoren und und Geräte per Lizenz integriert werden:

  • Virtuelle Sensoren
  • Virtuelle Modbus TCP/IP Sensoren
  • ONVIF IP Kamera
  • AKCP Geräte

Des Weiteren bietet AKCPro Server auch vielfältige Über- und Ansichten, wie z.B. schematische Darstellungen von Racks und Räumen und der Verteilung der entsprechenden Messpunkte. Besonders nützlich ist die Realtime-Aktualisierung von Daten und der Anzeigemöglichkeit auf Tablets, was z.B. für eine Begehung der entsprechenden Räumlichkeiten einen starken Mehrwert gibt. Eine Übersicht und Online-Demo bietet AKCP auf der Website zu AKCPro Server.

Rack-Übersicht in AKCPro Server

 

Selbstverständlich sind alle oben genannten Produkte und Lizenzen bei uns erhältlich. Solltet Ihr Fragen haben, dann sind wir jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team. Bleibt gesund – wir freuen uns auf Euch!

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...