Yellow Bricks

by Duncan Epping

iscsi

vscsiStats

· ·

I was doing performance troubleshooting with Frank Denneman this week and we wanted to use “vscsiStats” to verify if there was any significant latency.

We checked multiple whitepapers before we went onsite and our primary source was this excellent article by Scott Drummonds. After start vscsiStats and receiving a “successful started”  we waited for 15 minutes and verified if we could see any data at all. Unfortunately we did not see anything. What is happening here? We checked the build/patch level and it was ESX 3.5 Update 4. Nothing out of the ordinary I would say. After trying several VMs we still did not see anything with “vscsiStats -s -w <worldID>”. For some weird reason, in contrary to what all blog articles are stating and what Scott Drummonds states we had to use the following command:

vscsiStats -s -t -w <worldID>

This might not be the case in most situations, but again we had to add “-t” to capture any data. You can find the world ID of the VM you want to monitor the performance by using the following command:

vscsiStats -l

After a couple of minutes you can verify if any data is being collected by using the following command:

vscsiStats -p all -w <worldID>

If you want to save your data in a CSV file to import it in Excel use the following:

vscsiStats -p all -c -w <worldID> > /tmp/vmstats-<vmname>.csv

Don’t forget to stop the monitoring:

vscsiStats -x -w <worldID>

So what’s the outcome of this all? Well with vscsiStats you can create great diagrams which for instance show the latency. This can be very useful in NFS environments as esxtop does not show this info:

If you don’t want to do this by hand, check out this article by Gabe.

Multi Protocol Storage Provisioning with COMSTAR

· ·

I was just reading up on the enormous amount of articles I had waiting in Google Reader. I try to keep up to date as much as possible but sometimes there’s just not enough time. I just noticed an excellent article of Mike La Spina on COMSTAR. COMSTAR is part of OpenSolaris and on the OpenSolaris website it described as follows:

COMSTAR is a software framework that enables you to turn any OpenSolaris host into a SCSI target that can be accessed over the network by initiator hosts. COMSTAR breaks down the huge task of handling a SCSI target subsystem into independent functional modules. These modules are then glued together by the SCSI Target Mode Framework (STMF).

Mike wrote a really extensive article on how-to setup COMSTAR. I must admit it looks promising, and it’s open source… freely available! Also be sure to check out these pages on the OpenSolaris section of SUN’s website.

Update your bookmarks

· ·

Update your bookmarks, EMC’s Chad Sakac recently started blogging and already wrote some cool article. Check out his blog and add it to your RSS reader and/or bookmarks.

A couple of outtakes:

I’ve been working with 10 joint VMware/EMC customers this week in NY, NJ and Houston (phew!), and was in Australia the week before last where there were 2 more. Out of those 12, 4 asked me questions about the applicability of “stretching” their ESX clusters across geographic distances – that’s 33%, and absolutely above the “man, I should write a blog on the topic” threshold.

So, what are we talking about?

A stretched cluster is the practice of having ESX member servers in a cluster that are geographically separated. The reason this is generally done is to provide the ability to dynamically move workloads from one datacenter to another. Often, the customer is also considering it for disaster recovery purposes (“I’ll just VMotion in case of a disaster”). Can this be done – ABSOLUTELY – but not considered lightly.

read more…

I guess it was inevitable, but it’s still depressing. Traveling around the world means I read a LOT of magazines – there’s that 15 minutes of airplane ascent and decent where my usual toys (PSP, iPod, DS) are verboten. Some stuff (like the Economist) I read to expand my horizons, some stuff (like Maximum PC) I read as the nerd equivalent of Maxim (completely vacuous brain mush).

I couldn’t resist the headline of this month’s Windows IT Pro: “Virtualization Wars: Hyper-V vs. ESX Server ”

read more…

I am so not into protocol and transport wars – BUT that still doesn’t change the fact that the future is Ethernet-connected. So, then what about protocol? iSCSI, NFS, or FCoE? Well – NFS will continue to do well – it works well, there’s nothing wrong with it – and it will always have the strengths that it has in the VMware context (so easy to create massive datastores that span ESX clusters or even sites). iSCSI will continue to grow wildly (it is the fastest growing in the market at large, and in EMC’s portfolio) and is (IMHO – I’m still in love) the future of the block storage market en masse. BUT, I’m starting to come around on FCoE.

read more…

Nice iSCSI EMC/VMware PDF online

· ·

VMware just uploaded a cool PDF about configuring an iSCSI SAN. This particular PDF is created by EMC and deals about an EMC Celerra iSCSI SAN but there’s more than enough useful info in there for those who don’t own an EMC iSCSI SAN.

The cool thing about the Celerra is the possibility to use “network load balancing”. Where most iSCSI SAN’s work with a group address, which forces ESX to always walk the same path, the Celerra SAN’s use multiple interfaces with multiple ip-adresses. Would like to see this in real life…

New VCB features

· ·

When exploring VCB 1.1 I noticed some new features. One of the most prominent is the option to run VCB from within a VM. I can hear most of you think what’s the point of that and how about that HBA / iSCSI connection you need. Well if it’s of any use I will leave in the middle because I don’t see any reason for virtualizing VCB for larger environments. But for small environments, which don’t have shared storage this can be an easy way to dump their data without resorting to unsupported scripts. VCB is easily setup via the executable, next next finish. [Read more…] about New VCB features