Author: Michael Schroeder

Posted on

Resilient Network Infrastructure for Virtualization

Network topology 101 for Virtual Infrastructures

I usually don’t like writing about obvious matters. Yes, fire is hot – night is dark and ice is cold. But in recent times I’ve witnessed some network topology designs (?), that made me frown.

I admit, that in some cases the situation is based on a lack of budget or just structures that have grown over years. I can understand that and it’s no shame. It’s my job to give advices and help to re-design.

No matter how many resources you have – if you use them without thinking, it will never be enough.

On the other hand there are environments who boast with high class components that have cost a fortune and which are organized in such an inefficient way that it almost hurts.

This article is not intended as a networking deep-dive. It’s a shallow 101 about network design that should be common knowledge. It’s a guide for the novice but I’d be happy to get responses by experts too.

The Basics

First let’s start with four simple networking requirements for Virtual Infrastructures.

  • redundancy
  • resiliency
  • bandwidth
  • latency

Continue reading “Resilient Network Infrastructure for Virtualization”

Posted on

create kernel panic on ESXi

There are situations when you need to check cluster reactions after a ESX host crash. For example to see if HA will start VM on other hosts.

The easiest method is to pull a hosts powercord. But there ar more elegant ways to let a host crash.

Warning! Do not use on productive systems! This is for testing purposes under controlled conditions only. Use at your own risk.

PSOD

You can trigger a Purple-Screen-of-Death (PSOD) by issuing a special command that causes a kernel panic.  Use the VMkernel Sys Info Shell (vsish).

First you need a SSH connection to your host. Change to vsish

vsish
set /reliability/crashMe/Panic

Alternatively you can issue the command together with parameters.

vsish -e set /reliability/crashMe/Panic 1

Your host will end up in a PSOD and can be restarted afterwards.

 

Posted on

Backup vCenter Server High Availability nodes

Using Veeam Backup to protect VCHA

The vCenterServer Appliance (VCSA) is becoming more and more important. Many vSphere-related services rely deeply on the availability of vCenter. So it was a logic move to make vCenter more available by having an active, a passive and a witness node of vCenter in your cluster. In case the active appliance breaks, the passive appliance will take over.

I’ve been experimenting with VCHA for a while. Although I’m not yet satisfied with the failover time (5-10 minutes), I think it is a move into the right direction. I wouldn’t call it “high” availability right now – maybe “elevated” availability. But nevertheless the failover time might be alright for many environments today and it is used for production. That raises an important question:

How to backup a vCenter High Availability node?

If you have a standalone VC you’ll just make a backup or replica and you’re finished. But VCHA consists of 3 components and before backing up you’ll need to find out which one is the active node, because VMware only supports VADP-based backups (VMware vStorage API for Data Protection) of the active node. There’s no point in backing up the passive node or the witness. Keep in mind that active and passive node may have switched roles since last backup! Continue reading “Backup vCenter Server High Availability nodes”