ONTAP Discussions
ONTAP Discussions
Hi,
We are trying to Deploy ONTAP Select version 9.4 on a cluster of 2 nodes. We are trying the evaluation license and using vCenter 6.7 Enterprise.
The nodes are deployed succesfully but at the end of the process we get the following message:
You can see the screen shot of the events in the attachement.
Anybody has an idea why our installation fails?
Thank you,
Solved! See The Solution
The most common reason for the HA deployement to fail is disk access latency within Ontap select.
One of the requirements on hardware level is a supported raid controller and write-back enabled.
https://www.netapp.com/us/media/tr-4517.pdf - Product Architecture and Best Practices
page 8, 9 and 19
RAID Controller Configuration for Local Attached Storage All locally attached disks that provide ONTAP Select with backing storage must sit behind a RAID controller. Most commodity servers come with multiple RAID controller options across multiple price points, and each with varying levels of functionality. The intent is to support as many of these options as possible, providing they meet certain minimum requirements placed on the controller. The RAID controller that is managing the ONTAP Select disks must meet the following requirements: • The hardware RAID controller must have a battery backup unit (BBU) or flash-backed write cache (FBWC) and support 12Gbps of throughput. • The RAID controller must support a mode that can withstand at least one or two disk failures (RAID 5, RAID 6). • The drive cache should be set to disabled. • The write policy should be configured for writeback mode with a fallback to write through upon BBU or flash failure. • The I/O policy for reads must be set to cached. All locally attached disks that provide ONTAP Select with backing storage must be placed into RAID groups running RAID 5 or RAID 6. For SAS drives and SSDs, using RAID groups of up to 24 drives allows ONTAP to reap the benefits of spreading incoming read requests across a higher number of disks, providing a significant gain in performance. With SAS/SSD configurations, performance testing was done against single-LUN versus multi-LUN configurations. No significant differences were found, so for simplicity’s sake, NetApp recommends creating the fewest number of LUNs necessary to support your configuration needs.
The most common reason for the HA deployement to fail is disk access latency within Ontap select.
One of the requirements on hardware level is a supported raid controller and write-back enabled.
https://www.netapp.com/us/media/tr-4517.pdf - Product Architecture and Best Practices
page 8, 9 and 19
RAID Controller Configuration for Local Attached Storage All locally attached disks that provide ONTAP Select with backing storage must sit behind a RAID controller. Most commodity servers come with multiple RAID controller options across multiple price points, and each with varying levels of functionality. The intent is to support as many of these options as possible, providing they meet certain minimum requirements placed on the controller. The RAID controller that is managing the ONTAP Select disks must meet the following requirements: • The hardware RAID controller must have a battery backup unit (BBU) or flash-backed write cache (FBWC) and support 12Gbps of throughput. • The RAID controller must support a mode that can withstand at least one or two disk failures (RAID 5, RAID 6). • The drive cache should be set to disabled. • The write policy should be configured for writeback mode with a fallback to write through upon BBU or flash failure. • The I/O policy for reads must be set to cached. All locally attached disks that provide ONTAP Select with backing storage must be placed into RAID groups running RAID 5 or RAID 6. For SAS drives and SSDs, using RAID groups of up to 24 drives allows ONTAP to reap the benefits of spreading incoming read requests across a higher number of disks, providing a significant gain in performance. With SAS/SSD configurations, performance testing was done against single-LUN versus multi-LUN configurations. No significant differences were found, so for simplicity’s sake, NetApp recommends creating the fewest number of LUNs necessary to support your configuration needs.
Thanks a lot for the advice. I set our Raid Controller settings according to the spec you mentionned and it worked! ( Always Read Ahead, Caching IO to ON, local disk caching to OFF and Write Back Good BBU)
I am wondering why the Deploy did not give us any warning or message about the setting!
Anyway, things are back to awesome again! 🙂
Thanks again!
Good to hear that everything is back to being awesome again 🙂
Since different server brands use their own way to communicate to the raid controllers, it is simply not feasable for now to implement this into the deploy tool.
- if this post answered your question, please consider accepting it as the solution -