pixel
Seite wählen

NETWAYS Blog

Cloud Services and NWS-ID – It’s a match!

von | Jan 26, 2023 | , ,

We’re starting the new year with a new integration for you! As announced last year, the integration of further products with NWS-ID will continue in 2023! From now on the NWS Cloud Services are integrated with NWS-ID.

What are the advantages of integrating our Cloud Services with NWS-ID?

Combining these two services makes your daily work easier, because now you can:

  1. use a single login for both interfaces (Customer Interface and Cloud Interface)
  2. effortless switch between OpenStack projects, in the Customer Interface, in the Cloud Interface (Horizon) and on the OpenStack CLI
  3. use two-factor authentication for your Cloud Services
  4. authorise your colleagues to access your OpenStack projects in the NWS-ID group management

How can you use the Cloud Interface with NWS-ID?

Select NWS-ID at cloud.netways.de, log in and you’re done – simple as that! If you’re not an admin in your organization, they must authorize your NWS-ID. This happens as usual in the user group management in the customer interface.

How do I use the OpenStack-CLI with NWS ID?

As usual, you need an OpenStack Environment File. You can find a version adapted for NWS-ID under Get Started in your OpenStack project in the Customer Interface or in our NWS Docs.
If you’re a member of several OpenStack projects, you can easily switch between them. Simply source the OpenStack Environment File again to get a selection.
Don’t have the official OpenStack CLI client yet? No problem – you can get help in the NWS Docs!

What happens to the existing login?

The existing login can still be used, e.g. in your scripts or tools like Terraform. The password can be changed as usual on cloud.netways.de or via the OpenStack CLI.

What’s coming next?

For a more effortless access, we will gradually integrate our portfolio with NWS-ID. We are already playing with kubelogin and we are looking for a simple Vault SSH integration to extend the reach of your NWS-ID to your OpenStack Cloud Servers.
The same procedure as last year still applies. Please give us a little time to implement the integrations and we will of course come back to you as soon as possible! If you have any questions along the way, please feel free to contact us – we’re always there to help answer any open questions.

Achim Ledermüller
Achim Ledermüller
Lead 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.
Lies mehr von Achim und triff unser Team

Let me introduce: NWS-ID

von | Dez 1, 2022 | ,

We’re really excite to share an enhancement with you that puts your NWS Customer Interface experience to a whole new level! NWS-ID – our new core for managing your personal identity and access to nws.netways.de! Even if identity management sounds a bit dull to some, NWS-ID enables us to bring some new features to you. But  what are these new features, you wonder? Okay, let’s get right into it and answer some questions, you might have. First:

What is NWS-ID?

NWS-ID is the future home for your personal user profile and a much desired integration to the current customer interface. Here, you can update your password, configure 2FA and edit your profile data, although we rarely save any of it. The introduction of personal accounts allows us to provide new features to the NWS Customer Interface and the associated products – including a user and group management.

User and Group Management

The first and probably biggest thing is the integration of NWS-ID with our Customer Interface at nws.netways.de, which enables us to release user and group management – a feature many customers requested and that we’re now thrilled to provide. It basically allows you to give your team access to your account and products. The role-based approach allows you to easily create user groups with appropriate permissions and invite your colleagues with their own personal NWS-ID. Thanks to fine-grained authorization settings, you decide who can access and manage your projects or even the whole organisation!

Managing multiple organisations at NWS?

No problem with NWS-ID! It’s never been easier. If you are in charge of managing several organisations at NWS you will love NWS-ID. Your user can be associated with multiple organisations and it’s easy to switch between them with a single click! You no longer have to log in again or use multiple browsers.

When will NWS-ID be available?

We will release NWS-ID in two weeks, on December 14th. All existing accounts will be migrated automatically – if you are a current NWS customer, you will receive an e-mail to renew your password on that day. That’s it! From then on, your NWS-ID is active and the user and group management is available! Don’t forget to enable two-factor authentication! It does not only sound easy, it is easy! We can’t wait for you to use and implement NWS-ID into your everyday life and to see and hear, what benefits it brings to you.

What does the future hold?

With NWS-ID as the new core for our identity management, not only you benefit from this enhancement, but also our products, which you’ll be able to access more effortlessly. Our portfolio will be gradually integrated, which simplifies the access to products and projects for your whole team. SSO is the buzzword here. Give us a little time to implement the integrations and we will of course come back to you as soon as possible!

I hope you are looking forward to the new home for your user profile! I am sure that NWS-ID complements our portfolio well and is the base for simple and good authentication and authorisation. If you have any questions along the way, please feel free to contact us – we’re always there to help answer any open questions.

Achim Ledermüller
Achim Ledermüller
Lead 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.
Lies mehr von Achim und triff unser Team

Storage Wars – Using Ceph since Firefly | OSDC 2019

von | Apr 21, 2020 | , , , ,

This entry is part 5 of 6 in the series OSDC 2019 | Recap

YouTube player

 

Achim Ledermüller ist Lead Senior Systems Engineer bei NETWAYS und kennt sich aus in Sachen Storage. 2019 hat er seinen Talk „Storage Wars – Using Ceph since Firefly“ auf der Open Source Data Center Conference (OSDC) in Berlin gehalten. Wer den Talk verpasst hat, bekommt nun die Möglichkeit, Achims Vortrag noch einmal zu sehen und zu lesen (siehe weiter unten).

Die OSDC wird 2020 erstmalig unter neuem Namen stackconf veranstaltet. Mit den Veränderungen in der modernen IT hat sich in den vergangenen Jahren zunehmend auch der Fokus der Konferenz verlagert: Von einem hauptsächlich auf statische Infrastrukturen zielenden Ansatz zu einem breiteren Spektrum, das agile Methoden, Continuous Integration, Container-, Hybrid- und Cloud-Lösungen umfasst. Dieser Entwicklung soll mit der Namensänderung der Konferenz Rechnung getragen und das Themenfeld für weitere Innovationen geöffnet werden.

Aufgrund der Bedenken rund am das Coronavirus (COVID-19) wurde die Entscheidung getroffen, die stackconf 2020 als Online-Konferenz stattfinden zu lassen. Das Online-Event findet nun vom 16. bis 18. Juni 2020 statt. Live dabei sein lohnt sich! Jetzt Ticket sichern unter: stackconf.eu/ticket/

Storage Wars – Using Ceph since Firefly

Wenn es um Storage geht, ist die Erwartungshaltung klar definiert. Storage muss immer verfügbar, skalierbar, redundant, katastrophensicher, schnell und vor allem billig sein. Mit dem Unified Storage Ceph kann man zumindest die meisten Erwartungen ohne Abstriche erfüllen. Durch das Prinzip, wie Ceph Daten zerlegt, speichert und repliziert, ist die Verfügbarkeit, Skalierbarkeit und Redundanz gewährleistet und auch eine katastrophensichere Spiegelung eines Clusters ist ohne Probleme möglich.

Neben den angebotenen Features ist aber auch ein reibungsloser unterbrechungsfreier Betrieb wichtig. Während des fast siebenjährigen Betriebs unseres Clusters änderten sich fast alle Komponenten. Betriebsysteme, Kernel und Init-Systeme wurden ausgewechselt. Alte Netzwerkkarten wurden durch 10GE- und 40GE-Schnittstellen abgelöst und vervierzigfachten ihren Durchsatz. Layer 2 wird wegen Routing on the Host immer unwichtiger, Festplatten sind plötzlich dank moderner SSDs und NVMe nicht mehr das Bottleneck und natürlich gab es auch immer wieder neue Versionen von Ceph selbst. Zwischen all diesen Neuerungen in den letzten Jahren ist natürlich genügend Platz für kleine und große Katastrophen. Umso wichtiger ist es, dass man von Anfang an ein paar grundlegende Dinge richtig macht:

Limitiere IO-intensive Jobs

Im normalen Betrieb laufen verschiedene Aufgaben im Hintergrund, um einen gesunden Zustand des Clusters zu garantieren. Scrubbing Jobs prüfen die Integrität aller gespeicherten Daten einmal pro Woche, Platten- und andere Hardwarefehler veranlassen Ceph, die Anzahl der Replika automatisch wieder herzustellen und auch das Löschen von Snaphosts bringt die Festplatten zum Glühen. Für jedes dieser kleinen Probleme bietet Ceph Konfigurationsmöglichkeiten, um größere Auswirkungen auf Latenzen und Durchsatz der Clients zu verhindern.

Neben dem Datenmanagement durch Ceph selbst wird das Cluster natürlich auch von vielen Clients beansprucht. In unserem Fall wollen virtuelle Maschinen aus OpenStack und OpenNebula an ihre Daten, verschiedenste WebClients wie GitLab, Nextcloud, Glance und andere senden Swift- und S3-Anfragen und ein zentrales NFS-Storage will natürlich auch Tag und Nacht bedient werden. Auch hier kann eine Begrenzung der Requests durch libvirtd, rate-limiting oder andere Mechanismen sinnvoll sein.

Kenne deine Anforderungen

Die Anforderungen der Clients an die Latenz und den Durchsatz des Storage-Systems können sehr unterschiedlich sein. Features wie Replikation und Verfügbarkeit werden mit erhöhten Latenzen erkauft. Große Festplatten mit Spindeln drücken die Kosten, allerdings sind auch nur noch wenige Benutzer und Anwendungen mit wenigen IOPs, höheren Latenzen und dem geringen Durchsatz zufrieden. Was für Archivdaten kein Problem ist, sorgt bei Datenbanken oft für unglückliche Benutzer. Schnellere Festplatten und eine geringe Latenz im Netzwerk verbessern die Situation erheblich, erhöhen aber auch die Kosten. Zudem ändern sich die Bedürfnisse der Clients auch im Laufe der Zeit. Dank Crush kann Ceph den unterschiedlichen Ansprüchen gerecht werden. Ein schneller SSD-Pool kann ohne Probleme parallel zu einem Datengrab auf langsamen großen Spindeln betrieben werden und auch eine Umschichtung der Daten ist jederzeit flexibel möglich.

Plane im Voraus

Neben eines Datenverlusts ist ein volles Cluster wohl eines der schlimmeren Szenarios. Um eine Beschädigung der Daten zu verhindern, werden bei 95% Füllstand keine weiteren Daten mehr angenommen. In den meisten Fällen macht dies den Storage unbenutzbar. Zu diesem Zeitpunkt hat man eigentlich nur zwei Möglichkeiten: Man kann versuchen, nicht mehr benötigte Daten zu entfernen, z.B. in Form von alten, nicht mehr benötigten Snapshots, oder man vergrößert den Cluster rechtzeitig. Hierbei sollte man bedenken, dass die Beschaffung und der Einbau der Hardware schnell mal 7 bis 14 Tage in Anspruch nehmen kann. Genügend Zeit zum Handeln sichert man sich durch verschiedene Thresholds, so dass der Cluster z.B. ab einem Füllstand von 80% warnt.

Ceph kann die klaren Erwartungen an ein modernes Storage-System in den meisten Fällen erfüllen. Die gegebene Flexibilität und die ständige Weiterentwicklung sichert eine einfache Anpassung an neue Anforderungen und ein sich ständig änderndes Umfeld. Somit ist mit etwas Planung, Monitoring und Liebe ❤ ein reibungsloser und stressfreies Betreiben über viele Jahre möglich.

Achim Ledermüller
Achim Ledermüller
Lead 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.
Lies mehr von Achim und triff unser Team

Out-of-Memory: Marathon 1.6+ und Heap Size

von | Jan 15, 2020 |

Auch wenn in Sachen Container Orchestrierung Kubernetes klar gegen Marathon und Mesos gewonnen hat bietet das Duo seit Jahren eine zuverlässig Plattform. Durch die stetige Weiterentwicklung und die Umstellung auf Systemd ändert sich leider auch immer wieder die Konfigurationen der Dienste.

Für einen stabilen Betrieb von Marathon sollte die maximale Heap-Size der Java Virtual Machine (JVM) eine angemessene Größe haben. Zu wenig Memory äußert sich z.B. durch erhöhte Antwortzeiten oder durch die Aktivierung des OOM-Killer. Wo in vergangenen Versionen und Konfigurationen noch die /etc/defaults/marathon zum Setzen der Javaoption verwendet wurde, kann man hier seit Marathon 1.6 vergeblich sein Glück suchen. Aus meiner Sicht ist ein Verzicht auf /etc/defaults/marathon und eine saubere Definition in einer systemd Unit-Datei natürlich zu begrüßen. Die Umgebungsvariablen lassen sich auch dort einfach definieren, aber wie genau muss das für Marathon aussehen?

# systemctl edit marathon.service
[Service]
Environment=JAVA_OPTS=-Xmx2g

Mit systemclt edit kann man eine bestehende Unit-Datei einfach erweitern und der Parameter Environment setzt die Umgebungsvariable.  Alternativ könnte man auch Environmentfile=/etc/defaults/marathon verwenden um das gewohnte Verhalten wieder herzustellen.

Nach dem Speichern braucht es einen Daemon-Reload, damit die neue Unit-Datei eingelesen wird.

# systemctl daemon-reload
# systemctl restart marathon.service

Eigentlich bleibt also alles beim Alten, man muss nur die zusätzlichen Parameter in die JAVA_OPTS setzen und den Service neu starten ?.

 

Achim Ledermüller
Achim Ledermüller
Lead 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.
Lies mehr von Achim und triff unser Team

Finde den Weg mit mtr und traceroute

von | Mai 8, 2019 | ,

Zum prüfen der Routing Pfade durch das eigene Netzwerk war bisher mtr mein bevorzugtes Tool. Mit  mtr -u 10.10.10.10 werden anstatt icmp udp Pakete/Pings verwendet wodurch man nach und nach alle Pfade durch das eigene Netzwerk findet.

Da sich aber seit Version 3.6 immer wieder das Verhalten des Linux Kernels bezüglich des ECMP Hashing geändert hat, kommt es auf Hosts mit mehreren Pfaden zum ersten Hop/Router immer häufiger vor, dass mtr nur einen Pfad anzeigt (je nach Kernel Version des Hosts). Dies kann sowohl an dem verwendeten Tool als auch an dem sysctl Parameter net.ipv4.fib_multipath_hash_policy liegen. Per default steht dieser auf 0 und bewirkt, dass nur die IP Adressen des Senders und des Empfängers zur Berechnung des Pfades verwendet werden. Setzt man die Hash Policy hingegen auf 1, werden zusätzlich die Ports von Sender und Empfänger mit in die Berechnung aufgenommen.

Da mtr die Ports nicht mit jedem Ping/Paket wechselt, findet man leider wieder nicht die Pfade zum ersten Hop. traceroute hingegen wechselt Sender- und Empfängerport mit jedem Paket wodurch nun alle Pfade gefunden werden. Leider ist traceroute nicht gleich traceroute. Unter Ubuntu findet man dies z.B. in den beiden Paketen inetutils-traceroute und traceroute, in zwei verschiedenen Implementationen mit unterschiedlichem Verhalten. Um unter Ubuntu alle Pfade zu finden sollte man sicherstellen, dass man die Binary aus dem Paket traceroute verwendet.

Kurz zusammengefasst gibt es für nicht angezeigte Pfade also mehrer Ursachen:

  • unterschiedliches ECMP Hashing im Linux Kernel (in Abhängigkeit der Version)
  • nicht explizit aktivierte Multipath Hash Policy
  • Verwendung von mtr oder einer unpassenden traceroute Implementation

Ich für meinen Teil werde bei mtr bleiben und einfach Sender und Empfänger vertauschen, der Router vor dem Empfänger macht ja schon immer alles richtig und berücksichtig auch Layer4.

 

 

 

Achim Ledermüller
Achim Ledermüller
Lead 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.
Lies mehr von Achim und triff unser Team

Trainings

Web Services

Events