Hello List,
Can anyone recommend some sites regarding building high-availability storage networks using centos (or the upstream providers brand name)? I need to have approx 2-3 tb of storage available via iscsi and smb, but worry about having it all on a single server. Most of the HA articles I'm reading deal with application high availability, but not storage.
Right now I have a centos 4.6 box serving up a mirrored pair of 1tb drives via iscsi and smb, but the poor machine comes apart when anyone tries to write a lot of data. I'm hopefully to have a little budget to upgrade in Q1 2009. Ideally I'd like to get two boxes with proper hardware raid and have them in a cluster.
Any suggestions are appreciated,
Gordon
Gordon McLellan wrote:
Hello List,
Can anyone recommend some sites regarding building high-availability storage networks using centos (or the upstream providers brand name)? I need to have approx 2-3 tb of storage available via iscsi and smb, but worry about having it all on a single server. Most of the HA articles I'm reading deal with application high availability, but not storage.
Check out openfiler?
http://www.openfiler.com/products
For me I would just buy a real storage array, better reliability generally. Though entry level pricing is around $20k.
nate
On Thu, Nov 6, 2008 at 9:27 PM, nate centos@linuxpowered.net wrote:
Gordon McLellan wrote:
Hello List,
Can anyone recommend some sites regarding building high-availability storage networks using centos (or the upstream providers brand name)? I need to have approx 2-3 tb of storage available via iscsi and smb, but worry about having it all on a single server. Most of the HA articles I'm reading deal with application high availability, but not storage.
Check out openfiler?
http://www.openfiler.com/products
For me I would just buy a real storage array, better reliability generally. Though entry level pricing is around $20k.
nate
Hi Nate,
In some countries those storage arrays are about 3 more expensive, so it's cheaper to build it yourself with PC / server components. I'm actually interested in such a setup as well, and would like to cluster 2x machines to give a network RAID setup. What would you recommend using? The idea is to serve to servers which will be clustered as well, hosting web hosting Virtual Private Servers.
Rudi Ahlers schrieb:
On Thu, Nov 6, 2008 at 9:27 PM, nate centos@linuxpowered.net wrote:
Gordon McLellan wrote:
Hello List,
Can anyone recommend some sites regarding building high-availability storage networks using centos (or the upstream providers brand name)? I need to have approx 2-3 tb of storage available via iscsi and smb, but worry about having it all on a single server. Most of the HA articles I'm reading deal with application high availability, but not storage.
Check out openfiler?
http://www.openfiler.com/products
For me I would just buy a real storage array, better reliability generally. Though entry level pricing is around $20k.
nate
Hi Nate,
In some countries those storage arrays are about 3 more expensive, so it's cheaper to build it yourself with PC / server components. I'm actually interested in such a setup as well, and would like to cluster 2x machines to give a network RAID setup. What would you recommend using? The idea is to serve to servers which will be clustered as well, hosting web hosting Virtual Private Servers.
You could use DRBD, if you trust it. AFAIK, Parallels more-or-less supports this. http://wiki.openvz.org/HA_cluster_with_DRBD_and_Heartbeat
Rainer
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Rainer Duffner Sent: Friday, November 07, 2008 4:34 AM To: CentOS mailing list Subject: Re: [CentOS] HA Storage Cookbook?
Rudi Ahlers schrieb:
On Thu, Nov 6, 2008 at 9:27 PM, nate centos@linuxpowered.net wrote:
Gordon McLellan wrote:
Hello List,
Can anyone recommend some sites regarding building high-availability storage networks using centos (or the upstream providers brand name)? I need to have approx 2-3 tb of storage available via iscsi and smb, but worry about having it all on a single server. Most of the HA articles I'm reading deal with application high availability, but not storage.
Check out openfiler?
http://www.openfiler.com/products
For me I would just buy a real storage array, better reliability generally. Though entry level pricing is around $20k.
nate
Hi Nate,
In some countries those storage arrays are about 3 more expensive, so it's cheaper to build it yourself with PC / server components. I'm actually interested in such a setup as well, and would like to cluster 2x machines to give a network RAID setup. What would you recommend using? The idea is to serve to servers which will be clustered as well, hosting web hosting Virtual Private Servers.
If you are going the route of building your own systems vs. buying a true filer you may want to look at something like cleversafe.org. It is intended for globally diverse storage, but I don't see why you couldn't put together a system in-house. I think the minimum number of systems is 4.
Andrew
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
So the short answers are:
1) centos/redhat possess no built-in means of block-level replication via GFS / RHCS 2) openfiler provides some manor of block-level replication 3) there's "beta" software out there that can do it, but it might not be a good idea for production (drbd)
Just for reference; my hardware vendor can set me up with a Supermicro Superserver with 8tb of SAS disk space on hardware raid, 8g of ram and a 5410 quad core cpu for about $4500. From Dell, I can buy an empty SAN box for about $5000, and then pay $500 ea for 1tb sas disks that I can buy retail for about $200. The Dell solution provides no replication either. The only thing I see Dell providing in this case is a brand name and an on-site warranty. Given the most likely item to fail in a storage server is going to be the storage, I don't see the on-site warranty being a big bonus, since they still have to ship you a new drive.
-Gordon
On Fri, Nov 07, 2008 at 10:18:02AM -0500, Gordon McLellan wrote:
So the short answers are:
- centos/redhat possess no built-in means of block-level replication
via GFS / RHCS 2) openfiler provides some manor of block-level replication 3) there's "beta" software out there that can do it, but it might not be a good idea for production (drbd)
Just for reference; my hardware vendor can set me up with a Supermicro Superserver with 8tb of SAS disk space on hardware raid, 8g of ram and a 5410 quad core cpu for about $4500. From Dell, I can buy an empty SAN box for about $5000, and then pay $500 ea for 1tb sas disks that I can buy retail for about $200. The Dell solution provides no replication either. The only thing I see Dell providing in this case is a brand name and an on-site warranty. Given the most likely item to fail in a storage server is going to be the storage, I don't see the on-site warranty being a big bonus, since they still have to ship you a new drive.
I'm guessing you mean SATA instead of SAS.
I suppose you could perhaps do something with iSCSI or ATAoE to another similarly configured box and then tie the local corresponding block device and the ATAoE/iSCSI block device together with RAID1 or LVM...
Don't know how well that'd work vs something drbd with a local, "fast" device and a remote "slow" device (1Gbps over the network).
Ray
Ray,
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
-Gordon
On Fri, Nov 7, 2008 at 10:32 AM, Ray Van Dolson rayvd@bludgeon.org wrote:
I'm guessing you mean SATA instead of SAS.
On Fri, Nov 07, 2008 at 10:49:22AM -0500, Gordon McLellan wrote:
Ray,
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
-Gordon
Ah. So the description says it's a SATA drive, but I guess the connector is SAS...
Thanks for the link!
On Fri, Nov 7, 2008 at 10:32 AM, Ray Van Dolson rayvd@bludgeon.org wrote:
I'm guessing you mean SATA instead of SAS.
Ray Van Dolson wrote:
On Fri, Nov 07, 2008 at 10:49:22AM -0500, Gordon McLellan wrote:
Ray,
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
-Gordon
Ah. So the description says it's a SATA drive, but I guess the connector is SAS...
It's the same connector except keyed so you can plug a SATA device into a SAS backplane but not the reverse. SAS controllers are required to support SATA devices.
Gordon McLellan wrote:
Ray,
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
But, I think the OP's real problem is that everything is tied to one single large drive (i.e. the software mirroring is mostly irrelevant as well as the controller type). These would get you a queue of outstanding commands compared to a SATA, but if you want a big difference in throughput or less latency when multitasking you really have to split things over a bunch of drives, either with some other type of raid or explicitly mounting different filesystems so you can control which things compete for the disk head position.
Les,
That's pretty much my problem. I was hoping to kill two birds with one stone here. First order of business is to replace the single drive with a raid array. Second order was to replace a single iscsi server with duo of machines. If one machine had some sort of non-recoverable problem, the other could pick-up the torch and carry on, even if that means I need to "flip a switch" to make it happen.
Gordon
On Fri, Nov 7, 2008 at 11:06 AM, Les Mikesell lesmikesell@gmail.com wrote:
But, I think the OP's real problem is that everything is tied to one single large drive (i.e. the software mirroring is mostly irrelevant as well as the controller type). These would get you a queue of outstanding commands compared to a SATA, but if you want a big difference in throughput or less latency when multitasking you really have to split things over a bunch of drives, either with some other type of raid or explicitly mounting different filesystems so you can control which things compete for the disk head position.
Gordon McLellan schrieb:
Les,
That's pretty much my problem. I was hoping to kill two birds with one stone here. First order of business is to replace the single drive with a raid array. Second order was to replace a single iscsi server with duo of machines. If one machine had some sort of non-recoverable problem, the other could pick-up the torch and carry on, even if that means I need to "flip a switch" to make it happen.
Gordon
Well, you can always have spare HW onsite. Unless we are talking about a colo-situation, that's usually the way to avoid cost and/or headaches.
Because even the high-end solutions are not really trouble-free....
Rainer
Gordon McLellan wrote:
Les,
That's pretty much my problem. I was hoping to kill two birds with one stone here. First order of business is to replace the single drive with a raid array. Second order was to replace a single iscsi server with duo of machines. If one machine had some sort of non-recoverable problem, the other could pick-up the torch and carry on, even if that means I need to "flip a switch" to make it happen.
My solution for semi-critical stuff (i.e. a few minutes of downtime won't cost the 6 figures it would take to prevent it) has been to use RAID1 in a chassis with hot-swap carriers and keep a spare chassis handy. That way the common case of a disk failure doesn't even cause a slowdown and you can rebuild at an off-peak time without shutting down and in the much less likely case of a motherboard failure you yank the drives, put them in the other box and reboot. But, that means you are probably limited to 6 disks total with half used as mirrors and you still need backups for software or site disasters.
The next step up from this would be DRBD to keep hot copies on the spare machine but I've always gotten away with one spare chassis for several active servers (and sometime using it for testing other things too...).
You do need to know about the NIC hardware address in /etc/sysconfig/ifcfg-eth? when swapping disks around, though.
On Fri, Nov 7, 2008 at 9:03 PM, Les Mikesell lesmikesell@gmail.com wrote:
Gordon McLellan wrote:
Les,
That's pretty much my problem. I was hoping to kill two birds with one stone here. First order of business is to replace the single drive with a raid array. Second order was to replace a single iscsi server with duo of machines. If one machine had some sort of non-recoverable problem, the other could pick-up the torch and carry on, even if that means I need to "flip a switch" to make it happen.
My solution for semi-critical stuff (i.e. a few minutes of downtime won't cost the 6 figures it would take to prevent it) has been to use RAID1 in a chassis with hot-swap carriers and keep a spare chassis handy. That way the common case of a disk failure doesn't even cause a slowdown and you can rebuild at an off-peak time without shutting down and in the much less likely case of a motherboard failure you yank the drives, put them in the other box and reboot. But, that means you are probably limited to 6 disks total with half used as mirrors and you still need backups for software or site disasters.
The next step up from this would be DRBD to keep hot copies on the spare machine but I've always gotten away with one spare chassis for several active servers (and sometime using it for testing other things too...).
You do need to know about the NIC hardware address in /etc/sysconfig/ifcfg-eth? when swapping disks around, though.
-- Les Mikesell lesmikesell@gmail.com _______________________________________________
I've been contemplating a setup similar to what you're referring to.
Basically, take two PC's, (say a Dell PE 860 - I got some of these), and then network-RAID the two PC's, and setup them up with HA to offer one single IP to the network.
Thus, if either one of them fails, you still have the other one left.
If space (i.e. rackspace) is a problem, then 2x1U's won't cost that much, and they can take 2 HDD's each, so you could seup RAID 1 (mirror) on the 2 HDD's as well.
If you can afford 2U space, then you can setup a 2950 with 6 drives each, which has more capacity, and the 2 servers clustered will give redundancy.
Has anyone done something like this? What was your experience with this? I know SuperMicro has a chassis that can take 2x small factor motherboards, which means you can setup something like this on the same chassis.
Les Mikesell wrote:
But, I think the OP's real problem is that everything is tied to one single large drive (i.e. the software mirroring is mostly irrelevant as
...
I think that Les makes a good point, and I'd like to push the point even more generally: providing network file storage, via SAN or NFS is that when you have a single service instance, you need procedures and/or layers of caching to deal with outages.
I've been using a DRBD cluster joined by a bonded GigE switch and it replicates quite quickly. My issues have been related to Heartbeat and monitoring. We've learned it's very important to practice and tune the fail-over process and detect on file system performance rather than merely pinging. Also, it's necessary to monitor application performance to see if your storage nodes are suffering load issues. I've seen a two-core nfs server perform reliably under load 6-7 but it starts to get unhappy at any higher load.
Ironically, we've had absolutely no hard drive errors yet. Hardware things that come to mind are: mother boards: I've had more mother board and ram failures than drive failures with the systems we've had. Raid cards: we've had to swap out 2 3Ware raid controllers also.
Network failures will get you down if you're looking for uptime as well: we recently had a nic in one of our storage nodes get into a state where it was spouting 60Mbit of bad packets and created quite a layer-2 networking issue for two cabinets of web servers and two ldap servers. When the ldap servers couldn't respond, the access to the storage nodes got even worse. It was a black day.
The next thing in our setup has to do with reliance of NFS. NFS may not the best choice to put behind web-servers, but it was quickest. We're adjusting our application to caching the data found on NFS nodes on local file-systems so that we can handle an NFS outage.
My take is: if you're a competent Linux admin, DRBD will cost you less with by using appropriate servers be more maintainable than an appliance. The challenge of course is working out how to reduce response time when any hardware goes sour.
Good luck
Jed
On Fri, 7 Nov 2008, Gordon McLellan wrote:
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
Indeed. They're not SAS either.
Steve
Steve Thompson wrote:
On Fri, 7 Nov 2008, Gordon McLellan wrote:
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
Indeed. They're not SAS either.
From the manufacturer's page: "Barracuda ES.2 SAS 3.0-Gb/s 1-TB Hard Drive"
Sure sounds like SAS to me. What leads you to believe they are not being truthful?
Reading the datasheet, my interpretation is Seagate has taken a ide drive chassis (7200rpm, PMR, slow seek times, etc) and added a SAS interface board. They mention the sas version offers improved performance over the sata version, and also the sas version supports a dual-port interface. Other more expensive SAS drives take a scsi drive chassis (10-15krpm, GMR, fast seek times) and add the SAS interface board.
I guess I'm saying, if you interpret the name "Serial Attached Scsi" literally, then the Seagate ES.2 is not an SAS drive - it is not a scsi drive with a serial interface. However, if you interpret SAS as an interface standard, then the interface board determines what the drive is, more so than its mechanical construction.
-Gordon
On Fri, Nov 7, 2008 at 12:16 PM, Jerry Franz jfranz@freerun.com wrote:
Steve Thompson wrote:
On Fri, 7 Nov 2008, Gordon McLellan wrote:
I meant SAS; specifically Seagate Barracuda ES.2 drives. Here's a tiny version of their huge url:
No, they are not the super fast and expensive 15krpm database drives.
Indeed. They're not SAS either.
From the manufacturer's page: "Barracuda ES.2 SAS 3.0-Gb/s 1-TB Hard Drive"
Sure sounds like SAS to me. What leads you to believe they are not being truthful?
-- Benjamin Franz _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Gordon McLellan wrote:
I guess I'm saying, if you interpret the name "Serial Attached Scsi" literally, then the Seagate ES.2 is not an SAS drive - it is not a scsi drive with a serial interface. However, if you interpret SAS as an interface standard, then the interface board determines what the drive is, more so than its mechanical construction.
SAS and SATA use the same physical interface, the drive mentioned is most definitely SATA. Largest SAS drive I have heard of myself is 400GB, same as the max size for FC drives.
nate
On Fri, 7 Nov 2008 at 2:35pm, nate wrote
Gordon McLellan wrote:
I guess I'm saying, if you interpret the name "Serial Attached Scsi" literally, then the Seagate ES.2 is not an SAS drive - it is not a scsi drive with a serial interface. However, if you interpret SAS as an interface standard, then the interface board determines what the drive is, more so than its mechanical construction.
SAS and SATA use the same physical interface, the drive mentioned is most definitely SATA. Largest SAS drive I have heard of myself is 400GB, same as the max size for FC drives.
No. No it isn't. It's SAS. The platters etc are the same hardware used in the SATA part, but the interface circuitry is native SAS. Note that they offer the drive in both SATA and SAS variants.
While SATA and SAS are *supposed* to be able to be mixed freely, my vendor has warned me that it doesn't always work out that well. They have seen compatibility issues using SATA drives on SAS controllers. So for applications where you want/need a SAS controller but still need big capacity, these are the drives they recommend.
On Fri, Nov 07, 2008 at 05:46:36PM -0500, Joshua Baker-LePain wrote:
On Fri, 7 Nov 2008 at 2:35pm, nate wrote
Gordon McLellan wrote:
I guess I'm saying, if you interpret the name "Serial Attached Scsi" literally, then the Seagate ES.2 is not an SAS drive - it is not a scsi drive with a serial interface. However, if you interpret SAS as an interface standard, then the interface board determines what the drive is, more so than its mechanical construction.
SAS and SATA use the same physical interface, the drive mentioned is most definitely SATA. Largest SAS drive I have heard of myself is 400GB, same as the max size for FC drives.
No. No it isn't. It's SAS. The platters etc are the same hardware used in the SATA part, but the interface circuitry is native SAS. Note that they offer the drive in both SATA and SAS variants.
While SATA and SAS are *supposed* to be able to be mixed freely, my vendor has warned me that it doesn't always work out that well. They have seen compatibility issues using SATA drives on SAS controllers. So for applications where you want/need a SAS controller but still need big capacity, these are the drives they recommend.
Hehe, I think the somewhat confusing part about SAS is that you expect it to be a SCSI disk and have the corresponding performance level, but that won't necessarily be the case if its got SATA innards. :)
Ray
Joshua Baker-LePain wrote:
While SATA and SAS are *supposed* to be able to be mixed freely, my vendor has warned me that it doesn't always work out that well. They have seen compatibility issues using SATA drives on SAS controllers. So for applications where you want/need a SAS controller but still need big capacity, these are the drives they recommend.
Sounds like you need a better vendor for a solution that will work.
nate
On Fri, 7 Nov 2008 at 4:22pm, nate wrote
Joshua Baker-LePain wrote:
While SATA and SAS are *supposed* to be able to be mixed freely, my vendor has warned me that it doesn't always work out that well. They have seen compatibility issues using SATA drives on SAS controllers. So for applications where you want/need a SAS controller but still need big capacity, these are the drives they recommend.
Sounds like you need a better vendor for a solution that will work.
Wait, what? They steer me away from squirrely configs and find me one that works within my budget, and you're criticizing them? I'm rather confused.
Don't try to explain, though. I don't think I'll get it.
Joshua Baker-LePain wrote:
While SATA and SAS are *supposed* to be able to be mixed freely, my vendor has warned me that it doesn't always work out that well. They have seen compatibility issues using SATA drives on SAS controllers. So for applications where you want/need a SAS controller but still need big capacity, these are the drives they recommend.
What I've seen in multiple vendors configuration guidelines is that a given SAS controller and SAS/SATA chassis will support SATA *or* SAS, but not both at once on the same SAS multiplexor.
Am 07.11.2008 um 23:35 schrieb nate:
Gordon McLellan wrote:
I guess I'm saying, if you interpret the name "Serial Attached Scsi" literally, then the Seagate ES.2 is not an SAS drive - it is not a scsi drive with a serial interface. However, if you interpret SAS as an interface standard, then the interface board determines what the drive is, more so than its mechanical construction.
SAS and SATA use the same physical interface, the drive mentioned is most definitely SATA. Largest SAS drive I have heard of myself is 400GB, same as the max size for FC drives.
There are also SATA drives with FC-interfaces.... "FATA"
Used in SANs, mainly.
Take a look at Promise's VtrakJ610-series for cheap 16-bay JBOD array with SAS-connection to the server. Apple re-badges them...
Rainer
Jerry Franz wrote:
Indeed. They're not SAS either.
From the manufacturer's page: "Barracuda ES.2 SAS 3.0-Gb/s 1-TB Hard Drive"
Sure sounds like SAS to me. What leads you to believe they are not being truthful?
its a typo on that page, probably.
http://www.seagate.com/www/en-us/products/servers/barracuda_es/barracuda_es....
says those drives are available both SATA (xxxNS part numbers) and SAS (xxxSS p/n's).
Gordon McLellan schrieb:
So the short answers are:
- centos/redhat possess no built-in means of block-level replication
via GFS / RHCS 2) openfiler provides some manor of block-level replication 3) there's "beta" software out there that can do it, but it might not be a good idea for production (drbd)
Just for reference; my hardware vendor can set me up with a Supermicro Superserver with 8tb of SAS disk space on hardware raid, 8g of ram and a 5410 quad core cpu for about $4500. From Dell, I can buy an empty SAN box for about $5000, and then pay $500 ea for 1tb sas disks that I can buy retail for about $200. The Dell solution provides no replication either. The only thing I see Dell providing in this case is a brand name and an on-site warranty. Given the most likely item to fail in a storage server is going to be the storage, I don't see the on-site warranty being a big bonus, since they still have to ship you a new drive.
If you have a "real" SAN (HP EVA), you can buy block-level replication-software for that. But the software is not exactly cheap (six-figure-sum budget expected). What does downtime cost for you?
With a SAN, you also need switches and HBAs - and everything redundant....
I'd look into ZFS+StorageTek Availability-Suite - or, as sugggested, scrap the idea entirely and instead go for reliable hardware+onsite spares + a fast backup (which also means fast restore, usually). If your tape-backup does 80MB/s and you have 3 TB of data, you need about half a day to do a full-restore...
cheers, Rainer
If you have a "real" SAN (HP EVA), you can buy block-level replication-software for that. But the software is not exactly cheap (six-figure-sum budget expected). What does downtime cost for you?
HP-EVA controller runs on WIN2K, and you have all the inherent problems of why we are staying away from winbloze... ssu scripting is a pain in the neck
thad wrote:
HP-EVA controller runs on WIN2K, and you have all the inherent problems of why we are staying away from winbloze... ssu scripting is a pain in the neck
On the topic of enterprise storage arrays I'm pretty excited today I'm having a 150TB 3PAR T400 virtualized storage array being installed. All on SATA->FC. Controllers can push 100k IOPS to disk, 2.8Gigabytes/second throughput. Bad ass.
They run a hardened version of Debian. Don't get me wrong it's not cheap, list price is about $1 million, half of which is software. Worth every penny(after discount at least). Blows just about everything else on the market away.
nate
on 11-7-2008 7:18 AM Gordon McLellan spake the following:
So the short answers are:
- centos/redhat possess no built-in means of block-level replication
via GFS / RHCS 2) openfiler provides some manor of block-level replication 3) there's "beta" software out there that can do it, but it might not be a good idea for production (drbd)
Just for reference; my hardware vendor can set me up with a Supermicro Superserver with 8tb of SAS disk space on hardware raid, 8g of ram and a 5410 quad core cpu for about $4500. From Dell, I can buy an empty SAN box for about $5000, and then pay $500 ea for 1tb sas disks that I can buy retail for about $200. The Dell solution provides no replication either. The only thing I see Dell providing in this case is a brand name and an on-site warranty. Given the most likely item to fail in a storage server is going to be the storage, I don't see the on-site warranty being a big bonus, since they still have to ship you a new drive.
-Gordon
Who is your hardware vendor if you don't mind me asking? That is a very good deal on the storage.
Hello List,
Can anyone recommend some sites regarding building
high-availability
storage networks using centos (or the upstream providers
brand name)?
I need to have approx 2-3 tb of storage available via
iscsi and smb,
but worry about having it all on a single server. Most of the HA articles I'm reading deal with application high
availability, but not
storage.
Check out openfiler?
http://www.openfiler.com/products
For me I would just buy a real storage array, better reliability generally. Though entry level pricing is around $20k.
In some countries those storage arrays are about 3 more
expensive, so
it's cheaper to build it yourself with PC / server components. I'm actually interested in such a setup as well, and would like
to cluster
2x machines to give a network RAID setup. What would you recommend using? The idea is to serve to servers which will be clustered as well, hosting web hosting Virtual Private Servers.
You could use DRBD, if you trust it. AFAIK, Parallels more-or-less supports this. http://wiki.openvz.org/HA_cluster_with_DRBD_and_Heartbeat
I use drbd for database HA for over a year and have never seen any problems. I'm fairly confident it's ability. I know this is a CentOS mailing list, but a couple pizza boxes and a sas shelf that allows 2+ connections using open solaris+zfs may be your cheapest bet (if you trust a single sas box). ZFS lets you export the volumes as iscsi, nfs, and cifs. You can also use their storagetek suite to replicate over two boxes with independent storage.
Patrick
Rudi Ahlers wrote:
http://www.openfiler.com/products
For me I would just buy a real storage array, better reliability generally. Though entry level pricing is around $20k.
2x machines to give a network RAID setup. What would you recommend using? The idea is to serve to servers which will be clustered as well, hosting web hosting Virtual Private Servers.
openfiler(above from my original email) supports clustering in some form I believe.
I honestly wouldn't trust any such solution myself, if I'm going the cheap route then I would just have 2 of the systems and back up the data to the 2nd one on a routine basis. Clustering is a very in depth, fragile, complex thing to get right, and if not done very very well can cause much more problems than it helps prevent.
nate
-
Andrew Cotter -
Flaherty, Patrick -
Gordon McLellan -
Jed Reynolds -
Jerry Franz -
John R Pierce -
Joshua Baker-LePain -
Les Mikesell -
nate -
Rainer Duffner -
Ray Van Dolson -
Rudi Ahlers -
Scott Silva -
Steve Thompson -
thad