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]
