HP EX487 MediaSmart Server

[thecave]

This article mentions the option of backing up the server to Amazon's S3, but doesn't discuss options for backing up to an external drive or a networked drive. I know that WHS now supports backing up the server, but am having trouble finding out how this is accomplished.

I assume that the server includes software that will automatically back up to an external disk. Can anyone comment on what the sofware is and how well it works?

 

[corndog]

According to the article, the HP will back up to a USB disk but only when you ask it - not automated. And it will also NOT back up to a local network location.

I have a solution for mine. I have an old ReadyNAS 1100 from yesteryear still running on my LAN. I call it "Old Faithful". It's very very slow compared to all this new stuff but Netgear built a LOT of backup options into it.

What I do is this - create a "backup user" on the MSS - mine is called "bkup". Give this user read-only access to all shares. Then configure a backup job on the ReadyNAS for each share on the MSS. Set the ReadyNAS to "pull" from the MSS using Windows/NAS (Timestamp) setting. Schedule the job, and I'm all set. Once a day, the ReadyNAS connects to the MSS and copies only the files that have changed. It's an rsync-like kludge but it works wonders.

ReadyNAS doesn't get enough props for their myriad backup methods. QNAP and Thecus don't even come close, and let's not even get started on WHS. I'm basically covering up for WHS' backup inadequacy with my ReadyNAS.

 

[beq]

After reading the SmallNetBuilder review, I wonder how WHS can offer such great cached write (and to some extent read) performance for smaller mainstream file sizes -- compared to Linux NASes? And how pronounced this effect is in day-to-day usage in the real world? On the other hand, I don't like the steep fall-off in read (and to some extent write) performance past the 1-2GB file size. I'm also not sure how I feel about relying on the OS-level "Folder Duplication" functionality of WHS vs low-level RAID redundancy. Personally I would always want to make all of my data redundant anyways...

I do like the Amazon S3 cloud storage support via add-in though, and I wish other NASes have this. I read that the ReadyNAS NVX is coming with a ReadyNAS Vault online storage subscription, but the description makes it sound like a local program that you install on a client PC instead of native support on the NAS. I remember that Jungle Disk had announced plans to make a version for the various Linux NASes (they already have a version for WHS), hopefully sooner rather than later. Perhaps in the NAS market Jungle Disk could become the solution for Amazon S3/Rackspace Mosso Cloud Files what TwonkyMedia is for multimedia streaming...

In any case, I agree that the HP EX487 is impressively cheap at under $600 on the street with 1.5TB disk space.

 

[corndog]

Beq,

I share that question also. According to the charts, the new HP WHS is hitting 340MB/sec average write, which is basically about 3 times the maximum throughput of gigabit ethernet! There is no way that this can be simply attributed to the NAS's cache, because it still has to get FROM the test machine TO the NAS through a 1gigabit network connection, before it can even load into the cache. So there's something else going on. I've read that WHS and Vista both use an enhanced "version 2" flavour of the CIFS filesystem that is not yet built into the versions of samba that are used on Linux-based NASes.

So if we assume it is this newer cifs version that is providing the jump in performance, we still have to figure out why the throughput is nearly 3 times the absolute limit of the network media.

The first thing that comes to mind is compression. I remember the old bonnie++ filesystem benchmark on Linux taking a MAJOR beating from critics because all of the test files were filled with reams and reams of zeroes. Of course, any smart network file protocol that used compression would artificially inflate its benchmark because it could massively compress those zeroes for transport across the network.

If Tim's iozone tests use all zeroes in their test files (Tim, can you comment on this at all?) then I think we might be onto a compression artefact that is unfavourably biasing the tests toward WHS. But from my perspective this is just conjecture at the moment.

Comments all?

 

[thiggins]

Caching can happen on both ends of the connection. When you see performance above what the network connection supports, that is from OS cache on the iozone machine.

The answer could lie in the fact that there are Windows OSes involved on both ends of the connection. But iozone does not use any of the Windows enhanced-performance system calls. I suspect it is more the use of larger transfer sizes as discussed in How To Build a Really Fast NAS - Part 6: The Vista (SP1) Difference. This could be easily confirmed with a Process Monitor trace.

I checked an iozone .tmp file. It is not all, but it is mostly zeros.

This is one reason why I'm glad that I added file copy tests. If you look at those results, you might ask what tricks the ReadyNAS Pro is using to goose to up near 100 MB/s!

 

[corndog]

Hi Tim,

That's very interesting, and it raises even more questions. From that it would be a reasonable deduction that Microsoft has somehow configured Vista SP1 to very aggressively cache on the client side, ONLY when contacting a Windows Server. The other way of saying this is that Microsoft has intentionally hobbled performance when contacting a non-Windows Server. That raises the stench of nastiness from Microsoft which really wouldn't surprise me...

If we can rule out compression by insisting the test files must contain strings of random numbers, and use test files that are so collossally massive that all caches on client and server are completely overwhelmed, the best we should ever be able to hit is 125MB/sec, correct?

And that's assuming our network protocol is almost 100% efficient - no loss for acknowledgements and error correction. So most likely it might be more realistic to expect 110MB/sec or something like that due to necessary protocol inefficiency.

And then because ethernet is a Collision-based architecture, even with the increase in collision-avoidance provided by switching, it might be reasonable to expect to do no better than 100MB/sec.

... which would mean the Netgear Pro is unbeatable unless we go to 10Gig ethernet?

I'm probably missing something....

 

[thiggins]

Don't get too far into M$ conspiracy theories there, corndog! We already know that there are Microsoft system calls that can be used to enhance file copy performance. If that is what's in play, then it's just an advantage to be gained from using an all Microsoft solution vs. "intentionally" crippling performance when not using an MS to MS transfer.

Non-cached performance is going to be limited by the max speed of the network connection. Taking overhead into account, I'm using a rule of thumb of 100 MB/s as the max for a gigabit Ethernet connection.

As for the ReadyNAS Pro being unbeatable.... remember that it also gets its high average number in the charts partly from cached performance. So if it can do it, so can others.

 

[corndog]

Point taken

It's also quite convenient to expect 100MB/sec because it's basically taking your bit rate and dividing by 10 for byte rate, which is nice and easy.

I'm waiting with baited breath for the samba team to incorporate the cifs v2 changes in samba. Nicely, the EU convinced Microsoft to release the specs for this protocol to the community, so the samba team can be on a better footing with this new version than they are on their existing platform which is based on reverse engineering.

When it comes out in a stable version of Samba, it will be very interesting to see the effect on our Small Business NAS industry. If the performance of WHS is any indication, we might see a very large performance jump from the first vendors that embrace the new samba version.

Whoohoo!

 

[ymboc]

This is one reason why I'm glad that I added file copy tests. If you look at those results, you might ask what tricks the ReadyNAS Pro is using to goose to up near 100 MB/s!

Have you considered using iozone's '-c' switch to help reduce the effect of client-side caching on the write performance results?

I do realize it was intended for use with NFSv3 but it does appear to be working as intended on the win32 platform.

If you've fiddled with this already can you comment on how well (or poorly) iozone '-c' read & write performance results compare with your file copy results?

The EX487's write performance scores sure are impressive but when they're more than twice as high as what the transmission media can theoretically support, do the results still reflect reality?

 

[thiggins]

Our iozone testing has always included cache effects for both the NAS and client OS. See Why Cache Matters in NAS Performance.

We added the Vista SP1 file copy benchmarks to provide more "real world" performance information.

 

[00Roush]

I tend to think the high write results have more to do with how Iozone and Windows interact. Looking at some Process Monitor traces leads me to think that Iozone is sending all of data to the OS and letting the OS worry about sending the data across the network. The problem with this is that Iozone is only measuring how long it takes to send the data to the system and not how long it actually takes to send it across the network. So the results actually are showing how fast the OS can deal with a given amount of data. This could be considered cached performance but I don't think this is really what it would be. It think it would represent how fast the computer can create a file in memory and pass it off to the OS.

Now with larger file sizes I think the OS is limiting how much data is allowed to be waiting to be written to the network. So Iozone writes to the OS until the preset limit is reached. Then the OS has to get rid of some of the pending data by writing it to the network. This allows Iozone to write a little bit more data to the OS. This happens goes on until Iozone is done writing its data to the OS. After that Iozone records how long it took and waits for the file to close. Once the file is closed the calculated write speed is shown to the user.

I believe the reason this HP unit saw such high write speeds is due to using Windows on the server. One difference I have noticed between using Linux and Windows on my server is how writes are handled. When writing to a windows server I find that the as much of the data as possible will be cached (buffered) into its memory then written to disk whenever possible. A Linux setup usually will cache (buffer) some of the file but start writing to the disk right away. Also Linux seems to throttle the file transfer to keep memory usage under control. The difference here is that Windows can allow for a fast file transfer even if the data cannot be written to the disk that fast. Linux will throttle the connection to match how fast the data can actually be written to disk. I don't think all Linux versions do this but the few I have tested seemed to.

I went ahead and tested out Iozone with the -c per ymboc suggestion and it seems to give results that are closer to reality. This makes sense as this option makes Iozone wait for the file to be closed before recording how long it took.

Not sure how much of this made sense but oh well. All of this is of course just my opinion and based on my understanding of how all this stuff works.

00Roush

 

[thiggins]

I understand the point that both you and ymboc are making. But cache effects from OS and NAS are all part of performance, as is the network file system used (SMB/CIFS).

The NAS Charts results have always included cache effects. They were just not as noticeable because of the 512MB used in the iozone machine, smaller RAM sizes in NASes and, to some extent, using XP instead of Vista.

When I made the change to the new, faster test platform, I could have stayed with 512 MB and XP. But no computer today comes with that little memory and Vista is what is shipping with new machines. So I raised memory and changed OSes to keep current.

I have always said that the NAS Charts are not "truth". They can't be since they represent only a tiny subset of usage scenarios. But they can be used to make relative comparisons among products because they use as consistent and controlled a test methodology as I can perform.

You may notice that I have changed the default NAS Chart view to 1000 Mbps Read from 100 Mbps Write. I made this change to provide a "fairer" view of relative performance for readers unfamiliar with the charts and the methodology behind them.

 

[00Roush]

When I made the change to the new, faster test platform, I could have stayed with 512 MB and XP. But no computer today comes with that little memory and Vista is what is shipping with new machines. So I raised memory and changed OSes to keep current.

I have always said that the NAS Charts are not "truth". They can't be since they represent only a tiny subset of usage scenarios. But they can be used to make relative comparisons among products because they use as consistent and controlled a test methodology as I can perform.

You may notice that I have changed the default NAS Chart view to 1000 Mbps Read from 100 Mbps Write. I made this change to provide a "fairer" view of relative performance for readers unfamiliar with the charts and the methodology behind them.

I think you are doing a great job!!

Your update to your test bed was timed very well. As you pointed out it is much more in line with current systems.

While the NAS charts might not have a bunch of different usage scenarios they provide good insight into file transfer performance that a particular NAS is capable of. Since serving files will most likely be the primary function of any NAS, the charts and associated reviews provide a great way to compare products.

00Roush

 

[00Roush]

I understand the point that both you and ymboc are making. But cache effects from OS and NAS are all part of performance, as is the network file system used (SMB/CIFS).

I do agree that cache does affect NAS performance but only if the file(s) being transferred are in memory. Even when cache is in effect, network transfer speeds are limited to a maximum of 125 MB/sec on gigabit ethernet. So seeing write results that are higher than 125 MB/sec makes me wonder what is really being measured as it is not possible to transfer files over a gigabit connection faster than 125 MB/sec. Just wanted to clarify my thought process.

I do want to point out that to my knowledge Windows uses cache different with network file systems than local file systems. For example client side cache is not enabled by default for network file systems. Basically this means that if a file is located on the server it always is read from the server and not the local cache. An example would be if I open a picture located on my server it will will be read from the server. Then I close the picture and open it again. It will again be read from the server even though the file is in the local cache.

00Roush

 

[thiggins]

I do want to point out that to my knowledge Windows uses cache different with network file systems than local file systems. For example client side cache is not enabled by default for network file systems. Basically this means that if a file is located on the server it always is read from the server and not the local cache. An example would be if I open a picture located on my server it will will be read from the server. Then I close the picture and open it again. It will again be read from the server even though the file is in the local cache.

That behavior could have changed in Vista SP1. I think I recall something in Mark Russinovich's blog that said that an app could do either (read from cache or from remote share). But I could be wrong.

If I could figure out a way to use the iozone -c switch without totally confusing readers and essentially restarting the NAS charts from scratch, I might. But I can't.

 

[eaadams]

Quickbooks and Filemaker

I have asked on the Home Server forums and I have asked on Intuit and on the Filemaker forums but Home Server people say ask intuit/filemaker and intuit/filemaker give boiler plate Windows Server 2003 responce.

Question:
Can this Windows Home Server box serve up Quickbooks and Filemaker on the internet? Or must I buy a cheap Win Server 2003 box?

 

[corndog]

Hey there,

One thing you might want to keep in mind - the most annoying thing about WHS is that it seems to be intentionally locked down to only serve files to machines on it's own subnet. I have 3 network segments at home. One for my wife and I (our IT business), one for our wireless Networks (firewalled from the other ones) and a third for our kids (protects us from all the crap they download). Any of the other NASes I've tested (Netgear, QNAP, Synology, Thecus, etc) will serve files to any segment, as long as I allow it through my firewall (and remote-connected VPN segments too, for that matter).

But the WHS box - even though I can ping it from those remote segments - will only serve files to machines on it's local LAN. In my case, it's my kids' subnet.

So, to answer your question - will WHS serve up Quickbooks and Filemaker over the internet? If you're expecting to "map a drive letter" to your WHS server from a remote location and just run Quickbooks, expecting to access the data files on your WHS server, the answer is NO. Remotely, you can open a web-connection to WHS and get at your files with a web interface for downloading and uploading to and from the NAS, but it will not allow you to map drives, which I expect is something you're looking for, especially since you mention quickbooks.

Hope that helps.

 

[eaadams]

Bummer.

As far as I can tell Quickbooks will not work over a VPN so I have to figure out something that virtualizes (I don't know if that is the right word) to the internet the screen from a server. i.e. a setup that allowes me to remote desktop, PC anywhere, citrix etc... into the home server, and if home server can't do it then the Windows Small Buisness Server.

Is to virtualize the right word?