Gnocchi: Metriken und Metadaten

Gnocchi LogoGnocchi kann im Vergleich zu anderen Timeseries Datenbanken auch Metadaten zu einzelnen Ressourcen hinzufügen. Somit kann man Metriken einfach mit Informationen versehen die wiederum für so spannende Dinge wie Accounting und Reporting verwendet werden können. Eine konkrete Metrik, z.B. der aktuelle Speicherverbrauch eines Servers, wird in Gnocchi immer zu einer Ressource (z.B. mein-db-server1) gespeichert. Eine Ressource hat einen Typ, z.B. Server. Der Typ Server gibt die Attribute/Metadaten vor, welche zu meiner Ressource mein-db-server1 gespeichert werden können.
Also nochmal in kurz: Eine Metrik gehört zu einer Ressource. Eine Ressource hat einen Typ. Ein Typ hat Metadaten.
Ein neuer Ressourcetyp, z.B. Server,  mit den Attributen Name und Kundenummer ist mit folgenden HTTP Post an den Endpunkt /v1/resource_type schnell erstellt:

{
  "Name": "Server",
  "attributes": {
    "name": {
    "required": true,
    "type": "string"
  },
  "Kundennummer": {
    "max": 8,
    "min": 8,
    "type": "number",
    "required": true
  }
}

Um nun eine konkrete Ressource mein-db-server1 anzulegen, sendet man unten stehendes Json an den Endpunkt /v1/resource/server:

{
"Kundennummer": "12345678",
"Name": "mein-db-server1"
}

Zu der neuen Ressource kann man beliebige Metriken (z.B. CPU, Memory, Traffic etc.) hinzufügen und natürlich lassen sich auch die Filter der Suche auf die Kundennummer anpassen. Folgender HTTP Post an /v1/search/resource/server findet alle meine Server wieder:

{
  "=": {
    "Kundennummer": "12345678"
  }
}

Gnocchi gibt einem alles an die Hand um die eigenen Metriken mit Metadaten zu versorgen. Damit ist es ein Leichtes seine Reporting und Accounting Tools mit Daten zu befüllen, wie z.B. unser Cost Explorer.

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.

Gnocchi und Archiv Policies

Gnocchi ist eine time series database die aus dem OpenStack Projekt hervorgegangen ist. Da Gnocchi erst 2014 entstanden ist, wurde versucht die Schwächen vorhandener Lösungen zu umgehen. Im Vergleich fallen mir vor allem folgenden Features auf:

  • Mandantenfähigkeit
  • Skalierbarkeit
  • Hochverfügbarkeit
  • REST Interface (HTTP)
  • Unterstützung moderner Backends wie Ceph (librbd), Swift und S3
  • OpenSource

Ein weiters Feature ist die Unterstützung von archive policies. Diese legen fest wie lange und in welcher Granularität Metriken vorgehalten werden. Zusätzlich kann auch die Art der Aggregation definiert werden. Sendet man den unten stehenden json Text per HTTP an /v1/archive_policy wird z.B. eine Policy angelegt die Metriken mit einer Granularität von 5 Minuten für 62 Tage speichert und dafür 17856 Punkte benötigt (12 Metriken je Stunde * 24 Stunden * 62 Tage = 17856). Zusätzlich werden die Metriken in aggregierter From  für 365 und 3650 Tage gespeichert.
 

{
  "name": "router-metriken",
  "back_window" : 0,
  "definition" : [
    {
      "points" : 17856,
      "granularity" : "00:05:00",
      "timespan" : "62 days, 0:00:00"
    },
    {
      "points" : 8760,
      "granularity" : "1:00:00",
      "timespan" : "365 days, 0:00:00"
    },
    {
      "points" : 3650,
      "granularity" : "24:00:00",
      "timespan" : "3650 days, 0:00:00"
    }
  ],
  "aggregation_methods" : [
    "min",
    "max",
    "mean",
    "sum"
  ]
}

 
Welche archive policy für einzelne Metriken angewendet wird kann über rules bestimmt werden. Neue Metriken werden per Regex geprüft und ggf. einer Policy zugewiesen. Treffen mehrer Regeln greift der längste Regex. Mit der folgenden Regel werden alle Metriken die mit router beginnen zu der oben definierten Policy hinzugefügt.
 

{
  "archive_policy_name": "router-metriken",
  "metric_pattern": "router.*",
  "name": "router-metriken"
}

 
Mein erster Eindruck von Gnocchi ist durchaus positiv und mit den genannten Features kann sich die OpenStack Lösung von der Konkurrenz abheben. Aktuell ist Gnocchi wohl am besten für die Bedürfnisse von OpenStack ausgelegt. Es gibt aber auch Integrationen zu collectd, statsd, Icinga und Grafana.

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.

How to use ext4 beyond 16TiB

Using large file systems with several terabytes of data is quite common. Usually system administrators use well-known file systems like ext4, xfs, zfs or newcomers like btrfs. Even ext4, the more or less standard Linux file system, supports up to 10 EiB of data and is marked as stable since Kernel 2.6.28 (release in December 2008). Increasing volumes beyond 16 TiB shouldn’t be a problem.

In the case of ext4 this is only true if the file system was explicitly created with the 64bit feature enabled, which isn’t the default on recent Linux distributions like Ubuntu 16.04. Without 64-bit support your ext4 volumes are limited to 16TiB of data. The 64bit feature is enabled by default since e2fsprogs >= 1.43, but this version isn’t packed for many Linux distributions yet.

 

Fortunately converting a 32-bit ext4 volume to 64-bit is supported since e2fsprogs >= 1.43. A online conversion is not possible.


  1. download and compile e2fsprogs, at least version 1.43
    $ git clone -b v1.43 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git e2fsprogs
    $ cd e2fsprogs
    $ ./configure
    $ make
    $ cd resize2fs
    $ ./resize2fs
    
  2. unmount the file system
  3. run fsck and repair your file system
  4. run resize2fs with the -b flag to enable the 64bit feature
    $ resize2fs -b /dev/my-block-device
    
  5. check if 64bit feature is enabled
    $ tune2fs -l /dev/my-block-device
    

Depending on your number of inodes the file system check and the conversion to 64-bit can took a lot of time. For resizing or running a file system check you should use at least the latest minor release of e2fsprogs of 1.42.x


For a more detailed information, just have a quick look into the Release notes of e2fsprogs and on AskUbuntu.
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.

Ceph: Increasing placement groups in production

Ceph LogoIf you are running a Ceph cluster for several years you will come to the point where the number of placement groups (PGs) no longer fits to the size of your cluster. Maybe you increased the number of OSDs several times, maybe you misjudged the growth of a pool years ago.
Too few PGs per OSD can lead to drawbacks regarding performance, recovery time and uneven data distribution. The latter can be examined with the command ceph osd df. It shows the usage, weight, variance and number of PGs for each OSD as well the min/max variance and the standard deviation of your OSD usage.
Increasing the number of the PGs can lead to a more even data distribution,
but there are several warnings in blogs or mailings lists, especially for production environments. Doubling the PGs (e.g. from 1024 to 2048) may bring down your cluster for some minutes, because creating, activating and peering the new PGs may strongly influence your client’s traffic.
Regarding this warnings, we decided to increase the PGs in slices of 128. Between each slice we waited until all PGs peered successfully, which needed only a few seconds and did not influence the client traffic at all.
Increasing the number of PGs is done with two simple commands:

$ ceph osd set <pool> pg_num <int>
$ ceph osd set <pool> pgp_num <int>

Increasing pg_num creates new PGs, but the data rebalancing and backfilling will only start after increasing pgp_num (the number of placement groups for placement), too. pg_num and pgp_num should always have the same value. Increasing your PGs usually comes with a huge amount of backfilling which should not be a problem for a well configured cluster.

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.

GitLab CE: Continuous Integration, Jobs and Runners

NWS GitLab CE Hosting Zur Verwaltung von auf git basierenden Projekten bietet GitLab CE neben Issue Tracker und Wiki auch eine Continuous Integration (CI) Umgebung. Pro Projekt kann eine CI-Konfiguration mit Job Definitionen gesetzt werden, welche nach jedem Commit von sogenannten GitLab Runner ausgeführt werden.  Die klassische CI-Pipeline (vom Build bis zum Deploy) kann mit Hilfe von Stages abgebildet werden. Die CI-Konfiguration wird als Datei (.gitlab-ci.yml) im Projekt mit abgespeichert.
 
Im folgendem ein kleines Beispiel welches einen GitLab Runner mit Docker Executor verwendet:
.gitlab-ci.yml

image: debian:latest
stages:
  - build
  - test
  - deploy
job1:
  stage: build
  script: 'ping -c 4 nws.netways.de'
job2:
  stage: test
  script: 'ping -c 4 netways.de'
job3:
  stage: deploy
  script: 'echo "deploying"'
after_script:
  - 'echo "do some housekeeping"'

 
Mit jedem Commit im Projekt werden die definierten Stages build, test und deploy und deren Jobs durchlaufen und von GitLab CE natürlich auch schön visualisiert wird.


GitLab Runner können verschiedene Executor haben, beginnend mit der klassischen Shell über Parallels hinzu Docker und Kubernetes. Wem das alles zu viel ist kann auch unsere vorkonfiguriertes GitLab CE mit Runner ausprobieren oder bei unserem Manged Services nach einem maßgeschneidertem Angebot nachfragen.

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.

Neue Juwelen in Ceph

Schulung_Stammlogo_webDer letzte Ceph Major Release Jewel hat nicht nur viele Bugs behoben sondern auch neue Features eingeführt bzw. für die Produktion freigegeben.
Ein neues Feature ist der sogenannte rbd-mirror, welcher zur asynchronen Replikationen von RBDs (vergleichbar mir iSCSI) verwendet wird. Ein neuer Daemon kümmert sich selbständig um die ständige Replikation der der RBDs zwischen zwei Clustern. Dadurch wird der Betrieb eines unabhängigen Clusters für Disaster Recovery Zwecke sehr viel einfacher und effektiver.
Mit Jewel wurde auch das neue Storage Backend Bluestore eingeführt. Dies ist der erste Schritt um sich von XFS zu trennen und vor allem von den doppelten Schreibprozessen, welche durch das Journal des Dateisystems verursacht werden. Bluestore soll bereits in der nächsten Version für produktive Cluster geeignet sein.
Lang erwartet, wurde auch CephFS für die Produktion freigeben. Das POSIX kompatible, shared Dateisystem kann gleichzeitig von mehreren Clients eingebunden und verwendet werden. Allerdings gibt es noch kleinere Einschränkungen die aber natürlich mit den nächsten Versionen angegangen werden.
Wer jetzt mehr Lust auf Ceph bekommen hat ist herzlich zu unserer Ceph Schulung im November eingeladen. Neben den beständigen Neuerungen in Ceph werden dort natürlich die grundlegenden Komponenten und Konzepte im Detail erklärt.

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.

MesosCon Europe

Dieses Jahr findet die MesosCon Europe in Amsterdam statt. Neben schönem Wetter und einer tollen Stadt erwartet uns ein breites Programm rund um das Apache Mesos Framework.
Mesos selbst ist ein Cluster Framework zur Verwaltung der im Rechenzentrum zur Verfügung stehenden Ressourcen (z.B. CPU, Ram, Storage). Ein Scheduler in Mesos bietet diese Ressourcen verschiedensten Applikationen an und startet diese. Insbesondere im Containerumfeld bietet Mesos in Kombinationen mit Marathon (ein Mesos Plugin) viele Möglichkeiten seine Applikationen zu verwalten.
Die kürzlich veröffentlichte Version 1.0 ist natürlich ein großes Thema. So bietet Mesos jetzt neben einer neuen HTTP API auch einen unified containerizer zum Starten verschiedener Container Formate. Auch im Networking Bereich bietet die neue Version neue Features, vor allem die Möglichkeit eine IP je Container zu vergeben gehört zu den Highlights. Nicht zuletzt wird der Release von einem neuen Autorisierungsmodell abgerundet.
Das breit angelegte Programm bietet in den nächsten zwei Tagen Vorträge zu vermutlich allen Themen rund um Mesos, Marathon, Microservices, Service Discovery, Storage, DC/OS und mehr, aber natürlich geben auch namhafte Firmen wie Twitter und Netflix Einsicht in ihre Setups, bei denen natürlich Mesos die Microservices verwaltet.
Ein Hackathon am Freitag lässt die Konferenz schön ausklingen. Leider geht es für uns vorher schon zurück nach Nürnberg.

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.

docker-compose

Docker LogoAuf der diesjährigen DockerCon in San Francisco wurden viele Neuerungen vorgestellt. Neben der eigentlichen Docker Engine wurde auch eine neue Version von Compose vorgestellt. Mit docker-compose kann man ganze Anwendungsumgebungen definieren und mit einem Befehl starten. Dies ist vor allem für Setups mit mehreren Containern hilfreich. Man definiert in einer zentralen Datei (docker-compose.yml) die benötigten Container und deren Parameter und führt den Befehl docker-compose up aus. Wer Vagrant benutzt erkennt sofort die parallelen zur Vagrantfile. Compose sorgt dann dafür, dass die Container wie definiert gestartet werden.
Die docker-compose.yml ist im einfachen YAML-Format gehalten. Im folgendem ein kurzes Beispiel aus der offiziellen Dokumentation:

web:
  build: ./web/
  ports:
   - "5000:3333"
  links:
   - redis
  volumes:
   - .:/code
redis:
  image: redis

In diesem Beispiel wird für den Container web ein Image mit Hilfe der ./web/Dockerfile gebaut (build: ./web/), der Port 5000 wird an den Container Port 3333 weitergeleitet, es wird ein Link zum Container redis erstellt und es wird das Volume /code gemountet. Für den redis Container wird einfach das Image von DockerHub heruntergeladen.
docker-compose up -d startet web und redis im Hintergrund und mit docker-compose ps werden die aktuell laufenden Container angezeigt. docker-compose stop beendet diese wieder.
Am Besten einfach selber ausprobieren. docker-compose selbst kann man einfach mit pip installieren.

# pip install -U websocket
# pip install -U docker-compose
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.

Verifying YAML

Wer Puppet mit Hiera und einem YAML Backend nutzt weiß das einfache Format sicherlich zu schätzen. Listen, Maps und Einzelwerte lassen sich schnell, einfach und leserlich abbilden:

Liste1: ["a", "b", "c"]
Liste2:
  - d
  - e
MapEins:
  eins: 1
  zwei: 2
  drei:
    drei: 3
key: value

Zur Interpretation der Datenstrukturen verlässt sich YAML auf eine fehlerfreie Einrückung der einzelnen Elemente, z.B. müssen in Liste2 die Element e und d mit gleich vielen Leerzeichen eingerückt werden. Im Prinzip eine sehr einfach Regel, allerdings ist vermutlich auch schon jeder in solch kleine Stolperfallen des YAML-Formats gelaufen. In Verbindung mit Puppet führt dies manchmal zu unklaren bzw. ungenauen Fehlermeldungen. Oftmals werden Fehler durch zu viele oder zu wenige Leerzeichen, Tabs, unsichtbare Sonderzeichen bzw. falsche Zeilenumbrüche verursacht. Aber soweit muss es nicht kommen, da es viele Möglichkeiten gibt die YAML-Syntax zu prüfen. In der Regel bietet jede Skript Sprache einen YAML-Parser, welche mehr oder weniger klare Fehlermeldungen ausgeben. Für ein kleines Beispiel habe ich ein Element falsch eingerückt und in verschiedenen Skript Sprachen geladen:

$ python -c "import yaml; yaml.load( open('my.yaml', 'r'), Loader=yaml.CLoader  )"
yaml.scanner.ScannerError: mapping values are not allowed in this context
  in "my.yaml", line 8, column 8
$ ruby -e "require 'yaml'; YAML.load_file('my.yaml')"
/usr/share/ruby/psych.rb:370:in 'parse': (my.yaml): mapping values are not allowed in this context at line 8 column 8 (Psych::SyntaxError)
$ js-yaml my.yaml
JS-YAML: bad indentation of a mapping entry at line 8, column 8:
       zwei: 2
           ^

Ihr seht selbst, dass js-yaml den Fehler wohl am besten und klarsten darstellt. Natürlich will keiner immer wieder auf der Command-Line überprüfen ob die verwendeten YAML Dateien korrekt formatiert sind. Am besten soll dies der Editor bereits beim speichern der Datei anzeigen. Wer vim mit Syntastic verwendet muss nur dafür sorgen, dass js-yaml vorhanden ist. Dies installiert man am besten über den Node.js Paket Manager npm.

$ apt-get/yum/dnf install npm
$ npm install -g js-yaml

Wie man Syntastic für vim installiert könnt ihr hier nachlesen.

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.

Input/Output Muster visualisieren

In modernen Storage-Systemen wie Ceph hat man in der Regel verschiedene Arten und Möglichkeiten Caching zu realisieren. Bei einem einfachem Ceph Setup ist für gewöhnlich ein Schreib-Cache vorhanden der aus SSDs besteht. Verwendet man Ceph in Kombination mit QEMU/KVM so kann zusätzlich noch der sogenannte RBD-Cache aktiviert werden welcher bereits aus den Virtualisierungshosts Daten puffert.
Natürlich wird durch das Puffern der Daten das Lese- und Schreibmuster auf den endgültigem persistentem Datenträger (meist SAS- bzw. SATA-Platten) immer undurchsichtiger.
Mit Hilfe von blktrace kann man die Lese- und Schreibzugriffe auf dem Datenträger lokalisieren und seekwatcher erstellt einem ohne großen Aufwand auch noch ein Video davon.

# yum/apt-get install blktrace seekwatcher mencoder
# blktrace -d /dev/sda -o find
# seekwatcher -t find.blktrace.* -m -o find.mpg

Der erste Befehl schreibt alle aktuellen Aktivitäten von sda nach find.blktrace.x Dateien. seekwatcher erstellt anschließend ein Video.
Das erste Video zeigt ein `vagrant up` einer icinga2-Box. Die Box wird langsam heruntergeladen, das Image nochmals kopiert und dann geht es los mit der Installation. Das zweite Video zeigt ein `find /`. Jedes Quadrat zeigt einen Sector an und wird farbig sobald IO auf diesem stattfindet. Dieser blendet sich anschließend langsam wieder aus. Ich finde in diesen beiden Fällen kann man die IO-Muster schön interpretieren.


Für einen besseren Vergleich kann man sich die beiden Fälle auch in einer Grafik anzeigen lassen. Hat man noch Datenträger die sich drehen ist hier unter anderem der Seek Count interessant, aber seht selbst.
IO-Vergleich find / vs vagrant up

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.