ssd.iometer.followup.tests.123109.txt

I needed to followup on my test results with the Iomega IX4-200d SSD iometer testing to see what could be going on.. see http://blog.randyjcress.com/2009/12/howtokillanix4-200dwithssdiometertests1.html for the first set of numbers, but I will duplicate them here for comparision purposes.

The main goal was to keep the (4) Kingston SSDNow V-Series 128GB SSD Drives in a hardware RAID10 array throughout the testing process. I will drop the millisecond avg and max because it matters, but isn't the focal point..

Group_A: Iomega IX4-200d RAID10 SSD drives, 1Gb/s iSCSI to VMware ESX 4.0.0 bld 208167 with Windows Server 2008 x86 VM.

Group_B: Iomega IX4-200d RAID5 1TB mechanical disk, 1Gb/s iSCSI to VMware ESX 4.0.0 bld 208167 with Windows Server 2003 VM - http://www.gabesvirtualworld.com/?p=909

Group_C: RAID10 SSD Drives with LSI Logic PCIe MegaRAID SAS 8204ELP on Windows 7 Enterprise x64 direct IOMeter tests on the SYSTEM volume (C:)

Group_D: RAID10 SSD Drives with LSI Logic PCIi MegaRAID SAS8204ELP on Windows 7 Enterprise x84 with StarWind iSCSI Free Target with 1Gb/s Broadcom network connection

Results:

Test 001a - Max Throughput 100% read

Group_A: 1891.9 IOPS @ 59.1 MB/s
Group_B: 1761.9 IOPS @ 55.1 MB/s
Group_C: 4758.0 IOPS @ 148.63 MB/s
Group_D: 3361.7 IOPS @ 105.1 MB/s

Test 001b - RealLife-60%Rand-65%Read

Group_A: 179.2 IOPs @ 1.4 MB/s
Group_B: 89.2 IOPS @ 0.70 MB/s
Group_C: 109.0 IOPs @ 0.85 MB/s
Group_D: 99.3 IOPS @ 0.78MB/s

Test 001c - Max Throughput-50%Read

Group_A: 1589.9 IOPS @ 49.7 MB/s
Group_B: 705.3 IOPS @ 22.0 MB/s
Group_C: 1220.0 IOPS @ 38.0 MB/s
Group_D: 1771.63 IOPS @ 55.4 MB/s

Test 001d - Random-8k-70%Read

Group_A: No Results (SCSI failure)
Group_B: 64.7 IOPS @ 0.51 MB/s
Group_C: 121.8 IOPS @ 0.94 MB/s
Group_D: 95.0 IOPS @ 0.74 MB/s

Happy New Year!

decaf.v2.quick.review.123009.txt

After reading the emails on COFEE and DECAF because of some odd newsletter I am subscribed to and then seeing the following post: http://windowsir.blogspot.com/2009/12/lions-and-tigers-and-decafoh-my.html

I figured it would only be prudent to give it a shot..

First impression.. Is this whole thing a 2009 end of year joke? While I understand it has value, here are some simple steps to side-step decaf or just understand is weakness..

It runs in the systray, right-click, maximize and close it. That was easy.

Or if you don't want to touch anything on the system, just rename your tools.. I didn't take the time to join the forum and search is disabled for guests, but the signatures.dat file isn't utilizing MD5 or SHA-1 hashes. It's just plain and simple process name matching..

Tested tools that you can try yourself..

autoruns.exe, pslist.exe, pskill.exe, windd.exe, PasswareKitEnterprise.exe

Note the case-sensitivity in the PasswareKitEnterprise.exe.. I renamed NOTEPAD.EXE to passwarekitenterprise.exe and noticed that the workstation didn't lock, renamed it with with the proper case to match the commercial app and voila, decaf responds!

I am not assuming the person that decides to run decaf to "protect" their workstation should be a Windows Administrator, but atleast take the time to google "Software Restriction Policies" and see what you can do with hash rules, path rules and for the most-restrictive systems, certificate rules..

In the meantime, decaf should focus on making the signatures.dat and open standard with plain-text readable filenames, hash values (MD5 and SHA1) with version numbers instead of lack-luster case-sensitive process executable name matching to call a lock workstation API method.

how.to.kill.an.ix4-200d.with.ssd.iometer.tests.123009.txt

In response to Gabe's Virtual World post on his IX4-200D testing @
http://www.gabesvirtualworld.com/?p=909

and the follow-up from Ewan's blog:
http://ewan.to/post/307847803/thoughts-on-iomega-ix4-200d-performance-tests


My test environment is:

Host: VMware ESX 4.0.0 bld 208167 2Gb/s etherchannel
VM: Windows Server 2008 x86

NAS: Iomeda IX4-200d with (4) Kingston SSDNow V-Series 128GB SSD - RAID10

IOMeter with OpenPerformanceTest.icf

Test 001a - Max Throughput 100% read

1891.9 IOPS
59.1 MB/s
32.4 Ms Avg
139.2 Ms Max

Test 001b - RealLife-60%Rand-65%Read

179.2 IOPS
1.4 MB/s
332.0 Ms Avg
17150.3 Ms Max

Test 001c - Max Throughput-50%Read

1589.9 IOPs
49.7 MB/s
38.1 Ms Avg
296.5 Ms Max

Test 001d - Random-8k-70%Read

- NO RESULTS - Kills the NAS iSCSI with the ESX vmkernel's log of:

vmkernel: 0:01:12:59.532 cpu5:4116)WARNING: ScsiDeviceIO: 1266: Failed to issue command (0x16) on device naa.5000144f84161597: Timeout

Rescanning the VMFS volumes didn't help, removing and re-adding the VMware iSCSI Initiator entries didn't help.. what worked is rebooting the Iomega IX4-200d device. This was tested three times for verification.. if anyone cares to browse the vmware logs let me know..

Ran the ATTO Disk Benchmark v2.46 from: www.attotech.com

Ended up getting close to a 40MB/s write and >70MB/s read rates overall..

reduce.1st.run.backup.time.and.size.with.sdelete.121909.txt

This should be the first in a few very interesting findings while trying to reduce backup windows and disk/tape storage requirements for a fully virtualized environment in vSphere 4.0 with Veeam 4.1.

Ok, I figured this would have some impact after reading about zeroing free space on an NTFS volume..

Single server test on a VM (HW ver 7) that is 3 years old:
(bound to be alot of deleted data from windows updates and software upgrades)

ServerA - 8GB C:, 10GB E: - 18GB Total Provisioned Space

Pre-zeroing free space: Backup Time: 5:03, Total .vbk size: 5,852,222 KB
Post-zeroing free space: Backup Time: 4:23, Total .vbk size: 4,139,682 KB

Full 1st run backup time savings: 13% (40 seconds)
Full 1st run backup disk space savings: 29% (1,712,540 KB)

Two unique jobs were created in Veeam using optimal compression, VSS, and Change Block Tracking (CBT) was not turned on.

The tool used to zero the free space was the Systernals: SDelete from 2005!
("sdelete -c c:" then sdelete -c e:")
It took a couple of minutes to run inside the VM, very easy..'

I wanted to run this on one VM to highlight the potential savings (and to get quick results) in order to see how this would scale to hundreds of VMs.

If you can save ~25% on your first run backups, think of the money you could save with backup solutions that charge based on backend storage used.. EMC Avamar comes to mind.

This is pure speculation and it would be very difficult to predict. Factors include length of VM service and number of updates and software upgrades performed. On database servers that export to flat files you may have very large deleted files, etc..

So, before you jump on a solution, take a few minutes to realize that there is a bunch of blocks used by your VMs that can be zeroed and compressed very nicely saving you time, disk space and money.

client.workload.virtualization.xp.with.ramdisk.120509.txt

Where blog.storming meets brain.storming.. Here is a sample of what can be achieved with a Windows XP Pro SP3 Virtual Machine running on a Windows 7 x64 laptop with VMware Workstation 7 with 4GB RAM carved into a 2GB RAMDisk and 384MB VM:

http://j.mp/8kkdeN (if you can spare 75 seconds to watch the video)

Next step is to run Windows 2008 x64 with 16-32GB RAM and a 24GB RAMDisk serving a Citrix Provisioning Services volume to a PXE Boot client connected with a full 1GB/s ethernet link..