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

Single OpenShift cluster/instance across datacenter?



We are running into similar issue similar to below issue. 

http://stackoverflow.com/questions/34194602/single-kubernetes-openshift-cluster-instance-across-datacenters

Pondering whether to go with single cluster span across 3-4 data centers and go with each cluster dedicated to local DC. Each one has its own pros and cons but multiple clusters approach creating more management/operational overhead to both platform and client teams.

Why we hating multiple clusters approach?
  1. Each cluster has its own API end point. Clients has to use different API end points while working with each DC pods or life cycle management. They might don’t like it
  2. While provisioning apps, pods need to be created on each cluster and should tie-up up with another global routing layer
  3. If an application has few pods running from each cluster, how they communicate unless they create additional service groups or  other apps talking this app, will they have deal with multiple service and routing groups? Communication with in the app pods or inter application communication is complex. 
  4. To mask the multiple clusters and API end points, we have to build a uber style a common orchestration, routing and client interface where clients can ignore backend topology and use a common interface for their day to day job. 
I heard master place also can’t span across data centers, particularly etcd due to its latency requirements, to be co related in same location. Is it a still a problem if data centers are connected with decent network infra?

We are OK to restrict master and etcd to a single data center if latency as an issue but love to spin these components also across DC’s for high performance and fault tolerance.

Interested to hear what is the best reference architecture for multiple data centers or how people are dealing when they ran into similar situation? 

Any comments or suggestions are highly appreciated. 


-- 
Srinivas Kotaru

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