Leistung · Audit

Ceph-Audit, bezahlt nur bei Befund

Wir lesen deinen Cluster aus, rechnen nach und legen dir eine priorisierte Liste hin: was falsch steht, was es kostet, was die Korrektur auslöst. 479 € netto, fällig nur, wenn wir etwas finden. Finden wir nichts, bekommst du den Bericht trotzdem und keine Rechnung.

479 € netto
Festpreis je Cluster
Keine Tagessätze, keine Nachträge. Bis 12 Nodes und 120 OSDs, darüber machen wir vorher ein Angebot.
0 € bei Nullbefund
Das Risiko liegt bei uns
Enthält der Bericht keinen Befund aus den fünf Kategorien unten, stellen wir nichts in Rechnung. Den Bericht bekommst du trotzdem.
5 Arbeitstage
Vom Datensatz zum Bericht
Kein Workshop, kein Projekt, kein Change an eurer Umgebung. Ihr liefert die Ausgabe lesender Kommandos, wir liefern die Auswertung.
Kurz erklärt. OSD = ein Laufwerk im Ceph-Cluster mit dem Prozess davor. Placement Group (PG) = Zwischenschicht, auf die Ceph Daten verteilt, bevor sie auf OSDs landen. CRUSH = die Regel, die festlegt, wo Kopien liegen dürfen. size / min_size = wie viele Kopien es gibt und wie wenige reichen, damit noch geschrieben werden darf. Balancer = Ceph-Modul, das Ungleichverteilung selbsttätig ausgleicht.
Zwei Blickwinkel

Dieselbe Sache, einmal kaufmännisch und einmal technisch

Ein Ceph-Cluster ist selten laut, wenn er falsch steht. Er ist nur langsamer, voller und fragiler, als er sein müsste, und das fällt erst auf, wenn eine Node ausfällt oder der Speicherplatz gekauft werden soll, den man eigentlich schon hat.

Für die Geschäftsführung

Was du für 479 € abkaufst

  • Ein Ausfallrisiko, das du bisher nicht beziffern kannstDie häufigsten Ceph-Fehlkonfigurationen sind still: Der Cluster läuft grün, bis genau ein Server ausfällt. Dann steht er. Der Bericht sagt dir vorher, ob das bei euch so ist.
  • Hardware, die ihr schon bezahlt habtEin Cluster ist voll, wenn das vollste Laufwerk voll ist, nicht wenn der Durchschnitt es ist. Ungleichverteilung ist gekaufter, aber nicht nutzbarer Speicher. Die Rechnung dazu steht weiter unten.
  • Eine Entscheidungsvorlage, keine BeratungsschleifeJeder Befund kommt mit Ist-Wert, Zielwert, erwarteter Wirkung und dem Aufwand der Korrektur. Das lässt sich in zwanzig Minuten durchgehen und priorisieren.
  • Kein Vendor-Lock und keine FolgeverpflichtungDer Bericht gehört euch. Ob ihr die Änderungen selbst umsetzt, euren Dienstleister damit beauftragt oder uns, ist danach eine freie Entscheidung.
Für die Technik

Was der Bericht tatsächlich enthält

  • Kein Fragebogen, sondern KommandoausgabenGrundlage ist die Ausgabe von ceph osd df tree, ceph osd pool ls detail, ceph osd crush rule dump, ceph config dump und Konsorten. Nicht das, was jemand aus dem Gedächtnis in ein Formular schreibt.
  • Jeder Befund mit seiner QuelleZu jedem Punkt steht der Befehl da, aus dessen Ausgabe er stammt, mitsamt Zeile. Du kannst den Bericht gegenprüfen, bevor du ihn glaubst oder bezahlst.
  • Auch das, was ihr nicht anfassen solltetEine PG-Erhöhung löst ein Rebalancing aus, das tagelang läuft. Wo eine Korrektur teurer ist als der Zustand, steht das im Bericht statt einer Empfehlung.
  • Ihr behaltet die Kontrolle über den ZugangDrei Stufen, von gar kein Zugriff über einen Read-only-Cephx-Key bis zu einem SSH-Login, der genau ein root-eigenes Skript ausführen darf und sonst nichts. Alle drei stehen unten zum Kopieren.
Das Preismodell

Was als Befund zählt

„Nur bei Befund“ ist nur dann ein Versprechen und kein Streitpunkt, wenn vorher feststeht, was ein Befund ist. Deshalb steht es hier und nicht im Kleingedruckten. Ein Punkt zählt, wenn er aus den erhobenen Daten reproduzierbar ist, eine konkrete Empfehlung trägt und in eine dieser fünf Kategorien fällt.

KategorieWas als Befund zähltWoran du es selbst nachprüfst
DatenverlustEine Replikations- oder CRUSH-Einstellung, bei der ein definierter Einzelausfall Daten unerreichbar oder unwiederbringlich macht. Etwa size 2 mit min_size 1 oder eine Failure Domain auf OSD- statt auf Host-Ebene.ceph osd pool ls detail
ceph osd crush rule dump
VerfügbarkeitEin Einzelfehler, der den Cluster als Ganzes anhält: Monitor-Quorum ohne Reserve, kein zweiter Manager, kein Standby-MDS bei genutztem CephFS.ceph mon dump
ceph -s
KapazitätDer Cluster erreicht bei fortgeschriebenem Wachstum oder beim Verlust einer Node die nearfull-Schwelle, obwohl die rechnerische Nettokapazität das nicht hergeben müsste.ceph df detail
ceph osd df tree
LeistungEine Einstellung, deren Abweichung vom Zielkorridor aus euren Daten quantifizierbar ist: PG-Zahl, OSD-Streuung, Geräteklassen, DB/WAL-Platzierung, osd_memory_target, MTU oder Bonding.ceph osd pool autoscale-status
ceph config dump
BetriebEtwas, das den Cluster arbeitsunfähig macht, ohne dass er es meldet: abgeschalteter Balancer, seit Wochen nicht abgeschlossene Scrubs, abgekündigte Ceph-Version, uneinheitliche Daemon-Versionen.ceph balancer status
ceph versions
Was ausdrücklich kein Befund ist. Geschmacksfragen, Stilkritik an eurer Namensgebung, allgemeine Hinweise aus der Dokumentation ohne Bezug zu euren Werten und alles, was wir nicht mit einer Kommandoausgabe belegen können. Wir sind daran interessiert, dass der Bericht auch dann trägt, wenn ihr ihn eurem eigenen Storage-Team vorlegt.
Prüfumfang

Acht Stellschrauben, an denen wir zuerst nachsehen

Das ist keine vollständige Liste, aber es sind die Stellen, an denen wir in fremden Clustern am häufigsten etwas finden. Alle acht lassen sich aus lesenden Kommandos beurteilen, keine davon braucht einen Testlauf auf eurer Produktion.

StellschraubeWoran wir es sehenWas die Korrektur bewirkt
PG-Zahl je Poolceph osd pool autoscale-statusFeinere Verteilung, geringere Streuung der OSD-Füllstände, damit mehr nutzbare Kapazität. Zielkorridor sind rund 100 bis 150 PGs je OSD über alle Pools.
Failure Domain der CRUSH-Regelceph osd crush rule dumpSteht sie auf osd statt host, können mehrere Kopien derselben PG auf einem einzigen Server liegen. Der Nodeausfall wird dann vom Routinefall zum Stillstand.
size und min_size je Poolceph osd pool ls detailmin_size 1 heißt: Ceph bestätigt Schreibvorgänge, von denen genau eine Kopie existiert. Fällt dieses OSD vor der Replikation aus, ist der Schreibvorgang weg.
Balancerceph balancer statusAbgeschaltet oder im veralteten Modus bleibt die Ungleichverteilung bestehen, obwohl Ceph sie selbst auflösen könnte. upmap arbeitet feinkörniger als crush-compat.
DB- und WAL-Platzierung bei HDD-OSDsceph osd metadataLiegt die RocksDB-Metadatenschicht auf derselben drehenden Platte wie die Nutzdaten, konkurrieren Metadaten- und Datenzugriffe um dieselben Kopfbewegungen. Auf Flash ausgelagert ändern kleine Schreibvorgänge ihren Charakter.
osd_memory_targetceph config dumpDer Wert bestimmt die Größe des BlueStore-Caches je OSD. Ob eine Erhöhung bei euch etwas bringt, verrät das Verhältnis von bluestore_onode_hits zu _misses, und genau das rechnen wir aus, statt es pauschal zu empfehlen.
Netzwerk: MTU, Bonding, cluster_networkip -d link, ethtool -SUneinheitliche MTU erzeugt Fragmentierung und Neuübertragungen, die im Monitoring als „Storage ist langsam“ ankommen. Läuft Recovery-Verkehr über denselben Pfad wie Client-Verkehr, wird jeder Plattentausch zum Latenzereignis.
Scrub-Fensterceph config dumpDeep Scrubs ohne Zeitfenster laufen mitten im Tagesgeschäft. osd_scrub_begin_hour und osd_scrub_end_hour verschieben sie, ohne dass die Prüfung entfällt.
Rechenbeispiel

Was eine falsche PG-Zahl an Kapazität kostet

Zu wenige Placement Groups kosten keine Bandbreite, sondern Speicherplatz. Ceph warnt bei nearfull, sobald ein einzelnes OSD 85 Prozent erreicht, nicht wenn der Durchschnitt es tut. Je gröber die Verteilung, desto weiter liegt das vollste Laufwerk über dem Mittel, und desto früher ist die Kapazitätsplanung zu Ende.

Gleicher Cluster, zwei ZuständeZu wenige PGsIm Zielkorridor
OSDs24 × 8 TB24 × 8 TB
Rohkapazität192 TB192 TB
Netto bei dreifacher Replikation64 TB64 TB
PGs gesamt, mal size 3, je OSD128 → 161024 → 128
Abstand des vollsten OSD zum Mittel+22 %+4 %
Mittlerer Füllstand bei nearfull0,85 / 1,22 = 70 %0,85 / 1,04 = 82 %
Nutzbar, bevor der Cluster warnt44,6 TB52,3 TB
So ist gerechnet. Rohkapazität geteilt durch drei ergibt die Nettokapazität. nearfull_ratio steht ab Werk auf 0,85 und greift je OSD. Liegt das vollste OSD um x über dem Mittel, endet der nutzbare Mittelwert bei 0,85 geteilt durch (1 + x). Das ist reine Arithmetik, keine Messung: die 22 % und die 4 % sind Beispielwerte für die beiden Fälle. Deine eigene Zahl steht bereits in ceph osd df, in der Zeile STDDEV und in der Spanne zwischen MIN und MAX bei %USE. Genau die setzen wir im Audit ein und rechnen mit euren Werten statt mit unseren.
Und die Gegenrichtung, weil sie zum ehrlichen Bild gehört: Mehr PGs sind kein Turbo. Jede PG kostet Arbeitsspeicher und CPU auf jedem beteiligten OSD, und eine Erhöhung löst ein Rebalancing aus, das bei einem gut gefüllten Cluster Tage laufen kann. Deshalb steht im Bericht zu jedem Vorschlag nicht nur die Wirkung, sondern auch, was seine Umsetzung im laufenden Betrieb auslöst. Wie sich Ceph gegenüber ZFS überhaupt rechnet, steht ausführlich im Deep Dive Ceph oder ZFS: ab wann sich Scale-out wirklich rechnet.
Zugang

Drei Stufen, und ihr entscheidet

Wir brauchen Kommandoausgaben, keinen Zugriff. Deshalb gibt es das Audit in drei Ausführungen, die sich nur darin unterscheiden, wer die Befehle ausführt. Am Ergebnis ändert sich wenig, am Vertrauensbedarf sehr viel.

🔒

Stufe 1: ohne jeden Zugang

Ihr ladet das Sammelskript herunter, lest es, führt es selbst aus und bekommt ein Tar-Archiv. Das seht ihr durch, bevor ihr es uns schickt. Wir haben zu keinem Zeitpunkt Zugriff auf eure Systeme. Das ist die Voreinstellung.

kein SSHkein Keyihr lest alles vorher
🔑

Stufe 2: Read-only-Cephx-Key

Ihr legt einen Ceph-Nutzer mit den Capabilities allow r an. Damit lässt sich kein einziger schreibender Befehl absetzen, das verhindert Ceph selbst. Wir fragen den Cluster direkt ab und können bei Rückfragen nachsehen, statt euch erneut zu bitten.

kein SSHkein Schreibrechtjederzeit widerrufbar
🖥

Stufe 3: SSH auf genau ein Skript

Ein eigener Nutzer, dessen Schlüssel fest auf einen einzigen Aufruf verdrahtet ist: dasselbe Skript aus Stufe 1, root-eigen und für den Nutzer nicht schreibbar. Kein Shell-Zugang, keine Weiterleitung, kein zweiter Befehl. Sinnvoll, wenn wir auch Hardware- und Netzwerkebene sehen sollen und ihr das nicht selbst je Node abtippen wollt.

ein Befehlläuft nach 14 Tagen abAbbau dokumentiert
Ein Skript für alle drei Stufen. Stufe 1 und Stufe 3 verwenden dieselbe Datei. Das ist Absicht: Der sudo-Eintrag aus Stufe 3 erlaubt nicht „ceph“ und nicht „cat“, sondern genau diesen einen Dateipfad, dessen Inhalt ihr vorher gelesen habt. Ein Sudo-Recht auf ceph * wäre bequemer und würde nebenbei ceph osd out mit erlauben. Ein Sudo-Recht auf cat würde jede Datei auf dem System einschließen, auch die Keyrings. Beides tun wir deshalb nicht.
Stufe 1

Das Sammelskript

Lesende Befehle, ausschließlich. Keine Objektdaten, keine Keyrings, keine IP-Adressen, kein Schreibzugriff. Einmal je Node ausführen, der Cluster-Teil wird nur dort erhoben, wo ceph -s ohnehin antwortet.

Je Node eine Zeile
curl -fsSL https://precipice.tech/ceph-audit.sh | sudo bash
Das Skript verschickt nichts. Es legt ein Tar-Archiv im aktuellen Verzeichnis ab, sonst nichts. Ihr seht es durch und entscheidet danach, was ihr uns davon gebt; den Übergabeweg vereinbaren wir mit der Auftragsbestätigung. Wer das Skript erst lesen will, nimmt curl -fsSLO https://precipice.tech/ceph-audit.sh, sieht die Datei durch und führt sie dann mit sudo bash ceph-audit.sh aus. Es ist dasselbe Skript, das hier steht.
ceph-audit.sh
#!/usr/bin/env bash
# ceph-audit.sh  --  liest den Zustand eines Ceph-Clusters aus.
#
# Nur lesende Befehle. Keine Objektdaten, keine Keyrings, keine Adressen,
# kein Schreibzugriff. Ergebnis ist ein Tar-Archiv im aktuellen Verzeichnis,
# das vor dem Versand vollstaendig durchgesehen werden kann.
#
# Aufruf je Node:
#   curl -fsSL https://precipice.tech/ceph-audit.sh | sudo bash
#
# Lieber erst lesen, dann ausfuehren? Genauso richtig:
#   curl -fsSLO https://precipice.tech/ceph-audit.sh
#   less ceph-audit.sh
#   sudo bash ceph-audit.sh
#
#   --stdout        Archiv nach stdout statt in eine Datei (Abruf ueber Stufe 3)
#
# Das Skript verschickt nichts. Es legt ein Archiv ab, mehr nicht.

set -u
umask 077

STDOUT=0

while [ $# -gt 0 ]; do
  case "$1" in
    --stdout)    STDOUT=1; shift ;;
    -h|--help)   sed -n '2,22p' "$0" 2>/dev/null || true; exit 0 ;;
    *)           printf 'Unbekannte Option: %s\n' "$1" >&2; exit 2 ;;
  esac
done

OUT="precipice-ceph-$(hostname -s)-$(date +%Y%m%d-%H%M)"
mkdir -p "$OUT"
SEC="00-lauf.txt"

run() {                              # jeden Befehl mit seiner Ausgabe ablegen
  printf '\n### %s\n' "$*" >>"$OUT/$SEC"
  if command -v "$1" >/dev/null 2>&1; then
    "$@" >>"$OUT/$SEC" 2>&1 || printf '(Befehl endete mit Fehler %s)\n' "$?" >>"$OUT/$SEC"
  else
    printf '(Befehl nicht vorhanden)\n' >>"$OUT/$SEC"
  fi
}

if command -v ceph >/dev/null 2>&1 && ceph -s >/dev/null 2>&1; then
  SEC="01-cluster.txt"
  run ceph -s
  run ceph health detail
  run ceph versions
  run ceph df detail
  run ceph mon dump
  run ceph quorum_status
  run ceph time-sync-status

  SEC="02-osd.txt"
  run ceph osd tree
  run ceph osd df tree
  run ceph osd perf
  run ceph osd dump
  run ceph osd metadata

  SEC="03-pools-pg.txt"
  run ceph osd pool ls detail
  run ceph osd pool autoscale-status
  run ceph pg stat
  run ceph pg dump summary
  run ceph balancer status

  SEC="04-crush.txt"
  run ceph osd crush rule dump
  run ceph osd crush tree --show-shadow

  SEC="05-config.txt"
  run ceph config dump
  run ceph mgr module ls
  run ceph fs status
fi

SEC="06-host.txt"
run uname -a
run lscpu
run free -m
run lsblk -o NAME,ROTA,SIZE,MODEL,TRAN,MOUNTPOINT
run nvme list
run numactl --hardware
run tuned-adm active
for q in /sys/block/*/queue/scheduler; do
  [ -r "$q" ] && printf '%s: %s\n' "$q" "$(cat "$q")" >>"$OUT/$SEC"
done
run cat /sys/kernel/mm/transparent_hugepage/enabled

SEC="07-netz.txt"                    # Link-Ebene, bewusst ohne IP-Adressen
run ip -d link show
for i in $(ls /sys/class/net | grep -v '^lo$'); do
  run ethtool "$i"
  run ethtool -S "$i"
done
run sysctl net.core.rmem_max net.core.wmem_max net.core.netdev_max_backlog \
    net.ipv4.tcp_rmem net.ipv4.tcp_wmem net.ipv4.tcp_congestion_control

SEC="08-betrieb.txt"
run systemctl list-units --all --no-pager 'ceph*'
run timedatectl
printf '\n### slow requests der OSDs, letzte 7 Tage (nur die Anzahl)\n' >>"$OUT/$SEC"
journalctl -u 'ceph-osd@*' --since '-7 days' --no-pager 2>/dev/null \
  | grep -ci 'slow request' >>"$OUT/$SEC"

# ceph.conf ohne die Schluesselzeilen
if [ -r /etc/ceph/ceph.conf ]; then
  sed -E 's/^([[:space:]]*key[a-z_]*[[:space:]]*=).*/\1 <entfernt>/I' \
      /etc/ceph/ceph.conf >"$OUT/09-ceph.conf.txt"
fi

if [ "$STDOUT" -eq 1 ]; then          # nur fuer den Abruf ueber Stufe 3
  tar czf - "$OUT"
  rm -rf "$OUT"
  exit 0
fi

ARCHIV="$OUT.tar.gz"
tar czf "$ARCHIV" "$OUT" && rm -rf "$OUT"
PFAD="$(cd "$(dirname "$ARCHIV")" && pwd)/$(basename "$ARCHIV")"
GROESSE="$(du -h "$ARCHIV" 2>/dev/null | cut -f1)"
PRUEFSUMME="$(sha256sum "$ARCHIV" 2>/dev/null | cut -c1-64)"

echo
echo "Fertig: $ARCHIV  ($GROESSE)"
echo "Vorher ansehen: tar xzf $ARCHIV && less ${OUT}/*"
[ -n "$PRUEFSUMME" ] && echo "SHA-256: $PRUEFSUMME"
echo
echo "Die Datei bleibt hier liegen, das Skript verschickt nichts:"
echo "  $PFAD"
echo
echo "Schickt sie uns, wenn ihr sie durchgesehen habt. Den Uebergabeweg"
echo "vereinbaren wir mit der Auftragsbestaetigung."
Was drin bleibt, weil der Bericht sonst ins Leere zeigt: Hostnamen, OSD-IDs, Pool-Namen, Gerätemodelle und die Netze aus ceph config dump. Was wir herausnehmen: Schlüsselzeilen aus der ceph.conf und die IP-Adressen der Interfaces. Wenn euch etwas davon zu viel ist, streicht die Zeile aus dem Skript und schickt uns den Rest. Wir sagen euch dann, was ohne sie nicht beurteilbar bleibt.
Stufe 2

Read-only-Zugang über Cephx

Ceph bringt seine eigene Rechteverwaltung mit. Ein Nutzer mit allow r kann Zustand lesen und nichts verändern, unabhängig davon, was wir tun oder lassen.

Read-only-Nutzer anlegen und wieder entfernen
# Anlegen. 'allow r' laesst keinen schreibenden Befehl zu.
ceph auth get-or-create client.precipice-audit \
     mon 'allow r' mgr 'allow r' osd 'allow r'

# Die Ausgabe ist ein Keyring. Uebergabe bitte ueber einen Kanal,
# der nicht das Postfach ist: verschluesseltes Archiv oder Passwort-Safe.

# Nach dem Audit, ein Befehl:
ceph auth del client.precipice-audit

# Kontrolle, was der Nutzer durfte und ob er weg ist:
ceph auth get client.precipice-audit
Wo die Grenze dieser Stufe liegt. allow r schließt schreibende Befehle aus, ist aber eine breite Leseberechtigung auf den Cluster. Wer auch das Lesen von Cephx-Schlüsseln anderer Clients ausschließen will, nimmt Stufe 1: dort bekommen wir nur, was ihr uns nach Durchsicht gebt. Diese Stufe ist der Komfortweg, nicht der strengste.
Stufe 3

SSH, das genau einen Befehl kann

Vier Blöcke, in dieser Reihenfolge. Danach existiert ein Zugang, der buchstäblich nichts anderes kann, als das Skript auszuführen, das ihr vorher gelesen habt. Der Abbau steht darunter und dauert eine Zeile.

Zugang einrichten · auf jedem Node
# 1) Nutzer ohne Passwort, mit Ablaufdatum in 14 Tagen
sudo useradd -m -s /bin/bash precipice-audit
sudo passwd -l precipice-audit
sudo chage -E "$(date -d '+14 days' +%F)" precipice-audit

# 2) Das Skript gehoert root und ist fuer den Nutzer nicht schreibbar.
#    Damit kann der Zugang seinen eigenen Befehl nicht umschreiben.
curl -fsSLO https://precipice.tech/ceph-audit.sh
sudo install -o root -g root -m 0755 \
     ceph-audit.sh /usr/local/sbin/precipice-ceph-audit.sh

# 3) sudo genau fuer diese eine Datei. Kein 'ceph *', kein 'cat'.
printf '%s\n' \
  'precipice-audit ALL=(root) NOPASSWD: /usr/local/sbin/precipice-ceph-audit.sh --stdout' \
  | sudo tee /etc/sudoers.d/precipice-audit >/dev/null
sudo chmod 440 /etc/sudoers.d/precipice-audit
sudo visudo -c

# 4) Unser Schluessel, fest auf genau diesen Aufruf verdrahtet.
#    'restrict' schaltet Portweiterleitung, Agent, X11 und TTY ab.
#    Den vollstaendigen Schluessel bekommt ihr mit der Auftragsbestaetigung,
#    er wird je Kunde neu erzeugt und nach dem Audit vernichtet.
sudo install -d -m 700 -o precipice-audit -g precipice-audit \
     /home/precipice-audit/.ssh
printf '%s %s\n' \
  'restrict,command="/usr/bin/sudo -n /usr/local/sbin/precipice-ceph-audit.sh --stdout"' \
  'ssh-ed25519 AAAA...ERSETZEN... [email protected]' \
  | sudo tee /home/precipice-audit/.ssh/authorized_keys >/dev/null
sudo chown precipice-audit:precipice-audit /home/precipice-audit/.ssh/authorized_keys
sudo chmod 600 /home/precipice-audit/.ssh/authorized_keys
Abbau · jederzeit, ohne Rücksprache
sudo rm -f /etc/sudoers.d/precipice-audit \
           /usr/local/sbin/precipice-ceph-audit.sh
sudo userdel -r precipice-audit
Warum das sicher ist, und zwar nachprüfbar. Der Eintrag command= in der authorized_keys ist eine Zwangszuweisung: Was der Client als Befehl schickt, wird verworfen, ausgeführt wird immer nur der hinterlegte Pfad. restrict nimmt Portweiterleitung, Agent-Weiterleitung, X11 und die TTY-Zuteilung dazu. Der sudoers-Eintrag nennt eine einzelne Datei samt Argument, die root gehört und die der Nutzer nicht verändern kann. Es gibt keinen zweiten Befehl, keine interaktive Shell und keinen Weg, den Zugang zu etwas anderem umzubiegen. Prüfen lässt sich das mit sudo -l -U precipice-audit und einem Blick in die authorized_keys.
Grenzen

Was wir in keiner der drei Stufen tun

Diese Liste ist kein Vorsatz, sondern ergibt sich aus den Befehlen oben. Sie lässt sich am Skript nachlesen, und genau dazu ist es da.

Keine Nutzdaten

Es gibt keinen Befehl im Skript, der ein Objekt, ein RBD-Image oder eine Datei aus CephFS liest. Wir sehen Namen, Größen und Verteilung, nie Inhalte.

kein rados getkein rbd export
🔑

Keine Schlüssel

Kein ceph auth ls, kein Keyring, keine RGW-Zugangsdaten. Die ceph.conf geben wir nur mit ausgeschnittenen Schlüsselzeilen weiter.

kein auth lskey-Zeilen gefiltert

Kein schreibender Befehl

Kein ceph config set, kein osd out, kein Neustart eines Daemons. Auch keine Lasttests wie ceph tell osd.* bench, die eure Produktion während der Messung ausbremsen würden.

read onlykein Benchmark
🗑

Keine Aufbewahrung ohne Grund

Das erhobene Material liegt auf unseren eigenen Servern in Deutschland und wird nach Abgabe des Berichts gelöscht, auf Wunsch mit schriftlicher Bestätigung. AVV nach Art. 28 DSGVO auf Anfrage.

ComplianceLöschung bestätigt
Ablauf

Vier Schritte, keine Termine dazwischen

01

Stufe wählen

Ihr schreibt uns, welche der drei Stufen es sein soll und wie groß der Cluster ist. Wir bestätigen den Festpreis und, bei Stufe 3, den kundeneigenen Schlüssel.

02

Daten erheben

Skript laufen lassen, Archiv durchsehen, übergeben. Das ist der einzige Punkt, an dem ihr etwas tut, und er dauert je Node ein bis zwei Minuten.

03

Auswertung

Wir rechnen mit euren Werten: PG-Verhältnis, Streuung, Kapazitätsprojektion, CRUSH-Topologie gegen die tatsächliche Rack- und Hostverteilung, Netzwerk gegen die Fehlerzähler.

04

Bericht

Priorisierte Befunde, je mit Ist-Wert, Zielwert, Quelle, Wirkung und Umsetzungsrisiko. Dazu eine Seite Zusammenfassung, die auch ohne Ceph-Kenntnisse trägt. Danach entscheidet ihr, ob überhaupt etwas passiert.

Häufige Fragen

Was vor der Beauftragung gefragt wird

Was kostet das Ceph-Audit und wann wird es fällig?+

479 Euro netto als Festpreis je Cluster, bis 12 Nodes und 120 OSDs. Fällig ist der Betrag nur, wenn der Bericht mindestens einen Befund aus den fünf definierten Kategorien enthält: Datenverlust, Verfügbarkeit, Kapazität, Leistung oder Betrieb. Finden wir nichts, bekommt ihr den Bericht trotzdem, mit der Aufstellung dessen, was geprüft wurde, und wir stellen nichts in Rechnung. Größere Cluster kalkulieren wir vorher.

Wer entscheidet, ob etwas ein Befund ist?+

Die Kategorien und die Kriterien stehen vor der Beauftragung auf dieser Seite, nicht im Bericht. Ein Punkt zählt nur, wenn er aus den erhobenen Daten reproduzierbar ist und im Bericht mit der Kommandoausgabe belegt wird, aus der er stammt. Ihr könnt jeden Befund selbst nachvollziehen, bevor ihr die Rechnung bezahlt. Allgemeine Hinweise ohne Bezug zu euren Werten zählen ausdrücklich nicht.

Müssen wir euch SSH-Zugang geben?+

Nein. Die Voreinstellung ist Stufe 1: Ihr führt das Sammelskript selbst aus, seht das Ergebnis vollständig durch und schickt uns nur, was ihr schicken wollt. Wir haben dann zu keinem Zeitpunkt Zugriff. Stufe 2 gibt uns einen Cephx-Nutzer mit reinem Leserecht, Stufe 3 einen SSH-Login, der ausschließlich das eine hinterlegte Skript ausführen kann und nach 14 Tagen abläuft. Alle drei liefern denselben Bericht.

Kann das Skript etwas kaputt machen?+

Es enthält ausschließlich lesende Befehle. Kein ceph config set, kein osd out, kein Daemon-Neustart und bewusst auch kein Benchmark wie ceph tell osd.* bench, der während der Messung Last erzeugen würde. Das Skript steht vollständig auf dieser Seite, damit euer eigenes Team es vor der Ausführung durchgeht. Die Laufzeit liegt je Node bei ein bis zwei Minuten.

Warum sudo auf ein Skript statt auf ceph und cat?+

Weil ein Sudo-Recht auf ceph nebenbei ceph osd out und ceph config set mit erlauben würde, und ein Sudo-Recht auf cat jede Datei auf dem System einschließlich der Keyrings. Ein Eintrag auf genau einen root-eigenen Dateipfad lässt sich dagegen nicht ausweiten: Der Nutzer kann die Datei nicht verändern, und der SSH-Schlüssel ist per command= fest auf diesen Aufruf verdrahtet.

Bekommen wir Zahlen, die auf unseren Cluster passen?+

Ja, das ist der Punkt. Die Rechenbeispiele auf dieser Seite sind Arithmetik mit Beispielwerten und als solche gekennzeichnet. Im Bericht stehen eure eigenen Werte: die Streuung aus ceph osd df, die daraus folgende nutzbare Kapazität, das Verhältnis von PGs zu OSDs je Pool und die Trefferquote des BlueStore-Caches. Was wir nicht messen können, behaupten wir auch nicht.

Setzt ihr die Änderungen auch um?+

Auf Wunsch, aber getrennt beauftragt und getrennt kalkuliert. Das Audit ist bewusst so geschnitten, dass es auch dann etwas wert ist, wenn ihr danach nichts mit uns macht. Wer den Betrieb ganz abgeben will, findet die laufenden Konditionen unter Preise und die Reaktionszeiten unter Support und SLA.

Was passiert mit den Daten nach dem Audit?+

Das Material liegt während der Auswertung auf unseren eigenen Servern in Deutschland, nicht bei einem Cloud-Anbieter. Nach Abgabe des Berichts löschen wir es, auf Wunsch mit schriftlicher Bestätigung. Einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO stellen wir auf Anfrage, Details dazu stehen unter Compliance.

Steht euer Cluster richtig?

Schreibt uns die Eckdaten: Anzahl Nodes, Anzahl OSDs, Ceph-Version und welche der drei Zugangsstufen es sein soll. Wir bestätigen den Festpreis und schicken euch das Skript. Bezahlt wird erst, wenn etwas gefunden wurde.