Date: Sun, 06 Feb 2000 07:20:14 -0500 From: "Kim J. Brand" <kim@simple-mail.com> To: Dave Wells <wellsian@caffeine.com>, Greg Lehey <grog@lemis.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: RAID 1 Message-ID: <3.0.1.32.20000206072014.007291c0@192.168.0.1> In-Reply-To: <Pine.BSF.4.21.0002042208060.94611-100000@boris.netgate.net > References: <20000205161021.A11554@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
you've all been TOO kind to invest such thought and energy into this. my application doesn't require the sort of performance or 24/7 uptime that i think is being contemplated by much of the RAID technology i've learned about with your help. my application is a server in a cemetery office. (a VERY LARGE cemetery.) the data is ABSOLUTELY CRITICAL, but if access is delayed by even a day, life won't end.) i believe i could produce an X-Y plot of availability and data security requirements. at the upper right would be COMMERCIAL WEBSERVERS, at the lower left would be personal computers used for AOL access, but there is a distribution in the middle, and this customer just wants their data to BE THERE and it's OK if they have to call the service tech to get it. in fact, they implicitly make that choice by not spending the big bucks it takes to have all the auto-fail-over, hot swap stuff. i think most offices fall in this category of use. performance is NOT an issue, the alternative to looking this stuff up on the computer is walking over to a 400 square foot vault and finding one of 200K * 3 lot cards filed by name, location and date of burial. it would be COOL to have some sort of alert or e-mail message sent to a user that 'one drive failed and could you please get around to fix it'. that's about as automated as i need. it looks like VINUM could do what i need for RAID-1. i read through greg's stuff and am going to try to figure out how to make it work. any help along those lines would be much appreciated. in particular: hardware recommendations. would it be easier to wait for V4? thanks, kim At 11:13 PM 2/4/2000 -0800, Dave Wells wrote: >On Sat, 5 Feb 2000, Greg Lehey wrote: > >> > ...options. Unless some kind soul developer has taken a product line >under >> > their wing and decided to create support then you're working on the edge >> > and this violates most goals I'm aware of that call for RAID in the first >> > place. >> >> You're not "working on the edge", it just doesn't work. > >Granted, it may not. I'm saying that even if you find a driver you may be >out of luck when said kind soul gets a real job. Without commercial >support of some kind these products do not mature or continue, and without >demand, of which there seems too little, there won't be commercial >support. The solution then means falling back to products that are OS >independent, as with "external" controllers. > >I came to the conclusion that most applications just do not warrant >high-availability storage, or haven't yet, at least to their owners, and >that lack of need results in the few products we have available for real >OSs. :< If you have a real need you probably have a real budget and can >talk to a SAN vendor. Or you're one of the experienced few with an all too >familiar problem. > >> > You can figure out vinum and make a beautiful system but when >> > there's a failure it's going to be you back at the console fixing >> > things. >> >> That applies to all RAID systems. You'll probably also need to change >> a disk. >> When there's a failure it's going to be you back at the console fixing >> things. > >Not always true. External controllers generally have displays and control >panels with configuration and recovery options available to the operator. >The form-factor is that of a half or full-height disk with a little LCD >and a few membrane keys. > >I meant the freebsd console vs. someone going in and swapping a disk in >the cabinet and pressing a few membrane keys to start the live rebuild. >External controllers allow this which makes them very attractive. Multiple >disk failures or an axe through a cable are another matter. :) > >> > They'll cost more initially and may not match the best performance >> > you can get from a local vinum raid, but service is almost trivial >> > and support is available. >> >> I'd be interested in details of this. What I've seen has not been >> that simple. Certainly the support for the DPT RAID cards has been >> less than spectacular. > >Yes, card-based raid support is bad. What I meant by support being >available for external raid is that because the external controllers are >OS independant, the only support required is that for the product itself, >not the product vs. an OS. There need be no OS-specific software or >hardware at all. The devices make the RAIDs appear as single disks to the >client computers. > >You know better than most this stuff is moving along all the time. What I >evaluated provided for live RAID rebuilds at the drive array. That assumes >you build with hotswap bays (SCA or...) and configure your RAIDs such that >no drive stands alone. This gets expensive, but it's cheaper than SAN >products I'm aware of. > >> > The best ones? Can't say, but there are quite a few. Just to be sure >> > we're talking about the same things, here's one from Mylex: >> > >> > ftp://ftp.mylex.com/pub/prodinfo/dacsx/dacsx.pdf >> >> We will also support the Mylex RAID cards in release 4.X of FreeBSD. > >Excellent! The lack of support is what pushed us toward external >solutions. I'm sure this is improving but we were unable to find BSDI, >FreeBSD, or Linux solutions so ended up going with solutions that didn't >care about the OS. With "card" solutions, it would have been easiest to >build our RAIDs on NT which doesn't deserve consideration. Solaris has >nice options, but price/performance is poor. > >> > Oh, be careful of the versions that are SCSI cards. These can be tricky to >> > restore or control as the controlling/monitoring software is (once again) >> > Windows based. >> >> This is what I'm talking about. > >I'll second it, or whatever... > >> > Sad state of affairs... Stick with a nice supported SCSI card and an >> > external (to your SCSI card) RAID controller. >> >> So how does the support software work there? > >It doesn't. Because they can be configured "at the panel", monitoring is >the only place software support would help. And monitoring RAID is very >much like monitoring a UPS. Its importance is application specific. If >people are always around the systems then a red light or LCD alert may be >enough. If more is required then it should be possible to hack together >something to periodically query the controller across SCSI. > >One final thing I might add is that these external controllers do add one >single point of failure to the disk storage chain. Many have options for >fail-over cards but the price can quickly get to $3K+ and that's in >addition to the original SCSI card. Since most of us have budgets to worry >about it helps to be creative with how these are used. In large >applications it's often most efficient to build one or a pair of "RAID >hosts", each connected to the RAID controller and its RAIDs, and make them >available to clients on a fast back-channel network. Everything requires >its own specifics but that's the direction we went. > >Dave > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.1.32.20000206072014.007291c0>