Der Consultant und die lieben Zertifizierungen II

RHCA
Vielleicht erinnert sich noch jemand an meinen Blogpost bezüglich Zertifizierungen in dem ich angekündigt hatte auch noch den Performance-Tuning-Kurs bei Red Hat besuchen zu wollen. Nach einigem Hin und Her bei der Terminfindung durfte ich diesen nun endlich besuchen. Nach 4 Tagen Kurs die sich um Performance-Tuning und dem Sammeln der notwendigen Daten allgemein, den Tuning-Daemon tuned und das Tuning für verschiedene Workloads drehten, stand auch wieder eine Prüfung für das “Certificate of Expertise” an. Allein das Ziel dieses zu erlangen sorgte dafür, dass die 4 Tage Schulung jeweils aus mehr als 8 Stunden “Unterricht” und 2 Stunden “Nachlernen” bestanden. So tief hatte ich mich schließlich noch nie mit verschiedensten Kernelparametern, ihrer Auswirkung und den Berechnungen dahinter beschäftigt. Um nur ein Beispiel herauszupicken sei hier das Bandwidth delay product (BDP) mit dem so einiges aus den Verbindungen herauszuholen war. Natürlich kann aus einem optimal konfigurierten System nicht mehr viel herausgeholt werden, man spricht von 3-5%, aber das Wissen hilft auch erstmal diesen optimalen Zustand zu erreichen.

Vollgestopft mit diesem Wissen und trotzdem gefühlt vollkommen blank saß ich dann am Freitag in der Prüfung. Wie bei Red Hat üblich war dies eine praktische Prüfung am System. Das heißt man hat einem Pflichtenheft nicht unähnliche Aufgaben, die gelöst werden wollen. Im Gegensatz zu den bisher abgelegten Zertifizierungen hat diese auch viele “theoretische” Aufgaben bei denen Werte, Daten oder Zeiten ermittelt werden müssen, gerade bei diesen tut man sich schwer, wenn man sonst gewohnheitsmäßig ein anderes Werkzeug nutzt. Wer mein 4-stündiges emotionales Auf und Ab während der Prüfung beobachten konnte hatte sicher seine Freude, nach dem ersten Neustart und der Feststellung was nicht funktionierte wie gedacht war ich mir dann auch sicher nicht bestanden zu haben. Doch bereits wenige Stunden später kam das Prüfungsergebnis aus den USA und ich hatte genauso bestanden wie die beiden anderen Teilnehmer.

Zusätzlich zu dem Prüfungsergebnis kam überraschenderweise auch noch eine Mail, die mir zum Erlangen des Titels “Red Hat Certified Architect” gratulierte. Zwar wusste ich dass es mein fünftes “Certificate of Expertise” ist, aber ich hatte die Umstrukturierung so verstanden, dass man mittlerweile 5 bestimmte für die jeweilige Spezialisierung des RHCA wie beispielsweise “Datacenter” oder “Cloud” benötigt. Auch wenn ich überrascht war, freue ich mich nun zu den RHCAs zählen zu dürfen, denn dahinter steckt nicht nur viel erworbenes Wissen sondern auch viel aufgewendete Zeit. Ein Wissen, dass ich gerne an unsere Auszubildenden weitergeben und für unsere Kunden einsetze.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

Vom Noob-OS zum IPv4-Router

Dass man die Docker-Alternative LXD ohne große Hürden auch auf Mac OS X betreiben kann, habe ich in meinem letzten Blog-Post bereits detailliert erläutert.

Leider kann ich im Rahmen meiner Arbeit nicht alles in diesen Ubuntu-Containern betreiben. Die Entwicklungsumgebungen für so manche Anwendungen wie z. B. Icinga Web 2 werden mit Vagrant provisioniert und dieses Programm lässt sich nur sehr mühsam an LXD koppeln. Deshalb komme ich nur mit der einen LXD-VM wohl oder übel nicht aus.

Spätestens wenn die anderen VMs (oder deren Container) mit den LXD-Containern kommunizieren müssen, stößt dieses Setup an seine Grenzen… oder?

Das Setup im Detail

Wie auch jeder andere Gewerbebetrieb, in dem keine Schreibmaschinen mehr zum Einsatz kommen, verfügt NETWAYS über ein internes IP-Netz – beispielhaft mit den Host-Adressen 192.0.2.1 – 192.0.2.14. Der Router zum Internet beansprucht für sich die 192.0.2.1 und meinem Arbeitsgerät ist die 192.0.2.2 zugeteilt.

Um mit meinen virtuellen Maschinen kommunizieren zu können, teilt meine Workstation sich ein IP-Netz mit ihnen (192.0.2.17 – 192.0.2.30). Und schließlich sollen auch meine LXD-Container nicht so isoliert sein wie ein Schreibmaschinen-Nutzer – deshalb teilen sie sich ein wieder anderes IP-Netz (192.0.2.33 – 192.0.2.46) mit der LXD-VM.

Wenn nun ein Knoten einen anderen ansprechen will, muss er entweder im selben IP-Netz sein wie der gewünschte Gesprächspartner – oder in der Netz-Hierarchie unter einem Router stehen, der den gewünschten Gesprächspartner erreichen kann.

Beispiel #1

LXD-Container #1 will mit 192.0.2.50 kommunizieren, ist aber nicht im selben Netz. Ihm bleibt nichts anderes, als über sein Standard-Gateway, 192.0.2.33, zu senden und zu hoffen, dass die Verbindung erfolgreich zustande kommt. Die LXD-VM ist aber auch nicht im selben Netz. Daher muss sie sich wiederum auf ihren Standard-Gateway (192.0.2.17) verlassen. Meine Workstation delegiert wiederum an 192.0.2.1 usw.. Und wenn da draußen tatsächlich eine 192.0.2.50 online ist (und alle Internet-Router so rund laufen wie unser Firmen-Gateway) kommt letztendlich die Verbindung erfolgreich zustande.

Beispiel #2

VM #1 will mit 192.0.2.34 kommunizieren, ist aber nicht im selben Netz. Ihr bleibt nichts anderes, als an ihr Standard-Gateway, 192.0.2.17, zu delegieren. Leider weiß Mac OS nichts vom Netz 192.0.2.32/28 und delegiert an unser Firmen-Gateway. Das und alles dahinter kann noch so rund laufen, aber der Zug in Richtung des LXD-Container-Netzes ist längst abgefahren.

Aber ich würde nicht schon gut 3,5 Jahre bei NETWAYS arbeiten wenn ich diese Hürde nicht spielend einfach überwinden könnte. Dazu braucht es nur…

Statische Routen auf Mac OS X

Natürlich könnte ich auch auf jeder VM eine statische Route hinterlegen, aber das wäre zusätzlicher Aufwand bei jeder VM-Erstellung. Sollte darüber hinaus die Anzahl der VMs mit Linux-Containern zunehmen, steigt damit auch mein Aufwand beim Routen-Management nicht zu knapp…

Deshalb ist es langfristig so oder so sinnvoller, alle VMs an die Workstation delegieren zu lassen und diese zum Router zu befördern. Wie praktisch, dass Mac OS X auf 4.4BSD basiert und damit zur *nix-Familie gehört. Damit ist dieses Vorhaben ein Kinderspiel (wenn man weiß wie es geht).

Jetzt aber endlich mal Butter bei die Fische

Schritt 1: Konzentration!

Um Mac OS die gewünschten statischen Routen beizubringen, muss man tiefer ins System eingreifen, als es ein durchschnittlicher Mac-Nutzer es gewohnt ist. Dabei lässt sich mit ein bisschen Schusseligkeit sehr viel kaputt machen. Wenn Du gerade z. B. eine ordentliche Portion G&T konsumiert hast… habe Geduld. Morgen ist auch noch ein Tag und Mac OS läuft schon nicht weg.

Schritt 2: Root-Rechte

Obwohl Mac OS sich an weniger versierte Nutzer richtet, bietet es die Möglichkeit, Root-Rechte zu erlangen wie man das von verbreiteten GNU/Linux-Distributionen kennt:

Alexanders-MacBook-Pro:~ aklimov$ sudo -i
Password:
Alexanders-MacBook-Pro:~ root#

Schritt 3: Hilfs-Skripte

Die eben erlangten Privilegien berechtigen uns, Skripte in dem OS vorbehaltene Verzeichnisse zu platzieren – wovon wir auch Gebrauch machen, indem wir zunächst das Verzeichnis /usr/local/sbin erstellen und darin zwei Skripte ablegen:

Alexanders-MacBook-Pro:~ root# mkdir -p /usr/local/sbin
Alexanders-MacBook-Pro:~ root# vim /usr/local/sbin/add-static-route.pl
Alexanders-MacBook-Pro:~ root# chmod 0755 /usr/local/sbin/add-static-route.pl
Alexanders-MacBook-Pro:~ root# vim /usr/local/sbin/add-static-routes.sh
Alexanders-MacBook-Pro:~ root# chmod 0755 /usr/local/sbin/add-static-routes.sh

Das erste Skript, /usr/local/sbin/add-static-route.pl, dient dem Hinzufügen von statischen Routen, sobald die entsprechende Netzwerk-Schnittstelle online ist:

#!/usr/bin/perl

# (C) 2017 NETWAYS GmbH | GPLv2+
# Author: Alexander A. Klimov

my $destination = shift;
my $gateway = shift;

if (!(defined($destination) && defined($gateway))) {
    exit 2 # RTFM at https://wp.me/pgR2o-rlj
}


my $gatewayDec = ip4_2dec($gateway);

POLL: for (;;) {
    for (`/sbin/ifconfig`) {
        if (/^\tinet (.+?) netmask (.+?) /) {
            my $mask = hex($2);
            if (($gatewayDec & $mask) == (ip4_2dec($1) & $mask)) {
                my $status = system("/sbin/route", "add", "-net", $destination, $gateway) >> 8;
                die "/sbin/route: $status" if ($status != 0);
                last POLL
            }
        }
    }

    sleep 1
}


sub ip4_2dec
{
    hex(join("", map({ sprintf("%02x", $_) } split(/\./, shift()))))
}

Das zweite Skript, /usr/local/sbin/add-static-routes.sh, ruft das erste Skript auf und fügt damit konkrete Routen hinzu:

#!/bin/bash

set -e
set -o pipefail

/usr/local/sbin/add-static-route.pl 192.0.2.32/28 192.0.2.18

Die Kommandozeilen-Schnittstelle des ersten Skripts habe ich extra so gestaltet, dass die Routen-Liste (das zweite Skript) möglichst einfach erweitert werden kann. Wenn bspw. eine zweite LXD-VM mit der IP-Adresse 192.0.2.21 dazukommt und mit ihren Containern über das Netz 192.0.2.64/28 verbunden ist, gehört folgende Zeile ans Ende der Routen-Liste:

/usr/local/sbin/add-static-route.pl 192.0.2.64/28 192.0.2.21

Schritt 4: Autostart

Damit das zweite Skript nicht bei jedem Systemstart manuell ausgeführt werden muss, lassen wir Mac OS es für uns automatisch starten:

Alexanders-MacBook-Pro:~ root# pushd /Library/LaunchDaemons
/Library/LaunchDaemons ~
Alexanders-MacBook-Pro:LaunchDaemons root# vim mystaticroutes.plist
Alexanders-MacBook-Pro:LaunchDaemons root# launchctl load mystaticroutes.plist

Inhalt von mystaticroutes.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>MyStaticRoutes</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/local/sbin/add-static-routes.sh</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Fazit

Obwohl mich die Kollegen aus den eigenen Reihen – aber auch aus NMS und PS – spätestens seit diesem Blogeintrag mit besorgten Blicken überschütten, werde ich einfach nicht müde, das Noob-OS von Apple auf biegen und brechen meinen seltsamen Bedürfnissen entsprechend aufzubohren.

Abonniert gerne kostenlos diesen Blog um auch über die nächste Runde informiert zu werden – wenn ich den abgebissenen Apfel bis auf den Kern schäle…

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren – tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Shopware Update

Jeder nutzt für seine Dienste die verschiedensten Tools. Wir bei NETWAYS kümmern uns im Hosting Bereich für Sie um eben diese Dienste und Tools, sodass Sie als User sich damit nicht beschäftigen müssen.
In diesem Rahmen betreuen wir auch Shopware Installationen unserer Kunden.
Jedoch wollen derartige Dienste auch Updates um aktuell zu bleiben. Ein Shopware Update ist meist nichts großes. Dennoch gibt es hier auch nicht nur eine Variante, wie diese am besten durchzuführen sind. Die Variante die für mich die “beste” ist, möchte ich hier kurz vorstellen.


Schritt 1

Zunächst benötigt man das Paket des jeweiligen Updates. Diese können hier heruntergeladen werden. Im Anschluss kurz entpacken und schon kann es los gehen. Wichtig hierbei ist, dass die Dateien des Updates, die Dateien der Shopware Installation überschreiben.

Deswegen: Ein Backup rettet manchmal jeden Admin! Dies gilt auch für die DB, da diese ebenfalls bearbeitet wird.

Schritt 2
Das Update einspielen.

root@shopware:/tmp# cp -a -R /tmp/update_5/update_5/* /var/www/shopware_directory

Schritt 3
Im Endeffekt war es das auch schon. Unter http://shopware-test.meinedomain.com/recovery/update kann nun das Update gestartet werden. Hier passiert bis auf einige wenige Klicks alles automatisch. Nach dem erfolgreichen Update, muss noch ein Ordner gelöscht werden, sodass das System wieder freigegeben wird.

root@shopware:/var/www/shopware_directory# rm -rf /update-assets

Nun sind keine weiteren Schritte mehr nötig. Auf Fehlermeldungen muss natürlich individuell eingegangen werden. Sollten Sie hierbei auf Probleme stoßen oder möchten ebenfalls eine Umgebung aufbauen, können Sie gerne Kontakt zu uns aufnehmen.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten.
Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Revisited – Graphite-Web installation unter Debian 9

Erstmal wieso Revisited ?

Dies ist ein update meines älteren Blog Posts Blogpost 2016 welcher darauf einging das unter Debian 8.4 graphite-web wegen eines Fehlenden Eintrages in der Apache 2.4 Konfiguration nicht korrekt gestartet/aufgerufen werden konnte.
Es ist schon einige Zeit ins Land gegangen und ich habe weniger ein Auge darauf geworfen ob das weiterhin so Funktioniert.
Deshalb Revisited.

Here we Go again !

Ich gehe in diesem Fall von einer Debian Version der Nummer 9 aus und werde wie bei dem alten Blogpost. In der Grundannahme mal davon ausgehen das alles Funktioniert wie es soll:

Also hier die folgenden installationschritte:

#> apt-get install apache2 libapache2-mod-wsgi python-django python-django-tagging fontconfig python-tz python-pip python-dev python-twisted python-cairo
#> pip install carbon whisper graphite-web
#> pip install --upgrade twisted
#> cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf
#> cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf
#> /opt/graphite/bin/carbon-cache.py start
#> /opt/graphite/bin/carbon-cache.py status
#> cp /opt/graphite/examples/example-graphite-vhost.conf /etc/apache2/sites-available/graphite.conf
#> cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi
#> cp /opt/graphite/webapp/graphite/local_settings.py.example \ /opt/graphite/webapp/graphite/local_settings.py
#> python /opt/graphite/webapp/graphite/manage.py syncdb
#> chown www-data. -R /opt/graphite/storage
#> a2dissite 000-default
#> a2ensite graphite
#> a2enmod wsgi
#> service apache2 restart
#> chmod +x /etc/init.d/carbon-cache // Damit 'carbon-cache.py start' mit Systemstart erfolgt

Ergebnis davon ist -> Nichts funktioniert.

Back to the Roots

Ab hier kommt der Weg graphite-web auf einem Debian 9 (Stretch) in Betrieb zu nehmen.

Ausgangspunkt ist ein frisch installiertes Debian 9.

#> apt-get install vim -y
#> vim /etc/apt/sources.list

Wir müssen die Sources auf die Jessie Repositories setzen da zum Zeitpunkt dieses Blogposts die graphite-web Pakete nicht abrufbar sind.

Daher fügen wir folgendes hinzu in der sources.list
deb http://httpredir.debian.org/debian jessie main
Gefolgt von einem frischem #> apt-get update -y .

Nun installieren wir den großteil der Pakete welche wir benötigen.
#> apt-get install graphite-web graphite-carbon mysql-server python-mysqldb python-pymysql apache2 libapache2-mod-wsgi apt-transport-https ssl-cert python-pip -y

Es folgen ca. 300MB an Daten.
Daraufhin stürzen wir uns direkt auf die Konfig.

Wir fangen an folgende Datei zu editieren.
#> vim /etc/graphite/local_settings.py
Darin ändern wir folgende Settings Sinnvoll in etwas was wir für unsere Installation benötigen.

Also SECRET_KEY, TIME_ZONE & ALLOWED_HOSTS setzen.

Danach muss in der folgenden Datei ein “true” gesetzt werden damit graphite & carbon gemeinsam starten.

#> vim /etc/default/graphite-carbon

Nun kommt der trickreichste Part wir sind leider dazu genötigt eine alte django Version zu installieren.

#> pip install "django==1.4"

Damit haben wir die Grundlage womit wir das folgende Kommando erfolgreich absetzen können.

#> graphite-manage syncdb
#> chown _graphite. /var/lib/graphite/graphite.db
HINWEIS ! Dies setzt erst mal die voreingestellte sqlitedb in Gang.
Wenn eine andere DB verwendet werden soll dann sollte dies bitte in der “local_settings.py” vorgenommen werden.

Wir sind fast am Ziel ein funktionierendes graphite-web zu haben.
Es fehlt nur etwas Apache2 Magie.

#>a2dissite 000-default.conf
#>cp /usr/share/graphite-web/apache2-graphite.conf /etc/apache2/sites-available/
#> a2ensite apache2-graphite.conf
#> systemctl restart apache2

Voilà !

Es sollte nun auf dem Host System das graphite-web aufrufbar sein.

Danke für die Aufmerksamkeit !

David Okon

Autor: David Okon

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 glücklichen Menschen zu machen.

Monthly Snap August > GitHub, Icinga 2, OSBConf, OSMC, Mac, Cloud Management, SSH, Braintower, Foreman

In August, Johannes Meyer began with an overview of some future Github topics and Lennart continued with part 6 of Icinga 2 Best Practice.
Julia said thank you to our OSBConf Sponsors, while Georg wrote not one, not two, but three articles on simplifying SSL certificates!
Then Alex shared his happiness to be a Mac user now and Dirk reviewed the Foreman Birthday Bash!
On events, Julia announced the program for the Open Source Monitoring Conference, continued with the second reason to join the OSBConf and started the OSMC blog series “Stay tuned!”.
Later in August, Isabel presented the ConiuGo Modem and showed the advantages of the Braintower SMS Gateway.
Towards the end of August, Enrico started a blog series on Cloud Management and Gunnar told us about SSH authentication with GnuPG and smart cards.

Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über’s Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.

VM Volumes live anpassen mittels blkdeviotune

This entry is part 2 of 2 in the series Cloud Management

Wir bei NETWAYS setzen für das erstellen von VMs bestimmte Templates ein. In diesen Templates sind alle möglichen Konfigurationen hinterlegt. Unter anderem auch für die VM Volumes. Doch nicht immer passen diese Konfigurationen und so sind einzelne Anpassungen an der laufenden VM nötig. Mittels “blkdeviotune” ist man als Admin in der Lage, live die Volume-Daten der VMs zu bearbeiten.
Hierzu begibt man sich mittels “virsh” in das dazugehörige Terminal.

root@virt-system:~# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # list
Id Name State
----------------------------------------------------
01 one-1000 running
02 one-1001 running
03 one-1002 running
04 one-1003 running

In diesem Terminal hat man verschiedene Parameter die man anpassen kann. Welche verfügbar sind, kann man wie folgt anzeigen lassen. Hierbei wird die ID aus obigen Kommando benötigt:

virsh # blkdeviotune 02 vda
total_bytes_sec: 62914560
read_bytes_sec : 0
write_bytes_sec: 0
total_iops_sec : 500
read_iops_sec : 0
write_iops_sec : 0

Folglich ist hier die Möglichkeit gegeben, oben genannte Parameter anzupassen. Ob man hier nun die Limitierungen der IOPs und die “Bytes per second” bezüglich “read” und “write” unterscheidet, oder ob man einen totalen Wert angibt, bleibt jedem Admin selbst überlassen. In diesem Beispiel hat die VM mit der OpenNebula ID “one-1001” Limitierungen auf die Parameter “total_bytes_sec” und “total_iops_sec“. Die anderen Werte sind hier unlimitiert, jedoch werden sie durch den übergeordneten Parameter beschränkt. Wenn man die Werte nun entsprechend seiner Wünsche anpassen möchte, ist es wie im folgenden Beispiel wichtig, alle Werte mit anzugeben, auch wenn sie nicht verändert werden sollen. Als Beispiel wird hier nun der Parameter “total_bytes_sec” auf 0 zurück gesetzt und einzelne Limitierungen für die Werte “read_bytes_sec” und “write_bytes_sec” gesetzt. Ebenso werden die maximal zulässigen IOPs erhöht.

virsh # blkdeviotune 02 vda 0 31457280 31457280 1000 0 0
virsh # blkdeviotune 02 vda
total_bytes_sec: 0
read_bytes_sec : 31457280
write_bytes_sec: 31457280
total_iops_sec : 1000
read_iops_sec : 0
write_iops_sec : 0

Derartige Änderungen können live geschehen und benötigen keine weiteren Aktionen innerhalb der VMs. Wir bei NETWAYS reagieren so zum Beispiel auf temporäre Mehrauslastungen einzelner VMs.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten.
Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz