NAS comparison: iomega and netgear

As you will know, I’ve had no end of problems with iomega NAS boxes (and customer support for that matter), and so with a recent purchase decided to test the market again and purchase a different product.

Back in the day we had some Netgear ReadyNas boxes, little desktop units offering 2-3TB of network storage which was ideal for backups. The ReadyNas boxes weren’t special in any way, the interface was decidedly average and the software had a few quirks, but they did have one brilliant feature – they hardly ever stopped working.

So, I decided to give them a go again and have since done a direct comparison between the previously-complained-about iomega units and the newly-purchased netgear ones. There are a couple of differences you should know before you worry about the performance though: 1) the netgears are considerably more expensive; 2) the netgears come with a much better warranty.
Continue Reading →

Quick: Why not to buy the iomega ix12-300r either!

In a previous blog post I explained that our iomega ix4-200r was a generally faulty product with little or no hope of ever making it into my good books, mainly because of the (deliberate) limitations on iSCSI LUN sizes.

After feeding this information back to the suppliers who recommended the product they gave a response which was something like “oh, yes, well, those are the small units, they’re not too good, try the larger unit instead: the ix12″.

And so we did, we bought a few ix12-300r units and configured them up appropriately, the good news is they don’t have a restriction on iSCSI LUNs that I’m bothered about – it might be set at 16TB but I’m okay with that. The bad news is, the product itself is just as unreliable and realistically can’t be used for anything sensible. We had a fault initially logged on the 13th October and as I write this on the 5th December it’s still not resolved fully.
Continue Reading →

Installation of Dell EqualLogic MEM 1.0.9 (1.1 EPA) and vSphere 5

So the 1.0.9 version of Dell’s MEM module (ug, that’s as bad as PIN number), scratch that, of Dell’s Multipathing Extension Module for EqualLogic was released last week. I promptly ignored it for a week before reading the line that said “fully supported in production environments” (whoops) and installed it today. It wasn’t easy.

I’ve already upgraded vSphere Centre to version 5, and so I made an install package for MEM 1.0.9 (1.1EPA) – Update Manager then told me that it wasn’t required anywhere, “that can’t be right”, I thought to myself, and then realised that I needed ESXi 5.0 to install MEM; but you can’t install ESXi 5.0 while MEM1.0 (or anything pre 1.0.9) is installed. A little bit of a catch 22.

I then embarked on a whirlwind tour of command line chaos, using PowerShell to create my own installation .iso which combined the ESXi 5.0 install with the Dell MEM bundle, I uploaded that to the Update Manager and used it to upgrade two hosts, and I’m shocked to say that it worked almost perfectly, so, for the simple commands you need to use, see below!

To do all this you’ll need to download and install the vSphere PowerCLI.
Continue Reading →

Quick: Why not to buy the iomega ix4-200r for veeam backups

In previous blog posts (Using veeam to backup the new virtual infrastructure to Iomega NAS boxes and Backup Strategies with Virtual Machines in VMware using Veeam) I mention my purchases of the iomega ix4-200r, generally I haven’t been impressed with them because they’ve been a little unreliable.

Looking at use around the net I decided that the best way to have a target for my veeam backups would be the iSCSI initiator from Windows straight onto the device, so I should provision a LUN, add it to Windows and write to it.

I tried and failed, after about a week of to’ing and fro’ing with veeam, vmware and iomega support I got to the bottom of the issue: these nas boxes are software locked to provide LUNs that are <= 2TB in size* – bearing in mind my 8 file servers each serve up anywhere between 500GB and 1TB worth of data this means that my first backup file from veeam is always going be over 2TB, making the device pretty much worthless in my environment.

*I’ve been assured that a LUN that’s exactly 2TB will work, although I can’t actually get that working in my test lab having tried it on two separate devices.

snapshot February 2011

To advertise the success of the IT Service Desk in the last year we have producted a newsletter for internal circulation, it’s a high level overview of all of projects that we’ve successfully completed and I’ve been the owner and runner of almost all of them!

Click the thumbnails below for the two-page .pdf (~700kb).

Page 1 imagePage 2 screenshot

Using the Dell EQL MEM Module to simplify my backups (also, thanks again, veeam!)

Many posts cover the installation and performance benefits that come from using the Dell Multipathing Extension Module (MEM) on EqualLogic arrays (check the spoonapedia.com one), but the big difference for me was a bit of a pleasant side-effect in terms of handling backups! I’ve covered off this strategy from a high level in my previous blog post, Backup Strategies with Virtual Machines in VMware using Veeam, but I wanted to explain in a little bit of detail how I actually got there: it was down to the MEM!

Before – accessing data from within the OS

Because the file servers I’ve been working on access a lot of data (8TB worth), the original setup involved using the EqualLogic Host Integration Tools (HIT kit) from within the file server OS to access LUNs on the EQL array – this provided valuable multipath access and proved to be a very successful way of handling access to the data. The problem was that is complicated backups quite significantly, I could use veeam to backup the OSs (and I did), but I had no way of backing up the actual file data.

With various bad experiences from using market-leading backup software such as BackupExec in the past I wasn’t in a rush to go out and spend money on a software solution to handle all this file data, so I resorted to a very low-tech solution: I bought a nas box and did a nightly robocopy.

This was simple, but it was awful: the backups didn’t finish in time (they’re being taken over a 100mbit LES), they never caught up with themselves. It was a waste of time and it basically meant no backups were worth having.

After – install the MEM and let ESXi deal with it

But then the MEM came out, and essentially claimed to offer the same (if not better) performance via ESXi – no messing around with the HIT kit any more, and more importantly, a chance to re-evaluate my first decision about not using .vmdks… I changed my mind.

The first time round I did thick LUN straight into Windows, formatted as NTFS, simple. This time I re-evaluated and did a thick LUN on the EQL and then allocated thin disks in ESXi and mounted them to the file servers… This gives me greater flexibility if a disk gets close to its limits but it also now means that the extra .vmdks are picked up by veeam allowing me to replicate my previously successful backup strategy.

In summary…

Veeam now handles the file data as incremental .vmdks which means it only transfers the changes in the .vmdk files – the entire series of backups finishes over the 100mb LES in about 12 hours (which, bearing in mind I run it once a week at the weekend is ideal); the previous robocopy never finished in that amount of time: the size of the data transferred is obviously the same, but because robocopy iterated through every single file and folder for a comparison it took much longer whereas now veeam just… does it, and it was a product that I already had so didn’t require any extra spend (not to mention the money that could now be saved on not upgrading the LES to 1GB purely for the purposes of backup).

Next?

Now being quite satisfied with this setup I’m going to investigate the series of advice from ErikZandboer on optimising his ix2-200 backup speeds, specifically the post that looks at jumbo frames to target storage.

Backup Strategies with Virtual Machines in VMware using Veeam

A recent tweet from @win2ksrv and then retweeted by @veeam reminded me that I was going to write about the most recent backup strategy that I’d put in place using Dell EqualLogic SANs, VMware and of course, veeam, it went like this:

What is everyone’s Veeam backup strategy? What do you backup to & how do you get it offsite? Where do you place Veeam itself?

The basic setup looks like this:

The Production site has a Dell EqualLogic array and a local NAS box (that’s the black thing), the backup site which is connected via a 25mbps internet-based VPN simply has a larger NAS box (it deals with multiple sites). VMware has been used to create all the file server disks (they are .vmdks) and veeam is installed in another virtual machine using appliance mode to access the SAN.

There are essentially two main risks that we want to mitigate against here:

  1. Accidental deletion / corruption of files
  2. Complete site wipeout (i.e. full blown disaster)

Continue Reading →

New office success!

A fairly unique opportunity arose for me towards the end of 2010: I was able to design, purchase components for, and then oversee the implementation of a new office infrastructure. This was due to a new physical build, and based on the success of the previous SAN and Infrastrucure project, I was essentially given full control over all aspects of the IT infrastructure.

It was an extensive piece of work and covered about six months of my life before finally going live at the end of November 2010, it involved visits to the site before building works were completed; setup of an entire dedicated test lab; and various correspondances thrasing out the business requirements for the new build.

The actual move-and-go-live happened over a weekend, the staff downed tools on Friday, had their PCs moved over the weekend and were able to log on and start work again Monday morning, a huge achievement bearing in mind that the entire system had changed: everything from the cables to the printers to the back end storage was now completely different.
Continue Reading →

Using Network Access Quarantine for VPN Clients

The Scenario

Migrating machines from physical installations to virtual installations can be a chore, but it can also give you an opportunity to roll out new features and test new setups.

Having previously used a Microsoft Server 2003 installation to provide a free-of-charge and easy-to-maintain VPN system for employees I wanted to tighten up the security and be more specific about which users were able to connect to the VPN and what access they were allowed.

Two levels of access had already been decided upon, although not implemented in the current build of the VPN server (using Routing and Remote Access in 2003) and these were:

  1. Provide unlimited network access for company staff on company equipment
  2. Provide limited access for company staff using their personal home equipment

The intention here is that anyone with permission would be able to use any computer on the internet to connect in and perform certain functions, but to be able to browse all the data drives and have unlimited network access you would need to use a company laptop which in turn would be considerably more likely to have antivirus software on it and be up-to-date.

The upgrade

The upgrade to Server 2008 R2 gave an ideal time to test and implement the specific features that were required: two servers were being used side-by-side, the current 2003 box sat on an old 2mbps line and served all the current clients; the new 2008R2 box was on the new 25mbps line and was only serving the test clients until testing had been completed.

Despite the existence of the Microsft Server Migration tool I was unable to successfully migrate the settings from 2003 to 2008 and so had to manual re-create the VPN server in RRAS and create two policies which mirrored the above settings.

The settings
Continue Reading →

A template for new offices

Now that the first and largest implemtation is almost complete, I have to start thinking about producing an easy-to-understand template that allows us to build site offices in a practically identical manner. One of the main goals of this project was to be able to have a repeatable template of systems and processes that allowed us almost dump a pre-fabricated solution into a physical building, this sort of template would be tried and tested and be the first step to producing a business service of “deploy new office” – a service which until now has been very ad-hoc and piecemeal.

From a very high level there a few things you need to deploy IT systems into a new building:

  • Connectivity (Telephony and Data)
  • Hardware (Servers, Cabling, Computers)
  • Software (Client OSs, Server OSs, Applications)

Our template includes a base for things already which has come as a direct result of building up the first office: We know that a new site wants Dell EqualLogic storage so that it can use the inbuilt replication between sites (for backup etc); two servers for redundancy; an uninterruptable power supply and environmental monitoring. We know that the site needs at least 10mb of internet connectivity, but keeping in line with recent work this will actually start at 25mb, and we know that there is a need for phone lines (for staff to make calls, as well as for alarms etc). In terms of software, the Client OSs are all still going to be Windows XP, (but with a view to upgrade to 7 later on throughout) and the server OSs are going to be Windows Server 2008 R2 – the datacentre licensing here becomes a bit of a no-brainer, which I’ll explain in a follow up post.

So that’s it, that’s the start of our template for a new site office! I’ll explore the three high-level requirements in more detail in future posts.