As we've seen from previous blog posts in this series, moving from Nimble OS (NOS) 1.x to 2.x introduces some new concepts around storage management within a Nimble Storage environment. Chief amongst these new abilities is the scale out capability. Scale out allows Nimble Storage customers to grow their environment beyond a single array up to a maximum of four today. These can be identical arrays or from a different series (i.e. 2XX & 4XX) and each array could have been previously upgraded with additional cache or capacity.
We already saw how to do a basic merge of existing arrays in Rich Fenton's post Merging Two Arrays into a Single Group - Smells Like Scaleout and Rich touched on the concept of storage pools. Justin Rohan's blog Adding a New Array to an Existing Group shows us how to add new arrays in the GUI. However, when we scale out using completely different arrays with differing hardware capabilities, this can introduce some interesting results which we need to be aware of.
Definitions & Relationships
First of all let’s get some definitions out of the way. NOS 2.x introduces the terms groups and storage pools. These are defined as follows:
Group(s): Groups are multiple arrays that are managed as a single entity. Sharing an authentication secret word, the arrays share storage space and a management console. Today, you can have up to four arrays in a single group.
Storage Pool(s): A pool with one or more arrays across which data is stored (striped). Storage in all group members can be divided into storage pools. A storage pool must consist of at least one member array and can span to a maximum of four member arrays.
***Volumes are members of pools, pools are made up of one or more arrays, up to four arrays make a single group***
This diagram illustrates the relationship between groups, arrays, pools and volumes:
Day to Day Use
If you have a single array environment and upgrade from NOS 1.x to NOS 2.x, the system will automatically create a group name based on the original name of the array being upgraded and also create a default storage pool but you wont be able to see it within the GUI since there is only one array in the group. When you add a second new storage array into the group, you will be asked whether you want it to become part of the default storage pool or optionally, you can create a new storage pool for it immediately. Once you have done this, you will now be able to see the storage pools in the GUI.
The only exception to this rule is if you are merging two existing arrays as described in Rich Fentons blog. In this case, the second already configured array will be placed in a separate pool and its name will be default-oldarrayname. I will focus mainly on new arrays being added into a group but if you have questions on merging existing arrays, please ask them below.
With two or more arrays in a group and all arrays being a member of the default storage pool, when volumes are created, these volumes will be striped across all arrays by default. With Nimble Connection Manager (NCM blog for Windows & VMware) installed on your hosts, the hosts know where to locate data on each array. This gives the host an almost linear increase in performance for the volumes being accessed.
However, Nimble Storage arrays are already very powerful and striping of data across arrays may not be required. Many administrators may prefer to organise volumes in a more granular way. This becomes more of a factor when different array configurations have been merged into a single group. These different configurations occur from our ability to scale compute, scale cache and scale capacity independently on each array. This is illustrated below:
In this case, an administrator may want to separate out certain types of data so that they co-exist within different storage pools which in turn exist on separate arrays. For example, some common ways of segregating the storage pools could be based on application type, users or certain workloads. This is illustrated below where the pools have been segregated by application type:
Nodes one and two will be used exclusively for SQL and data will be striped across both nodes for performance and/or capacity reasons, while nodes three and four will both be used for Exchange and VDI deployments also for performance and/or capacity reasons.
For example, if you have a group that consists of both 2XX and 4XX systems then it is advisable to have different systems in separate pools. This is because each system has different performance characteristics and while you can in theory put them into the same storage pool, that storage pool will be unbalanced from a performance point of view. Arrays with different amounts of cache should be treated with caution for the same reason. Capacity is also something to be aware of however, if you have arrays with different amounts of capacity, the group will intelligently distribute data across nodes in a proportional way so that arrays with more capacity hold more of the volume. This can also lead to an unbalanced group if the volume is being used for high performance purposes. I would recommend speaking with your Nimble Systems Engineer or Nimble Support to discuss any plans to scale out to ensure no problems are encountered and best practices are followed. Additionally, Infosight can help to identify any issues that may need attention.
Using the GUI to Manipulate Storage Pools
To create a new storage pool from one or more arrays, you can do this by navigating to Manage -> Storage Pools. From here click on the New Storage Pool… button as per below:
Any uninitialised arrays will be shown here and you can select which arrays will become part of this new storage pool.
If you wanted to edit/add/remove storage pool configuration for existing arrays with data already on them, you can edit their setting by going to Manage -> Storage Pools. Select the pool you want to edit and click the Edit… button and from here you can add/remove arrays from a pool as shown below.
Warning! Be careful here. By unchecking an array in an existing pool, you will start an evacuation of the data on this array. This could take a long time depending on the amount of data on the array.
You can also merge pools if so desired by clicking the Merge Pools… button and selecting which pool to merge into the one currently being edited.
Moving volumes between pools is also something that can be done through the GUI.
NOTE: this is NOS 2.1.x functionality which will be released very soon!
To do this, go to Manage -> Volumes and you should see this in a multi-array group:
Select a volume and click the Move… button and you see something similar to below:
Select the destination pool that you want to migrate the volume to and then the move process begins once you click Move. Once again, be aware that moving large volumes between pools can take some time depending on the size of the volume and how busy the associated arrays are!
Hopefully this high level overview of storage pools has been helpful and more importantly, you can see where they can be very useful. In environments where multiple Nimble arrays are deployed, these can now be consolidated into one or more groups for unified management. We can merge for performance & capacity scaling or separate out the data through the use of storage pools for isolation by user type, application or workloads.
This is also a great way of re purposing arrays for different uses such as DR or for use on other sites. By evacuating arrays from pools, they can be safely removed from groups to be used elsewhere in your environment. This also provides the ability to continuously upgrade and enhance the storage environment as newer models of Nimble Storage arrays are released and older systems are retired.
Look out for the next post in this series from Phil Davies covering changes to replication in NOS 2.0.
Feel free to ask any additional questions you may have!