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.
This month we started our upgrade journey from vSphere 6.0 -> 6.5 in production. We have had 6.5 running in lab for some time after the release last fall and we have enjoyed it so far. As a part of this upgrade we plan to migrate to the vCenter appliance on both PSC’s and vCenter’s as this has gotten all functionality (i.e. Update Manager), and it scales to the same extent as the Windows one.
Recently I’ve been messing around with the new .NET Core. I’ve created a class library which I’m using in an ASP.NET Core Web API. Firstly, at least before 1.1, I couldn’t add a reference to the class library just by giving it the .dll file. I needed to create a NuGet package of my library and publish it to a NuGet feed. I set up a local NuGet feed and added it as a source in VS and were able to add my code.
I have recently installed Visual Studio 2017 and with that started to migrate some of my .NET Core projects to the new .csproj Check out this post by Steve Gordon to get more background insight on the migration This looks easy enough with the migration wizard in VS. And the first try on a class library seemed to work just fine. However when revisiting the project a couple of days after the migration I get this in VS 2017: