Hi,
even if you intended for this question to be off-list, I think my answer
could be interesting to others as well;-)
On 16.03.2012 18:36, Timothy J Massey wrote:
> Arnold Krille<arnold AT arnoldarts DOT de> wrote on 03/15/2012 04:29:45 PM:
>> The scripts are in /var/lib/backuppc/bin, so they are present on both
>> the cluster machines. Yes, my backuppc runs as (one of many) service on
>> a two-node pacemaker-cluster with shared config for the
>> backuppc+apache-stack on a small drbd and /var/lib/backuppc on a bigger
>> drbd...
>
> Have you had any issues or shortcomings with this configuration compared
> to a normal single-machine BackupPC installation? I looked into that same
> configuration (using DRDB and heartbeat), but decided that my BackupPC
> installations (which are on dedicated embedded-style hardware providing
> only BackupPC) were so very reliable that it wasn't worth the hassle, and
> that by far the biggest issue I've experienced has been disk failure and I
> addressed that with RAID (and even that failure was rare, and usually not
> without warning).
>
> I still feel this way, but would still be very curious to hear about your
> experience. It is definitely something that I keep in my back pocket:
> with virtualized environments, we want both file- and disk-level backups,
> and my BackupPC servers are now growing into some pretty large servers of
> their own...
My backuppc-pacemaker-drbd setup was "just" a side-effect of a bigger
project to use drbd and pacemaker to take our virtual machines and their
disk-resources into the high-availability world. One of the first
resources I made HA was a simple apache to display the cluster-status as
html-page. Then I also added backuppc to that resource group.
So there is one drbd-share for the shared configuration (aka
sharedconfig) with the config for this "ClusterGroup" of backuppc, bind,
isc-dhcp, tftp and apache. That drbd-share is small, the additional
drbd-resource for backuppc is of course bigger. Constraints then put all
these resources onto the same node.
And it works rather nice. (Some other parts of these first experiments
didn't go that well. Lets just say gfs2 isn't my friend for the next year.)
As for disk-mirroring with drbd and/or md and/or lvm:
- One thing I learned from hard (bad) experience is that when using
mirroring, you should always use two different disks. Buy the same disks
at the same time (bonus points for directly incrementing serial
numbers), put them in the same machine, let them live through the same
usage and you will find that they also break at the same time.
Don't tell me this doesn't happen because it never happened to you, it
happened to me and to people I know. And I can show you the statistical
calculation that I am right.
- I find mirroring with lvm to be more flexible then "just" hw- or
sw-raid. With lvm you can decide for each of your dynamic discs if they
are unimportant and don't need mirroring. Or if they are pretty
important and need three copies while everything else is just two
copies. I tend to use sw-raid only for the system-partition (with
metadata-format 0.99) because this is also mountable if your kernel
doesn't know about raid.
- You should stay away from hw-raid. It might give you a bit more
performance. But if you don't keep a second controller spare, you are
f***ed when the controller goes to the electronic heaven and your client
insists that he paid a premium for the raid to have "zero downtime".
- Mirroring discs with drbd works surprisingly well in standard
single-primary mode. The latency will be a bit higher that what you get
from pure local discs but you get much lower 'median time between
failures' because you have less (or no) single points of failure.
- When you need more mirrors, either bug/pay the drbd-authors or try
one of the alternatives like MooseFS, Ceph or (my current favourite)
GlusterFS. But I didn't yet test any of these with backuppc...
Man, I should make a blog-post out of this. If I had a blog...
Have fun,
Arnold
--
Dieses Email wurde elektronisch erstellt und ist ohne handschriftliche
Unterschrift gültig.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
