mirror of
https://github.com/status-im/consul.git
synced 2025-01-13 23:36:00 +00:00
/docs/architecture
This commit is contained in:
parent
76c064d1fd
commit
a95a7ec40f
@ -1,11 +1,11 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Anti-Entropy
|
||||
description: |
|
||||
This section details the process and use of anti-entropy in Consul.
|
||||
page_title: Anti-Entropy Enforcement
|
||||
description: >-
|
||||
Anti-entropy keeps distributed systems consistent. Learn how Consul uses an anti-entropy mechanism to periodically sync agent states with the service catalog to prevent either from becoming stale.
|
||||
---
|
||||
|
||||
# Anti-Entropy
|
||||
# Anti-Entropy Enforcement
|
||||
|
||||
Consul uses an advanced method of maintaining service and health information.
|
||||
This page details how services and checks are registered, how the catalog is
|
||||
|
@ -1,10 +1,8 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Consensus Protocol
|
||||
page_title: Consensus Protocol | Raft
|
||||
description: >-
|
||||
Consul uses a consensus protocol to provide Consistency as defined by CAP. The
|
||||
consensus protocol is based on Raft: In search of an Understandable Consensus
|
||||
Algorithm. For a visual explanation of Raft, see The Secret Lives of Data.
|
||||
Consul ensures consensus between server logs by using the Raft protocol to elect cluster leaders. Learn how Raft works in Consul and how consistency modes can lower consensus latency.
|
||||
---
|
||||
|
||||
# Consensus Protocol
|
||||
|
@ -1,7 +1,8 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Network Coordinates
|
||||
description: A Decentralized Network Coordinate System, with several improvements based on several follow-on papers.
|
||||
description: >-
|
||||
Network coordinates are node locations in network tomography used to estimate round trip time (RTT). Learn how network coordinates manifest in Consul, how it calculates RTT, and how to work with coordinates.
|
||||
---
|
||||
|
||||
# Network Coordinates
|
||||
|
@ -1,12 +1,8 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Gossip Protocol
|
||||
page_title: Gossip Protocol | Serf
|
||||
description: >-
|
||||
Consul uses a gossip protocol to manage membership and broadcast messages to
|
||||
the cluster. All of this is provided through the use of the Serf library. The
|
||||
gossip protocol used by Serf is based on SWIM: Scalable Weakly-consistent
|
||||
Infection-style Process Group Membership Protocol, with a few minor
|
||||
adaptations.
|
||||
Consul agents manage membership and broadcast messages using the Serf protocol. Learn about the differences between LAN and WAN gossip pools and how `serfHealth` affects health checks.
|
||||
---
|
||||
|
||||
# Gossip Protocol
|
||||
|
@ -1,16 +1,11 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Improving Consul Resilience
|
||||
page_title: Fault Tolerance
|
||||
description: >-
|
||||
Fault tolerance is the ability of a system to continue operating without interruption
|
||||
despite the failure of one or more components. Consul's resilience, or fault tolerance,
|
||||
is determined by the configuring of its voting server agents. Recommended strategies for
|
||||
increasing Consul's fault tolerance include using 3 or 5 voting server agents, spreading
|
||||
server agents across infrastructure availability zones, and using Consul Enterprise
|
||||
redundancy zones to enable backup voting servers to automatically replace lost voters.
|
||||
Fault tolerance is a system's ability to operate without interruption despite component failure. Learn how quorums provide fault tolerance and improve Consul’s resiliency when servers are deployed across redundancy and availability zones.
|
||||
---
|
||||
|
||||
# Improving Consul Resilience
|
||||
# Fault Tolerance
|
||||
|
||||
Fault tolerance is the ability of a system to continue operating without interruption
|
||||
despite the failure of one or more components.
|
||||
|
@ -1,13 +1,11 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Consul Architecture
|
||||
page_title: Consul Internals Overview
|
||||
description: >-
|
||||
Consul is a complex system that has many different moving parts. To help users
|
||||
and developers of Consul form a mental model of how it works, this page
|
||||
documents the system architecture.
|
||||
Consul datacenters consist of clusters of server agents (control plane) and client agents deployed alongside service instances (dataplane). Learn how these components and their different communication methods make Consul possible.
|
||||
---
|
||||
|
||||
# Consul Architecture
|
||||
# Consul Internals Overview
|
||||
|
||||
Consul is a complex system that has many different moving parts. To help
|
||||
users and developers of Consul form a mental model of how it works, this
|
||||
|
@ -1,14 +1,11 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Jepsen Testing
|
||||
page_title: Jepsen Testing Results
|
||||
description: >-
|
||||
Jepsen is a tool, written by Kyle Kingsbury, designed to test the partition
|
||||
tolerance of distributed systems. It creates network partitions while fuzzing
|
||||
the system with random operations. The results are analyzed to see if the
|
||||
system violates any of the consistency properties it claims to have.
|
||||
Jepsen is a tool to measure the reliability and consistency of distributed systems across network partitions. Learn about the Jepsen testing performed on Consul to ensure it can provide consistent deployments.
|
||||
---
|
||||
|
||||
# Jepsen Testing
|
||||
# Jepsen Testing Results
|
||||
|
||||
[Jepsen](http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions)
|
||||
is a tool, written by Kyle Kingsbury, designed to test the partition
|
||||
|
Loading…
x
Reference in New Issue
Block a user