I managed to get out on dartmoor twice the weekend before last; once on the Friday night for a quick getaway, and more seriously on the Sunday night where Jackie and I managed a 12 mile round-trip hike.
I'm excited because a few recent purchases (ThermaRest Prolite, Montane Featherlite) and a slightly more ruthless approach to packing has reduced the weight of my pack by a couple of kilograms, but the best part is that with a cheap compression sack my Eureka Spitfire tent takes up a lot less room and I can now fit back in to my much lighter 45L Osprey pack for one or two-day trips instead of the massive and heavy 65+10L Berghaus beast.
A one-man tent with a decent vestibule is still high on my wishlist so I can drop the tarp I'm currently using to make a verandah, and as Jackie's more enthusiastic about nights away than I thought she might be, I'd really like to find a larger, lighter alternative to the depressingly pokey, cheap, and disproportionately heavy Millets special two-man tent we have to lug around at the moment.
I originally had my sights set on the venerable Terra-Nova Laser Comp, but I've been put off recently by questions about its stability in high-wind, what with nothing to support the tunnel structure and only a single end-guy. But it's still one of the best weight-to-room ratio tents that (my kind of) money can buy.
For a two-man, I'm tempted by a tarptent design. But again, the poor hydrostatic-head of silicon impregnated nylon is a worry - not so much for the fly, but the floor. So you start having to lug about a footprint just to keep the floor dry.
Anyway, I need to move on the one-man tent soon. The Eureka's all-mesh inner won't cut it as the temperature drops.
Friday, 10 September 2010
Thursday, 2 September 2010
More on SSD longevity
This whitepaper published by Western Digital is an interesting read and provides a couple of well thought-out equations for estimating SSD life with a known workload.
The trick is knowing your workload, and fitting it to the simple parameters in the WD LifeEST model.
The trick is knowing your workload, and fitting it to the simple parameters in the WD LifeEST model.
Wednesday, 1 September 2010
Exchange and SSDs
I'm designing an Exchange 2010 system at the moment as an upgrade from a clustered Exchange 2003 environment.
I won't go in to the details about the restrictions in the current system, save to say that even after having lots of physical spindles thrown at it, it's still IO bound.
So the new system is going to have SSD. And what a lot of fun that's turning out to be. Try finding some hard data on the life expectency of MLC SSDs under genuine enterprise (i.e. not desktop) workloads. Go on, I dare you. I'd settle for real-world life expectencies of MLC drives full stop.
Instead, everyone's throwing around the 10,000 program/erase cycle design spec with a caution to keep an eye on it, and the vendors seem reluctant to let go any real information how many writes you can expect to get away with before hard errors start to crop up.
Use SLC you say? Fair enough, but until the cost per GB comes down it's still likely to be more cost effective to burn through a couple of same-size MLCs on a price per GB per year equation. I think. See above re: vagaries of predicting drive failure.
Either SSD is still finding its feet in the enterprise space, or people just aren't writing about it yet. Or maybe the drives just haven't started to fail.
Reliability will improve as the technology continues to mature, and it's maturing fast. Even if I only get 6 months before the first drives start to burn out, which I think is exceedingly pessimistic, the replacement drives are likely to be hardier, and cheaper even then.
Anyway, I'm looking forward to getting of the design sheet on this one and starting to push bytes around. Stay tuned.
I won't go in to the details about the restrictions in the current system, save to say that even after having lots of physical spindles thrown at it, it's still IO bound.
So the new system is going to have SSD. And what a lot of fun that's turning out to be. Try finding some hard data on the life expectency of MLC SSDs under genuine enterprise (i.e. not desktop) workloads. Go on, I dare you. I'd settle for real-world life expectencies of MLC drives full stop.
Instead, everyone's throwing around the 10,000 program/erase cycle design spec with a caution to keep an eye on it, and the vendors seem reluctant to let go any real information how many writes you can expect to get away with before hard errors start to crop up.
Use SLC you say? Fair enough, but until the cost per GB comes down it's still likely to be more cost effective to burn through a couple of same-size MLCs on a price per GB per year equation. I think. See above re: vagaries of predicting drive failure.
Either SSD is still finding its feet in the enterprise space, or people just aren't writing about it yet. Or maybe the drives just haven't started to fail.
Reliability will improve as the technology continues to mature, and it's maturing fast. Even if I only get 6 months before the first drives start to burn out, which I think is exceedingly pessimistic, the replacement drives are likely to be hardier, and cheaper even then.
Anyway, I'm looking forward to getting of the design sheet on this one and starting to push bytes around. Stay tuned.
Tuesday, 31 August 2010
Hello World
Hi, Sam here.
When I heard Brendan was going to be starting a blog to help with the VCAP study, I thought it would be a great opportunity for me to stop procrastinating and work on it too.
So just a brief background on me. Started using VMWare back in 2000, first production ESX site in 2003 (ESX2.5), currently running ESXi 4.0 update 2 with an upgrade to 4.1 pending in 3 weeks. We have been running effectively "cloud services" since 2005 and have offered this under the guise of Utility Computing.
In the coming months, I hope to cover quite a bit on the VCAP blueprint as it relates to my current environment. Along with that I want to cover off on a few areas that appear to be lacking from what I have heard in podcasts and user group discussions. Things like developing a cost model, Billing Models, Virtualised Storage, Monitoring (Open Source Solutions), Monitoring (COTS) and some other tit bits learned by blooding my nose on the sharp end of innovation.
So enough from me now and talk to you all soon.
Saturday, 7 August 2010
Building an ESXi provisioning environment: Part 1
There are three things I knew I was going to need to build my provisioning environment:
The TFTP server is going to provide the PXE boot image and ESXi bootstrap files.
The FTP or web server is the repository from which the ESXi installable image, kickstart script (ESXi install script), and post-install configure/build scripts are going to come from.
As far as I'm concerned, the quickest and least resource intensive way to achieve all three is to knock up a small Linux box. I chose Debian.
The DHCP server is of the ISC variety and is provided by the dhcp3-server package.
I went with the tftpd-hpa package, but any TFTP server will work for this - I'm not using any interesting features.
I opted for a web server over an FTP repository for my install media as it lends itself to a configuration script repository better than FTP. Apache's httpd server is my weapon of choice and Debian puts it in the apache2 package.
The PXE boot environment files we need come from the syslinux-common package. You'll need that too.
Install with:
I've configured my host with the IP address of 10.0.0.1/24, which sets the scene for my DHCP server configuration.
My basic dhcpd configuration is:
I'm not expecting to be building more than ten hosts at once, but it's easy to extend anyway.
The next part is the PXE, or in this case gPXE configuration. Now I used the ESXi 4.1 setup guide to, er, guide me on the next part as I'd never heard of gPXE before now. Unfortunately, the VMware setup guide's gPXE example is poorly explained. They spend a lot of time talking about how great gPXE is because you can boot from HTTP or FTP (or iSCSI, or ATA-over-Ethernet, or whatever) but their guide will set you up to boot from TFTP, just like a regular PXE stack, so what's the point?
The VMware guide includes:
In a nutshell this defines a DHCP user class called "pxeclients" based on whether or not the vendor-class-identifier client identifier option contains the string "PXEClient" in its first nine characters. Not surprisingly, the PXE ROM in your network card does announce this.
So inside this class we can specify options and configuration that only apply to PXE clients. I've given the IP address of my Linux host as the next-server option. That's where the PXE client looks for its boot files. The next bit:
basically says: if you've not identified yourself as a gPXE client, retrieve and load the /gpxelinux.0 image.
tftpd-hpa uses /var/lib/tftpboot as its root directory. Put /usr/lib/syslinux/gpxelinux.0 in there. i.e.
Cool. But what about if you are a gPXE client? Then you'll try and pull down your configuration file based on where you came from: TFTP. I want to use HTTP as my boot protocol from this point. So I've changed that stanza to read:
Now everything that gPXE does from this point will be relative to http://10.0.0.1/, which means I've got to set up my web server file tree.
My apache document root contains this file structure:
The ./pxelinux.cfg/default file will be pulled down by the gPXE image. Mine's been ripped pretty much straight out of the VMware manual:
(Keep the append directive on a single line)
It gives me two options. I can either boot into the ESXi installer (label 1), or boot from the local disk (label 0). The default is the ESXi installer which will be invoked automatically after 50 seconds. Cool.
Everything in my ./boot directory came off the root of the ESXi install CD, as did the ./dist/imagedd.bz2 and ./dist/imagedd.md5 files. I could have just dumped everything in the root of /var/www but this way is neater.
The last part of the magic is the kickstart script referenced by the ks=http://10.0.0.1/ks/ks.cfg part of my PXE boot line.
For now, I've used:
The install url http://10.0.0.1/dist/ directive says to perform the install from my website.
And there we go. Everything you need to automatically build an army of basic ESXi servers. The resulting ESXi servers will use DHCP for their default vmkernel adapter.
Next time I'll cover my lab DNS setup and automatically deploying a basic per-host configuration on my freshly built ESXi systems using the %firstboot kickstart section.
- A DHCP server
- A TFTP server
- An FTP or web server
The TFTP server is going to provide the PXE boot image and ESXi bootstrap files.
The FTP or web server is the repository from which the ESXi installable image, kickstart script (ESXi install script), and post-install configure/build scripts are going to come from.
As far as I'm concerned, the quickest and least resource intensive way to achieve all three is to knock up a small Linux box. I chose Debian.
The DHCP server is of the ISC variety and is provided by the dhcp3-server package.
I went with the tftpd-hpa package, but any TFTP server will work for this - I'm not using any interesting features.
I opted for a web server over an FTP repository for my install media as it lends itself to a configuration script repository better than FTP. Apache's httpd server is my weapon of choice and Debian puts it in the apache2 package.
The PXE boot environment files we need come from the syslinux-common package. You'll need that too.
Install with:
vm-sys-cfg:~# apt-get install dhcp3-server tftpd-hpa apache2 syslinux-common
I've configured my host with the IP address of 10.0.0.1/24, which sets the scene for my DHCP server configuration.
My basic dhcpd configuration is:
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.201 10.0.0.210;
}
I'm not expecting to be building more than ten hosts at once, but it's easy to extend anyway.
The next part is the PXE, or in this case gPXE configuration. Now I used the ESXi 4.1 setup guide to, er, guide me on the next part as I'd never heard of gPXE before now. Unfortunately, the VMware setup guide's gPXE example is poorly explained. They spend a lot of time talking about how great gPXE is because you can boot from HTTP or FTP (or iSCSI, or ATA-over-Ethernet, or whatever) but their guide will set you up to boot from TFTP, just like a regular PXE stack, so what's the point?
The VMware guide includes:
option space gpxe;
option gpxe-encap-opts code 175 = encapsulate gpxe;
option gpxe.bus-id code 177 = string;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server 10.0.0.1;
if not exists gpxe.bus-id {
filename "/srv/tftp/gpxelinux.0";
}
}
In a nutshell this defines a DHCP user class called "pxeclients" based on whether or not the vendor-class-identifier client identifier option contains the string "PXEClient" in its first nine characters. Not surprisingly, the PXE ROM in your network card does announce this.
So inside this class we can specify options and configuration that only apply to PXE clients. I've given the IP address of my Linux host as the next-server option. That's where the PXE client looks for its boot files. The next bit:
if not exists gpxe.bus-id {
filename "/gpxelinux.0";
}
basically says: if you've not identified yourself as a gPXE client, retrieve and load the /gpxelinux.0 image.
tftpd-hpa uses /var/lib/tftpboot as its root directory. Put /usr/lib/syslinux/gpxelinux.0 in there. i.e.
vm-sys-cfg:~# find /var/lib/tftpboot/ /var/lib/tftpboot/ /var/lib/tftpboot/gpxelinux.0
Cool. But what about if you are a gPXE client? Then you'll try and pull down your configuration file based on where you came from: TFTP. I want to use HTTP as my boot protocol from this point. So I've changed that stanza to read:
if not exists gpxe.bus-id {
filename "/gpxelinux.0";
} else {
filename "http://10.0.0.1/";
}
Now everything that gPXE does from this point will be relative to http://10.0.0.1/, which means I've got to set up my web server file tree.
My apache document root contains this file structure:
vm-sys-cfg:~# cd /var/www vm-sys-cfg:/var/www# find . ./index.html ./cfg ./cfg/cfg-00:0c:29:f2:55:a7.sh ./dist ./dist/imagedd.md5 ./dist/imagedd.bz2 ./ks ./ks/ks.cfg ./boot ./boot/vmkboot.gz ./boot/vmkernel.gz ./boot/ienviron.vgz ./boot/cim.vgz ./boot/sys.vgz ./boot/install.vgz ./boot/mboot.c32 ./boot/menu.c32 ./pxelinux.cfg ./pxelinux.cfg/default ./gpxelinux.0
The ./pxelinux.cfg/default file will be pulled down by the gPXE image. Mine's been ripped pretty much straight out of the VMware manual:
default 1 prompt 1 menu title VMware VMvisor Boot Menu timeout 50 label 1 kernel boot/mboot.c32 append boot/vmkboot.gz ks=http://10.0.0.1/ks/ks.cfg --- boot/vmkernel.gz --- boot/sys.vgz --- boot/cim.vgz --- boot/ienviron.vgz --- boot/install.vgz label 0 localboot 0x80
(Keep the append directive on a single line)
It gives me two options. I can either boot into the ESXi installer (label 1), or boot from the local disk (label 0). The default is the ESXi installer which will be invoked automatically after 50 seconds. Cool.
Everything in my ./boot directory came off the root of the ESXi install CD, as did the ./dist/imagedd.bz2 and ./dist/imagedd.md5 files. I could have just dumped everything in the root of /var/www but this way is neater.
The last part of the magic is the kickstart script referenced by the ks=http://10.0.0.1/ks/ks.cfg part of my PXE boot line.
For now, I've used:
# Accept the VMware End User License Agreement vmaccepteula # Set the root password for the DCUI and Tech Support Mode rootpw p4ssw0rd # Erase partition table on first local disk clearpart --firstdisk=local --overwritevmfs # Choose the first discovered disk to install onto autopart --firstdisk --overwritevmfs # The installation media is in the CD-ROM drive install url http://10.0.0.1/dist/ # Set the network to DHCP on the first network adapater network --bootproto=dhcp --device=vmnic0 --addvmportgroup=0
The install url http://10.0.0.1/dist/ directive says to perform the install from my website.
And there we go. Everything you need to automatically build an army of basic ESXi servers. The resulting ESXi servers will use DHCP for their default vmkernel adapter.
Next time I'll cover my lab DNS setup and automatically deploying a basic per-host configuration on my freshly built ESXi systems using the %firstboot kickstart section.
VCAP and building an ESXi provisioning environment
So I'm starting down the VMware VCAP road, and I want to be thorough about it, because I've read the first hand reports of people who've sat the VCAP Datacenter Administration beta exam and it sounds tough.
Being thorough means a painstaking walk through the exam blueprint. And there's going to be lots to learn as the VCAP isn't just about basic vCenter and the vSphere hypervisor any more, and that means spending time with Orchestrator, vShield Zones, the PowerCLI and much more besides; stuff which I haven't had a need to explore up to now.
But the best place for me to start is with ESXi 4.1, or as it now seems to be called (according to the download), VMvisor. Partly this is because up to now all of my VMware hypervisor work has been with ESX, console operating system and all, and that's for historical reasons (I've been doing this since before ESXi existed). But mostly it's because vSphere 4.1 is the last time we'll see the ESX service console as all future versions will be ESXi only.
Now, in the interests of making life easy for myself, I've built a simple provisioning environment to take advantage of the new scripted install mode in ESXi 4.1. This means I can have a central repository of build and configure scripts and spin up an arbitrarily complex ESXi test lab at the push of a couple of PXE-capable network-card buttons. This is a Good Thing™ because each task/step in the exam blueprint isn't necessarily going to be feature-compatible with the preceding or subsequent steps so being able to tear down and rebuild a lab repeatably and consistently is going to prove essential.
I'm building my ESXi lab on top of ESXi itself. Each 4GB physical host will house at least two 2GB ESXi systems. I'm doing that because it lets me take advantage of memory over-provisioning since I don't have the budget for more than 4GB per host, and I can have as many virtual network cards per virtual-ESXi as I need. Throw in a few Linux VMs as routers and I've got a WAN in a box as well. There'll be more about the lab architecture later.
The test lab doesn't have to be fast, it just has to work - so I don't mind so much if I end up swapping with the virtual-ESXi guests.
Anyway, that's the precis. The build environment comes next.
Being thorough means a painstaking walk through the exam blueprint. And there's going to be lots to learn as the VCAP isn't just about basic vCenter and the vSphere hypervisor any more, and that means spending time with Orchestrator, vShield Zones, the PowerCLI and much more besides; stuff which I haven't had a need to explore up to now.
But the best place for me to start is with ESXi 4.1, or as it now seems to be called (according to the download), VMvisor. Partly this is because up to now all of my VMware hypervisor work has been with ESX, console operating system and all, and that's for historical reasons (I've been doing this since before ESXi existed). But mostly it's because vSphere 4.1 is the last time we'll see the ESX service console as all future versions will be ESXi only.
Now, in the interests of making life easy for myself, I've built a simple provisioning environment to take advantage of the new scripted install mode in ESXi 4.1. This means I can have a central repository of build and configure scripts and spin up an arbitrarily complex ESXi test lab at the push of a couple of PXE-capable network-card buttons. This is a Good Thing™ because each task/step in the exam blueprint isn't necessarily going to be feature-compatible with the preceding or subsequent steps so being able to tear down and rebuild a lab repeatably and consistently is going to prove essential.
I'm building my ESXi lab on top of ESXi itself. Each 4GB physical host will house at least two 2GB ESXi systems. I'm doing that because it lets me take advantage of memory over-provisioning since I don't have the budget for more than 4GB per host, and I can have as many virtual network cards per virtual-ESXi as I need. Throw in a few Linux VMs as routers and I've got a WAN in a box as well. There'll be more about the lab architecture later.
The test lab doesn't have to be fast, it just has to work - so I don't mind so much if I end up swapping with the virtual-ESXi guests.
Anyway, that's the precis. The build environment comes next.
Monday, 17 May 2010
Fa Jin (發劲)
I learned an important lesson about fa jin (發劲) on Sunday while training pao chui (炮捶 - 老架二路); don't over-reach the end-stop. It's a simple principle really, and an obvious one. Don't over-stretch the punch. Don't over-stretch an elbow, or a shoulder. Most of the 太极拳 fa jin expressions are design for use at very close range. Even strikes like that found in 掩手肱拳 (Hidden Punch) are close range attacks.
Mentally bringing my "target" two inches closer to my body made my expression of fa jin (發劲) in the punch so much sharper, and more balanced.
Pao chui (炮捶) was a lot of fun to train, but I'm not ready for it yet.
On a related note, while looking up the characterisation of 發劲 I found a wonderful short video of Chen Xiao Wang (陈小旺) demonstrating applications of the first Buddha's Warrior Attendant Pounds the Mortar (金刚捣碓).
And remember, kids; you can't 發劲 round corners.
Mentally bringing my "target" two inches closer to my body made my expression of fa jin (發劲) in the punch so much sharper, and more balanced.
Pao chui (炮捶) was a lot of fun to train, but I'm not ready for it yet.
On a related note, while looking up the characterisation of 發劲 I found a wonderful short video of Chen Xiao Wang (陈小旺) demonstrating applications of the first Buddha's Warrior Attendant Pounds the Mortar (金刚捣碓).
And remember, kids; you can't 發劲 round corners.
Subscribe to:
Posts (Atom)