HPE released it’s 4th version of their OneView management appliance late in December. While version 3 was a great deal better than v2 and v1 I have some expectations on this release as well. I think all versions have had value and the new features and functionalities presented has been for the better. Still it wasn’t until version 3 I really felt that it was a solid product. We’ve run v3 for almost as long as it has been available and have been happy with it.
For those of you that have read my blog you probably know I’ve done a series on performance monitoring infrastructure with the help of InfluxDB. InfluxDB is a part of the TICK stack delivered by InfluxData. All components are open-sourced and available. The TICK stack consists of, Telegraf, InfluxDB, Chronograf and Kapacitor. This post will do a quick review and some examples on how I have started exploring them in my Performance monitoring project.
In our environment we have several HPE Blade Chassis systems. The chassis is managed with the Onboard Administrator (OA) which consists of one or two management modules. Like all other hardware these modules have components that needs firmware to run. And firmware needs to be kept updated to fix bugs, add features, new hardware compatibility and mitigate security risks. It’s also a good thing to keep it pretty close to the iLO version updates on your blades as I suspect HPE might not test newer iLO against a lot of old OA version.
This weekend our primary OneView appliance crashed. This particular OneView appliance handles 10 blade chassis and over 120 blade servers As OneView handles only the management side of the hardware nothing in production was affected by this crash. TLDR; There is a bug in version 3.10.04 which doesn’t delete expired sessions. This is fixed in version 3.10.07 A few troubleshooting steps was taken initially. First we restarted the appliance, it took a while but it stopped when loading it’s resource managers and threw the same error We also gave it some more CPU’s and more RAM to see if it was a resource issue, after powering on the VM it eventually threw the same error Unfortunately we are not doing backups of the appliance from OneView.
If you’ve followed my vSphere performance data blog series you probably have noted that I used InfluxDB as the database for storing the performance data. With over 4 months of performance data in the InfluxDB I’ve picked up some gotcha’s along the way (there’s probably more lying around which I’ve not come over yet). In this blog post I’ll outline what I’ve learned so far (Save) Disk space One of them is of course, and this is an obvious one, the amount of data and the corresponding disk space needed to store it.
Following up on my last post on Automating DRS Groups with PowerCLI I found that we also need to automatically remove VMs and Hosts from a given DRS Group. Although I could have included this in the previous script which creates the groups and adds members I wanted to separate them. There could for instance be times when you would like to run such a script on a different interval than the one that adds members as well as other scenarios.
In vCenter we have lot’s of DRS functionalities. I won’t go into all of them here, you’ll probably know about most of them already. This blog post will talk about the VM/Host affinity functionality, i.e. rules to keep VMs running one or more specific host(s). There is multiple use-cases for this. You might want to keep some VMs together on the same host to minimize latency, maybe you are doing some port mirroring and so on.
This is Part 8 and last part (I think…) of my series on vSphere Performance data. Part 1 discusses the project, Part 2 is about exploring how to retrieve data, Part 3 is about using Get-Stat for the retrieval. Part 4 talked about the database used to store the retrieved data, InfluxDB. Part 5 showed how data is written to the database. Part 6 was about creating dashboards to show off the data.
This is Part 7 of my series on vSphere Performance data. Part 1 discusses the project, Part 2 is about exploring how to retrieve data, Part 3 is about using Get-Stat for the retrieval. Part 4 talked about the database used to store the retrieved data, InfluxDB. Part 5 showed how data is written to the database. Part 6 was about creating dashboards to show off the data. This post adds even more data to the project!
This is Part 6 of my series on vSphere Performance data. Part 1 discusses the project, Part 2 is about exploring how to retrieve data, Part 3 is about using Get-Stat for the retrieval. Part 4 talked about the database used to store the retrieved data, InfluxDB. Part 5 showed how data is written to the database. This post will show some results of our work! As I talked about in Part 1 I had decided to go with Grafana as the front-end.
