geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb - geode - Git at Google

 ---
 title:  Multi-site (WAN) Topologies
 ---

 <!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
 -->

 To configure your multi-site topology, you should understand the recommended topologies and the topologies to avoid.

 <a id="multisite_topologies__section_26A561471249495A847B4C3854EE04C9"></a>
 This section describes <%=vars.product_name%>'s support for various topologies. Depending on your application needs, there may be several topologies that work. These are considerations to keep in mind:

 -   When a <%=vars.product_name%> site receives a message from a gateway sender, it forwards it to the other sites it knows about, excluding those sites that it knows have already seen the message. Each message contains the initial sender's ID and the ID of each of the sites the initial sender sent to, so no site forwards to those sites. However, messages do not pick up the ID of the sites they pass through, so it is possible in certain topologies for more than one copy of a message to be sent to one site.
 -   In some configurations, the loss of one site affects how other sites communicate with one another.

 ## <a id="multisite_topologies__section_7ECE1AFB1F94446FAA0A9FD504217C76" class="no-quick-link"></a>Fully Connected Mesh Topology

 A fully connected mesh network topology is one in which all sites
 know about each other.
 This is a robust configuration,
 as any one of the sites can go down without disrupting communication
 between the other sites.
 A fully connected mesh topology also guarantees that no site receives
 multiple copies of the same message.

 A fully connected mesh with three sites is shown in this figure.
 In this scenario, if site 1 sends an update to site 2,
 site 2 forwards to site 3.
 If site 1 sends an update to sites 2 and 3,
 neither forwards to the other.
 This is likewise true for any other initiating site.
 If any site is removed, the remaining two are still fully connected.

 <img src="../../images/multisite-topology-parallel.png" id="multisite_topologies__image_6CB125A80DF74DCE96A94020F7003DAE" class="image" />

 ## <a id="multisite_topologies__section_17EC1FD63A5241159FE2ED07F72CD5DC" class="no-quick-link"></a>Ring Topology

 A ring topology is one in which each site forwards information
 to one other site,
 and the sites are connected in a circular manner.
 This figure shows a ring with three sites.
 In this topology, if site 1 sends updates to site 2,
 site 2 forwards the updates to site 3.
 No updates are forwarded to the original sender,
 so site 3 does not send the updates back to site 1.

 <img src="../../images/multisite-topology-serial.png" id="multisite_topologies__image_876567BB077C4398BEFB13EEC34DA53C" class="image" />

 A ring topology guarantees that every site receives one copy of
 each message sent by any site.
 In a ring, every site must stay up to maintain the connection.
 The failure of any site breaks the ability for updates to reach
 all sites.
 If site 2 went down, for example,
 site 3 could send to site 1, but site 1 could not send to site 3.

 ## <a id="multisite_topologies__section_AA3A864753DF4C218133C0A7460D2D19" class="no-quick-link"></a>Hybrid Multi-site Topology

 There are numerous hybrid network topologies.
 Some of the sites are fully connected, while others form a ring.

 The following figure shows a hybrid topology that forms a ring,
 with an extra connection that fully connects
 sites 1 and 3.

 <img src="../../images/multisite-topology-hybrid-1.png" id="multisite_topologies__image_7656D6CEC2C947F8BFE67A0BB0BA5FDE" class="image" />

 With this hybrid topology, if site 2 went down,
 it would not affect communication between sites 1 and 3.
 If site 3 went down, however, site 2 would not be able to send to site 1.

 A second example hybrid topology is shown in the figure below.
 In this tree topology with site 1 as the root of the tree,
 sites 2 and 3 do not communicate with each another.
 This topology works for an application in which site 1 is a producer
 and the consumers (sites 2 and 3) have nothing to gain from
 being connected to each other.
 This topology also guarantees that no site receives the same update twice.

 <img src="../../images/multisite-topology-hybrid-2.png" id="multisite_topologies__image_1904C515A3224BE09589921A15D6D59B" class="image" />

 ## <a id="multisite_topologies__section_8D7912BF9D8549A491D9AE5E0DC3CC1F" class="no-quick-link"></a>Unsupported Topologies

 Topologies in which the same update may be delivered twice
 to a particular site do not work and are unsupported.

 The DAG topology shown in this figure is an example of an unsupported
 technology.
 Site 4 will receive more than one copy of the same message when
 site 1 sends a message to sites 2 and 3,
 and sites 2 and 3 each forward the message to site 4.

 <img src="../../images/multisite-topology-avoid-3.png" id="multisite_topologies__image_710EB20403C942D0B756F9D22B3359A6" class="image" />
	---
	title: Multi-site (WAN) Topologies
	---

	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	To configure your multi-site topology, you should understand the recommended topologies and the topologies to avoid.

	<a id="multisite_topologies__section_26A561471249495A847B4C3854EE04C9"></a>
	This section describes <%=vars.product_name%>'s support for various topologies. Depending on your application needs, there may be several topologies that work. These are considerations to keep in mind:

	- When a <%=vars.product_name%> site receives a message from a gateway sender, it forwards it to the other sites it knows about, excluding those sites that it knows have already seen the message. Each message contains the initial sender's ID and the ID of each of the sites the initial sender sent to, so no site forwards to those sites. However, messages do not pick up the ID of the sites they pass through, so it is possible in certain topologies for more than one copy of a message to be sent to one site.
	- In some configurations, the loss of one site affects how other sites communicate with one another.

	## <a id="multisite_topologies__section_7ECE1AFB1F94446FAA0A9FD504217C76" class="no-quick-link"></a>Fully Connected Mesh Topology

	A fully connected mesh network topology is one in which all sites
	know about each other.
	This is a robust configuration,
	as any one of the sites can go down without disrupting communication
	between the other sites.
	A fully connected mesh topology also guarantees that no site receives
	multiple copies of the same message.

	A fully connected mesh with three sites is shown in this figure.
	In this scenario, if site 1 sends an update to site 2,
	site 2 forwards to site 3.
	If site 1 sends an update to sites 2 and 3,
	neither forwards to the other.
	This is likewise true for any other initiating site.
	If any site is removed, the remaining two are still fully connected.

	<img src="../../images/multisite-topology-parallel.png" id="multisite_topologies__image_6CB125A80DF74DCE96A94020F7003DAE" class="image" />

	## <a id="multisite_topologies__section_17EC1FD63A5241159FE2ED07F72CD5DC" class="no-quick-link"></a>Ring Topology

	A ring topology is one in which each site forwards information
	to one other site,
	and the sites are connected in a circular manner.
	This figure shows a ring with three sites.
	In this topology, if site 1 sends updates to site 2,
	site 2 forwards the updates to site 3.
	No updates are forwarded to the original sender,
	so site 3 does not send the updates back to site 1.

	<img src="../../images/multisite-topology-serial.png" id="multisite_topologies__image_876567BB077C4398BEFB13EEC34DA53C" class="image" />

	A ring topology guarantees that every site receives one copy of
	each message sent by any site.
	In a ring, every site must stay up to maintain the connection.
	The failure of any site breaks the ability for updates to reach
	all sites.
	If site 2 went down, for example,
	site 3 could send to site 1, but site 1 could not send to site 3.

	## <a id="multisite_topologies__section_AA3A864753DF4C218133C0A7460D2D19" class="no-quick-link"></a>Hybrid Multi-site Topology

	There are numerous hybrid network topologies.
	Some of the sites are fully connected, while others form a ring.

	The following figure shows a hybrid topology that forms a ring,
	with an extra connection that fully connects
	sites 1 and 3.

	<img src="../../images/multisite-topology-hybrid-1.png" id="multisite_topologies__image_7656D6CEC2C947F8BFE67A0BB0BA5FDE" class="image" />

	With this hybrid topology, if site 2 went down,
	it would not affect communication between sites 1 and 3.
	If site 3 went down, however, site 2 would not be able to send to site 1.

	A second example hybrid topology is shown in the figure below.
	In this tree topology with site 1 as the root of the tree,
	sites 2 and 3 do not communicate with each another.
	This topology works for an application in which site 1 is a producer
	and the consumers (sites 2 and 3) have nothing to gain from
	being connected to each other.
	This topology also guarantees that no site receives the same update twice.

	<img src="../../images/multisite-topology-hybrid-2.png" id="multisite_topologies__image_1904C515A3224BE09589921A15D6D59B" class="image" />

	## <a id="multisite_topologies__section_8D7912BF9D8549A491D9AE5E0DC3CC1F" class="no-quick-link"></a>Unsupported Topologies

	Topologies in which the same update may be delivered twice
	to a particular site do not work and are unsupported.

	The DAG topology shown in this figure is an example of an unsupported
	technology.
	Site 4 will receive more than one copy of the same message when
	site 1 sends a message to sites 2 and 3,
	and sites 2 and 3 each forward the message to site 4.

	<img src="../../images/multisite-topology-avoid-3.png" id="multisite_topologies__image_710EB20403C942D0B756F9D22B3359A6" class="image" />