Merge pull request #7495 from hashicorp/3242020-ent-docs-update

updating enterprise documentation with additional clarity

website/source/docs/enterprise/backups/index.html.md

@@ -3,17 +3,31 @@ layout: "docs"
 page_title: "Consul Enterprise Automated Backups"
 sidebar_current: "docs-enterprise-backups"
 description: |-
-  Consul Enterprise provides a highly available service that manages taking snapshots, rotation and sending backup files offsite to Amazon S3 (or another S3-compatible endpoint).
+  Consul Enterprise provides a highly available service that manages taking snapshots, rotation and sending backup files offsite to Amazon S3 (or S3-compatible endpoints), Google Cloud Storage, or Azure Blob Storage.
 ---
 
-# Consul Enterprise Automated Backups
+# Automated Backups
 
-Consul's core snapshot functionality allows operators to save and restore the state of
-the Consul servers for disaster recovery. Snapshots are atomic and
-point-in-time, and include key/value entries, service catalog, prepared
-queries, sessions, and ACLs.
 
-[Consul Enterprise](https://www.hashicorp.com/consul.html) provides a [highly
-available service](/docs/commands/snapshot/agent.html) that
-integrates with the snapshot API to automatically manage taking snapshots,
-perform rotation and send backup files offsite to GCP, Amazon S3, or another S3-compatible endpoint.
+[Consul Enterprise](https://www.hashicorp.com/consul.html) enables you to run
+the snapshot agent within your environment as a service (Systemd as an example)
+or scheduled through other means. Once running, the snapshot agent service operates as a highly 
+available process that integrates with the snapshot API to automatically manage 
+taking snapshots, backup rotation, and sending backup files offsite to Amazon S3 
+(or another S3-compatible endpoint), Google Cloud Storage, or Azure Blob Storage.
+
+This capability provides an enterprise solution for backup and restoring the state of Consul servers 
+within an environment in an automated manner. These snapshots are atomic and point-in-time. Consul 
+datacenter backups include (but are not limited to): 
+
+- Key/Value Store Entries
+- Service Catalog Registrations 
+- Prepared Queries 
+- Sessions
+- Access Control Lists (ACLs)
+- Namespaces
+
+For more experience leveraging Consul's snapshot functionality, we suggest you look through our HashiCorp 
+Learn guide for [Datacenter Backups in Consul](https://learn.hashicorp.com/consul/datacenter-deploy/backup). 
+For detailed configuration information on configuring the Consul Enterprise's snapshot agent, review the 
+[Consul Snapshot Agent documentation](/docs/commands/snapshot/agent.html).

website/source/docs/enterprise/index.html.md

@@ -8,10 +8,11 @@ description: |-
 
 # Consul Enterprise
 
-Consul Enterprise simplifies operations by automating workflows. It adds support
-for microservices deployments across complex network topologies. It also
-increases both scalability and resilience. If you have already purchased Consul Enterprise, please see the [licensing section](#licensing)
-below.
+[Consul Enterprise](https://www.hashicorp.com/consul.html) features ease the complexity of operating Consul at 
+organizational scale by automating common operator workflows. It introduces capabilities for expanding 
+performance scalability, resiliency, and cluster lifecycle. It also adds support for application and service 
+architectures across complex network topologies. If you have already purchased Consul Enterprise, please 
+see the [licensing section](#licensing) below.
 
 Features include:
 
@@ -19,8 +20,7 @@ Features include:
 - [Automated Upgrades](/docs/enterprise/upgrades/index.html)
 - [Enhanced Read Scalability](/docs/enterprise/read-scale/index.html)
 - [Redundancy Zones](/docs/enterprise/redundancy/index.html)
-- [Advanced Federation for Complex Network
-  Topologies](/docs/enterprise/federation/index.html)
+- [Advanced Federation for Complex Network Topologies](/docs/enterprise/federation/index.html)
 - [Network Segments](/docs/enterprise/network-segments/index.html)
 - [Namespaces](/docs/enterprise/namespaces/index.html)
 - [Sentinel](/docs/enterprise/sentinel/index.html)

website/source/docs/enterprise/namespaces/index.html.md

@@ -9,14 +9,14 @@ description: |-
 # Consul Enterprise Namespaces
 
 With [Consul Enterprise](https://www.hashicorp.com/consul.html) v1.7.0, data for different users or teams
-can be isolated from each other with the use of Namespaces. Namespaces help reduce operational challenges 
+can be isolated from each other with the use of namespaces. Namespaces help reduce operational challenges 
 by removing restrictions around uniqueness of resource names across distinct teams, and enable operators 
 to provide self-service through delegation of administrative privileges.
 
-For more information on how to use namespaces with Consul Enterprise please review the following Learn Guides:
+For more information on how to use namespaces with Consul Enterprise please review the following HashiCorp Learn Guides:
 
-- [Register and Discover Services within Namespaces](https://learn.hashicorp.com/consul/namespaces/discovery-namespaces) - Register multiple services within different Namespaces in Consul
-- [Setup Secure Namespaces](https://learn.hashicorp.com/consul/namespaces/secure-namespaces) - Secure resources within a namespace and delegate Namespace ACL rights via ACL tokens
+- [Register and Discover Services within Namespaces](https://learn.hashicorp.com/consul/namespaces/discovery-namespaces) - Register multiple services within different namespaces in Consul.
+- [Setup Secure Namespaces](https://learn.hashicorp.com/consul/namespaces/secure-namespaces) - Secure resources within a namespace and delegate namespace ACL rights via ACL tokens.
 
 
 ## Namespace Definition
@@ -24,7 +24,7 @@ For more information on how to use namespaces with Consul Enterprise please revi
 Namespaces are managed exclusively through the [HTTP API](/api/namespaces.html) and the [Consul CLI](/docs/commands/namespace.html).
 The HTTP API accepts only JSON formatted definitions while the CLI will parse either JSON or HCL.
 
-An example Namespace definition looks like the following:
+An example namespace definition looks like the following:
 
 JSON:
 
@@ -86,24 +86,24 @@ Meta {
 
 ### Fields
 
-- `Name` `(string: <required>)` - The Namespaces name must be a valid DNS hostname label.
+- `Name` `(string: <required>)` - The namespaces name must be a valid DNS hostname label.
 
 - `Description` `(string: "")` - This field is intended to be a human readable description of the
   namespace's purpose. It is not used internally.
   
-- `ACLs` `(object: <optional>)` - This fields is a nested JSON/HCL object to contain the Namespaces
+- `ACLs` `(object: <optional>)` - This fields is a nested JSON/HCL object to contain the namespaces
   ACL configuration. 
   
   - `PolicyDefaults` `(array<ACLLink>)` - A list of default policies to be applied to all tokens
     created in this namespace. The ACLLink object can contain an `ID` and/or `Name` field. When the
-    policies ID is omitted Consul will resolve the name to an ID before writing the Namespace
-    definition internally. Note that all policies linked in a Namespace definition must be defined
+    policies ID is omitted Consul will resolve the name to an ID before writing the namespace
+    definition internally. Note that all policies linked in a namespace definition must be defined
     within the `default namespace.
     
   - `RoleDefaults` `(array<ACLLink>)` - A list of default roles to be applied to all tokens
     created in this namespace. The ACLLink object can contain an `ID` and/or `Name` field. When the
-    roles' ID is omitted Consul will resolve the name to an ID before writing the Namespace
-    definition internally. Note that all roles linked in a Namespace definition must be defined
+    roles' ID is omitted Consul will resolve the name to an ID before writing the namespace
+    definition internally. Note that all roles linked in a namespace definition must be defined
     within the `default namespace.
     
 - `Meta` `(map<string|string>: <optional>)` - Specifies arbitrary KV metadata to associate with

website/source/docs/enterprise/network-segments/index.html.md

@@ -7,16 +7,16 @@ description: |-
   cluster to segment network groups.
 ---
 
-# Consul Enterprise Network Segments
+# Network Segments
 
 Consul Network Segments enables operators to create separate LAN gossip segments
 in one Consul cluster. Agents in a segment are only able to join and communicate
-with other agents in its network segment. This functionality is useful for
+with other agents in it's network segment. This functionality is useful for
 clusters that have multiple tenants that should not be able to communicate
 with each other.
 
-To get started with Network Segments,
-[read the guide](https://learn.hashicorp.com/consul/day-2-operations/network-segments).
+To get started with network segments you can review the guide on HashiCorp Learn for
+[Network Segments](https://learn.hashicorp.com/consul/day-2-operations/network-segments).
 
 ~> **Note:** Due to limitations in [Serf](https://www.consul.io/docs/internals/gossip.html), a Consul agent configured with too many network segments may not be able to start
 
@@ -38,7 +38,8 @@ cluster each set per "datacenter". These Consul servers are federated together
 over the WAN. Consul clients make use of resources in federated clusters by
 forwarding RPCs through the Consul servers in their local cluster, but they
 never interact with remote Consul servers directly. There are currently two
-inter-cluster network models: [WAN Gossip (OSS)](https://learn.hashicorp.com/consul/security-networking/datacenters)
+inter-cluster network models which can be viewed on HashiCorp Learn: 
+[WAN gossip (OSS)](https://learn.hashicorp.com/consul/security-networking/datacenters)
 and [Network Areas (Enterprise)](https://learn.hashicorp.com/consul/day-2-operations/advanced-federation).
 
 **LAN Gossip Pool**: A set of Consul agents that have full mesh connectivity

website/source/docs/enterprise/read-scale/index.html.md

@@ -3,14 +3,17 @@ layout: "docs"
 page_title: "Consul Enterprise Enhanced Read Scalability"
 sidebar_current: "docs-enterprise-read-scale"
 description: |-
-  Consul Enterprise supports increased read scalability without impacting write latency.
+  Consul Enterprise supports increased read scalability without impacting write latency by introducing
+  non-voting servers.
 ---
 
-# Consul Enterprise Enhanced Read Scalability
+# Enhanced Read Scalability with Non-Voting Servers
 
-In [Consul Enterprise](https://www.hashicorp.com/consul.html), servers can be
-explicitly marked as non-voters. Non-voters will receive the replication stream
-but will not take part in quorum (required by the leader before log entries can
-be committed). Adding explicit non-voters will scale
-reads
-without impacting write latency.
+[Consul Enterprise](https://www.hashicorp.com/consul.html) provides the ability to scale clustered Consul servers
+to include voting and non-voting servers. Non-voting servers still receive data from the cluster replication,
+however, they do not take part in quorum election operations. Expanding your Consul cluster in this way can scale
+reads without impacting write latency. 
+
+For more details, review the [Consul server configuration](https://www.consul.io/docs/agent/options.html) 
+documentation and the [-non-voting-server](https://www.consul.io/docs/agent/options.html#_non_voting_server)
+configuration flag.

website/source/docs/enterprise/redundancy/index.html.md

@@ -6,14 +6,22 @@ description: |-
   Consul Enterprise redundancy zones enable hot standby servers on a per availability zone basis.
 ---
 
-# Consul Enterprise Redundancy Zones
+# Redundancy Zones
 
-[Consul Enterprise](https://www.hashicorp.com/consul.html) [redundancy
-zones](https://learn.hashicorp.com/consul/day-2-operations/autopilot#redundancy-zones) make
-it possible to have more servers than availability zones. For example, in an
-environment with three availability zones it's now possible to run one voter and
-one non-voter in each availability zone, for a total of six servers. If an
-availability zone is completely lost, only one voter will be lost, so the
-cluster remains available. If a voter is lost in an availability zone, Autopilot
-will promote the non-voter to voter automatically, putting the hot standby
-server into service quickly.
+[Consul Enterprise](https://www.hashicorp.com/consul.html) redundancy zones provide 
+both scaling and resiliancy benefits by enabling the deployment of non-voting
+servers alongside voting servers on a per availability zone basis.  
+
+When using redundancy zones, if an operator chooses to deploy Consul across 3 availability zones, they 
+could have 2 (or more) servers (1 voting/1 non-voting) in each zone. In the event that a voting 
+member in an availability zone fails, the redundancy zone configuration would automatically 
+promote the non-voting member to a voting member. In the event that an entire availability 
+zone was lost, a non-voting member in one of the existing availability zones would promote 
+to a voting member, keeping server quorum. This capability functions as a "hot standby" 
+for server nodes while also providing (and expanding) the capabilities of 
+[enhanced read scalability](/docs/enterprise/read-scale/index.html) by also including recovery 
+capabilities. 
+
+For more information, review the HashiCorp Learn guide on 
+[Redundancy Zones](https://learn.hashicorp.com/consul/day-2-operations/autopilot#redundancy-zones), 
+as well as the documentation for [Consul Autopilot](https://www.consul.io/docs/commands/operator/autopilot.html).

website/source/docs/enterprise/upgrades/index.html.md

@@ -6,14 +6,12 @@ description: |-
   Consul Enterprise supports an upgrade pattern that allows operators to deploy a complete cluster of new servers and then just wait for the upgrade to complete.
 ---
 
-# Consul Enterprise Automated Upgrades
+# Automated Upgrades
 
-[Consul Enterprise](https://www.hashicorp.com/consul.html) supports an [upgrade
-pattern](https://learn.hashicorp.com/consul/day-2-operations/autopilot#upgrade-migrations)
-that allows operators to deploy a complete cluster of new servers and then just wait
-for the upgrade to complete. As the new servers join the cluster, server
-introduction logic checks the version of each Consul server. If the version is
-higher than the version on the current set of voters, it will avoid promoting
-the new servers to voters until the number of new servers matches the number of
-existing servers at the previous version. Once the numbers match, Autopilot will
-begin to promote new servers and demote old ones.
+[Consul Enterprise](https://www.hashicorp.com/consul.html) enables the capability of automatically upgrading a cluster of Consul servers to a new
+version as updated server nodes join the cluster. This automated upgrade will spawn a process which monitors the amount of voting members 
+currently in a cluster. When an equal amount of new server nodes are joined running the desired version, the lower versioned servers 
+will be demoted to non voting members. Demotion of legacy server nodes will not occur until the voting members on the new version match. 
+Once this demotion occurs, the previous versioned servers can be removed from the cluster safely. 
+
+You can review more information about this functionality in the [Consul operator autopilot](https://www.consul.io/docs/commands/operator/autopilot.html) documentation as well as on the HashiCorp Learn [Automated Upgrade](https://learn.hashicorp.com/consul/day-2-operations/autopilot#upgrade-migrations) guide.