1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
<refsect1 id='failover'>
<title>AUSFALLSICHERUNG</title>
<para>
Die Ausfallsicherungsfunktionalität ermöglicht es, dass Backends automatisch
auf einen anderen Server wechseln, falls der aktuelle versagt.
</para>
<refsect2 id='failover_syntax'>
<title>AUSFALLSICHERUNGSSYNTAX</title>
<para>
Die Server werden als durch Kommata getrennte Liste angegeben. Um das Komma
herum ist eine beliebige Anzahl von Leerzeichen erlaubt. Die Server werden
in Reihenfolge der Bevorzugung aufgeführt. Die Liste kann eine beliebige
Anzahl von Servern enthalten.
</para>
<para>
Von jeder Konfigurationsoption mit aktivierter Ausfallsicherung existieren
zwei Varianten: <emphasis>primary</emphasis> und
<emphasis>backup</emphasis>. Die Idee dahinter ist, dass Server in der Liste
»primary« bevorzugt werden und nur nach »backup«-Servern gesucht wird, falls
kein »primary«-Server erreichbar ist. Falls ein »backup«-Server ausgewählt
wird, wird eine Dauer von 31 Sekunden bis zur Zeitüberschreitung
festgelegt. Nach dieser Zeit wird SSSD periodisch versuchen, sich mit einem
der primären Server zu verbinden. Ist dies erfolgreich, wird es den derzeit
aktiven (»backup«-)Server ersetzen.
</para>
</refsect2>
<refsect2 id='failover_mechanism'>
<title>Der Ausfallsicherungsmechanismus</title>
<para>
Der Ausfallsicherungsmechanismus unterscheidet zwischen einer Maschine und
einem Dienst. Das Backend versucht zuerst, den Rechnernamen der angegebenen
Maschine aufzulösen. Falls dieser Versuch scheitert, wird davon ausgegangen,
dass die Maschine offline ist und sie auch für keinen anderen Dienst zur
Verfügung steht. Kann der den Namen erfolgreich aufgelöst werden, versucht
das Backend, sich mit einem Dienst auf dieser Maschine zu verbinden. Ist das
nicht möglich, dann wird nur dieser bestimmte Dienst als offline angesehen
und das Backend wechselt automatisch weiter zum nächsten. Die Maschine wird
weiterhin als online betrachtet und kann immer noch für andere Dienste
herangezogen werden.
</para>
<para>
Weitere Verbindungsversuche zu Maschinen oder Diensten, die als offline
gekennzeichnet sind, werden erst nach einer angegebenen Zeitspanne
unternommen. Diese ist derzeit hart auf 30 Sekunden codiert.
</para>
<para>
Falls es weitere Maschinen durchzuprobieren gibt, wechselt das Backend als
Ganzes in den Offline-Modus und versucht dann alle 30 Sekunden, sich erneut
zu verbinden.
</para>
</refsect2>
<refsect2 id='failover_tuning'>
<title>Failover time outs and tuning</title>
<para>
Resolving a server to connect to can be as simple as running a single DNS
query or can involve several steps, such as finding the correct site or
trying out multiple host names in case some of the configured servers are
not reachable. The more complex scenarios can take some time and SSSD needs
to balance between providing enough time to finish the resolution process
but on the other hand, not trying for too long before falling back to
offline mode. If the SSSD debug logs show that the server resolution is
timing out before a live server is contacted, you can consider changing the
time outs.
</para>
<para>
This section lists the available tunables. Please refer to their description
in the <citerefentry>
<refentrytitle>sssd.conf</refentrytitle><manvolnum>5</manvolnum>
</citerefentry>, manual page. <variablelist>
<varlistentry>
<term>
dns_resolver_server_timeout
</term>
<listitem>
<para>
Time in milliseconds that sets how long would SSSD talk to a single DNS
server before trying next one.
</para>
<para>
Voreinstellung: 1000
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
dns_resolver_op_timeout
</term>
<listitem>
<para>
Time in seconds to tell how long would SSSD try to resolve single DNS query
(e.g. resolution of a hostname or an SRV record) before trying the next
hostname or discovery domain.
</para>
<para>
Voreinstellung: 3
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
dns_resolver_timeout
</term>
<listitem>
<para>
How long would SSSD try to resolve a failover service. This service
resolution internally might include several steps, such as resolving DNS SRV
queries or locating the site.
</para>
<para>
Voreinstellung: 6
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
For LDAP-based providers, the resolve operation is performed as part of an
LDAP connection operation. Therefore, also the
<quote>ldap_opt_timeout</quote> timeout should be set to a larger value than
<quote>dns_resolver_timeout</quote> which in turn should be set to a larger
value than <quote>dns_resolver_op_timeout</quote> which should be larger
than <quote>dns_resolver_server_timeout</quote>.
</para>
</refsect2>
</refsect1>
|
