29.11.2019 17:46, Jan Pokorný пишет:
On 27/11/19 20:13 +0000, matt_murd...@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/


_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

Reply via email to