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