[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