Let's Consider Having Three Separated Environments in Infra

[Yedidyah Bar David]

On Wed, Jul 20, 2016 at 7:45 PM, Anton Marchukov <amarchuk at redhat.com> wrote:
> Hello All.
>
> This is a follow up to the meeting minutes. Just to record my thoughts to
> consider during the actual design.
>
> To make it straight. I think we need to target creation of 3 (yes, three)
> independent and completely similar setups with as less shared parts as
> possible.
>
> If we choose to go with reliability on service level than we do need 3
> because:
>
> 1. If we mess up with one environment (e,g, storage will be completely dead
> there) we will have 2 left working that gives us a reliability still because
> one of them can fail. So it will move us out of crunch mode into the regular
> work mode.
>
> 2. All consensus based algorithms generally require at least 2N+1 instances
> unless they utilize some special mode. The lowest is N=1 that is 3 and it
> would make sense to distribute them into different environments.
>
> I know the concern for having even 2 envs was that we will spend more effort
> to maintain them. But I think the opposite is true. Having 3 is actually
> less effort to maintain if we make them similar because of:
>
> 1. We can do gradual canary update, Same as with failure. You can test
> update on 1 instance leaving 2 left running that still provides reliability.
> So upgrade is no longer time constrained and safe.
>
> 2. If environments are similar then once we establish the correct playbook
> for one we can just apply it for second and later for third. So this
> overhead is not tripled in fact and if automated than it is no additional
> effort at all.
>
> 3. We are more open to test and play with one. We can even destroy it
> recreate from scratch, etc. Indirectly this will reduce our effort.
>
> I think the only real problem with it is the initial step when we should
> design an ideal hardware and network layout for that. But once it is done it
> will be easier to go with 3 environments. Also it may be possible to design
> the plan the way that we start with just one and later convert it into
> three.

Not sure it's my business, but whatever:

1. Do you intend also separate data centers? Such that if one (or two) of
them looses connectivity/power/etc, we are still up?

2. If so, does it mean that recreating it means copying from one of the
others many GBs of data? And if so, is that also the plan for recovering
from bad tests?

3. If so, it probably means we'll not do that very happily, because
"undo" will take a lot of time and bandwidth.

4. If we still want to go that route, perhaps consider having per-site
backup, which allows syncing from the others the changes done on them
since X (where X is "death of power/connectivity", "Start of test", etc).
Some time ago I looked at backup tools, and found out that while there are
several "field tested" tools, such as bacula and amanda, they are considered
old-fashioned, but there are several different contenders for the future
"perfect" tool. For an overview of some of them see [1]. For my own uses
I chose 'bup', which isn't perfect, but seemed good and stable enough.

5. This way we still can, perhaps need to, sync over the Internet many
GBs of data if the local-site backup died too, but if it didn't, and we
did everything right, we only need to sync diffs, which hopefully be much
smaller.

[1] http://changelog.complete.org/archives/9353-roundup-of-remote-encrypted-deduplicated-backups-in-linux

Best,

>
> Anton.
>
> --
> Anton Marchukov
> Senior Software Engineer - RHEV CI - Red Hat
>
>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



-- 
Didi