tmart
08-10-2010, 02:23 PM
in the enterprise space it would be extremely handy to have multiple resource (I'm thinking strictly resources here, not general properties) configuration views be configured and built-into a given application. This would allow an application to be "parked" on one grid in a database replication slave model, for example, which could quickly be turned-up in case of DR without extensive reconfiguration.
For example, I'd like the ability to build into the configuration either "run state" type scripting or else different resource configurations that would allow me to shift from "standby" to "DR" or "active" mode and automagically start/restart the components with appropriate resource assignments for that new run state.
A concrete example is an app such as the following:
http://www.geosprings.com/storage/misc/clipboard_1.png
Where we have a secondary instance of this identical app running on another grid, but basically only have the MYSQLR and the VPN up & running and thinly provisioned. In a DR scenario we'd like to change the state of the secondary instance to "Run" or "DR" that includes scripting necessary to [re]start any necessary components (the "IN" firewall, web and app servers, etc. -- components that are not necessary in an application standby mode) for that run state with the appropriate resources. Start order could still be heeded to make sure that the right thing happens. Anything that doesn't differ in resources wouldn't need to be touched.
So maybe each "view" provides: cpu/mem/bw figures as well as potentially its own "standby" property that allows us to control which components should be started or stopped when moving into that run state. I don't think that we'd need to provide an explicit path for each possible run state movement... simply the difference in the values between run states would dictate what should be done.
The benefit in doing this is that we can have standby apps configured with built-in knowledge of what's necessary to run the app, but without consuming all of the resources of a fully functional app. Right now we can accomplish this either with custom "3t" style scripting or else by manually doing the needful. This would allow us to "cook in" the two (or more) configurations to the application ahead of time, speeding the DR scenario execution and preventing mistakes.
-- Tim
For example, I'd like the ability to build into the configuration either "run state" type scripting or else different resource configurations that would allow me to shift from "standby" to "DR" or "active" mode and automagically start/restart the components with appropriate resource assignments for that new run state.
A concrete example is an app such as the following:
http://www.geosprings.com/storage/misc/clipboard_1.png
Where we have a secondary instance of this identical app running on another grid, but basically only have the MYSQLR and the VPN up & running and thinly provisioned. In a DR scenario we'd like to change the state of the secondary instance to "Run" or "DR" that includes scripting necessary to [re]start any necessary components (the "IN" firewall, web and app servers, etc. -- components that are not necessary in an application standby mode) for that run state with the appropriate resources. Start order could still be heeded to make sure that the right thing happens. Anything that doesn't differ in resources wouldn't need to be touched.
So maybe each "view" provides: cpu/mem/bw figures as well as potentially its own "standby" property that allows us to control which components should be started or stopped when moving into that run state. I don't think that we'd need to provide an explicit path for each possible run state movement... simply the difference in the values between run states would dictate what should be done.
The benefit in doing this is that we can have standby apps configured with built-in knowledge of what's necessary to run the app, but without consuming all of the resources of a fully functional app. Right now we can accomplish this either with custom "3t" style scripting or else by manually doing the needful. This would allow us to "cook in" the two (or more) configurations to the application ahead of time, speeding the DR scenario execution and preventing mistakes.
-- Tim