Seite wählen

NETWAYS Blog

Ceph Backfilling Crash: Datenintegrität manuell wiederherstellen

Seit vielen Jahren haben wir Ceph im Einsatz. Unser erstes produktives Cluster begleitet uns seit 2015. Auch wenn die ersten Major-Updates des Clusters holprig verliefen ist die nötige Pflege des Clusters mit jedem Release von Ceph geringer geworden. Abgesehen vom Einspielen der Updates oder dem Tauschen von kaputten Festplatten ist wenig am Ceph Cluster zu tun, umso unerwarteter traf uns ein Fehler in der Replikation der Snapshots. Die Lösung des Problems hat sich über eine längere Zeit gezogen und mit diesem Blogpost hoffe ich anderen Ceph-Administratoren schneller auf den richtigen Weg zu verhelfen. Aber zuerst eine kleine Begriffserklärung.

Wie werden Daten im Ceph gespeichert?

Speichert man Daten (z.B. Objekt O) in ein Ceph Cluster wird dieses einer Placementgruppe (PG 1.1) zugeordnet. PG 1.1 besteht aus drei Festplatten (wir nennen diese OSDs) und das Objekt O wird auf alle drei OSDs (osd.1, osd.2, osd.3) gespeichert.
Fällt nun osd.3 aus, wird eine andere Festplatte (osd.4) zu der PG 1.1 zugeordnet und Daten werden von osd.1 auf osd.4 kopiert. Dieser Prozess heißt backfilling. Die Verfügbarkeit und die Integrität der Daten ist währenddessen nie gefährdet und der Ausfall von osd.3 ist schnell wieder behoben. Die Bereitschaft wird nicht geweckt und die kaputte Festplatte wird zu normalen Betriebszeiten ersetzt.

Was ist schief gelaufen?

Beim backfilling einer PG kam es zu einem ceph_assert(clone_overlap.count(clone)) mit dem sich die OSDs der Placementgruppen selbst stoppen. In Kombination mit systemd wurden die OSDs mehrfach neu gestartet (bis zum erreichen der StartLimitsBurst) und sind immer wieder in den assert gelaufen wodurch wir folgende Ausgangslage vorfanden:

  • PG 1.1 hatte nur noch osd.1 mit vollständigen aktuellen Daten
  • osd.2 und osd.4 konnten auf Grund des Bugs nicht mit den aktuellen Daten versorgt werden (backfilling)
  • Tools zum debuggen des Problems lieferten keine Informationen
  • deep-scrub (und damit auch repair) haben den gleichen Bug ausgelöst

Wie das Cluster genau in den Zustand kam ist uns unklar. Wir vermuten eine Kombination aus einer kaputter Festplatte, durch den Bug verursachten Crashes der OSDs und dem gleichzeitigen erstellen und löschen von Snapshots.

Was bedeutet das für die Datenintegrität und Verfügbarkeit?

  • osd.1 hat alle aktuellen Objekte und ist voll funktionsfähig
  • ein Ausfall von osd.1 führt zu Datenverlust
  • ein temporärer Ausfall bzw. Neustart von osd.1 führt zur nicht Verfügbarkeit der Objekte in PG 1.1 (down)
  • eine automatische Replikation der Daten ist nicht möglich
  • Snapshots auf PG 1.1 werden nicht gelöscht und häufen sich an
  • Scrubbing für PG 1.1 wird nicht durchgeführt

 

Lösung

Die Logdatein der OSDs lassen vermuten, dass fehlerhafte Clones (osd_types.cc: In function ‚uint64_t SnapSet::get_clone_bytes(snapid_t) const‘) beim backfilling den ceph_assert(clone_overlap.count(clone)) auslösen. In den bekannten Mailinglisten haben wir erste Hinweise auf einen Bug gefunden der in allen aktuellen Versionen (Nautilus bis Quincy) zu finden ist.
Die hier aufgelisteten Befehle können sehr leicht zum Datenverlust führen. Die Informationen sollen jedem Ceph-Admin der in einer ähnlichen Lage ist Hilfestellung leisten. Wir können nicht gewähren, dass die Lösung auf allgemeingültig funktioniert!

Lösungsansätze waren dort auch zu finden, welche teilweise positiv aber auch negativ bestätigt wurden. Einige Betroffene konnten das Problem nur mit dem löschen der PG lösen, was mit Datenverlust einhergeht und natürlich zu vermeiden ist. In unserem Fall hatten wir die aktuelle Daten verfügbar und ein weiteres unabhängiges Ceph Cluster welches im Disasterfall ein maximal 24 Stunden altes Backup bereitstellt.

1. Verfügbarkeit des PG 1.1 gewährleisten

Damit der letzte verbleibende osd.1 nicht regelmäßig auf den Bug trifft und sich neu startet haben wir das backfilling verhindert (ceph daemon osd. config set osd_max_backfills 0). Damit ist osd.1 und damit PG 1.1 dauerhaft verfügbar und für alle Clients wie gewohnt nutzbar. Hiermit wird aber auch das backfilling für alle anderen PGs auf osd.0 verhindert.

2. Wiederherstellung der Replikation

Zur manuelle wiederherstellen der Replikation gibt es die Möglichkeit Placementgruppen aus einem gestoppten OSD zu exportieren und in andere OSDs wieder zu importieren. Man führt das backfilling sozusagen manuell aus. Hierbei spielt es eigentlich auch keine Rolle auf welchen OSD die PG eingespielt wird. Ceph erkennt selbstständig die PG (pg[…] transitioning to Stray) und kopiert die Daten selbstständig zum richtigen OSD. Je nach Situation kann es auch nötig sein die PG von allen OSDs zu entfernen. ceph pg 1.1 query liefert hier genauere Information zu den OSDs mit Objekten aus der PG.

Für die Prozedur benötigt man drei Befehle:

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --no-mon-config --pgid 1.1 --op export --file /tmp/pg-1.1.export 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-2 --no-mon-config --op import --file /tmp/pg-1.1.export

Die OSDs müssen dazu gestoppt sein und sollte die PG schon vorher auf dem OSD vorhanden sein muss diese zuerst gelöscht werden:

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-2 --pgid 1.1 --op remove --force

 

Wer noch Filestore OSDs betreibt muss den Befehl um --type filestore --journal-path /var/lib/ceph/osd/ceph-1/journal erweitern.
Mit Filestore sollten auch owner und group kontrolliert werden. Im Beispiel muss /var/lib/ceph/osd/ceph-2/current/omap und /var/lib/ceph/osd/ceph-2/current/1.1_head und mit chwon -R ceph:ceph wieder angepasst werden.

Durch diese Maßnahme konnten wir osd.2 und osd.4 wieder auf den aktuellen Stand bringen was folgende Verbesserungen bringt:

  • alte Snapshots auf PG 1.1 werden wieder gelöscht
  • backfilling kann wieder aktiviert werden, wovon alle anderen PGs auf osd.1 profitieren
  • scrubbing und repair funktioniert wieder

Im Vergleich zum Anfang ist das Cluster wieder in einem guten Zustand. Alle Objekte werden wieder repliziert, die Verfügbarkeit und Integrität der Daten ist gewährleistet und PG 1.1 häuft nicht weiterhin alte Snapshots an. Allerdings sind die ursprünglichen Probleme noch nicht gelöst, da wir nur eine exakte Kopie der Daten an anderen Stellen eingespielt haben. Sollte ein backfilling für PG 1.1 nötig sein würde das Problem weiterhin auftreten.

3. Erkennen und löschen der fehlerhaften Clones

Mit funktionierenden (deep-)scrubbing sammelt Ceph auch wieder Daten über Integrität und Zustand der Objekte und Clones in der PG 1.1.

rados list-inconsistent-snapset 1.1 –format=json-pretty zeigt gefundene Fehler, Inkonsistenzen und die dazugehörigen Metadaten wie Objektnamen, SnapIDs (dezimal) und Fehlerbeschreibungen. Wir mussten hier die Fehler clone_missing und extra_clones manuell beheben. Weiter Fehler wie z.B. mismatch kann Ceph selbst im repair beheben.

Hinweis zum Format: Objekte und Clones werden in der Regel in folgendem Format angezeigt: rbd_data.dad3d1238e1f28.00000000000062d5:107BE rbd_data.dad3d1238e1f28 ist der block name prefix. 0000000000062d5 der Objektname. 107BE die SnapID (wird manchmal auch als Dezimalzahlen angezeigt).

Sind die Objekte identifiziert zeigt einem das ceph-objectstore-tool die nötigen Details um die Fehler zu beheben.

ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --op list rbd_data.dad3d1238e1f28.00000000000062d5 
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2225964,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}] 
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2226131,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}] 
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2224480,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]
["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":-2,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]

 

Jede Zeile beschreibt einen Clone oder das Objekt selbst und wird als Parameter zum bereinigen der Fehler gebraucht.

Bereinigen von clone_missing

Im Fall von clone_missing kann man Metadaten eines Clones manuell vom Objekt entfernen. Hierfür wird remove-clone-metadata verwendet. Das Objekt des Snapshots wurde bereits entfernt.

ceph-objectstore-tool --pgid <pgid> '<Objektzeile>' remove-clone-metadata <snapid-decimal> 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 --pgid 1.1 '["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":-2,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]' remove-clone-metadata 2225750

 

Bereinigen von extra_clones

Bei extra_clones handelt es sich um Clones welche im Filesystem noch zu finden sind, aber eigentlich schon gelöscht sein sollten. Man findet diese auch direkt im Filesystem. Diese kann man mit dem ceph-objectstore-tool entfernen:

ceph-objectstore-tool 'Snapshotzeile' remove 
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-1 '["1.1",{"oid":"rbd_data.dad3d1238e1f28.00000000000062d5","key":"","snapid":2224480,"hash":2449849216,"max":0,"pool":1,"namespace":"","max":0}]' remove

 

Résumé

Das Bereinigen der Inkonsitenzen im Snapshot war der letzte Schritt zum wiederherstellen des Clusters. Diese Lösung zu finden hat mehrere Tage gedauert unter anderem auch weil wir natürlich das Löschen und wieder einspielen der PlacementGroup in einem anderen Cluster ausführlich getestet haben.

Brauchst Du Hilfe bei mit deinem Ceph Cluster? Schreibe uns gerne eine Nachricht oder melde Für mehr Inhalte zu dem Thema abonniere unser Newsletter.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

NWS-ID for your Managed Kubernetes!

First Cloud, now Kubernetes – the integration of NWS-ID with our portfolio continues! As a next step, we will merge your Managed Kubernetes clusters with NWS-ID. Credit goes to Justin for extending our cluster stack with OpenID-Connect (OIDC), the base for NWS-ID!

How can you use your Kubernetes Cluster with NWS-ID?

All you need is kubelogin, a plugin for kubectl, and a customized kubeconfig, which can be downloaded in the NWS Customer Interface. But: this applies to newly started clusters only. Older installations need some action from you! Let’s go and see, what other scenarios there are!

If you have a cluster running with a Kubernetes v1.23 or greater, just enable NWS-ID in the Customer Interface. This will restart the kube-apiserver with some new parameters which will authenticate your requests against NWS-ID using OpenID-Connect.

For clusters in version v1.22 or less you need to update your cluster at least to v1.23 and enable NWS-ID in the Customer Interface. After your cluster is ready for NWS-ID you need to pimp your kubectl for OpenID-Connect.

kubectl and kubelogin

kubelogin is a plugin for kubectl, which enables authentication via OIDC. It is easily installed with brew, krew, choco or Github Releases as described in the official documentation. After the installation, just download your kubeconfig for NWS-ID from the Customer Interface and start using kubectl as usual!

If you have multiple Managed Kubernetes clusters it is easy to switch the context with kubectl config use-context MyCluster.

Permissions and Roles

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. As admin you can grant two different roles to your colleagues. Choose between admin and reader which will be mapped the to corresponding Kubernetes cluster role.

If you need some more detailed help, just have a look into our docs for User and Groups and Permissons.

What are the advantages of integrating our Managed Kubernetes with NWS-ID?

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

  1. use a single login for the NWS Customer Interface, the Cloud Interface and your Kubernetes clusters
  2. effortless switch between your Managed Kubernetes clusters with a single kubeconfig
  3. use two-factor authentication for your Kubernetes clusters
  4. authorise your colleagues to access your clusters in the NWS-ID group management

What happens to the existing certificate authentication?

The authentication with the X509 client certificate is still available for everybody with the appropriate permissions in your organization.

 

Thanks again to Justin for expanding our Kubernetes stack! 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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

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

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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Let me introduce: NWS-ID

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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Storage Wars – Using Ceph since Firefly | OSDC 2019

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
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.