Welcome back to my continuing series on PernixData software. Today we are continuing on with Architect. The last installment was on how to upgrade FVP to 3.1 and enable Architect. Now, we’re going to go through the fun stuff. Dashboards. Now, I will tell you now, some of it is redundant from the FVP dashboards. All the verbiage is the same. In fact, when you go to FVP reporting, if Architect is enabled, it tells you to go there. Alright, let’s get going.
We start off on a page that looks just like the FVP main dashboard. The cluster selection page. This allows you to see all clusters that you have in your environment. Nothing new here. Let’s move over to the Workload tab.
The Workload tab lets you see a visual representation of reads vs writes for a given cluster. You can see the block size frequency, and even change the sampled time range from anywhere from 10 minutes through days. There is several pre-set time ranges, or you can set your own.
On that same chart, you can change from Read / Write Summary to Per VM Breakdown. This allows you to see another breakdown of VM’s based on Write Heavy, Write Moderate, Balanced, Read Moderate, and Read Heavy VM’s. Let’s move on to the next tab.
The VM Performance Plot. While I am all for visualizations, this one was difficult for me to get my head around at first. Not because of the data plotted, but because of the visual representation. It’s simply a bunch of dots. Most of mine were bunched together. I assume with this visual that it gets better when you have more VM’s doing more things than I have in my lab. I’ll be setting up some read / write tests in a later installment which I hope will make some of the features of all this really open up. The next tab gets us into a concept I had to read up on a bit, as it is a common theme of PernixData.
The first instance of Working Set Estimation appears on this tab. Working set refers to the data used in an environment over any period of time. This could be any size data over any time period, really. There is a good write up on Working Set Sizes by Pete Koehler on the PernixData blog here.
As you can see from our next screenshot, we went back to the Overview tab, and clicked into our Production cluster. This is the main Summary dashboard for the cluster. This will give you a broad overview of everything, just as the FVP dashboard did. You can change the workload visual from the Summary graph to the IO Frequency heat map seen below:
Next we’ll move to the reporting tab. This is where all the performance data and graphs come together.
You can see the Performance Grid first. This has graphs for VM latency, IOPS, Throughput, Acceleration Ratae, Write Back Destaging, Population vs Eviction, and Workload. A pretty cool layout. It is even interactive. If you mouse over any of the graphs and move the mouse over a given point, it will popup the exact stats for that graph, as well as all others at once. So you can quick look at a given time and stats. All the rest of the reporting is very similar to the FVP reporting dashboards.
The intelligence tab. The reason we are all here. This is really where Architect shines. All the rest of the stuff there is just to give you the warm and fuzzies that you didn’t waste your money on FVP. While it’s nice having all the analytics, it doesn’t really DO anything.
The Working Set Estimation, we already talked about. It simply shows you your host breakdown of working sets. The next bit is the real cool part.
Recommendations. What could you change to optimize your environment? Architect is finally pulling its own weight. Since I don’t have a full version of FVP, all my VM’s are in Write-Through mode. Based on its activity, Architect suggests that I put my vCenter VM in write-back mode. I’d love to have the full versions of FVP and Architect so I could really get into making the changes and opening it up. Maybe some day. For now, I’ll just look at the recommendation and know Architect is trying.
The next option is the Insight. It allows you to get a visual representation of Reads / Writes Accelerated, IOs saved from datastore, and datastore bandwidth saved. This is all stuff you can see from the FVP dashboards, but this goes a bit more in depth. The cool part of this is seeing the Results in section. It shows you how your environment reacts with FVP and without. Now, currently, my two times are the same. Earlier after I first installed it, the time without FVP was much greater than with.
On to the final page where Architect earns it’s keep. Sizing.
Sizing is one of the most important things in design. You don’t want to buy more than you need, and you don’t want to need more than you have. This page shows you exactly how much resources you’d need to size FVP for all the different storage policy modes. Write Through, Write Back + 0, WB + 1, WB +2. It gives you a range of flash needed for each. This is very cool if you need to know exactly what you’re looking for in terms of flash. I see this as useful as you could get FVP and run it all in write through. Let Architect run for a while, then use the estimates to size your flash purchase to enable write-back mode. That way you aren’t doing any guessing, or over-purchasing / under-buying.
Hopefully this was enlightening to you. I am really liking the PernixData stuff here. It is really cool to play with, and in a tiny home lab like mine, I need all the storage help I can get. Stay tuned for IO testing coming very soon. My countdown clock is on for my Architect trial!
Note: My series on PernixData software is in no way sponsored by PernixData. The posts are all written by me, for knowledge, not compensation.