The following people attended the ASARCH review of User Managed Clusters on May 17, 2011:
- Nazrul
- Bill
- Tom
- Chris
- Jerome
- Rajiv
- Ludo
2. Notes
- Lack of experience in regards to *AAS suggests that we should implement option 1 first and use it as a stepping stone to option 3.
- How will GMS find instances?
- Multicast (Can configure OVM to use multicast)
- Environment specific plugin (Amazon: use AutoScale API to find instance group)
- List of multicast URL's
- Jerome: Coherence may solve some issues. Bill: Need some reliable shared storage.
- Potentially everything we sync would need to be relocated to the DB
- Nazrul: If have an HA filesystem we could make it work
- Ex: drop war in a directory and have it deployed to all instances without the need to invoke the deploy command.
- Bill suggests, for symmetry with the centralized DAS model, we create the domain in the instance area and allow commands to operate on it.
- The same App ID needs to be used across all instances. To avoid having to share it we could use the same method to generate the ID on each instance thus arriving at the same value. Could be the SHA-256 hash on the war file plus other data (e.g. context root).
- How do we handle deploy/undeploy where these command perform some operations on the first (or last instance) - e.g. create/drop tables.
- Push the responsibility to the user since they are the "central administrator" now.
- Can provide new options to deploy/undeploy that the user passes on the first or last instance to trigger the correct operation (create/drop table).
- There are potentially JMS integration issues that will need to be addressed.
- In a UMC are there domains? Named clusters?
- Probably should combine the two into one - that is use the same name for the cluster and the domain.
- In a UMC a "domain" can only contain one cluster because the instances of the cluster make up the domain.
- --target
- Default to instance currently executing against.
- Specifying something else is an error
- Don't want command replication to be used.
- DEFAULT_SERVER_INSTANCE_NAME=server
- Need to review DAS only commands to understand what they should do (if anything) on the instance.
- Review the cases where the isDAS() conditional is used to determine what is appropriate in the case where there is no DAS.
- 128 cases in the code.
- Some should be pretty straight forward.
- Deploy can not be executed on instances - that needs to change.
- deploy vs _deploy - need to talk to deploy team.
- Do not introduce a new runtime type. Run instances as normal instances. May have some special cases.
Discussion about Option 3:
- Option 3 - Limit it to single domain and a cluster
- Option 4 - (Bill) HA DAS cluster which manages other domains and clusters. The HA DAS cluster are just instances that run the DAS
- Reviewing 3.1 Feature Overview - potentially 1 and 2 require different solutions.
- OVM requires shared storage to operate
- Nazrul: DAS writes to shared storage. Instances sync from URI when started. If no shared storage we could use the sync-bundle to move data.
- An advantage of the share storage approach is that when the DAS is transfered to another instance the instance should have all the info it needs to take over as the DAS.
- How do we determine which instance should take over as the DAS - ideally want to use a lightly used instance. Don't choose an instances that is very busy.
- Today the DAS does not create that much load.
- Amazon does not have a convenient shared storage mechanism.
- Could the DAS/instance run in the same VM?
- Use embedded DAS in the same JVM?
- Global vars will be an issue.
- One server with two admin adapters enabled - one for instance and one for DAS.
- Would you need two habitats? Probably.
- Should talk to the JVM folks and they are interested in multi-tenancy requirements.
- Can the runtime type change on the fly? What happens to an instance when it becomes the DAS? Does it restart? Could that cause a cascade of failures?
|