DataPersistence¶There are two kind of data that needs to be preserved (across reboot, to backup/recovery, etc..):
- Data related to applications and APIs: this is the data that the application produces, consumes, and needs for its correct functioning (for example Datastores data, Users data etc..)
- Deployment data: this the data needed by AppScale for the specific deployment (for example, the nodes, the volumes, where are the difference components, cloud administrators etc..).
- Datastore, which at this time uses cassandra
- Zookeeper which at this time is used for transaction, and some runtime configurations (ie applications, nodes, appcontroller state)
- file system which is used as a persistent data (ie the appcontroller may use it at start time to read the configuration) and as a temporary runtime data (ie the port file used to allow the appserver to bind to the proper port)
Following are few options we discussed on rationalize this process:
- Option A: cassandra is used for APIs and application data (ie the current apps metadata should be removed). Zookeeper is used for the deployment data: this has the benefit of having a natural way to have consistent data across multiple nodes. The file system is used for the temporary runtime data. In this scenario an AppScale deployment depends on zookeeper to be up and running to start up;
- Option B: cassandra is used for both APIs, application data, and deployment data. Under this scenario AppScale will need to have cassandra up and running to properly configure itself and to basically boot. The file system is used for temporary runtime data. The benefit of this option is that cassandra is already preserved because of the application data, so there is only one place to worry about for backup/recovery and to move a deployment. Cassandra (as zookeeper) already solves the consistent configuration issues across multiple nodes. zookeeper is used only for transaction and possibly removed altogether;
- Options C: the file system is used for the deployment information, Cassandra for application and APIs data, and zookeeper for transaction and possibly some runtime data. This option has the benefit of simplicity (ie modifying configuration will be as easy as to edit a text file), and the downside of the difficulty of keeping the configuration consiste across multiple nodes.
Option A is the favorite one at this time, with Zookeeper been the ultimate repository for deployment data. The picture show a possible workflow assuming that Zookeeper is the deployment information. In this case, all the nodes/AC will have to wait for Zookeeper to be available to read the current state, and then start all the needed services. This may slow the start up time, but it would be consistent in all scenarios.