Re: Fwd: Fwd: Re: endb 101
malte <[email protected]>
| Newsgroups | gmane.linux.enbd.general |
|---|---|
| Message-ID | <[email protected]> |
Hi i hope my bad english will make this topic not fully unreadable so what we really want follows : We have some kind of Clusterproject over here ... It will be an apache mod_backhand Cluster frontend by one server. Although we now have 3 servers we have no chance in using some sort of floating ip and so on but thats all part of different questions. We thought we could use enbd in a way we have some kind of "master" server getting all write operations and 2 or more boxes(the slaves) getting the files read-only via enbd. we were looking forward using fr1 - raid1 on the slaves to get the best in speed and always the newest data from the master. The problem is when the master fails we want the fastest available Slave (the election is another thing) to be the new master and export the files on his disks (the fr1-raid1) as the new source for the other slaves. cause we can't use the floating ip we think we can do that thing with our name servers by changing one CNAME to whatever the new master is. The slaves always look for the Master CNAME not for the real names. Could be its will take one moment longer for detecting the changes ... but it could work. But we're now unsure if it is possible to change the master and then let the slave sync to the new master if there was no problem before ? thanks in advance malte [email protected] wrote: >In article <[email protected]> you wrote: > > >>Peter T. Breuer schrieb: >> >> >> >>>>machine A: md0 [hda3+nda0] >>>> | >>>> |__________________________ >>>> | >>>>machine B: md0 [hda3+nda0], enbd-server exports hda3 >>>> >>>> >>>I don't understand this diagram very well, because of the "machine B: >>>md0 [hda3+nda0]" part. What is that doing there? machine B is exporting >>>hda3, not building it into a raid array! >>> >>> >>aha. i really though both machines build its own md0 out of >>1) a local partition >>2) an imported enbd >> >> > >Well, they do - but not at the same time! > >The whole idea of fallover is that you have a "floating IP address" >that moves between two machines, according to which of them is acting >as the server at that moment. That "primary" (A), when it breaks, passes the >IP over to the "secondary" (B), which has an up-to-date mirror copy of >the data to serve from. > >When A comes back up again, it's likely the roles will remain reversed >until B breaks down for some reason. Depends how you prefer to do it. > >It's also normal to have TWO floating IPs, and TWO resources on each >of TWO servers. One resource on each server acts as a remote mirror >for a resource on the other server. When one server breaks, BOTH >floating IP addresses pass to the remaining server (well, it had one >already). > > > >>so then it's like this: >> >>machine-A: md0 [hda3+nda0] >> >>machine-B: exporting hda3, but were do the applications >> write to? >> >> > >What applications? There should be a service running on the floating IP >on machine A which uses md0. It can be an nfs service if you like! All >access should be via that IP address, and will thus be to machine A, >until it breaks. > > > >>so, machine-A has md0, the applications write to md0, if Machine-B is >>down, Machine-A's md0 can still work in degraded mode. >> >> > >Yes. > > > >>if Machine-A is down, Machine-B has to serve files. does it serve them >>from hda3? >> >> > >Yes. Or if it likes it can start a trivial raid mirror using hda3 and >waiting for machine A to come back up, which it can then use as the >second half of the raid mirror. > > > > >>so machine-A is the only machine with a md0 made from a local partition >>and an nda0 from some other machine. >> >> > >While it is running, yes. > > > > >>i *thought* all machines could >>carry and md0. i was wrong. hm. >> >> > >They can, and you are not wrong. There is no reason for B to use a >mirror (in degraded mode) while A is running, but it can. It would >make things a little easier for when A comes back up again. > > > >>>The intention is key. I think you want to build a failover arrangement? >>> >>> >>yes. >> >> >> >>>In that case, you are doing fine. Now you export md0 from A, >>> >>> >>"export md0 from A"? you mean, i "use md0 on machine A, which is made >>from local hda3+nda0", right? >> >> > >Yes - you use it as the basis of whatever service you are running via >the floating IP, which currently resides on A. > > > >>>and when A breaks you fail over to exporting hda3 from B instead. >>> >>> >>if A breaks, B takes over and B's hda3 (which is exported by >>enbd-server, but not used by A now) is serving the files. >> >> > >Yes. > > > >>>If B breaks instead you still have the hda3 part of the raid on A >>> >>> >> > working. >> >>yes. i think i got it now, if you can please confirm the statement above. >> >> > >Sure. I think you have it too! > > > >>>There are prepared failover scripts for heartbeat in the etc/ directory >>>in the archive. >>> >>> >>yes, that'll be a tricky part too. >> >> >> >>>It's fine - it's even convenient, as you can switch off kernel >>>buffering (use the switch that does open O_DIRECT on the server) and >>>rely on the db servers to sync between distributed copies of the db. >>> >>> >>ok. i'm thinking about one issue here, but it's not really >>enbd-specific: if the db-server (mysqld) is running on A and B all the >>time and now A goes down, B takes over. fine. but in the time A *and* B >>are running, only *one* machines should be allowed to write, yes? (i >> >> > >Indeed. Only one is normally capable of being accessed, because only >one has the floating IP address through which communication occurs. > >But with a DB server that understands distribution, I think it doesn't >matter - not that I have personal experience. > > > >>guess i'll only start mysqld on B when A is really down). >> >> > >That would be the standard way. But mysqld may understand the concept >of running two places at once! Oracle does, I believe. > >Peter >_______________________________________________ >ENBD mailing list >[email protected] >http://lists.community.tummy.com/mailman/listinfo/enbd > >----- End forwarded message ----- > > > > >---------------------------------------------------------------- >This message was sent using IMP, the Internet Messaging Program. > >----- End forwarded message ----- > > > > >---------------------------------------------------------------- >This message was sent using IMP, the Internet Messaging Program. > >