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.
This is Part 5 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. This one will do some actual work and will retrieve data from vCenter and write it to the database. The last post showed how to write some data to the performance database InfluxDB through its API.
We are using Storage Policies on all VMs in our environment and rely on those to give the VM’s the correct storage. Storage Policy based management is a key area for VMware going forward it seems, especially with things like vSAN and VVOL. In addition to matching a VM and it’s storage we are using the policies to set limits on the VM’s. We have a shared environment and we have to have some limitation on the VM’s so that one VM couldn’t impact all the others.
This is Part 4 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. This post will be about the database used to store the retrieved data, InfluxDB. The last post left of with the beginning of a script that had retrieved data from vCenter. Before I can finish that script I need to have somewhere to put that data.
This is the Part 3 in my series on vSphere performance data. Part 1 discussed the project, Part 2 was about checking the methods of retrieving data and ended with me realizing I would use Get-Stat against all (4000) VMs to retrieve data. Part 2 was posted over a month ago as I have been busy preparing for the VCP 6.5 DCV exam (which I passed btw) as well as upgrading/migrating our vCenter servers, but I have actually been able to do a lot of work on this project as well so there will be some updates in the next couple of days.
I’m using the Scheduled Tasks functionality in Windows Server quite extensively. I have tasks for importing stuff to a database with Powershell scripts, running some cleanup scripts etc Almost all of my scripts run on different intervals during the day. Some maybe just once a day and some might run every x minutes. Recently I encountered a difference in the way Scheduled Tasks work on Windows Server 2012R2 (and below) and on Windows Server 2016.
In my last post about upgrading vCenter to 6.5 I’ve outlined the steps I needed to do for the migration. Both pre-migration, the actual migration and some post-migration steps. Today we were about to upgrade/migrate one of our oldest and biggest vCenters which presented some additional steps to consider for the pre-migration checks and tasks. This is also described in the VMware documentation so it shouldn’t be a surprise to those reading that before migrating.
In a previous postI talked about the upgrade of our vSphere environment. The first post described the upgrade and migration of the Platform Services Controller (PSC) from a version 6 running on Windows to a 6.5 Appliance. Our upgrade path would be PSC -> vCenter -> Hosts. Our environment consists of several vCenters so this will take some time and we might upgrade hosts in a vCenter that has been upgraded to 6.
This is part 2 of my vSphere Performance Data series. Part 1described the project and my goals with the project. This post will be my thoughts on retrieving performance data from our vSphere environment. As I described in part 1 our environment consist of 100+ hosts and 4000+ VMs. These are hosted in 3 different vCenters in the same SSO domain (Enhanced Linked Mode). All hosts and vCenters are at version 6.
There is lots of posts on retrieving performance data from your vSphere environment (I’ll probably use a lot of them in this series), but here’s my take on it. My ultimate goal is to build my own database of performance data and have a nice front-end presenting this. I also want to have an API that extracts data from the performance DB which I will use in our in-house portals and dashboards.