{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modellierung von ausfallsicheren Clustern basierend auf PostgreSQL und Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h1>\n

<\/p>\n

Vor einiger Zeit wurde ich mit der Aufgabe betraut, ein ausfallsicheres Cluster zu entwickeln f\u00fcr PostgreSQL<\/a><\/noindex>, das in mehreren Rechenzentren betrieben wird, die durch Glasfaser innerhalb einer Stadt verbunden sind und in der Lage sind, einen Ausfall (z. B. Stromausfall) eines Rechenzentrums zu \u00fcberstehen. Als Software, die f\u00fcr die Ausfallsicherheit verantwortlich ist, habe ich mich f\u00fcr Pacemaker<\/a><\/noindex>entschieden, da es sich um die offizielle L\u00f6sung von RedHat zur Erstellung von ausfallsicheren Clustern handelt. Sie zeichnet sich dadurch aus, dass RedHat Unterst\u00fctzung bietet und dass sie modular (universell) ist. Damit kann die Ausfallsicherheit nicht nur f\u00fcr PostgreSQL, sondern auch f\u00fcr andere Dienste gew\u00e4hrleistet werden, entweder durch die Verwendung standardm\u00e4\u00dfiger Module oder durch die Entwicklung spezifischer Module f\u00fcr besondere Anforderungen.<\/p>\n

<\/p>\n

Zu dieser L\u00f6sung stellt sich die berechtigte Frage: Wie hoch ist die Ausfallsicherheit eines hochverf\u00fcgbaren Clusters? Um dies zu erforschen, habe ich eine Testumgebung entwickelt, die verschiedene Ausf\u00e4lle an den Knoten des Clusters simuliert, auf die Wiederherstellung der Funktionalit\u00e4t wartet, den ausgefallenen Knoten wiederherstellt und die Tests in einer Schleife fortsetzt. Urspr\u00fcnglich nannte sich dieses Projekt hapgsql, aber mit der Zeit langweilte mich der Name, der nur einen Vokal enth\u00e4lt. Daher begann ich, hochverf\u00fcgbare Datenbanken (und die darauf verweisenden Float-IPs) nach krogan<\/strong> (einem Charakter aus einem Videospiel, bei dem alle wichtigen Organe doppelt vorhanden sind), w\u00e4hrend ich die Knoten, Cluster und das Projekt selbst nach tuchanka<\/strong> (dem Planeten, auf dem die Kroganer leben) benannte.<\/p>\n

<\/p>\n

Jetzt hat die Gesch\u00e4ftsf\u00fchrung erlaubt, das Projekt unter der MIT-Lizenz f\u00fcr die Open-Source-Community zu \u00f6ffnen.<\/a><\/noindex>Die README wird bald ins Englische \u00fcbersetzt (da erwartet wird, dass die Hauptnutzer Entwickler von Pacemaker und PostgreSQL sind), und die alte russische Version der README habe ich beschlossen, (teilweise) in Form dieses Artikels zu gestalten.<\/p>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/a><\/noindex><\/p>\n

Cluster werden auf virtuellen Maschinen VirtualBox<\/a><\/noindex>. Es werden insgesamt 12 VMs (insgesamt 36GiB) bereitgestellt, die 4 hochverf\u00fcgbare Cluster bilden (verschiedene Variationen). Die ersten beiden Cluster bestehen aus zwei PostgreSQL-Servern, die in verschiedenen Rechenzentren platziert sind, und einem gemeinsamen Server Witness<\/em> c Quorum-Ger\u00e4t<\/strong> (untergebracht auf einer kosteng\u00fcnstigen VM in einem dritten Rechenzentrum), das Unklarheiten aufl\u00f6st 50%\/50%<\/strong>, indem es seine Stimme einer der Seiten gibt. Das dritte Cluster verteilt sich auf drei Rechenzentren: ein Master, zwei Slave-Server, ohne Quorum-Ger\u00e4t<\/strong>. Das vierte Cluster besteht aus vier PostgreSQL-Servern, zwei pro Rechenzentrum: ein Master, die anderen Replikate, und nutzt ebenfalls Witness<\/em> c Quorum-Ger\u00e4t<\/strong>. Das vierte kann den Ausfall von zwei Servern oder eines Rechenzentrums \u00fcberstehen. Diese L\u00f6sung kann, wenn n\u00f6tig, auf eine gr\u00f6\u00dfere Anzahl von Replikaten skaliert werden.<\/p>\n

<\/p>\n

Zeitdienst ntpd<\/a><\/noindex> wurde ebenfalls f\u00fcr Hochverf\u00fcgbarkeit neu konfiguriert, jedoch verwendet es die Methode des ntpd<\/code> (Orphan-Modus<\/em>). Der gemeinsame Server Witness<\/em> fungiert als zentraler NTP-Server, der seine Zeit an alle Cluster verteilt und somit alle Server synchronisiert. Wenn Witness<\/em> ausfallen oder isoliert werden, dann wird einer der Cluster-Server (innerhalb des Clusters) die Zeit zur Verf\u00fcgung stellen. Der unterst\u00fctzende Cache HTTP-Proxy<\/strong> ist ebenfalls aktiviert auf Witness<\/em>, wodurch die anderen virtuellen Maschinen Zugriff auf die Yum-Repositories haben. In der Praxis werden solche Dienste wie Zeitserver und Proxy wahrscheinlich auf dedizierten Servern gehostet, w\u00e4hrend sie in der Testumgebung auf Witness<\/em> nur zur Einsparung von virtuellen Maschinen und Platz platziert sind.<\/p>\n

<\/p>\n

Versionen<\/h1>\n

<\/p>\n

v0. Funktioniert mit CentOS 7 und PostgreSQL 11 auf VirtualBox 6.1.<\/p>\n

<\/p>\n

Clusterstruktur<\/h1>\n

<\/p>\n

Alle Cluster sind f\u00fcr die Bereitstellung in mehreren Rechenzentren konzipiert, in einem flachen Netzwerk verbunden und m\u00fcssen den Ausfall oder die Netzwerkisolierung eines Rechenzentrums \u00fcberstehen. Daher nicht erstellt werden kann<\/strong> wird zur Abwehr von Split-Brain<\/strong> die standardm\u00e4\u00dfige Pacemaker-Technologie verwendet, die als STONITH<\/em> (\u201eShoot The Other Node In The Head\u201c) oder Fencing<\/em>. Das Prinzip: Wenn Knoten in einem Cluster den Verdacht haben, dass bei einem Knoten etwas nicht stimmt, dieser nicht antwortet oder sich fehlerhaft verh\u00e4lt, dann schalten sie ihn \u00fcber externe Ger\u00e4te, wie beispielsweise die IPMI-Management-Karte oder eine USV, zwangsweise ab. Dies funktioniert jedoch nur, wenn im Falle eines Einzelserverausfalls IPMI oder die USV weiterhin betriebsbereit sind. Hier wird ein Schutz gegen einen viel katastrophaleren Ausfall geplant, bei dem das gesamte Rechenzentrum ausf\u00e4llt (zum Beispiel durch Stromausfall). Bei solch einem Ausfall funktionieren auch die stonith<\/em>-Ger\u00e4te (IPMI, USV usw.) nicht mehr.<\/p>\n

<\/p>\n

Stattdessen basiert das System auf der Idee des Quorums. Alle Knoten haben eine Stimme, und nur die Knoten, die mehr als die H\u00e4lfte aller Knoten sehen, k\u00f6nnen arbeiten. Diese Anzahl, die \u201eH\u00e4lfte+1\u201c genannt wird, ist das Quorum<\/strong>. Wenn das Quorum nicht erreicht wird, entscheidet der Knoten, dass er in einer Netzwerkisolierung ist und seine Ressourcen abschalten muss, d.h. dies ist eine Schutzma\u00dfnahme gegen Split-Brain<\/strong>. Wenn die Software, die f\u00fcr solch ein Verhalten verantwortlich ist, nicht funktioniert, wird ein Watchdog eingreifen, beispielsweise auf Basis von IPMI.<\/p>\n

<\/p>\n

Wenn die Anzahl der Knoten gerade ist (Cluster in zwei Rechenzentren), kann die sogenannte Unbestimmtheit auftreten 50%\/50%<\/strong> (fifty-fifty<\/em>), wenn die Netzwerkisolierung das Cluster genau in zwei H\u00e4lften teilt. Daher wird bei einer geraden Anzahl von Knoten hinzugef\u00fcgt Quorum-Ger\u00e4t<\/strong> \u2014 ein unauff\u00e4lliger Daemon, der auf der g\u00fcnstigsten virtuellen Maschine im dritten Rechenzentrum gestartet werden kann. Er gibt seine Stimme einem der Segmente (das er sieht) und l\u00f6st damit die 50%\/50% Unbestimmtheit auf. Der Server, auf dem das Quorum-Ger\u00e4t laufen wird, habe ich genannt Witness<\/em> (Terminologie aus repmgr, hat mir gefallen).<\/p>\n

<\/p>\n

Ressourcen k\u00f6nnen von einem Ort zum anderen bewegt werden, zum Beispiel von defekten Servern zu funktionierenden, oder auf Befehl von Systemadministratoren. Damit die Kunden wissen, wo sich die ben\u00f6tigten Ressourcen befinden (wozu sie sich verbinden m\u00fcssen?), werden schwebende IPs<\/em> (float IP<\/strong>). Das sind IPs, die Pacemaker zwischen den Knoten verschieben kann (alles befindet sich im flachen Netzwerk). Jede von ihnen symbolisiert eine Ressource (Service) und wird dort platziert, wo man sich verbinden muss, um Zugang zu diesem Service zu erhalten (in unserem Fall zur DB).<\/p>\n

<\/p>\n

Tuchanka1 (Schema mit Verdichtung)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Die Idee war, dass wir viele kleine Datenbanken mit geringer Auslastung haben, f\u00fcr die es sich nicht lohnt, einen dedizierten Slave-Server im Hot-Standby-Modus f\u00fcr Read-Only-Transaktionen zu unterhalten (es besteht keine Notwendigkeit f\u00fcr eine solche Ressourcenverschwendung).<\/p>\n

<\/p>\n

In jedem Rechenzentrum befindet sich ein Server. Auf jedem Server laufen zwei Instanzen von PostgreSQL (in der Terminologie von PostgreSQL werden sie als Cluster bezeichnet, um Verwirrung zu vermeiden, nenne ich sie Instanzen (analog zu anderen DBs), w\u00e4hrend ich Cluster nur f\u00fcr Pacemaker-Clustern verwenden werde). Eine Instanz arbeitet im Master-Modus und bietet ausschlie\u00dflich Dienste an (auf sie verweist die Float-IP). Die zweite Instanz fungiert als Slave f\u00fcr das zweite Rechenzentrum und bietet Dienstleistungen nur an, wenn der Master ausf\u00e4llt. Da die meisten Dienste (Anfragen) von nur einer der beiden Instanzen (dem Master) bereitgestellt werden, werden alle Serverressourcen auf den Master optimiert (Speicher wird f\u00fcr den Cache von shared_buffers bereitgestellt usw.), wobei jedoch auch gen\u00fcgend Ressourcen f\u00fcr die zweite Instanz (auch wenn sie nur suboptimal \u00fcber den Cache des Dateisystems arbeitet) bereitgestellt werden, um einen Ausfall eines der Rechenzentren abzufangen. Der Slave bietet keine Dienste an (f\u00fchrt keine schreibgesch\u00fctzten Anfragen aus), solange der Cluster normal arbeitet, um Ressourcenkonflikte mit dem Master auf demselben Server zu vermeiden.<\/p>\n

<\/p>\n

Bei zwei Knoten ist Hochverf\u00fcgbarkeit nur mit asynchroner Replikation m\u00f6glich, da bei synchroner Replikation der Ausfall des Slave-Servers zum Stillstand des Masters f\u00fchrt.<\/p>\n

<\/p>\n

Ausfall des Witness<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Ausfall des Witness (Quorum-Ger\u00e4t<\/em>) werde ich nur f\u00fcr das Cluster Tuchanka1 betrachten, bei allen anderen wird es die gleiche Geschichte sein. Bei einem Ausfall des Witness \u00e4ndert sich in der Clusterstruktur nichts, alles funktioniert weiterhin wie gewohnt. Aber das Quorum wird 2 von 3 betragen, wodurch jeder weitere Ausfall fatal f\u00fcr das Cluster wird. Es muss dringend repariert werden.<\/p>\n

<\/p>\n

Ausfall Tuchanka1<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Der Ausfall eines der Rechenzentren f\u00fcr Tuchanka1. In diesem Fall Witness<\/em> gibt seine Stimme dem zweiten Knoten im zweiten Rechenzentrum ab. Dort wird der vorherige Slave zum Master und somit arbeiten beide Master auf einem Server, auf den beide ihre Float-IP zeigen.<\/p>\n

<\/p>\n

Tuchanka2 (klassisch)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Klassisches Setup mit zwei Knoten. Auf einem arbeitet der Master, auf dem anderen der Slave. Beide k\u00f6nnen Anfragen bearbeiten (Slave nur read-only), daher zeigen beide auf ihre Float-IPs: krogan2 \u2013 auf den Master, krogan2s1 \u2013 auf den Slave. Die Hochverf\u00fcgbarkeit gilt sowohl f\u00fcr den Master als auch f\u00fcr den Slave.<\/p>\n

<\/p>\n

Bei zwei Knoten ist Ausfallsicherheit nur mit asynchroner Replikation m\u00f6glich, da die synchronisierte Replikation zur Stilllegung des Masters f\u00fchrt, wenn ein Slave ausf\u00e4llt.<\/p>\n

<\/p>\n

Ausfall von Tuchanka2<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Bei einem Ausfall eines der Rechenzentren Witness<\/em> wird f\u00fcr das zweite abgestimmt. Im einzigen betriebsbereiten Rechenzentrum wird der Master hochgefahren, und beide Float-IP-Adressen, die Master- und Slave-IP, zeigen darauf. Nat\u00fcrlich muss die Instanz so konfiguriert sein, dass sie \u00fcber ausreichende Ressourcen (Limits f\u00fcr Verbindungen usw.) verf\u00fcgt, um gleichzeitig alle Verbindungen und Anfragen von den Master- und Slave-Float-IP-Adressen zu akzeptieren. Das hei\u00dft, im Normalbetrieb sollte sie ausreichend Reserven bei den Limits haben.<\/p>\n

<\/p>\n

Tuchanka4 (viele Slaves)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Das ist bereits eine andere Extremit\u00e4t. Es gibt Datenbanken, die viele Leseanfragen erhalten (typischer Fall bei stark frequentierten Websites). Tuchanka4 ist eine Situation, in der es drei oder mehr Slaves geben kann, um solche Anfragen zu bearbeiten, allerdings nicht zu viele. Bei einer sehr gro\u00dfen Anzahl von Slaves w\u00e4re es notwendig, ein hierarchisches Replikationssystem zu entwickeln. Im Minimalfall (wie auf dem Bild) befinden sich in jedem der beiden Rechenzentren zwei Server, auf denen jeweils eine PostgreSQL-Instanz l\u00e4uft.<\/p>\n

<\/p>\n

Eine weitere Besonderheit dieses Schemas besteht darin, dass hier bereits eine synchrone Replikation eingerichtet werden kann. Sie ist so konfiguriert, dass sie nach M\u00f6glichkeit in ein anderes Rechenzentrum repliziert, anstatt auf eine Replik im selben Rechenzentrum wie das Master zuzugreifen. Sowohl das Master als auch jeder Slave verwenden eine Float-IP. Ideal w\u00e4re es, zwischen den Slaves eine Lastverteilung f\u00fcr die Anfragen durchzuf\u00fchren, beispielsweise SQL-Proxy<\/em>, um verschiedenen Arten von Clients gerecht zu werden. Unterschiedliche Typen von Clients ben\u00f6tigen m\u00f6glicherweise unterschiedliche Typen von SQL-Proxy<\/em>, und nur die Entwickler der Clients wissen, welcher f\u00fcr wen erforderlich ist. Diese Funktionalit\u00e4t kann sowohl durch einen externen Daemon als auch durch eine Clientbibliothek (Connection Pool) usw. realisiert werden. All dies geht \u00fcber das Thema des ausfallsicheren DB-Clusters hinaus (Ausfallsicherheit SQL-Proxy<\/em> kann unabh\u00e4ngig umgesetzt werden, zusammen mit der Ausfallsicherheit des Clients).<\/p>\n

<\/p>\n

Ausfall Tuchanka4<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Wenn ein Rechenzentrum ausf\u00e4llt (d.h. zwei Server), stimmt das Witness f\u00fcr den zweiten ab. Daraus ergibt sich, dass im zweiten Rechenzentrum zwei Server betrieben werden: auf einem l\u00e4uft der Master, der durch die Master-Float-IP angezeigt wird (f\u00fcr die Annahme von Read-Write-Anfragen); und auf dem zweiten Server l\u00e4uft ein Slave mit synchroner Replikation, der durch eine der Slave-Float-IPs angezeigt wird (f\u00fcr Read-Only-Anfragen).<\/p>\n

<\/p>\n

Das Erste, was zu beachten ist: von den Slave-Float-IPs wird nicht jede arbeitsf\u00e4hig sein, sondern nur eine. Und f\u00fcr die korrekte Funktion mit dieser muss sichergestellt sein, dass SQL-Proxy<\/em> alle Anfragen auf die einzige verbleibende Float-IP weitergeleitet werden; und wenn SQL-Proxy<\/em> nicht, kann die Auflistung aller Slave-Float-IPs durch Kommas im URL f\u00fcr die Verbindung erfolgen. In diesem Fall wird die libpq<\/em> Verbindung zum ersten funktionierenden IP hergestellt, so ist es im System f\u00fcr automatische Tests implementiert. M\u00f6glicherweise funktioniert es in anderen Bibliotheken, z.B. JDBC, nicht so, und es ist notwendig SQL-Proxy<\/em>. Dies geschieht, weil die Float-IPs f\u00fcr die Slaves das gleichzeitige Hochfahren auf einem Server untersagt ist, um eine gleichm\u00e4\u00dfige Verteilung auf die Slave-Server zu gew\u00e4hrleisten, wenn mehrere in Betrieb sind.<\/p>\n

<\/p>\n

Zweitens: Selbst im Falle eines Ausfalls des Rechenzentrums bleibt die synchrone Replikation bestehen. Und selbst wenn es zu einem sekund\u00e4ren Ausfall kommt, das hei\u00dft, einer der beiden Server im verbleibenden Rechenzentrum ausf\u00e4llt, wird der Cluster zwar seine Dienste einstellen, jedoch die Informationen \u00fcber alle best\u00e4tigten Transaktionen, f\u00fcr die eine Best\u00e4tigung gegeben wurde, weiterhin speichern (es gibt keinen Informationsverlust bei einem sekund\u00e4ren Ausfall).<\/p>\n

<\/p>\n

Tuchanka3 (3 Rechenzentren)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Dies ist ein Cluster f\u00fcr Situationen, in denen drei voll funktionsf\u00e4hige Rechenzentren vorhanden sind, in denen jeweils ein vollst\u00e4ndig funktionsf\u00e4higer Datenbankserver betrieben wird. In diesem Fall Quorum-Ger\u00e4t<\/em> ist nicht erforderlich. In einem Rechenzentrum arbeitet der Master, in zwei anderen die Slaves. Die Replikation ist synchron, Typ ANY (slave1, slave2), das bedeutet, dass der Kunde eine Committ-Best\u00e4tigung erh\u00e4lt, sobald einer der Slaves zuerst antwortet, dass er das Commit akzeptiert hat. Die Ressourcen werden durch eine einzelne Floating-IP f\u00fcr den Master und zwei f\u00fcr die Slaves angegeben. Im Gegensatz zu Tuchanka4 sind alle drei Floating-IPs fehlertolerant. Zur Lastverteilung von read-only SQL-Anfragen kann man SQL-Proxy<\/em> (mit separater Fehlertoleranz) oder der H\u00e4lfte der Kunden einen Slave-Floating-IP zuweisen und der anderen H\u00e4lfte die zweite.<\/p>\n

<\/p>\n

Ausfall von Tuchanka3<\/h3>\n

<\/p>\n

\"Modellierung<\/p>\n

<\/p>\n

Wenn einer der Rechenzentren ausf\u00e4llt, bleiben zwei \u00fcbrig. In einem wird der Master und die Float-IP vom Master betrieben, im anderen der Slave und beide Slave-Float-IPs (auf der Instanz sollte eine doppelte Ressourcenvorhaltung vorhanden sein, um alle Verbindungen von beiden Slave-Float-IPs zu akzeptieren). Zwischen Master und Slave erfolgt eine synchrone Replikation. Das Cluster speichert auch Informationen \u00fcber best\u00e4tigte und committierte Transaktionen (es wird keine Informationsverluste geben) im Falle der Zerst\u00f6rung von zwei Rechenzentren (sofern diese nicht gleichzeitig zerst\u00f6rt werden).<\/p>\n

<\/p>\n

Eine detaillierte Beschreibung der Dateistruktur und des Deployments habe ich entschieden nicht einzuf\u00fcgen. Wer experimentieren m\u00f6chte, kann alles in der README nachlesen. Ich gebe nur eine Beschreibung der automatischen Tests an.<\/em><\/p>\n

<\/p>\n

Das System f\u00fcr automatisierte Tests<\/h1>\n

<\/p>\n

Zur \u00dcberpr\u00fcfung der Ausfallsicherheit von Clustern unter Simulation verschiedener St\u00f6rungen wurde ein System f\u00fcr automatische Tests entwickelt. Es wird \u00fcber ein Skript gestartet test\/failure<\/code>. Das Skript kann als Parameter die Nummern der Cluster annehmen, die getestet werden sollen. Zum Beispiel dieser Befehl:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
Es werden nur der zweite und der dritte Cluster getestet. Wenn keine Parameter angegeben sind, werden alle Cluster getestet. Alle Cluster werden parallel getestet, und das Ergebnis wird im tmux Panel angezeigt. Tmux verwendet einen dedizierten tmux-Server, daher kann das Skript aus dem standardm\u00e4\u00dfigen tmux gestartet werden, was zu einem verschachtelten tmux f\u00fchrt. Ich empfehle, das Terminal in einem gro\u00dfen Fenster und mit kleiner Schriftgr\u00f6\u00dfe zu verwenden. Vor dem Teststart werden alle virtuellen Maschinen auf den Snapshot zum Zeitpunkt des Skriptschlusses zur\u00fcckgesetzt. setup<\/code>.<\/p>\n
<\/p>\n
\"Modellierung<\/p>\n
<\/p>\n
Das Terminal ist in Spalten unterteilt, je nach Anzahl der getesteten Cluster, standardm\u00e4\u00dfig (im Screenshot) sind es vier. Den Inhalt der Spalten werde ich am Beispiel von Tuchanka2 erl\u00e4utern. Die Panels im Screenshot sind nummeriert:<\/p>\n
<\/p>\n
    \n
  1. Hier wird die Statistik der Tests angezeigt. Spalten:\n