mirror of https://github.com/hashicorp/consul
40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
|
---
|
||
|
|
layout: "intro"
|
||
|
|
page_title: "Consul vs. SkyDNS"
|
||
|
|
sidebar_current: "vs-other-skydns"
|
||
|
|
---
|
||
|
|
|
||
|
|
# Consul vs. SkyDNS
|
||
|
|
|
||
|
|
SkyDNS is a relatively new tool designed to solve service discovery.
|
||
|
|
It uses multiple central servers that are strongly consistent and
|
||
|
|
fault tolerant. Nodes register services using an HTTP API, and
|
||
|
|
queries can be made over HTTP or DNS to perform discovery.
|
||
|
|
|
||
|
|
Consul is very similar, but provides a super-set of features. Consul
|
||
|
|
also relies on multiple central servers to provide strong consistency
|
||
|
|
and fault tolerance. Nodes can use an HTTP API or use an agent to
|
||
|
|
register services, and queries are made over HTTP or DNS.
|
||
|
|
|
||
|
|
However, the systems differ in many ways. Consul provides a much richer
|
||
|
|
health checking framework, with support for arbitrary checks and
|
||
|
|
a highly scalable failure detection scheme. SkyDNS relies on naive
|
||
|
|
heartbeating and TTLs, which have known scalability issues. Additionally,
|
||
|
|
the heartbeat only provides a limited liveness check.
|
||
|
|
|
||
|
|
Multiple datacenters can be supported by using "regions" in SkyDNS,
|
||
|
|
however the data is managed and queried from a single cluster. If servers
|
||
|
|
are split between datacenters the replication protocol will suffer from
|
||
|
|
very long commit times. If all the SkyDNS servers are in a central datacenter, then
|
||
|
|
connectivity issues can cause entire datacenters to lose availability.
|
||
|
|
Additionally, even without a connectivity issue, query performance will
|
||
|
|
suffer as requests must always be performed in a remote datacenter.
|
||
|
|
|
||
|
|
Consul supports multiple datacenters out of the box, and it purposely
|
||
|
|
scopes the managed data to be per-datacenter. This means each datacenter
|
||
|
|
runs an independent cluster of servers. Requests are forwarded to remote
|
||
|
|
datacenters if necessary. This means requests for services within a datacenter
|
||
|
|
never go over the WAN, and connectivity issues between datacenters do not
|
||
|
|
affect availability within a datacenter.
|
||
|
|
|