Yellow Bricks

by Duncan Epping

hcl

Single socket vSAN ready node AMD EPYC Rome on the VCG!

· · 3 Comments

Yesterday I tweeted something and I want to reiterate it to make sure that those who are just following the blog, and not my twitter account, also are aware. On the vSAN Compatibility Guide (VCG) there were already a number of single-socket servers, but most of these were limited in terms of CPU/MEM resources. Last week two new servers were added to the VCG. These servers are based on the AMD EPYC Rome CPUs and can have up to 64 cores. Yes, 64 cores per CPU. They can go up to 2TB worth of memory, depending on the DIMMS used, also while on the topic of memory, the NUMA implementation completely changed with AMD EPYC Rome, but I am sure Frank Denneman will have something to say about that soon. Why would I bring these servers up? Well, for those looking to do 2-node vSAN configurations or smaller vSAN clusters, they could be a great alternative solution! Heck, I would consider them in general I think.

Startup update: Runecast 2.0

· ·

Last week I was briefed by Runecast (together with Cormac) on the new version, Runecast 2.0, which was released/announced today. I always enjoy talking to Stan as every time we talk they have something new which surprises me, or he tells me about something cool on the roadmap. For those who did not read my previous articles, Runecast is a company which focusses on analyzing VMware environments and assess the environment on potential issues. These issues could be anything ranging from configuration issues, driver/firmware issue, to security issues. It reminds me very much of what we have with vSAN which is the health check. The big difference though is that this solution includes many more checks and doesn’t just focus on vSAN but on many different parts of the stack. Just to give you an idea, today Runecast can analyze your vSphere environment up to vSphere 6.7 and can also analyze vSAN and NSX-V. The cool thing is that it also does this “offline”, they have an appliance and regular updates (rules and features) and this means that even in a dark site this would work.

A lot of Runecast’s customers are either in the financial space or government space. I guess this is also why their focus for the 2.0 version was primarily on PCI-DSS. With over 200 technical checks, which map against PCI-DSS requirements, they (as Runecast told me) have by far the largest collection of requirements in an automated analyzer (for VMware) in the industry. Definitely, a smart enhancement, if you are not interested in PCI-DSS, you can simply disable the whole check and it will never show up in your interface. You can also, if only a limited number of clusters should be validated, filter out certain results.

The 20 version of Runecast also comes with a lot of updates around the appliance, now I consider these “internals” as for most customers it is not relevant in terms of the value it offers, but it is important to know from a security perspective I guess.

This version also introduces a historical perspective. Meaning that starting with Runecast 2.0 the historical information of checks is stored. This will allow you to see some form of trending when it comes to the different checks/validations. You could for instance now track if you do updates and maintenance if the number of potential issues is going down. You could also task someone with validating the reported issues and fixing those when or where possible. This should over time improve the availability, reliability, and security of your environment.

Last but not least the UI has been fully overhauled. They redesigned it just to make it easier to read and understand. Also, a couple of dashboards were added, which makes sense… a new release means new dashboards!

If you happen to go to VMworld, make sure to stop by their booth and have a look, I think you will find it interesting. Or simply read the Runecast blog, and download the appliance and try it out.

Startup update: Runecast

· ·

A while ago I introduced Runecast on my blog. I have known these guys for a while and this week I had to pleasure to be briefed on their new release: Runecast 1.7. The big ticket item in this release for sure it the vSAN Support. You may ask yourself why you would need Runecast when you have things like the health check and the “online” health check, well it seems that Runecast’s implementation covers more detail. Anyway, what is Runecast? As a company they refer to themselves as the knowledge automation experts, and I think that is a fair statement.

Runecast has developed an appliance which can be connected to one or multiple vCenter Server instances. After linking these you can “scan” the environment and Runecast will tell you about the risks. Not just from a security perspective, but it will also assess logs, configuration and even best practices. Your whole environment will be assessed in a report will be provided in a simple HTML-5 interface, or in the Web Client or the vSphere H5 client even. I said “simple”, but the information provided and the detail is far from simple… When I say simple I refer to their user interface. It is slick, and very easy to use.

Since I discussed Runecast last they added some additional features, like for instance a VRO plugin, full rest API, improved log search, Web Client and H5 client plugins but more importantly for many government agencies: DISA STIG compliancy checks. Yes, Runecast can check your environment against DISA STIG and report on any potential issues. Nice right?

This new release, version 1.7, now brings vSAN support. It also includes a new dashboard widget, which provides faster insights in how your environment is behaving. For vSAN in particular they didn’t only include KB article checks, but also implemented all best practices from the Design and Sizing guide, Network Design guide and the Stretched Cluster white paper. And they even hinted about adding best practices which are listed in the Essential vSAN book Cormac and I wrote, how cool is that? What is also nice is that their appliance is supported with vSAN 5.x and 6.x, and requires no direct access to the internet. You can simply download the appliance and install, and then update with the latest dataset by downloading an ISO.

Oh and before I forget, of course they also provide all the guidance and info needed around Spectre/Meltdown. Where normally their trial is limited, they actually do provide ALL info needed for Spectre/Meltdown as they realized that this is very valuable to customers and felt they could not hold this back.

For the Runecast blog on the 1.7 release go here.

Check your VSAN disk controllers against the HCL with PowerCLI

· ·

Every now and then customers ask if it is possible to check if disk controllers are on the VSAN HCL (Or VMware Compatibility Guide (VCG) as it is actually called these days) for a given set of hosts through PowerCLI. Alan Renouf figured he would knock something out, thanks Alan for sharing! (Next up would be validate drivers and firmware of all components, thanks!) What this script does is the following, note that you need internet access for this to work:

  • Connect to vCenter
  • Download latest VSAN HCL details (json file)
  • Compare controllers of each host against the VSAN HCL
  • Report the state of your infra

Here is the script, it can also be found in the VMware Developer Center repository by the way.

Connect-VIServer myvcenter -user Administrator -password MyPass23
 
 
Function Get-CompatibleVSANController {
    if (-Not $vSANHCL) {
        $vSANHCL = Invoke-WebRequest -Uri http://partnerweb.vmware.com/service/vsan/all.json | ConvertFrom-Json
    }
    $vSANHCL.data.controller
}
 
$HBAs = get-vmhost | Get-VMHostPciDevice | where { $_.DeviceClass -eq "MassStorageController" }
 
Foreach ($HBA in $HBAs) {
    $HBAFound = $false
    Write-Host "Looking for $($hba.name) from host $($HBA.VMhost)"
    Foreach ($entry in Get-CompatibleVSANController) {
        $vid = [String]::Format("{0:x}", $HBA.VendorId)
              $did = [String]::Format("{0:x}", $HBA.DeviceId)
              $svid = [String]::Format("{0:x}", $HBA.SubVendorId)
        $ssid = [String]::Format("{0:x}", $HBA.SubDeviceId)
        If (($vid -eq $entry.vid) -and ($did -eq $entry.did) -and ($svid -eq $entry.svid) -and ($ssid -eq $entry.ssid) ) {
            Write-Host " HBA in $($HBA.VMHost) is $($HBA.Name) which can be found in the HCL as $($Entry.vendor) - $($Entry.Model) at the following URL: `n $($entry.vcglink)" -ForegroundColor Green
            $HBAFound = $true
        }
    }
    If (-Not $HBAFound){
        Write-Host " $($HBA.Name) in $($HBA.VMHost) is not found!" -ForegroundColor Red
    }
}

If you run it the output will look like this:

Selecting a disk controller for VSAN using the HCL

· ·

As this was completely unclear to me as well and I started a thread on it on our internal social platform I figured I would share this with you. When you go through the exercise of selecting a disk controller for VSAN using the VMware Compatibility Guide (vmwa.re/vsanhcl) you will see that there are 4 “features” listed. The four features describe how you can use your disk controller to manage the disks in your host. This is important as selecting the wrong disk controller could lead to unwanted side effects.

Let me list the four features and explain what they actually mean:

  • Virtual SAN – SAS
  • Virtual SAN – SATA
  • Virtual SAN Pass-Through
  • Virtual SAN RAID 0

Virtual SAN – SAS / SATA and Pass-through are essentially the same thing. Well not entirely as it is implemented in a different way, but the result is the same. What this does is serving the disks straight up to the hypervisor. This functionality literally passes the disk through to ESXi, and avoids the need to create a RAID set or volume for your disks. This is by far the easiest way to pull your disks in to a VSAN datastore if you ask me.

Virtual SAN RAID 0 means that in order to use the disks you will need to create a single disk RAID 0 set for each disk in your system. The downside is when using this that things like hot-swap will be impossible as your Disk (ID) is bound to the RAID 0 set. However there is also a positive thing, many of these disk controllers support things like encryption of data at rest and if your disks support this you could potentially use this. It should be noted however that as far as I know today this functionality has not been tested (extensively) and support could be an issue. However, I could see why one would want to buy a controller that offer this functionality to be future proof.

Then there is another aspect, I have been asked about this a couple of times already and that is the performance capability of the controller. As far as I have seen the HCL today consists of 3Gbps and 6Gbps controllers. In most cases there is little to no cost difference, so if supported I would always recommend to go with the faster controller. But there is another thing here that is often overlooked and that is the queue depth. Before you pull the trigger and decide to buy controller-A over controller-B you may want to verify what the queue depth is of both of them. In some cases, and especially the cheaper disk controllers, the queue depth is low (32) where others offer 256 and higher. Especially when you are building an environment where a lot of IO is expected these are things to take in to consideration, plus you wouldn’t want to buy a screaming fast SSD and then find out your bottleneck is the queue depth of your disk controller right?

<update>A very good point made by Tom Fenton, if you select a controller and are at the point of rolling out VSAN make sure you validate the firmware and the driver used. If you click on the “Model” you will be able to see those details. This also applies for SSDs and HDDs!</update>

I hope that helps,