Hot Backups mittels Xtrabackup

Wie Markus in seinem letzten Blogpost schon beschrieben hat, hatte er die zweifelhafte Ehre ein Backup einer verhältnismäßig großen MySQL-Datenbank (MariaDB) zu machen. Das große Problem bei ihm war allerdings, dass das Kopieren auf Dateiebene eine Downtime der Datenbank voraussetzte und somit der laufende Betrieb eingestellt werden musste. Man legt sozusagen die Datenbank auf Eis und deshalb nennt man dieses Verfahren auch Cold Backup (Offline Backup). Dies war zumindest meine Schlussfolgerung zur Namensgebung…

Als wissensdurstiger Azubi bei NETWAYS wollte ich wissen ob es vielleicht eine Möglichkeit gibt, ein Backup einer MySQL-Datenbank während  des laufenden Betriebes zu machen. Bei meinen Recherchen bin ich letztlich auf ein heiß diskutiertes Thema gestoßen. Wie der Name schon sagt, auf das “heiße”, sogenannte Hot Backup (Online Backup). Bei diesem Backupverfahren ist es möglich während des laufenden Betriebes einer MySQL-Datenbank ein Backup zu erstellen und somit eine Downtime der Datenbank zu vermeiden. Das Online Backup kann somit mehrmals am Tag durchgeführt werden, des Weiteren ist es deutlich schneller als das Offline Backup. Allerdings birgt ein Hot Backup auch ein gewisses Risiko, da im Gegensatz zum Cold Backup, weiter Daten in die Datenbank geschrieben werden und diese somit nicht im Backup enthalten wären. Das wäre aber im Ernstfall (Ausfall der Datenbank) zu verschmerzen, da somit beispielsweise womöglich nur Daten der letzten paar Stunden und nicht von einem ganzen Arbeitstag verloren wären.

Im Folgenden zeige ich anhand eines kleinen Beispiels, wie so ein Hot Backup vonstatten geht. Das Tool meiner Wahl ist Xtrabackup von Percona. Xtrabackup kann ein Hot Backup erstellen indem es sich die sog. crash-recovery Funktion von InnoDB-Datenbanken zu Nutze macht. Die Installation von Xtrabackup ist in der Dokumentation hervorragend beschrieben.

Zunächst benötigt man einen Datenbankuser mit folgenden Rechten:
mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'SuperGeheim!';
mysql> GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';
mysql> GRANT SELECT ON performance_schema.log_status TO 'backupuser'@'localhost';

Der nächste Schritt ist ein Backup anzustoßen:
$ xtrabackup --backup --user=backupuser --password=SuperGeheim! --target-dir=/var/test_backup
“–target-dir”: In diesem frei zu wählenden Ordner werden die Backups gespeichert.

Man kann bei der Ausgabe sehr gut erkennen, dass Xtrabackup sich die sog. LSN (Log Sequence Number) “merkt” und ab diesem Zeitpunkt die Tabellen der Datenbank sperrt sowie alle weiteren Schreiboperationen “puffert”. Nach dem Kopieren der Daten werden die Tabellen wieder frei gegeben und der Betrieb ab der “gemerkten” LSN wieder aufgenommen:
190829 10:27:43 >> log scanned up to (146090017)
xtrabackup: Generating a list of tablespaces
190829 10:27:43 [01] Copying ./ibdata1 to /var/test_backup/ibdata1
190829 10:27:44 [01] ...done
190829 10:27:44 >> log scanned up to (146090017)
190829 10:27:44 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
190829 10:27:44 Executing FLUSH TABLES WITH READ LOCK...
190829 10:27:44 Starting to backup non-InnoDB tables and files
[...]
[...]
190829 10:27:46 Finished backing up non-InnoDB tables and files
190829 10:27:46 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '146090233'
xtrabackup: Stopping log copying thread.
.190829 10:27:46 >> log scanned up to (146090233)
190829 10:27:46 Executing UNLOCK TABLES
190829 10:27:46 All tables unlocked
190829 10:27:46 Backup created in directory '/var/test_backup'
190829 10:27:46 [00] Writing /var/test_backup/backup-my.cnf
190829 10:27:46 [00] ...done
190829 10:27:46 [00] Writing /var/test_backup/xtrabackup_info
190829 10:27:46 [00] ...done
xtrabackup: Transaction log of lsn (146086198) to (146090233) was copied.
190829 10:27:46 completed OK

Wenn das Backup erfolgreich war und man dieses wieder einspielen will, muss man dieses zuvor “vorbereiten”. Da die kopierten Daten womöglich nicht mit den aktuellen Daten übereinstimmen:
$ xtrabackup --prepare --target-dir=/var/test_backup

Hat man ein InnoDB: Shutdown completed; log sequence number 146093758
190829 10:45:05 completed OK!
erhalten, lässt sich das Backup wiederherstellen

ACHTUNG: Es müssen beim Wiederherstellen alle Daten aus /var/lib/mysql/ gelöscht werden. Hierbei sollte man sehr aufpassen, ansonsten kann es zum kompletten Datenverlust führen!!!

Um das “vorbereitete” Backup einzuspielen, muss der MySQL (MariaDB) Dienst gestoppt sein (was bei einem Ausfall sowieso der Fall sein dürfte). Der nächste Schritt wäre den Benutzer der Daten anzupassen und den Dienst erneut zu starten:
$ systemctl stop mariadb.service
$ rm -rf /var/lib/mysql/*
$ xtrabackup --move-back --target-dir=/var/test_backup
$ chown -R mysql:mysql /var/lib/mysql/
$ systemctl start mariadb.service

Als Fazit kann man sagen, dass sich Hot Backups sehr lohnen, aber auch ein gewisses Risiko beherbergen können. Cold Backups sind dazu im Gegensatz sehr “starr” und können nur während einer Downtime durchgeführt werden. Sie bieten jedoch die höhere Chance auf Datenkonsistenz und sind deutlich einfacher zu handhaben. Empfehlenswert ist es auf jeden Fall sich eine geeignete Datensicherungsstrategie aus beiden Varianten zu überlegen, bei der man zum Beispiel am Ende des Tages ein Cold Backup und während der Geschäftszeiten mehrere Hot Backups macht.

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

i-doit API Ruby-Scripting

Wie in meinem letzten Blogpost angekündigt stelle ich heute eine gescriptete Variante für die API der i-doit CMDB vor.

Einzelne Abfragen, sowie das Anlegen von Objekten über den RESTClient mögen auf den ersten Blick zum Testen bzw. Debuggen  ziemlich sinnvoll erscheinen, aber man stößt schnell an Grenzen, sobald es sich über mehrere hundert solcher Objekte handelt. Darüber hinaus ist diese Methode sehr umständlich.

Meine Idee war es eine Webanwendung zu benutzen, welche mit einem einzelnen Requests (im JSON-Format) an die API von I-doit Abfragen oder das Neuanlegen von Objekten vereinfacht. Da bot sich das Framework Sinatra an, da dieses eine sehr einfache und schnell zu lernende DSL besitzt. Wenn diese Anwendung läuft, kann mit der Eingabe einer bestimmten URL, ein Objekt abgefragt bzw. erstellt werden. In diesem Beispiel, werde ich die Namen sowie IDs aller Server aus der CMDB auslesen.

Zunächst müssen wir folgende drei Bibliotheken einbinden:

#!/usr/bin/env ruby

require 'sinatra/base'
require 'json'
require 'rest-client

Im nächsten Schritt bauen wir uns einen generischen Request (wie in meinem vorherigen Blogpost zu lesen) zusammen:

$baseurl = "https://example-idoit-web-gui.de"
$apikey = "random_key"

class CMDBApi
  def initialize(url=$baseurl, apikey=$apikey, objID=nil)
    @url = url
    @apikey = apikey
    @objID = objID
  end

  def postHeader(endpoint, method, payload)
    response = RestClient::Request.new({
      :method => method,
      :headers => {:accept => :json, :content_type => :json},
      :url => "#{@url}/#{endpoint}",
      :payload => payload
    }).execute
  end
  def readAllServer()
    payloadMetadata = Hash.new
    payloadMetadata[:version] = "2.0"
    payloadMetadata[:id] = "1"
    payloadMetadata[:method] = "cmdb.objects.read"
    payloadMetadata[:params] = Hash.new
    payloadMetadata[:params][:apikey] = @apikey
    payloadMetadata[:params][:filter] = {"type": "5"}
    @payloadJsonFormat = payloadMetadata.to_json
    response = postHeader("src/jsonrpc.php", :post, @payloadJsonFormat)
    response_hash = JSON.parse(response)
  end
end

get "/server" do
  api = CMDBApi.new($baseurl, $apikey)
  response = api.readAllServer(objectID)
  allServerHash = {}
  response["result"].each do |result|
    serverID = result["id"]
    serverName = result["title"]
    allServerHash[:"#{serverName}"] = serverID
  end
  allServerHash.to_json
end

Wenn man das Skript ausführt, wird (je nach Konfiguration) über http://127.0.0.1:4567 auf das Webfrontend zu gegriffen. Durch das zusätzliche Anhängen von  “/server” ist es möglich, alle Servernamen und deren zugehörigen Server-IDs aus i-doit auszulesen.

{
  • "Server_A" : 66273,
  • "Server_B" : 94647,
  • “Server_C” : 21221,
  • “…”: ….
}

Der große Vorteil einer solchen Webanwendung ist, dass man durch Erweiterung eine Automatisierung erreichen kann. Erhält man z.B. einen neuen Server, der mittels Puppet provisioniert wurde, kann vom Puppetmaster ein Objekt im i-doit angelegt werden. Hierzu kann damit auch auf alle ermittelten Facts zurückgegriffen werden. Diese sind dann über das zu erweiternde Skript an die API weiterzugeben, um final ein Server-Objekt mit allen angereicherten Informationen zu erhalten.

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

i-doit API create, update, delete

Wie in meinem letzten Blogpost angekündigt, werde ich anhand eines Beispiels zeigen, wie man mittels der i-doit-API Daten erstellen, aktualisieren und löschen kann.
Ein großer Vorteil den man durch das Benutzen der i-doit-API hat, ist der, dass man nicht “wie üblich” mit SQL-Statements interne Verarbeitungsschritte innerhalb der Datenbank umgeht. Dadurch kann es nicht passieren, dass man durch z.B. einem UPDATE-Statement einen Datensatz so verändert, dass dieser fehlerhaft wird. Somit ist die Datenintegrität mit der API gewährleistet.
Zunächst sucht man sich das Objekt aus der CMDB heraus welches man verändern will (im folgenden Beispiel das Modell eines bestehenden Servers):

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.read", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL"}}' \
--header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

Man erhält durch diese Anfrage folgende Antwort:

{
    "id": "1",
    "jsonrpc": "2.0",
    "result": []
}

Wie man sieht ist das result null. D.h. dieser Server/Objekt besitzt keinen Eintrag zu einem Modell bzw. Hersteller. Somit kann man nun ein neues Modell hinzufügen.
Zu beachten ist, dass im Voraus schon Modelle bzw. Hersteller in der CMDB angelegt wurden!

Die zu benutzende Methode ist cmdb.category.create:

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.create", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL",\
"data":{ "manufacturer": "random_manufacturer","title":"random_modelname","serial":"1234"}}}' \
--header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

Sollte alles funktioniert haben, bekommt man folgenden Response zurück:

{
  "jsonrpc": "2.0",
  "result": {
    "id": "855",
    "message": "Category entry successfully created.",
    "success": true
  },
  "id": "1"
}

Hat man z.B. die Seriennummer falsch eingetragen und möchte diese verändern, kann man dies mit der Methode update durchführen.
cmdb.category.update

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.update", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL",\
"data":{ "serial":"4321"}}' --header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

Im Anschluss kann man überprüfen ob alle eingetragenen Daten stimmen, indem man wieder den Server ausliest (oberes Beispiel cmdb.category.read):

{
  "jsonrpc": "2.0",
  "result": [{
    "id": "855",
    "objID": "random_objectid",
    "manufacturer": {
      "id": "13",
      "title": "random_manufacturer",
      "const": null,
      "title_lang": "random_manufacturer"
    },
    "title": {
      "id": "3",
      "title": "random_modelname",
      "const": null,
      "title_lang": "random_modelname"
    },
    "productid": "",
    "service_tag": "",
    "serial": "4321",
    "firmware": "",
    "description": ""
  }],
  "id": "1"
}

Zum Schluss löschen wir den Server komplett mittels der Methode quickpurge (quickpurge muss in i-doit aktiviert sein!)
cmdb.category.quickpurge:

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.quickpurge", \
"params":{ "apikey":"random_key","id":"random_objectid","\
--header "Content-Type: application/json" https://example-idoit-web-gui.de/src/jsonrpc.php \
| python -m json.tool

 

{
  "jsonrpc": "2.0",
  "result": {
    "message": "Object(s) successfully purged",
    "success": true
  },
  "id": "1"
}

Quickpurge ist eine Methode bei denen die drei Löschschritte (archivieren, löschen, purge) automatisch hintereinander ausgeführt werden. Ansonsten müsste man der Methode cmdb.object.delete die verschiedenen Status in folgender Reihenfolge mitschicken:

{
  ...
  "status": "C__RECORD_STATUS__ARCHIVED"
  ...
}
{
  ...
  "status": "C__RECORD_STATUS__DELETED"
  ...
}
{
  ...
  "status": "C__RECORD_STATUS__PURGE"
  ...
}

Im nächsten Teil der Serien zeige ich wie man mit einem Ruby-Script all diese Schritte automatisiert durchführen kann.

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

i-doit API

Als IT-Dienstleister bieten wir nicht nur Web Services oder Schulungen, sondern unter anderem auch Hosting an. Im Hosting-Bereich ist eine umfassende und geordnete IT-Dokumentation zwingend erforderlich um ein reibungsloses Arbeiten zu ermöglichen.  Als Lösung wird eine sog. CMDB (Configuration Management Database) eingesetzt, welche nicht nur als eine Inventarisierungs-Datenbank dient, sondern auch die gegenseitigen Abhängigkeiten der Objekte verwaltet. I-doit ist eine solche CMDB.
Seit der i-doit Version 1.8 ist die API kein Bestandteil der Pro-Version mehr und wird als separates Modul ausgeliefert welches frei verfügbar ist. Infolge dessen hab ich ein Azubiprojekt bekommen bei dem man die Funktionsweise einer API kennenlernen kann. Ich zeige im ersten Teil der i-doit API Serie wie man einen Request  über den curl – Befehl versendet.

Hat man die API über die Web GUI von i-doit konfiguriert kann man über folgende URL, welche an die Basis-URL angehängt wird, zugreifen:

/src/jsonrpc.php

Die Programmierschnittstelle kann auf Daten der CMDB über das JSON-Format zugreifen, d.h. es werden JSON-RPC Requests per HTTP-Post an i-doit geschickt und als JSON-RPC Response (mit HTTP-Header application/json) zurückgegeben. Somit kann man entweder über den curl – Befehl oder über einen RESTClient (z.B. als Firefox-Addon) die API ansprechen.
Ein beispielhafter Aufbau eines Request könnte folgendermaßen aussehen :

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "cmdb.objects.read",
  "params": {
    "apikey": "random_key",
    "filter": {
      "type": "4"
    }
  }
}
  • jsonrpc – version: Da i-doit ausschließlich die Version 2.0 des RPC-Request untersützt
  • id: Ein optionaler skalarer Wert (True, False, String, Numer) welcher aber nicht Null sein darf. Lässt man diesen Parameter aus, so wird lediglich eine Mitteilung verschickt, sodass der Server keine Rückmeldung generiert
  • method: Die zu aufrufende Methode
  • params: Parameter welche an die Methode übergeben werden
curl -s --data '{"jsonrpc":"2.0","id":"1","method":"cmdb.objects.read","params": \
{"apikey":"random_key","filter":{"type":"4"}}}' \
--header "Content-Type: application/json" \
https://example-idoit-web-gui.de/src/jsonrpc.php | python -m json.tool

Mit diesem Request lesen wir alle Objekte in der CMDB aus welche dem Typ 4 (Rack) entsprechen:

{
  "id": "1",
  "jsonrpc": "2.0",
  "result": [{
    "cmdb_status": "6",
    "cmdb_status_title": "in operation",
    "created": "2018-01-05 11:32:13",
    "id": "33",
    "image": "https://example-idoit-web-gui.de/images/objecttypes/something.png",
    "status": "2",
    "sysid": "SYSID_[RANDOMNUMBER_3849274329]",
    "title": "RacknameXYZ",
    "type": "4",
    "type_group_title": "Infrastructure",
    "type_title": "Rack",
    "updated": "2018-01-11 13:38:09"
  },
  {
    ...
    ...
  }]
}

Um z.B. alle Informationen einer Kategorie eines Objektes auslesen zu können, benutzt man die Methode cmdb.category.read:

curl -s --data '{"jsonrpc":"2.0","id":"1","method":"cmdb.category.read","params": \
{"apikey":"random_key","objID":"1234","category":"C__CATG__MODEL"}' \
--header "Content-Type: application/json" \
https://example-idoit-web-gui.de/src/jsonrpc.php | python -m json.tool

Response:

{
  "id": "1",
  "jsonrpc": "2.0",
  "result": [{
    "description": "",
    "firmware": "",
    "id": "307",
    "manufacturer": {
      "const": null,
      "id": "5",
      "title": "Random_Manufacturer_Name",
      "title_lang": "Random_Manufacturer_Name"
    },
  "objID": "Uniqe-Object-ID",
  "productid": "",
  "serial": "1235265477457",
  "service_tag": "",
  "title": {
    "const": null,
    "id": "71",
    "title": "XYZ1234",
    "title_lang": "XYZ1234"
  }
  }]
}

Eine ausführliche Liste aller in i-doit benutzten Kategorien kann man unter folgendem URL-Anhang aufrufen:

https://example-idoit-web-gui.de/index.php?load=api_properties

Darüber hinaus kann man über die i-doit API nicht nur Daten aus einer CMDB herauslesen, sondern auch erstellen, aktualisieren oder löschen. Diese Methoden werde ich im Teil 2 dieser Serie abhandeln.
 
Quellen: i-doit Knowledge Base



Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

Festplattenbenchmark mit bonnie++

Vor einigen Wochen haben Killian und Ich eine Serverwartung durchgeführt. Dabei haben wir nach der Aktualisierung einen sehr simplen Festplatten-Benchmark mittels dd durchgeführt. Im Nachhinein interessierte es mich, welche Performancewerte denn mein Arbeitslaptop bringen würde. Da ich genauere und ausführlichere Performancewerte haben wollte, suchte ich nach Benchmarktools. Nach einiger Recherche im Internet fand ich das Tool bonnie++, welches sich perfekt für einen Festplattenbenchmark eignet.
bonnie++ ist in den meisten Repositories verfügbar oder kann auf der Homepage heruntergeladen werden. Mit “aptget install bonnie++installiert man bonnie++ auf einem Debian/Ubuntu basierten System. Nun kann man schon mit den Tests starten!

Um  aussagekräftige Werte zu bekommen, muss man den Filecache so gering wie möglich halten. Man erreicht dies indem man Datasets schreibt, welche größer als der zu Verfügung stehende RAM ist (bonnie++ nimmt als Defaultwert  2 x RAM). Als Folge muss man also mindestens 2 x RAM freien Festplattenspeicher haben!

Wenn man bonnie++ ohne Parameter startet wird das Tool ausgeführt und liefert ein leicht unübersichtliches Ergebnis:

user@user-notebook:~$ bonnie++
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
user-notebook 15664M 658 99 290591 40 180714 21 1909 99 498792 39 8705 159
Latency 38628us 193ms 269ms 22258us 14790us 5094us
Version 1.97 ------Sequential Create------ --------Random Create--------
user-notebook -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
 files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 589us 1486us 935us 814us 71us 452us
1.97,1.97,nb-user-notebook,1,1524129932,15664M,,658,99,290591,40,180714,21,1909,99,498792,39,8705,159,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,38628us,193ms,269ms,22258us,14790us,5094us,589us,1486us,935us,814us,71us,452us

Falls man über eine GUI verfügt, kann man sich den Output auch in eine HTML-Datei speichern und diese über einen Webbrowser öffnen. Dies geht mit folgendem Befehl:

bonnie++ | tail -n 1 | bon_csv2html > $(date +"%Y.%m.%d.%S.%N")_bonnie.html

Die nun erstellte HTML-Datei listet alle Werte strukturiert auf und kann zugleich als Vergleichswert für spätere Tests verwendet werden.

Es ist auch möglich bonnie++ mit individuellen Einstellungen zu starten, im Folgendem die wichtigsten Parameter:

  • -r: Größe des Arbeitsspeichers in Megabyte und somit auch die Größe des zu erstellenden Datasets
  • -n: Anzahl der Dateien die zu einem Dataset zusammengesetzt werden
  • -x n: Der Test wird “n-mal” ausgeführt
  • -s: Definiert die Größe des Datasets in Megabyte
  • -b: Schaltet “write buffering” aus und führt einen “Sync” am Ende jeder bonnie++-Operation durch

(Alle Parameter mit ausführlicher Beschreibung findet man im Manual)
Man sollte bonnie++ mehrmals am Tag ausführen, denn nur so können Anomalien abgefangen werden und man erhält einen aussagekräftigen Durchschnittswert.
Quellen: UbuntuWiki, OCH-Group, JamesCoyle

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

Fast ein halbes Jahr NETWAYS

Am 01.September 2017 haben wir (Afeef, Killian, Philipp) bei NETWAYS unsere Ausbildung zum Fachinformatiker angefangen. Um uns auf die bevorstehende Arbeit im Professional Service vorzubereiten, bekamen wir gleich in der ersten Woche eine “Linux Basic”-Schulung. Damit wir das Gelernte weiter festigen können, wurde uns ein “LAMP”-Projekt aufgetragen. Ziel war es einen hochverfügbaren Webserver mit einer WordPress-Installation zur Verfügung zu stellen. Wir haben das Projekt in drei Teilbereiche aufgeteilt: LoadBalancer, Webserver und Datenbank. Nach erfolgreicher Zusammenarbeit haben wir das Projekt fertiggestellt und gemeinsam präsentiert.
Um Einblicke in andere Abteilungen zu bekommen, wurden wir in den daurauffolgenden Wochen aufgeteilt. Afeef durfte Managed Service unterstützten indem er ein automatisiertes Grafana-Dashboard mittels Puppet konfigurieren sollte. Besonders gefallen hat Ihm dabei die Hilfsbereitschaft der Kollegen aus Managed Service die Ihm bei Fragen über Puppet sofort geholfen haben. Meine Aufgabe war es derweil einen Maillserver aufzusetzen. Damit der Mailserver auch leicht zu benutzen ist, implementierte ich eine WebGUI mittels Roundcube.  Schon stand ein Wechsel zur Events-Abteilung an, die ich im November besuchen durfte. Ich half dabei, dass Schulungen richtig geplant und durchgeführt werden. In dieser Zeit kümmerte sich Killian um die neuen Schulungslaptops und konfigurierte ein neues Backupsystem namens ReaR. Schon stand auch die OSMC im November an, eine Premiere für uns Drei. Damit alle Vorträge auch aufgenommen werden hatten wir die ehrenvolle Aufgabe, als Raumwächter jeden Vortrag aufzunehmen, damit man diesen später anschauen kann.
Das nächste große Highlight war die Teilnahme unserer ersten NETWAYS-Schulung. “Fundamentals for Puppet” stand auf dem Programm, welche eine komplett neue Erfahrung für uns drei war. Damit meine ich nicht nur die technische Seite sondern auch, wie von NETWAYS gewohnt, die herzliche Umgangsweise und die super Verpflegung.
Damit wir das Gelernte gleich umsetzen können, stand das nächste große Projekt an und zwar mit Puppet. Killians Aufgabe ist es einen LAMP-Stack mittels Puppet zu realisieren, dazu benötigt er das Wissen von unserem ersten gemeinsamen LAMP-Projekt. Afeef kümmert sich derzeit weiter um das Grafana-Dashboard und ich realisiere meinen zuvor erstellten Mailserver mittels Puppet.

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...

Unternehmensfortbildung NETWAYS-Style

Als ich am 01. September meine Ausbildung bei NETWAYS begonnen habe, bemerkte ich sofort die kollegiale und angenehme Atmosphäre unter den Kollegen. Diese positive Ausstrahlung hält noch bis heute an, dennoch kommt sie nicht von Ungefähr. Viele Events und Abendveranstaltungen werden immer als Team besucht. Um den Zusammenhalt noch weiter zu stärken gab es vom 30.11 – 01.12 die Premiere der ersten „NETWAYS Startupdays“, welche eine teamübergreifende Zusammenarbeit in den Vordergrund stellen soll.
Im Vorfeld wurden zahlreiche Ideen gesammelt und am Donnerstag vom jeweiligen Ideengeber als Pitch vorgestellt:

  • NWS Marketing, neue Unternehmensbroschüre
  • Interner Shop
  • NETWAYS Konferenz Ticket Plattform
  • Control Panel Raspberry PIs, Dashing Container
  • Icinga 2 SNMP Monitoring
  • Chatbot
  • Donation Backend / Platform based on Blockchain

Nach dem Pitch konnte sich jeder Mitarbeiter einem „Ideenteam“ anschließen, dabei war es wichtig, dass sich Teams aus unterschiedlichen Abteilungen bilden um neue, frische Ideen zu generieren. Gleich nach der Teambildung verteilten sich die Arbeitsgruppen im Büro und haben mit der Arbeit begonnen. Was mir sehr gut gefallen hat, war die interdisziplinäre Arbeit zwischen den technischen und nicht technischen Abteilungen. Durch diesen Mix konnten Ideen gefunden werden welche man durch eventuelle festgefahrene Denkweisen nicht generieren hätte können. Zum Mittagessen gab es eine bayerische Spezialität: Weißwurst mit Breze.  Am zweiten Tag wurde engagiert weitergearbeitet, bis es „NETWAYS-typisch“ ein zünftiges Mittagessen gab. Gut gestärkt ging es in die finale Phase und das NETWAYS-Team hat sich im Schulungs- und Trainingszentrum eingefunden um anschließend die ausgearbeiteten Ideen und bis dahin umgesetzten Themen vorzustellen.


 

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...