DOC-3624 RS: Add UI & REST API methods to configure proxy policy & some copy edits

rrelledge · rrelledge · commit 31b14deacefb · 2024-12-06T13:24:21.000-06:00
diff --git a/content/operate/rs/databases/configure/proxy-policy.md b/content/operate/rs/databases/configure/proxy-policy.md
@@ -9,9 +9,9 @@ description: null
 linktitle: Proxy policy
 weight: 40
 ---
-Redis Enterprise Software (RS) provides high-performance data access
+Redis Software provides high-performance data access
 through a proxy process that manages and optimizes access to shards
-within the RS cluster. Each node contains a single proxy process.
+within the Redis Software cluster. Each node contains a single proxy process.
 Each proxy can be active and take incoming traffic or it can be passive
 and wait for failovers.
 
@@ -25,56 +25,77 @@ A database can have one of the following proxy policies:
 | All primary shards | Multiple proxies are bound to the database, one on each node that hosts a database primary shard. | Most use cases that require multiple endpoints, such as when using the [OSS Cluster API]({{<relref "/operate/rs/clusters/optimize/oss-cluster-api">}}) | Lower latency, fewer network hops, higher throughput | Higher resource usage, more application-to-proxy connections |
 | All nodes | Multiple proxies are bound to the database, one on each node in the cluster, regardless of whether or not there is a shard from this database on the node. | When using [load balancers]({{<relref "/operate/rs/networking/cluster-lba-setup">}}) for environments without DNS | Higher throughput | Highest resource usage |
 
-## Database configuration
+## View proxy policy
 
-A database can be configured with a proxy policy using rladmin bind.
+You can use the Cluster Manager UI, [`rladmin`]({{<relref "/operate/rs/references/cli-utilities/rladmin">}}), or the [REST API]({{<relref "/operate/rs/references/rest-api">}}) to view proxy configuration settings.
 
-Warning: Any configuration update which causes existing proxies to be
-unbounded can cause existing client connections to get disconnected.
-
-You can run rladmin to control and view the existing settings for proxy
-configuration.
-
-The **info** command on cluster returns the existing proxy policy for
-sharded and non-sharded (single shard) databases.
+The [`rladmin info cluster`]({{<relref "/operate/rs/references/cli-utilities/rladmin/info#info-cluster">}}) command returns the current proxy policy for sharded and non-sharded (single shard) databases.
 
 ```sh
 $ rladmin info cluster
 cluster configuration:
-   repl_diskless: enabled
+   ...
    default_non_sharded_proxy_policy: single
    default_sharded_proxy_policy: single
-   default_shards_placement: dense
-   default_shards_overbooking: disabled
-   default_fork_evict_ram: enabled
-   default_redis_version: 3.2
-   redis_migrate_node_threshold: 0KB (0 bytes)
-   redis_migrate_node_threshold_percent: 8 (%)
-   redis_provision_node_threshold: 0KB (0 bytes)
-   redis_provision_node_threshold_percent: 12 (%)
-   max_simultaneous_backups: 4
-   watchdog profile: local-network
+   ...
 ```
 
-You can configure the proxy policy using the `bind` command in
-rladmin. The following command is an example that changes the bind
-policy for a database named "db1" with an endpoint id "1:1" to "All
-primary shards" proxy policy.
+## Configure database proxy policy
+
+You can use the [Cluster Manager UI](#cluster-manager-ui-method), the [REST API](#rest-api-method), or [`rladmin`](#command-line-method) to configure a database's proxy policy.
+
+{{<warning>}}
+Any configuration update that unbinds existing proxies can disconnect existing client connections.
+{{</warning>}}
+
+### Cluster Manager UI method
+
+You can change a database's proxy policy when you [create]({{<relref "/operate/rs/databases/create">}}) or [edit]({{<relref "/operate/rs/databases/configure#edit-database-settings">}}) a database using the Cluster Manager UI:
+
+1. While in edit mode on the database's configuration screen, expand the **Clustering** section.
+
+1. Select a policy from the **Database proxy** list.
+
+1. Click **Create** or **Save**.
+
+### REST API method
+
+You can specify a proxy policy when you [create a database]({{<relref "/operate/rs/references/rest-api/requests/bdbs#post-bdbs-v1">}}) using the REST API:
+
+```sh
+POST /v1/bdbs/<database-id>
+{ 
+  "proxy_policy": "single | all-master-shards | all-nodes",
+  // Other database configuration parameters
+}
+```
+
+To change an existing database's proxy policy, you can use an [update database configuration]({{<relref "/operate/rs/references/rest-api/requests/bdbs#put-bdbs">}}) REST API request:
+
+```sh
+PUT /v1/bdbs/<database-id>
+{ "proxy_policy": "single | all-master-shards | all-nodes" }
+```
+
+### Command-line method
+
+You can configure a database's proxy policy using [`rladmin bind`]({{<relref "/operate/rs/references/cli-utilities/rladmin/bind">}}).
+
+The following example changes the bind policy for a database named "db1" with an endpoint ID "1:1" to "All primary shards" proxy policy:
 
 ```sh
 rladmin bind db db1 endpoint 1:1 policy all-master-shards
 ```
 
-The next command performs the same task using the database id in place of the name.  The id of this database is "1".
+The next command performs the same task using the database ID instead of the name. The ID of this database is "1".
 
 ```sh
 rladmin bind db db:1 endpoint 1:1 policy all-master-shards
 ```
 
 {{< note >}}
-You can find the endpoint id for the endpoint argument by running
-*status* command for rladmin. Look for the endpoint id information under
-the *ENDPOINT* section of the output.
+You can find the endpoint ID for the endpoint argument by running `rladmin status`. Look for the endpoint ID information under
+the `ENDPOINT` section of the output.
 {{< /note >}}
 
 ### Reapply policies after topology changes
@@ -100,44 +121,25 @@ disconnected, and hence might not entirely enforce the policies. In such
 cases, you can enforce the policy using the appropriate rladmin
 commands.
 
-## About multiple active proxy support
+## Multiple active proxies
 
-RS allows multiple databases to be created. Each database gets an
-endpoint (a unique URL and port on the FQDN). This endpoint receives all
-the traffic for all operations for that database. By default, RS binds
-this database endpoint to one of the proxies on a single node in the
-cluster. This proxy becomes an active proxy and receives all the
-operations for the given database. (note that if the node with the
-active proxy fails, a new proxy on another node takes over as part of
-the failover process automatically).
+Each database you create in a Redis Software cluster has an endpoint, which consists of a unique URL and port on the FQDN. This endpoint receives all the traffic for all operations for that database. By default, Redis Software binds this database endpoint to one of the proxies on a single node in the cluster. This proxy becomes an active proxy and receives all the operations for the given database. If the node with the active proxy fails, a new proxy on another node takes over as part of the failover process automatically.
 
 In most cases, a single proxy can handle a large number of operations
 without consuming additional resources. However, under high load,
-network bandwidth or a high rate of packets per second (PPS) on the
+network bandwidth, or a high rate of packets per second (PPS) on the
 single active proxy can become a bottleneck to how fast database
-operation can be performed. In such cases, having multiple active
-proxies, across multiple nodes, mapped to the same external database
+operations can be performed. In such cases, having multiple active proxies across multiple nodes, mapped to the same external database
 endpoint, can significantly improve throughput.
 
-With the multiple active proxies capability, RS enables you to configure
-a database to have multiple internal proxies in order to improve
-performance, in some cases. It is important to note that, even though
-multiple active proxies can help improve the throughput of database
+You can configure a database to have multiple internal proxies, which can improve performance in some cases.
+Even though multiple active proxies can help improve the throughput of database
 operations, configuring multiple active proxies may cause additional
 latency in operations as the shards and proxies are spread across
 multiple nodes in the cluster.
 
 {{< note >}}
-When the network on a single active proxy becomes the bottleneck,
-you might also look into enabling the multiple NIC support in RS. With
-nodes that have multiple physical NICs (Network Interface Cards), you
-can configure RS to separate internal and external traffic onto
-independent physical NICs. For more details, refer to [Multi-IP &
-IPv6]({{< relref "/operate/rs/networking/multi-ip-ipv6.md" >}}).
+When the network on a single active proxy becomes the bottleneck, consider enabling multiple NIC support in Redis Software. With nodes that have multiple physical NICs (Network Interface Cards), you can configure Redis Software to separate internal and external traffic onto independent physical NICs. For more details, refer to [Multi-IP & IPv6]({{< relref "/operate/rs/networking/multi-ip-ipv6.md" >}}).
 {{< /note >}}
 
-Having multiple proxies for a database can improve RS's ability for fast
-failover in case of proxy and/or node failure. With multiple proxies for
-a database, there is no need for a client to wait for the cluster
-to spin up another proxy and a DNS change in most cases, the client
-just uses the next IP in the list to connect to another proxy.
+Having multiple proxies for a database can improve Redis Software's ability for fast failover in case of proxy or node failure. With multiple proxies for a database, a client doesn't need to wait for the cluster to spin up another proxy and a DNS change in most cases. Instead, the client uses the next IP address in the list to connect to another proxy.
