# Multi DC cluster or separate cluster per DC? **URL:** \ **Category:** Elasticsearch\ **Created:** [May 6, 2014, 1:51pm UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373 "2014-05-06T13:51:24Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Sebastian\_Laskawiec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebastian_laskawiec/32/1572_2.png) [@Sebastian\_Laskawiec](https://discuss.elastic.co/u/Sebastian_Laskawiec)\ **Post date:** [May 6, 2014, 1:51pm UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/1 "2014-05-06T13:51:24Z")
Hi! I'd like to ask for advice about deployment in multi DC scenario. Currently we operate on 2 Data Centers in active/standby mode. like to opeIn case of ES we'd like to have different approach - we'drate in active-active mode (we want to optimize our resources especially for querying). Here are some details about target configuration: - 4 ES instances per DC. Full cluster will have 8 instances. - Up to 1 TB of data - Data pulled from database using JDBC River - Database is replicated asynchronously between DCs. Each DC will have its own database instance to pull data. - Average latency between DCs is about several miliseconds - We need to operate when passive DC is down We know that multi DC configuration might end with Split Brain issue. Here is how we want to prevent it: - Set node.master: true only in 4 nodes in active DC - Set node.master: false in passive DC - This way we'll be sure that new cluster will not be created in passive DC - Additionally we'd like to set discovery.zen.minimum\_master\_nodes: 3 (to avoid Split Brain in active DC) Additionally there is problem with switchover (passive DC becomes active and active becomes passive). In our system it takes about 20 minutes and this is the maximum length of our maintenance window. We were thinking of shutting down whole ES cluster and switch node.master setting in configuration files (as far as I know this settings can not be changed via REST api). Then we'd need to start whole cluster. So my question is: is it better to have one big ES cluster operating on both DCs or should we change our approach and create 2 separate clusters (and rely on database replication)? I'd be grateful for advice. Regards Sebastian -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [May 7, 2014, 1:23am UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/2 "2014-05-07T01:23:43Z")
Go the latter method and have two clusters, ES can be very sensitive to network latency and you'll likely end up with more problems than it is worth. Given you already have the data source of truth being replicated, it's the sanest option to just read that locally. Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: [markw@campaignmonitor.com](mailto:markw@campaignmonitor.com) web: [www.campaignmonitor.com](http://www.campaignmonitor.com) On 6 May 2014 23:51, Sebastian Łaskawiec [sebastian.laskawiec@gmail.com](mailto:sebastian.laskawiec@gmail.com)wrote: > Hi! > > I'd like to ask for advice about deployment in multi DC scenario. > > Currently we operate on 2 Data Centers in active/standby mode. like to > opeIn case of ES we'd like to have different approach - we'drate in > active-active mode (we want to optimize our resources especially for > querying). > Here are some details about target configuration: > > - 4 ES instances per DC. Full cluster will have 8 instances. > - Up to 1 TB of data > - Data pulled from database using JDBC River > - Database is replicated asynchronously between DCs. Each DC will have > its own database instance to pull data. > - Average latency between DCs is about several miliseconds > - We need to operate when passive DC is down > > We know that multi DC configuration might end with Split Brain issue. Here > is how we want to prevent it: > > - Set node.master: true only in 4 nodes in active DC > - Set node.master: false in passive DC > - This way we'll be sure that new cluster will not be created in > passive DC > - Additionally we'd like to set discovery.zen.minimum\_master\_nodes: 3 > (to avoid Split Brain in active DC) > > Additionally there is problem with switchover (passive DC becomes active > and active becomes passive). In our system it takes about 20 minutes and > this is the maximum length of our maintenance window. We were thinking of > shutting down whole ES cluster and switch node.master setting in > configuration files (as far as I know this settings can not be changed via > REST api). Then we'd need to start whole cluster. > > So my question is: is it better to have one big ES cluster operating on > both DCs or should we change our approach and create 2 separate clusters > (and rely on database replication)? I'd be grateful for advice. > > Regards > Sebastian > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAEM624b94kkDgY5ehdwSvPkA4TaZ9QPvds%3DZHsJ%2B5DFX1\_e3xQ%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAEM624b94kkDgY5ehdwSvPkA4TaZ9QPvds%3DZHsJ%2B5DFX1_e3xQ%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Sebastian\_Laskawiec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebastian_laskawiec/32/1572_2.png) [@Sebastian\_Laskawiec](https://discuss.elastic.co/u/Sebastian_Laskawiec)\ **Post date:** [May 10, 2014, 8:05am UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/3 "2014-05-10T08:05:08Z")
Thanks for the answer! We've been talking with several other teams in our company and it looks like this is the most recommended and stable setup. Regards Sebastian W dniu środa, 7 maja 2014 03:23:43 UTC+2 użytkownik Mark Walkom napisał: > Go the latter method and have two clusters, ES can be very sensitive to > network latency and you'll likely end up with more problems than it is > worth. > Given you already have the data source of truth being replicated, it's the > sanest option to just read that locally. > > Regards, > Mark Walkom > > Infrastructure Engineer > Campaign Monitor > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com) \ > web: [www.campaignmonitor.com](http://www.campaignmonitor.com) > > On 6 May 2014 23:51, Sebastian Łaskawiec \<[sebastian...@gmail.com](mailto:sebastian...@gmail.com)\ > > > wrote: > > > Hi! > > > > I'd like to ask for advice about deployment in multi DC scenario. > > > > Currently we operate on 2 Data Centers in active/standby mode. like to > > opeIn case of ES we'd like to have different approach - we'drate in > > active-active mode (we want to optimize our resources especially for > > querying). > > Here are some details about target configuration: > > > > - 4 ES instances per DC. Full cluster will have 8 instances. > > - Up to 1 TB of data > > - Data pulled from database using JDBC River > > - Database is replicated asynchronously between DCs. Each DC will > > have its own database instance to pull data. > > - Average latency between DCs is about several miliseconds > > - We need to operate when passive DC is down > > > > We know that multi DC configuration might end with Split Brain issue. > > Here is how we want to prevent it: > > > > - Set node.master: true only in 4 nodes in active DC > > - Set node.master: false in passive DC > > - This way we'll be sure that new cluster will not be created in > > passive DC > > - Additionally we'd like to set discovery.zen.minimum\_master\_nodes: 3 > > (to avoid Split Brain in active DC) > > > > Additionally there is problem with switchover (passive DC becomes active > > and active becomes passive). In our system it takes about 20 minutes and > > this is the maximum length of our maintenance window. We were thinking of > > shutting down whole ES cluster and switch node.master setting in > > configuration files (as far as I know this settings can not be changed via > > REST api). Then we'd need to start whole cluster. > > > > So my question is: is it better to have one big ES cluster operating on > > both DCs or should we change our approach and create 2 separate clusters > > (and rely on database replication)? I'd be grateful for advice. > > > > Regards > > Sebastian > > > > -- > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/71a8db73-40bc-431d-bb9a-b581f510cf03%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/71a8db73-40bc-431d-bb9a-b581f510cf03%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![dkjhanitt](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dkjhanitt/32/1575_2.png) [@dkjhanitt](https://discuss.elastic.co/u/dkjhanitt)\ **Post date:** [May 12, 2014, 6:02pm UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/4 "2014-05-12T18:02:35Z")
Having a separate cluster is definitely a better way to go. OR, you can control the shard, replica placement so that they are always placed in the same DC. In this way, you can avoid interDC issues still having a single cluster. I have the similar issue and I am looking at it as one of the alternative. On Saturday, May 10, 2014 1:05:08 AM UTC-7, Sebastian Łaskawiec wrote: > Thanks for the answer! We've been talking with several other teams in our > company and it looks like this is the most recommended and stable setup. > > Regards > Sebastian > > W dniu środa, 7 maja 2014 03:23:43 UTC+2 użytkownik Mark Walkom napisał: > > > Go the latter method and have two clusters, ES can be very sensitive to > > network latency and you'll likely end up with more problems than it is > > worth. > > Given you already have the data source of truth being replicated, it's > > the sanest option to just read that locally. > > > > Regards, > > Mark Walkom > > > > Infrastructure Engineer > > Campaign Monitor > > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com) > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com) > > > > On 6 May 2014 23:51, Sebastian Łaskawiec [sebastian...@gmail.com](mailto:sebastian...@gmail.com) wrote: > > > > > Hi! > > > > > > I'd like to ask for advice about deployment in multi DC scenario. > > > > > > Currently we operate on 2 Data Centers in active/standby mode. like to > > > opeIn case of ES we'd like to have different approach - we'drate in > > > active-active mode (we want to optimize our resources especially for > > > querying). > > > Here are some details about target configuration: > > > > > > - 4 ES instances per DC. Full cluster will have 8 instances. > > > - Up to 1 TB of data > > > - Data pulled from database using JDBC River > > > - Database is replicated asynchronously between DCs. Each DC will > > > have its own database instance to pull data. > > > - Average latency between DCs is about several miliseconds > > > - We need to operate when passive DC is down > > > > > > We know that multi DC configuration might end with Split Brain issue. > > > Here is how we want to prevent it: > > > > > > - Set node.master: true only in 4 nodes in active DC > > > - Set node.master: false in passive DC > > > - This way we'll be sure that new cluster will not be created in > > > passive DC > > > - Additionally we'd like to set discovery.zen.minimum\_master\_nodes: > > > 3 (to avoid Split Brain in active DC) > > > > > > Additionally there is problem with switchover (passive DC becomes active > > > and active becomes passive). In our system it takes about 20 minutes and > > > this is the maximum length of our maintenance window. We were thinking of > > > shutting down whole ES cluster and switch node.master setting in > > > configuration files (as far as I know this settings can not be changed via > > > REST api). Then we'd need to start whole cluster. > > > > > > So my question is: is it better to have one big ES cluster operating on > > > both DCs or should we change our approach and create 2 separate clusters > > > (and rely on database replication)? I'd be grateful for advice. > > > > > > Regards > > > Sebastian > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/5875ae02-0cdd-4ce7-bce0-18e01bf0877a%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/5875ae02-0cdd-4ce7-bce0-18e01bf0877a%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Amit\_Soni](https://avatars.discourse-cdn.com/v4/letter/a/c0e974/32.png) [@Amit\_Soni](https://discuss.elastic.co/u/Amit_Soni)\ **Post date:** [May 14, 2014, 6:50am UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/5 "2014-05-14T06:50:34Z")
I am just wondering whether Elasticsearch team has any plans to add features for multi-data center deployment (active-active)? -Amit. On Mon, May 12, 2014 at 11:02 AM, Deepak Jha [dkjhanitt@gmail.com](mailto:dkjhanitt@gmail.com) wrote: > Having a separate cluster is definitely a better way to go. OR, you can > control the shard, replica placement so that they are always placed in the > same DC. In this way, you can avoid interDC issues still having a single > cluster. I have the similar issue and I am looking at it as one of the > alternative. > > On Saturday, May 10, 2014 1:05:08 AM UTC-7, Sebastian Łaskawiec wrote: > > > Thanks for the answer! We've been talking with several other teams in our > > company and it looks like this is the most recommended and stable setup. > > > > Regards > > Sebastian > > > > W dniu środa, 7 maja 2014 03:23:43 UTC+2 użytkownik Mark Walkom napisał: > > > > > Go the latter method and have two clusters, ES can be very sensitive to > > > network latency and you'll likely end up with more problems than it is > > > worth. > > > Given you already have the data source of truth being replicated, it's > > > the sanest option to just read that locally. > > > > > > Regards, > > > Mark Walkom > > > > > > Infrastructure Engineer > > > Campaign Monitor > > > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com) > > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com) > > > > > > On 6 May 2014 23:51, Sebastian Łaskawiec [sebastian...@gmail.com](mailto:sebastian...@gmail.com) wrote: > > > > > > > Hi! > > > > > > > > I'd like to ask for advice about deployment in multi DC scenario. > > > > > > > > Currently we operate on 2 Data Centers in active/standby mode. like to > > > > opeIn case of ES we'd like to have different approach - we'drate in > > > > active-active mode (we want to optimize our resources especially for > > > > querying). > > > > Here are some details about target configuration: > > > > > > > > - 4 ES instances per DC. Full cluster will have 8 instances. > > > > - Up to 1 TB of data > > > > - Data pulled from database using JDBC River > > > > - Database is replicated asynchronously between DCs. Each DC will > > > > have its own database instance to pull data. > > > > - Average latency between DCs is about several miliseconds > > > > - We need to operate when passive DC is down > > > > > > > > We know that multi DC configuration might end with Split Brain issue. > > > > Here is how we want to prevent it: > > > > > > > > - Set node.master: true only in 4 nodes in active DC > > > > - Set node.master: false in passive DC > > > > - This way we'll be sure that new cluster will not be created in > > > > passive DC > > > > - Additionally we'd like to set discovery.zen.minimum\_master\_nodes: > > > > 3 (to avoid Split Brain in active DC) > > > > > > > > Additionally there is problem with switchover (passive DC becomes > > > > active and active becomes passive). In our system it takes about 20 minutes > > > > and this is the maximum length of our maintenance window. We were thinking > > > > of shutting down whole ES cluster and switch node.master setting in > > > > configuration files (as far as I know this settings can not be changed via > > > > REST api). Then we'd need to start whole cluster. > > > > > > > > So my question is: is it better to have one big ES cluster operating on > > > > both DCs or should we change our approach and create 2 separate clusters > > > > (and rely on database replication)? I'd be grateful for advice. > > > > > > > > Regards > > > > Sebastian > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f% > > > > [40googlegroups.com](http://40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/5875ae02-0cdd-4ce7-bce0-18e01bf0877a%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/5875ae02-0cdd-4ce7-bce0-18e01bf0877a%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/5875ae02-0cdd-4ce7-bce0-18e01bf0877a%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/5875ae02-0cdd-4ce7-bce0-18e01bf0877a%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAAOGaQJU\_Mb2Puk9kc0KcEwZeaQj2XaFdCrUCuVMMa%2BWt\_289A%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAOGaQJU_Mb2Puk9kc0KcEwZeaQj2XaFdCrUCuVMMa%2BWt_289A%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Sebastian\_Laskawiec](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sebastian_laskawiec/32/1572_2.png) [@Sebastian\_Laskawiec](https://discuss.elastic.co/u/Sebastian_Laskawiec)\ **Post date:** [May 15, 2014, 7:23am UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/6 "2014-05-15T07:23:29Z")
We are still thinking about production configuration and here is a short list of single/separate cluster's advantages and disadvantages... Single cluster: - (+) If you have single cluster - you perform single query to the database. In case of having cluster per DC - each cluster needs to query DB separately - (+) Data consistency - in the matter of fact this is achieved by single query to the DB - (+) You can introduce new DC easily - (+) True active-active configuration - (-) Split brain and pretty complicated configuration (to avoid split brain in case when DC link is down) - (-) node.master setting can not be changed in runtime (take a look at my first post and split brain solution) - (-) In case of a disaster we need to operate on single DC. If you use single cluster per 2 DCs you can't really tell if a single DC is strong enough to handle query and indexing load - (-) In pessimistic scenario data travels through WAN 2 times (first time - database replication, second time - ES replication) - (-) You can't really tell which node will respond to the query. Let's assume that you have full index in each DC (force awareness option). ES might decide to gather results from the remote DC and not from the local one. This way you need to add WAN latency into your query time. - (-) You need to turn off whole cluster or perform cycle restarts during upgrade Separate cluster per DC: - (+) No Split brain - (+) You can tell precisely when you are out of resources to handle load in ES cluster in each DC - (+) You can experiment with different settings on production. If something goes wrong - just switch clients to standby DC. - (+) Full failover - in case of any problems - just switch to the other DC - (+) Upgrades are easy and you have no down time (upgrade first DC, stabilize it, test it, and then to the same to the other DC) - (+) Since these are 2 separate clusters you can avoid data traveling through WAN during queries. Each DC queries nodes locally. - (-) It is not a full active-active configuration. It's more like an active-standby configuration - (-) Data inconsistency might occur (different results when queried local and remote DC) - (-) Each DC will query DB separately. This will generate additional load to the DB Right now we think we should go for 2 separate clusters. DB load is a thing which worries me the most (we have really complicated query with a lot of left joins). However we think that in our case having to separate DC have more advantages then disadvantages. If you have some more arguments or comments - please let us know 🙂 Regards Sebastian W dniu poniedziałek, 12 maja 2014 20:02:35 UTC+2 użytkownik Deepak Jha napisał: > Having a separate cluster is definitely a better way to go. OR, you can > control the shard, replica placement so that they are always placed in the > same DC. In this way, you can avoid interDC issues still having a single > cluster. I have the similar issue and I am looking at it as one of the > alternative. > > On Saturday, May 10, 2014 1:05:08 AM UTC-7, Sebastian Łaskawiec wrote: > > > Thanks for the answer! We've been talking with several other teams in our > > company and it looks like this is the most recommended and stable setup. > > > > Regards > > Sebastian > > > > W dniu środa, 7 maja 2014 03:23:43 UTC+2 użytkownik Mark Walkom napisał: > > > > > Go the latter method and have two clusters, ES can be very sensitive to > > > network latency and you'll likely end up with more problems than it is > > > worth. > > > Given you already have the data source of truth being replicated, it's > > > the sanest option to just read that locally. > > > > > > Regards, > > > Mark Walkom > > > > > > Infrastructure Engineer > > > Campaign Monitor > > > email: [ma...@campaignmonitor.com](mailto:ma...@campaignmonitor.com) > > > web: [www.campaignmonitor.com](http://www.campaignmonitor.com) > > > > > > On 6 May 2014 23:51, Sebastian Łaskawiec [sebastian...@gmail.com](mailto:sebastian...@gmail.com) wrote: > > > > > > > Hi! > > > > > > > > I'd like to ask for advice about deployment in multi DC scenario. > > > > > > > > Currently we operate on 2 Data Centers in active/standby mode. like to > > > > opeIn case of ES we'd like to have different approach - we'drate in > > > > active-active mode (we want to optimize our resources especially for > > > > querying). > > > > Here are some details about target configuration: > > > > > > > > - 4 ES instances per DC. Full cluster will have 8 instances. > > > > - Up to 1 TB of data > > > > - Data pulled from database using JDBC River > > > > - Database is replicated asynchronously between DCs. Each DC will > > > > have its own database instance to pull data. > > > > - Average latency between DCs is about several miliseconds > > > > - We need to operate when passive DC is down > > > > > > > > We know that multi DC configuration might end with Split Brain issue. > > > > Here is how we want to prevent it: > > > > > > > > - Set node.master: true only in 4 nodes in active DC > > > > - Set node.master: false in passive DC > > > > - This way we'll be sure that new cluster will not be created in > > > > passive DC > > > > - Additionally we'd like to set discovery.zen.minimum\_master\_nodes: > > > > 3 (to avoid Split Brain in active DC) > > > > > > > > Additionally there is problem with switchover (passive DC becomes > > > > active and active becomes passive). In our system it takes about 20 minutes > > > > and this is the maximum length of our maintenance window. We were thinking > > > > of shutting down whole ES cluster and switch node.master setting in > > > > configuration files (as far as I know this settings can not be changed via > > > > REST api). Then we'd need to start whole cluster. > > > > > > > > So my question is: is it better to have one big ES cluster operating on > > > > both DCs or should we change our approach and create 2 separate clusters > > > > (and rely on database replication)? I'd be grateful for advice. > > > > > > > > Regards > > > > Sebastian > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/6be53754-63fd-4202-b940-750a3e0c1a8f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/2bf8598c-463d-4216-b964-068ec26b97fb%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/2bf8598c-463d-4216-b964-068ec26b97fb%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:29am UTC](https://discuss.elastic.co/t/multi-dc-cluster-or-separate-cluster-per-dc/17373/7 "2017-07-06T01:29:15Z")