Neil Garthwaite wrote: > Hi Julian, > > Good feedback. > > W.r.t a probe running inside a heterogenous domU I agree that it would > offer a more realistic domU state. In this regard I also agree it > should be optional, simply because a "virsh domstate" maybe good > enough for some. Furthermore, the "good enough" solution maybe > complimented by existing external systems management tools. Anyway my > point here is to simply agree it should be optional. >
I agree, too. > Taking the view that a more deterministic probe is required to reflect > the state inside a heterogenous domU, I have a few thoughts. > > - We could provide an interface to the probe that allows for a user- > defined probe that provides a highly customized capability. Such a > user-defined probe could simply be called within the HA-xVM probe > under hatimerun conditions. While the benefits of this are great, I > can't help feeling that offering a user-defined probe may compromise > the behavior of the HA-xVM agent, although I guess we can mitigate > against that. Although we're essentially at the design stage, I'd like > to consider the possibility of HA-xVM becoming a fully supported > product within whatever delivery platform, and in that regard a user- > defined probe with the potential to compromise the agent maybe too big > of a support issue. > > - We could provide well defined probes that plugin into the HA-xVM > probe, also under hatimerun conditions. In this regard one could take > the view of up-leveling the probe from just checking the heterogeneous > OS and instead extend into checking the application running within > that OS. While the benefits of this are also great, the issue is > having the proprietary client application program available on the > OHAC/xVM dom0. > > - I'm reluctant to have an additional daemon installed inside a domU > that specifically interacts with the HA-xVM probe in dom0. However, > I'm not adverse to suggesting that the domU provides a service that > the HA-xVM probe in dom0 detects. In this regard, we could suggest > that for a domU to warrant having a more deterministic probe it should > provide service X. For example, the service could be a SMB/CIFS share > that could be probed by a OpenSolaris CIFS client or Samba. Naturally, > this then requires the heterogenous domU to provide that service and > although this maybe possible, our probe may react to the results of a > SMB/CIFS client's connection when SMB/CIFS isn't the main service > being provided by the domU. Nevertheless I hope you get the idea. > I've often thought that a generic probe might be useful. Define the protocol in XML, so that we can extend later. Then the daemons can be written in perl, C, Java, or whatever. This would allow people to easily do interesting things, such as add resource management probes, time-of-day probes, or whatever. -- richard > Anyway, I think it's a good topic for debate. We could perhaps > consider OS personality probes, e.g. a plugin probe per OS. > > W.r.t resource management, I feel we have some aspect of this covered. > One very nice aspect of Solaris Cluster & OHAC is RG Affinities. This > was discussed at the project proposal, i.e. > > http://www.opensolaris.org/jive/thread.jspa?threadID=36406&tstart=15 > > In particular with OHAC we can offer [strong] positive or negative > affinities between Resource Groups. This is very nicely explained in > http://blogs.sun.com/SC/entry/how_does_sun_cluster_decide > . I also plan to show this within a cheat sheet I'm putting together. > > So while RG Affinities addresses important and less important domUs > upon failover, it doesn't address the situation where a physical > server is becoming overloaded. In this regard I think we could look at > how to accommodate this, i.e. to start moving lower prioritized > domains (via live migration or graceful shutdown/restart) to lesser > loaded nodes if a physical server reaches certain thresholds. > > Regards > Neil > _______________________________________________ > ha-clusters-discuss mailing list > ha-clusters-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss >
