NetApp COE Lab - Upgrade / Expansion / Reorganisation

[rbo]

we have the chance to upgrade the FAS2552

1. to a newer ONTAP version
2. Disks from 900GB to 1.2TB
   • if additional capacity is needed a change from Double Parity to Single Parity could also be done in the future - online without an disruption (as you know the slogan in IT).

/cc @mschindl

[mschindl]

Command log for disk replacements and aggregate recreation, because there is no auto-expand option:

fas2552::*> set adv
> to get more fancy function (advanced mode)
fas2552::*> storage aggregate show-spare-disks
> check if enough spares are available
fas2552::*> disk fail -disk 1.0.23 -immediate true
> fail old disk
fas2552::*> disk assign -disklist 1.0.23 -owner fas2552-01 -force true
> assign new disk from other controller
fas2552::*> disk show 1.0.23
> shows for example old information of the replaced disk
fas2552::*> storage aggregate remove-stale-record -nodename fas2552-01 -aggregate <...>
> remove old information from disk
fas2552::*> disk show 1.0.23
> 1.0.23 is now a spare
fas2552::*> storage aggregate show-spare-disks
> show current available spare disks
**> WAIT up to 10 minutes**
fas2552::*> disk zerospares
> just best practise
fas2552::*> aggr status -aggregate *fas2552_0* -fields raidstatus,state
> check aggr state
fas2552::> disk replace -disk 1.0.1 -action start -replacement 1.0.21
> replace old (smaller) disks with newer one

[mschindl]

Additional tipps behind the scenes:

Storage administrators have the ability to move volumes between aggregates and controllers in the ONTAP cluster non-disruptively to the storage consumer
[ONTAP: Move a volume](https://docs.netapp.com/us-en/ontap/volumes/move-volume-task.html)

This operation does not affect Trident or the Kubernetes cluster, as long as the destination aggregate is one which the SVM Trident is using has access to

::>vserver show -vserver nfs_svm -fields aggr-list
    vserver aggr-list
   ------- -----------
   nfs_svm aggr1,aggr2

Add aggr3 to the SVM aggr-list:
::>vserver modify -vserver nfs_svm -aggr-list aggr1,aggr2,aggr3
If aggregate has been newly added to the SVM, the backend will need to be “refreshed” by re-adding it to Trident using the Trident backend update command, shown in this example:

$ tridentctl update backend <backend-name> -f <backend.json> -n trident

If backend has multiple aggregates, Trident randomly shuffles and selects aggregate during PersistentVolumeClaim(PVC)/PersistentVolume(PV) creation in order to prevent concentration. Particular aggregate cannot be specified when creating PVC/PV.

Use DATA partitions from other disks to expand AGGR.

fas2552::*> disk show -disk 1.0.1 -partition-ownership  
fas2552::*> storage disk removeowner -disk 1.0.1 -data true  
fas2552::*> storage disk assign -disk 1.0.1 -owner fas2552-02 -data true 
fas2552::*> disk show -disk 1.0.1 -partition-ownership  

fas2552::*> aggr show -aggregate fas2552_02_SAS -raid-info                
                                RAID        Max    Checksum Checksum
Aggregate RAID Groups           Type   RAIDSize       State    Style Inconsist
--------- --------------------- ------ --------  ---------- -------- ----------
fas2552_02_SAS 
          /fas2552_02_SAS/plex0/rg0 (block)
                                raid_dp      20  active     block    false

# storage aggregate show-status

How is it going?

fas2552::*> set diag                              
fas2552::*> node run -node fas2552-01 sysstat -M 1

[DanielFroehlich]

@mschindl isnt this done? Please close if so. thx Daniel

[rbo]

Still on going.

[mschindl]

• [ x ] Upgrade to a newer ONTAP version
• [ x ] Replace disks from 900GB to 1.2TB
• [ x ] Recreated Aggr's to 1x Aggr with 1x RG (23 disks) on Ctrl 02 and 1x spare disk
• [ x ] Disk .15 checked, because of LED issue on the case - disks seems to work well