NETWAYS Cloud: Schnell & einfach Netzwerke erstellen mit SDN

SDN heißt Software Defined Networking – so weit, so klar. Die meisten setzen irgendeine Art SDN bereits bei sich im Unternehmen ein. Und in der Cloud? Normalerweise bieten dies nur die großen Anbieter und es ist relativ aufwendig zu betreiben. Die NETWAYS Cloud bietet mit dem OpenStack SDN die Möglichkeit, eigene Netzwerke frei zu gestalten – und dies komplett selbständig über unser OpenStack-Backend.

Das Design des Netzwerks läuft wie gewohnt – Webserver sind von außen erreichbar (ggf. noch mit Loadbalancer) und greifen nur auf intern erreichbare Datenbankserver zu. Die Imageserver stellen die entsprechenden Bilder zur Verfügung und das Wiki mit den Arbeitsanweisungen ist nur per VPN erreichbar. Dies ist alles mit “virtuellen Netzwerkkabeln” über das OpenStack SDN mit wenigen Klicks erstellbar. Und das alles ohne neue Netzwerkhardware, neue Kabel, Netzwerkadmins und viel Zeit. Alles wird per Self-Service aufgebaut und zur Verfügung gestellt.

Der Mehrwert?
Die Hauptvorteile liegen in der schnellen Bereitstellung von Netzwerkressourcen und im freien Design der Netzwerkarchitektur.

Zielgruppe
Kunden mit größeren Hosting-Projekten und der Anforderung nach logischer Netzwerktrennung – perfekt also für Webagenturen, Hostingdienstleister ohne eigenes Rechenzentrum und Anbieter von SaaS-Lösungen, die eine Trennung von Kundennetzwerken benötigen.

Bekomme ich das alleine hin?
Klar! Und wenn wir eine Einführung machen dürfen oder gleich die komplette Erstellung des eigenen Netzwerks, dann stehen unsere Kollegen als persönlicher MyEngineer zur Verfügung.

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.

Cachet now available at NETWAYS Web Services

We think communication is crucial. Especially during downtimes. That’s why we release a new app today. An app, which allows you to share all necessary information about your services and servers with your users. Cachet is software that improves downtime.

Cachet is a status page, which is very simple to use, yet it offers many opportunities, to better communicate downtime and system outages to customers, teams and shareholders. You can display the status of your services, websites and servers. You can create and show metrics, plan maintenances or inform your users about current issues.

 

 

Cachet comes with a powerfull API. In the detailed documentation you can generate your calls for whatever you want to create or change. All information which can be created and edited in the admin panel, can also be created and changed with an API call. The interesting part about Cachet is that administrators have the opportunity to automate the updates. For example with data of your monitoring or some scripts on your hosts which check some services.

In the following command, you would create a new incident with the name “Down” and the message “A server went down“.

  • It will be in the state “1“, which means “investigating
  • The component which is affected by this incident has the id 2, which is in this case “My Login
  • The component will be in state “4“, which means “Major Outage
  • Notify: true – so your user would receive an email with about this incident.

mgebert@MacBook-Pro ~ $ curl --request POST --url https://cachet-demo.nws.netways.de/api/v1/incidents -H "Content-Type: application/json;" -H "X-Cachet-Token: j5t0mNvvh57ubO84TxJq" --data '{"name":"Down","message":"A server went down.","status":1,"visible":1,"component_id":2,"component_status":4,"notify":"true"}'

If you want to notify your users as soon as an incident was reported, you will have to configure the credentials for your mailserver and enable the “Subscribe” button, which can be done in the settings quite simple.

But if you don’t want to use the API, you can create and manage your information just by changing the states of your components and incidents, as you can see in the screenshots below.

 

You can start your own Cachet app at the NWS platform now on our platform. First 30 days are for free and the app will be ready within 5 minutes – so what are you waiting for?

Last but not least, I want to share with you the link to a temporary available demo installation, so you can have a look at it right now. Check it out!

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

Trefft unser NETWAYS Web Services Team auf der DOST!

Die DOST hat sich nachhaltig als anerkannte Fachkonferenz rund um den Betrieb modularer Cloud-Plattformen etabliert. Da dürfen unsere Kollegen von NETWAYS Web Services natürlich nicht fehlen! Wir werden als Konferenzteilnehmer vor Ort vertreten sein, aber auch als Sponsor mit einem Stand in der Sponsorenausstellung. Egal ob nach oder vor einem Vortrag oder an unserem Stand – sprecht uns an!

Wir freuen uns auf interessante Gespräche zu Cloud und Co.!

Erzählt uns von euren Systemen und Lösungen und erfahrt von uns alles, was es zur NETWAYS Cloud auf OpenStack-Basis zu wissen gibt!

Das Programm, Tickets und alles weitere zur DOST: https://openstack-tage.de/

Alles zur NETWAYS Cloud: https://nws.netways.de/de/cloud/

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.

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