While a primary/secondary "application" (previously master/slave) can be implemented by oneself I was wondering whether this doesn’t come out of the box in a container orchestration management system.
Requirements:
- High availability (redundancy) but doesn’t need scaling (capacity).
- Orchestration decides which one is Primary/Secondary (or Alternates (multiples)).
- Container and application (MyApp) knows whether its Primary/Secondary (or Alternates (multiples)).
- Only the primary application (MyApp) is communicating with the service x and the physical device(s).
- Only the primary application (MyApp) forwards the responses to the secondary (with a safe mechanism in place) so that the secondary has all the data/states up to date at all times.
- Both Container/MyApp primary/secondary receive messages from a service (not in picture) so that both are always up to date in case of a failover.
- Both primary/secondary MyApp's should have the same data at any given time (obviously small delay) but only the primary is communicating towards other services.
- Failover should happen within less than a second (e.g. 500ms).
Design
Though I have left out the details I hope the overall requirements/concept is clear.
Questions:
- Is there a container orchestration management that handles primary/secondary application concept?
- Most importantly will my application (MyApp) hosted in the container know when it's in what state (Startup, Sync, Primary, Secondary, PrimaryOnly)?
- How is it best implemented if there is an existing concept?
Did some research but didn't find anything related to primary/secondary application concept where the container knows in which state it's in (Message orchestration to container?).