> (a) gathering enough information about the real state of the network in > a central place to be able to make meaningful decisions.
I want to throw in a couple of examples from some work that I've done recently on management of virtual machine environments in terms of planning and deployment. This is small scale, but already at this level there are behaviours that are relevant to this discussion. Somewhat fragmented notes, but here we go: I've found that it's not only necessary, but critical to have an intermediate representation of "real-worl" state at a more "centralized" level - put this in quotes, since this in itself can be a distributed application, the primary requirement is that there is a co-ordinated location where state-information and change-instructions flow through and are cross-checked. To create a virtual machine instance (aka guest) it will need a number of resources available, say memory and disk space. You can blindly send change instructions and have this fail at runtime, or you can run the request through a capacity model paired together with state-information. It should be noted that if a request to create a virtual machine instance fails because the capacity calculation tell you that there is no available capacity, then the system works according to it's specification. This is important for definition of things like bulk operations. I request to get 100 virtual machine instances, but the infrastructure can only provide me with 80 according to the definition of virtual machines I have specified - then the entire change request can fail gracefully without any attempts to actual changes. You have the opportunity to operate on captured state information, and even before change-instructions are executed _validate_ that your stipulations about capacity is correct. By representing aggregated run state information you can also make automated decisions about where to place virtual machines. This is resource management 101, but I'm not sure to what extent the compute clusters with resource managers have modeled services in such a way that their resource requirements are encoded and that you can make "meaningful decisions" about them. Another important property of this intermediate state information is that you can further associate data with this. For a virtual machine environment you can introduce in the state machine that a set of resources are "allocated" even if they're currently not in effect. You do this when you want to create new virtual machine instances and prevent the race that another set of change instructions come around and grab the resources you have requested. At this point you have a more granular run state data set than either the configuration or the real systems could provide you combined. By further adding state-machine behaviour to this aggregation point, you can update allocated resource slice to a resource slice in actual use the moment it is confirmed that a virtual machine instance is created and in use. There is a bunch of other parameters in play here, but they all work the same. An observation from this work, is that it's important to identify the authority of resources, who should control a set of resources. Take the example of available disk space. In this particular case, there is storage dedicated to virtual machines and any physical machine will yield management authority to the remote system. If there is a difference between what the virtual machine management system think is the state of that storage and what is actually on the system, then you have an error and it's not operating according to your specification. This is as Ed points out very hard/impossible? to implement in a general way, but I do believe that any framework need to provide the facilities to represent not only an encoding of configurations and their relationships to each other, but also of the real-world resources and their relationships to each other. This is also where I'm uncertain if the layered approach will hold up very long. I've recently started to appreciate more what Ed pointed out to me a couple of years a go, that the "end" set of procedural code that actually make changes on a system, becomes far less important (e.g. could be just shell scripts) the moment you can encode/encapsulate a "component's" (LCFG-speak) behaviour at a higher level. -- ---------------------------------------------------------------------- |\|\ where in the | s_u_b_s_t_r_u_c_t_i_o_n | | >=========== W.A.S.T.E. | genarratologies |/|/ (_) is the wisdom | [EMAIL PROTECTED] ---------------------------------------------------------------------- _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
