Capacity Planning and Optimization: IBM Storage Insights provides visibility into storage capacity utilization, trends, and forecasts. It helps organizations analyze historical data and predict future capacity requirements, facilitating effective capacity planning. By understanding storage utilization patterns, organizations can optimize their storage resources, avoid unnecessary purchases, and ensure efficient utilization of existing storage assets.
There are a number of components that are software defined that make IBM Storage Ceph work. The components include a monitor, a manager, and an Object Storage Daemon or OSD that is responsible for storing objects on a local file system and providing access to them over the network. Ceph was really built to have no single point of failure, and so IBM recommends to have minimum two to three of each of these services running at any time and you can run hundreds of services in a cluster and more than one service on a single host.
The IBM Storage Ceph "monitor" maintains a map of the entire cluster, so it has a copy of the OSD map, the monitor map, the manager map, and finally the data optimization map also known as the crush map. So these maps are extremely critical for the storage components to coordinate with each other. IBM requires at least three monitors when building storage clusters to ensure high availability, redundancy, and for the monitors to reach quorum.
IBM Storage Ceph managers do things like keeping track of the runtime metrics, as well as your system utilization, things like your CPU performance, disk load, things like that. So these managers also host the dashboard web GUI, was well as perform most tasks required for configuration and management of the system. IBM also recommends three managers, although two will suffice.
IBM Storage Ceph has something called an OSD or an “Object Storage Daemon”, but it also has things called OSD nodes. So with our clusters, the minimum OSD nodes to begin with is 3 for test/dev and minimum of 4 for production. So the OSD is where your data is stored, and they also handle things like rebalancing and replication. OSD’s will also send some information to your monitors and your managers so in nearly all cases you will have one OSD per HDD or SSD in your cluster. So you'll most likely have dozens or possibly hundreds or thousands of OSD’s depending on how big your cluster is, although three is the minimum to ensure redundancy and high availability.
The object-based interfaces or RADOS Gateway (RGW) ia meant to provide the end-user with RESTful based object storage into the cluster. So the RGW currently supports two different interfaces and those are S3 and Swift. So one unique feature about this is if the end user wants to use both the S3 and the Swift API; because it's under the same namespace, they can then write under one API and read with the other.
All these nodes have to communicate somehow and Ceph does it is through the network so IBM recommends a private network for your OSD’s and a public network for the rest of the cluster. It is important that OSD traffic is not restricted as they handle self-healing, replication, and moving data through the cluster, and so it's best to keep that off the public network Ceph can run on one gigabit networks, but typically its best with a 10 gigabit network and if desired one can use a LACP bonded 10 gigabit network to give 20 gigabit of bandwidth over your private networks.