In the second part of my series of testing home lab NAS/SAN solutions I tested Open-E’s DSS v6.
I had been planning on testing the current release candidate of FreeNAS, RC5, unfortunately during initial testing this proved to be a little unreliable in it’s current state as you can’t mount iSCSI targets, even from the command line, NFS shares however do work ok. Until FreeNAS release a version that I am comfortable working with I am stopping testing with FreeNAS at this time.
With the recent release of Openfiler 2.99 there has been an on-going issue with an inability to create certain software RAID arrays. This is present in the beta and final release of the software and was getting frustrating, however there is a fix.
If you are going to be installing Openfiler 2.99 and discover that you’re not able to create software RAID 1 arrays then the following will resolve that for you.
In this new NAS\SAN Shoot-Out series I will be testing available NAS\SAN solutions out there for those of you wanting a free\cheap home based Lab NAS\SAN solution for your vSphere labs.
I will be providing the testing results of the following software solutions:-
Iomega IX4-200D
Openfiler (2.99)
FreeNAS (7.2 and 8.0RC5)
NexentaStor (3.0.4)
OpenIndiana (Build 148 – using napp-it)
Oracle Solaris 11 Express (using napp-it)
Open-E DSS (6)
Having installed Veeam FastSCP onto my Windows 7 (64) Ultimate workstation I was getting frustrated with the error messages I was getting "Retrieving the COM class factory for component with CLSID [5F1555F0-0DBB-47F6-B10B-0AB0E1C1D8CE} failed due to the following error: 800700c1", a quick google search found the answer for me.
Looking into the fix I found here I realised that it’s a tad long winded and bloated (no disrespect intended, as it is the fix). So I thought to myself, did I actually need all of that for the fix to work. The answer is no.
Having looked at what was required (running "corflags "C:\Program Files (x86)\Veeam\Veeam Backup and FastSCP\VeeamShell.exe" /32BIT+" to resolve the issue with FastSCP not working on any 64bit Windows OS resulted in the above error message when trying to copy files between Datastores) I decided to see what happens if I just took the corflags.exe file and ran that instead of having the entire SDK installed, the results were that the program now works.
My hardware raid controller (Lenovo branded M1015) simply isn’t recognised by OF or Freenas 7.2 and FreeNas 8 (RC2 and RC3) has a penchant for just crashing during the installation.
I have been toying with NexentaStor but haven’t been overly impressed with my SSD failing on it (the SSD works fine in Windows but fails under Nexenta), I have noticed that there were others experiencing the same issues with the OCZ Onyx 32gb SSD so I tried using an external SATA card.. which of course wasn’t recognised by NexentaStor, Solaris or Open Indiana, so that blew out my chances of getting the L2ARC working on any of them.
Today I reinstalled my vCenter server so that I could manage both of my vSphere Hosts centrally, the installation itself went as smoothly as possible but there was one small blip.
When connecting to the vCenter server I discovered that I couldn’t browse to the Hardware Status page but if I connected directly to the host with the vSphere client I had no issues.
A Google search later found that this had been an issue back in 2009 but I hadn’t really found much since, the methods to fix this differed slightly with me probably down to the fact that I had installed vCenter onto a 2008 R2 SP1 installation.
To fix the issue on a 2008 R2 installation do the following.
1. On the vCenter server go to Start – Run – ADSI Edit
2. Select connect to and ensure the following is selected under connection settings
– Connection name – vCenter
– Connection Point – Distinguished Name is selected and name is “dc=virtualcenter, dc=vmware,dc=int”
– Computer – Server name : localhost
– port : 389
– Click ok to connect
4. Once in Adsi Edit browse to
Right click on the CN=VIMWEBSVC and choose Properties.
Scroll Down to vmw-vc-URL
Here we can see that this is populated with a DNS name, we are going to change it to an IP address.
Click OK and exit out from ADSI Edit.
At this stage I then launched Services.MSC and restarted the two following services.
However, when trying to restart the VMware VirtualCenter Server service (which requires a restart of the Webservices service anyway) I had an issue where the VMware VirtualCenter Management Webservices service wouldn’t restart, at this point a simple reboot resolved the issues.
Once the vCenter server had restarted (and I reconnected back via the vSphere Client) I then went to the Hardware Status Page and was presented with the following screen.
All fixed 🙂
Hi all, as some of you may know I recently experienced issues with my IX4 whilst using the paid for TZO subscription service for remote access, having diagnosed the fault down to one of two different avenues.
1, Jumbo Frames
2, Bonded NICs
I disabled both and over the last two weeks have re-enabled NIC teaming, I can now advise you that during that period I had one issue with the device losing connectivity (not the old message, something new this time that I am putting down to my changing things on my Netgear switch rather than the IX4), since the reboot (over a week ago now) I haven’t experienced any further issues with the performance or availability of the device.
Running my own home based lab I had struggled to find out which storage solution was going to be the best for me, I had multiple choices with the types of storage I could use (I own the following storage enabled\capable hardware; Buffalo TeraStation Pro 2, Iomega IX4-200d 2TB and HP’s MicroServer running Openfiler 2.3).
Over the last couple of weeks I have been carrying out various tests to see which device I would be using as my NAS\SAN solution and which device would end up being the location to store my Veeam Backups on.
All three devices run software raid, although I am about to try and fit an IBM M1015 SAS\SATA Controller in to my HP MicroServer (with the Advanced Key to allow Raid 5 and 50)) so both the Iomega and HP were similar where raid types were concerned. The Terastation is an already operational device that has existing data on it and could only be tested using NFS, it’s never really been in contention where SAN\NAS devices for ESXi was concerned.
Where I wasn’t sure about was whether I would be better off using RAID’s 0, 5 or 10 (obviously I am aware of the resilience issues with RAID 0 but I do have to consider the performance capacity of it as I do want to run a small VMware View lab here as well), not only was there a decision on the RAID types but also should I go down the iSCSI or NFS route as well.
Having read a number of informative blog and forum posts I knew that to satisfy my own thirst for knowledge I was going to have to perform my own lab testing.
Lab Setup
OS TYPE: Windows XP SP3 VM on ESXi 4.1 using a 40gb thick provisioned disk
CPU Count \ Ram: 1 vCPU, 512MB ram
ESXi HOST: Lenovo TS200, 16GB RAM; 1x X3440 @ 2.5ghz (a single ESXi 4.1 host with a single running Iometer VM was used during testing).
STORAGE TYPE
Iomega IX4-200d 2TB NAS, 4x 500gb, JBOD – iSCSI, JBOD – NFS, RAID 10 – iSCSI, RAID 10 –NFS, RAID 5 – iSCSI and finally RAID5 – NFS ** Software RAID only **
Buffalo TeraStation Pro 2, 4 x 1500gb, RAID 5 – NFS (this is an existing storage device with existing data on it so I could only test with NFS and the existing RAID set, the device isn’t iSCSI enabled).
HP MicroServer, 2gb ram, 4 x 1500gb + the original servers 1.6tb disk for the Openfiler OS install, RAID 5 – iSCSI, RAID5 – NFS, RAID 10 – iSCSI, RAID 10 –NFS, RAID 0 – iSCSI and finally RAID 0 – NFS.
Storage Hardware: Software based iSCSI and NFS.
Networking: NetGear TS724T 24 x 1 GB Ethernet switch
Iometer Test Script
To allow for consistent results throughout the testing, the following test criteria were followed:
1, One Windows XP SP3 with Iometer was used to monitor performance across the three platforms.
2, I utilised the Iometer script that can be found via the VMTN Storage Performance thread here, the test script was downloaded from here.
The Iometer script tests the following:-
TEST NAME: Max Throughput-100%Read
size,% of size,% reads,% random,delay,burst,align,reply
32768,100,100,0,0,1,0,0
TEST NAME: RealLife-60%Rand-65%Read
size,% of size,% reads,% random,delay,burst,align,reply
8192,100,65,60,0,1,0,0
TEST NAME: Max Throughput-50%Read
size,% of size,% reads,% random,delay,burst,align,reply
32768,100,50,0,0,1,0,0
TEST NAME: Random-8k-70%Read
size,% of size,% reads,% random,delay,burst,align,reply
8192,100,70,100,0,1,0,0
Two runs for each configuration were performed to consolidate results.
Lab Results
After a long week or so (not only did I have to test each device twice, I also had to move the VM between devices which also took up time) I have come up with the following results.
Iomega IX4-200D Results
Openfiler 2.3 Results
TeraStation Pro II Results
Conclusions
Having looked at the results the overall position is clear, the Iomega IX4-200D is now going to be my Veeam backup destination whilst my HP MicroServer is going to be my centralised storage host for ESXi, I now have to decide whether to go for the R0 or R10 iSCSI approach as they offer the best performance, at this stage I am tempted to go for the Raid 10 approach however because the disks in the server aren’t new. Over the next few months I will see how the reliability of the solution is and take it from there.
One thing I can add however is that over the next couple of days I will be attempting to fit my M1015 RAID controller in there and seeing how that performs, once fitted I will re do the Openfiler tests and post an update.
An update to my previous post.
Having purchased the subscription for the TZO Remote Access for the NAS device I eventually had to open a support call with TZO because the SSL certificate still wasn’t downloaded to the device.
The only way that I actually managed to get the device to re-enable Remote Access was to completely wipe the unit, thereby returning it to factory default, that’s ok if it’s a new device and doesn’t contain data but when you have 4tb of data on the unit it starts making life a little difficult (luckily for me the IX4 is my backup unit, it stores replicated data from my old Terastation unit), with a little bit of worry I wiped the unit and started from scratch.
Having the all clear from TZO that the certificate had now been issued by the supplier I was advised to reboot the NAS unit, I did that and all of a sudden my URL was coming back a being secured (yay). I now just needed to import the data from my Terastation again… 🙁
Jump forward 3 weeks, in those three weeks I have had countless emails from my NAS telling me that it was having issues with the TZO client not being able to confirm the external IP address for the unit, it as concerning as I had already port forwarded 443 via my router to the NAS box.
A little further investigation and some minor changes appear to have resolved my issues (I used to get emails 5 or 6 times a day, so far in the last 14 hours I haven’t received any so fingers crossed). The cause? Well to try and speed up my data transfer across my switched network I had enabled jumbo frames as well as bonded the two interfaces together (jumbo frames enabled on the switch and NAS), disabling both appears to have fixed the issues, at the moment I want to leave it for a couple of days before I start trouble shooting to see whether it was the bonded or jumbo frames that did it but my gut is going with jumbo frames.
So far all is well and good (I can tell you that jumbo frames improved the data sync by about 2 days).
The Iomega IX4 is a handy little unit that comes bundled with a whole load of loveliness, well actually it would do if the loveliness actually worked correctly.
Over the weekend I purchased a subscription from TZO to allow for remote access to my IX4 8TB unit. Included in that purchase was a 1 year SSL subsciption for the domain name My-HomeNas.com, unfortunately said SSL certificate has never downloaded to the NAS. I am now in the position where not only does the NAS throw up errors all the time but I also can’t actually re-enable Remote Access on it.
Everytime I try to enable Remote Access using the Paid Subscription (Already Own) settings the NAS will just sit there with a processing screen. A support desk entry over at TZO resulted in a reply and the ticket being closed (even tho the email asked me to reply to them when the NAS had been rebooted) and it left me with the task of wiping the NAS again to see if that allowed me to configure Remote Access again.
I am currently left with a NAS device that’s trying to rebuild the Disk Structure (clearing the config on the unit) but unfortunately that appears as if it’s going to take days to complete.
Overall I am not that impressed with the Iomega NAS line, so far I had my first unit turn up DOA, the second one wouldn’t let me upgrade the disks (I know, it’s not factory supported anyway) and now the 8tb unit won’t actually let me enable Remote Access successfully. The only time it did work over the weekend (with the certificate error) the device kept stalling when trying to remotely access a 50mb file (whereas using the same net connection on a WHS server allowed the file to be retrieved very quickly (I love my 50\5mb Up\Down speeds :D)).
