mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-28 15:45:36 +00:00
Add v2.14 preview docs (#2212)
This commit is contained in:
Lucas Saintarbor
GitHub
+88
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: Installing Rancher in a VMware vSphere Environment
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a VMware vSphere environment. It also desctibes standard vSphere best practices as documented by VMware.
|
||||
|
||||
|
||||
<figcaption>Solution Overview</figcaption>
|
||||
|
||||
|
||||
|
||||
## 1. Load Balancer Considerations
|
||||
|
||||
A load balancer is required to direct traffic to the Rancher workloads residing on the RKE nodes.
|
||||
|
||||
### Leverage Fault Tolerance and High Availability
|
||||
|
||||
Leverage the use of an external (hardware or software) load balancer that has inherit high-availability functionality (F5, NSX-T, Keepalived, etc).
|
||||
|
||||
### Back Up Load Balancer Configuration
|
||||
|
||||
In the event of a Disaster Recovery activity, availability of the Load balancer configuration will expedite the recovery process.
|
||||
|
||||
### Configure Health Checks
|
||||
|
||||
Configure the Load balancer to automatically mark nodes as unavailable if a health check is failed. For example, NGINX can facilitate this with:
|
||||
|
||||
`max_fails=3 fail_timeout=5s`
|
||||
|
||||
### Leverage an External Load Balancer
|
||||
|
||||
Avoid implementing a software load balancer within the management cluster.
|
||||
|
||||
### Secure Access to Rancher
|
||||
|
||||
Configure appropriate Firewall / ACL rules to only expose access to Rancher
|
||||
|
||||
## 2. VM Considerations
|
||||
|
||||
### Size the VM's According to Rancher Documentation
|
||||
|
||||
See [Installation Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md).
|
||||
|
||||
### Leverage VM Templates to Construct the Environment
|
||||
|
||||
To facilitate the consistency of Virtual Machines deployed across the environment, consider the use of "Golden Images" in the form of VM templates. Packer can be used to accomplish this, adding greater customization options.
|
||||
|
||||
### Leverage DRS Anti-Affinity Rules (Where Possible) to Separate Rancher Cluster Nodes Across ESXi Hosts
|
||||
|
||||
Doing so will ensure node VM's are spread across multiple ESXi hosts - preventing a single point of failure at the host level.
|
||||
|
||||
### Leverage DRS Anti-Affinity Rules (Where Possible) to Separate Rancher Cluster Nodes Across Datastores
|
||||
|
||||
Doing so will ensure node VM's are spread across multiple datastores - preventing a single point of failure at the datastore level.
|
||||
|
||||
### Configure VM's as Appropriate for Kubernetes
|
||||
|
||||
It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node.
|
||||
|
||||
## 3. Network Considerations
|
||||
|
||||
### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes
|
||||
|
||||
Deploy etcd members within a single data center where possible to avoid latency overheads and reduce the likelihood of network partitioning. For most setups, 1Gb connections will suffice. For large clusters, 10Gb connections can reduce the time taken to restore from backup.
|
||||
|
||||
### Consistent IP Addressing for VM's
|
||||
|
||||
Each node used should have a static IP configured. In the case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated.
|
||||
|
||||
## 4. Storage Considerations
|
||||
|
||||
### Leverage SSD Drives for ETCD Nodes
|
||||
|
||||
ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.
|
||||
|
||||
## 5. Backups and Disaster Recovery
|
||||
|
||||
### Perform Regular Management Cluster Backups
|
||||
|
||||
Rancher stores its data in the ETCD datastore of the Kubernetes cluster it resides on. Like with any Kubernetes cluster, perform frequent, tested backups of this cluster.
|
||||
|
||||
### Back up Rancher Cluster Node VMs
|
||||
|
||||
Incorporate the Rancher management node VM's within a standard VM backup policy.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Rancher Deployment Strategy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/rancher-deployment-strategy"/>
|
||||
</head>
|
||||
|
||||
There are two recommended deployment strategies for a Rancher instance that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case.
|
||||
|
||||
## Hub & Spoke Strategy
|
||||
---
|
||||
|
||||
In this deployment scenario, there is a single Rancher instance managing Kubernetes clusters across the globe. The Rancher instance would be run on a high-availability Kubernetes cluster, and there would be impact due to latencies.
|
||||
|
||||
### Pros
|
||||
|
||||
* Single control plane interface to view/see all regions and environments.
|
||||
* Kubernetes does not require Rancher to operate and can tolerate losing connectivity to the Rancher instance.
|
||||
|
||||
### Cons
|
||||
|
||||
* Subject to network latencies.
|
||||
* If Rancher goes down, global provisioning of new services is unavailable until it is restored. However, each Kubernetes cluster can continue to be managed individually.
|
||||
|
||||
## Regional Strategy
|
||||
---
|
||||
In the regional deployment model a Rancher instance is deployed in close proximity to the downstream Kubernetes clusters.
|
||||
|
||||
### Pros
|
||||
|
||||
* Rancher functionality in regions stay operational if a Rancher instance in another region goes down.
|
||||
* Network latency between Rancher and downstream clusters is greatly reduced, improving the performance of functionality in Rancher.
|
||||
* Upgrades of Rancher can be done independently per region.
|
||||
|
||||
### Cons
|
||||
|
||||
* Overhead of managing multiple Rancher installations.
|
||||
* Visibility into Kubernetes clusters in different regions requires multiple interfaces/panes of glass.
|
||||
* Deploying multi-cluster apps in Rancher requires repeating the process for each Rancher server.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Best Practices for the Rancher Server
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server"/>
|
||||
</head>
|
||||
|
||||
This guide contains our recommendations for running the Rancher server, and is intended to be used in situations in which Rancher manages downstream Kubernetes clusters.
|
||||
|
||||
### Recommended Architecture and Infrastructure
|
||||
|
||||
Refer to this [guide](tips-for-running-rancher.md) for our general advice for setting up the Rancher server for a production installation.
|
||||
|
||||
### Deployment Strategies
|
||||
|
||||
This [guide](rancher-deployment-strategy.md) is designed to help you choose whether a regional deployment strategy or a hub-and-spoke deployment strategy is better for a Rancher server that manages downstream Kubernetes clusters.
|
||||
|
||||
### Installing Rancher in a VMware vSphere Environment
|
||||
|
||||
This [guide](on-premises-rancher-in-vsphere.md) outlines a reference architecture for installing Rancher in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: Tips for Running Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tips-for-running-rancher"/>
|
||||
</head>
|
||||
|
||||
This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
|
||||
|
||||
A high-availability Kubernetes installation, defined as an installation of Rancher on a Kubernetes cluster with at least three nodes, should be used in any production installation of Rancher, as well as any installation deemed "important." Multiple Rancher instances running on multiple nodes ensure high availability that cannot be accomplished with a single node environment.
|
||||
|
||||
If you are installing Rancher in a vSphere environment, refer to the best practices documented [here.](on-premises-rancher-in-vsphere.md)
|
||||
|
||||
When you set up your high-availability Rancher installation, consider the following:
|
||||
|
||||
### Minimize Third-Party Software on the Upstream Cluster
|
||||
|
||||
We generally recommend running Rancher on a dedicated cluster, free of other workloads, to avoid potential performance and compatibility issues.
|
||||
|
||||
Rancher, especially when managing a growing number of clusters, nodes, and workloads, places a significant load on core Kubernetes components like `etcd` and `kube-apiserver` on the upstream cluster. Third-party software can interfere with the performance of these components and Rancher, potentially leading to instability.
|
||||
|
||||
Furthermore, third-party software can functionally interfere with Rancher. To minimize compatibility risks, deploy only essential Kubernetes system components and Rancher on the upstream cluster.
|
||||
|
||||
The following applications and components generally do not interfere with Rancher or the Kubernetes system:
|
||||
* Rancher internal components, such as Fleet
|
||||
* Rancher extensions
|
||||
* Cluster API components
|
||||
* CNIs, CPIs, CSIs
|
||||
* Cloud controller managers
|
||||
* Observability and monitoring tools (except prometheus-rancher-exporter)
|
||||
|
||||
Note that each of these components has its own minimum resource requirements, which must be met in addition to Rancher's. For high-scale deployments, also consider dedicating separate nodes to non-Rancher software using [taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) to minimize interference.
|
||||
|
||||
The following software can interfere with Rancher performance and is therefore discouraged on the upstream cluster:
|
||||
* [CrossPlane](https://www.crossplane.io/)
|
||||
* [Argo CD](https://argoproj.github.io/cd/)
|
||||
* [Flux](https://fluxcd.io/)
|
||||
* [prometheus-rancher-exporter](https://github.com/David-VTUK/prometheus-rancher-exporter) (see [issue 33](https://github.com/David-VTUK/prometheus-rancher-exporter/issues/33))
|
||||
* Container registries such as [Harbor](https://goharbor.io/), which can require significant bandwidth for serving images
|
||||
|
||||
### Guidance for Container Registries
|
||||
|
||||
Container registries, such as [Harbor](https://goharbor.io/), can consume significant network bandwidth when serving images. This demand increases with the number of images, the frequency of image pulls, and the quantity of clusters and container runtimes they serve. Due to this potential for interference with Rancher UI and API traffic, we recommend against running container registries on the same cluster as the Rancher management server.
|
||||
|
||||
Regardless of your deployment strategy for a container registry, ensure sufficient bandwidth is available, ideally reserved using Quality of Service (QoS) mechanisms.
|
||||
|
||||
Consider the following recommendations based on your needs:
|
||||
|
||||
* **Simple Setups (HA Not a Primary Concern):** A container registry deployed as a single Virtual Machine (VM) can be a viable solution.
|
||||
* **High Availability (HA) Requirements:** We recommend running the registry in a dedicated Kubernetes cluster. All other clusters should then be configured to pull images from this centralized, HA registry.
|
||||
* **Very Large-Scale or Complex Network Topologies:** Multiple registry clusters might be necessary. These can be deployed in a hierarchical or federated model to efficiently distribute images and manage traffic.
|
||||
|
||||
### Make sure nodes are configured correctly for Kubernetes
|
||||
It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.5/op-guide/performance/).
|
||||
|
||||
### Run All Nodes in the Cluster in the Same Datacenter
|
||||
For best performance, run all three of your nodes in the same geographic datacenter. If you are running nodes in the cloud, such as AWS, run each node in a separate Availability Zone. For example, launch node 1 in us-west-2a, node 2 in us-west-2b, and node 3 in us-west-2c.
|
||||
|
||||
### Development and Production Environments Should be Similar
|
||||
It's strongly recommended to have a "staging" or "pre-production" environment of the Kubernetes cluster that Rancher runs on. This environment should mirror your production environment as closely as possible in terms of software and hardware configuration.
|
||||
|
||||
### Monitor Your Clusters to Plan Capacity
|
||||
The Rancher server's Kubernetes cluster should run within the [system and hardware requirements](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md) as closely as possible. The more you deviate from the system and hardware requirements, the more risk you take.
|
||||
|
||||
However, metrics-driven capacity planning analysis should be the ultimate guidance for scaling Rancher, because the published requirements take into account a variety of workload types.
|
||||
|
||||
Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution, and Grafana, which lets you visualize the metrics from Prometheus.
|
||||
|
||||
After you [enable monitoring](../../../integrations-in-rancher/monitoring-and-alerting/monitoring-and-alerting.md) in the cluster, you can set up alerts to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
---
|
||||
title: Tuning and Best Practices for Rancher at Scale
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale"/>
|
||||
</head>
|
||||
|
||||
|
||||
This guide describes the best practices and tuning approaches to scale Rancher setups and the associated challenges with doing so. As systems grow, performance will naturally reduce, but there are steps that can minimize the load put on Rancher and optimize Rancher's ability to manage larger infrastructures.
|
||||
|
||||
## Optimizing Rancher Performance
|
||||
|
||||
* Keep Rancher up to date with patch releases. We are continuously improving Rancher with performance enhancements and bug fixes. The latest Rancher release contains all accumulated improvements to performance and stability, plus updates based on developer experience and user feedback.
|
||||
|
||||
* Always scale up gradually, and monitor and observe any changes in behavior while doing do. It is usually easier to resolve performance problems as soon as they surface, before other problems obscure the root cause.
|
||||
|
||||
* Reduce network latency between the upstream Rancher cluster and downstream clusters to the extent possible. Note that latency is, among other factors, a function of geographic distance - if you require clusters or nodes spread across the world, consider multiple Rancher installations.
|
||||
|
||||
## Minimizing Load on the Upstream Cluster
|
||||
|
||||
When scaling up Rancher, one typical bottleneck is resource growth in the upstream (local) Kubernetes cluster. The upstream cluster contains information for all downstream clusters. Many operations that apply to downstream clusters create new objects in the upstream cluster and require computation from handlers running in the upstream cluster.
|
||||
|
||||
### Minimizing Third-Party Software on the Upstream Cluster
|
||||
|
||||
Recommendations outlined in the [general Rancher recommendations](./tips-for-running-rancher.md#minimize-third-party-software-on-the-upstream-cluster) are particularly important in a high scale context.
|
||||
|
||||
### Managing Your Object Counts
|
||||
|
||||
Etcd is the backing database for Kubernetes and for Rancher. The database may eventually encounter limitations to the number of a single Kubernetes resource type it can store. Exact limits vary and depend on a number of factors. However, experience indicates that performance issues frequently arise once a single resource type's object count exceeds 60,000. Often that type is `RoleBinding`.
|
||||
|
||||
This is typical in Rancher, as many operations create new `RoleBinding` objects in the upstream cluster as a side effect.
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
* Use as few rules as possible in custom roles.
|
||||
* Consider whether adding a role to a user is redundant.
|
||||
* Consider using less, but more powerful, clusters.
|
||||
* Kubernetes permissions are always "additive" (allow-list) rather than "subtractive" (deny-list). Try to minimize configurations that gives access to all but one aspect of a cluster, project, or namespace, as that will result in the creation of a high number of `RoleBinding` objects.
|
||||
* Experiment to see if creating new projects or clusters manifests in fewer `RoleBindings` for your specific use case.
|
||||
|
||||
### Using External Authentication
|
||||
|
||||
If you have fifty or more users, you should configure an [external authentication provider](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md). This is necessary for better performance.
|
||||
|
||||
After you configure external authentication, make sure to assign permissions to groups instead of to individual users. This helps reduce the `RoleBinding` object count.
|
||||
|
||||
### RoleBinding Count Estimation
|
||||
|
||||
Predicting how many `RoleBinding` objects a given configuration will create is complicated. However, the following considerations can offer a rough estimate:
|
||||
* For a minimum estimate, use the formula `32C + U + 2UaC + 8P + 5Pa`.
|
||||
* `C` is the total number of clusters.
|
||||
* `U` is the total number of users.
|
||||
* `Ua` is the average number of users with a membership on a cluster.
|
||||
* `P` is the total number of projects.
|
||||
* `Pa` is the average number of users with a membership on a project.
|
||||
* The number of `RoleBindings` increases linearly with the number of clusters, projects, and users.
|
||||
|
||||
### Using New Apps Over Legacy Apps
|
||||
|
||||
Rancher uses two Kubernetes app resources: `apps.projects.cattle.io` and `apps.cattle.cattle.io`. Legacy apps, represented by `apps.projects.cattle.io`, were introduced with the former Cluster Manager UI and are now outdated. Current apps, represented by `apps.catalog.cattle.io`, are found in the Cluster Explorer UI for their respective cluster. `Apps.cattle.cattle.io` apps are preferable because their data resides in downstream clusters, which frees up resources in the upstream cluster.
|
||||
|
||||
You should remove any remaining legacy apps that appear in the Cluster Manager UI, and replace them with apps in the Cluster Explorer UI. Create any new apps only in the Cluster Explorer UI.
|
||||
|
||||
### Using the Authorized Cluster Endpoint (ACE)
|
||||
|
||||
An [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) (ACE) provides access to the Kubernetes API of Rancher-provisioned RKE2 and K3s clusters. When enabled, the ACE adds a context to kubeconfig files generated for the cluster. The context uses a direct endpoint to the cluster, thereby bypassing Rancher. This reduces load on Rancher for cases where unmediated API access is acceptable or preferable. See [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information and configuration instructions.
|
||||
|
||||
### Reducing Event Handler Executions
|
||||
|
||||
The bulk of Rancher's logic occurs on event handlers. These event handlers run on an object whenever the object is updated, and when Rancher is started. Additionally, they run every 10 hours when Rancher syncs caches. In scaled setups these scheduled runs come with huge performance costs because every handler is being run on every applicable object. However, the scheduled handler execution can be disabled with the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable. If resource allocation spikes are seen every 10 hours, this setting can help.
|
||||
|
||||
The value for `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` can be a comma separated list of the following options. The values refer to types of handlers and controllers (the structures that contain and run handlers). Adding the controller types to the variable disables that set of controllers from running their handlers as part of cache resyncing.
|
||||
|
||||
* `mgmt` refers to management controllers which only run on one Rancher node.
|
||||
* `user` refers to user controllers which run for every cluster. Some of these run on the same node as management controllers, while others run in the downstream cluster. This option targets the former.
|
||||
* `scaled` refers to scaled controllers which run on every Rancher node. You should avoid setting this value, as the scaled handlers are responsible for critical functions and changes may disrupt cluster stability.
|
||||
|
||||
In short, if you notice CPU usage peaks every 10 hours, add the `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` environment variable to your Rancher deployment (in the `spec.containers.env` list) with the value `mgmt,user`
|
||||
|
||||
## Optimizations Outside of Rancher
|
||||
|
||||
Important influencing factors are the underlying cluster's own performance and configuration. The upstream cluster, if misconfigured, can introduce a bottleneck Rancher software has no chance to resolve.
|
||||
|
||||
### Manage Upstream Cluster Nodes Directly with RKE2
|
||||
|
||||
As Rancher can be very demanding on the upstream cluster, especially at scale, you should have full administrative control of the cluster's configuration and nodes. To identify the root cause of excess resource consumption, use standard Linux troubleshooting techniques and tools. This can aid in distinguishing between whether Rancher, Kubernetes, or operating system components are causing issues.
|
||||
|
||||
Although managed Kubernetes services make it easier to deploy and run Kubernetes clusters, they are discouraged for the upstream cluster in high scale scenarios. Managed Kubernetes services typically limit access to configuration and insights on individual nodes and services.
|
||||
|
||||
Use RKE2 for large scale use cases.
|
||||
|
||||
### Keep all Upstream Cluster Nodes co-located
|
||||
|
||||
To provide high availability, Kubernetes is designed to run nodes and control components in different zones. However, if nodes and control plane components are located in different zones, network traffic may be slower.
|
||||
|
||||
Traffic between Rancher components and the Kubernetes API is especially sensitive to network latency, as is etcd traffic between nodes.
|
||||
|
||||
To improve performance, run all upstream node clusters in the same location. In particular, make sure that latency between etcd nodes and Rancher is as low as possible.
|
||||
|
||||
### Keeping Kubernetes Versions Up to Date
|
||||
|
||||
You should keep the local Kubernetes cluster up to date. This will ensure that your cluster has all available performance enhancements and bug fixes.
|
||||
|
||||
### Optimizing etcd
|
||||
|
||||
Etcd is the backend database for Kubernetes and for Rancher. It plays a very important role in Rancher performance.
|
||||
|
||||
The two main bottlenecks to [etcd performance](https://etcd.io/docs/v3.5/op-guide/performance/) are disk and network speed. Etcd should run on dedicated nodes with a fast network setup and with SSDs that have high input/output operations per second (IOPS). For more information regarding etcd performance, see [Slow etcd performance (performance testing and optimization)](https://www.suse.com/support/kb/doc/?id=000020100) and [Tuning etcd for Large Installations](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md). Information on disks can also be found in the [Installation Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#disks).
|
||||
|
||||
It's best to run etcd on exactly three nodes, as adding more nodes will reduce operation speed. This may be counter-intuitive to common scaling approaches, but it's due to etcd's [replication mechanisms](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size).
|
||||
|
||||
Etcd performance will also be negatively affected by network latency between nodes as that will slow down network communication. Etcd nodes should be located together with Rancher nodes.
|
||||
|
||||
### Browser Requirements
|
||||
|
||||
At high scale, Rancher transfers more data from the upstream cluster to UI components running in the browser, and those components also need to perform more processing.
|
||||
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
Reference in New Issue
Block a user