storage:svc_bestpractice
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
storage:svc_bestpractice [2022/08/09 00:57] manu |
storage:svc_bestpractice [2025/03/04 19:05] (current) manu [Linux optimization] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== SVC Best practice with IBM storage ===== | ===== SVC Best practice with IBM storage ===== | ||
| + | |||
| + | ===== SVC Enhanced Stretch Cluster ====== | ||
| + | |||
| + | For stretched systems that use the enhanced configuration functions, **storage systems that are configured to one of the main sites (1 or 2) need be zoned only to be visible by the nodes in that site**. Storage systems in site 3 or storage systems that have no site that is defined must be zoned to all nodes. | ||
| + | |||
| + | Note: ISLs must not be shared between private and public virtual fabrics. | ||
| + | |||
| + | Configure Enhanced Stretch Cluster | ||
| + | |||
| + | https://www.ibm.com/docs/en/spectrumvirtualsoftw/8.2.x?topic=details-configuring-enhanced-stretched-system | ||
| + | |||
| + | ===== Speed for mirroring ===== | ||
| For information, for volume mirroring, the max speed is sync rate 100% corresponding to 64MB/s | For information, for volume mirroring, the max speed is sync rate 100% corresponding to 64MB/s | ||
| + | |||
| + | ==== SAN switches ==== | ||
| + | |||
| + | **buffer credit on SAN switches** | ||
| + | 40 for 16Gb or 32Gb | ||
| + | |||
| + | |||
| + | **workload segregation** | ||
| + | on storage dedicated ports for high speed traffic ex: 32Gb | ||
| + | and other ports for lower speed 8Gb / 16Gb using zoning | ||
| + | |||
| ==== FCM optimization ==== | ==== FCM optimization ==== | ||
| Line 85: | Line 108: | ||
| When using **compression on storage**, reduce block size on host to a value lower than **64k** | When using **compression on storage**, reduce block size on host to a value lower than **64k** | ||
| + | |||
| + | FIXME v8.4 and higher: Where possible limit the maximum transfer size sent to the IBM FlashSystem to | ||
| + | no more than **256 KiB**. This limitation is general best practice and not specific to only | ||
| **Details**\\ | **Details**\\ | ||
| Line 127: | Line 153: | ||
| ==== Linux optimization ==== | ==== Linux optimization ==== | ||
| + | |||
| + | FIXME v8.4 and higher: Where possible limit the maximum transfer size sent to the IBM FlashSystem to | ||
| + | no more than **256 KiB**. This limitation is general best practice and not specific to only | ||
| Using compression on SVC volumes, the best is to set IO size to 64k | Using compression on SVC volumes, the best is to set IO size to 64k | ||
| Line 136: | Line 165: | ||
| If you don’t have UDEV in your distribution then the alternative is to use rc.local and essentially apply the same command, as an example, “echo 1024 > /sys/block/sda/queue/max_sectors_kb” | If you don’t have UDEV in your distribution then the alternative is to use rc.local and essentially apply the same command, as an example, “echo 1024 > /sys/block/sda/queue/max_sectors_kb” | ||
| + | <cli> | ||
| + | [root@prscale-b-02 block]# cat /sys/block/sda/queue/max_sectors_kb | ||
| + | 1280 | ||
| + | [root@prscale-b-02 block]# echo "64" > /sys/block/sda/queue/max_sectors_kb | ||
| + | [root@prscale-b-02 rules.d]# cat /etc/udev/rules.d/80-persistent-diskio-ibm.rules | ||
| + | ACTION=="add|change", SUBSYSTEM=="block", ATTR{device/model}=="*", ATTR{queue/nr_requests}="256", ATTR{device/queue_depth}="32", ATTR{queue/max_sectors_kb}="64" | ||
| + | </cli> | ||
| + | Use the command : **udevadm info -a** | ||
| ===== Perf issue on SAN / Storage ===== | ===== Perf issue on SAN / Storage ===== | ||
| [[storage:brocade_pb#buffer_credit_problem|Brocade buffer credit]] | [[storage:brocade_pb#buffer_credit_problem|Brocade buffer credit]] | ||
| + | ===== CPU usage with DR pool ===== | ||
| + | |||
| + | When you use DR pool volume deletion will use high CPU (lower than 20% in current usage) you can easily reach 60% of CPU during deletion process. | ||
| + | |||
| + | To check deletion, there is only one way, but no progress status ! | ||
| + | <cli prompt='>'> | ||
| + | IBM_FlashSystem:V5100-02:superuser>lsvdiskcopy | grep del | ||
| + | 125 l0000-DB01 0 deleting yes no 0 Pool0 200.00GB striped no on balanced yes 0 Pool0 no yes | ||
| + | 148 l0000-tap04 0 deleting yes no 0 Pool0 200.00GB striped no on balanced yes 0 Pool0 no yes | ||
| + | 149 l0000-tap03 0 deleting yes no 0 Pool0 200.00GB striped no on balanced yes 0 Pool0 no yes | ||
| + | 150 l0000-tap01 0 deleting yes no 0 Pool0 200.00GB striped no on balanced yes 0 Pool0 no yes | ||
| + | 151 l0000-tap02 0 deleting yes no 0 Pool0 200.00GB striped no on balanced yes 0 Pool0 no yes | ||
| + | </cli> | ||
| + | |||
| + | Usually if the CPU is not above 90% it is not considered as high and it is not affecting the performance. | ||
storage/svc_bestpractice.1659999450.txt.gz · Last modified: 2022/08/09 00:57 by manu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
