Merge pull request #13914 from hashicorp/docs/remove-comparisons-from-ref-docs
docs: remove comparative info from ref docs site
This commit is contained in:
Jared Kirschner
GitHub
commit
39480deed0
|
|
@ -115,7 +115,5 @@ forward the request to the remote datacenter and return the result.
|
|||
|
||||
## Next Steps
|
||||
|
||||
- See [how Consul compares to other software](/docs/intro/vs) to assess how it fits into your
|
||||
existing infrastructure.
|
||||
- Continue onwards with [HashiCorp Learn](https://learn.hashicorp.com/tutorials/consul/get-started-install)
|
||||
to learn more about Consul and how to get Consul up and running.
|
||||
Continue onwards with [HashiCorp Learn](https://learn.hashicorp.com/tutorials/consul/get-started-install)
|
||||
to learn more about Consul and how to get Consul up and running.
|
||||
|
|
|
|||
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: 'Consul vs. Chef, Puppet, etc.'
|
||||
description: >-
|
||||
It is not uncommon to find people using Chef, Puppet, and other configuration
|
||||
management tools to build service discovery mechanisms. This is usually done
|
||||
by querying global state to construct configuration files on each node during
|
||||
a periodic convergence run.
|
||||
---
|
||||
|
||||
# Consul vs. Chef, Puppet, etc.
|
||||
|
||||
It is not uncommon to find people using Chef, Puppet, and other configuration
|
||||
management tools to build service discovery mechanisms. This is usually
|
||||
done by querying global state to construct configuration files on each
|
||||
node during a periodic convergence run.
|
||||
|
||||
Unfortunately, this approach has
|
||||
a number of pitfalls. The configuration information is static
|
||||
and cannot update any more frequently than convergence runs. Generally this
|
||||
is on the interval of many minutes or hours. Additionally, there is no
|
||||
mechanism to incorporate the system state in the configuration: nodes which
|
||||
are unhealthy may receive traffic exacerbating issues further. Using this
|
||||
approach also makes supporting multiple datacenters challenging as a central
|
||||
group of servers must manage all datacenters.
|
||||
|
||||
Consul is designed specifically as a service discovery tool. As such,
|
||||
it is much more dynamic and responsive to the state of the cluster. Nodes
|
||||
can register and deregister the services they provide, enabling dependent
|
||||
applications and services to rapidly discover all providers. By using the
|
||||
integrated health checking, Consul can route traffic away from unhealthy
|
||||
nodes, allowing systems and services to gracefully recover. Static configuration
|
||||
that may be provided by configuration management tools can be moved into the
|
||||
dynamic key/value store. This allows application configuration to be updated
|
||||
without a slow convergence run. Lastly, because each datacenter runs independently,
|
||||
supporting multiple datacenters is no different than a single datacenter.
|
||||
|
||||
That said, Consul is not a replacement for configuration management tools.
|
||||
These tools are still critical to set up applications, including Consul itself.
|
||||
Static provisioning is best managed by existing tools while dynamic state and
|
||||
discovery is better managed by Consul. The separation of configuration management
|
||||
and cluster management also has a number of advantageous side effects: Chef recipes
|
||||
and Puppet manifests become simpler without global state, periodic runs are no longer
|
||||
required for service or configuration changes, and the infrastructure can become
|
||||
immutable since config management runs require no global state.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. Custom Solutions
|
||||
description: >-
|
||||
As a codebase grows, a monolithic app often evolves into a Service Oriented
|
||||
Architecture (SOA). A universal pain point for SOA is service discovery and
|
||||
configuration. In many cases, this leads to organizations building home grown
|
||||
solutions. It is an undisputed fact that distributed systems are hard;
|
||||
building one is error-prone and time-consuming. Most systems cut corners by
|
||||
introducing single points of failure such as a single Redis or RDBMS to
|
||||
maintain cluster state. These solutions may work in the short term, but they
|
||||
are rarely fault tolerant or scalable. Besides these limitations, they require
|
||||
time and resources to build and maintain.
|
||||
---
|
||||
|
||||
# Consul vs. Custom Solutions
|
||||
|
||||
As a codebase grows, a monolithic app often evolves into a Service Oriented
|
||||
Architecture (SOA). A universal pain point for SOA is service discovery and
|
||||
configuration. In many cases, this leads to organizations building home grown
|
||||
solutions. It is an undisputed fact that distributed systems are hard; building
|
||||
one is error-prone and time-consuming. Most systems cut corners by introducing
|
||||
single points of failure such as a single Redis or RDBMS to maintain cluster
|
||||
state. These solutions may work in the short term, but they are rarely fault
|
||||
tolerant or scalable. Besides these limitations, they require time and resources
|
||||
to build and maintain.
|
||||
|
||||
Consul provides the core set of features needed by an SOA out of the box. By
|
||||
using Consul, organizations can leverage open source work to reduce the time
|
||||
and effort spent re-inventing the wheel and can focus instead on their business
|
||||
applications.
|
||||
|
||||
Consul is built on well-cited research and is designed with the constraints of
|
||||
distributed systems in mind. At every step, Consul takes efforts to provide a
|
||||
robust and scalable solution for organizations of any size.
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. Eureka
|
||||
description: >-
|
||||
Eureka is a service discovery tool that provides a best effort registry and
|
||||
discovery service. It uses central servers and clients which are typically
|
||||
natively integrated with SDKs. Consul provides a super set of features, such
|
||||
as health checking, key/value storage, ACLs, and multi-datacenter awareness.
|
||||
---
|
||||
|
||||
# Consul vs. Eureka
|
||||
|
||||
Eureka is a service discovery tool. The architecture is primarily client/server,
|
||||
with a set of Eureka servers per datacenter, usually one per availability zone.
|
||||
Typically clients of Eureka use an embedded SDK to register and discover services.
|
||||
For clients that are not natively integrated, a sidecar such as Ribbon is used
|
||||
to transparently discover services via Eureka.
|
||||
|
||||
Eureka provides a weakly consistent view of services, using best effort replication.
|
||||
When a client registers with a server, that server will make an attempt to replicate
|
||||
to the other servers but provides no guarantee. Service registrations have a short
|
||||
Time-To-Live (TTL), requiring clients to heartbeat with the servers. Unhealthy services
|
||||
or nodes will stop heartbeating, causing them to timeout and be removed from the registry.
|
||||
Discovery requests can route to any service, which can serve stale or missing data due to
|
||||
the best effort replication. This simplified model allows for easy cluster administration
|
||||
and high scalability.
|
||||
|
||||
Consul provides a super set of features, including richer health checking, key/value store,
|
||||
and multi-datacenter awareness. Consul requires a set of servers in each datacenter, along
|
||||
with an agent on each client, similar to using a sidecar like Ribbon. The Consul agent allows
|
||||
most applications to be Consul unaware, performing the service registration via configuration
|
||||
files and discovery via DNS or load balancer sidecars.
|
||||
|
||||
Consul provides a strong consistency guarantee, since servers replicate state using the
|
||||
[Raft protocol](/docs/architecture/consensus). Consul supports a rich set of health checks
|
||||
including TCP, HTTP, Nagios/Sensu compatible scripts, or TTL based like Eureka. Client nodes
|
||||
participate in a [gossip based health check](/docs/architecture/gossip), which distributes
|
||||
the work of health checking, unlike centralized heartbeating which becomes a scalability challenge.
|
||||
Discovery requests are routed to the elected Consul leader which allows them to be strongly consistent
|
||||
by default. Clients that allow for stale reads enable any server to process their request allowing
|
||||
for linear scalability like Eureka.
|
||||
|
||||
The strongly consistent nature of Consul means it can be used as a locking service for leader
|
||||
elections and cluster coordination. Eureka does not provide similar guarantees, and typically
|
||||
requires running ZooKeeper for services that need to perform coordination or have stronger
|
||||
consistency needs.
|
||||
|
||||
Consul provides a toolkit of features needed to support a service oriented architecture.
|
||||
This includes service discovery, but also rich health checking, locking, Key/Value, multi-datacenter
|
||||
federation, an event system, and ACLs. Both Consul and the ecosystem of tools like consul-template
|
||||
and envconsul try to minimize application changes required to integration, to avoid needing
|
||||
native integration via SDKs. Eureka is part of a larger Netflix OSS suite, which expects applications
|
||||
to be relatively homogeneous and tightly integrated. As a result, Eureka only solves a limited
|
||||
subset of problems, expecting other tools such as ZooKeeper to be used alongside.
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. Other Software
|
||||
description: >-
|
||||
The problems Consul solves are varied, but each individual feature has been
|
||||
solved by many different systems. Although there is no single system that
|
||||
provides all the features of Consul, there are other options available to
|
||||
solve some of these problems.
|
||||
---
|
||||
|
||||
# Consul vs. Other Software
|
||||
|
||||
The problems Consul solves are varied, but each individual feature has been
|
||||
solved by many different systems. Although there is no single system that
|
||||
provides all the features of Consul, there are other options available to solve
|
||||
some of these problems.
|
||||
|
||||
In this section, we compare Consul to some other options. In most cases, Consul
|
||||
is not mutually exclusive with any other system.
|
||||
|
||||
Use the navigation to the left to read the comparison of Consul to specific
|
||||
systems.
|
||||
|
|
@ -1,80 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. Istio
|
||||
description: >-
|
||||
Istio is a platform for connecting and securing microservices. This page
|
||||
describes the similarities and differences between Istio and Consul.
|
||||
---
|
||||
|
||||
# Consul vs. Istio
|
||||
|
||||
Istio is an open platform to connect, manage, and secure microservices.
|
||||
|
||||
To enable the full functionality of Istio, multiple services must
|
||||
be deployed. For the control plane: Pilot, Mixer, and Citadel must be
|
||||
deployed and for the data plane an Envoy sidecar is deployed. Additionally,
|
||||
Istio requires a 3rd party service catalog from Kubernetes, Consul, Eureka,
|
||||
or others. Finally, Istio requires an external system for storing state,
|
||||
typically etcd. At a minimum, three Istio-dedicated services along with at
|
||||
least one separate distributed system (in addition to Istio) must be
|
||||
configured to use the full functionality of Istio.
|
||||
|
||||
Istio provides layer 7 features for path-based routing, traffic shaping,
|
||||
load balancing, and telemetry. Access control policies can be configured
|
||||
targeting both layer 7 and layer 4 properties to control access, routing,
|
||||
and more based on service identity.
|
||||
|
||||
Consul is a single binary providing both server and client capabilities, and
|
||||
includes all functionality for service catalog, configuration, TLS certificates,
|
||||
authorization, and more. No additional systems need to be installed to use
|
||||
Consul, although Consul optionally supports external systems such as Vault
|
||||
to augment behavior. This architecture enables Consul to be easily installed
|
||||
on any platform, including directly onto the machine.
|
||||
|
||||
Consul uses an agent-based model where each node in the cluster runs a
|
||||
Consul Client. This client maintains a local cache that is efficiently updated
|
||||
from servers. As a result, all secure service communication APIs respond in
|
||||
microseconds and do not require any external communication. This allows us to
|
||||
do connection enforcement at the edge without communicating to central
|
||||
servers. Istio flows requests to a central Mixer service and must push
|
||||
updates out via Pilot. This dramatically reduces the scalability of Istio,
|
||||
whereas Consul is able to efficiently distribute updates and perform all
|
||||
work on the edge.
|
||||
|
||||
Consul provides layer 7 features for path-based routing, traffic shifting,
|
||||
load balancing, and telemetry. Consul enforces authorization and identity to
|
||||
layer 4 only — either the TLS connection can be established or it can't.
|
||||
We believe service identity should be tied to layer 4, whereas layer 7 should be
|
||||
used for routing, telemetry, etc. We will be adding more layer 7 features to Consul in the future.
|
||||
|
||||
The data plane for Consul is pluggable. It includes a built-in proxy with
|
||||
a larger performance trade off for ease of use. But you may also use third
|
||||
party proxies such as Envoy to leverage layer 7 features. The ability to use the
|
||||
right proxy for the job allows flexible heterogeneous deployments where
|
||||
different proxies may be more correct for the applications they're proxying. We
|
||||
encourage users leverage the pluggable data plane layer and use a proxy which
|
||||
supports the layer 7 features necessary for the cluster.
|
||||
|
||||
In addition to third party proxy support, applications can natively integrate
|
||||
with the Connect protocol. As a result, the performance overhead of introducing
|
||||
Connect is negligible. These "Connect-native" applications can interact with
|
||||
any other Connect-capable services, whether they're using a proxy or are
|
||||
also Connect-native.
|
||||
|
||||
Consul implements automatic TLS certificate management complete with rotation
|
||||
support. Both leaf and root certificates can be rotated automatically across
|
||||
a large Consul cluster with zero disruption to connections. The certificate
|
||||
management system is pluggable through code change in Consul and will be
|
||||
exposed as an external plugin system shortly. This enables Consul to work
|
||||
with any PKI solution.
|
||||
|
||||
Because Consul's service connection feature "Connect" is built-in, it
|
||||
inherits the operational stability of Consul. Consul has been in production
|
||||
for large companies since 2014 and is known to be deployed on as many as
|
||||
50,000 nodes in a single cluster.
|
||||
|
||||
This comparison is based on our own limited usage of Istio as well as
|
||||
talking to Istio users. If you feel there are inaccurate statements in this
|
||||
comparison, please click "Edit This Page" in the footer of this page and
|
||||
propose edits. We strive for technical accuracy and will review and update
|
||||
this post for inaccuracies as quickly as possible.
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: 'Consul vs. Nagios'
|
||||
description: >-
|
||||
Nagios is a tool built for monitoring. It is used to quickly
|
||||
notify operators when an issue occurs.
|
||||
---
|
||||
|
||||
# Consul vs. Nagios
|
||||
|
||||
Nagios is a tool built for monitoring. It is used to quickly notify
|
||||
operators when an issue occurs.
|
||||
|
||||
Nagios uses a group of central servers that are configured to perform
|
||||
checks on remote hosts. This design makes it difficult to scale Nagios,
|
||||
as large fleets quickly reach the limit of vertical scaling, and Nagios
|
||||
does not easily scale horizontally. Nagios is also notoriously
|
||||
difficult to use with modern DevOps and configuration management tools,
|
||||
as local configurations must be updated when remote servers are added
|
||||
or removed.
|
||||
|
||||
Consul provides the same health checking abilities as Nagios,
|
||||
is friendly to modern DevOps, and avoids the inherent scaling issues.
|
||||
Consul runs all checks locally, avoiding placing a burden on central servers.
|
||||
The status of checks is maintained by the Consul servers, which are fault
|
||||
tolerant and have no single point of failure. Lastly, Consul can scale to
|
||||
vastly more checks because it relies on edge-triggered updates. This means
|
||||
that an update is only triggered when a check transitions from "passing"
|
||||
to "failing" or vice versa.
|
||||
|
||||
In a large fleet, the majority of checks are passing, and even the minority
|
||||
that are failing are persistent. By capturing changes only, Consul reduces
|
||||
the amount of networking and compute resources used by the health checks,
|
||||
allowing the system to be much more scalable.
|
||||
|
||||
An astute reader may notice that if a Consul agent dies, then no edge triggered
|
||||
updates will occur. From the perspective of other nodes, all checks will appear
|
||||
to be in a steady state. However, Consul guards against this as well. The
|
||||
[gossip protocol](/docs/architecture/gossip) used between clients and servers
|
||||
integrates a distributed failure detector. This means that if a Consul agent fails,
|
||||
the failure will be detected, and thus all checks being run by that node can be
|
||||
assumed failed. This failure detector distributes the work among the entire cluster
|
||||
while, most importantly, enabling the edge triggered architecture to work.
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. Envoy and Other Proxies
|
||||
description: >-
|
||||
Modern service proxies provide high-level service routing, authentication,
|
||||
telemetry, and more for microservice and cloud environments. Envoy is a
|
||||
popular and feature rich proxy. This page describes how Consul relates to
|
||||
proxies such as Envoy.
|
||||
---
|
||||
|
||||
# Consul vs. Envoy and Other Proxies
|
||||
|
||||
Modern service proxies provide high-level service routing, authentication,
|
||||
telemetry, and more for microservice and cloud environments. Envoy is
|
||||
a popular and feature-rich proxy that is often
|
||||
used on its own. Consul [integrates with Envoy](/docs/connect/proxies/envoy) to simplify its configuration.
|
||||
|
||||
Proxies require a rich set of configuration to operate since backend
|
||||
addresses, frontend listeners, routes, filters, telemetry shipping, and
|
||||
more must all be configured. Further, a modern infrastructure contains
|
||||
many proxies, often one proxy per service as proxies are deployed in
|
||||
a "sidecar" model next to a service. Therefore, a primary challenge of
|
||||
proxies is the configuration sprawl and orchestration.
|
||||
|
||||
Proxies form what is referred to as the "data plane": the pathway which
|
||||
data travels for network connections. Above this is the "control plane"
|
||||
which provides the rules and configuration for the data plane. Proxies
|
||||
typically integrate with outside solutions to provide the control plane.
|
||||
For example, Envoy integrates with Consul to dynamically populate
|
||||
service backend addresses.
|
||||
|
||||
Consul is a control plane solution. The service catalog serves as a registry
|
||||
for services and their addresses and can be used to route traffic for proxies.
|
||||
The Connect feature of Consul provides the TLS certificates and service
|
||||
access graph, but still requires a proxy to exist in the data path. As a
|
||||
control plane, Consul integrates with many data plane solutions including
|
||||
Envoy, HAProxy, Nginx, and more.
|
||||
|
||||
The [Consul Envoy integration](/docs/connect/proxies/envoy)
|
||||
is currently the primary way to utilize advanced layer 7 features provided
|
||||
by Consul. In addition to Envoy, Consul enables
|
||||
third party proxies to integrate with Connect and provide the data
|
||||
plane with Consul operating as the control plane.
|
||||
|
||||
Proxies provide excellent solutions to layer 7 concerns such as path-based
|
||||
routing, tracing and telemetry, and more. By supporting a pluggable data plane model, the right proxy can be
|
||||
deployed as needed.
|
||||
For performance-critical applications or those
|
||||
that utilize layer 7 functionality, Envoy can be used. For non-performance critical layer 4 applications, you can use Consul's [built-in proxy](/docs/connect/proxies/built-in) for convenience.
|
||||
|
||||
For some applications that may require hardware, a hardware load balancer
|
||||
such as an F5 appliance may be deployed. Consul encourages this use of the right
|
||||
proxy for the scenario and treats hardware load balancers as swappable components that can be run
|
||||
alongside other proxies, assuming they integrate with the [necessary APIs](/docs/connect/proxies/integrate)
|
||||
for Connect.
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. Serf
|
||||
description: >-
|
||||
Serf is a node discovery and orchestration tool and is the only tool discussed
|
||||
so far that is built on an eventually-consistent gossip model with no
|
||||
centralized servers. It provides a number of features, including group
|
||||
membership, failure detection, event broadcasts, and a query mechanism.
|
||||
However, Serf does not provide any high-level features such as service
|
||||
discovery, health checking or key/value storage. Consul is a complete system
|
||||
providing all of those features.
|
||||
---
|
||||
|
||||
# Consul vs. Serf
|
||||
|
||||
[Serf](https://www.serf.io) is a node discovery and orchestration tool and is the only
|
||||
tool discussed so far that is built on an eventually-consistent gossip model
|
||||
with no centralized servers. It provides a number of features, including group
|
||||
membership, failure detection, event broadcasts, and a query mechanism. However,
|
||||
Serf does not provide any high-level features such as service discovery, health
|
||||
checking or key/value storage. Consul is a complete system providing all of those
|
||||
features.
|
||||
|
||||
The internal [gossip protocol](/docs/architecture/gossip) used within Consul is in
|
||||
fact powered by the Serf library: Consul leverages the membership and failure detection
|
||||
features and builds upon them to add service discovery. By contrast, the discovery
|
||||
feature of Serf is at a node level, while Consul provides a service and node level
|
||||
abstraction.
|
||||
|
||||
The health checking provided by Serf is very low level and only indicates if the
|
||||
agent is alive. Consul extends this to provide a rich health checking system
|
||||
that handles liveness in addition to arbitrary host and service-level checks.
|
||||
Health checks are integrated with a central catalog that operators can easily
|
||||
query to gain insight into the cluster.
|
||||
|
||||
The membership provided by Serf is at a node level, while Consul focuses
|
||||
on the service level abstraction, mapping single nodes to multiple services.
|
||||
This can be simulated in Serf using tags, but it is much more limited and does
|
||||
not provide useful query interfaces. Consul also makes use of a strongly-consistent
|
||||
catalog while Serf is only eventually-consistent.
|
||||
|
||||
In addition to the service level abstraction and improved health checking,
|
||||
Consul provides a key/value store and support for multiple datacenters.
|
||||
Serf can run across the WAN but with degraded performance. Consul makes use
|
||||
of [multiple gossip pools](/docs/architecture) so that
|
||||
the performance of Serf over a LAN can be retained while still using it over
|
||||
a WAN for linking together multiple datacenters.
|
||||
|
||||
Consul is opinionated in its usage while Serf is a more flexible and
|
||||
general purpose tool. In [CAP](https://en.wikipedia.org/wiki/CAP_theorem) terms,
|
||||
Consul uses a CP architecture, favoring consistency over availability. Serf is an
|
||||
AP system and sacrifices consistency for availability. This means Consul cannot
|
||||
operate if the central servers cannot form a quorum while Serf will continue to
|
||||
function under almost all circumstances.
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
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
|
||||
|
||||
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 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
|
||||
health checking framework with support for arbitrary checks and
|
||||
a highly scalable failure detection scheme. SkyDNS relies on naive
|
||||
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.
|
||||
|
||||
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; requests for services within a datacenter
|
||||
never go over the WAN, and connectivity issues between datacenters do not
|
||||
affect availability within a datacenter. Additionally, the unavailability
|
||||
of one datacenter does not affect the discovery of services
|
||||
in any other datacenter.
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul vs. SmartStack
|
||||
description: >-
|
||||
SmartStack is a tool which tackles the service discovery problem. It has a
|
||||
rather unique architecture and has 4 major components: ZooKeeper, HAProxy,
|
||||
Synapse, and Nerve. The ZooKeeper servers are responsible for storing cluster
|
||||
state in a consistent and fault-tolerant manner. Each node in the SmartStack
|
||||
cluster then runs both Nerves and Synapses. The Nerve is responsible for
|
||||
running health checks against a service and registering with the ZooKeeper
|
||||
servers. Synapse queries ZooKeeper for service providers and dynamically
|
||||
configures HAProxy. Finally, clients speak to HAProxy, which does health
|
||||
checking and load balancing across service providers.
|
||||
---
|
||||
|
||||
# Consul vs. SmartStack
|
||||
|
||||
SmartStack is a tool which tackles the service discovery problem. It has a rather
|
||||
unique architecture and has 4 major components: ZooKeeper, HAProxy, Synapse, and Nerve.
|
||||
The ZooKeeper servers are responsible for storing cluster state in a consistent and
|
||||
fault-tolerant manner. Each node in the SmartStack cluster then runs both Nerves and
|
||||
Synapses. The Nerve is responsible for running health checks against a service and
|
||||
registering with the ZooKeeper servers. Synapse queries ZooKeeper for service providers
|
||||
and dynamically configures HAProxy. Finally, clients speak to HAProxy, which does
|
||||
health checking and load balancing across service providers.
|
||||
|
||||
Consul is a much simpler and more contained system as it does not rely on any external
|
||||
components. Consul uses an integrated [gossip protocol](/docs/architecture/gossip)
|
||||
to track all nodes and perform server discovery. This means that server addresses
|
||||
do not need to be hardcoded and updated fleet-wide on changes, unlike SmartStack.
|
||||
|
||||
Service registration for both Consul and Nerves can be done with a configuration file,
|
||||
but Consul also supports an API to dynamically change the services and checks that are
|
||||
in use.
|
||||
|
||||
For discovery, SmartStack clients must use HAProxy, requiring that Synapse be
|
||||
configured with all desired endpoints in advance. Consul clients instead
|
||||
use the DNS or HTTP APIs without any configuration needed in advance. Consul
|
||||
also provides a "tag" abstraction, allowing services to provide metadata such
|
||||
as versions, primary/secondary designations, or opaque labels that can be used for
|
||||
filtering. Clients can then request only the service providers which have
|
||||
matching tags.
|
||||
|
||||
The systems also differ in how they manage health checking. Nerve performs local health
|
||||
checks in a manner similar to Consul agents. However, Consul maintains separate catalog
|
||||
and health systems. This division allows operators to see which nodes are in each service
|
||||
pool and provides insight into failing checks. Nerve simply deregisters nodes on failed
|
||||
checks, providing limited operational insight. Synapse also configures HAProxy to perform
|
||||
additional health checks. This causes all potential service clients to check for
|
||||
liveness. With large fleets, this N-to-N style health checking may be prohibitively
|
||||
expensive.
|
||||
|
||||
Consul generally provides a much richer health checking system. Consul supports
|
||||
Nagios-style plugins, enabling a vast catalog of checks to be used. Consul allows for
|
||||
both service- and host-level checks. There is even a "dead man's switch" check that allows
|
||||
applications to easily integrate custom health checks. Finally, all of this is integrated
|
||||
into a Health and Catalog system with APIs enabling operators to gain insight into the
|
||||
broader system.
|
||||
|
||||
In addition to the service discovery and health checking, Consul also provides
|
||||
an integrated key/value store for configuration and multi-datacenter support.
|
||||
While it may be possible to configure SmartStack for multiple datacenters,
|
||||
the central ZooKeeper cluster would be a serious impediment to a fault-tolerant
|
||||
deployment.
|
||||
|
|
@ -19,51 +19,6 @@
|
|||
"path": "intro/usecases/what-is-a-service-mesh"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "Consul vs. Other Software",
|
||||
"routes": [
|
||||
{
|
||||
"title": "Overview",
|
||||
"path": "intro/vs"
|
||||
},
|
||||
{
|
||||
"title": "Chef, Puppet, etc.",
|
||||
"path": "intro/vs/chef-puppet"
|
||||
},
|
||||
{
|
||||
"title": "Nagios",
|
||||
"path": "intro/vs/nagios"
|
||||
},
|
||||
{
|
||||
"title": "SkyDNS",
|
||||
"path": "intro/vs/skydns"
|
||||
},
|
||||
{
|
||||
"title": "SmartStack",
|
||||
"path": "intro/vs/smartstack"
|
||||
},
|
||||
{
|
||||
"title": "Serf",
|
||||
"path": "intro/vs/serf"
|
||||
},
|
||||
{
|
||||
"title": "Eureka",
|
||||
"path": "intro/vs/eureka"
|
||||
},
|
||||
{
|
||||
"title": "Istio",
|
||||
"path": "intro/vs/istio"
|
||||
},
|
||||
{
|
||||
"title": "Envoy and Other Proxies",
|
||||
"path": "intro/vs/proxies"
|
||||
},
|
||||
{
|
||||
"title": "Custom Solutions",
|
||||
"path": "intro/vs/custom"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
|
|
@ -291,52 +291,6 @@ module.exports = [
|
|||
permanent: true,
|
||||
},
|
||||
{ source: '/intro', destination: '/docs/intro', permanent: true },
|
||||
{ source: '/intro/vs', destination: '/docs/intro/vs', permanent: true },
|
||||
{
|
||||
source: '/intro/vs/chef-puppet',
|
||||
destination: '/docs/intro/vs/chef-puppet',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/nagios',
|
||||
destination: '/docs/intro/vs/nagios',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/skydns',
|
||||
destination: '/docs/intro/vs/skydns',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/smartstack',
|
||||
destination: '/docs/intro/vs/smartstack',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/serf',
|
||||
destination: '/docs/intro/vs/serf',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/eureka',
|
||||
destination: '/docs/intro/vs/eureka',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/istio',
|
||||
destination: '/docs/intro/vs/istio',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/proxies',
|
||||
destination: '/docs/intro/vs/proxies',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/intro/vs/custom',
|
||||
destination: '/docs/intro/vs/custom',
|
||||
permanent: true,
|
||||
},
|
||||
{
|
||||
source: '/docs/k8s/ambassador',
|
||||
destination:
|
||||
|
|
|
|||
Loading…
Reference in New Issue