Are any of you aware of best practices (or any practice ! ) to "reserve" some disk capacity when ACS does the initial configuration.
Step12 of ACS's onecommand does (on a 2TB drive in our 1/2 rack):
* Wipe clean the celldisks (created out of both HardDisk & FlashDisk LUNs/diskTypes)
* Create celldisks (out of both FlashDisk & HardDisk LUNs)
* Create FlashCache (feeding all the celldisks based out of FlashDisk-s)
* Reserve the sweetest 1832.546875G to temporary griddisks prefixed with TESTGD
* For the non-System LUNs, carve out griddisk from the interior-most disk part for 29.109375G
* Drop griddisk created to reserve the griddisks with prefix TESTGD (12 such griddisks in each of the 12 disks in each of the 7 cells)
* Now that we have the 1832.546875G back again, ACS allocated first 1466G from each of the 12 disks in the 7 servers to the DATA diskgroup.
* The remaining 366G went to RECO making the standard 80/20 split for DATA/RECO
Currently ACS does the DATA / RECO with a 80/20 split & 'utilizes' all HardDisk capacity into DATA/RECO.
Is there a way to reserve some capacity, so that 6 months down the line, I can decide, if I want to go with a 60/40 DATA/RECO split? Is it possible for me to move around the RESERVE capacity either to DATA or RECO later, whatwith the different disk sizes/performance characterirics due to differing disk geometry between RESERVE & DATA?
Since the order of griddisk creation matters, this looks tricky.
Creating new griddisks with prefix, say, RSRV for carving out the RESERVE capacity introduces performance issues because it has a low-performing 'offset' value than the currently provisioned DATA griddisks.
Also, there's the issue of the DATA & RSRV & RECO ASM disk size differences.
Or, should the reservation be done at a celldisk level? So that I don't carve concentric RESERVE griddisks in all the 12 disks of a cell, but rather, send some of the DATA griddisks to a diskgroup called RESERVE_DG? That might eliminate the mixing of differently performing disk geometries to be mixed up in the same DATA when I provision the storage from RESERVE.
I wish someone has gone through a similar puzzle before.
The order of creation doesn't have to matter - you can alternatively use the offset=<somenumber>g to offset the start of the griddisk as desired. If you don't use the offset attribute, the new griddisk will be created at the lowest offset location that has free space.
The deployment engineers have no mechanism available to leave space unallocated during initial deployment. However, customers are free to modify the deployment as needed.
However, the bigger question is: Why do you want to have a non-default deployment? The deployment employs best practices compiled over hundreds of deployments and unless your situation is very very unique, it is likely that you'll benefit from the best practices employed already.
Thanks for taking the time.
The main driver for this is: the databases that are going to be migrated into this 1/2 rack is not yet finalized. Different databases in-house here have different mission-critical, survival-critical ratings which will drive the decision if their backups are going to be stored in RECO or onto tape-drives on a dedup appliance.
So, after a year, we are hoping that the capacity in this 1/2 rack will be filled out and we will know the exact profile of the databases housed in the 1/2 rack and we want to be able decide IN THE FUTURE if we want to go with 80/20 or 60/40 DATA/RECO split.
1. Once you decide, how do you expect to use the empty space? You wouldn't want to add two griddisks from the same celldisk into the same diskgroup. You can resize the griddisks by adding to the end of them, but if you want to grow RECO, the process will be more involved since you'll need to move the starting point for that griddisk, not the ending point. Besides, see #2.
2. You can always change the griddisk configuration/sizing later without downtime (though it takes some administrator time, there is no DB or app downtime). The resize procedure is the same you'd likely use for #1.
I'd recommend starting with 60/40 for now if you're unsure since it is relatively easier to set the db_recovery_file_dest_size to limit reco usage. If later you want to change the storage layout, it can be done online. If the layout you choose works for you, no changes needed.
Thanks for your time & attention to this problem. We will go with #2 that you mentioned.
In addition to the pointers you made, we found the following note to be helpful:
How to resize ASM disk/Grid disk in Exadata Environment [ID 1245494.1]
Thanks again. Good day !