Red Hat Ceph Storage for OpenStack – CL260 — Lesson 1: Ceph Architecture, Monitors, Managers, OSDs, CRUSH, and Cluster Deployment

Learning Objectives

• Explain the architecture, purpose, dependencies, and expected behavior of Ceph architecture, monitors and managers, and OSDs.
• Apply CRUSH maps and cluster deployment while preserving reviewable technical evidence.
• Recognize and correct the condition where an unstated prerequisite or ownership gap causes the initial design to be incomplete.

Detailed Topics

• Ceph architecture: apply the concept to the course scenario, identify dependencies and controls, and record objective evidence of the result.
• monitors and managers: apply the concept to the course scenario, identify dependencies and controls, and record objective evidence of the result.
• OSDs: apply the concept to the course scenario, identify dependencies and controls, and record objective evidence of the result.
• CRUSH maps: apply the concept to the course scenario, identify dependencies and controls, and record objective evidence of the result.
• cluster deployment: apply the concept to the course scenario, identify dependencies and controls, and record objective evidence of the result.

Instructor Demonstration

The instructor demonstrates ceph architecture, monitors, managers, osds, crush, and cluster deployment by tracing architecture, commands, configuration, system messages, and evidence. The walkthrough tests how an unstated prerequisite or ownership gap causes the initial design to be incomplete and explains how to isolate the cause without masking related issues.

Hands-On Exercise

Establish a controlled baseline for Ceph Architecture, Monitors, Managers, OSDs, CRUSH, and Cluster Deployment and add the verified result to the Ceph cluster build record, OpenStack integration design, health evidence, capacity plan, and recovery runbook.

1. Confirm scope, versions, access, dependencies, assumptions, and acceptance criteria.
2. Perform the workflow while recording commands, configuration, output, events, and decisions.
3. Test the normal path and one course-specific exception or boundary condition.
4. Retest the correction and document rollback, ownership, and follow-up actions.

Scenario Analysis

• Identify which dependency most strongly influences Ceph architecture in the stated scenario.
• Compare two approaches for CRUSH maps and explain the security, reliability, performance, and support trade-offs.
• Decide what evidence must be retained in the Ceph cluster build record, OpenStack integration design, health evidence, capacity plan, and recovery runbook before operational acceptance.

Troubleshooting Guidance

Begin with the first observable difference from the expected result. Check architecture, scope, identities, prerequisites, and starting conditions separately, then correlate logs, events, commands, metrics, and configuration history. Treat the assumption that an unstated prerequisite or ownership gap causes the initial design to be incomplete as a hypothesis until a reproducible retest confirms the cause.

Validation Checklist

• The required architecture, scope, identities, prerequisites, and starting conditions were checked and recorded.
• The normal path and a course-specific exception were tested.
• The Ceph cluster build record, OpenStack integration design, health evidence, capacity plan, and recovery runbook links conclusions to commands, configuration, logs, metrics, or other objective evidence.
• Corrective actions, rollback, ownership, and handover notes are complete.

Lesson Outcome

Learners can apply Ceph Architecture, Monitors, Managers, OSDs, CRUSH, and Cluster Deployment, explain the observed platform behavior, and support the result with a reviewable Ceph cluster build record, OpenStack integration design, health evidence, capacity plan, and recovery runbook.