[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Redundant setup



Thinking about how to make a redundant Openshift setup I came across some interesting information in the web, but it still left me with some vital questions:

1. Redundant brokers
These are said to be completely stateless. Does that also mean that my fail-over load balancers do not need to synchronize the state table for network connections as e.g. pfsync does it for BSD? So i do not need sticky sessions on the load balancers and if one of them dies, the next packet of a session can just be sent over the other load balancer and will maybe end up on the other broker. The client should not notice this and does not need to re-create the session. Also if a broker fails the other one can take over in the middle of open sessions.

2. Redundant DDNS setup
With dynamically created apps in Openshift I see the DNS service become more important. A failure of the master DNS server would not interrupt running apps but would block Openshift from doing dynamic DNS updates and creating new apps. As I know BIND there is no real multi-master setup for the same domain, you can have only one active server that takes the DDNS updates and distributes them to the slave servers. What is the best practice here? Is it just not that important? Do you have a custom setup with a fail-over master DNS server or do you switch one of the slave servers to become a master and configure the other ones to sync from the new master? I guess it is not trivial to sync the DNS data with dynamic updates between multiple servers by hand and guarantee a consistent state.

3. Redundant gears for an app
As I see from the DNS entry of an app it points to a node directly. Initial traffic and also SSH login will always go to a "master" gear of an app. If that gear or its node fail the app will be down. I guess this is not really a focus now, since also the db gears are not redundant. The redundancy and scaling of storage is a well known feature request, especially with MongoDB. But that would still leave the part of the master gear of an app a single point of failure. Are there any plans to address that?

Thanks for any thoughts on this.

Cheers,
Anselm


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]