[ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons
Jan Pokorný
jpokorny at redhat.com
Fri Nov 29 09:46:04 EST 2019
On 27/11/19 20:13 +0000, Matt_Murdock at amat.com wrote:
> I finally understand that there is a Apache Resource for Pacemaker
> that assigns a single virtual ipaddress that "floats" between two
> nodes as in webservers.
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_administration/ch-service-haaa
>
> Can generic applications use this same resource type or is there an
> API to use to create a floating ip or a generic resource to use?
Be assured generic applications can use the same "floating IP
address", effectively IPAddr2 resource (particular instances
thereof) to their own benefit.
The only crux that can be seen here stems from loose started/stopped
kind of inter-resource (putting resource-node relations aside)
integration facilitated by pacemaker, imposing these constraints
for a generic/convenient use case:
1. the resource relying on the particular floating IP instance
needs to start at later moment than this IP instance
(it could miss listening on the newly/at later point
appearing IP otherwise)
2. the resource relying on the particular floating IP instance,
in order to retain enough configuration flexibility, must
_not_ be restricted regarding where to listen (bind the
server side socket) at, for several reasons:
- different names of the interfaces across the nodes
to appoint the "externally provided service" network
- fragile, possibly downright cluster-management hidden
interdependencies whereby two parts of the overall
configuration must exactly agree on the address to bind at,
for given point in time
apparently, this approach is suboptimal for constraining
the allowed data paths (think, information security)
Btw. As a slight paradox, rgmanager used for HA resource clustering
in RHEL in the past allowed for natural resource "composability"
(combinability, stackability) with a straightforward propagation of
configuration values in the hierarchical composition of the resources
-- it would then be enough if a floating IP dependent resource
explicitly referred to IP to be borrowed from the cluster-tracked
configuration of its hierarchically preceding "virtual IP" resource
instance, avoiding thus hindrance stated in item 2. (item 1. remains
rather universal). (Similar thing can, of course, be emulated with
explicit pacemaker configuration introspection in the agent itself,
however it feels rather dirty [resource agents would preferably avoid
back-channel introspection of their own runners as much as possible,
it'd break the rule of loose one-way coupling] in comparison to said
built-in mechanism.) [*]
> In other HA system, Oracle Solaris Cluster, HPUX Service Guard, IBM
> PowerHA, they provide a "SharedAddress" resource type for
> applications to use.
I suppose our ocf:heartbeat:IPAddr2 resource agent is a direct
equivalent, but don't have the knowledge of these other products.
> I am getting confused by the Clone feature, the virtualized feature,
> and now the Apache resource as to how they all differ.
"Clone" feature for IPAddr2 is actually sort of an overloading that
agent with an alternative functionality -- trivial low-level load
balancing. You can ignore that if you don't need any such.
Regarding "virtualized", virtual and floating are being used
interchangably to refer to said "IP address" resource agent
instances.
Of course, you then have various other contexts of "virtualized",
you can have virtual machines (VMs) as resources managed by pacemaker,
your cluster can consist of a set of VMs rather than set of bare
metal machines, "remote" instances of pacemaker can be detached
in VMs, and so forth.
> If this isn't right group, let me know, and be kind, im just trying
> to get something working and make recommendations to my developers.
This venue is a spot-on, welcome :-)
[*] I've touched this topic slightly in the past:
https://github.com/ClusterLabs/resource-agents/issues/1304#issuecomment-473525495
https://github.com/ClusterLabs/OCF-spec/issues/22
--
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20191129/dc41773c/attachment.sig>
More information about the Users
mailing list