I would probably go with a multi-x86 box (low cost) running Linux (kernel 2.2), SAMBA, hardware RAID, etc.
I have seen some very good comparative SMB numbers on these boxes. And now that the processor archetecture is scalable with Linux's kernel, the sky's the limit and the cost is VERY low!
Tom Weeks
-----Original Message----- From: askaquestion@iname.com [mailto:askaquestion@iname.com] Sent: Saturday, March 06, 1999 4:36 PM To: toasters@mathworks.com Subject: NetApp/Auspex killer?
Yes, NetApps are fine boxes but...
If you started a company to build a NAS box, what would you build that would be better than what NetApp, Auspex, etc. has?
I'm looking for serious responses here - to improve the market with competition!
I don't view the kind of very-low $ suggestions on this list recently as the kind of thing that most of us are interested in.
Don't let my anonymous query lead you into thinking that I'm not 100% serious. If anything it should illustrate just how serious I am.
--------------------------------------------------- Get free personalized email at http://www.iname.com
1999-03-15-21:47:33 Weeks, Thomas:
I would probably go with a multi-x86 box (low cost) running Linux (kernel 2.2), SAMBA, hardware RAID, etc.
I'd probably do something similar, but not quite identical. I wouldn't mess with multi-cpu, at least not intially (though Linux supports it) until and unless I got convinced that I couldn't tune the code to saturate a 100Mbps with a nice fast single cpu. I'd make sure my solution supported the Znyx quad-100BaseT Tulip cards. And then the thing I'd add to the picture, my special niche product, would be a nice setup for battery-backed SDRAM; I'd probably at least start off making it PCI, and would go with the PC100 interface ==> cheap fast chips. Allow multiple boards. Rig 'em with say a few minutes of battery run-time on-board, and an external connector for a deep-cycle marine battery or some such to ride out weeks or months of power outage. Publish the Linux drivers, so that you can get a lot more people contributing debugging and performance tuning help.
Go with say 512MB battery-backed SDRAM at the low end, scalable up to a few gigs, teach the filesystem drivers to work well with it as write cache, configure plenty of regular ram and let the OS have it for read cache.
I'd really hope you could pretty easily saturate 100BaseT with that sort o' lashup, and be well-positioned to deliver rocking performance through etherchannel and maybe even gigabit ether, though there you might in fact need more muscle.
-Bennett
On Mon, Mar 15, 1999 at 11:46:29PM +0000, Bennett Todd wrote:
1999-03-15-21:47:33 Weeks, Thomas:
I would probably go with a multi-x86 box (low cost) running Linux (kernel 2.2), SAMBA, hardware RAID, etc.
Note that Cobalt just started shipping their NAS product, a slim line rack mountable unit supporting 10 or 16 gigs of RAID-1 or 20 or 32 gigs of RAID-0. It takes 1U of rack space, and is very easy to manage.
But it certainly isn't a NetApp.
On Mon, 15 Mar 1999, Dane Jasper wrote:
Note that Cobalt just started shipping their NAS product
Ahh Cobalt, didn't someone here mention building a Linux based file server just yesterday?
But it certainly isn't a NetApp.
Yeah, but it is much much cheaper. If they market themselves well, they should capture the lower and mid-price niches. ISPs may certainly go for xit.
Tom
On Mon, 15 Mar 1999, Bennett Todd wrote:
I'd probably do something similar, but not quite identical. I wouldn't mess with multi-cpu, at least not intially (though Linux supports it) until and unless I got convinced that I couldn't tune the code to saturate a 100Mbps with a nice fast single cpu.
Cynicism aside, I's still want to run a microkernel rather than Linux on my box. The whole idea between NetApp is that it is a limited, but fairly highly optimized (although surprisingly unstable at times) box. If you do what you described below you're just creating another Auspex. Auspex have their place too though, they're easily customizable and can tun SunOS services which can be very usefull for home directory servers.
I'd really hope you could pretty easily saturate 100BaseT with that sort o' lashup, and be well-positioned to deliver rocking performance through etherchannel and maybe even gigabit ether, though there you might in fact need more muscle.
Speaking of EtherChannel or more generically Link Aggregation. Does anyone know a link describing it in quite a detail without going through a complete protocol suite definition.
Tom
1999-03-16-02:01:42 Tom:
Speaking of EtherChannel or more generically Link Aggregation. Does anyone know a link describing it in quite a detail without going through a complete protocol suite definition.
Don't know of a link, would love to see one. But as I understand it, the general strategy is that very roughly each side separately runs simple algorithms to attempt to schmeer traffic over the multiple links. Often the algorithm is based on the MAC addrs of the two endpoints, and so won't yield over 100Mbps for any single link, but will hopefully (3 times out of 4) place competing high-volume connections on separate links.
There are then hacks for failing over to another line when one link drops, and other border-condition exotica.
But the basic idea is that given a large number of communication endpoints, you can schmear the traffic over multiple links quite cheaply.
Dunno if this is any help to you.
-Bennett
On Tue, 16 Mar 1999, Bennett Todd wrote:
Don't know of a link, would love to see one. But as I understand it, the general strategy is that very roughly each side separately runs simple algorithms to attempt to schmeer traffic over the multiple links.
Yes, I know that much as well. There are several schemes to balance the traffic.
The most popular is MAC hashing when the system uses n last bits to determine which port to use for traffic. The downside is that one interface can still send to at most one interface in the agregate (trunk). The way that Sun describes it in it's literature is a bit confusing "Uses the last two bits of the MAC address of both the source and destination. For four ports the source and destination addresses are XORed: Result = 00, 01, 10, 11, which selects the port." In reality the destination address (the address of the trunk, not to be confused with the destination port which could be very different I guess) usually ends with 00 for the four port scenario, so effectively you AND the source address with 11 and get, voila, the last two bits. Also usually the address of the trunk is the address of the "head" interface and the subsequent interfaces in the trunk are sequentially numbered so the two bit port sequence numbers derived above map directly into the last two bits of the port addresses. Of course this method breaks down when one of the ports dies. Sun doesn't mention the scheme they use to take over for a dead port or ports. NetApps link aggregation (EtherChannel, trunking, bonding, etc.) is implemented in a similar way as I can tell from the docs I read.
Sun also implements a better and simpler scheme. It's called round robin. Why is it better? I rotates usage of the interfaces, i.e. nth packet to the (n mod (number of interfaces))th interface. KISS right. Well, there are some downsides, some stacks don't handle packets out of sequence very well, but that's a good possibility on non-guaranteed delivery networks anyway. The benefit, one interface can send to all available interfaces in the agregate (trunk). Thus even if you have only two trunked hosts you'll 100% potential utilization of the trunk in contrast to 25%. I WOULD LOVE TO SEE NETAPP IMPLEMENT THIS. I already mentioned it to them. I hope the standard that's being developed includes this scheme. COME ON NETAPP, THIS IS "KISS!"
At any rate, I was looking for some documentation on how the switch and the trunked host negotiate the connection. I looked into the standard, but it's incomplete and a bit too much to quickly digest.
Tom
On Wed, 17 Mar 1999 tkaczma@gryf.net wrote:
Also usually the address of the trunk is the address of the "head" interface and the subsequent interfaces in the trunk are sequentially numbered so the two bit port sequence numbers derived above map directly into the last two bits of the port addresses.
Ugggh, I think I went a bit too far. There really shouldn't be any relationship between MAC adresses of the ports and the port numbers as seen by the switch, e.g. you connect port x:x:x:x:00 to the third port on the switch, and x:x:x:x:x:01 to the second. In fact I think NetApp claims that the MAC addresses of all the interfaces in an aggregate are all one address. Come to think of it, why? I'm sure the answer is in the developing standard. If there is some explicit advertisement/negotiation between the host and the switch then it shouldn't matter what the MAC is. The switch must have had known it per port anyway even without trunking.
Tom
-
Bennett Todd -
Dane Jasper -
tkaczma＠gryf.net -
Weeks, Thomas