2008:SE401:Hypothesized Solution - Revision history

Mark at 22:41, 2 May 2008

2008-05-02T22:41:02Z

← Older revision		Revision as of 22:41, 2 May 2008
Line 44:		Line 44:
	*Appendices		*Appendices
	**Gantt Chart		**Gantt Chart


			This project aims to create a framework which takes advantage of Amazon Web Services and provides an infrastructure that can scale the number of available physical servers to balance load, providing a constant level of service.

Mark: /* Report Structure */

2008-04-30T03:04:07Z

Report Structure

← Older revision		Revision as of 03:04, 30 April 2008
Line 28:		Line 28:
	**Existing solutions		**Existing solutions
	*Main		*Main
			**AWS
	**Load measuring techniques		**Load measuring techniques
	**Load balancing		**Load balancing

Mark: /* Report Structure */

2008-04-28T21:47:05Z

Report Structure

← Older revision		Revision as of 21:47, 28 April 2008
Line 34:		Line 34:
	**Look at a similar web system and why ours will be better		**Look at a similar web system and why ours will be better
	**Our approach		**Our approach
			***Agent archatecture
			****Election algorithm
	**Planned structure		**Planned structure
	**plug in modules for settings		**plug in modules for settings

Mark at 21:42, 28 April 2008

2008-04-28T21:42:13Z

← Older revision		Revision as of 21:42, 28 April 2008
Line 25:		Line 25:
	*Introduction		*Introduction
	**Motivation		**Motivation
	**~~requirements~~		**Requirements of the system
			**Existing solutions
	*Main		*Main
	**Load measuring techniques		**Load measuring techniques
Line 31:		Line 32:
	**Testing		**Testing
	**Possible approaches		**Possible approaches
			**Look at a similar web system and why ours will be better
	**Our approach		**Our approach
	**Planned structure		**Planned structure
			**plug in modules for settings
	*Conclusions		*Conclusions
	*Acknowledgements		*Acknowledgements

Mark at 21:37, 28 April 2008

2008-04-28T21:37:08Z

← Older revision		Revision as of 21:37, 28 April 2008
Line 20:		Line 20:



			==Report Structure==

	*Introduction		*Introduction

Mark at 21:36, 28 April 2008

2008-04-28T21:36:24Z

← Older revision		Revision as of 21:36, 28 April 2008
Line 17:		Line 17:
	*Overriding predictions about the use for a system are hard to determine. Both overestimates and underestimates could be costly (cost of running servers and losing customers respectively).		*Overriding predictions about the use for a system are hard to determine. Both overestimates and underestimates could be costly (cost of running servers and losing customers respectively).
	*Election system, still have no idea how it will work algorithmically.		*Election system, still have no idea how it will work algorithmically.




			*Introduction
			**Motivation
			**requirements
			*Main
			**Load measuring techniques
			**Load balancing
			**Testing
			**Possible approaches
			**Our approach
			**Planned structure
			*Conclusions
			*Acknowledgements
			*References
			*Appendices
			**Gantt Chart

Mark at 20:46, 27 March 2008

2008-03-27T20:46:41Z

← Older revision		Revision as of 20:46, 27 March 2008
Line 5:		Line 5:
	It is assumed that in some cases the load on a service will be predictable, an example of this may be a web service advertising the rate of inflation; it is likely that there would be a lot of interest on the day the reserve bank is to announce the newly calculated rate. In such a case our system could preemptively scale up the number of available machines before the service becomes exhausted by the scale of requests.		It is assumed that in some cases the load on a service will be predictable, an example of this may be a web service advertising the rate of inflation; it is likely that there would be a lot of interest on the day the reserve bank is to announce the newly calculated rate. In such a case our system could preemptively scale up the number of available machines before the service becomes exhausted by the scale of requests.

	To determine the quantity of service, we		To determine the quantity of service, we will likely have to use a combination of CPU usage, latency of messages (in RTT). Message queue length? Ram/Total User Footprint usage.

	~~To test~~ our system...		We want to decentralise our system, so our system itself is not a point of failure. We propose to replicate our application on every machine in the cluster providing the service. One instance will act as a master (assuming the services are well load balanced) and based upon its own quality of service, scales the service. Using a heart beat mechanism to keep track of each instance, if the master becomes incapacitated, then a new master will be elected and will take over the scaling of the service.

	Our system should		To test our system we will use JMeter.

			Our system should ...

	Problems;		Problems;
	*Delay in server start up times, introducing windows of possibly poor service; this could be controlled by increasing the sensitivity of the system so it starts services sooner, however this increases cost.		*Delay in server start up times, introducing windows of possibly poor service; this could be controlled by increasing the sensitivity of the system so it starts services sooner, however this increases cost.
	*Overriding predictions about the use for a system are hard to determine. Both overestimates and underestimates could be costly (cost of running servers and losing customers respectively).		*Overriding predictions about the use for a system are hard to determine. Both overestimates and underestimates could be costly (cost of running servers and losing customers respectively).
			*Election system, still have no idea how it will work algorithmically.

Mark at 20:24, 27 March 2008

2008-03-27T20:24:07Z

← Older revision		Revision as of 20:24, 27 March 2008
Line 1:		Line 1:
	The goal of the project is to autonomously scale a web service to provide a consistent quality of service(QOS). Using Amazon Web Services, it is fairly easy to start additional physical machines which can hold a replica of the service and can be used to help balance the load upon that service(It may be that bottlenecks such as databases affect the ease of which services can be replicated and synchronized).		The goal of the project is to autonomously scale a web service to provide a consistent quality of service(QOS) at a minimal cost. Using Amazon Web Services, it is fairly easy to start additional physical machines, which can hold a replica of the service and can be used to help balance the load upon that service(It may be that bottlenecks such as databases affect the ease of which services can be replicated and synchronized). As the utilisation of these services decreases, the number of physically active machines can be decreased allowing us to reduce the running cost.

	We propose to create an application in Java (due to its OS generic nature, native network capabilities and experience with the language and tools held by the developers). This application will monitor the quality of the service being provided and start ~~more services~~ when the QOS starts to deteriorate. As the load on these services starts to decrease, while maintaining our standard of QOS, our application will also scale down the quantity of physical machines, thus reducing the cost of providing the service (this is charged by Amazon Web Services at an hourly rate for each physically active machine.)		We propose to create an application in Java (due to its OS generic nature, native network capabilities and experience with the language and tools held by the developers) to control the replication of a web service. This application will monitor the quality of the service being provided and start additional machines with a replica of the service when the QOS starts to deteriorate. As the load on these services starts to decrease, while maintaining our standard of QOS, our application will also scale down the quantity of physical machines, thus reducing the cost of providing the service (this is charged by Amazon Web Services at an hourly rate for each physically active machine.)

	It is assumed in some cases the load on a service will be predictable, an example of ~~which~~ may be a web service advertising the rate of inflation; it is likely there would be a lot of interest on the day the reserve bank is to announce the newly calculated rate. In such ~~cases it should be possible for~~ our system ~~to pre-emptively~~ scale up the ~~capacity~~ of the service.		It is assumed that in some cases the load on a service will be predictable, an example of this may be a web service advertising the rate of inflation; it is likely that there would be a lot of interest on the day the reserve bank is to announce the newly calculated rate. In such a case our system could preemptively scale up the number of available machines before the service becomes exhausted by the scale of requests.

			To determine the quantity of service, we

			To test our system...

	Our system should		Our system should

Mark: New page: The goal of the project is to autonomously scale a web service to provide a consistent quality of service(QOS). Using Amazon Web Services, it is fairly easy to start additional physical ma...

2008-03-27T20:11:13Z

New page: The goal of the project is to autonomously scale a web service to provide a consistent quality of service(QOS). Using Amazon Web Services, it is fairly easy to start additional physical ma...

New page

The goal of the project is to autonomously scale a web service to provide a consistent quality of service(QOS). Using Amazon Web Services, it is fairly easy to start additional physical machines which can hold a replica of the service and can be used to help balance the load upon that service(It may be that bottlenecks such as databases affect the ease of which services can be replicated and synchronized).

We propose to create an application in Java (due to its OS generic nature, native network capabilities and experience with the language and tools held by the developers). This application will monitor the quality of the service being provided and start more services when the QOS starts to deteriorate. As the load on these services starts to decrease, while maintaining our standard of QOS, our application will also scale down the quantity of physical machines, thus reducing the cost of providing the service (this is charged by Amazon Web Services at an hourly rate for each physically active machine.)

It is assumed in some cases the load on a service will be predictable, an example of which may be a web service advertising the rate of inflation; it is likely there would be a lot of interest on the day the reserve bank is to announce the newly calculated rate. In such cases it should be possible for our system to pre-emptively scale up the capacity of the service.

Our system should

Problems;
*Delay in server start up times, introducing windows of possibly poor service; this could be controlled by increasing the sensitivity of the system so it starts services sooner, however this increases cost.
*Overriding predictions about the use for a system are hard to determine. Both overestimates and underestimates could be costly (cost of running servers and losing customers respectively).