Determining Flash Pool candidacy and optimal cache size

Before converting an existing aggregate to a Flash Pool aggregate, you can determine whether the aggregate is I/O bound, and what would be the best Flash Pool cache size for your workload and budget. You can also check whether the cache of an existing Flash Pool aggregate is sized correctly.

Before you begin

You should know approximately when the aggregate you are analyzing experiences its peak load.

Steps

  1. Enter advanced mode: set advanced
  2. If you need to determine whether an existing aggregate would be a good candidate for conversion to a Flash Pool aggregate, determine how busy the disks in the aggregate are during a period of peak load, and how that is affecting latency: statistics show-periodic -object disk:raid_group -instance raid_group_name -counter disk_busy|user_read_latency -interval 1 -iterations 60
    You can decide whether reducing latency by adding Flash Pool cache makes sense for this aggregate.
    Example
    The following command shows the statistics for the first RAID group of the aggregate "aggr1": statistics show-periodic -object disk:raid_group -instance /aggr1/plex0/rg0 -counter disk_busy|user_read_latency -interval 1 -iterations 60
  3. Start Automated Workload Analyzer (AWA): system node run -node node_name wafl awa start aggr_name
    AWA begins collecting workload data for the volumes associated with the specified aggregate.
  4. Exit advanced mode: set admin
    Allow AWA to run until one or more intervals of peak load have occurred. AWA collects workload statistics for the volumes associated with the specified aggregate, and analyzes data for up to one rolling week in duration. Running AWA for more than one week will report only on data collected from the most recent week. Cache size estimates are based on the highest loads seen during the data collection period; the load does not need to be high for the entire data collection period.
  5. Enter advanced mode: set advanced
  6. Display the workload analysis: system node run -node node_name wafl awa print
    You can use the -t option to show information about the volumes in the aggregate that are the best candidates for being on a Flash Pool aggregate.
    AWA displays the workload statistics and optimal Flash Pool cache size.
  7. Stop AWA: system node run -node node_name wafl awa stop
    All workload data is flushed and is no longer available for analysis.
  8. Exit advanced mode: set admin

Example

In the following example, AWA was run on aggregate "aggr1". Here is the output of the awa print command after AWA had been running for about 3 days (442 10-minute intervals):

	### FP AWA Stats ###

                     Host lada66a                    Memory 93788 MB
            ONTAP Version NetApp Release R8_3_1x_awa_2809198_1504220853: Tue Apr 21 18:35:12 PDT 2015 

Basic Information
                Aggregate lada66a_aggr1
             Current-time Thu Apr 23 16:42:17 PDT 2015
               Start-time Thu Apr 23 08:03:51 PDT 2015
      Total runtime (sec) 31103
    Interval length (sec) 600
          Total intervals 54
        In-core Intervals 1024

Summary of the past 20 intervals
                                max          
                                ------------ 
        Read Throughput (MB/s): 181.772      
       Write Throughput (MB/s): 550.611      
            Cacheable Read (%): 12           
           Cacheable Write (%): 30           
Max Projected Cache Size (GiB): 787.077      

Summary Cache Hit Rate vs. Cache Size
Referenced Cache Size (GiB): 787.077
Referenced Interval: ID 53 starting at Thu Apr 23 16:33:07 PDT 2015
         Size        20%        40%        60%        80%       100% 
 Read Hit (%)          9         20         28         32         35 
Write Hit (%)         17         21         23         25         30

The results provide the following pieces of information: