As far as I know, the cost of SAN is very high. It also gives your more GB then you need. And if you need less GB than what given - you just pay too much extra on each GB.
Also, don't forget the equipment using to work with fiber optic cables (control cards, switches and so on). At this cost I think you can build a HA solution: 1. A red rubin DNS. 2. heart bit. 3. using another computer for db/files and two servers to serve the files (sure, has lower performance). Regards, Lior Kaplan [EMAIL PROTECTED] http://www.Guides.co.il Come to write at the forums: http://www.guides.co.il/forums ----- Original Message ----- From: "Dan Fruehauf" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, September 25, 2003 7:39 PM Subject: Re: live website mirroring > On Thursday 25 September 2003 11:45, [EMAIL PROTECTED] wrote: > it was probably my mistake, i said NAS, but i meant SAN (Storage Area > Network). > I can see people are showing interest, so i'll give some more details on what > were doing at work. > > Assuming one server is always active, and the other one is passive, we map the > same disks drives to them through the SAN (while only one server mounts the > storage at a given time). > when a failover happens, the passive server "steals" the ip of the active > server, and it's storage as well and mounts it. > after this, the application is being executed and all should be fine. > what's not too good is that sessions are lost, so if youre application is > stateful, your users will feel the crash that happened, while if it's > stateless the damage will be much smaller. > > Dan. > > > Sagi Bashari wrote: > > >> It's a possible solution, but: > > >> > > >> 1. The NAS is still a single point of failure. > > >> 2. They are talking about having a server at a different location, > > >> so they'll need to replicate the NAS as well. > > > > > > We would like to do this with our current hardware at this stage, we > > > already have RAID1 on both servers so I would just like to keep the > > > arrays identical. > > > > As far as I understood it, the meaning of "NAS" is that you'll have > > common storage accessed over the network ("NAS" = "Network Attached > > Storage"). What does this have to do with each server having its own > > RAID? > > > > BTW, If you already have RAID 1 (mirroring) and if you have more than > > one disk on each mirror side (i.e. at least 4 disks total in each > > mirror) then you better do RAID 0+1 (mirroring over stripping), to > > enhance your access times. > > (e.g. http://www.acnc.com/04_01_0p1.html) > > > > > Right now we will stick to having both servers at the same location, my > > > question was about changing the IP address dynamically if something > > > happens if we ever decide to setup a backup server on another location. > > > > You had two questions, haven't you? > > > > As for this IP question: > > > > 1. If you want the backup server to serve also at "regular times" > > then just advertise both addresses in A records in DNS, the DNS > > server will alternate their order when resolving the server's address > > which will be a very cheap way to load-balance between them. > > > > 2. If you just want the bakcup server to be accessed only when the > > primary one goes down then the only way I can think off right now is > > with having setting the A record with a very short time to live (5-15) > > minutes, as much as you can stand with having an inaccessible server) > > so your DNS will be accessed almost every time the site is accessed, > > when the primary goes down (which can be discovered with various High > > Availability solutions) the secondary updates your DNS server and takes > > over control. > > > > See http://linux-ha.org/ for instance. > > > > (1) and (2) can be implemented together (advertise both, when one > > server goes down the other will delete its address from DNS, when the > > downed server goes back up it will register with the DNS). > > > > There are also mailing lists, forums and sites about Linux high > > availability, maybe you'll find there more knowledgeable crowde, though > > I for one would be curious to hear what you decided to do. > > > > >> My suggestion for a general direction to investigate: > > >> > > >> 1. Check rsync more closely - as far as I remember from using it, it > > >> is actually a very efficient program in CPU, memory, and network > > >> usage. > > > > > > Yes, but I'm not sure that running it every 10 minutes is a good idea, > > > especially if you have many files and some of them are being changed > > > while rsync is running. > > > > Have you conducted your own tests or found results of such tests? > > In general, rsync is supposed to cope well with changing files. > > > > > I found out about a kernel module named "enbd" which is supposed to do > > > RAID over network somehow, but I would like to hear about the experience > > > of others before I start to play with it. > > > > Never heard of it, though I did see the "Network Block Device" option > > in the Kernel 2.4 config, which sounds related to this. I'd expect you > > can google for a community of this module. > > > > >> 2. What about using a content-management (CM) solution which manages > > >> your site instead of handling files "manualy"? Keeping track of your > > >> files through a CM software will enable it to copy over every file > > >> when it's updated, and it can also sort-of track changes and versions. > > >> I can't recall a particular software for this, maybe you can start > > >> by looking for WebDAV implementations (e.g. Apache's WebDAV module). > > > > > > I'm not sure. Basically we're storing all the data in our database and > > > only use the filesystem for files - image files, flash files, website > > > root directories etc. > > > > That's what content management is about. > > > > > All the files must be accessible by apache (it is serving the images > > > directly, we don't read them in our application) . > > > > What I was suggesting (never tried this myself) is that instead of just > > writing files directly to the disk and hope that some sync program will > > find it and copy it over, use a tool which writes it to the disk (so > > it's accessible by Apache) but in the same time can send it (or notify > > about the change) to the backup server. WebDAV is one standard protocol > > to achive the "write a file to a Web server" part. > > > > Also when you have such tools instead of directly writing files to disk, > > you can start using other tools on top of them (QA, testting, > > versioning, authentication, authorization, general site management) > > > > --Amos > > > > > > > > ================================================================= > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > > > ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
