Monthly Snap February 2020

Monthly Snap February 2020

Start with a laugh!

In the beginning of the month Nicole asked some of us what we found the most annoying aspect of working in an office. Not at all surprising was the most common answer: the printers! Yes, sometimes they seemingly do as they please! Read Nicole`s humorous blog on aggression at work! [Eine nicht ganz ernste] Betrachtung von Aggression am Arbeitsplatz.

 

Christians news

What`s new in Graylog`s latest release? Christian filled us in in Graylog 3.2 – Jetzt verfügbar. What else was Christian up to? Well, as a matter of fact, he developed Icinga Monitoring for Windows! Read all about it in Icinga for Windows 1.0 – Eine neue Ära.

 

The Shops` corner

Isabel let us know that STARFACE has expanded their product-range for smaller companies in STARFACE erweitert den Compact Bereich. Why is this SMSEagle so popular? Nicole gave us several reasons in Wieder verfügbar! SMSEagle MHD-8100 – 8 Modems für parallelen SMS Versand. She also gave us loads of information about the SMSEagle, including a video of the unboxing! Unboxing a Beauty – SMSEagle MHD-8100.

 

Techie tipps…

Dirk attended the Configmgmt Camp for the fifth time in a row. What was new in Gent this year? Config Management Camp Ghent 2020 – Recap. Thilo shared some insider tricks in Ansible – should I use omit filter? Blerim gave us tips on photo sizes and meta tags for social media in Quick Tip: Vorschaubilder in sozialen Medien.

 

Upcoming events

Julia shared some news in Deploy Peanutbutter:Jelly or: First stackconf speakers online! And Julia also let us in on why it is perfect to Sponsor stackconf 2020.  Join us in Amsterdam in June! But first: listen to Julia and Get your Early Bird Tickets for IcingaConf! And then listen to her some more: The call for papers for the OSCamp on Bareos is still open! OSCamp on Bareos: Let’s talk about backups!

#lifeatnetways

NETWAYS goes Business Cup 2020! Niko is looking forward to taking part with the NETWAYS-team and informs about this and other sports- events we will attend this year! Read about Aleksander in our blog-series NETWAYS stellt sich vor, where new members of the NETWAYS-family share a bit about themselves. How much can a company do for the environment? A group of colleagues worked on the subject and Catharina concluded with Umweltschutz a la NETWAYS.

 

Exclusion of NPD and AfD supporters from our events

The most important blog of the month was written by our very own CEO Bernd. He has changed our code of conduct to puplicly announce that we do not tolerate racism and that therefore no members or sympathizers of the AFD or NPD are welcome to any of our events. He informed the NETWAYS team in our annual meeting, and immediately got a roaring applause

Catharina Celikel
Catharina Celikel
Office Manager

Catharina unterstützt seit März 2016 unsere Abteilung Finance & Administration. Die gebürtige Norwegerin ist Fremdsprachenkorrespondentin für Englisch. Als Office Manager kümmert sie sich deshalb nicht nur um das Tagesgeschäft sondern übernimmt nebenbei zusätzlich einen Großteil der Übersetzungen. Privat ist der bekennende Bücherwurm am liebsten mit dem Fahrrad unterwegs.

OSCamp on Bareos: Let’s talk about backups!

Heterogeneous server landscapes are more the rule than the exception in many companies today. The technical requirements for software systems for data backup, archiving and recovery are increasing accordingly. What are the challenges coming with these changes? Let’s talk about it!

Let’s talk about backups at OSCamp!

CFP until end of march

The Call for Papers for the Open Source Camp (OSCamp) on Bareos is still open. Until March 31, 2020 you got the chance to submit your paper. Ideally you give a comprehensive technical insight into Bareos and offer administrators new impulses for data backup, archiving and recovery. Each presentation is scheduled for 45 minutes, including a 5 to 10-minute Q&A session. All software presented must be freely available for download and therefore meet open source standards such as GPL.

OSCamp – the series

The OSCamp on Bareos is where the community, users and developers meet – it’s an opportunity to talk to like-minded people and share expertise – as a speaker on stage, or as attendee during discussions and breaks.

Open Source Camp is a conference format dedicated to different Open Source projects and products and of course their communities. Get in touch with the Open Source enthusiasts behind the presented project. Learn new features and techniques, benefit from their extensive know-how and get up-dated on the latest developments. Backup your seat!

Join stackconf too

OSCamp #5 on Bareos takes place directly after stackconf, on June 19, 2020 in Berlin. Conference and camp venue is the same. More about stackconf at stackconf.eu! This is your chance to join two outstanding Open Source events in one week!

More info and tickets at opensourcecamp.de.

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

OSCamp on Bareos: Submit your Paper!

The title of this year’s Open Source Camp (OSCamp) tells it all: We want your backup stories! And ideally you tell them on stage. This time we focus on the Open Source backup software Bareos. Together with the Bareos company we invite you to share your expertise.

Call for Papers open

Call for Papers is open until March 30, 2020! Share your technical insights into Bareos and offer administrators new impulses for data backup, archiving and recovery. Each presentation is scheduled for 45 minutes, including a 5 to 10-minute Q&A session. Submit your paper at opensourcecamp.de!

The OSCamp on Bareos is where the community, Bareos users and developers meet – it’s an opportunity to talk to like-minded people and share expertise – as a speaker on stage, or as attendee during discussions and breaks.

What is OSCamp all about?

Open Source Camp is a conference format dedicated to changing Open Source projects and products and of course their communities.

The one-day event comprises expert presentations and tutorials on technical backgrounds, insights into the latest developments, how-tos, as well as future trends and perspectives. Focusing on advanced topics, the international addresses experienced administrators and systems engineers.

Get in touch with the Open Source enthusiasts behind the presented projects. Learn new features and techniques, benefit from their extensive know-how and get up-dated on the latest developments.

About Bareos

Bareos (Backup Archiving Recovery Open Sourced) provides an enterprise-level open source platform that preserves, archives and restores data from all major operating systems. The cross-network software protects your most critical data on-premises and in the cloud, including Enterprise Storage Systems.

Bareos offers NDMP support, LTO hardware encryption, bandwidth management, and a sophisticated scheduler that increases the level of automation.

Following stackconf

OSCamp #5 on Bareos takes place directly after stackconf, on June 19, 2020, in Berlin. More about stackconf at stackconf.eu! This is your chance to join two outstanding Open Source events in one week!

More information and tickets at opensourcecamp.de.

 

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.
OpenStack made easy – Snapshots erstellen, rotieren, einspielen

OpenStack made easy – Snapshots erstellen, rotieren, einspielen

This entry is part 4 of 5 in the series OpenStack made easy

Früher oder später gelangt wohl jede/r, die / der einen Server am Laufen hat einmal an den Punkt, dass es ihr / ihm die VM (oder Teile davon) irreversibel “zerreißt” – wodurch auch immer.
Wer sich im Vorfeld der Sicherung seiner Daten gewidmet hat, ist jetzt klar im Vorteil und hat signifikant niedrigere Adrenalinpegel zu erwarten – besonders, wenn die letzte Sicherung keine 24 Stunden her ist. Unsere OpenStack-Plattform bietet für die Sicherung Ihrer virtuellen Maschine(n) Funktionalität zum automatischen oder auch manuellen Erstellen von Schattenkopien (im Folgenden Snapshots genannt) an.

 > Automatischen Snapshot einrichten

Man wähle den Reiter Snapshots und setze ein Häkchen bei der automatisch zu sichernden VM und die Einstellung wird übernommen.

Et voilà! Ab sofort kümmert sich die OpenStack-App jede Nacht nach 00:00 Uhr darum, dass ein Snapshot dieser virtuellen Maschine erstellt wird. Wie im Bild erwähnt macht sie sieben Stück, beim achten Mal Snapshot-Erstellen löscht sie den ältesten, also den ersten, usw.
Ergo ist “7” ist der Rotations-Standardwert. Wer diesen gerne verändern möchte, d. h. weniger als eine Woche täglicher Snapshots vorhalten will, beispielsweise nur deren drei, kann das wie folgt tun: Zurück zum Reiter “LiveView” > Compute > Instanzen > Drop-down-Menü (ganz rechts neben der Instanz, die modifiziert werden soll) > “Aktualisiere Metadaten”.
Hier sieht man nun, dass unter “Existing Metadata” “nws_backup” existiert und auf “true” gesetzt ist.

Man schreibe unter “Available Metadata” neben das Feld “Custom” “rotation” hinein, füge es mit dem Pluszeichen der “Existing Metadata” hinzu, trage dort den Wert “3” ein und klicke auf “Speichern”.
Fertig.

¡¡¡ Im Fall von Datenbanken auf der zu sichernden VM !!!
Da Snapshots im laufenden Betrieb genommen werden, ist die Konsistenz der Datenbanken darin nicht garantiert. Ich empfehle die Einrichtung eines Cronjobs, der einen Dump der laufenden DBs oder anderer nicht-persistenter Daten anlegt. Gut wäre, wenn dieser vor 24:00 Uhr fertig ist und somit nahtlos mitgebackupt werden kann.

 > Manuellen Snapshot erstellen

Wer hingegen nur einen bestimmten Zustand – beispielsweise nach Durchführung aller Installationshandgriffe seiner Software-Landschaft – gesichert haben möchte, kann das manuell tun: Compute > Instanzen > Schattenkopie erstellen (neben der zu sichernden VM). Es ist dann noch ein aussagekräftiger Schattenkopiename zuzuteilen und Schattenkopie erstellen zu klicken.

Eine grüne Erfolgsmeldung wird hierauf oben rechts aufpoppen.
Hier sollte – wie oben beschrieben – ebenfalls auf Datenbanken geachtet werden.

 > Snapshot einspielen

Sollte es dann eben zur Havarie oder einem sonstigen Fall notwendiger Zurücksetzung kommen, läuft das Einspielen der Sicherung so ab, als würde man eine neue VM starten.
Compute > Instanzen > Instanz starten.

Details > Instanzname setzen

Quelle > Bootquelle auswählen:
Hier gibt es zwei Möglichkeiten, wo sich Ihr Snapshot befindet:

  • entweder > “Datenträger Snapshot” (i. F. v. VMs “mit Datenträger” bzw. “mit Volume”: Systemdatenträger in unserem Ceph-Storage, insgesamt dreifache Replikation an zwei Standorten)
  • oder > “Abbild” oder “Instanz Snapshot” (i. F. v. VMs “ohne Datenträger” bzw. “ohne Volume”: Systemdatenträger lediglich auf dem Hypervisor)

Variante, Netzwerke, Sicherheitsgruppen und Schlüsselpaar sind wie gehabt zu setzen.

Als Ergebnis wird man jetzt zwei ähnliche VMs haben:

Um den neuen Sollzustand zu verkomplettieren, bleibt, der zu verwerfenden Instanz die Floating-IP abzutrennen (Drop-down-Menü ganz rechts neben der Instanz) und diese der neuen zuzuweisen. Wenn sicher ist, dass die alte nicht mehr benötigt wird, kann diese dann auch gelöscht werden, um nicht weiterhin nutzlos Kosten zu verursachen.

Dieses Vorgehen eignet sich nicht nur zur Desaster-Recovery. Auch das Aufsetzen einer baugleichen VM oder das Testen größerer Patches abseits der produktiven Areale kann so bewerkstelligt werden.

> Snapshot als Datenträger einbinden

Für den Fall, dass man nur an die enthaltenen Daten heranwill, existiert auch die Möglichkeit, aus dem Snapshot einen Datenträger zu erstellen und diesen einer anderen laufenden VM anzuhängen.
Dies ist möglich über zwei Schritte:
Compute > Abbilder > Drop-down-Menü (ganz rechts neben dem zu benutzenden Abbild) > Datenträger erstellen > Datenträger erstellen.
Weiter über Datenträger > Datenträger > Drop-down-Menü (ganz rechts neben dem zu benutzenden Datenträger) > Anhänge verwalten.

Es ist noch die Instanz, mit der das Laufwerk verbunden werden soll auszuwählen und zu bestätigen.
Jetzt steht die Platte zur Verfügung, auf Ubuntu beispielsweise als /dev/sdb1 .

Martin Scholz
Martin Scholz
Systems Engineer

Martin sattelte unlängst vom sozialen Bereich auf die IT um und ist im Managed-Services-Support tätig. Praktischerweise nutzt ihm hier, dass er sich bereits vor geraumer Zeit Linux als User zugewandt hat. Privat ist er bekennende Couch-Potatoe. Es sei denn, er fühlt sich einmal wieder gedrängt, einen Marathon-Marsch zu unternehmen. Kein feliner oder kanider Passant ist vor seiner Kontaktaufnahme sicher.

NWS OpenStack – automatisierte Snapshots

Unser Ziel war und ist es, eine Plattform zu schaffen, die sehr hohe Flexibilität, Sicherheit und Komfort bietet. Unsere Kunden sollen in eigenen, isolierten Projekten ihrer Kreativität freien Lauf lassen und nahezu uneingeschränkt sein, ohne sich um essenzielle Dinge Gedanken machen zu müssen.

In genau diesem Zuge, haben wir diese Woche ein neues Feature für unsere OpenStack Cloud veröffentlicht – automatisierte Snapshots für virtuelle Maschinen und Volumes! Mit diesem neuen Feature können sich unsere “IaaS” (Infrastructure as a Service) Kunden zurücklehnen, entspannen und die Verantwortung der zuverlässigen Sicherung an uns abgeben. Wir stellen sicher, dass ausgewählte Instanzen ordnungsgemäß gesichert werden und dieser Prozess überwacht wird.

Doch wie genau funktioniert das nun? Wir haben in unserer Plattform einen Menüpunkt eingebaut, der als Schaltzentrale fungiert. Eingesehen werden kann dieser von jedem Nutzer in der Übersicht seiner OpenStack Instanz. Es werden hier alle VMs sowie Volumes aufgelistet und gegebenenfalls mit Notizen versehen. Beispielsweise in welcher VM ein Volume unter welchem Pfad eingehängt ist.

In dieser Liste kann nach belieben, durch setzen eines Hakens, der Sicherungsprozess aktiviert oder deaktiviert werden.
Neben dem Erstellen von Backups werden nach einer gewissen Retention, Snapshots natürlich auch vollkommen automatisch wieder gelöscht. Per Default alle Sicherungen, welche älter als 7 Tage sind.

Eine Übersicht über die aktuellen Sicherungen gibt es im OpenStack selbst:
Compute -> Images / Volumes -> Snapshots 

Erweiterungen zu dieser Sicht sind geplant. Ebenso weitere neue spannende Features, welche aktuell noch in der Entwicklung sind.
Wir haben zum Snapshot/Backup Release auf unserem Twitter Account ein kurzes Video mit einer Live Demo dazu für euch vorbereitet. Lasst uns auf Twitter gerne wissen, was ihr davon haltet!

Noch kein NWS IaaS Kunde? – Hier geht’s zu unserer Platform

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...

Ceph Mimic | Using loop devices as OSD

For quite some time we have been using ceph-deploy to deploy OSD in folders during the Ceph trainings held by Netways. This worked perfectly with jewel, but newer versions don’t allow this behaviour anymore.
There are several reasons for this, however, as we have a quite regulated setup for our training notebooks, we had to come up with some kind of workaround. This approach is, while working fine in our training setup, not recommended for production!
The following steps apply to a current CentOS 7 system.
As stated before, we will deploy an OSD on a block device. Though you could use a separate partition for this, we will use a loop device. For this, the first step is to create a file:
For this, create an OSD directory
 

$ mkdir -p /home/training/my-cluster/osd-$HOSTNAME
$ cd /home/training/my-cluster/osd-$HOSTNAME/

in this folder, create a file for later use

$ fallocate -l 30G 30GB.img

test it

# losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"
# wipefs -a /dev/loop1
# lsblk

This should then display your new loopdevice.
As loop devices are not reboot safe, you need to go some steps further. If you like to use rc.local for this, you’re free to do so.
We’re going to create a service, which will essentially execute the prior mentioned losetup command. For this, we need a script with the command and a .service file, which will execute the script:

rebloop.sh
#!/bin/bash
sudo losetup -l -P /dev/loop1 "/home/training/my-cluster/osd-$HOSTNAME/30GB.img"

and the service file:

rebloop.service
[Unit]
Description=Reattach loop device after reboot
[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/rebloop.sh
[Install]
WantedBy=multi-user.target

These files have to be executable and be copied to the correct folders. Afterwards, the service must be enabled and can be started.

# chmod +x rebloop.*
# cp rebloop.sh /usr/bin/rebloop.sh
# cp rebloop.service /etc/systemd/system
# systemctl enable rebloop.service
# systemctl start rebloop.service

Ceph, however, will still not want to create an OSD on this device, instead give you following error message:

-->  RuntimeError: Cannot use device (/dev/mapper/<name>). A vg/lv path or an existing device is needed 

You have to make changes to /usr/lib/python2.7/site-packages/ceph_volume/util/disk.py on the OSD host:
in line 201, add “or TYPE==’loop'”:

# use lsblk first, fall back to using stat
TYPE = lsblk(dev).get('TYPE')
if TYPE:
return TYPE == 'disk' or TYPE == 'loop'

and in line 286, change the “skip_loop” switch from “True” to “False”:

 def get_block_devs(sys_block_path="/sys/block", skip_loop=False): 

For testing purposes, simply reboot your system and verify if the loop device gets reattached correctly.
If yes, you can deploy an OSD. We’re using ceph-deploy here:

$ ceph-deploy osd create --data /dev/loop1 $HOSTNAME

When the command was successfully executed on your hosts, you can create your first pool

# ceph osd pool create rbd 100 100 replicated

examine ceph status

# ceph status

tag the pool with an application

# ceph osd pool application enable rbd rbd

As you can see, there are quite some changes to be made, and each of it is failure-prone.
Best practice is to simply use a real block device and for production you really should stick to this.
If, however, there are certain needs to be fulfilled, ceph can be convinced to comply.
 
Sources:
http://tracker.ceph.com/issues/36603
https://tracker.ceph.com/issues/23337
https://github.com/NETWAYS/ceph-training
 
 
 

Tim Albert
Tim Albert
Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...