Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.
 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier
openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'
In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Gitlab | self-hosted vs. Gitlab as a Service

Egal ob GitLab-CE oder GitLab-EE, es stellt sich die Frage, ob self-hosted oder vielleicht sogar als GitLab as a Service (im Folgenden GaaS genannt). Unterschiede gibt es bei diesen beiden Varianten genug. Doch wo sind die gravierendsten Unterschiede in diesen beiden Varianten, was ist das richtige für wen? Diese Fragen möchte in dem folgenden Blogpost beantworten.
 
 

Zeitaufwand

Fangen wir mit dem zeitlichen Aufwand an. Eine GitLab Instanz zu installieren, kann schon einmal etwas Zeit in Anspruch nehmen. Installation, Konfiguration, Wartung, etc, aber auch das Bereitstellen eines Systems (Hardware Server oder VM und eventuell sogar Storage), kann hier mehrere Stunden dauern. Im direkten Vergleich hierzu steht GaaS gehostet in unserem NWS Portal. Nach bestellen einer Gitlab-CE oder GitLab-EE App, dauert es ca 10 Minuten bis alle Funktionen installiert und konfiguriert sind und GitLab einsatzbereit ist.

Umfang

Bei der self-hosted Variante hat man natürlich alle Freiheiten, die ein Administrator der Anwendung haben sollte. Die Instanz kann mit allen gewünschten Features erweitert und somit sehr stark individualisiert werden. Man hat die Auswahl ob man gerne AutoDevOps mit Kubernetes oder GitLab Runner für das Ausführen von Build Jobs haben möchte.
In der GaaS Lösung ist es so, dass hier direkt ein GitLab Runner mit ausgeliefert wird, sodass ohne Verzögerung erste Jobs laufen können. Eine Umstellung auf AutoDevOps ist jedoch auch möglich. Ebenso bringt diese Variante alle standardmäßigen Features mit, die GitLab so haben sollte. Individuelle Features können leider nicht ohne weiteres hinzugefügt werden, da diese durch das NWS Team geprüft, getestet und für alle Kunden zur Verfügung gestellt werden müssen.

Backups

Wer GitLab nutzt möchte natürlich auch Backups seiner Daten und Arbeiten erstellen. GitLab selbst bietet hier die Möglichkeit Backups aller Daten zu erstellen und diese entsprechend auf dem Server zu speichern. Regelmäßiges Warten dieser Backups ist nötig, da diese Backups je nach Größe der Instanz entsprechend Speicherplatz verbrauchen.
NWS bietet hier etwas mehr Komfort, denn um Backups muss sich hier nicht gekümmert werden. Das System erstellt automatisch jede Nacht Snapshots der Apps und auf Wunsch können auch Tagsüber Snapshots erstellt werden, zum Beispiel wenn Änderungen vorgenommen werden sollen und ein zusätzliches Backup gewünscht ist.

Updates

Regelmäßig werden durch GitLab Updates veröffentlicht. Im normalen Zyklus geschieht dies jeden Monat am 22.ten, jedoch werden zwischendrin auch Security Updates oder Bug Fixes veröffentlicht. Als Administrator vertraut man Updates nicht immer und möchte diese vorher Testen, bevor sie in der Produktionsumgebung eingespielt werden. Hier ist ein Testsystem von Nutzen.
In der GaaS Lösung ist dies automatisch der Fall. Nach Veröffentlichung eines Updates wird in verschiedenen Phasen getestet:

  1. Lokales starten der neuen GitLab Instanz
  2. Starten in der Testing Umgebung
  3. Upgrade einer “veralteten” Instanz in der Testing Umgebung
  4. Starten in der Produktionsumgebung
  5. Upgrade einer “veralteten” Instanz in der Produktions Umgebung

Erst wenn diese 5 Phasen durchlaufen sind, werden Wartungsmails verschickt und die neue Version wird für alle Nutzer live genommen.

TLS

TLS ist aus der heutigen Zeit nicht mehr weg zu denken. Zertifikate sind jedoch unter Umständen etwas teurer. GitLab bietet hier jedoch die Möglichkeit, mittels Letsencrypt TLS Zertifikate für die jeweilige Instanz zu generieren. Sowohl in der Self-Hosted Variante als auch bei GaaS ist dies recht einfach. Der Unterschied besteht lediglich darin, dass in der NWS Plattform lediglich ein Haken gesetzt werden muss, um eben diese Verschlüsselung zu aktivieren.

Self-Hosted

sed -i "/letsencrypt\['enable'\] = true/d" /etc/gitlab/gitlab.rb
sed -i "s#^external_url 'https://.*#external_url 'https://$YOUR_DOMAIN'#g" /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure

GaaS

Monitoring

Monitoring ist ebenso ein essenzieller Bestandteil von Produktionsumgebungen. Bei der selbstständig gehosteten Lösung muss sich hier eigenständig darum gekümmert werden. Welches Tool hierzu verwendet wird, bleibt jedem selbst überlassen, wir empfehlen aber Icinga 2.
Mit der GaaS Lösung kommt ein Monitoring automatisch mit. Zwar ist dies für die Kunden nicht einsehbar, jedoch werden alle Funktionen der Instanz durch unser Support Team überwacht.

Fazit

Welche Variante für einen selbst nun die richtige muss jeder für sich entscheiden. Wenn man GitLab selbst hosted, hat man absolute Kontrolle über die Instanz. Backups, Updates, Ressourcen, es kann selbständig über die Dimensionen entschieden werden und man ist etwas flexibler als in der GaaS Lösung. Jedoch ist in eben dieser der Vorteil, dass Backups, Updates, sowie Konfiguration und Support von den Mitarbeitern von NWS übernommen werden. GitLab kann in NWS 30 Tage kostenlos getestet werden, probiert es also einfach mal aus – testen

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

NWS | Neuerungen und Updates

Die letzten Wochen hat sich auf unserer NWS Plattform sehr viel getan. Wir möchten uns an dieser Stelle auch bei unseren Nutzern bedanken, die Verbesserungsvorschläge der Apps an uns reported haben. Aufgrund dieser Aussagen ist es uns möglich, uns und NWS selbst stetig zu verbessern und so schließlich auch das Erlebnis der User zu verbessern! Im Folgenden möchte ich etwas darauf eingehen, welche Neuerungen die letzten Wochen vorgenommen wurden.
Migration der NWS Plattform auf OpenStack
Ein sehr großer Teil, wenn nicht sogar der größte Teil, war die Migration unserer Server auf das neue OpenStack Setup an unserem neuem RZ-Standort. Neue Server, neue Technologie und ein neues Rechenzentrum. All das ermöglicht uns eine Performance-Steigerung der Produkte sowie unserer Anwendung selbst. Es wurde hier eine komplett neue Umgebung aufgebaut, auf der nun auch NWS läuft. Die alte Umgebung wurde komplett abgeschaltet.

Gitlab-CE / Gitlab-EE

Natürlich haben wir auch Updates eingespielt. Gitlab-CE sowie Gitlab-EE wurde auf die Version 11.0.4 angehoben. Diese Version bringt AutoDevOps mit sich und diverse andere Neuerungen.

Icinga2 Satellite

Unsere Satelliten wurden auf die aktuelle Icinga2 Version angehoben, welche aktuell die 2.9.0-1 ist.

Icinga2 Master

Die Master App wurde ebenso auf die 2.9.0-1 angehoben. Wir haben hier auch das eingesetzte Grafana aktualisiert auf die Version 5, welches ein komplett neues Interface mit sich bringt. Ein Update für das neue icinga2-Web steht noch aus!

SuiteCRM

Die Version von SuiteCRM selbst, welche bisher bei NWS im Einsatz war, hatte leider einige wenige Bugs. Diese konnten wir mit der neuen Version 7.10.7 beheben und so die Produktivität der App verbessern. Wir haben hier auch kleinere Änderungen am Aufbau und Konfiguration der Container vorgenommen, welche die Start-Zeit enorm verkürzt haben. Hierzu beigetragen haben auch die Ressourcen, wovon wir den Containern mehr zuteilen.

Rocket.Chat

Rocket.Chat wurde mit der Version 0.66.3 auf die aktuellste verfügbare Version erhöht. Wir haben hier auch den Begrüßungstext, der in der Instanz angezeigt wird durch ein kleines “HowTo” ersetzt, um einen leichteren Einstieg in diese App zu ermöglichen.

WordPress

Auch WordPress wurde mit einem Update versehen. Wir haben hier die Version 4.9.7 aktiviert. Diese Version ist ebenso wie 4.9.6 DSGVO konform.

Nextcloud Verbesserungen

Wir haben einige Reports bekommen, dass die Performance unserer Nextcloud App noch verbesserungsfähig ist. Wir haben aufgrund dieser, gewisse Verhalten nachstellen können und konnten so die dafür verantwortlichen Fehler finden und beheben. Unsere Arbeiten resultierten in einer wesentlichen Performance-Steigerung der App, vor allem im Bereich der Dokumente, der Foto Galerie, sowie des Logins.

Diverse Fehlerbehebungen / Verbesserungen

Wie oben bereits erwähnt, haben wir unter anderem durch die Reports unserer Nutzer Fehlerstellen gefunden und konnte diese beheben. Daraus resultierend hat sich die Start-Zeit der Apps verkürzt, was wir auch bei den Restarts und bei den Updates beobachten konnten. Dies erleichtert uns natürlich die Wartungsarbeiten aber auch die Downtimes für unsere Nutzer, sofern ein Restart einmal nötig sein sollte. Wir haben ebenso falsche/hängende Flows gefunden, welche bisher dafür gesorgt haben, dass Container innerhalb eines Setups gelegentlich die Connection zueinander verlieren konnten. Dieser Fehler wurde behoben und tritt derzeit nicht mehr auf. Wir sind stets dabei weitere Verbesserungen vorzunehmen und Neuerungen zu testen. Um hier Up-to-date zu bleiben, kann ich unseren Twitter Account empfehlen. Hier werden alle Updates regelmäßig veröffentlicht!

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Anpassungen der Nextcloud Login Seite werden nicht geladen

Wie uns bei den NWS Apps aufgefallen ist, gibt es aktuell in der Nextcloud Version 13.0.1 den Bug, dass Anpassungen an der Login Seite nicht aktualisiert werden. Das Problem ist hier wohl der “Image Cache“, der nicht aktualisiert wird.
Es werden verschiedene Möglichkeiten geschildert, dieses Problem zu umgehen, beziehungsweise zu beheben. Zwei dieser Wege werden im folgenden beschrieben:
 

1) Installation von “Unsplash”
  • Gewünschte Anpassungen vornehmen
  • Installation der “Unsplash” App
  • Deaktivierung dieser App im Anschluss
2) Image Cache manuell aktualisieren

Eine weitere Möglichkeit ist den Image Cache manuell zu updaten. Dies funktioniert jedoch nicht in allen Fällen.

sudo -u www-data php occ maintenance:theme:update

Dieses Problem gab es in früheren Version schon einmal. Der Bug sollte in künftigen Versionen behoben sein.
Hier ein paar links zu diesem Thema:

 
 

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Running Icinga in NWS with Slack notifications

Slack notifications through Icinga2. This is what we activated last week for our Icinga2 Master apps on our NWS platform! The feature came highly recommended, so we decided to give it a try. And we did. It really is awesome!!
First of all, I want to show you how it will look like on your side, so have a look at the small demo-video!


 
To work with this feature, all you need is a Slack workspace and a chatroom for your alerts. once you are done with configuration part, just follow the 7 steps below.

  1. Go to Configuration/Commands in your Icinga2 app
  2. Open command-slack-host/command-slack-service and open the drop-down Custom properties
  3. Fill in the slack_channel you want to use
  4. Fill in the slack_webhook_url (You can get your webhook url from your Slack-account settings)
  5. Create a new user in Configuration/User and add user to the two groups for Slack-Message on critical hosts/services. Also give user the user template user-template in Imports
  6. Add the states you want to receive as a notifications for to the Configuration / User/Contacts / User-template / modify / State and transition type filtersfield
  7. Deploy your changes in the Configuration/Deployments

If you have ideas for more features for our apps, just contact us via email, twitter, facebook or our NWS chat!
 

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

NETWAYS Web Services: WordPress now up and running!

We are proud to announce a new app hosted in our NWS platform! WordPress is now available!
“Simply for everyone – Perfect for everyone who wants to create individual content. Simple and safe.”
Just as our slogan for this app tells you, we decided to create an app for our users, which can be used by anybody. An app, which is ready to use, easy to configure and practically for almost everyone, without writing code or configuring credentials etc.
We built up an automated migration program, so you can migrate your existing WordPress instance to our platform, no matter which version you are running. We also decided to give the users the opportunity to restore their website by their self and to manage their website without the need of one of our WordPress experts.
The WordPress app includes our S3 compatible replication-based and distributed storage.
All in all it will bring you the following enhanced functions to your cloud:

  • Automated Updates
  • Easy migration
  • Super fast assests delivery via S3
  • Full domain freedom / No domain needed
  • Free CNAME
  • It is available immediately
  • Automated Backups, which are stored for 24 hours
  • Preinstalled plugins and themes
  • Access to DocRoot / Backup via WebDAV

Give it a try! If you are new to our platform, you can use it 30 days for free. The app is of course monthly callable but we think you will like it!
 

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

Gitlab now supports Let's Encrypt


Since last week our Gitlab-ce and Gitlab-ee instances are able to use Let’s Encrypt for SSL encryption. As an owner of one of our instances, you are able to use Let’s Encrypt simply by activating it in your product view on our NWS platform.
With this, you can now use your own domain, without the need of an existing SSL-certificate. If you already have a SSL-certificate active and want to test Let’s Encrypt, you can do so. Your active certificate will be stored and will be activated again, as soon as you deactivate the SSL encryption with Let’s Encrypt.
In the screenshot below, you can see an example of how it looks in the product view. Activation and deactivation will always require a restart of your instances, since these are major configurations changes to your container.

If you are interested in one of our instances, just have a look on nws.netways.de! We have many more open-source apps available, such as Rocket.Chat, RT or Nextcloud and are currently working on some new features/apps.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

MariaDB Upgrade von 10.0.x auf 10.2.x in 10 einfachen Schritten

Ein Upgrade von verschiedenster Software ist von Zeit zu Zeit nötig. So auch von MariaDB. Der Folgende Blogpost ist ein Leitfaden für ein normales Upgrade.
Wenn man noch MariaDB 10.0.x im Einsatz hat und möchte nun auf 10.2.x ist dies in der Regel kein Problem. Es gibt jedoch ein paar wenige Punkte auf die man dabei achten sollte.


  • Ab MariaDB 10.1.x  können unter “/etc/mysql/conf.d” keine speziellen Parameter mehr für Multi-Instanzen angeben werden. Hier wurden in der Vergangenheit beispielsweise Parameter gespeichert, die man mit einem Config-Management Tool verwaltet hat und man nicht wollte, dass mehrere Server die gleichen Parameter bekommen. Bei manchen Setups kann dies etwas aufwendig werden, aber es gibt keinen Weg drum herum.
  • ich empfehle vorher auf jeden Fall ein Backup der Konfigurationsdateien und der Datenbanken anzufertigen.
  • Unbedingt erst die Slaves upgraden, dann die Master. Denn:
    Master MariaDB 10.0.x <=> Slave MariaDB 10.2.x funktioniert
    Master MariaDB 10.2.x <=> Slave MariaDB 10.0.x funktioniert nicht 
  • Es haben sich zwischen den Versionen verschiedene Default Parameter der DBs geändert. Es sollten also auch die Changelogs für die jeweils wichtigsten Parameter geprüft werden.

Sofern oben genannte Punkte berücksichtigt wurden, kann das eigentliche Upgrade vorbereitet werden. Als Zwischenschritt, empfehle ich MariaDB 10.1.x zu installieren, um eventuell anfallende Abhängigkeiten mitzunehmen:

  1. Parameter aus /etc/mysql/conf.d anpassen
    Wichtig dabei, auch die Instanznummerierungen [mysqldX] auszukommentieren 

    #[mysqld1]
    # * Basic Settings
    #read_only = 1
    #[mysqld2]
    # * Basic Settings
    #read_only = 1
  2. Datenbank Instanz(en) stoppen
    Mutli-Instanzen stoppen mit:

    mysqld_multi stop X
  3. Pins aus /etc/apt/preferences.d/mariadb.pref entfernen (oder die Datei löschen)
    rm /etc/apt/preferences.d/mariadb.pref
  4. Upgrade vorbereiten
    /etc/apt/sources.list.d/mariadb.list

    deb http://mirror2.hs-esslingen.de/mariadb/repo/10.1/ubuntu xenial main
    deb-src http://mirror2.hs-esslingen.de/mariadb/repo/10.1/ubuntu xenial main
  5. Upgrade durchführen
    Allgemein:

    apt-get update && apt-get upgrade

    mariadb-server upgraden

    apt-get upgrade mariadb-server
  6. Das gleiche nun nochmal mit der Version 10.2.x
    /etc/apt/sources.list.d/mariadb.list

    deb http://mirror2.hs-esslingen.de/mariadb/repo/10.2/ubuntu xenial main
    deb-src http://mirror2.hs-esslingen.de/mariadb/repo/10.2/ubuntu xenial main
  7. Upgrade dürchführen
    Allgemein:

    apt-get update && apt-get upgrade

    mariadb-server upgraden

    apt-get upgrade mariadb-server mysql-common
  8. Die Instanz(en) nun wieder anstarten
    Multi Instanzen werden gestartet mit:

    mysqld_multi start X
  9. Datenbank Upgrade durchführen
    Für eine Instanz: 

    mysql_upgrade

    Für multi-Instanzen:

    for sock in /var/run/mysqld/mysqld_33*.sock ; do mysql_upgrade -S $sock ; done
  10. Aufräumen
    dpkg -l | grep maria

    Hier kann alles entfernt werden, was mit “rc” gekennzeichnet ist. 

    apt-get purge $alte-mariadb-versionen && apt-get autoremove

 
Nun sollten die Instanzen alle mit der aktuellen MariaDB 10.2.x laufen. Dieser Artikel ist nur ein Vorschlag, wie das Upgrade durchgeführt werden kann. Letztendlich kann es sein, dass in Einzelfällen noch Pakete nachinstalliert werden müssen. Ein mir bekannter Kandidat ist zum Beispiel: libmariadb3

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

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
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

VM Volumes live anpassen mittels blkdeviotune

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
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...