Skip to main content
RunBook Academy

CephL · Cluster DeploymentCluster Deployment

Time and name resolution as deployment prerequisites

Intermediate⏱ ~16 minchronycephdig

What you'll learn

  • Configure time synchronisation to Ceph's requirements
  • Configure forward and reverse name resolution
  • Recognise the symptoms of each being wrong
  • Verify both before deployment

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Not yet marked complete on this device.

Why this matters in production

Time skew and name resolution failures produce Ceph symptoms that look like Ceph problems — authentication failures, monitor warnings, hosts that will not join. Both are trivially verifiable and both are frequently assumed rather than checked.

Time

Ceph requires monitors to agree on time closely. The default tolerance is tight:

ceph config get mon mon_clock_drift_allowed      # 0.05 seconds
# chrony on every host
systemctl enable --now chronyd
chronyc tracking
chronyc sources -v
# /etc/chrony.conf
server ntp1.example.com iburst
server ntp2.example.com iburst
server ntp3.example.com iburst
makestep 1.0 3

Three or more sources so a single bad one is outvoted. Every Ceph host on the same sources so they converge together.

ceph -s | grep -i clock
ceph time-sync-status

Symptoms of skew: MON_CLOCK_SKEW warnings, cephx authentication failures that appear after a period of working, S3 RequestTimeTooSkewed errors, and monitor elections.

Name resolution

# forward
getent hosts ceph-osd-01
dig +short ceph-osd-01.example.com

# reverse — frequently the missing one
dig +short -x 10.20.0.21

Both directions must work, from every host. Reverse resolution is the one usually forgotten and it affects daemon identification and log clarity.

hostnamectl status
hostname -f

The hostname must match what the cluster knows the host as. A mismatch between hostname -s and the name used in ceph orch host add produces a host that appears added and never receives daemons.

Verification before deployment

for h in ceph-mon-01 ceph-osd-01 ceph-osd-02; do
  echo "== $h"
  ssh "$h" 'hostname -f; chronyc tracking | head -3; getent hosts $(hostname -f)'
  dig +short -x "$(getent hosts "$h" | awk '{print $1}')"
done

Running this across every intended host before bootstrap catches both classes of problem while they are cheap to fix.

Symptom mapping

SymptomCause
MON_CLOCK_SKEWtime
Auth works then failstime
RequestTimeTooSkewed on S3time
Host adds but gets no daemonshostname mismatch
Orchestrator cannot reach a hostforward resolution or SSH
Daemon names look wrong in logsreverse resolution

Quiz

Knowledge check · 4 questions

  1. Q1. A host was added successfully but never receives any daemons. What should you check?

  2. Q2. Ceph's default monitor clock drift tolerance is tighter than a tenth of a second.

  3. Q3. Diagnose authentication failures appearing after hours of correct operation.

    A new cluster worked correctly after deployment. Several hours later, cephx authentication began failing intermittently across multiple hosts. Nothing was changed. The cluster reports HEALTH_WARN.

  4. Q4. Why does reverse DNS matter for a Ceph deployment?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Verify time synchronisation and both directions of name resolution across every host before bootstrap; both produce symptoms that read as Ceph faults and both are confirmed in one loop. Point every Ceph host at the same three or more NTP sources so they converge together rather than independently.

Cross-course references

  • Kubernetes: certificate validity and etcd leases have the same clock sensitivity
  • Linux: Kerberos and TLS both fail in the same characteristic way under clock skew