When it's time to expand storage capacity or change the composition of a storage system that has usually meant a great deal of planning and manual work. In the case of a traditional array, it can mean a forklift upgrade in redeployment or it's time spent balancing new and unused capacity with capacity that's already present. Furthermore, units of scale tend to be so large that initial over provisioning is very likely with the software defined storage solution, administering and coordinating a large number of nodes, software updates can be the time consuming part of the process.
Fortunately scale IO makes these changes as snap at every stage of the process and will see it in action. First, let's briefly cover the aspects of scale io's architecture that make this possible. First of all, scale IO is elastic, the composition of a system is never fixed so it can grow larger and smaller while remaining online and serving data. It can use both flash and hard drive based storage in the same system and nodes can freely participate as servers clients or both. It's just a matter of loading the appropriate software onto the node ski IO knows how to transition a pool of storage to a larger or smaller size using a many to many copy operation. This takes the shortest amount of time while making sure that the system's existing data will be fully balanced across nodes and devices.
In fact, any given volume will have its data distributed amongst the devices in the system automatically as it's written. So any scale IO client will be reading and writing data on many different scale IO servers simultaneously. For the purposes of growing a scale IO system. It's important to realize that from the client point of view, its data is laid out in a meshed mirrored configuration with the scale IO server software responsible for making sure all data is written onto two separate nodes with scale server and client software as well as a hypervisor all residing on the same node.
This demo will showcase a common converged architecture. The system is run by metadata manager software that resides on multiple nodes and acts as a cluster. Its job is to coordinate system activity and storage layout. When new nodes are brought into a scale IO system, the hardware deployment wizard takes care of automating the following steps, discovering the new nodes and giving them a network configuration, installing and configuring KEO software setting up new storage poles or integrating the new nodes into existing ones, contacting the V center installation and registering the new nodes is part of a VMWARE ex cluster. Then the nodes are online and operational and scal io Rebalances in the background. Let's see it.
In action, we're going to expand an existing system of six nodes that have a mixture of flash and spinning storage media with five nodes that have only flash media. This will have the effect of both increasing the size of the pole and redistributing the data already in the flash storage pole among all the new devices. Although this upcoming demonstration has continuously running load with some variability, it is meant to be a demonstration of continuous operation and not speed first because all this can happen while the system is serving data. I've got a virtual machine deployed to every node running VD bench and generating some storage traffic to all the other nodes.
Now I'll run the no deployment wizard from the menu here. The management server is searching for nodes running a factory image and waiting to be contacted since they don't have a networking configuration yet. They need to be in the same broadcast domain as the management server. All right, it's found all five nodes. If we click deploy, then scale will use the IP address ranges specified during management server set up. Advanced will let us review and assign any IP addresses. We want. This lab's network environment has predefined IP address and node pairings. So in this case, we'll use manually assigned IP addresses instead of assigning them sequentially from the pool. At this point, the nodes are ready to be deployed.
This next step will perform installation and set up of scale io no input is required other than the command to proceed the add nodes step selects a protection domain for the new nodes to join or a new one can be created if one doesn't exist already or if a new one is needed. We are expanding an existing protection domain in this case. Now, the cache configure step lets us assigned storage devices appropriate for our needs. We're adding nodes that only have S SDS in order to add performance and capacity. Therefore, everything will stay as used for storage. Though, if we had nodes with both S SDS and spinning disk drives, we could set up an accelerated storage pool with some S sds and disk drives and use other S sds as a flash only pool in the same node.
Next, we've come to the add devices step. We can assign devices that we set to storage in the previous step to existing storage pools or create new ones. Currently, we have an existing hard disk drive storage pool with cash and an existing storage pool with SDS scale has grouped similar devices and by default, we'll be adding these sds to the existing flash pool. At the end of the step scale, io's management server makes an API call to the V center server and adds our new nodes so that they can participate in the same hypervisor cluster. Note that there might be some other hypervisor configuration tasks here that would depend on the environment. The system happens to be running in altogether.
It's taken about 23 minutes as shown by the timer here for the discovery and deployment part of the process. Now the storage pole will automatically rebalance in the background to take advantage of the new devices that have been added. Let's fast forward a few weeks. These five nodes have served their purpose in providing a great deal of flash storage temporarily to our hypervisor cluster. Now they're needed in another configuration elsewhere. Scale ao's ability to resize and rebalance on the fly means that we can remove any of these nodes and keep volumes intact and serving data the entire time when a node is selected for removal, scal o selects a data layout that will allow for all the data currently on devices that are about to be removed to occupy a different location on the remaining devices.
Data is copied to the new location. And when it's all in place, the old note is dropped from the system without needing any further actions. As long as we have enough remaining capacity to copy data to we could continue to remove storage devices. Let's see it in action. First, we'll move over to the hardware tab here, we can select the nodes that we intend to remove and then cue them since we have enough capacity on the nodes that will remain in the system to contain all the data in that storage pool. It's just a matter of rebalancing it across the disks that will remain here. Scalia opens a separate job window for pending actions. Now it's just a matter of time and the data will be evacuated and rebalanced onto the remaining nodes leaving us with the original six. When expanding a storage pool, rebalance operations tend to be a little faster than removing them.
Since all the data on those nodes needs to be moved elsewhere. Now, we're going to fast forward while the Scalia system is handling both regular IO and rebalancing as it shrinks into fewer nodes. At this point. You can see that there's no longer data pending to be rebalanced and that we've gone from 11 SDS components back to six. Once any VM guests have been evacuated from these nodes on the hypervisor side, they're ready to be powered off and repurposed on the hardware tab, the nodes that we removed show is online but that their disks are no longer participating in the scale IO system, selecting those same nodes and using remove node and unassigned IP addresses will free up those IP addresses to be assigned to other nodes.
Later note the set identification led option which could be used to locate and identify the physical nodes in question. So there you have it growing a scale IO system is as easy as discovering nodes and incorporating them into an existing cluster. And letting scale IO do all the work of optimization and protection. Shrinking a Scalia system is as easy as selecting the nodes to be removed and waiting, whether you're growing or shrinking scal io automates the work of making changes to capacity and eliminates the bottlenecks of manually migrating or rebalancing your data.
