AJAX mit Ruby on Rails und :remote => true

Mit :remote => true bietet das das Ruby Webframework Rails eine sehr einfache Methode um mit Hilfe von AJAX eine Webseite zu aktualisieren. Dieses kann z.B. einfach zu HTML-Elementen wie Formulare, Buttons, Links und Checkboxen hinzugefügt werden. Dadurch werden z.B. gefüllte Formulare nicht mehr wie gewohnt an den Webserver gesendet, sondern mit AJAX. Man erspart dem Benutzer dadurch einen lästigen ggf. langwierigen Seitenaufbau. Im Gegenzug muss man sich aber selber um eine Aktualisierung der Webseite mit Hilfe von jQuery oder JavaScript kümmern.

Folgender Code in einem View erstellt eine Checkbox welche bei einem Klick mit Hilfe von AJAX einen HTTP Post an die angeben URL sendet:

check_box_tag( 
  "my_checkbox", "i_am_checked", false, 
  data: { 
    remote: true, 
    url: "my_checkbox/click", 
    method: "POST" 
  }
)

Der Request muss in diesem Fall vom my_checkbox Controller angenommen und verarbeitet werden. Um die Ansicht des Benutzers zu ändern schickt man mit den bekannten Rails Methoden Javascript an den Browser zurück. Im my_checkbox_controller.rb erweitert man z.B. die respond_to einfach um ein format.js:

def click
  respond_to do |format|
    format.js {}
  end
end

Der dazugehörigen View (click.js.erb) wird somit an den Browser zurück gesendet und man kann per JavaScript die Webseite aktualisieren:

console.log('I am the response!')
alert('You clicked the checkbox!')

Rails bietet mit :remote=>true somit eine wirklich einfach Methode um AJAX für seine Webseite einzusetzen!

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.

Get your RadosGW metrics into Ceilometer

With OpenStack it is an ease to provide an object store backed up from your Ceph RadosGW. But getting the usage metrics from Ceph into Ceilometer and Gnocchi is a little bit tricky. At least if you use OpenStack Pike. Following the official Pike documentation we need a RadosGW user with the correct credentials, usage logging enabled and a little bit of Ceilometer configuration:
 

$ radosgw-admin user create --uid ceilometer --display-name "ceilometer" --caps "usage=read;metadata=read;users=read;buckets=read"
# ceilometer.conf
[service_types]
radosgw = object-store
 
[rgw_admin_credentials]
access_key = access
secret_key = secret

 
Additionally we need to add the radosgw.* metrics to your ceilometer polling.yaml. At this point the official documentation lets you down with inconsistent metric names. In Pike, there are no entry points for radosgw.* metrics, only for the old rgw.* metrics. This is described in the bug #1726458. But following the defined entry points into the code, we see that these creates the new radosgw.* metrics. Well, adding the old metric names to your polling.yaml delivers you the new metric names… ¯\_(ツ)_/¯
 

# polling.yaml
- name: radosgw_pollsters
    interval: 1200
    meters:
    -  rgw.containers.objects
    -  rgw.containers.objects.size
    -  rgw.objects
    -  rgw.objects.size
    -  rgw.objects.containers
    -  rgw.usage

To bring it to an end, restarting “ceilometer central” will deliver your RadwosGW metrics to Gnocchi.

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: 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 <pool> pg_num <int>
$ ceph osd <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.