NETWAYS Cloud: Dein MyEngineer unterstützt Dich. Jederzeit.

“Wir wollen doch nur eine Homepage!” – dieses Leid hat uns einmal ein Kunde nach einem 4-stündigen technischen Gesprächsmarathon zwischen Webagentur, Hostingdienstleister (das waren wir) und Kundenvertretern geklagt – und Recht hat er. Natürlich hatte der Kunde Ansprüche an Hochverfügbarkeit und Lastverteilung, die nicht ganz trivial waren, aber das sollte nicht sein Problem sein, das haben die entsprechenden Dienstleister zu lösen.

“Aber geht das auch in der Cloud?”
Grundsätzlich sind die meisten Angebote auf Self-Service ausgelegt und bieten hier die tollsten technischen Lösungen, damit man sich DevOps-mäßig voll ausleben kann. Und natürlich ist dies in der NETWAYS Cloud auch so. Wir haben alle möglichen APIs, ein Self-Service Portal und die OpenStack Dokumentation ist sehr ausführlich.

“Aber ich will mich voll auf meine Anwendungen konzentrieren!”
Verstehen wir und hier kommt unser MyEngineer ins Spiel. Wir stehen unseren Kunden mit genau dem Service-Umfang zur Verfügung, der für die eigene Umgebung benötigt wird. Du brauchst nur eine kurze Starthilfe für das OpenStack-Backend? Dann machen wir nur einen kurzen Workshop zur Bedienung und dann kannst du selbst loslegen. Du willst dich rein um deine Anwendung kümmern? Dann übernehmen wir das komplette Setup und die Betreuung bis zur Anwendungsschicht – natürlich mit 24×7 Support nach Bedarf.

“Und wo ist der Vorteil für mich?”
NETWAYS hat über 15 Jahre Erfahrung im Hosting und Betrieb von komplexen Open Source Umgebungen und unsere Kollegen stehen jederzeit auf Abruf zur Verfügung. Und die Abrechnung läuft nicht über undurchsichtige Pauschalen, sondern rein nach Bedarf. Natürlich sprechen wir vor Projektbeginn alle wichtigen Prozesse mit unseren Kunden ab und passen uns so voll und ganz unseren Kunden an.

“Super, wie gehts jetzt weiter?”
Einfach unter nws.netways.de anmelden und Kontakt mit uns aufnehmen. Dann kann es mit dem Projekt schon losgehen!

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.

Server löschen mit Darik´s Boot and Nuke

Da ich derzeit meinen Abteilungsdurchlauf bei Netways Managed Services mache, übernehme ich heute den wöchentlichen Post. Ich dachte mir, da ich derzeit viele Server lösche und aus dem Rechenzentrum ausbaue, wäre es ein gutes Thema über das sichere löschen von Servern zu reden. Das Tool welches wir bei Netways zum löschen von Servern und Festplatten benutzen, ist Darik´s Boot and Nuke (kurz DBAN).

Was ist DBAN?

DBAN ist ein Werkzeug zum kompletten Überschreiben von Festplatten und Servern.

Wie funktionert Darik´s Boot and Nuke?

Das Tool überschreibt die gewünschten Festplatten so oft mit Einsen und Nullen, wie man es wünscht. Dadurch ist eine Wiederherstellung der Daten nicht möglich. Außerdem kann man verschiedene “Löschmethoden” auswählen. Diese werden ich in diesem Artikel aber nicht alle einzeln aufzählen und erklären, da dies zu weit gehen würde. Die Methode welche wir zum löschen nutzen, ist DoD 5220.22-M.

Warum löschen wir Server?

Aus einem einfachen Grund: Daten von Kunden, welche sich auf den Servern befinden, dürfen nicht an die Öffentlichkeit gelangen. Für jemanden der sich in dieser Branche auskennt, ist es kein Problem übrige oder gar nicht gelöschte Daten aus den Festplatten der Server zu lesen. Sollte ein Server verschrottet werden, ist es also trotzdem nötig die Daten vorher sauber und sicher zu löschen. Außerdem werden Server, welche in guter Verfassung und auf dem heutigen Standart sind, meist nach der Löschung weiter verwendet.

Wie erstellt man einen bootbaren DBAN Stick?

Mit diesem Thema hatte ich lange zu kämpfen. Als Information vorab, DBAN ist als ISO Image zu downloaden und als bootbares Image zu nutzen. DBAN kann man mit so gut wie jeden “Startmedienersteller” bootbar auf einen Stick schreiben. Allerdings wird bei Ubuntu 18.04 (welches ich auf meinem Rechner habe) das Image nicht komplett erstellt. Es fehlen einzelne Bruchteile des Systems, welche dafür sorgen, dass ich DBAN nicht booten kann. Ich habe lange gebraucht um herauszufinden, wie ich einen DBAN Stick erstellen kann. Am Ende war es ziemlich simpel. Ich habe versucht das Image auf einem Windows 10 Rechner zu erstellen, und der bootbare Stick wurde sauber ersellt und ich konnte von ihm booten.

Eine kleine Tücke, über die ich auch gestolpert bin, sind Raids. Raids müssen vor dem löschen entfernt, bzw. jede Platte sollte als eigenständiges Raid 0 auf geführt werden, da sie sonst nicht in der Tabelle der löschbaren Festplatten auftauchen.

Ich hoffe ich konnte euch einen kleinen Einblick in DBAN liefern und habe euch für das Werkzeug begeistert.

Tobias Bauriedel
Tobias Bauriedel
Junior Consultant

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns macht er zurzeit seine Ausbildung zum Fachinformatiker. In seiner Freizeit ist er viel unterwegs und unternimmt gern etwas mit Freunden.

Lessons learned – how not to make beginner’s mistakes: Migrating server

At Netways we try to learn all the time. Often you can simply read man pages, change logs, or even tabtab through your shell command at hand.

Trainings and conferences are a bit more time consuming, but can offer you one priceless advantage: the direct communication with someone, who has seen several sides of the topic at hand. I think, you learn best from other peoples experiences – even more from the situations where failure ensued. Here it is critical to not only look at the failure itself, but why it occured and how it was finally resolved.

Using other persons failure as a mean to learn  might seem a bit cynically at first. In an ideal world, however, the same failure would only ocurr once.

So let’s begin with my contribution to a better world, maybe even as a start of a series. This entry is not meant as full post-morten per se, it only describes mistakes you can make and should avoid.

As many might know, our office moved. Having been 10ish years in our “old” office, you might figure that quite a lot “historical infrastructure” can grow in this time. Especially in an IT environment where everybody wants to try something new, better, and undocumented.

Being in the distinguished situation of having direct access to our DC via 1GBit-Fiber, it was possible to use some of our external IPs in our office. VLAN-Tagging, firewall policies, iptables rules – all well known and understood best practices. The services got installed, used and worked flawlessly for all the time and have lived happily ever after.

With the announcement of moving to the new premises, the blue sky became a bit hazy. We had to move all needed hardware devices (NASA could tell you how small and well hidden some of them can be) and also separate them from the unneeded devices. Todays story is about two specific systems, each consisting of two 1U server. Those were some of the systems which used external IPs to provide services to the public. They have been running flawlessly for quite some time and given their age, had started to develop some adorable quirks.

It was my task to move these “dear old ladies” out of the cozy office into the cold, professional DC downstairs.

What harm can 4 old and lovable server possibly do, you might ask? The answer is: None, if you treat them the way they were used to.

First things first: How can you gain access to the DC? Is there a registration process, which has to be followed? How long does this take? Can you access the DC after business hours easily? (Hints: yes, long, no)

Also don’t try to rush things when it comes to shutdown the machines for moving  them. The machines owners like to what is going to happen.

Grab all the tools you will need to remove the server from your previous rack and install them in their new home (cordless screwdriver, all bits you can find)

Are all installation material available? This is not only referring to rack rails, but also cage nuts, screws (size matters) and front covers for feng-shui and air flow. (depends, mostly: no)

Cables! Just collect all the cables you need and then some. Usually, they will be too short. Too long is not an issue you can’t fix with zip ties (you will forget these)

Do you have network access in the DC for debugging, communication etc.? (Hint: depends)

Do you want to move more than one server? Be cautios and do them step by step. You’re absolutely allowed to install them all at the same time. Be aware you might experience crooked rails, incorrect cabling and other time consuming things.

When you have installed the machines, definitely take your time to check these with a KVM device. Whichever is in reach. (you guessed it: there won’t be any when you need them the most). Don’t rely on the machine and its fancy blinkenlights: Some may flash when everything is ok, some flash to indicate errors, some don’t flash at all.

Check all your cabling at least twice, give them a gentle pull – if they come lose, you have to start over again.

Take breaks between different machines. Either try to find a cool spot in the DC (haha) or get outside, have something to drink and return refreshed. The noise (ear plugs, ANC Headphones), temperature, confinement while working in the rack will wear you out eventually.

If you route the machines traffic through several VLANs, make sure all needed switch ports are tagged (or untagged? You decide!) and firewall policies applied for the new location.

Always have a piece of paper and a (working!) pen with you – it’s faster to scribble something on paper than to crawl through yor rats nest of cabling, climb over all the machines you’re up to install and then find your trusty notebook with dead battery.

Before you finally leave, make sure to give everything one last check and, if possible, communicate with the owners of the respective machines. Collect all the tools you brought with you. If you didn’t bring them but “found” them somewhere and used them: make sure to return them.

If you run into any issues, make sure all colleagues you could ask for assistance are currently at the party you’re rushing to attend.

Also make sure to communicate only via phone, so you don’t leave any paper trail when it comes to DC access, network config or time accounting.

When you don’t experience some of these mistakes because of this post, this post was a success. Of course some points are missing (feel free to comment), but I hope the overall pattern is visible:

be prepared, double check and take your time

 

Oh, and don’t forget the key to your racks. There is just one key, right?

Tim Albert
Tim Albert
System 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...
NWS – because web services don’t have to be complicated

NWS – because web services don’t have to be complicated

Web services platforms are a common way nowadays, to run your services without the need of your own infrastructure. No matter if you need a safe place for your data, an app to communicate with people or just a place to run your own services. But what do you know about the platform of your choice?

  • Do you know how your data is stored?
  • Do you know where the servers are located in detail?
  • Do you know the people which are giving you support?
  • Do you know what happens in case of a critical issue?

I bet, most of you, or at least some of you, don’t. But that’s the point where we start. We want to be different. We want to be transparent and uncomplicated.

Our servers are located in Nuremberg – Germany. We are running them in two different datacenters to ensure high security.

Working with our apps is pretty simple. Just start them! There is no complicated registration process, just fill in the form and you are good to go. The best thing is: you don’t even need a domain or some know how of SSL. It’s already configured for you! Of course you can use your own domain and certificates if you want, but you don’t have to.
If you are curious about how our apps are working in detail or what features are available in our apps, just have a look at our FAQs
Still can’t find what you are looking for? Contact us via live chat! If there is no live chat agent available, an automated ticket will be created, so we can get in touch with you.

But whats so special about our support? Well, it’s quick, it’s professional, it’s individual and most important of all: Our developers and administrators are your support team.

We also want to create our bills as transparent as possible. In case of our OpenStack cloud, you won’t just get a bill with an amount. You will get a detailed report of all resources you used in the past month. Which IP was used how long? How many CPUs were used how long and which VM did use them? But thats still not all. We want to give you the possibility to check at a various day of the month, how much money you spent on our cloud so far and how much you will spent till the end of the month.

Keep track of whats going on! And even if you have your applications running on a different platform – we will help you migrating your data with almost no downtime. Because we take care.

Most features we released for our apps and the platform itself, were not features “we wanted” to release. Don’t get me wrong here, we also wanted to release them, but most of them were features our customers requested and needed.

And we got one more thing. If you don’t know if you can trust us, you can just give it a try. Ask us anything or just try our services – 30 days for free (OpenStack is excluded here – but just get in touch with us. We will find a solution that fit your needs.).

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

Terraform Changes

Hallo!

Was vielen von unseren Lesern entgeht, ist das wir auch in unserem Alltag zwischen der ganzen Softwareschreiber- und Kompilier- Tätigkeiten auch ganz viele virtuelle Maschinen und Container zum testen selbiger Software rauf und runter installieren müssen, und das Tag für Tag.

Deshalb versuchen wir uns das Leben mit dafür erstellter Software und deren arbeitserleichternden Funktionen leichter zu machen. Wie mein Kollege schon in seinem Blogpost im März mir vorgegriffen hat, benutzen wir bei der Netways Terraform. Achim wird in weiteren Artikeln darauf eingehen wie man Openstack per Terraform nach seiner Pfeife tanzen lassen kann und Ich möchte mich heute auf ein anderes Terraform Thema beziehen, nämlich dem nahen Release von Terraform 0.12.

Zu dem Zeitpunkt wo ich diese Zeilen niederschreibe, ist auf der aktuellen Website von Hashicorp noch die Aktuelle Version 0.11.13 zu finden.

Aber Terraform hat uns schon vielversprechendes gezeigt mit dem 0.12.0-beta1 pre-release.

Damit kann man schon die vielen Erleichterungen, welche der neue Terraform Release mit sich bringt erahnen und auch schon antesten. Ich versuche die Änderungen Anhand eines kleinen Beispiels zu erläutern.
Vielleicht kann ich den einen oder anderen IaaS Codeschreiber, welcher sich hierfür interessiert, etwas auf den Geschmack zu bringen schon etwas zu testen mit der neuen Version.

Hier der Unterschied zwischen einer (aktuell 0.11.13) alten Terraform Version und einer neuen Version in Terraform 0.12 durch eine Gegenüberstellung.

main.tf (Random Tiernamen Beispiel)

variable "count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "zoo_enabled" { default = "0" } variable "prefix_liste" { default = [] } resource "random_pet" "my_pet" { count = "${var.count}" prefix = "${var.zoo_enabled == "0" ? var.default_prefix : element(concat(var.prefix_liste, list (""), count.index)}" }

main.tf HCL2 Version(Random Tiernamen Beispiel)

variable "pet_count" { default = 1 } variable "default_prefix" { default = "Giraffe" } variable "prefix_list" { default = [] } resource "random_pet" "my_pet" { count = var.pet_count prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix }

Die Unterschiede fallen zuerst etwas weniger ins Auge, sind aber dafür meines Erachtens tiefgreifender für Leute, die IaaS Code schreiben müssen und dienen der Lesbarkeit des Codes.

Vorteil Nummer 1:
Im alten Beispiel musste noch mit “${var.count}” von einem String zu einer Number evaluiert werden. Mit der neuen HCL2 Schreibweise entfällt das, und es kann mit var.pet_count direkt der korrekte String oder Number Wert adressiert werden.

Vorteil Nummer 2:
Auch die Evaluierung der Liste prefix = “${var.zoo_enabled == “0” ? var.default_prefix : element(concat(var.prefix_liste, list (“”), count.index)}”  wird mit der neuen Notation der HCL2 wesentlich eingängiger. prefix = var.zoo_enabled ? element(var.prefix_list, count.index) : var.default_prefix ist prägnanter. Es entfällt auch die element(concat(x), list(“”), x ) Hack-Situation, um aus einer leeren Liste auch eine Liste mit einem NULL Element zum machen.

Weitere Vorteile: es gibt viel mehr was geändert worden ist, if you want to know more, klick here.

Ich hoffe ich habe euch nicht zu sehr gelangweilt mit C.O.D.E. kurz vor dem Wochenende.

Gruß David

 

David Okon
David Okon
Senior Consultant

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

Infrastructure as Code mit Terraform und Openstack

This entry is part 1 of 1 in the series Openstack und Terraform Beispiele

Der Drang weg von Hardware zu einer virtuellen oder sogar serverless Infrastruktur ist weiterhin stark. Nicht alle Administratoren oder Entwickler denken sofort an eine Containerplattform wie Kubernetes oder serverless functions sondern verlagern die eigene Infrastruktur in eine Public Cloud. Dadurch bleiben einem lästige Aufgaben in Kalt- und Warmgängen im Rechenzentrum erspart und es bleibt mehr Zeit für anderen Tätigkeiten. Cloud Plattformen wie OpenStack bieten alle nötigen virtuelle Ressourcen die auch in einem Rechenzentrum vorhanden sind, nur dass diese in wenigen Sekunden verfügbar sind. So kann man Komponente wie z.B. Router, Bridges, Interfaces, Server (VMs), Storage (von Block bis Object) und andere schnell und einfach über offene Schnittstellen erstellen und verwalten.

Dies gibt uns Administratoren auch die Möglichkeit unsere Infrastruktur in Textdateien zu beschreiben, zu automatisieren und zu verwalten. Unter dem Buzzword Infrastructure as Code findet man viele Tools die einem hier unterstützen und Terraform ist eines der bekanntesten um z.B. Ressourcen in OpenStack zu verwalten. Mit meinen nächsten Blogposts will ich mit vielen Beispielen zeigen wie man mit Terraform seine virtuelle Ressourcen in der Netways Cloud verwalten kann. Mehr zum Thema Terraform gibt es auch im Talk von Anton Babenko auf der OSDC.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.