Reference guide
Page 12
Figure 6:
HPE Apollo 4200 System rear view with “2 small form factor rear drive cage plus 2 PCIe card expander” option
Configuration guidance
This section covers how to create a SUSE Enterprise Storage cluster to fit your business needs. The basic strategy of building a cluster is
this: with a desired capacity and workload in mind, understand where performance bottlenecks are for the use case, and what failure domains the
cluster configuration introduces. After choosing hardware, SUSE Enterprise Storage Administration and Deployment Guide is an excellent place
to start for instructions on installing software.
General configuration recommendations
•
The slowest performer is the weakest link for performance in a pool. Typically, OSD hosts should be configured with the same quantity, type,
and configuration of storage. There are reasons to violate this guidance (pools limited to specific drives/hosts, federation being more
important than performance), but it’s a good design principle.
•
A minimum recommended size cluster would have at least six compute nodes. The additional nodes provide more space for unstructured
scale, help distribute load per node for operations, and make each component less of a bottleneck. When considering rebuild scenarios, look at
the capacity of a node in relation to available bandwidth. Higher density nodes work better in larger, faster clusters, while less dense nodes
should be used in smaller clusters.
•
If the minimum recommended cluster size sounds large, consider whether SUSE Enterprise Server is the right solution. Smaller amounts of
storage that don’t grow at unstructured data scales could stay on traditional block and file or leverage an object interface on a file-focused
storage target.
•
SUSE Enterprise Server clusters can scale to hundreds of petabytes, and you can easily add storage as needed. However, failure domain
impacts must be considered as hardware is added. Design assuming elements will fail at scale.
SSD journal usage
If data requires significant write or PUT bandwidth, consider SSDs for data journaling.
Advantages
•
Separation of the highly sequential journal data from object data—which is distributed across the data partition as RADOS objects land in their
placement groups—means significantly less disk seeking. It also means that all bandwidth on the spinning media is going to data I/O,
approximately doubling bandwidth of PUTs/writes.
•
Using an SSD device for the journal keeps storage relatively dense because multiple journals can go to the same higher bandwidth device
while not incurring rotating media seek penalties.
Disadvantages
•
Each SSD in this configuration is more expensive than a spinning drive that could be put in the slot. Journal SSDs reduce the maximum
amount of object storage on the node.
•
Tying a separate device to multiple OSDs as a journal and using XFS—the default file system the
Ceph-deploy
tool uses—means that loss of
the journal device is a loss of all dependent OSDs. With a high-enough replica and OSD count this isn’t a significant additional risk to data
durability, but it does mean architecting with that expectation in mind.
