We currently own 2 AFF systems. One in the primary data center and one in an off site location. Both are used for a broad range of applications:
Cache Database (Epic EMR and Sunquest Lab)
Oracle Database (Multiple applications)
SQL Server (Hundreds of databases)
AIX Boot from SAN
VMWare guests (Over 1,000 VMs)
All production systems are snap-mirrored between the two AFF systems for redundancy and recoverability.
- It is fast. We have multiple large and vastly different types of workloads and our response time is always sub-milisecond
- NetApp has done a phenomenal job with developing Ontap. It continues to improve in large leaps on a short development cycle
- The snapshot technology at the heart of Ontap is incredibly powerful and versatile. It is at the heart of most of their most useful technologies.
- Non-disruptive moves of volumes between nodes, aggregates and even different media types makes management vert simple
- Volume level data encryption. We have this enabled for all volumes and have seen zero performance impact.
- The GUI of Ontap is in constant flux. Every time there is an upgrade it appears to be completely redesigned. Some stability in its design would be nice
- As new or improved technologies addressing compression, compaction and deduplication occur within upgrades it would be nice if preexisting data could benefit from it by background processes looking for opportunities to apply savings to data in place.
- It is not simple to see when data from the AFF is being access inefficiently through the cluster interconnect. Because data moves sometimes access to the data remains with the nodes that originally owned them. I would like to be able to easily identify these instances so that I can take corrective action.
We us our AFF to support all applications that have a response time imperative or are IO intensive such as databases, email, VMware VMs and applications that have users at a keyboard needing a responsive interaction. It is also where we put all data that must be encrypted at rest such as HIPAA data.
It is of no value to data that is generally archived, little used or has low IO requirements. These would include scanned images, videos, IP Camera storage and most CIFS and NFS file based storage. For these types of applications SATA is still a better choice.