[ClusterLabs] DRBD or SAN ?

Ian ian.ninjabadger at gmail.com
Mon Jul 17 18:45:33 UTC 2017


DRBD is absolutely compatible with mysql/postgres.

In my experience, with a 10G pipe for block replication, there's also
basically no performance degradation compared to native disk writes, even
with an SSD array.

> I've always favored native replication over disk replication for
databases. I'm not sure that's a necessity, but I would think the
biggest advantage is that with disk replication, you couldn't run the
database server all the time, you'd have to start it (and its VM in your
case) after disk failover.

This is true, you have to start mysql/the vm during failover, but in my
experience usually that is very fast (depending on mysql/vm
configuration).  Also, depending on what replication tools you are using,
you'd still have to promote the slave to a master, which might save seconds
or less compared to starting mysql (which, I recognize, could be
important).  Note that I am unfamiliar with methods of postgres
replication.

I think a big advantage compared to native replication is that DRBD offers
synchronous replication at the block level as opposed to the transaction
level.  I have not run my own tests, but my vicarious experience with tools
such as Galera or other synchronous forms of SQL replication indicate that
there may be a significant performance hit based on workload.  Obviously,
there's no significant performance hit if you are doing mysql native
asynchronous replication (I guess as long as you aren't spending all your
i/o on the master on your binlogs), but then you are relying on
asynchronous processes to keep your data safe and available.  Perhaps that
is not a big deal, I am not well versed in that level of replication theory.

> physical proximity so that environmental factors could
take down the whole thing.

Literal server fires come to mind.

@OP, I agree with Ken that a multi-datacenter setup is ideal if your
application can deal with its various caveats and may be worth
investigating since the advantages of moving to a DRBD setup doesn't
eliminate any more problems than a multi-dc setup would as long as your SAN
is already set up on independent electrical circuits and separate
networking stacks to begin with.  E.g., both a multi-server and
multi-center setup would protect from small disasters that take out the
whole server, but a DRBD setup does not add much more than that whereas a
multi-center setup would also protect from large-scale disaster.   DRBD and
a SAN would also both suffer from a building-wide power outage.  Do you
have generators?

On Mon, Jul 17, 2017 at 1:30 PM, Digimer <lists at alteeve.ca> wrote:

> On 2017-07-17 05:51 AM, Lentes, Bernd wrote:
> > Hi,
> >
> > i established a two node cluster with two HP servers and SLES 11 SP4.
> I'd like to start now with a test period. Resources are virtual machines.
> The vm's reside on a FC SAN. The SAN has two power supplies, two storage
> controller, two network interfaces for configuration. Each storage
> controller has two FC connectors. On each server i have one FC controller
> with two connectors in a multipath configuration. Each connector from the
> SAN controller inside the server is connected to a different storage
> controller from the SAN. But isn't a SAN, despite all that redundancy, a
> SPOF ?
> > I'm asking myself if a DRBD configuration wouldn't be more redundant and
> high available. There i have two completely independent instances of the vm.
> > We have one web application with a databse which is really crucial for
> us. Downtime should be maximum one or two hours, if longer we run in
> trouble.
> > Is DRBD in conjuction with a database (MySQL or Postgres) possible ?
> >
> >
> > Bernd
>
> DRBD any day.
>
> Yes, even with all the redundancy, it's a single electrical/mechanical
> device that can be taken offline by a bad firmware update, user error,
> etc. DRBD gives you full mechanical and electrical replication of the
> data and has survived some serious in-the-field faults in our Anvil!
> system (including a case where three drives were ejected at the same
> time from the node hosting the VMs, and the servers lived).
>
> --
> Digimer
> Papers and Projects: https://alteeve.com/w/
> "I am, somehow, less interested in the weight and convolutions of
> Einstein’s brain than in the near certainty that people of equal talent
> have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20170717/11a0a203/attachment-0002.html>


More information about the Users mailing list