So there is a lot of different constructs within ScaleIO that might make you relate to the picture above. However, do not fear. Lets go through the most critical ones, those that you simply must know in order to configure a system.

ScaleIO Data Server

I touched in this one in a previous post as well, but the SDS is the component from which you map in block devices that can then be pooled and mapped back to the clients.

ScaleIO Data Client

As the name implies, this is the client to which you map volumes to from within ScaleIO.

Meta Data Manager

The most critical component. There can be either 1, 3 or 5 of these depending on the size of the cluster but given that the minimum amount of SDS’s are 3, I see not reason to ever having less that 3. It’s very common to have the first 3 SDS’s also be the MDM’s. These are responsible for knowing where all your storage is at any given time. Loose more than half of these servers and you will be offline. Loose all of them permanently, pray that you didn’t just download free and frictionless and put it into production because you will need to contact support in order to get things back online again. The MDM do take a backup automatically so there should always be a way back from this.

Protection Group

This is the logical grouping of servers that will use each other for parity (provided they have disks in the same storage pool). You can add nodes to a protection group and then create storage pools within the protection group. After that you can add disks to the storage pool or you can introduce an extra layer called a fault domain in which you can add nodes and disks.

A single protection domain can have many storage pools and a storage pool can hold many protection domains and disks. The current maximum for disks in a single storage pool is 300.

Storage Pool

This would then be you group of similar disks. And when I say similar disks, I’m talking about speed. You don’t really have to care about the size of the disks, you have to care about the size of the node in comparison to all the other nodes with disks in that storage pool. Is a perfectly valid use case to have different sizes or nodes, you just have to set the reservation capacity so that its larger than the largest node. I’m I saying that you shouldn’t try to have homogeneous nodes? Absolutely not (personal preference).

It’s also here that you configure the spare percentage, IO priority, ram read cache, checksums and a bunch of other stuff.

Fault Set

Well, you now deployed a system across two racks and now you want to make sure that copy a is in rack a and copy b is in rack b. Well, too bad, you can’t because this has to be setup before putting data on the system. But let’s say that you were planning to do build a new system then this would be the concept you needed to achieve that requirement. Also, this can be used for other things like getting around the maximum size or node (yep, per node… not the physical server).

Order of doing things?

So, let’s put things into order.

  1. Build the MDM Cluster
  2. Build the protection domains
  3. Build the storage pools
  4. Build the fault sets (optional)
  5. Add in the SDS
  6. Add the drives

So, this may come as a shocker to you, but there are actually quite a few people around the world who doesn’t know what ScaleIO is, even though prominent people like Chad Sakac has mentioned it a myriad of times on his blog. But just to make sure that everyone know, here is another introduction.

ScaleIO is a Software Defined Storage-product from EMC. It’s primary focus is performance and thus it’s actually quite low on features compared to many other products out there. So if you’re looking for something that does replication, look the other way. If you’re looking for something that does deduplication, look the other way. If you’re looking for something that does anything else than block, look the other way. If you’re looking for something that does compression… you get the point. However, if you’re on the other hand looking for something that can be deployed on most anything, is incredibly performant and will tolerate a giant beating before letting you down, ScaleIO might be something for you.

Components

A ScaleIO-system consists of a few components:

  • SDC: ScaleIO Data Client
  • SDC: ScaleIO Data Server
  • LIA: Light Installation Agent
  • MDM: Metadata Manager
  • ScaleIO GUI
  • ScaleIO Gateway

There are a few more than these, but I’m skipping them since they have no interest to me 🙂

SDC

So as you can probably guess, the SDC is a component that needs to be installed on whatever OS you want to map some storage to.

SDS

The SDS is installed on all the servers which make up the “storage array”. So basically all the servers that has spare capacity which you then want to present backup the all the SDC’s. And yes, an SDS can be an SDC as well (think HCI for instance).

LIA

This is the agent that is installed on all nodes (both MDM, SDC, SDS) in the ScaleIO-system. This agent is used when you want to do something on the endpoints, ie. collect logs or upgrade the system to a newer release.

MDM

These babies holds the keys to the castle. The contain information on where all data is at any given point. You would typically install the MDM in a 3-node active/passive/witness cluster or a 5-node active/passive/passive/witness/witness configuration. The MDM can be standalone machines or could be installed on the SDS’s. They can be deployed as masters or tie-breakers.

GUI

The management interface for ScaleIO. Wont say to much about this, a picture does a better job.

Billedresultat for scaleio management

Gateway

An application that you would typically install on a server separate from the SDS/SDC/MDM-servers. This is because this component is used for deploying/reconfiguring/updating the system.

Billedresultat for scaleio gateway

Scale

Probably much more than you will ever need, but here is a few pointers.

  • Min/Max ScaleIO Installation Size: 300GB to 16PB
  • Individual Device Size: 100GB to 8TB
  • Volume Size: 8GB to 1PB
  • Max SDS Size: 96TB
  • Max SDS pr. System: 1024
  • Max SDS pr. Protection Domain: 128
  • Max Disks pr. Storage Pool: 300

Deployment Options

ScaleIO can be deployed in 3 different ways from a purely architectural point of view.

  • New and fancy HCI-mode. SDS + SDC on the same node.
  • Two-Layer mode. If you want to build it like you would any traditional storage system (other than the fact that it doesn’t share any other things that the deployment model)
  • Hybrid. Some nodes have both SDS + SDC, some only have SDS, others only SDC. Giant mashup.

Deployment Example

So now you’re thinking: “okay, fair enough.. but how are all these deployed into a storage system?”

To give you an example, lets say that you have 7 servers on which you want to deploy ScaleIO. A deployment example would be like this:

  • Server 1
    • MDM
    • SDS
    • LIA
  • Server 2
    • MDM
    • SDS
    • LIA
  • Server 3
    • MDM
    • SDS
    • LIA
  • Server 4
    • MDM (TB)
    • SDS
    • LIA
  • Server 5
    • MDM (TB)
    • SDS
    • LIA
  • Server 6
    • SDS
    • LIA
  • Server 7
    • SDS
    • LIA

What this gives you is a 5-node MDM cluster managing a 7-node SDS cluster all with LIAs installed so that it can be patched/managed from a single ScaleIO Gateway.

Wrap Up

So this was the extremely quick 40000 foot view of ScaleIO. If asked about it, I would characterize it like this.

  • True software defined storage.
  • Very flexible.
  • High performance
  • Very durable.

But I Want To Know More!

Might I then recommend reading the architecture guide (https://www.emc.com/collateral/white-papers/h14344-emc-scaleio-basic-architecture.pdf) or the user guide (https://community.emc.com/docs/DOC-45035). Both are very good and very detailed.