I'm following up on a thread from mid-June. You may recall that I asked
for assistance deciding between a couple of small NetApps and a Falcon
Systems FastFilePro 7000. I've include Andy Watson's response below for
context.
We made our decision to go with NetApp last week. Two key factors:
- NetApp is the market leader and has strong momentum. With NetApp, I'm
not concerned about owning an orphaned product, and I expect that the
product line will continue to develop rapidly. NetApp's large customer
base is a major asset because I feel comfortable that the toasters user
community will be a good source of information as well as a point of
leverage for ensuring that NetApp is responsive.
- NetApp's entry-level price is very low compared to that of the
FastFilePro 7000, and upgrades are easy and penalty-free.
Our plans have changed a bit -- we're buying an F210 now for a big customer
project and the two we originally wanted this fall.
Thanks very much everyone for sharing your thoughts with me.
-- Marc Rouleau
VP and Chief Technology Officer Voice: (812) 479-1700 Fax: (812) 479-3439
World Connection Services, LLC http://www.evansville.net
On Jun 13, 4:36pm, Andy Watson wrote:
> Marc --
>
> Given that no one else has offered you opinions (none that I've
> seen on this distribution list, anyway), I thought I ought to
> comment. I'll try not to exhibit too much of a NetApp vendor bias.
>
>> Apologies if this is off the charter -- let me know (gently, please!)
>> and I'll desist -- but I'm evaluating dedicated NFS servers and have
>> narrowed things down to Network Appliance (F220, qty 2) versus Falcon
>> Systems (FastfilePro 7000, qty 1). I must admit that I'm leaning
>> toward the 7000 due to its superior expandability and greater
>> administrative flexibility (multiple filesystems and RAID sets, ability
>> to run old drives via JBOD on the SCSI port). ...
>
> As I'm sure you are aware, NetApp has made design choices towards
> simplification. The goal is not to offer "administrative flexibility"
> but instead to provide a dedicated function appliance where admin
> is streamlined to a minimal set of tasks.
>
> For example, unlike a mundane file server that requires the
> administrator(s) to load balance among multiple file systems,
> and reallocate storage between them, a NetApp filer has a single
> file system that can be *software*-partitioned among subtrees
> such that space allocation can be managed on-the-fly by simply
> editing the tree quotas in /etc/quotas, and where no load-balancing
> whatsoever need be attempted. You can export the single file system
> as if it were multiple file systems by exporting subtrees with
> various permissions and options specified in the /etc/exports file.
>
>> ... Also, the 7000 tests
>> about even with the F540 in various magazine reviews, and NetApp's own
>> LADDIS testing shows the F220 to be only half as fast as the F540 (is
>> this true in the real world?).
>
> Well, in at least one magazine review I think it was UNIX REVIEW,
> as I recall) a benchmark called "bigdisk" was used, which showed
> Falcon's performance as comparable to a NetApp filer. Other than
> that I don't recall other reviews where Falcon matched NetApp.
> Anyway, in that article, bigdisk exercised the Falcon using NFSv2
> over UDP, because at that time Falcon's software did not support
> NFSv3 nor NFS over TCP. NetApp was tested with NFSv3 over TCP.
> Running NFS over TCP is known to hurt performance compared to UDP,
> but TCP is provided because it is better for WANs and other "lossy"
> networks where packet loss can cause heavy retrans overhead.
> Anyway, we ran bigdisk internally, using NFSv2 over UDP, and
> our performance was significantly better than what that magazine
> reported for Falcon.
>
> On the broader topic of benchmarking, the industry-standard
> benchmark of NFS file server performance is SFS (also known as
> "LADDIS") from SPEC. SPEC has a peer review process whereby
> official results are submitted, and if accepted by SPEC, can
> be published in the SPEC Newsletter and on the SPEC website --
> (see http://www.specbench.org/osg/sfs93/results/results.html).
> You will find Falcon and NetApp SFS benchmark results at that
> site (and in the hardcopy Newsletter, if you have access to it).
> NetApp has also published SFS results which have been accepted
> by SPEC, but which have been inexplicably delayed in appearing
> on the SPEC website. SPEC assures me that they will appear
> very soon, probably by early next week. In the meanwhile, you
> can see our latest results for our F210, F230, F520, and F630
> filers at http://www.netapp.com/technology/performance.html.
>
> Falcon has published four results via SPEC, but none of them
> are annotated as being for a model "7000", so I'm not sure
> what that machine's SFS benchmark results might be. Also,
> in 3 out of those 4 tested configurations, Falcon used a
> SSD (SolidState Disk) to significantly accelerate their
> performance. If the proposed Falcon configuration you are
> considering does not include that SSD, then you should ask
> to have that added if you want to optimize that system's
> performance. On the 4th Falcon configuration for which they
> have published SFS results, instead of SSD, they combined
> a BBU (Battery Backup Unit) with a Mylex disk controller's
> RAM cache to accelerate Write performance. If you are
> considering that approach, instead of using SSD, be sure not
> to omit the BBU, because otherwise pending Writes (asynchronously
> acknowledged to the clients) could be lost in the event of
> a power interruption. (NetApp uses battery-backed NVRAM
> ((Non-Volatile RAM)) to capture and preserve updates to the
> file system, evenin the event of an interruption in power.
>
> The SPEC results will show you that our filers outperform Falcon's
> servers in terms of average response time. This means we provide
> faster replies to clients. Also, Falcon has only published results
> for one configuration where parity RAID protection was enabled.
> That happens to be for a model 9000 system with 62 disks, with
> three RAM-caching Mylex controllers, and an SSD. Even so, two
> F220s together will present more total ops/s (1213 ops/s each,
> or 2426 together) than the large-config Falcon 9000 (2392 ops/s).
> Each F220 needed only 14 disks to achieve this performance,
> so even two of them together were exercising less than half the
> spindles than the high-end Falcon. And with our latest software
> release, and the newer F230 filer, the performance has improved
> both in terms of faster response time (4.5ms for 1221 ops/s,
> compared to the F220's 9.4 ms for 1231 ops/s) and greater max
> throughput (1610 ops/s).
>
> But this is benchmarking numerology, to some extent. You are
> wise to ask about realworld performance. We have consistently
> found that NetApp filers deliver better performance for actual
> application environments than indicated by the SFS benchmark
> because the benchmark has a "worst-case" workload, compared
> to most application requirements. Also, unlike other vendors
> (including Falcon) where the SFS benchmark load is *perfectly*
> load-balanced across many file systems, NetApp is benchmarking
> with a single file system. Realworld applications depend on
> the performance of the individual file system where the target
> data resides. It is rare to find an individual application that
> is actively exercising data stored in multiple file systems.
>
> I've written a paper which goes into greater detail on this
> topic: "Interpreting SPEC SFS ('LADDIS') Benchmark Results"
> (http://www.netapp.com/technology/level3/3010.html). It doesn't
> specifically mention Falcon, but I think you will find it useful
> in the analysis of your requirements and the comparison of NetApp
> filer performance versus benchmark results for multiple-file system
> configurations such as Falcon's.
>
>> On the other hand, NetApp tells me that the highly random nature of my
>> traffic -- typical ISP work including email, USENET news, and webservers --
>> should point me toward multiple servers to maximize main memory cache hits.
>> They say that the main memory cache on the 7000 will become worthless as I
>> expand storage and that performance will drop off. I don't have a good
>> feel for the importance of main memory cache here -- the 7000 uses hardware
>> RAID controllers with onboard cache, so it seems like it would be less
>> important to the Falcon product than it is to the NetApp line. But I must
>> admit that NetApp's larger installed base -- 1000's versus 100's of
>> systems -- makes it a safer choice on the surface.
>
> On the above topic, you should check out Karl Swartz's paper:
> "The Brave Little Toaster Meets Usenet" (a USENIX LISA paper --
> see http://www.netapp.com/technology/level3/brave.html).
>
> In general, for large data sets and the highly randomized loads seen
> by growing ISPs, it is futile to try to solve your I/O problems with
> larger caches. Let's say you have 20 GB of data that is being accessed
> by a large population of diverse users, such that there is relatively
> little likelihood of data re-use from the cache. If even only 25% of
> that 20-GB is exercised, then you would need 4 GB RAM, and you'd
> merely fill it with data retrieved only to never need it again,
> as the next 4-GB of different data flows through the cache over the
> next equivalent time interval.
>
> So what you really need to focus on is disk subsystem performance.
> And that's where we excel. Note that we have published all our
> benchmark results with relatively small disk complements, giving
> us the best per-disk (and per-file-system) performance results
> in the industry.
>
> >Anyone care to share his/her thoughts on this topic?
>
> Well, I hope this helped. I tried to provide as much relevant
> information as I could, with references, and to avoid spouting
> unsubstantiated opinions.
>
> Good luck in your exploration of alternatives!
>
> -- Andy
>
> Andy Watson
> Director, Technical Marketing watson@netapp.com
> Network Appliance +1 408 367 3220 voice
> 2770 San Tomas Expressway +1 408 367 3151 fax
> Santa Clara, CA 95051 <http://www.netapp.com/>
>
> "It's really stupid to be an intellectual when you're young.
> You should be an intellectual when you're a hundred years old
> and can't feel anything anymore."
> -- a character in Bruce Sterling's novel, HOLY FIRE
>
>
>
>
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 10:19:20 EST