Tag Archive for ESXi

NanoLab – Index of Tekhead.it Posts on Intel NUC VMware vSphere Homelabs

Starting in January 2013, my Intel NUC series is now over has reached the heady heights of double digits over the past few years, so I figured it might be handy to make them a bit easier to find!

Nanolab Posts

More posts coming soon… 🙂

Just in case I forget to keep this page updated:
http://tekhead.it/blog/category/nanolab/

Intel NUC Nanolab blog posts

You had me at Tiered Non-Volatile Memory!

Memory isn’t cheap! Despite the falling costs and increasing sizes of DRAM DIMMS, it’s still damned expensive compared to most non-volatile media at a price per GB. What’s more frustrating is that often you buy all of this expensive RAM, assign it to your applications, and find later through detailed monitoring, that only a relatively small percentage is actually being actively used.

For many years, we have had technologies such as paging, which allow you to maximise the use of your physical RAM, by writing out the least used pages to disk, freeing up RAM for services with current memory demand. The problem with paging is that it is sometimes unreliable, and when you do actually need to get that page back, it can be multiple orders of magnitude slower returning it from disk.

Worse still, if you are running a workload such as virtual machines and the underlying host becomes memory constrained, a hypervisor may often not have sufficient visibility of the underlying memory utilisation, and as such will simply swap out random memory pages to a swap file. This can obviously have significant impact on virtual machine performance.

More and more applications are being built to run in memory these days, from Redis to Varnish, Hortonworks to MongDB. Even Microsoft got on the bandwagon with SQL 2014 in-memory OLTP.

One of the companies we saw at Storage Field Day ,  Plexistor, told us that can offer both tiered posix storage and tiered non-volatile memory through a single software stack.

The posix option could effectively be thought of a bit like a non-volatile, tiered RAM disk. Pretty cool, but not massively unique as RAM disks have been around for years.

The element which really interested me was the latter option; effectively a tiered memory driver which can present RAM to the OS, but in reality tier it between NVDIMMs, SSD and HDDs depending on how hot / cold the pages are! They will also be able to take advantage of newer bit addressable technologies such as 3D XPoint as they come on the market, making it even more awesome!

PlexistorArch.jpg

Plexistor Architecture

All of this is done through the simple addition of their NVM file system (i.e. device driver) on top of the pmem and bio drivers and this is compatible with most versions of Linux running reasonably up to date kernel versions.

It’s primarily designed to work with some of the Linux based memory intensive apps mentioned above, but will also work with more traditional workloads as well, such as MySQL and the KVM hypervisor.

Plexistor define their product as “Software Defined Memory” aka SDM. An interesting term which is jumping on the SDX bandwagon, but I kind of get where they’re going with it…

SDM_vs_SDS2.png

Software Defined Memory!

One thing to note with Plexistor is that they actually have two flavours of this product; one which is based on the use of NVRAM to provide a persistent store, and one which is non-persistent, but can be run on cloud infrastructures, such as AWS. If you need data persistence for the latter, you will have to do it at the application layer, or risk losing data.

If you want to find out a bit more about them, you can find their Storage Field Day presentation here:
Plexistor Presents at Storage Field Day 9

Musings…
As a standalone product, I have a sneaking suspicion that Plexistor may not have the longevity and scope which they might gain if they were procured by a large vendor and integrated into existing products. Sharon Azulai has already sold one startup in relatively early stages (Tonian, which they sold to Primary Data), so I suspect he would not be averse to this concept.

Although the code has been written specifically for the Linux kernel, they have already indicated that it would be possible to develop the same driver for VMware! As such, I think it would be a really interesting idea for VMware to consider acquiring them and integrating the technology into ESXi. It’s generally recognised as a universal truth that you run out of memory before CPU on most vSphere solutions. Moreover, when looking in the vSphere console we often see that although a significant amount of memory is allocated to VMs, often only a small amount is actually active RAM.

The use of Plexistor technology with vSphere would enable VMware to both provide an almost infinite pool of RAM per host for customers, as well as being able to significantly improve upon the current vswp process by ensuring hot memory blocks always stay on RAM and cold blocks are tiered out to flash.

plexistorvmware

The homelab nerd in me also imagines an Intel NUC with 160GB+ of addressable RAM per node! 🙂

Of course the current licensing models for retail customers favour the “run out of RAM first” approach as it sells more per-CPU licenses, however, I think in the long term VMware will likely move to a subscription based model, probably similar to that used by service providers (i.e. based on RAM). If this ends up being the approach, then VMware could offer a product which saves their customers further hardware costs whilst maintaining their ESXi revenues. Win-Win!

Further Reading
One of the other SFD9 delegates had their own take on the presentation we saw. Check it out here:

Disclaimer/Disclosure: My flights, accommodation, meals, etc, at Storage Field Day 9 were provided by Tech Field Day, but there was no expectation or request for me to write about any of the vendors products or services and I was not compensated in any way for my time at the event.

VCP6-DCV Delta Exam (2V0-621D) Study Guide and Exam Experience

Having successfully completed the VCP6-DCV Delta Exam (2V0-621D) this week, I thought it would be worthwhile jotting down a few thoughts on the exam, and noting the resources I used to prepare for it.

I’ve previously completed the VCP3, VCP4 and VCP5 “DCV” exams, however being specifically a delta exam, this one was a little different. The exam primarily covers the differences between vSphere 5 and vSphere 6, with a handful of seemingly more general questions.

For summary impressions of the exam (i.e. the TLDR), jump to the end of this article! 🙂

Preparation
I used the following resources in prep for the exam:

homelab

The Exam
The exam itself was different to any previous VCP exam I’ve done. I would say that because the scope of the exam was much narrower, the depth of the questions seemed to me to be significantly more, with a few really tricky ones thrown in there.

Over all if I was to do it again (and when it comes time to do the VCP7 in a few years) I would probably just do the full VCP exam, rather than the delta. That way you can be sure of a decent number of the easy peasy questions which will probably be on stuff you’ve been doing for years, as well as the new stuff you may not know quite as well.

Obviously having not done the full VCP6 exam I can’t say this for sure, but I would say it’s a pretty good bet.

NanoLab – Part 10 – Your NUCs are nice and cool, but what about your stick?

I have been running a variety of Intel NUC nodes in my vSphere homelab over the past 3 years now, including the D34010WYKH, DC3217IYE & DC53427HYE.

In that time I have unfortunately seen more than my fair share of USB drive failures and corruptions, generally with an error which looks something like this:

Error loading /k.b00
Fatal error: 33 (Inconsistent data)

 
These are not cheap and nasty, or freebie USB drives, so I would not normally expect to see this rate of failures. The error only occurs when you reboot the host, and the startup bombs out at the start of the hypervisor launch. I have often managed to recover the stick by copying back corrupted files from another instance, but generally I needed to rebuild and restore the image. An unnecessary pain in the rear!

The Root Cause
The NUC case can become quite warm during normal operation with or without the fans spinning up, and I have come to believe that the main reason for the corruptions is that the USB stick itself is getting too hot and therefore eventually failing. Having pulled a USB out from a recently shut down node, they are really quite hot to the touch. You don’t actually see the symptom / failure until a reboot because the ESXi image actually runs in memory, so is only loaded from the USB stick at boot time.

The Solution
As for the solution, it’s really quite simple. I purchased a number of 12cm (5 inch) USB 2.0 extender cables on eBay for just 99p each (including delivery!).

These keep the USB stick indirectly attached to the NUC chassis, and as such the heat does not transfer into the flash drive. Since doing this I have not seen any further issues with the corruptions. Job done!

Keeping things cool: USB extender on Intel NUC

Keeping things cool: USB extender on Intel NUC

%d bloggers like this: