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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Redundante und Failover-Netzwerk-Überwachung</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.75.1">
<meta name="keywords" content="Supervision, Icinga, Icinga, Linux">
<link rel="home" href="index.html" title="Icinga Version 1.0.2 Dokumentation">
<link rel="up" href="ch06.html" title="Kapitel 6. Fortgeschrittene Themen">
<link rel="prev" href="distributed.html" title="Verteilte Überwachung">
<link rel="next" href="flapping.html" title="Erkennung und Behandlung von Status-Flattern">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<CENTER><IMG src="../images/logofullsize.png" border="0" alt="Icinga" title="Icinga"></CENTER>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Redundante und Failover-Netzwerk-Überwachung</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="distributed.html">Zurück</a> </td>
<th width="60%" align="center">Kapitel 6. Fortgeschrittene Themen</th>
<td width="20%" align="right"> <a accesskey="n" href="flapping.html">Weiter</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="section" title="Redundante und Failover-Netzwerk-Überwachung">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="redundancy"></a>Redundante und Failover-Netzwerk-Überwachung</h2></div></div></div>
<p><span class="bold"><strong>Einführung</strong></span></p>
<p>Dieser Abschnitt beschreibt einige Szenarien zum Implementieren von redundanten Überwachungs-Hosts auf verschiedenen Arten
von Netzwerk-Layouts. Mit redundanten Hosts können Sie die Überwachung Ihres Netzwerkes aufrecht erhalten, wenn der primäre
Host, auf dem Icinga läuft, ausfällt oder wenn Teile Ihres Netzwerkes unerreichbar werden.</p>
<p><span class="color"> <span class="bold"><strong>Anmerkung:</strong></span> </span> Wenn Sie gerade lernen,
wie Icinga zu nutzen ist, würden wir empfehlen, Redundanz so lange nicht zu implementieren, bis Sie mit den <a class="link" href="redundancy.html#redundancy-prerequisites">Voraussetzungen</a> vertraut sind. Redundanz ist ein relativ komplexes Thema und es ist
noch schwieriger, es zu implementieren.</p>
<p><span class="bold"><strong>Index</strong></span></p>
<p><a class="link" href="redundancy.html#redundancy-prerequisites">Voraussetzungen</a></p>
<p><a class="link" href="redundancy.html#redundancy-samples">Beispiel-Scripte</a></p>
<p><a class="link" href="redundancy.html#redundancy-scenario_1">Szenario 1 - Redundante Überwachung</a></p>
<p><a class="link" href="redundancy.html#redundancy-scenario_2">Szenario 2 - Failover Überwachung</a></p>
<p><a name="redundancy-prerequisites"></a> <span class="bold"><strong>Voraussetzungen</strong></span></p>
<p>Bevor Sie überhaupt daran denken können, Redundanz mit Icinga zu implementieren, müssen Sie mit folgenden Dingen
vertraut werden...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>Implementieren von <a class="link" href="eventhandlers.html" title="Eventhandler">Eventhandlern</a> für Hosts und Services</p>
</li>
<li class="listitem">
<p>Erteilen von <a class="link" href="extcommands.html" title="Externe Befehle">externen Befehlen</a> an Icinga über Shell-Scripts</p>
</li>
<li class="listitem">
<p>Ausführen von Plugins auf entfernten Hosts mit Hilfe des <a class="link" href="addons.html#addons-nrpe">NRPE Addons</a> oder
einer anderen Methode</p>
</li>
<li class="listitem">
<p>Überprüfen des Zustands des Icinga-Prozesses mit dem <span class="emphasis"><em>check_nagios</em></span> Plugin</p>
</li>
</ul></div>
<p><a name="redundancy-samples"></a> <span class="bold"><strong>Beispiel-Scripte</strong></span></p>
<p>Jedes dieser Beispiel-Scripte, die wir in dieser Dokumentation benutzen, finden Sie im
<span class="emphasis"><em>eventhandlers/</em></span>-Unterverzeichnis der Icinga-Distribution. Vielleicht müssen Sie sie modifizieren,
damit sie auf Ihrem System funktionieren...</p>
<p><a name="redundancy-scenario_1"></a> <span class="bold"><strong>Szenario 1 - Redundante Überwachung</strong></span></p>
<p><span class="bold"><strong>Einführung</strong></span></p>
<p>Dies ist eine einfache (und harmlose) Methode, redundante Überwachungs-Hosts zu implementieren, und es wird nur gegen eine
begrenzte Anzahl von Ausfällen schützen. Komplexere Setups werden benötigt, um intelligentere Redundanz, bessere Redundanz über
verschiedene Netzwerk-Segmente hinweg zu bieten.</p>
<p><span class="bold"><strong>Ziele</strong></span></p>
<p>Das Ziel dieser Art von Redundanz-Implementierung ist einfach. Sowohl der "Master"- als auch der "Slave"-Host überwachen
die gleichen Hosts und Services auf dem Netzwerk. Unter normalen Umständen wird nur der "Master"-Host Benachrichtigungen an
Kontakte versenden. Wir wollen, dass der "Slave"-Host die Benachrichtigung von Kontakten übernimmt, wenn:</p>
<div class="orderedlist"><ol class="orderedlist" type="1">
<li class="listitem">
<p>der "Master"-Host, auf dem Icinga läuft, "down" ist oder...</p>
</li>
<li class="listitem">
<p>der Icinga-Prozess auf dem "Master"-Host aus irgendeinem Grund stoppt</p>
</li>
</ol></div>
<p><span class="bold"><strong>Netzwork-Layout-Diagramm</strong></span></p>
<p>Das untenstehende Diagramm zeigt ein sehr simples Netzwerk-Setup. Bei diesem Szenario nehmen wir an, dass auf den Hosts A
und E Icinga läuft und alle gezeigten Hosts überwacht werden. Host A ist der "Master"-Host und Host E der
"Slave"-Host.</p>
<div class="informaltable">
<table border="1">
<colgroup><col></colgroup>
<tbody><tr><td><p> <span class="inlinemediaobject"><img src="../images/redundancy.png"></span> </p></td></tr></tbody>
</table>
</div>
<p><span class="bold"><strong>anfängliche Programmeinstellungen</strong></span></p>
<p>Auf dem Slave-Host (Host E) wird die ursprüngliche <a class="link" href="configmain.html#configmain-enable_notifications">enable_notifications</a>-Direktive deaktiviert, so dass dadurch der Versand von
Host- oder Service-Benachrichtigungen verhindert wird. Sie sollten auch sicherstellen, dass die <a class="link" href="configmain.html#configmain-check_external_commands">check_external_commands</a>-Direktive deaktiviert ist. Das war einfach
genug...</p>
<p><span class="bold"><strong>anfängliche Konfiguration</strong></span></p>
<p>Als nächstes sollten wir die Unterschiede zwischen den <a class="link" href="configobject.html" title="Überblick Objektkonfiguration">Objekt-Konfigurationsdatei</a> von
Master- und Slave-Host(s) betrachten...</p>
<p>Wir gehen davon aus, dass Sie den Master-Host (Host A) so konfiguriert haben, dass er alle Services auf den gezeigten
Hosts des Diagramms überwacht. Der Slave-Host (Host E) sollte die gleichen Hosts und Services überwachen, mit folgenden Zusätzen
in der Konfigurationsdatei...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>Die Host-Definition für Host A (in der Host-Konfigurationsdatei von Host E) sollte einen Host-<a class="link" href="eventhandlers.html" title="Eventhandler">Eventhandler</a> enthalten. Der Name für den Host-Eventhandler lautet <span class="color">handle-master-host-event</span>.</p>
</li>
<li class="listitem">
<p>Die Konfigurationsdatei auf Host E enthält einen Service, der den Status des Icinga-Prozesses auf Host A prüft.
Lassen Sie uns annehmen, dass diese Prüfung das <span class="emphasis"><em>check_nagios</em></span>-Plugin auf Host A aufruft. Das kann durch
eine der in den <span class="bold"><strong>FAQ</strong></span> beschriebenen Methoden erfolgen.</p>
</li>
<li class="listitem">
<p>Die Service-Definition für den Icinga-Prozess auf Host A sollte einen <a class="link" href="eventhandlers.html" title="Eventhandler">Eventhandler</a>-Eintrag enthalten. Als Namen für diese Service-Eventhandler wählen wir <span class="color">handle-master-proc-event</span>.</p>
</li>
</ul></div>
<p>Es ist wichtig anzumerken, dass Host A (der Master-Host) keine Ahnung von Host E (dem Slave-Host) hat. In diesem Szenario
besteht ganz einfach keine Notwendigkeit dazu. Natürlich können Sie von Host A Services auf Host E überwachen, aber das hat
nichts mit der Implementierung von Redundanz zu tun...</p>
<p><span class="bold"><strong>Eventhandler-Befehlsdefinitionen</strong></span></p>
<p>Wir müssen kurz innehalten und beschreiben, wie die Befehlsdefinitionen für die Eventhandler auf dem Slave-Host aussehen.
Hier ist ein Beispiel...</p>
<pre class="screen"> define command{
command_name handle-master-host-event
command_line /usr/local/icinga/libexec/eventhandlers/handle-master-host-event $HOSTSTATE$ $HOSTSTATETYPE$
}
define command{
command_name handle-master-proc-event
command_line /usr/local/icinga/libexec/eventhandlers/handle-master-proc-event $SERVICESTATE$ $SERVICESTATETYPE$
}</pre>
<p>Dies setzt voraus, dass Sie die Eventhandler-Scripte im Verzeichnis
<span class="emphasis"><em>/usr/local/icinga/libexec/eventhandlers</em></span> abgelegt haben. Sie können sie ablegen, wohin Sie wollen, aber dann
müssen Sie die beigefügten Beispiele anpassen.</p>
<p><span class="bold"><strong>Eventhandler-Scripte</strong></span></p>
<p>Okay, lassen Sie uns nun einen Blick darauf werden, wie die Eventhandler-Scripte aussehen...</p>
<p>Host-Eventhandler (<span class="color">handle-master-host-event</span>):</p>
<pre class="screen"> #!/bin/sh
# Only take action on hard host states...
case "$2" in
HARD)
case "$1" in
DOWN)
# The master host has gone down!
# We should now become the master host and take
# over the responsibilities of monitoring the
# network, so enable notifications...
/usr/local/icinga/libexec/eventhandlers/enable_notifications
;;
UP)
# The master host has recovered!
# We should go back to being the slave host and
# let the master host do the monitoring, so
# disable notifications...
/usr/local/icinga/libexec/eventhandlers/disable_notifications
;;
esac
;;
esac
exit 0</pre>
<p>Service-Eventhandler (<span class="color">handle-master-proc-event</span>):</p>
<pre class="screen"> #!/bin/sh
# Only take action on hard service states...
case "$2" in
HARD)
case "$1" in
CRITICAL)
# The master Icinga process is not running!
# We should now become the master host and
# take over the responsibility of monitoring
# the network, so enable notifications...
/usr/local/icinga/libexec/eventhandlers/enable_notifications
;;
WARNING)
UNKNOWN)
# The master Icinga process may or may not
# be running.. We won't do anything here, but
# to be on the safe side you may decide you
# want the slave host to become the master in
# these situations...
;;
OK)
# The master Icinga process running again!
# We should go back to being the slave host,
# so disable notifications...
/usr/local/icinga/libexec/eventhandlers/disable_notifications
;;
esac
;;
esac
exit 0</pre>
<p><span class="bold"><strong>Was tun sie für uns</strong></span></p>
<p>Auf dem Slave-Host (Host E) sind anfänglich die Benachrichtigungen deaktiviert, so dass er keine Host- oder
Service-Benachrichtigungen versendet, solange der Icinga-Prozess auf dem Master-Host (Host A) noch läuft.</p>
<p>Der Icinga-Prozess auf dem Slave-host (Host E) wird zum Master-Host, wenn...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>der Master-Host (Host A) "down" geht und der <span class="emphasis"><em> <span class="color">handle-master-host-event</span> </em></span> -Host-Eventhandler ausgeführt wird.</p>
</li>
<li class="listitem">
<p>der Icinga-Prozess auf dem Master-Host (Host A) aufhört zu arbeiten und der <span class="emphasis"><em> <span class="color">handle-master-proc-event</span> </em></span> -Service-Eventhandler ausgeführt wird.</p>
</li>
</ul></div>
<p>Wenn bei dem Icinga-Prozess auf dem Slave-Host (Host E) Benachrichtigungen aktiviert sind, kann er
Benachrichtigungen über jegliche Host- und Service-Probleme und Erholungen versenden. An diesem Punkt hat Host E die
Verantwortlichkeiten über die Benachrichtigung von Kontakten über Host- und Service-Probleme übernommen!</p>
<p>Der Icinga-Prozess auf Host E wird wieder zum Host-Slave, wenn...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>sich Host A wieder erholt und der <span class="emphasis"><em> <span class="color">handle-master-host-event</span> </em></span> -Host-Eventhandler ausgeführt wird.</p>
</li>
<li class="listitem">
<p>sich der Icinga-Prozess auf Host A wieder erholt und den <span class="emphasis"><em> <span class="color">handle-master-proc-event</span> </em></span> -Service-Eventhandler ausführt.</p>
</li>
</ul></div>
<p>Wenn bei dem Icinga-Prozess auf dem Slave-Host (Host E) Benachrichtigungen deaktiviert sind, wird er keine
Benachrichtigungen mehr über Host- und Service-Probleme und Erholungen versenden. An diesem Punkt hat Host E die
Verantwortlichkeiten über die Benachrichtigung von Kontakten über Host- und Service-Probleme an Host A übergeben. Alles ist
wieder so, als wir angefangen haben!</p>
<p><span class="bold"><strong>Zeitverzögerungen</strong></span></p>
<p>Redundanz bei Icinga ist in keinster Weise perfekt. Eins der offenkundigeren Probleme ist die Verzögerung zwischen
dem Ausfall von Host A und der Übernahme durch Host E. Das ist bedingt durch folgende Dinge...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>die Zeit zwischen dem Ausfall des Master-Host und dem ersten Mal, dass der Slave-Host ein Problem entdeckt</p>
</li>
<li class="listitem">
<p>die Zeit, die benötigt wird, um festzustellen, dass der Master-Host wirklich ein Problem hat (unter Verwendung von
Host- oder Service-Prüfwiederholungen auf dem Slave-Host)</p>
</li>
<li class="listitem">
<p>die Zeit zwischen der Ausführung des Eventhandlers und der Zeit, zu der Icinga das nächste Mal auf externe
Befehle prüft</p>
</li>
</ul></div>
<p>Sie können diese Verzögerung minimieren durch...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>eine hohe Frequenz von (Wiederholungs-) Prüfungen für Services auf Host E. Das kann durch die
<span class="emphasis"><em>check_interval</em></span>- und <span class="emphasis"><em>retry_interval</em></span>-Optionen in jeder Service-Definition erreicht
werden.</p>
</li>
<li class="listitem">
<p>eine Zahl der Host-Wiederholungsprüfungen für Host A (auf Host E), die eine schnelle Erkennung von Host-Problemen
erlaubt. Das wird erreicht durch das <span class="emphasis"><em>max_check_attempts</em></span>-Argument in der Host-Definition.</p>
</li>
<li class="listitem">
<p>erhöhen der Frequenz der <a class="link" href="extcommands.html" title="Externe Befehle">external command</a>-Prüfungen auf Host E. Dies wird erreicht
durch die Anpassung der <a class="link" href="configmain.html#configmain-command_check_interval">command_check_interval</a>-Option in der
Hauptkonfigurationsdatei.</p>
</li>
</ul></div>
<p>Wenn sich Icinga auf Host A erholt, gibt es ebenfalls eine Verzögerung, bevor Host E wieder zu einem Slave-Host
wird. Das wird durch folgende Dinge beeinflusst...</p>
<div class="itemizedlist"><ul class="itemizedlist" type="disc">
<li class="listitem">
<p>die Zeit zwischen der Erholung des Master-Hosts und der Zeit, zu der der Icinga-Prozess auf Host E die Erholung
erkennt</p>
</li>
<li class="listitem">
<p>die Zeit zwischen der Ausführung des Eventhandlers auf Host A und der Zeit, zu der Icinga-Prozess auf Host E
das nächste Mal auf externe Befehle prüft</p>
</li>
</ul></div>
<p>Die genaue Verzögerung zwischen dem Übergang der Verantwortlichkeiten hängt davon ab, wieviele Services Sie definiert
haben, dem Intervall, in dem Services geprüft werden, und einer Menge pures Glück. Auf jeden Falls ist es besser als
nichts.</p>
<p><span class="bold"><strong>Spezialfälle</strong></span></p>
<p>Eins sollten Sie beachten: Wenn Host A "down" geht, werden bei Host E die Benachrichtigungen aktiviert und er übernimmt
die Verantwortung für das Informieren der Kontakte bei Problemen. Wenn sich Host A wieder erholt, werden bei Host E die
Benachrichtigungen deaktiviert. Falls der Icinga-Prozess - wenn sich Host A erholt - auf Host A nicht sauber startet,
gibt es eine Zeitspanne, während der keiner der beiden Hosts die Kontakte über Probleme informiert! Glücklicherweise
berücksichtigt die Service-Prüflogik in Icinga diesen Umstand. Das nächste Mal, wenn der Icinga-Prozess auf Host E
den Status des Icinga-Prozesses auf Host A prüft, wird er feststellen, dass dieser nicht läuft. Auf Host E werden dann
wieder die Benachrichtigungen aktiviert und er wird erneut die Verantwortung für die Benachrichtigung der Kontakte
übernehmen.</p>
<p>Der exakte Wert für die Zeit, während der keiner der Hosts das Netzwerk überwacht, ist schwer zu ermitteln. Offensichtlich
kann diese Zeit durch die Erhöhung der Frequenz von Service-Prüfungen (auf Host E) für Host A minimiert werden. Der Rest ist
purer Zufall, aber die gesamte "Blackout"-Zeit sollte nicht allzu hoch sein.</p>
<p><a name="redundancy-scenario_2"></a> <span class="bold"><strong>Szenario 2 - Failover-Überwachung</strong></span></p>
<p><span class="bold"><strong>Einführung</strong></span></p>
<p>Failover-Überwachung ist ähnlich wie die redundante Überwachung (wie beschrieben in <a class="link" href="redundancy.html#redundancy-scenario_1">Szenario 1</a>).</p>
<p><span class="bold"><strong>Ziele</strong></span></p>
<p>Das grundlegende Ziel der Failover-Überwachung besteht darin, dass der Icinga-Prozess auf dem Slave-Host untätig
ist, während der Icinga-Prozess auf dem Master-Host läuft. Wenn der Prozess auf dem Master-Host stoppt (oder der Host
"down" geht), übernimmt der Icinga-Prozess auf dem Slave-Host die gesamte Überwachung.</p>
<p>Während es Ihnen die in <a class="link" href="redundancy.html#redundancy-scenario_1">Szenario 1</a> beschriebene Methode erlaubt, weiterhin
Benachrichtigungen zu erhalten, wenn der Master-Host "down" geht, gibt es einige Fallen. Das größte Problem besteht darin, dass
der Slave-Host die gleichen Hosts und Services wie der Master <span class="emphasis"><em>zur gleichen Zeit wie der Master</em></span> überwacht!
Dies kann Probleme durch übermäßigen Traffic und Load auf den überwachten Maschinen verursachen, wenn Sie viele Services
definiert haben. Hier nun, wie Sie das Problem umgehen können.</p>
<p><span class="bold"><strong>Initiale Programm-Einstellungen</strong></span></p>
<p>Deaktivieren Sie aktive Service-Prüfungen und Benachrichtigungen auf dem Slave-Host durch die <a class="link" href="configmain.html#configmain-execute_service_checks">execute_service_checks</a>- und die <a class="link" href="configmain.html#configmain-enable_notifications">enable_notifications</a>-Direktiven. Dies wird den Slave-Host davon abhalten,
Services und Hosts zu überwachen und Benachrichtigungen zu versenden, während der Icinga-Prozess auf dem Master-Host noch
läuft. Stellen Sie außerdem sicher, dass die <a class="link" href="configmain.html#configmain-check_external_commands">check_external_commands</a>-Direktive auf dem Slave-Host aktiviert ist.</p>
<p><span class="bold"><strong>Master-Prozess-Prüfungen</strong></span></p>
<p>Setzen Sie einen cron-Job auf dem Slave-Host auf, der periodisch (sagen wir jede Minute) läuft und den Status des
Icinga-Prozesses auf dem Master-Host (mit dem <span class="emphasis"><em>check_nrpe</em></span> auf dem Slave-Host und den <a class="link" href="addons.html#addons-nrpe">nrpe daemon</a> und <span class="emphasis"><em>check_nagios</em></span>-Plugins auf dem Master-Host) prüft. Das Script
sollte den Return-Code des <span class="emphasis"><em>check_nrpe-Plugins</em></span> prüfen. Falls es einen nicht-OK-Status zurückliefert, sollte
das Script den entsprechenden Befehl an das <a class="link" href="configmain.html#configmain-command_file">external command file</a> senden, um
sowohl die Benachrichtigungen als auch die aktiven Service-Prüfungen zu aktivieren. Falls das Plugin einen OK-Status
zurückliefert, sollte das Script Befehle an das external command file senden, um sowohl Benachrichtigungen als auch aktive
Prüfungen zu deaktivieren.</p>
<p>Auf diese Weise läuft jeweils nur ein Prozess, der Hosts und Services prüft, was wesentlich effizienter ist als alles
doppelt zu überwachen.</p>
<p>Auch von Interesse: Sie müssen <span class="emphasis"><em>nicht</em></span> wie in <a class="link" href="redundancy.html#redundancy-scenario_1">Szenario 1</a>
beschrieben die Host- und Service-Handler definieren, weil die Dinge anders behandelt werden.</p>
<p><span class="bold"><strong>Zusätzliche Themen</strong></span></p>
<p>An diesem Punkt haben Sie ein sehr einfaches Failover-Überwachungs-Setup implementiert. Trotzdem gibt es einen weiteren
Punkt, den Sie berücksichtigen sollten, damit die Dinge besser laufen.</p>
<p>Das große Problem dabei, wie die Dinge bisher konfiguriert sind, besteht darin, dass der Slave-Host nicht den aktuellen
Status von Hosts und Services kennt, wenn er die Überwachung übernimmt. Ein Weg, dieses Problem zu lösen, ist es, die <a class="link" href="configmain.html#configmain-ocsp_command">ocsp command</a>-Option auf dem Master-Host zu aktivieren und alle Service-Prüfergebnisse
mit dem <a class="link" href="addons.html#addons-nsca">nsca Addon</a> an den Slave-Host zu schicken. Der Slave-Host wird dann aktuelle
Status-Informationen für alle Services haben, wenn er die Überwachung übernimmt. Weil aktive Service-Prüfungen auf dem
Slave-Host nicht aktiviert sind, werden sie nicht ausgeführt. Host-Prüfungen hingegen werden nach Bedarf ausgeführt. Das
bedeutet, dass sowohl Master- als auch Slave-Host Host-Prüfungen ausführen, wenn sie benötigt werden, was kein Problem
darstellen sollte, weil die Mehrzahl der Überwachung Service-Prüfungen betrifft.</p>
<p>Das ist eigentlich alles, was das Setup betrifft.</p>
<a class="indexterm" name="id5597718"></a>
<a class="indexterm" name="id5597726"></a>
<a class="indexterm" name="id5597736"></a>
<a class="indexterm" name="id5597746"></a>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="distributed.html">Zurück</a> </td>
<td width="20%" align="center"><a accesskey="u" href="ch06.html">Nach oben</a></td>
<td width="40%" align="right"> <a accesskey="n" href="flapping.html">Weiter</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Verteilte Überwachung </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Zum Anfang</a></td>
<td width="40%" align="right" valign="top"> Erkennung und Behandlung von Status-Flattern</td>
</tr>
</table>
</div>
<P class="copyright">© 2009-2010 Icinga Development Team, http://www.icinga.org</P>
</body>
</html>
|
