One of the key features of Consul is its support for multiple datacenters. The architecture of Consul is designed to promote a low-coupling of datacenters, so that connectivity issues or failure of any datacenter does not impact the availability of Consul in other regions. This means each datacenter runs independently, with a dedicated group of servers and a private LAN gossip pool.
One of the key features of Consul is its support for multiple datacenters. The architecture of Consul is designed to promote a low-coupling of datacenters so that connectivity issues or failure of any datacenter does not impact the availability of Consul in other regions. This means each datacenter runs independently, with a dedicated group of servers and a private LAN gossip pool.
---
---
# Multi-Datacenter Deploys
# Multi-Datacenter Deploys
One of the key features of Consul is its support for multiple datacenters.
One of the key features of Consul is its support for multiple datacenters.
The [architecture](/docs/internals/architecture.html) of Consul is designed to
The [architecture](/docs/internals/architecture.html) of Consul is designed to
promote a low-coupling of datacenters, so that connectivity issues or
promote a low-coupling of datacenters so that connectivity issues or
failure of any datacenter does not impact the availability of Consul in other
failure of any datacenter does not impact the availability of Consul in other
regions. This means each datacenter runs independently, with a dedicated
regions. This means each datacenter runs independently, with a dedicated
group of servers and a private LAN [gossip pool](/docs/internals/gossip.html).
group of servers and a private LAN [gossip pool](/docs/internals/gossip.html).
Very few infrastructures are entirely self-contained, and often rely on a multitude of external service providers. Most services are registered in Consul through the use of a service definition, however that registers the local node as the service provider. In the case of external services, we want to register a service as being provided by an external provider.
Very few infrastructures are entirely self-contained. Most rely on a multitude of external service providers. Consul supports this by allowing for the definition of external services, services that are not provided by a local node.
---
---
# Registering an External Service
# Registering an External Service
Very few infrastructures are entirely self-contained, and often rely on
Very few infrastructures are entirely self-contained. Most rely on a multitude
a multitude of external service providers. Most services are registered
of external service providers. Consul supports this by allowing for the definition
in Consul through the use of a [service definition](/docs/agent/services.html),
of external services, services that are not provided by a local node.
however that registers the local node as the service provider. In the case
of external services, we want to register a service as being provided by
an external provider.
Consul supports this, however it requires manually registering the service
Most services are registered in Consul through the use of a
with the catalog. Once registered, the DNS interface will be able to return
[service definition](/docs/agent/services.html). However, this approach registers
the appropriate A records or CNAME records for the service. The service will
the local node as the service provider. In the case of external services, we must
also appear in standard queries against the API.
instead register the service with the catalog rather than as part of a standard
node service definition.
Once registered, the DNS interface will be able to return the appropriate A
records or CNAME records for the service. The service will also appear in standard
queries against the API.
Let us suppose we want to register a "search" service that is provided by
Let us suppose we want to register a "search" service that is provided by
"www.google.com", we could do the following:
"www.google.com". We might accomplish that like so: