Welcome to Part 8 of the Nimble OS 2.x Blog Post Series! In past bogs, we have covered how to scale-out systems by either merging in-use Nimble arrays together, or adding fresh uninitialised Nimble arrays alongside your current Nimble system. The next question that follows when in a scale-out scenario is "what happens with firmware updates?". Well today we're going to cover this subject.
In a scale-out design we introduce the concept of storage pools; which allows us to combine the resources of an arrays controller cpu, cache & capacity for ease of management and increased performance & capacity... OR we can silo Nimble arrays into their own pool for a muli-tenant or muti-department environment where performance and capacity needs to be guaranteed, yet management needs to be simple.
In both of the above scenarios, simplistic, reliable and automated array firmware upgrades may arguably become more important as data could be striped across multiple systems. This is something that engineering have built into the product meaning that all firmware upgrades are now automated and staggered throughout multiple arrays within the group.
In my lab environment i'm currently testing out some new builds of upcoming NOS2.1. I have two arrays (Optimus Prime & Megatron) in my group called Transformers (yeah, i'm a child of the 80s!). Optimus Prime is in the default pool, whilst Megatron is in its own pool called Decepticons. Below is my view from the Group GUI.
When I head to Administration-> Software I can now see what firmware version my group is running, and underneath I see the firmware details of each system within my group. When I click "download" to see the latest firmware available, it will be pulled down onto the nominated group leader at that point of time...
Just like in previous updates, I can then choose to update the array firmware at a later date (ie out of hours in a maintenance window). When the update is deployed, the group will update itself an array at a time rather than all arrays at once. As usual, before the update starts a series of pre-checks are ran to ensure that the group and each array will not suffer degraded performance or encounter any problems after the update is completed.
As you can see below I have deployed the update, with Optimus Prime updating first and Megraton second. Megatron only starts updating once Optimus Prime has completed and all post-update checks are complete & successful. Note: you cannot specify which array to update first in the process.
Finally once all arrays are updated successfully the GUI reflects that both systems within my group are up to date.
Whilst we're updating multiple systems within the group, as only ever a single array is updated at a time, there should be no outage or loss of data experienced similar to the experience of updating firmware in a single array environment.
I hope this has been useful and answered a question that may have been in the back of your mind when looking at some of the new functionality introduced in NOS 2.x.
My colleague Phil Davies will continue the series by looking at some subtle changes to array based replication... and then we'll be marching towards looking at some new things in the upcoming 2.1 release.
As always, please ask questions below!