Zen

Source string Source string

78/10000 · 78

The string is read only.

English Actions
One central {productname} Server, which acts as the Hub Server.
One or more additional {productname} Servers, registered to the Hub as Salt clients.
This document refers to these as peripheral servers.
Any number of clients registered to the peripheral servers.
Ensure the Hub Server and all peripheral servers are running {productname}{nbsp}4.1 or higher.
The Hub Server must not have clients registered to it. Clients should only be registered to the peripheral servers.
Peripheral Servers
Peripheral servers must be registered to the Hub Server as Salt clients. When you register the peripheral servers, assign them the appropriate ``SUSE Manager Server`` software channel as their base channel. Additionally, they must be registered to the Hub Server directly, do not use a proxy.
Peripheral servers must be registered to the Hub Server as Salt clients. When you register the peripheral servers, assign them the appropriate ``SUSE Manager Server`` software channel as their base channel. Additionally, they must be registered to the Hub Server directly, do not use a proxy.
For more information about registering clients, see xref:client-configuration:registration-webui.adoc[].
You need credentials to access the XMLRPC APIs on each server, including the Hub Server.
Monitoring Large Scale Deployments
You can monitor your {productname} environment using Prometheus and Grafana. {productname} Server and Proxy are able to provide self-health metrics. You can also install and manage a number of Prometheus exporters on Salt clients.
Prometheus and Grafana packages are included in the {productname} Client Tools for {sle}{nbsp}12, {sle}{nbsp}15, {rhel}{nbsp}7, {rhel}{nbsp}8 and openSUSE 15.x.
Prometheus and Grafana packages are included in the {productname} Client Tools for {sle}{nbsp}12, {sle}{nbsp}15, {centos}{nbsp}7, {centos}{nbsp}8 and openSUSE 15.x.
You need to install Prometheus and Grafana on a machine separate from the {productname} Server. We recommend you use a managed Salt client as your monitoring server.
For more information on monitoring, see xref:administration:monitoring.adoc[].
Using Multiple Servers to Manage Large Scale Deployments
If you need to manage a large number of clients, in most cases you can do so with a single {productname} Server, tuned appropriately. However, if you need to manage tens of thousands of clients, you might find it easier to use multiple {productname} Servers, in a hub, to manage them.
{productname} Hub helps you manage very large deployments. The typical Hub topology looks like this:
typical-hub-architecture-overview.svg
Operation Recommendations
This section contains a range of recommendations for large scale deployments.
Always start small and scale up gradually. Monitor the server as you scale to identify problems early.
Salt Client Onboarding Rate
The rate at which {productname} can onboard clients is limited and depends on hardware resources. Onboarding clients at a faster rate than {productname} is configured for will build up a backlog of unprocessed keys. This slows down the process and can potentially exhaust resources. We recommend that you limit the acceptance key rate programmatically. A safe starting point would be to onboard a client every 15 seconds. You can do that with this command:
for k in $(salt-key -l un|grep -v Unaccepted); do salt-key -y -a $k; sleep 15; done
Salt Clients and the RNG
All communication to and from Salt clients is encrypted. During client onboarding, Salt uses asymmetric cryptography, which requires available entropy from the Random Number Generator (RNG) facility in the kernel. If sufficient entropy is not available from the RNG, it will significantly slow down communications. This is especially true in virtualized environments. Ensure enough entropy is present, or change the virtualization host options.
You can check the amount of available entropy with the [command]``cat /proc/sys/kernel/random/entropy_avail``. It should never be below 100-200.
Clients Running with Unaccepted Salt Keys
Idle clients which have not been onboarded, that is clients running with unaccepted Salt keys, consume more resources than idle clients that have been onboarded. Generally, this consumes about an extra 2.5 Kb/s of inbound network bandwidth per client. For example, 1000 idle clients will consume about 2.5 Mb/s extra. This consumption will reduce almost to zero when onboarding has been completed for all clients. Limit the number of non-onboarded clients for optimal performance.
Idle clients which have not been onboarded, that is clients running with unaccepted Salt keys, consume more resources than idle clients that have been onboarded. Generally, this consumes about an extra 2.5 Kb/s of inbound network bandwidth per client. For example, 1000 idle clients will consume about 2.5 Mb/s extra. This consumption will reduce almost to zero when onboarding has been completed for all clients. Limit the number of non-onboarded clients for optimal performance.

Loading…

No matching activity found.
Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Inconsistent: Czech, Japanese, Chinese (China) (zh_CN)

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
read-only
Source string location
modules/specialized-guides/pages/large-deployments/monitoring.adoc:6
String age
5 months ago
Last updated
a month ago
Source string age
5 months ago
Translation file
l10n-weblate/specialized-guides/specialized-guides.pot, string 235