There are many factors, that reflects the layout of the machine.
1.) Array(s): with one Array over all Disks i get the best balance of performance from the physical disks. Take in account that the storage system will scale with the amount of Devices build in. A FS5035 will scale up to about 14 SSDs. More drives will increase capacity, but no more performance. But if i need multiple pools, this will result in multiple Arrays. Each Array with DRAID6 will cost at least Capacity of 3 Disks (P+Q+Spare). Mirror for instance works only between pools. Normally with the capacities i am working, i use a single array. My hint : use STORM
2.) Pools : on Pool level you have to decide if you want to use DataReductionPools or traditional Pools. As DRP has some restrictions related to the way it is working, DRP will cost capacity on the one hand and, if compression or Dedup activated, also CPU Cycles. Related to the workload, the CPU cycles may cause a noticible decrease in performance. I normally consider only traditional Pools.
On Pool level, the extentsize was defined. Also here : use STORM
3.) LUNs : They are build from an integer of the extents. Each LUN will be processed by one Core. So you should build at least so many LUNs as your Storage has cores. You can combine those LUNs within most of the Host OS, but there are also restrictions. Windows and Linux can do a real RAID0, so they will spread the Data across all LUNs. VMware will fill one LUN after the other, so no performanceincrease related to one big LUN.
As you can see every Layout is a compromise between performance, capacity and handling options
4.) OS : Each OS can display the net capacity in a different way. First they will setup their filesystem on the LUN, that costs capacity and on the second hand i do not know how each OS will count written capacity (# of physically written bytes from the App to the Filesystem, # of Blocks the filesystem writes to the storage, does the file overhead be considered or not). As mentioned above, each OS will handle disks in different way and all these processes may change from one Release to the next.
5.) Compression and Dedup are related to the data. If data is encrypted, compression and dedup will only cost CPU, but you will not get more capacity as physically is build in. Veeam writes encrypted data and taking into account that there are bad guys out there, i expect that the applications will increase, that are writing encryted data. If you will be prepared for a ransomware attack, you should not calculate on Dedup or compression while doing a capacity sizing.
6.) Apps : they can change the way of life with a new release also. In the presentation i am doing a test with one small document, i found on our server. This document was created with an older version of a popular writing app. Opening this old doc with the latest version of the App and saving it with the new format will reduce the needed amount of space on the storage from the filesystemview. The calculated compression ratio will decrease.
Thinking of pictures : over time the resolution of the digicams increased, so the needed storage gets bigger and bigger. Doubling the resolution will need 4 times the capacity. if you size the storage keeping a number of photos can result in a misconfiguration very quickly.
You see, there are many considerations, so that i cannot give you THIS ONE GUIDELINE, because each customer has other expectations, other security considerations, other data and other workflow. Every machine setup is based on experience and customer conditions
kind regards
------------------------------
Martin Haussmann
SE
TD SYNNEX
------------------------------
Original Message:
Sent: Wed August 09, 2023 02:07 PM
From: Sandeep Sharma
Subject: IBM Flash System - Provisioned and written capacity does not match actual capacity
Can you share those guidelines, I have customer query asking for the same.
------------------------------
Sandeep Sharma
Original Message:
Sent: Wed July 26, 2023 02:39 PM
From: Alejandro Rojas
Subject: IBM Flash System - Provisioned and written capacity does not match actual capacity
Hi Martin! Thank you for your reply, it's very clear. And, for the record, you are right, I have FCM installed.
So, according to your answer, I guess there are some guidelines or best practices about LUN sizing, right? I'll check out the official documentation in order to improve my capacity planning, but at least I have an explanation.
Cheers!
------------------------------
Alejandro Rojas
Original Message:
Sent: Wed July 26, 2023 02:21 AM
From: Martin Haussmann
Subject: IBM Flash System - Provisioned and written capacity does not match actual capacity
Dear Alejandro
You did not tell us about the build in drives in your FS5200. Here in Europe, we will mostly use FlashCore Modules instead of Flash Drives. FlashCore Modules or FCMs did Hardwarecompression within the drive. In the Screenshot, you see a usable Capacity of 34 TiB, this is the physical Capacity without the HW compression.
You have a sum of nearly 50TiB provisioned Capacity with a compression of nearly 2:1, so i think you have FCMs installed.
On the other hand a volume exists (on the storage) as a number of extents. So for example a Volume with 500kB will use one 1 GB extent. The difference will be lost. If you write 250k to that Volume, and remember the compression. So it is not unsusual that you get different numbers.
If you look from a Server to that volume, a server will write infrastructure information to that drive (File Allocation Table), that consumes space and will not be shown as available Capacity. So a formatted drive will never show the same number, as the storage will show.
And pay attention to the unit, you are talking. There are decimal TB and binary TiB. The difference between is about 9% in the Terabyte Range. The Storage is talking binary, but what does the server OS do? Will it count the 250k from the example above or does it count the number of blocks written multiplied with the blocksize?
Write 12k of Data to the storage with 8k Blocksize, you will need at least two blocks/ I/Os. Does the server count 12k or 16k?
Creating a LUN may result in one extent not fully utilized and is one of the reasons, that results in capacity differences. You have a lot of LUNs, so there might be a "lot " of wasted capacity. I am not sure, if the storage counts number of extents vs. "real" capacity provisioned.
So you can see, there are a lot of things to be considered talking about capacity.
kind regards
Martin
------------------------------
Martin Haussmann
SE
TD SYNNEX
Original Message:
Sent: Tue July 25, 2023 11:05 AM
From: Alejandro Rojas
Subject: IBM Flash System - Provisioned and written capacity does not match actual capacity
Hello everyone! I'm trying to find out why provisioned & written capacity showed in FS dashboard does not match with actual prov. & writt. capacity.
I have an IBM Flash System 5200 with one Pool (DRP disabled; no thin provisioned volumes) with many LUNs mapped to AIX hosts. This is what I see in the storage dashboard.
49,97 TiB (54,94 TB) provisioned capacity and 22,09 TiB (24,2 TB) of written capacity.
The thing is, if I do some maths I have 51,6 TB provisioned. There is a 3,3TB gap.
And, the written capacity is pretty much the same.
I got 25 TB assigned to filesystems but only 19,4 TB written.
I already check that every LUN is mapped to a host and every mapped LUN belongs to a volume group (even database VG or rootvg, there are no other VGs).
This is really confusing, so I will appreciate any help.
Have a good day, cheers!
------------------------------
Alejandro Rojas
------------------------------