consul/website/content/docs/intro/vs/skydns.mdx

46 lines
2.2 KiB
Plaintext
Raw Normal View History

---
layout: docs
2020-04-07 18:55:19 +00:00
page_title: Consul vs. SkyDNS
description: >-
SkyDNS is a tool designed to provide 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 vs. SkyDNS
2015-03-10 22:38:15 +00:00
SkyDNS is a tool designed to provide 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.
2015-03-10 22:38:15 +00:00
Consul is very similar but provides a superset 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
2015-03-10 22:38:15 +00:00
health checking framework with support for arbitrary checks and
a highly scalable failure detection scheme. SkyDNS relies on naive
2015-03-10 22:38:15 +00:00
heartbeating and TTLs, an approach which has known scalability issues.
Additionally, the heartbeat only provides a limited liveness check
versus the rich health checks that Consul performs.
2015-03-10 22:38:15 +00:00
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
2015-03-10 22:38:15 +00:00
datacenters if necessary; requests for services within a datacenter
never go over the WAN, and connectivity issues between datacenters do not
2014-04-14 18:58:40 +00:00
affect availability within a datacenter. Additionally, the unavailability
2018-01-04 21:44:07 +00:00
of one datacenter does not affect the discovery of services
2014-04-14 18:58:40 +00:00
in any other datacenter.