I’ve published a new version of TR-3633, the Oracle on ONTAP technical guide.
I added the following content:
- Oracle on ONTAP Cloud, ONTAP Select, and NetApp Private Storage (NPS)
- A section on performance testing and benchmarking of database storage systems
- A few notes about using Oracle on ZFS within a Solaris LDOM
Here’s an overview of what I added:
ONTAP can run in all sorts of environments. If you really want the fastest possible database, you’ll need a physical FAS or AFF system. Not everybody needs that, though.
I’ve seen the performance data on literally thousands of databases, and the majority of what I see simply doesn’t need the silly levels of IOPS everyone throws around these days. Think about it. Most database applications handle business processes like payroll and HR. Those tasks ran fine on a 20-year-old VAX system, and they should be equally fine on ONTAP Select or ONTAP Cloud.
In other cases the production workloads might need physical hardware, but development and testing performance needs aren’t generally as high. ONTAP Select or ONTAP Cloud would again be options. ONTAP Cloud is also useful for low-cost disaster recovery in the Cloud. You can efficiently replicate your source environment to the ONTAP Cloud and only pay for storage, not a whole set of servers in a physical data center that hopefully you will never need to use.
The section on performance testing is intended to stop a lot of unnecessary or misleading testing efforts. It especially drives me up the wall when we get into IOPS fights that have no basis in real-world needs. Most of the all-flash systems being sold today can deliver far more performance than can be consumed by current workloads.
For example, is a system that delivers 300K IOPS actually faster than a system that delivers 500K IOPS? If the database only wants 50K IOPS, then why are you wasting money buying something you don’t need? It’s like FedEx choosing a delivery truck that can do 200MPH rather than one that only does 150MPH. They won’t be able to use that additional speed, so what’s the point of even testing such things?
Here’s a picture from one of my presentations at Insight that illustrates what an AFF8080 system can do, and this isn’t even the top of the line anymore. I’m assuming my management won’t mind me putting this picture on a personal blog.
I’ve got tons of these graphs with different workloads. That’s an actual Oracle database pushing 310K IOPS and it hasn’t even breached the 1ms read latency threshold. I have seen databases that need this, but they are in the top tenth of one percent of all database workloads.
The best way to evaluate a storage system is to base it on the actual requirements, not platform maximums that you’ll never touch. That means looking at the current IOPS and latencies. I like to size based on Oracle AWR data. Most of the time I end up guessing a given storage system is somewhere between 5X and 50X more powerful than current needs, and that’s the end of it.
The last update to TR-3633 is related to some Solaris ZFS projects I’ve seen recently. There are two things to know about Solaris ZFS on ONTAP:
- ZFS has a sort of intrinsic block size that is set the moment the zpool is created. This is your one and only change to get it right. The parameter you need to check is ashift. If it’s not set to 12 and you’re using ONTAP, stop. You haven’t correctly set some of the driver parameters, and you may have performance problems. Read the NetApp documentation again.
- If you use a Solaris LDOM, you also need to set block sizes correctly using the vdc.conf file. See TR-3633 f0r more details on how this parameter works.