Date: Tue, 11 Dec 2007 02:29:45 +0000 From: "Storer, Darren" <darren.storer (at mark) gmail.com> Subject: [coba-e:11393] Re: Project Live? - Updates - Disaster Recovery To: coba-e (at mark) bluequartz.org Message-Id: <1142a46a0712101829o298c2019q6da6792f4c86cda9 (at mark) mail.gmail.com> In-Reply-To: <200712101353.58354.bq (at mark) solarspeed.net> References: <683F5FB5E2C08E4A8FE8D499A890A3EA0378B7 (at mark) mainserver.mainline.local> <008b01c83a65$79293230$6b7b9690$ (at mark) co.uk> <00b601c83a6f$51871fd0$f4955f70$ (at mark) co.uk> <200712101353.58354.bq (at mark) solarspeed.net> X-Mail-Count: 11393Hi Michael, MS > While a "do it yourself" approach is of course possible, MS> there is also a commercial software available which does this out of the box please could you supply details (or a URL) for the commercial solution that you mention above? Many Thanks Darren On 10/12/2007, Michael Stauber <bq (at mark) solarspeed.net> wrote: > > Hi Jason, > > > 1. None of the Internet resource pages for BlueQuartz (Home page, > > SourceForge, etc...) seem to be active. Is this still an active and > > supported project and if so what Web resources have I missed? > > The official homepage for the BlueQuartz project is http://bluequartz.org > > > 2. On the BlueLinQ page only the YUM Updater works. All the other update > > pages give: "BlueLinQ was unable to retrieve a list of packages from the > > BlueLinQ server located at ." Presumably I am supposed to fill in the > > relevant servers in the settings area. What should I put there or should > I > > in fact leave as is and forget about this facility? > > The only relevant menu entries in "BlueLinQ" are this: > > "YUM Updater": This is how you update BlueQuartz. > > "Installed Software": Shows installed PKGs and software components. > > All other menu entries are more or less deprecated and a carry over from > the > Sun Cobalt times when patches and updates were delivered as PKGs. They're > just left in for historical reasons and to give third party software > vendors > the ability to distribute their PKGs. > > > 3. Now the hard question. I would like to synchronise a second > > geographically separate server with my master for DR reasons. The second > > server will be on a different IP address and in the case of disaster I > > would point the relevant DNS records (not held on the master) to the > second > > server. However I would like it if any additions/changes to the Master > were > > synchronised to the secondary along with site content. Users etc... I'm > > guessing there isn't a simple solution to this? > > That is something that BlueQuartz doesn't support out of the box. > > There are several approaches imagineable to do that and which one is best > of > course depends on the expected usage and how much time, efforts and money > you > want to invest, if you want to do it in a "do it yourself" approach, or > want > to buy components or entire solutions that fulfill all or most of the > required needs. Or something in the middle. > > A "weak" solution would be to mirror the data through Rsync over SSH. I > call > it weak, because the way BlueQuartz spreads the information around on the > disks makes it difficult to use Rsync to mirror it all. It's possible, but > you have to have a good understanding of the architecture to make it > happen > without breaking things. > > Another approach is to use CMU to export sites and users on the primary, > copy > the data over to the secondary and import it there. This can be scripted > to > run automatically on both ends, but isn't very relieable. > > A better approach is to use clustering - for example with DRBD and > Heartbeat. > With or without virtualization. If you check the list archives you'll see > that this has been discussed in the past. See [coba-e:05068] and > [coba-e:08772]. While a "do it yourself" approach is of course possible, > there is also a commercial software available which does this out of the > box. > > -- > With best regards, > > Michael Stauber > > >11393_2.html (attatchment)(tag is disabled)