Cloud administrators can manually specify which machines should host each of the critical services in AppScale. This document outlines how to use this service to explore alternative deployment schemes that may give your user's applications potentially better performance or make it more fault tolerant.
For a list of the deployments that we fully support and thus test as part of our continuous integration system, please see this page.
What are the critical services?In order to host your applications, AppScale employs the following components:
Change your `ips_layout' to specify exactly what machines should run which services in your deployment. Here's an example:
master: 192.168.1.2
appengine:
- 192.168.1.3
- 192.168.1.4
database:
- 192.168.1.5
Also, as no machine has been specified as the login node, the master node automatically takes up this role. Therefore, one node (192.168.1.2) routes users to their App Engine applications, hosted at 192.168.1.3 and 192.168.1.4. Finally, one machine (192.168.1.5) hosts the database in the system.
Let's look at another example:
master: 192.168.1.2
appengine:
- 192.168.1.3
- 192.168.1.4
database:
- 192.168.1.3
- 192.168.1.4
login:
- 192.168.1.5
In this example, one node (192.168.1.5) routes users to their App Engine applications and performs no other functions. Two nodes (192.168.1.3 and 192.168.1.4) host App Engine applications and host the chosen database. Finally, the master node (192.168.1.2) queries the other nodes in the system to ensure they are running properly and handles transactions via ZooKeeper.
controller: 192.168.1.2
servers:
- 192.168.1.3
- 192.168.1.4
- 192.168.1.5
This deployment employs a controller and a number of servers. These "aggregate roles" each run a number of roles in the system:
But how do you use this placement support in public cloud mode? It's simple - just replace each of the IPs in your ips_layout with node-X (where X is an integer). Here's an example:
master: node-1
appengine:
- node-2
- node-3
database:
- node-4
And for completeness, here's the second example once more:
master: node-1
appengine:
- node-2
- node-3
database:
- node-2
- node-3
login:
- node-4
Component placement in AppScale deployments can possibly offer better (or worse) performance and/or fault tolerance. Let's examine this fact through a familiar example:
master: node-1
appengine:
- node-2
- node-3
database:
- node-4
Here, performance is likely to be better under lower load due to having only one database - many of the internal agreement protocols are vastly simplified when only one node is involved. However, this node is now a single-point-of-failure in the system - if it goes down, users won't be able to read or write data.
Let's look at another familiar example:
controller: node-1
servers:
- node-2
- node-3
- node-4
This deployment gives us four database nodes (one for each node in the system) and three App Engine nodes - giving us vastly better fault tolerance than in the previous deployment.
This document outlines a number of ways by which cloud administrators can manually specify where AppScale's critical services should run. Explore the various deployment options that are now available, and let us know what you're using!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4