Select Page

NETWAYS Blog

Netzwerkprobleme im Homeoffice erkennen

by | Jan 13, 2021 |

In den letzten Monaten gab es zwischenzeitlich wegen allgemein erhöhtem Datenvolumen im Internet ja immer wieder ein mal Probleme mit diversen Providern bezüglich langsamer oder nur sporadisch oder tagelang nicht richtig funktionierender Internet Verbindungen.

Gerade die zunehmende Verbreitung von Videokonferenzen in Unternehmen durch Homeoffice und parallel ein immenser Zuwachs der Kunden von Streaming Plattformen hat dazu sicher massgeblich beigetragen.

Nun ist es auf den ersten Blick auch nicht immer so einfach zu erkennen, welche Ursachen z.B. Probleme bei einer Videokonferenz haben können.

Wenn alle anderen Dienste wie E-Mail, normale Webseiten, oder auch das Arbeiten auf der Kommandozeile trotzdem irgendwie funktionieren, denkt man nicht immer gleich daran, dass es trotzdem ein Problem im lokalen Netzwerk oder auf der Strecke zum entsprechenden Server geben könnte.

Zunächst ist es natürlich sinnvoll erst ein mal zu schauen, ob man nicht grundsätzliche Probleme im lokalen Netzwerk hat, z.B. bei Mehrfamilien Häusern oder Wohnblöcken ein überlastetes 2,4 GHz WLAN.
Dabei ist es sehr hilfreich, wenn man entsprechende Tools für sein Betriebssystem nutzt, die die Auslastung und die Verbindungsqualität der aktuellen WLAN Verbindung anzeigen können.
(Beispiel siehe unten)

Falls dort alles o.k. ist, es aber trotzdem noch Probleme gibt, helfen altbekannte Tools, die es auch für alle gängigen Betriebssysteme gibt, bei der Eingrenzung weiter.

Einige im Beispiel mit der IP des Google DNS als Ziel:
(Syntax kann von System zu System unterschiedlich sein)

1. Ein simpler Ping
(die Antwortzeiten sollten nicht zu hoch sein, das Beispiel unten ist in dem Fall i.O.)

2. Traceroute
(man sieht die Antwortzeiten für alle Hops auf dem Weg zum Ziel)

3. MTR (mytraceroute)

MTR finde ich persönlich am besten, da es eine Kombination von Ping und Traceroute ist und man für jeden einzelnen Hop die Paket Verluste sieht und dadurch ziemlich gut einschätzen kann, ob die Probleme z.B. eher im lokalen Netz, auf dem Weg zum Ziel, oder direkt nur am Ziel liegen (oder an allem gleichzeitig).

Leider blocken immer mehr Service Anbieter und Provider, oder auch Cloud Software Lösungen ICMP Pakete, so dass diese Tools nicht immer funktionieren, bzw. dann an bestimmten Stellen nur drei ??? eingeblendet werden.

Am Beispiel oben zum Google DNS war das zum Glück nicht der Fall.

Stefan Gundel
Stefan Gundel
Senior Systems Engineer
Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.
Read more from Stefan and meet the Team

Icinga2 GitLab Health Check

by | Sep 5, 2018 | , , , , ,

GitLab
Neulich hatten wir bei einigen GitLab Updates auf die neueste Version das Problem, dass die Dienste nach dem Update zwar korrekt alle wieder gestartet wurden und daher unser alter Monitoring Check “Service: gitlab” den Status “Gitlab OK: All services are running!” zurückgeliefert hat, auch der Check “Service: http git.netways.de” “HTTP OK: HTTP/1.1 200 OK” geliefert hat, und daher hat ohne manuelle Prüfung niemand vermutet, dass im Hintergrund doch etwas schief gelaufen war (z.B. die Datenbank Migration während einem Update, oder ein vergessenes skip-XXX File im /etc/gitlab Verzeichnis).
Auch wenn man das Update direkt auf der command line ausgeführt hat, konnte man in der abschliessenden Meldung nicht sehen, ob noch alles o.k. ist.
Festgestellt hat man das dann erst, wenn man sich in der GitLab Admin Area unter “Health Check” den Status angesehen hat.
Unten ein Beispiel wie es aussieht, wenn alles i.O. ist (Zur Info: Die Beispiel URL und Token gibt es nicht):
GitLab Status
D.h. ein neuer Check musste her, und den gibt es auch direkt bei GitLab zum Downloaden unter:
https://gitlab.com/6uellerBpanda/check_gitlab/blob/master/check_gitlab.rb
Der alte Check lief dabei direkt auf den einzelnen GitLab Hosts. Das war mit dem neuen Check allerdings ein Problem, weil er als Voraussetzung Ruby >2.3 hat, und wir z.B. noch einige Hosts unter Ubuntu Trusty betreiben.
Deshalb wird der neue Check direkt auf dem Monitoring Server (auch Ubuntu Trusty) ausgeführt, der zu diesem Zweck zusätzlich per rvm mit einem z.Zt. neuen Ruby 2.5.1 ausgestattet wurde, wobei im Ruby Skript das Shebang leider hardcoded eingetragen werden musste, weil es (zumindest unter Trusty) nicht anders funktioniert hatte (ohne grösseren Aufwand und vielen Änderungen an anderen Systemdateien):

#!/usr/local/rvm/rubies/ruby-2.5.1/bin/ruby

Nachdem die Token zum Zugriff im Bild oben seit einigen GitLab Versionen deprecated sind zugunsten einer IP Whitelist, hat das den Deploy des Checks zusätzlich erleichtert.
Der Aufruf des Checks sieht dann z.B. so aus:

root@icinga2-server:~# check_gitlab.rb -m health -s https://gitlab.netways.de -k
OK - Gitlab probes are in healthy state

Damit das dann auch funktioniert, muss auf der entfernten GitLab Instanz noch die IP Whitelist unter /etc/gitlab/gitlab.rb eingetragen werden:

gitlab_rails['monitoring_whitelist'] = ['127.0.0.1/8','10.XX.XX.XX/24']

Am besten checkt man natürlich nur über ein internes Netz, wie oben im Beispiel angegeben.
Das ganze kann man auch über ein GitLab Puppet Modul realisieren, indem man die Whitelist über Hiera oder Foreman verteilt:
Beispiel Hierarchie im Foreman:

gitlab:
    gitlab_rails:
      monitoring_whitelist:
      - 127.0.0.1/8
      - 10.XX.XX.XX/24
Stefan Gundel
Stefan Gundel
Senior Systems Engineer
Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.
Read more from Stefan and meet the Team

Mission Loadbalancer Upgrade

by | May 10, 2017 | , , ,

Mission Loadbalancer Upgrade
Heute Nacht hatte das Managed Services Team die spannende Aufgabe unseren Loadbalancer Cluster auf neue Systeme umzuziehen.
Der alte Cluster lief zwar seit Jahren problemlos, allerdings erhoffen wir uns von dem neuen Setup eine gesteigerte Netzwerk Performance und durch neuere Cluster Management Pakete insgesamt auch eine bessere Wartbarkeit, wie z.B. bei unserem halbjährlichen Failovertest.
Sehr wichtig ist dabei natürlich, dass auch in der Nacht die Downtime der Services so gering wie möglich ausfällt.
Da bei uns die komplette Loadbalancer Cluster Konfiguration über Puppet provisioniert wird, war es daher auch kein Problem die Neuinstallation der Cluster Knoten sehr zügig durchzuführen.
Die tatsächliche Downtime der Services betrug daher nach der Neuprovisionierung wie erwartet auch nur wenige Sekunden und die ersten Performance Tests waren sehr vielversprechend.
Ein Beispiel für einen Service Eintrag im Puppetlabs Hiera sieht in etwa so aus (wir verwenden dafür den ldirectord aus dem Linux Virtual Server Projekt):

ldirector::member:
  "web-host1.netways.de_%{::hostname}":
    ip: "%{ipaddress_bond0_XX}"
    weight: 1
    service_name: 'web-host1.netways.de'
    ssl: true
    password: 'XXXXXXXXXX'
    ensure: 'present'

Dieser Eintrag in einer Hostname FQDN YAML Datei genügt somit, um den entsprechenden Host in den Loadbalancer Pool eines Services mit den entsprechenden Parametern (Gewichtung u.s.w.) aufzunehmen.
Im zugrundeliegenden ldirectord Puppetmodul werden zudem ausgiebig ‘Exported resources’ in Verbindung mit der PuppetDB verwendet, um am Ende die komplette Loadbalancer Konfiguration Live zu nehmen.
Wenn Sie sich für mehr Informationen zu einem redundanten, jederzeit skalierbaren Loadbalancer Setup und mehr interessieren, schauen Sie sich doch einfach ein mal unser Hosting & Services Angebot an.

Stefan Gundel
Stefan Gundel
Senior Systems Engineer
Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.
Read more from Stefan and meet the Team

Rückblick Debian Wheezy Distribution Upgrade

by | Sep 10, 2013 | ,

wheezy
Seit Anfang Mai 2013 gibt es ja nun die neue stabile Debian Distribution Wheezy.
Natürlich freut man sich auch immer darauf, dass eine neue Version kommt, weil das System im Lauf der Jahre generell immer besser geworden ist.
Aber spätestens ein paar Wochen danach wird auch jedem klar, es hilft nichts, man “muss” auch upgraden um ein Jahr nach dem Release weiterhin Security Updates zu erhalten, weil ab dann die Oldstable – in dem Fall Debian Squeeze – nicht mehr unterstützt wird.
Das Upgrade sollte man auch nicht zu lange aufschieben, weil man sich sonst Anfang nächsten Jahres nur unnötig selbst unter Druck setzt.
Ab einer gewissen Anzahl Server ist natürlich der Aufwand alle komplett neu zu installieren, und das im laufenden Serverbetrieb, trotz aller Installations Automatisierung zuviel, zumal es auch immer wieder genug Spezialfälle gibt.
Wenn man sich sicher ist, dass man die alten Konfigurationsfiles der Pakete behalten möchte, und um die Downtime der einzelnen Server möglichst kurz zu halten und nicht ständig unnötige Fragen beantworten zu müssen, kann man dann auch ein “unattended-upgrade” machen.
Falls man mehrere Server vom gleichen Typ hat empfiehlt es sich allerdings zunächst mindestens ein “normales” interaktives Upgrade zu machen.
Deshalb an dieser Stelle ein Beispiel, wie man so ein unattended-upgrade durchführen kann:
1. Zuerst alle vorhandenen Updates für Debian Squeeze einspielen, damit das System vor dem Distributionsupgrade auf einem aktuellen Stand ist.
2. Die Debian Wheezy Quellen in die /etc/apt/sources.list eintragen. Falls man noch weitere Listen im Verzeichnis /etc/apt/sources.list.d hat, müssen diese noch zusätzlich angepasst werden. Man kann die Änderung auch automatisieren mit:


sed -i 's/squeeze/wheezy/g' /etc/apt/sources.list

und/oder


sed -i 's/squeeze/wheezy/g' /etc/apt/sources.list.d/*.list

3. Das eigentliche Distributions Upgrade kann man dann starten mit:


export DEBIAN_FRONTEND=noninteractive
yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" upgrade
yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

Das ganze in upgrade und danach erst dist-upgrade aufzuteilen hat den Vorteil, dass man beim “upgrade” noch sieht, ob es gravierende Probleme mit Paketabhängigkeiten gibt, und diese noch fixen kann vor dem abschliessenden endgültigen Distributions Upgrade.
Bisher haben alle Upgrades bei uns gut geklappt. Falls aber die Applikation z.B. wegen dem PHP Versionsupgrade von Squeeze 5.3.3 auf Wheezy 5.4.4 nicht mehr funktioniert, kann man sich immer noch durch ein Downgrade der PHP Version retten, um anschliessend die Fehler vor einem weiteren Upgrade in Ruhe beheben zu können.
Eine entsprechende Anleitung findet man z.B. hier.

Stefan Gundel
Stefan Gundel
Senior Systems Engineer
Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.
Read more from Stefan and meet the Team

SCP und Rsync Boost Parameter

by | Apr 2, 2013 | , ,

speedy
Wer kennt es nicht: Es muss schnell etwas per scp oder rsync aus dem Backup oder einem LVM Snapshot auf einen anderen Server im internen Netz kopiert werden, weil gerade zur ungünstigsten Zeit z.B. eine Datenbank nicht korrigierbar ausgefallen ist.
Da die dabei anfallenden Datenvolumen heuzutage wohl eher beständig mehr als weniger werden, ist jedes bisschen Übertragungs-Speed, das man aus der Leitung kitzeln kann, sehr wichtig.
Was gerne übersehen wird: SSH bietet da zumindest einen Parameter an, mit dem man die Geschwindigkeit ordentlich nach oben schrauben kann durch die Wahl eines anderen Cypher Algorithmus, auch über rsync.
Das ganze bringt satte rund 30% mehr an Daten über die Leitung und spart dadurch natürlich auch entsprechend viel Zeit beim Kopieren.
Als Beispiel ein rsync Befehl, den ich in so einem Fall immer verwende:


rsync -aPHxz --delete -e 'ssh -c arcfour' root@:/foo/bar/* /foo/bar/

Wem das immer noch nicht reicht, der kann zusätzlich auch noch einen anderen ‘message authentication code’ angeben über den Parameter: ‘-m hmac-md5-96″

Stefan Gundel
Stefan Gundel
Senior Systems Engineer
Stefan ist ein Urgestein bei NETWAYS und arbeitet im Managed Services Team. Der internationale Durchbruch gelang Stefan als Fotomodel für den K+K Warenkorb. Nachdem er einige Jahre exklusiv für unseren Kunden StayFriends gearbeitet hat, darf er nun endlich auch wieder in anderen Projekten mitarbeiten.
Read more from Stefan and meet the Team

Trainings

Web Services

Events