Healthcheck with Serverspec

As I mentioned in my previous post, I would like to introduce a project I have recently started which is a Chef cookbook about system healthcheck.

The idea is to generate a healthcheck page based on results of running Serverspec tests.  Specifically, it would be helpful for load balancers and more specifically for AWS ELB healthcheck. According to Serverspec: it tests your servers’ actual state by executing command locally, via SSH, via WinRM, via Docker API and so on. So you don’t need to install any agent softwares on your servers and can use any configuration management tools. But the true aim of Serverspec is to help refactoring infrastructure code. Load Balancers check health of system using this healthcheck URL and stop sending traffic if it’s not healthy. The generated health check page can be handy for this URL then. If self-check fails, it will return an error status code, otherwise 200 status code. In this cookbook, 2 concepts are used:

  • Infrastructure test as code using Serverspec: It’s best if we have a test-driven infrastructure as code but even if there is no code for infrastructure, this cookbook can still help!
  • Loadbalancer healthcheck: if healthchek page is comprehensive enough, this check can help in having a high available system. In case of AWS, when ELB is accompanied by Auto Scaling Group, a new healthy instance will replace the bad one if ELB notices an issue.

So, if you are interested in test driven coding especially in infrastructure, please have a look. Looking forward to hear your feedbacks.

Top vBlog voting

Time goes fast! It was not a long time ago when I was listed in Virtualization and Cloud portal (vLaunchpad) and it’s my pleasure that I’m a candidate now. So, if you like this blog, please go and cast your vote here. Please remember that you should choose 10 items to proceed.You can also find winners for last year in vLaunchpad main page.


To install VMware vSphere Big Data Extensions 1.1, if you satisfy the requirements mentioned in vmware document, go ahead with installation by deploying Big Data Extensions OVA as documented. But attention that:

  • Better to create a specific Resource Pool for your Big Data Cluster and specify the total amount of resources you want to assign and apply possible limits.
  • Create a port group dedicated to Big Data Extensions  as a communication link between management servers and working VMs.
  • When deploying Big Data Extensions Management server (OVA), ‘setup networks’ asks you to assign a destination port group. Note that: Management Network will use this network to communicate with vCenter server. So, if you use VLAN tags, the port group should be in the same VLAN (use same VLAN id) with vCenter network. If vCenter can not see Big Data Management server and vice versa, integration will not be made properly.


  • In ‘Customize template’ step, there are 2 important settings: SSO service and Management Server IP address. So, from right-pane open ‘VC SSO Lookup Service URL’ and ‘Management Server Networks Settings’. Enter appropriate values. For SSO Lookup Service URL, use vCenter server with the same format (if you didn’t change defaults), I mean port 7444/lookupservice/sdk. Use FQDN of vCenter and not IP address or certificate will not be accepted and you will see errors for connecting Big Data Extensions plugin to Serengeti server in the future.


Supported Hardware Version in Provider vDC

Remember to change default value of “Highest supported hardware version” from 7 to 9 when you create a Provider vDC in VMware vCloud Director 5 or you will face some issues later on when you want to import VM’s from vCenter to your Catalogs and will get this error message:
“The selected vdc does not support required virtual hardware version”
The interesting point is that VM’s in vCenter are created compatible to Hardware Version 8 by default! In fact, there are some inconsistencies between vCenter, vSphere and vCloud Director; it is just one of them.

To get started …

Well, there should be a beginning for everything and yes, it’s the beginning for this blog! So, let’s go over this cliche quick.

It’s going to be a technical blog about networking, as its name implies: some tweets about networking! I’m prone to cloud topics, though it won’t be limited to cloud stuff. You may ask do we need just another blog about networking or cloud computing? Ummm, I would say the number of ways to approach a problem equals the number of people who think about it. Networking and cloud is not a different story and this variety in techniques is beautiful!

My name is Mehdi Kianpour, now living in Canada. It’s like 15 years I’m working in this field and I think I can add something to online resources that may help other people fix their issues or understand a concept quicker. Recently, I’m engaged in some projects that are dependant on cloud technologies. Of course, we all know that cloud is the new (almost new) trend, while comparing to other networking stuff, there is less independent information over Internet. I will try to talk about some less experienced tasks and address some yet unknown issues and I hope this blog to be useful in this field.

And last but not least, I’m looking forward to hear from everybody (in specific other specialists) in my blog about the topics I cover or any other comment. So, see you soon!