Hello, what about data synchronization? I suppose that user also write to ERP
and not only read, right?
in my opinion, more complexity = more fragile system = lower availability that
simple system.
so, you can setup in each site, local loadballancer, which by default will
connect to DC instace and in case of failure (DC, Internet connection, etc..)
it will switch to local instance.
If you need also writes, them you also need to solve some data synchronization.
S pozdravem Kristián Feldsam
Tel.: +420 773 303 353, +421 944 137 535
E-mail.: supp...@feldhost.cz
www.feldhost.cz - FeldHost™ – profesionální hostingové a serverové služby za
adekvátní ceny.
FELDSAM s.r.o.
V rohu 434/3
Praha 4 – Libuš, PSČ 142 00
IČ: 290 60 958, DIČ: CZ290 60 958
C 200350 vedená u Městského soudu v Praze
Banka: Fio banka a.s.
Číslo účtu: 2400330446/2010
BIC: FIOBCZPPXX
IBAN: CZ82 2010 0000 0024 0033 0446
> On 5 Aug 2017, at 13:11, Jan Pokorný <jpoko...@redhat.com> wrote:
>
> On 05/08/17 00:10 +0200, Jan Pokorný wrote:
>> [addendum inline]
>
> And some more...
>
>> On 04/08/17 18:35 +0200, Jan Pokorný wrote:
>>> On 03/08/17 20:37 +0530, sharafraz khan wrote:
>>>> I am new to clustering so please ignore if my Question sounds silly, i have
>>>> a requirement were in i need to create cluster for ERP application with
>>>> apache, VIP component,below is the scenario
>>>>
>>>> We have 5 Sites,
>>>> 1. DC
>>>> 2. Site A
>>>> 3. Site B
>>>> 4. Site C
>>>> 5. Site D
>>>>
>>>> Over here we need to configure HA as such that DC would be the primary Node
>>>> hosting application & be accessed from by all the users in each sites, in
>>>> case of Failure of DC Node, Site users should automatically be switched to
>>>> there local ERP server, and not to the Nodes at other sites, so
>>>> communication would be as below
>>>>
>>>> DC < -- > Site A
>>>> DC < -- > Site B
>>>> DC < -- > Site C
>>>> DC < -- > Site D
>
> Note that if you wanted to imply you generally rely on/are limited with
> star-like network topology with a central machine doubling as a relay,
> you distort our implicit notion (perhaps we should make it explicit)
> of cluster forming a complete graph (directly or indirectly through
> multicast) amongst the nodes of the healthy partition (corosync is not
> as advanced to support grid/mesh/star topologies, but it's a non-goal
> for a direct peer messaging layer to start with). Sure, you can
> workaround this with tunnelling, at the cost of compromising
> reliability (and efficiency) and hence high availability :)
>
> With communication site x DC communication _after failure_, do you
> mean checking if the DC is OK again or something else?
>
>>>> Now the challenge is
>>>>
>>>> 1. If i create a cluster between say DC < -- > Site A it won't allow me to
>>>> create another cluster on DC with other sites
>>>>
>>>> 2. if i setup all the nodes in single cluster how can i ensure that in case
>>>> of Node Failure or loss of connectivity to DC node from any site, users
>>>> from that sites should be switched to Local ERP node and not to nodes on
>>>> other site.
>>>>
>>>> a urgent response and help would be quite helpful
>>>
>>> From your description, I suppose you are limited to just a single
>>> machine per site/DC (making the overall picture prone to double
>>> fault, first DC goes down, then any of the sites goes down, then
>>> at least the clients of that very site encounter the downtime).
>>> Otherwise I'd suggest looking at booth project that facilitates
>>> inter-cluster (back to your "multi cluster") decisions, extending
>>> upon pacemaker performing the intra-cluster ones.
>>>
>>> Using a single cluster approach, you should certainly be able to
>>> model your fallback scenario, something like:
>>>
>>> - define a group A (VIP, apache, app), infinity-located with DC
>>> - define a different group B with the same content, set up as clone
>>> B_clone being (-infinity)-located with DC
>>> - set up ordering "B_clone starts when A stops", of "Mandatory" kind
>>>
>>> Further tweaks may be needed.
>>
>> Hmm, actually VIP would not help much here, even if "ip" adapted per
>> host ("#uname") as there're two conflicting principles ("globality"
>> of the network for serving from DC vs. locality when serving from
>> particular sites _in parallel_). Something more sophisticated would
>> likely be needed.
>
> Thinking about that more, the easiest solution _configuration-wise_
> might be:
>
> * single-real-node cluster at each of the sites, each having
> - disabled fencing (but configure and enable when/if you add more nodes)
> - a unique "prolonged arm" in a form of ocf:pacemaker:remote instance
> to be running at DC (e.g. different ports can be used so as to avoid
> communication clashes at DC)
> - custom resource agent (e.g. customization of ocf:heartbeat:anything)
> that will be just monitoring liveness of ERP application,
> preferring to run at the DC through that very pacemaker-remote
> - a unique IP (hostname mapping) which will be used by the users
> of that very site to access the application
> - VIP configured to represent that very IP, collocated with
> the said monitoring agent, meaning that VIP will follow it,
> i.e. will only run where the ERP application is running,
> primarily will stay at DC, with the fallback to the home site
>
> There are many adjustments possible on top of this sketch, which is
> furthermore totally untested. Advantage is that you may add new nodes
> at each site so as to achieve per-site HA. (But When also DC will get
> clustered with additional nodes, then booth will likely be a way
> forward.)
>
> Note that to avoid race conditions, pacemaker-remote instances at DC
> should not try to control the ERP application directly, but it should
> rather be set for autonomous recovery (most simple restart-after-failure
> case can be achieved, for instance, through service file directives
> of systemd if that's how it gets launched).
>
>
> This is definitely quite atypical workload from what I've seen so far,
> and is not easy to wrap my head around.
>
> --
> Poki
> _______________________________________________
> Users mailing list: Users@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
_______________________________________________
Users mailing list: Users@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
