[ClusterLabs] Concept of a Shared ipaddress/resource for generic applicatons

[Andrei Borzenkov]

29.11.2019 17:46, Jan Pokorný пишет:
> 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.
> 

At least in Oracle Solaris Cluster Shared Address is used in "scalable 
resource group" and effectively implements load-balance across multiple 
nodes, where each node answers requests on single virtual address. RH 
mentioned earlier actually describes typical failover cluster (with 
single IP address floating between two nodes), so I find reference to 
ShareAddress rather confusing here.

>> 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.
> 

I would say IPaddr2 in clone mode does something similar to SharedAddress.

> 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
> 
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
>