pixel
Seite wählen

NETWAYS Blog

Riesige Datenmengen transportieren – ein Ding der Unmöglichkeit?

Zugegeben, vor dem konkreten Problem, eine fast 2 TB große Datei von einem System zu transportieren, auf das man nur über mehrere Hops Zugriff hat, steht man nicht jeden Tag. Aber wenn doch, dann bietet eine ganze Sammlung an Tools eine gemeinsame Lösung an.

Mit “mehrere Hops” ist gemeint, dass es nicht möglich ist, mit den üblichen Bordmitteln wie scp oder rsync Daten zu kopieren. Ein Beispiel könnte ein Citrix-Zugang mit PuTTy sein, der zwar Shell-Zugriff erlaubt, aber kein Kopieren. Im konkreten Fall “durften” die Daten natürlich kopiert werden, es war schlicht nur technisch nicht “möglich”. Der Host, auf dem die Daten lagen, hatte Zugriff auf Websites im Internet durfte aber keine anderen Protokolle “nach draussen” benutzen.

Zerhacken und Zerteilen um riesige Datenmengen transportieren zu können

Zwar ist es heutzutage eigentlich problemlos möglich, auch riesige Datenmengen von A nach B zu kopieren. Da wir hier aber von einem nicht unerheblichen Zeitraum sprechen, den die Kopie braucht und ein kurzer Abbruch wertvolle Zeit gekostet hätte, war der Ansatz erstmal folgender:

  • Die Daten so klein komprimieren wie es sinnvoll ist (hier mit bzip2)
  • Die Daten klein hacken (mit split)
  • Die einzelnen Stücke dann hochladen
  • Beim Empfänger zusammensetzen und entpacken

Das lässt sich ganz gut per Shell realisieren.

nohup time tar cjvf testdb.tar.bz ../backups/full/ &
split -b5000000000 testdb.tar.bz

Die Datenbank bestand dabei aus einigen sehr kleinen Dateien und einigen, die etliche GB und teilweise sogar über 1 TB groß waren. Es zahlte sich also nicht aus, die Dateien einzeln zu kopieren.

  • nohup lässt den Befehl weiterlaufen, auch wenn die Verbindung abbricht und schreibt den Output nach nohup.out
  • time gibt ab, wie lang das Komprimieren braucht. Weil ich einfach ein neugieriger Mensch bin
  • tar mit -j komprimiert die Dateien mit bzip2 statt gzip was in vielen Fällen zwar länger dauert aber deutlich kleinere Dateien hervorbringt
  • split hackt eiskalt die Dateien in kleine Teile. In diesem Fall jeweils 5 GB groß. Dabei hat der Befehl noch einige Optionen um einem das Leben leichter zu machen. Es zahlt sich aus, da etwas mehr nachzustöbern als ich das damals gemacht hab

Somit hat man dann eine große Anzahl “ausreichend kleiner” Dateien. Mit tail -f nohup.out kann man beobachten, was sich gerade tut. Das geht auch, wenn disconnected wurde. Alternativ kann man auch screen oder tmux nehmen. Da diese Tools aber Probleme mit manchen remote Verbindungen machen und nicht immer zur Verfügung stehen, bleib’ ich persönlich lieber bei nohup.

Übrigens sollte man nicht unbedingt an die maximale Obergrenze des Uploads gehen. Beim ersten Versuch hab’ ich das getan und die Daten wurden teilweise von NextCloud verworfen. Warum, hab’ ich nicht mehr versucht herauszufinden, weil es bei der Methode eigentlich egal ist, ob man wenige große oder sehr viele sehr kleine Dateien nimmt. 5 GB haben aber gut funktioniert.

Der Transporter

Zugegeben, ich hatte den Vorteil, eine NextCloud Instanz nutzen zu können, die noch dazu genug Platz bot. Der Trick funktioniert bis hier her aber natürlich auch mit jedem anderen Übertragungsweg. Auch wenn man die Dateien ggf. kleiner hacken muss.

Für den weiteren Schritt baut man sich ein kleines Script.

#!/bin/bash
for i in $(ls x*)
do
  curl -T $i -u transportuser:$MYPASSWORD https://nextcloud.example.com/remote.php/webdav/testdb/$i
done

Auch dazu ein paar Erklärungen.

  • ls x* gibt alle Dateien aus, die split erstellt hat. Ohne weitere Optionen startet der Name aller zerlegten Dateien mit x
  • In der NextCloud wird im Home von User transportuser der Ordner testdb angelegt
  • curl nutzt WebDAV um die einzelnen Schnippsel hochzuladen
  • Der User transportuser wurde dafür extra angelegt und der Ordner testdb den eigentlichen Empfängern freigegeben. Das erleichtert das Management und vor allem das Passworthandling
  • Das Passwort kommt im nächsten Schritt

Tatsächlich riesige Datenmengen transportieren

Das Script hat noch eine Einschränkung. Da es auf einem “fremden” System liegt, möchte man darin natürlich nicht das Passwort eines NextCloud Users hinterlegen. Wir haben einige Möglichkeiten ausprobiert und dabei auch bedacht, dass man es evtl. aus der Shell-History oder der Prozessliste auslesen könnte. Das beste, das wir bisher gefunden haben ist eine Umgebungsvariable, die nicht in der History landet.

 export MYPASSWORD=mysupersecret
nohup time ./thetransporter.sh

Und wieder Erläuterungen.

  • Die erste Zeile ist um eine Stelle eingerückt. Das verhindert (üblicherweise!) dass sie in die Shell History aufgenommen wird. Bevor man sich darauf verlässt, sollte man das unbedingt testen!
  • Die zweite Zeile ruft schlicht das Script von oben auf, wo die Umgebungsvariable genutzt wird

Andere Lösungen, wie eine interaktive Angabe beissen sich sich mit nohup.

Ganz unabhängig davon, ob das Passwort hier sicher genug war oder nicht, schadet ein Wechsel des Passworts direkt im Anschluss sicher nicht. Hat man sich einen eigenen User für den Transport angelegt, kann man ihn auch einfach wieder entfernen.

Die Auflösung

Hat man die Daten so in die NextCloud gepushed, kann man sie einfach mit dem NextCloud Client auf ein eigenes Gerät synchronisieren lassen. Tip: Man kann im Client angeben, welche Ordner synchronisiert werden sollen und welche nicht, falls man mehrere Geräte angeschlossen hat.

Um die Daten wieder zusammenzubauen reicht ein schlichtes cat.

cat x* > testdb.tar.bz2
tar xvf testdb.tar.bz2

Und was? Ja, Erläuterungen.

  • split benennt die Dateien so, dass die alphabetische Sortierung von cat sie wieder richtig zusammenbaut
  • tar ist inzwischen so schlau, dass man die Kompressionsmethode nicht mehr angeben muss. Schadet zwar nicht, sieht aber irgendwie cooler aus so

Besonders charmant finde ich daran, dass es den Tools völlig wurscht ist, was in den Dateien drin ist. Ob das Klartext, binaries oder was auch immer sind. Sie tun ja nichts mit dem Inhalt, zerhacken sie nur und stückeln sie zusammen.

Wer uns gern an solchen Lösungen kiefeln und werkeln sehen möchte, schliesst am besten gleich einen Support-Vertrag bei uns ab.

Thomas Widhalm
Thomas Widhalm
Lead Senior Systems Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Kubernetes: Mehrere Cluster mit kubectl

Während man mit Kubernetes arbeitet oder entwickelt, wird man in den seltensten Fällen alles auf einem Cluster machen. Ob man ein lokales Minikube verwendet, oder Zugriff auf verschiedene Cluster für Produktion und Testing hat, muss man die Daten ja verwalten, und auswählen in welchem Kontext man gerade arbeitet.

Struktur der Konfiguration

Die Konfiguration für kubectl und andere Kubernetes Clients findet man normalerweise in $HOME/.kube/config. Ich möchte hier ein paar Beispiele zeigen, wie man hier neue Cluster hinzufügen kann. Der Inhalt sieht im einfachsten Fall so aus. Hier sind die Daten bzw. Secrets abgekürzt.

apiVersion: v1
kind: Config
current-context: my-cluster
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://my-cluster:6443
  name: my-cluster
contexts:
- context:
    cluster: my-cluster
    user: admin
  name: my-cluster
users:
- name: admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

Hier sind nun folgende Bereiche wichtig:

  • clusters definiert die bekannten Cluster mit API Endpunkt (URL) und dem passenden CA Zertifikat
  • users definiert Zugangsdaten und Authentifizierungsmechanismen, meistens ein Client Zertifikat, Auth-Tokens oder SSO Daten
  • contexts verbindet Cluster und Authentifizierung, und erlaubt auch das setzen des Namespaces
  • current-context zeigt an welcher Context gerade benutzt wird

Die aktuell verwendete Konfiguration kann man sich bequem anzeigen lassen, und dabei werden dann auch die Detaildaten zensiert – wie oben.

kubectl config view

Andere Konfigurations Dateien

Viele Kubernetes Anbieter stellen direkt die fertige Konfigurationsdatei zur Verfügung, die speichert man entweder direkt unter $HOME/.kube/config oder spezifiziert diese explizit.

kubectl --kubeconfig /tmp/my-config config view

export KUBECONFIG=/tmp/my-config
kubectl config view

Dabei wird nun diese Datei alleine geladen und ist direkt benutzbar. KUBECONFIG gilt dann für alle weiteren Befehle in der Shell auch.

Verbinden der Konfiguration

Um mehrere Dateien zusammenzuführen kann man nun auch mehrere Dateien laden, und so zusammenführen.

cp ~/.kube/config ~/.kube/config.bak
KUBECONFIG=~/.kube/config.bak:/tmp/my-config kubectl config view --raw >~/.kube/config

Bitte unbedingt die Datei vor dem speichern prüfen, doppelte Namen können zu Fehlern führen und der Context wird dann neu gesetzt.

Für kleinere Korrekturen kann man dann auch problemlos die Datei nachträglich von Hand editieren.

Tools und Shell Erweiterungen

Ich nutze gerne die Tools kubectx und kubens um schnell zwischen verschiedenen Kontexten umschalten zu können, bzw. zu sehen mit was ich gerade arbeite. Dazu gibt es auch die praktische Auto-Vervollständigung für die Shell.

Welchen Kontext bzw. Namespace ich gerade nutze, zeigt mir außerdem mein Bash Prompt auch an. Hier am Beispiel von powerline-shell mit meinen Modifikationen.

Es existieren auch einfachere Möglichkeiten, wie die kube-ps1 von jonmosco auf GitHub.

Mehr Infos

Wir bereiten gerade unsere neue Kubernetes Quick Start Schulung vor um den Teilnehmern einen schnellen Einstieg in die Benutzung von Kubernetes zu bringen. Wenn du Interesse hast mehr mit uns in Kubernetes einzusteigen, schau doch mal nach den Terminen.

Das Headerbild stammt von Loik Marras via unsplash.

Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Von Fackeln, elektrischen Schafen und Datenpunkten

Hallo und Willkommen im Jahr 2021! sheep

Damit sind wir offiziell 2 Jahre nach dem originalen Zeitablauf von Blade Runner welcher 2019 spielt.
Hmm, nirgends sind Nexus 6 Modelle die Rumlaufen und von elektrischen Schafen träumen.
(Auch keine Flugautos) *seufz*. Egal !!

Kommen wir zu dem eigentlichen Thema diese Woche.
Ich würde euch gern im neuen Jahr kurz erklären wie ihr mit einfachen Bordmitteln & wenig Aufwand aus den den meisten APIs Prometheus Daten exportiert ohne Zusatzsoftware zu installieren.

Explainer!! Was macht man mit den Fackeln https://prometheus.io/ ist eine Software welche mit ihrer eigenen Time Series Database auch Graphen Zeichnen kann und einen ziemlichen Erfolg hat, https://prometheus.io/docs/prometheus/latest/storage/ wenn man allerdings aus seiner Allerweltsapplikation Daten nach Prometheus exportieren will ist man leicht Aufgeschmissen. Viele Anbieter verkaufen teuer Plugins welche dies für Software tun oder es gibt halt keine Schnittstelle.

Ich versuche in meinem Beispiel aufzuzeigen wie man sich selbst einen Prometheus Output baut und ihn mit dem Prometheus node_exporter zu der Haupt Prometheus Instanz bringt.

Was brauchen wir an Software dafür machen wir einen kleinen Einkaufszettel 🙂

Die Zutaten:
1x Software welche eine API zur verfügung stellt – als Beispiel nehmen wir Icinga 2 kann aber eine Software eurer Wahl sein
1x Prometheus node_exporter (muss man leider zusätzlich installieren)
1x crontab – bringt hoffentlich eure Linux Distro von Haus aus mit
1x curl – hoffentlich auch schon von “Werk” ab mit an Bord
1x awk – same here auch hoffentlich schon mit an Bord
1x jq – Okay .. ich geb zu das muss man nachinstallieren (ich versuche mich gerade unter dem Schreibtisch zu verstecken)
https://stedolan.github.io/jq/download/

Nun wo wir die Zutaten kennen kommen wir zu dem eigentlichen Rezept.
*/1 * * * * curl -k -s -u 'user:password' https://localhost:5665/v1/status | jq '.results[1].status.active_host_checks_1min' | awk {'print "node_icinga2_active_checks1m""{" "active=" "\"" "/checks1m" "\"" "}" " "$1'} > /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ && mv /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ /var/lib/node_exporter/textfile_collector/active_checks.prom

Was habe Ich da in der Zeile über dieser eigentlich verbrochen?
Dröseln wir das doch auf, Schritt für Schritt.

Step 1:
*/1 * * * * curl -k -s -u 'user:password' https://localhost:5665/v1/status
Ich gehe im Crontab jede Minute her und greife mir aus der lokalen icinga 2 Instanz per Api den Status per JSON.

Step 2:
| jq '.results[1].status.active_host_checks_1min'
Dann gebe ich den JSON Output an jq weiter. Dies lass ich auf einen Wert aus dem JSON parsen. Idealerweise ein Zahlenwert welchen einen schönen Datenpunkt abgibt.

Step 3:
| awk {'print "node_icinga2_active_checks1m""{" "active=" "\"" "/checks1m" "\"" "}" " "$1'}
Dies reicht leider für Prometheus nicht aus wir müssen das etwas aufbereiten das Prometheus das auch als Datenquelle akzeptiert. Der Inhalt eines .prom Files muss in folgenderweise Formatiert sein. Hier kommt awk für die Aufbereitung ins Spiel.

Was nach dem awk Befehl rauskommt sieht formatiert ungefähr so aus node_icinga2_active_checks1m{active="/checks1m"} 607.

Ich hab mal aus Beschreibungsgründen den vorderen Teil node_icinga2_active_checks1m genannt. Könnte aber auch node_raspberrypi15_active_tempsensor30s sein. Danach folgt {active="/checks1m"} 607 welches nochmal auf den Key=Value + Wert Part hinweist. Ich bin aber ehrlich hier schwimme ich selbst etwas. Wenn mir jemand hier Aufschlüsseln kann was hier “Notwendig” ist wäre ich sehr Dankbar.

Step 4:
> /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ && mv /var/lib/node_exporter/textfile_collector/active_checks.prom.$$ /var/lib/node_exporter/textfile_collector/active_checks.prom
Danach wird der von awk aufbereitete String in eine active_checks.prom Datei geschrieben.

Damit haben wir ein valides Prometheus File welches wir dem node_exporter (Prometheus) übergeben können.
Was hat es nun mit /var/lib/node_exporter/textfile_collector/active_checks.prom auf sich .. Der oben in der Zutatenliste erwähnte Prometheus node_exporter ist im Grunde die Datenschleuder welche konfiguriert, in einem selbst definierten Intervall (scrape_intervall) die active_checks.prom Datei in Richtung Prometheus Hauptinstanz wirft. Die dann wiederum die Werte in ihre Time Series Database einträgt und den Graphen zeichnet.

Da der Prometheus node_exporter selbst unterschiedliche Möglichkeiten hat Daten entgegenzunehmen, wir aber in "textform" Daten ihm liefern legen wir die .prom Datei unter dem Pfad /var/lib/node_exporter/textfile_collector/ ab.

Damit der node_exporter weiß wann er in welchem Intervall die von uns Aufbereiteten Daten an das Haupt Prometheus übergeben soll.
Muss Konfig ihm sagen wann (kurzer Abriss der /etc/prometheus/prometheus.yml)
...
## Add Node Exporter
- job_name: 'icinga2'
   scrape_interval: 60s
   static_configs:
      - targets: ['x.x.x.x:9100'] <= Adresse der Haupt Prometheus Instanz welche in dem Screenshot unten uns dann einen Graphen zeichnet.

Im Prometheus (Hauptinstanz) haben wir dann so einen Graphen wie im Screenshot unten, dies kann man auch noch schöner in Grafana zeichnen lassen sprich wenn man in seiner Software ein Grafana Fenster eingebunden hat kann man diese Graphen da hinein verlinken.

Ich hoffe ich konnte euch etwas den Einstieg in das neue Jahr verschönern mit meinem Versuch euch einen Prometheus Datenexport nahe zubringen und ich freue mich über euer Feedback.
Servus bis zum nächsten Mal !

David

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

DevOpsDays Berlin cancelled

The DevOpsDays Berlin have been cancelled for this year due to Corona. “Though there were good arguments for running the conference, most of us felt uncomfortable to expose people to a potential danger that isn’t fully understood yet”, the organizers said. They decided to suspend the event in 2020 and to hold it again in 2021. Holding the conference online was not really an option for the Berlin crew. Other DevOpsDays who did an online version of their event had great success with the attendee numbers, but they felt that this would miss out with the most important part of the conference: Bringing people together in person and the community aspect of the event. The Berlin organizers are planning an event for 2021, which can be expected to fall into the same time as this or the last years: Beginning to middle of fall 2021.

Entries from this Call for Papers won’t be kept for next year (“because the only thing older than a ‘Tech Talk’ from a year ago is yesterday’s newspaper”). Who already proposed would need to create a new entry next year. The DevOpsDays Berlin organizers thank all speakers for their awesome talk and session proposals this year, and encourage and invite people to propose again in 2021.

Keep an eye on https://devopsdays.berlin/ or on the Twitter feed @blndevops to stay informed and get the new dates.

Julia Hornung
Julia Hornung
Lead Senior Marketing Manager

Julia ist seit Juni 2018 bei NETWAYS. Mit ihren Spezialgebieten Texte/Konzepte, Branding und PR ist sie für Tone of Voice und Wording von NETWAYS und Icinga verantwortlich. Davor war sie als Journalistin und in der freien Theaterszene spannenden Geschichten auf der Spur. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Ihre innere Mitte findet sie beim Klettern und Yoga.

Ansible – Use Blocks and Rescue Errors

Ansible is a widely used and powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

Since version 2.0.0 Ansible introduced the usage of blocks, they provide the possibility to group or rescue failed tasks.
On blocks we can assign most directives which are available for any other task at block level, only loops aren’t available.

- name: Update Systems
  hosts: all
  tasks:
    - name: execute this block only for rhel family hosts
      block:
        - name: install epel repository
          yum:
            name: epel-release
            state: present

        - name: install updates
          yum:
            name: '*'
            state: latest
            exclude: kernel*

      when: ansible_os_family == 'RedHat'
      become: true

When we try to deploy applications, sometimes we need to test connections or if requirements are met. When those tasks fail caused by the negative test result, the playbook by default fails and therefore stops.
To force Ansible to execute all other tasks, we could use the directive ignore_failed: true and checking the return value for any other depending task.

With blocks this is easily solved, by using rescue to catch the error and force a particular tasks to run.
The always will make sure that the listed tasks get executed.


- name: rescue my errors
  hosts: localhost
  tasks:
    - name: Try to reach host
      block:
        - name: "[Try reach DNS] Check Connection over DNS"
          command: ping client01.demo.local -c 2
          register: output
      rescue:
        - name: "[Rescue failed DNS] Check Connection over IP"
          command: ping 192.168.33.1 -c 2
          register: output
      always:
        - debug:
            var: output

To handle more than one rescue statement, the block can be simply used in the rescue section, like in the following example.


  - name: Try to execute skript
    block:
      - name: Check Connection over DNS
        command: ping nclient01.demo.local -c 2
        register: output
    rescue:
      - name: "this will fail"
        block:
          - name: it will be false
            command: /bin/false
            register: output
        rescue:
          - name: "this works"
            command: ping 192.168.33.1 -c 2
            register: output

Try to reduce ignored tasks in failed state with rescue blocks, this reduces the confusion of users when inspecting the output.
As second advice try to reduce code duplication by grouping tasks with similar directives.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.