A Match Made In The Midrange: IBM i And FlashSystem
June 3, 2024 Steven McIver
If you are only looking at IBM i from the “green screen,” not much has changed over the years. We run mostly the same commands and access the same operating system menus. It can seem like time has stood still and IBM i has not changed at all.
However, from the infrastructure point of view, that is certainly not the case. In this article, I want to focus on the popular external storage option for IBM i systems, which is FlashSystem. There have been some great new features that have been added lately to make the storage administrator’s life easier.
Dynamically Increasing the Size of LUNs
This one is not new, but I don’t believe the message has fully gotten out yet that it is now possible to increase the size of LUNs in IBM i. For those of you unfamiliar with the term LUN, it stands for Logical Unit Number, and in laymen’s terms it means “a virtual storage unit carved out of a physical storage unit.”
You no longer need to add more, larger LUNs and migrate to them in order to get larger LUN sizes. You simply hop on the FlashSystem, choose to increase the size of each LUN, wait till the additional space has been formatted, and then IPL in order for IBM i to see the increased space. If you had 10 LUNs at 100 GB a piece, you could increase them all to 200 GB (granted you have got extra space in your storage pool to give!) and double the size of your IBM i system without having to add and balance additional LUNs.
The minimum requirement is to be on IBM i 7.3 TR7 and later, 7.4 TR1 and later, or 7.5. More details about this can be found at https://www.ibm.com/support/pages/node/716777.
Volume Groups
This relatively new feature is a game-changer when it comes to removing pesky dependencies on volumes. FlashCopy and Remote Copy are fantastic features for getting instant copies of the system and replicating copies of the system, respectively. However, they can create a significant number of extra volumes that are tied to the source volumes and target volumes, and those dependencies can prevent you from doing cool things, like dynamically increasing the size of LUNs. Enter Volume Groups, which allow for the attaching of two recently added policies: Snapshot and Replication Policies. A volume group is simple to create. After creating a volume group, you add all of the source volumes into it. Then, you will create policies to add to the volume group.
Snapshot Policy
IBM seems to be moving to the more widely adopted term “snapshot” as opposed to their trademark FlashCopy. Both mean the same thing. With a snapshot policy, you define how often to perform snapshots and how long to retain them. This eliminates having to create FlashCopy consistency groups, which create dependencies by tying the source volumes to target volumes. The snapshot policy handles all that work for you.
Replication Policy
These policies greatly simplify the setup for replicating volumes to a target FlashSystem unit. An easy-to-use wizard guides you through creating the policy to replicate to a target unit. A massive change here is that you’re no longer given the perplexing question of whether to choose Metro Mirror, Global Mirror, or Global Mirror with Change Volumes, which most people do not understand the nuances of each one. Instead, you’re asked what your RPO (Recovery Point Objective) is, and the replication policy handles the rest for you in the background.
Like the snapshot policy, this eliminates the dependencies created by tying change volumes to both the source and target volumes. Another added perk is that you don’t even have to create the target volumes or volume group. Once you slap on the policy, it creates all that on the target FlashSystem for you! Note that Replication Policy is asynchronous only, so if the business demands a synchronous replication, you will still need to do Metro Mirror via Remote Copy.
Partnerships For More Than One FlashSystem
This is another major change that is very welcomed for mostly migration purposes. In the past, an IP Partnership, which has to be established for replicating volumes over an IP network, was only allowed to a single target FlashSystem. With the 8.6.0.0 and later code, you can now target additional FlashSystems. If you have two FlashSystems in an existing partnership, and you decide to put a FlashSystem in another data center, you can now target your IP replication on the Source FlashSystem to this newly added FlashSystem as well, without dismantling your currently in-sync replication.
This removes a lot of headache for the storage administrator when migrating, and the business keeps their data in-sync. A win-win!
All of these added features have me excited about the future of IBM i and FlashSystem storage. IBM understands what has been pain points in the past, and are working to make old processes work smarter and difficult configurations be easier. Can’t wait to see what they crank out next!
Steven McIver is an IBM i Senior System Administrator who has spent 16 years specializing in IBM i, IBM Power Systems and Storage. He has been with Service Express for four years, focusing on projects revolving around IBM i. Steven has been recognized as an IBM Fresh Face for his contributions to IBM i and Power Systems.
RELATED STORIES
Understanding The Power Of Power10
Power10 Upgrade Considerations You Need to be Aware Of
Service Express Buys iTech Solutions, iInTheCloud
iTech Solutions Keeps You In The Know With VERIFi
