• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

VMware ThinApp 4.7 Essentials by Peter Björk!

Duncan Epping · Nov 26, 2012 ·

About a year ago one of my colleagues reached out with some questions around book publishing. Many people ask me questions around what it takes, hours involved etc etc, and unfortunately many decide it is not the right time. I guess Peter Björk decided it was the right time as he managed to crank out this awesome book within a year. Congrats Peter, awesome work and major achievement!

The book is titled “VMware ThinApp 4.7 Essentials” and contains everything you need to know about ThinApp, or as the website states:

“VMware ThinApp 4.7 Essentials” shows you how to deploy ThinApp packages in order to improve the portability, manageability and compatibility of applications by encapsulating them from the underlying operating system on which they are executed.

In this book you will learn about how application virtualization works and how to deploy ThinApp packages. You will learn how to update and tweak ThinApp Projects before distribution. This book will then cover design and implementation considerations for future ThinApp projects.

You can find it on Amazon here: Kindle ($ 23.25) – Paper (54.99). Pick it up!

What is that poweron file in my .vSphere-HA folder?

Duncan Epping · Nov 23, 2012 ·

When answering some questions in the vSphere HA section of the VMTN forum the “poweron” file was mentioned. I have gotten some other questions as well about this file so a public blog post makes most sense.

Each hosts in a vSphere HA cluster keeps track of the power state of the virtual machines it is hosting. This set of powered on virtual machines is stored the “poweron” file. Note that this applies to both the master and the slave hosts in your cluster. This file is located on your vmfs volumes in the hidden directory “.vSphere-HA/<FDM cluster ID>“.

The naming scheme for this file is as follows:
host-<id>-poweron

Tracking virtual machine power-on state is not the only thing the “poweron” file is used for. This file is also used by the slaves to inform the master that it is isolated from the management network: the top line of the file will either contain a “0” (zero) or a “1”. A “0” means not-isolated and a “1” means isolated. The master will inform vCenter about the isolation of the host.

This also means that if a host is not sending out any heartbeats to the master, the master will validate if that host has been isolated by reading the “poweron” file. This could be considered as an extra check on top of the “datastore heartbeating” mechanism.

Want to do some VMware Hands-on Labs but don’t have the kit?

Duncan Epping · Nov 22, 2012 ·

Those who have visited VMworld and done a couple of labs know how awesome these are. Recently VMware announced that the VMware Hands-On Labs (HoL) would be made available online. You had the option to register for the beta and last week they announced the public beta was opened! On twitter some early reports are already popping up and judging by the comments people are loving it.

Just completed my first HOL – highly productive!! /cc @vmwarehol

— Maish Saidel-Keesing (@maishsk) November 22, 2012

 

@vmwarehol Glad to be a part of it! Really amazing stuff!!!

— Jake Robinson (@jakerobinson) November 17, 2012

 

Loving the HoL Beta! cc: @heyitspablo @vmwareholyfrog.com/mof74p

— Bill Hill (@virtual_bill) November 14, 2012

 

If you want to know more about the HoL portal make sure to read this blog, I played around with it various times… I loved it. Sign up and try it out. There is no excuse any longer for not having hands-on experience with VMware products, you don’t need to own a lab…

vSphere 5.1 Clustering Deepdive only $17.95, limited time!

Duncan Epping · Nov 21, 2012 ·

Frank and I decided to put the vSphere 5.1 Clustering Deepdive (paper copy) up for sale for only $ 17.95. This is a limited time offer (21st of December), so if you want to get yourself, your friend-husband-father-kids or even grandmother a nice present be quick.

How’s that for a black-friday, cyber-monday, christmas / sinterklaas special? Yes indeed, the paper copy is cheaper than all e-books on vSphere 5.x out there on Amazon and with 5 stars (11 reviews) you know you can’t go wrong.

Happy holidays,

Frank and Duncan
(ps: the kindle copy is only 7.49, so even combined it is cheaper than most e-books out there :-))

Thinking about a stretched vCloud Director deployment

Duncan Epping · Nov 20, 2012 ·

Lately I have been thinking about what it would take to deploy a stretched vCloud Director (vCD) infrastructure. “The problem” with a vCloud Director infrastructure is that there are so many moving components, this makes it difficult to figure out how to protect each component. Let me point out that I do not have all the definitive answers to this yet, I am writing this article to get a better understanding of the problem myself. If you do not agree with my reasoning please feel free to comment, as I need YOUR help defining the recommended practices around vCD on a stretched infrastructure.

I listed the components I used in my lab:

  • vCenter Server Management
  • vCenter Server Cloud Resources
  • vCloud Director Cells
  • vShield Manager
  • Database Server

That would be 5 moving components, but in reality we are talking more around 8. The thing here is that vCenter Server also has multiple components:

  • Single Sign On
  • Inventory Service
  • Web Client
  • vCenter Server

How do I protect these 8 components? The first 5 listed will be individual VMs and vCloud Director itself will be multiple cells even. What would this look like?

As you can see there are multiple vCenter Servers, one manages the Management Cluster and its components. While the other manages the “Cloud Resource Cluster”. Lets start listing all the components and discuss what the options are and if we can protect them in a special way or not.

vCenter Server (cloud resources and management)

vCenter Server can be protected through various methods. There is vCenter Heartbeat and of course we have vSphere HA (including VM Monitoring). First of all it is key to realize that neither of these solutions are fully “non-disruptive”. Both vSphere HA and vCenter Heartbeat will cause a slight disruption. vSphere HA will simply restart your VM when a host has failed, and vSphere HA – VM Monitoring can restart the Guest OS when the VM has failed. vCenter Heartbeat is a more intelligent solution, it can detect outages using a heartbeat mechanism and respond to that.

I guess the question is availability vs operational simplicity. How important is vCenter Server availability in your environment? Setting up vSphere HA and VM Monitoring is a matter of seconds. Installing and configuring vCenter Heartbeat is probably hours… And think about upgrade processes etc. I personally prefer not using vCenter Heartbeat but going for vSphere HA and VM Monitoring in this scenario, how about you?

What about these vCenter services like SSO / Inventory Service / Web Client etc. Although in a way, from a scalability/performance perspective, it might make sense to split things out… It also makes your environment more vulnerable to failures. What if 1 VM in your “vCenter service chain” is down. That might render your whole solution unusable. I would personally prefer to have vCenter Server, Inventory Service and the Web Client to be installed in a single VM. I can imagine that for SSO you would like to split it out, so that when you have multiple vCenter Server instances you can link them to the same SSO instance.

As mentioned SSO potentially could be deployed in an HA fashion. HA with regards to SSO is an active/standby solution, but I have been told there are other ways of deploying it and more info would be released soon.

Recommended Practice: I am a big fan of keeping things simple. Keep vCenter and at a minimum the Inventory Service together, and potentially the Web Client. Although Heartbeat has the potential of decreasing vCenter Server downtime, in many cloud environments SLAs are around vCloud workload availability and not about vCenter itself. One component that I would recommended to configure in a HA fashion is SSO. Without SSO you cannot login, this is critical for operations.

vCloud Director

Hopefully all of you are aware that vCloud Director can easily scale by deploying new “cells” as we call it. A cell is simply said a virtual machine running the vCD software. These cells are all connected to the same database and can handle load. Not only can they handle load, but they can also continue where another stopped. So from an Availability perspective this is ideal. I already depicted this in the diagram above by the way.

Recommended Practice: Deploy multiple vCloud Director cells in your management cluster. Ensure that at a minimum two cells reside on each of the “sites” of your stretched cluster. In order to achieve this vSphere DRS VM-Host affinity groups should be used!

vShield Manager

vShield Manager is one of the difficult components. It is a single virtual machine. You can protect it using vSphere HA but that is about it as the VM has multiple vCPUs which rules out FT. So what would make sense in this case? I would try to ensure that the vShield Manager is in the same site as vCenter Server. In the case there is a network failure between sites, at least the vShield Manager and vCenter Server can communicate when needed.

Recommended Practice: The vShield Manager virtual appliance resides in the same site as the vCenter Server, in other words it is a recommended practice to have both be part of the same vSphere DRS VM-Host affinity group. It is also recommended to leverage vSphere HA – VM Monitoring to allow for automatic restarts to occur in the case of a host or guest failure.

Database

This is the challenging one… As of vCloud Director 5.1 it is supported to cluster your database. So you could potentially cluster the vCD database. However this Database Server will host more than just vCD, it will probably also host the vCenter Server database and potentially other bits and pieces like Chargeback / Orchestrator etc. Not all of these support a clustered database solution today unfortunately. It is difficult defining a recommended practice in this case. Although Database Clustering will theoretically increase availability it will also complicate operations. From an operational perspective the difficult part is how to manage site isolations. Just imagine the network between Site-A and Site-B is down but all components are still running. What will you do with the database?

This is definitely one I am not sure about what to do with…

Summary

As you can see this is not a fully worked out set of recommended practices guide yet, there is still stuff to be figured out and I am going through the exercise as we speak. If you have an opinion about this, and I am sure many do, don’t hesitate to leave a comment!

  • « Go to Previous Page
  • Page 1
  • Interim pages omitted …
  • Page 199
  • Page 200
  • Page 201
  • Page 202
  • Page 203
  • Interim pages omitted …
  • Page 492
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Advertisements




Copyright Yellow-Bricks.com © 2025 · Log in