This document provides an overview of Ceph storage, including: 1) Ceph addresses challenges faced by traditional storage such as increasing data growth and legacy infrastructure limitations through a software-defined storage approach. 2) Ceph's architecture is based on RADOS which uses four daemons - monitors, object storage devices, managers, and metadata servers - to distribute and organize data across pools and placement groups. 3) Clients can access Ceph storage using the Ceph native API, Ceph block device, Ceph object gateway, or Ceph file system.

1. CEPH
STORAGE
Architecture & Administration
By Liam Dao

2. for Red Hat Ceph Storage
01
Preparing

3. Chapter Overview
Goal ● Identify challenges faced by traditional storage and
explain how Ceph addresses them.
Objectives ● Summarize the challenges faced by traditional
storage solutions and explain the use case for
software-defined storage in general and Ceph in
particular.
● Describe the architecture of Red Hat Ceph Storage,
explain how it distributes and organizes data, and
list the methods that clients can use to access that
data

4. Data Storage Challenges
1
2
3
4
5
6
7
Data Keeps Growing
Integration of Emerging
Technologies
Legacy Storage
Infrastructure
Responsiveness
Performance, Resilience
and DR
Opportunity Cost
Different Types of
Storage

5. Software Defined Storage
Before SDS

6. Software Defined Storage
After SDS

7. Ceph Storage
Definition
-> An open source, petabyte-scale distributed storage
system primarily for object-based, block-based and
file-based store

8. Ceph Storage
Design goals:
● Be scalable for every component
● Provide no single point of failure
● Be software-based (not an appliance) and open
source (no vendor lock-in)
● Run on readily available hardware
● Be self-managed wherever possible, minimizing
user intervention

9. Ceph Storage
Use case:
● Storing images and virtual block device storage
for an OpenStack environment (using Glance,
Cinder, and Nova)
● Applications that use standard APIs to access
object-based storage
● Persistent storage for containers
● Rich media applications

10. Ceph Storage
Features:
● Multisite and disaster recovery options
● Flexible storage policies
● Data durability via erasure coding or replication
● Deployment in a containerized environment

11. RADOS
-> the Ceph storage back end
-> based on 4 daemons :
● Monitors
● Object Storage Devices
● Managers
● Metadata Servers
Architecture

12. RADOS Daemons
MONs
MGRs
OSDs
MDSs
Monitors: maintain maps of
the cluster state and are used
to help the other daemons
coordinate with each other
Object Storage Devices: store
data and handle data
replication, recovery, and
rebalancing
Managers: keep track of
runtime metrics and expose
cluster information
Metadata Servers: store
metadata used by CephFS

13. Access Methods
Ceph Native API
(librados)
-> allows applications to work
directly with RADOS to access object
stored by the Ceph Cluster

14. Access Methods
Ceph Block Device
(RBD)
-> Provide block storage within a
Ceph cluster through RBS images.

15. Access Methods
Ceph Object Gateway
(RADOS Gateway - RGW)
-> object storage interface, provides
applications with a gateway with
RESTful API

16. Access Methods
Ceph File System
(CephFS)
-> parallel file system that provides
a scalable, single-hierarchy shared
disk

17. Access Methods
4 types of accessing
● Ceph Native API
● Ceph Object Gateway
● Ceph Block Device
● Ceph File System

18. Data Distribution & Organization
Pools
-> Logical partitions of the Ceph
storage cluster
-> Each Pool is assigned number of
hash Buckets (Placement Group)

19. Data Distribution & Organization
Placement Group (PG)
-> aggregates a series of objects
into a hash bucket, or group, and it
mapped to a set of OSDs
CRUSH algorithm
-> Used to select the OSDs hosting the
data for a pool

20. Data Distribution & Organization
Mapping an Object to Its Associated OSDs:

21. Data Distribution & Organization
Mapping an Object to Its Associated OSDs:
1. Ceph get the latest copy of the cluster map from monitor
2. Calculate the PG ID for an object
○ by the object’s name and object’s storage pool
3. CRUSH algorithm determine the Acting Set
○ Acting Set: which OSDs are responsible for a PG
○ The first ODS in the acting set is the current primary ODS, All other is the
secondary
○ Ceph client can then directly work with primary ODS in order to access the
object

22. Next Chapter
Chapter 2: Deploying Red Hat Ceph Storage
Goal ● Deploy and expand a new Red Hat Ceph Storage
cluster
Objectives ● Plan a Red Hat Ceph Storage deployment based on the
software's prerequisites.
● Describe supported configurations for Red Hat Ceph
Storage.
● Deploy a Red Hat Ceph Storage cluster using Ansible.
● Add OSDs to nodes in an existing cluster to increase
capacity and performance.