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
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>7.7. Redundante und Failover-Netzwerk-Überwachung</title>
<link rel="stylesheet" href="../stylesheets/icinga-docs.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.75.1">
<meta name="keywords" content="Supervision, Icinga, Nagios, Linux">
<link rel="home" href="index.html" title="Icinga Version 1.14 Dokumentation">
<link rel="up" href="ch07.html" title="Kapitel 7. Fortgeschrittene Themen">
<link rel="prev" href="distributed.html" title="7.6. Verteilte Überwachung">
<link rel="next" href="flapping.html" title="7.8. Erkennung und Behandlung von Status-Flattern">
<script src="../js/jquery-min.js" type="text/javascript"></script><script src="../js/icinga-docs.js" type="text/javascript"></script>
</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">7.7. 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 7. 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="7.7. Redundante und Failover-Netzwerk-Überwachung">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="redundancy"></a>7.7. Redundante und Failover-Netzwerk-Überwachung</h2></div></div></div>
<div class="toc"><dl>
<dt><span class="section">7.7.1. <a href="redundancy.html#introduction">Einführung</a></span></dt>
<dt><span class="section">7.7.2. <a href="redundancy.html#redprerequisites">Voraussetzungen</a></span></dt>
<dt><span class="section">7.7.3. <a href="redundancy.html#samplescripts">Beispielscripts</a></span></dt>
<dt><span class="section">7.7.4. <a href="redundancy.html#redundantmonitoring">Scenario 1 - Redundante Üverwachung</a></span></dt>
<dt><span class="section">7.7.5. <a href="redundancy.html#failovermonitoring">Scenario 2 - Failover Überwachung</a></span></dt>
</dl></div>
<div class="section" title="7.7.1. Einführung">
<div class="titlepage"><div><div><h3 class="title">
<a name="introduction"></a>7.7.1. Einführung</h3></div></div></div>
<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"><font color="red"> <span class="bold"><strong>Anmerkung:</strong></span> </font></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#redprerequisites" title="7.7.2. Voraussetzungen">Voraussetzungen</a> vertraut sind. Redundanz ist ein relativ komplexes Thema und es ist noch
schwieriger, es zu implementieren.</p>
</div>
<div class="section" title="7.7.2. Voraussetzungen">
<div class="titlepage"><div><div><h3 class="title">
<a name="redprerequisites"></a>7.7.2. Voraussetzungen</h3></div></div></div>
<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="7.3. Eventhandler">Eventhandlern</a> für Hosts und Services</p>
</li>
<li class="listitem">
<p>Erteilen von <a class="link" href="extcommands.html" title="7.1. 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>
</div>
<div class="section" title="7.7.3. Beispielscripts">
<div class="titlepage"><div><div><h3 class="title">
<a name="samplescripts"></a>7.7.3. Beispielscripts</h3></div></div></div>
<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>
</div>
<div class="section" title="7.7.4. Scenario 1 - Redundante Üverwachung">
<div class="titlepage"><div><div><h3 class="title">
<a name="redundantmonitoring"></a>7.7.4. <a name="redundancy-scenario_1"></a>Scenario 1 - Redundante Üverwachung</h3></div></div></div>
<div class="toc"><dl>
<dt><span class="section">7.7.4.1. <a href="redundancy.html#redundantmonitoring-introduction">Einführung</a></span></dt>
<dt><span class="section">7.7.4.2. <a href="redundancy.html#redundantmonitoring-goals">Ziele</a></span></dt>
<dt><span class="section">7.7.4.3. <a href="redundancy.html#redundantmonitoring-networklayoutdiagram">Netzwork-Layout-Diagramm</a></span></dt>
<dt><span class="section">7.7.4.4. <a href="redundancy.html#redundantmonitoring-initialprogramsettings">anfängliche Programmeinstellungen</a></span></dt>
<dt><span class="section">7.7.4.5. <a href="redundancy.html#redundantmonitoring-initialconfig">anfängliche Konfiguration</a></span></dt>
<dt><span class="section">7.7.4.6. <a href="redundancy.html#redundantmonitoring-eventhandlercmddefinition">Eventhandler-Befehlsdefinitionen</a></span></dt>
<dt><span class="section">7.7.4.7. <a href="redundancy.html#redundantmonitoring-eventhandlerscript">Eventhandler-Scripte</a></span></dt>
<dt><span class="section">7.7.4.8. <a href="redundancy.html#redundantmonitoring-usage">Was tun sie für uns</a></span></dt>
<dt><span class="section">7.7.4.9. <a href="redundancy.html#redundantmonitoring-timelags">Zeitverzögerungen</a></span></dt>
<dt><span class="section">7.7.4.10. <a href="redundancy.html#redundantmonitoring-specialcases">Spezialfälle</a></span></dt>
</dl></div>
<div class="section" title="7.7.4.1. Einführung">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-introduction"></a>7.7.4.1. Einführung</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.4.2. Ziele">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-goals"></a>7.7.4.2. Ziele</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.4.3. Netzwork-Layout-Diagramm">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-networklayoutdiagram"></a>7.7.4.3. Netzwork-Layout-Diagramm</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.4.4. anfängliche Programmeinstellungen">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-initialprogramsettings"></a>7.7.4.4. anfängliche Programmeinstellungen</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.4.5. anfängliche Konfiguration">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-initialconfig"></a>7.7.4.5. anfängliche Konfiguration</h4></div></div></div>
<p>Als nächstes sollten wir die Unterschiede zwischen den <a class="link" href="configobject.html" title="3.3. Ü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="7.3. Eventhandler">Eventhandler</a> enthalten. Der Name für den Host-Eventhandler lautet <span class="color"><font color="red">handle-master-host-event</font></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="7.3. Eventhandler">Eventhandler</a>-Eintrag enthalten. Als Namen für diese Service-Eventhandler wählen wir <span class="color"><font color="red">handle-master-proc-event</font></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>
</div>
<div class="section" title="7.7.4.6. Eventhandler-Befehlsdefinitionen">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-eventhandlercmddefinition"></a>7.7.4.6. Eventhandler-Befehlsdefinitionen</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.4.7. Eventhandler-Scripte">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-eventhandlerscript"></a>7.7.4.7. Eventhandler-Scripte</h4></div></div></div>
<p>Okay, lassen Sie uns nun einen Blick darauf werden, wie die Eventhandler-Scripte aussehen...</p>
<p>Host-Eventhandler (<span class="color"><font color="red">handle-master-host-event</font></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"><font color="red">handle-master-proc-event</font></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>
</div>
<div class="section" title="7.7.4.8. Was tun sie für uns">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-usage"></a>7.7.4.8. Was tun sie für uns</h4></div></div></div>
<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"><font color="red">handle-master-host-event</font></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"><font color="red">handle-master-proc-event</font></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"><font color="red">handle-master-host-event</font></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"><font color="red">handle-master-proc-event</font></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>
</div>
<div class="section" title="7.7.4.9. Zeitverzögerungen">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-timelags"></a>7.7.4.9. Zeitverzögerungen</h4></div></div></div>
<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="7.1. 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>
</div>
<div class="section" title="7.7.4.10. Spezialfälle">
<div class="titlepage"><div><div><h4 class="title">
<a name="redundantmonitoring-specialcases"></a>7.7.4.10. Spezialfälle</h4></div></div></div>
<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>
</div>
</div>
<div class="section" title="7.7.5. Scenario 2 - Failover Überwachung">
<div class="titlepage"><div><div><h3 class="title">
<a name="failovermonitoring"></a>7.7.5. Scenario 2 - Failover Überwachung</h3></div></div></div>
<div class="toc"><dl>
<dt><span class="section">7.7.5.1. <a href="redundancy.html#failovermonitoring-introduction">Einführung</a></span></dt>
<dt><span class="section">7.7.5.2. <a href="redundancy.html#failovermonitoring-goals">Ziele</a></span></dt>
<dt><span class="section">7.7.5.3. <a href="redundancy.html#failovermonitoring-initialprogramsettings">Initiale Programm-Einstellungen</a></span></dt>
<dt><span class="section">7.7.5.4. <a href="redundancy.html#failovermonitoring-masterprocesscheck">Master-Prozess-Prüfungen</a></span></dt>
<dt><span class="section">7.7.5.5. <a href="redundancy.html#failovermonitoring-additionalissues">Zusätzliche Themen</a></span></dt>
</dl></div>
<div class="section" title="7.7.5.1. Einführung">
<div class="titlepage"><div><div><h4 class="title">
<a name="failovermonitoring-introduction"></a>7.7.5.1. Einführung</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.5.2. Ziele">
<div class="titlepage"><div><div><h4 class="title">
<a name="failovermonitoring-goals"></a>7.7.5.2. Ziele</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.5.3. Initiale Programm-Einstellungen">
<div class="titlepage"><div><div><h4 class="title">
<a name="failovermonitoring-initialprogramsettings"></a>7.7.5.3. Initiale Programm-Einstellungen</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.5.4. Master-Prozess-Prüfungen">
<div class="titlepage"><div><div><h4 class="title">
<a name="failovermonitoring-masterprocesscheck"></a>7.7.5.4. Master-Prozess-Prüfungen</h4></div></div></div>
<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>
</div>
<div class="section" title="7.7.5.5. Zusätzliche Themen">
<div class="titlepage"><div><div><h4 class="title">
<a name="failovermonitoring-additionalissues"></a>7.7.5.5. Zusätzliche Themen</h4></div></div></div>
<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="idm139734665907264"></a>
<a class="indexterm" name="idm139734665905584"></a>
<a class="indexterm" name="idm139734665903840"></a>
<a class="indexterm" name="idm139734665902224"></a>
</div>
</div>
</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="ch07.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">7.6. 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"> 7.8. Erkennung und Behandlung von Status-Flattern</td>
</tr>
</table>
</div>
<P class="copyright">© 1999-2009 Ethan Galstad, 2009-2017 Icinga Development Team, https://www.icinga.com</P>
</body>
</html>
|
