{"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\/sv\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modellering av felresistenta kluster baserade p\u00e5 PostgreSQL och Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduktion<\/h1>\n

<\/p>\n

F\u00f6r en tid sedan fick jag i uppdrag att utveckla en h\u00f6g tillg\u00e4nglighetskluster f\u00f6r PostgreSQL<\/a><\/noindex>, som fungerar i flera datacentra, kopplade med fiber inom samma stad, och som kan klara av att ett datacenter g\u00e5r nere (till exempel str\u00f6mavbrott). Som programvara f\u00f6r h\u00f6g tillg\u00e4nglighet valde jag Pacemaker<\/a><\/noindex>, eftersom detta \u00e4r den officiella l\u00f6sningen fr\u00e5n RedHat f\u00f6r att skapa h\u00f6g tillg\u00e4ngliga kluster. Det \u00e4r bra eftersom RedHat ger st\u00f6d f\u00f6r det, och det \u00e4r en universell (modul\u00e4r) l\u00f6sning. Med hj\u00e4lp av detta kan h\u00f6g tillg\u00e4nglighet s\u00e4kerst\u00e4llas f\u00f6r inte bara PostgreSQL, utan ocks\u00e5 andra tj\u00e4nster, antingen genom att anv\u00e4nda standardmoduler eller genom att skapa dem f\u00f6r specifika behov.<\/p>\n

<\/p>\n

Det uppstod en rimlig fr\u00e5ga om detta l\u00f6sning: hur h\u00f6g tillg\u00e4nglighet kommer det h\u00f6g tillg\u00e4nglighetsklustret att ha? F\u00f6r att unders\u00f6ka detta utvecklade jag en testmilj\u00f6 som imiterar olika fel p\u00e5 klusternoderna, v\u00e4ntar p\u00e5 \u00e5terst\u00e4llande av funktionaliteten, \u00e5terst\u00e4ller den misslyckade noden och forts\u00e4tter testningen i cykler. Ursprungligen kallades detta projekt hapgsql, men med tiden blev jag tr\u00f6tt p\u00e5 namnet som bara hade en vokal. D\u00e4rf\u00f6r b\u00f6rjade jag kalla h\u00f6g tillg\u00e4ngliga databaser (och den flytande IP som pekar p\u00e5 dem) krogan<\/strong> (en karakt\u00e4r fr\u00e5n ett datorspel vars alla viktiga organ \u00e4r duplicerade), och noder, kluster och sj\u00e4lva projektet \u2014 tuchanka<\/strong> (planeten d\u00e4r krogans bor).<\/p>\n

<\/p>\n

Nu har ledningen beslutat att \u00f6ppna projektet f\u00f6r open source-gemenskapen under MIT-licensen<\/a><\/noindex>. README kommer snart att \u00f6vers\u00e4ttas till engelska (eftersom det f\u00f6rv\u00e4ntas att huvudkonsumenterna kommer att vara utvecklare av Pacemaker och PostgreSQL), och den gamla ryska varianten av README har jag beslutat att utforma (delvis) i form av denna artikel.<\/p>\n

<\/p>\n

\"Modellering<\/p>\n

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

Klustren s\u00e4tts upp p\u00e5 virtuella maskiner VirtualBox<\/a><\/noindex>. Totalt kommer 12 virtuella maskiner att s\u00e4ttas upp (totalt 36 GiB), som bildar 4 h\u00f6g tillg\u00e4nglighetskluster (olika varianter). De f\u00f6rsta tv\u00e5 klustren best\u00e5r av tv\u00e5 PostgreSQL-servrar, som \u00e4r placerade i olika datacentra, och en gemensam server witness<\/em> c quorum device<\/strong> (placerad p\u00e5 en billig virtuell maskin i det tredje datacentret), som l\u00f6ser os\u00e4kerheten 50%\/50%<\/strong>, genom att ge sin r\u00f6st till en av parterna. Det tredje klustret best\u00e5r av tre datacenter: en master och tv\u00e5 slavservrar, utan quorum device<\/strong>. Den fj\u00e4rde klustret best\u00e5r av fyra PostgreSQL-servrar, tv\u00e5 per datacenter: en master och resten repliker, och anv\u00e4nder ocks\u00e5 witness<\/em> c quorum device<\/strong>. Fj\u00e4rde klustret klarar av att f\u00f6rlora tv\u00e5 servrar eller ett datacenter. Denna l\u00f6sning kan, vid behov, skalas upp till fler repliker.<\/p>\n

<\/p>\n

Tj\u00e4nst f\u00f6r exakt tid ntpd<\/a><\/noindex> har ocks\u00e5 konfigurerats f\u00f6r h\u00f6g tillg\u00e4nglighet, men d\u00e4r anv\u00e4nds metoden f\u00f6r ntpd<\/code> (orphan mode<\/em>). Den gemensamma servern witness<\/em> har en central roll som NTP-server, som delar sin tid med alla kluster och p\u00e5 s\u00e5 s\u00e4tt synkroniserar alla servrar med varandra. Om witness<\/em> den g\u00e5r s\u00f6nder eller blir isolerad, d\u00e5 b\u00f6rjar en av klusterservrarna (inom klustret) dela sin tid. En hj\u00e4lpkassande HTTP-proxy<\/strong> \u00e4r ocks\u00e5 uppr\u00e4ttad, witness<\/em>med hj\u00e4lp av denna har de andra virtuella maskinerna tillg\u00e5ng till Yum-repositorier. I verkligheten kommer s\u00e5dana tj\u00e4nster som exakt tid och proxy f\u00f6rmodligen att hostas p\u00e5 dedikerade servrar, men i detta stand har de placerats p\u00e5 witness<\/em> endast f\u00f6r att spara p\u00e5 antalet virtuella maskiner och utrymme.<\/p>\n

<\/p>\n

Versioner<\/h1>\n

<\/p>\n

v0. Fungerar med CentOS 7 och PostgreSQL 11 p\u00e5 VirtualBox 6.1.<\/p>\n

<\/p>\n

Konstruktur f\u00f6r kluster<\/h1>\n

<\/p>\n

Alla kluster \u00e4r avsedda f\u00f6r distribution i flera datacenter, sammanl\u00e4nkade i ett enda platt n\u00e4tverk och ska klara av ett fel eller n\u00e4tverksisolering av ett datacenter. D\u00e4rf\u00f6r \u00e4r om\u00f6jligt<\/strong> anv\u00e4nds f\u00f6r skydd mot split-brain<\/strong> standardteknologin Pacemaker, som kallas STONITH<\/em> (Shoot The Other Node In The Head) eller fencing<\/em>. Dess k\u00e4rna: om noderna i klustret b\u00f6rjar misst\u00e4nka att n\u00e5got \u00e4r fel med en nod, den svarar inte eller beter sig felaktigt, s\u00e5 st\u00e4nger de av den tv\u00e5ngsm\u00e4ssigt via \"externa\" enheter, till exempel en IPMI-kontrollkort eller UPS. Men detta fungerar bara i fall d\u00e4r vid enstaka serverfel forts\u00e4tter IPMI eller UPS att fungera. H\u00e4r planeras skydd mot betydligt mer katastrofalt fel, n\u00e4r hela datacentret g\u00e5r ner (till exempel str\u00f6mavbrott). Vid s\u00e5dan avbrott kommer alla stonith<\/em>-enheter (IPMI, UPS osv.) heller inte fungera.<\/p>\n

<\/p>\n

Ist\u00e4llet bygger systemet p\u00e5 id\u00e9n om majoritet. Alla noder har en r\u00f6st, och endast de som ser mer \u00e4n h\u00e4lften av alla noder kan arbeta. Detta antal \"h\u00e4lften+1\" kallas kvorum<\/strong>. Om majoriteten inte uppn\u00e5s anser noden att den \u00e4r i n\u00e4tverksisolering och att den m\u00e5ste st\u00e4nga av sina resurser, dvs. det \u00e4r s\u00e5 h\u00e4r skydd mot split-brain<\/strong>. Om mjukvaran som ansvarar f\u00f6r detta beteende inte fungerar, b\u00f6r en watchdog aktiveras, till exempel baserat p\u00e5 IPMI.<\/p>\n

<\/p>\n

Om antalet noder \u00e4r j\u00e4mnt (klustret finns i tv\u00e5 datacenter) kan det uppst\u00e5 s\u00e5 kallad os\u00e4kerhet 50%\/50%<\/strong> (fifty-fifty<\/em>), n\u00e4r n\u00e4tverksisoleringen delar klustret i exakt tv\u00e5 halvor. D\u00e4rf\u00f6r l\u00e4ggs det till ett j\u00e4mnt antal noder quorum device<\/strong> \u2014 en resurskr\u00e4vande demon som kan k\u00f6ras p\u00e5 den billigaste virtuella maskinen i det tredje datacentret. Den ger sin r\u00f6st till en av segmenten (som den ser) och d\u00e4rmed l\u00f6ser 50%\/50% os\u00e4kerheten. Servern d\u00e4r quorum-enheten kommer att k\u00f6ras har jag kallat witness<\/em> (terminologi fr\u00e5n repmgr, jag gillade den).<\/p>\n

<\/p>\n

Resurser kan flyttas runt, till exempel fr\u00e5n trasiga servrar till fungerande, eller p\u00e5 beg\u00e4ran av systemadministrat\u00f6rer. F\u00f6r att kunder ska veta var deras n\u00f6dv\u00e4ndiga resurser finns (var de ska ansluta?), anv\u00e4nds flytande IP<\/em> (float IP<\/strong>). Det \u00e4r IP-adresser som Pacemaker kan flytta mellan noder (allt finns i ett platt n\u00e4tverk). Varje av dem symboliserar en resurs (tj\u00e4nst) och kommer att befinna sig d\u00e4r man beh\u00f6ver ansluta f\u00f6r att f\u00e5 tillg\u00e5ng till denna tj\u00e4nst (i v\u00e5rt fall DB).<\/p>\n

<\/p>\n

Tuchanka1 (schema med komprimering)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Id\u00e9n var att vi har m\u00e5nga sm\u00e5 databaser med l\u00e5g belastning, f\u00f6r vilka det inte \u00e4r l\u00f6nsamt att ha en dedikerad slavserver i hot standby-l\u00e4ge f\u00f6r read only-transaktioner (ingen anledning till s\u00e5dan resurs\u00e5terg\u00e5ng).<\/p>\n

<\/p>\n

I varje datacenter finns en server. P\u00e5 varje server finns det tv\u00e5 instanser av PostgreSQL (i PostgreSQL-termer kallas de kluster, men f\u00f6r att undvika f\u00f6rvirring kommer jag att kalla dem instanser (i analogi med andra databaser), och kluster kommer jag bara att kalla kluster f\u00f6r Pacemaker). En instans fungerar i masterl\u00e4ge, och endast den tillhandah\u00e5ller tj\u00e4nster (det \u00e4r bara den som har float IP). Den andra instansen fungerar som en slav f\u00f6r det andra datacentret och kommer endast att erbjuda tj\u00e4nster om dess master g\u00e5r ner. Eftersom det under st\u00f6rre delen av tiden bara \u00e4r en instans av de tv\u00e5 (master) som tillhandah\u00e5ller tj\u00e4nster (bearbetar f\u00f6rfr\u00e5gningar) optimeras alla serverresurser f\u00f6r master (minne avs\u00e4tts f\u00f6r cache av shared_buffers etc.), men s\u00e5 att det ocks\u00e5 finns tillr\u00e4ckligt med resurser f\u00f6r den andra instansen (om \u00e4n f\u00f6r en suboptimal drift via filsystemets cache) i h\u00e4ndelse av att ett av datacentren slutar fungera. Slaven tillhandah\u00e5ller inga tj\u00e4nster (g\u00f6r inga read-only-f\u00f6rfr\u00e5gningar) under normal drift av klustret f\u00f6r att undvika resurskonflikter med mastern p\u00e5 samma maskin.<\/p>\n

<\/p>\n

I fallet med tv\u00e5 noder \u00e4r felresiliens endast m\u00f6jlig vid asynkron replikering, eftersom en synkroniserad fel p\u00e5 slaven skulle leda till att mastern stannar.<\/p>\n

<\/p>\n

Fel witness<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Fel witness (quorum device<\/em>) jag kommer endast att \u00f6verv\u00e4ga f\u00f6r klustret Tuchanka1, alla andra kommer att ha samma historia. Vid ett fel p\u00e5 witness i klustrets struktur f\u00f6r\u00e4ndras ingenting, allt kommer att fungera som tidigare. Men avg\u00f6rande r\u00f6ster blir 2 av 3, och d\u00e4rf\u00f6r kommer varje f\u00f6ljande fel att vara fatalt f\u00f6r klustret. Det m\u00e5ste fortfarande \u00e5tg\u00e4rdas omedelbart.<\/p>\n

<\/p>\n

Fel Tuchanka1<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Fel p\u00e5 ett av datacentren f\u00f6r Tuchanka1. I detta fall witness<\/em> ger sin r\u00f6st till den andra noden i det andra datacentret. D\u00e4r f\u00f6rvandlas den tidigare slaven till master, vilket resulterar i att b\u00e5da mastern arbetar p\u00e5 en server och b\u00e5da deras float IP pekar p\u00e5 dem.<\/p>\n

<\/p>\n

Tuchanka2 (klassisk)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Klassiskt m\u00f6nster med tv\u00e5 noder. P\u00e5 en arbetar master, p\u00e5 den andra slav. B\u00e5da kan behandla f\u00f6rfr\u00e5gningar (slaven bara read-only), s\u00e5 b\u00e5da pekar p\u00e5 float IP: krogan2 - f\u00f6r mastern, krogan2s1 - f\u00f6r slaven. Felresiliens kommer att finnas b\u00e5de hos mastern och slaven.<\/p>\n

<\/p>\n

I fallet med tv\u00e5 noder \u00e4r felresiliens endast m\u00f6jlig vid asynkron replikering, eftersom en synkroniserad fel p\u00e5 slaven skulle leda till att mastern stannar.<\/p>\n

<\/p>\n

Fel Tuchanka2<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Vid ett fel p\u00e5 ett av datacentren witness<\/em> r\u00f6star p\u00e5 den andra. P\u00e5 det enda fungerande datacentret kommer en master att s\u00e4ttas upp, och b\u00e5da float IP:erna \u2013 master och slav \u2013 kommer att peka p\u00e5 den. Sj\u00e4lvklart m\u00e5ste instansen konfigureras s\u00e5 att den har tillr\u00e4ckligt med resurser (gr\u00e4nser f\u00f6r anslutningar etc.) f\u00f6r att samtidigt ta emot alla anslutningar och f\u00f6rfr\u00e5gningar fr\u00e5n b\u00e5de master- och slavens float IP. Det vill s\u00e4ga, under normal drift b\u00f6r den ha ett tillr\u00e4ckligt \u00f6verskott av kapacitet.<\/p>\n

<\/p>\n

Tuchanka4 (m\u00e5nga slavar)<\/h2>\n

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Det \u00e4r redan en annan extrem. Det finns databaser som har mycket h\u00f6ga read-only f\u00f6rfr\u00e5gningar (ett typiskt fall f\u00f6r en h\u00f6gbelastad webbplats). Tuchanka4 \u00e4r en situation d\u00e4r det kan finnas tre eller fler slavar f\u00f6r att hantera s\u00e5dana f\u00f6rfr\u00e5gningar, men \u00e4nd\u00e5 inte f\u00f6r m\u00e5nga. Vid ett mycket stort antal slavar beh\u00f6ver man uppfinna ett hierarkiskt replikationssystem. I det minimiella fallet (p\u00e5 bilden) finns det tv\u00e5 servrar i varje datacenter, med en instans av PostgreSQL p\u00e5 varje server.<\/p>\n

<\/p>\n

En annan funktion hos detta system \u00e4r att man redan kan organisera en synkron replikation. Den \u00e4r konfigurerad f\u00f6r att replikera, n\u00e4r det \u00e4r m\u00f6jligt, till ett annat datacenter, snarare \u00e4n till en replika i samma datacenter som master. B\u00e5de master och varje slav pekar p\u00e5 float IP. F\u00f6r att optimera detta b\u00f6r man balansera f\u00f6rfr\u00e5gningarna mellan slavar med hj\u00e4lp av n\u00e5got. sql proxy<\/em>, till exempel fr\u00e5n klientens sida. Olika typer av klienter kan beh\u00f6va olika typer sql proxy<\/em>, och endast klientutvecklarna vet vem som beh\u00f6ver vad. Denna funktionalitet kan implementeras antingen som en extern demon eller som en klientbibliotek (connection pool), etc. Allt detta faller utanf\u00f6r \u00e4mnet f\u00f6r ett fel- och drift-s\u00e4kert databaskluster (drift-s\u00e4kerhet SQL proxy<\/em> kan realiseras oberoende, tillsammans med klientens drift-s\u00e4kerhet).<\/p>\n

<\/p>\n

Fel i Tuchanka4<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Vid fel i ett datacenter (dvs tv\u00e5 servrar) r\u00f6star witness f\u00f6r den andra. Som en f\u00f6ljd av detta fungerar tv\u00e5 servrar i det andra datacentret: en server hanterar master och pekar p\u00e5 master float IP (f\u00f6r att ta emot read-write f\u00f6rfr\u00e5gningar); och p\u00e5 den andra servern verkar en slav med synkron replikation, och p\u00e5 den pekar ett av slavarnas float IP (f\u00f6r read-only f\u00f6rfr\u00e5gningar).<\/p>\n

<\/p>\n

Det f\u00f6rsta att notera \u00e4r att arbetsfloat IP f\u00f6r slavar inte kommer att vara alla, bara en. Och f\u00f6r att kunna arbeta korrekt med det kr\u00e4vs det att sql proxy<\/em> alla beg\u00e4rningar omdirigerades till den enda kvarvarande float IP; om inte sql proxy<\/em> kan man lista alla float IP f\u00f6r slavarna med kommatecken i URL:en f\u00f6r anslutning. I s\u00e5 fall kommer anslutningen att ske till den f\u00f6rsta fungerande IP:n, som implementerats i automatiseringstestningssystemet. Det kan h\u00e4nda att det fungerar annorlunda i andra bibliotek, som JDBC, och d\u00e5 kr\u00e4vs libpq<\/em> att anslutningen kommer att ske till den f\u00f6rsta fungerande IP:n, vilket implementerats i automatiserat testningssystem. I andra bibliotek, som JDBC, kan det h\u00e4nda att detta inte fungerar och att det kr\u00e4vs sql proxy<\/em>. Detta \u00e4r f\u00f6r att float IP:n f\u00f6r slavarna har en restriktion f\u00f6r att samtidigt kunna k\u00f6ra p\u00e5 en server, s\u00e5 att de f\u00f6rdelas j\u00e4mnt \u00f6ver slavservrarna om flera \u00e4r ig\u00e5ng.<\/p>\n

<\/p>\n

F\u00f6r det andra: \u00e4ven om datacentret skulle falla kommer den synkrona replikeringen att bevaras. Om en sekund\u00e4r felaktighet uppst\u00e5r, det vill s\u00e4ga om en av tv\u00e5 servrar i det kvarst\u00e5ende datacentret g\u00e5r ner, s\u00e5 kommer klustret, \u00e4ven om det slutar erbjuda tj\u00e4nster, fortfarande att bevara information om alla kommitterade transaktioner som det har bekr\u00e4ftat med en commit (ingen f\u00f6rlust av information vid sekund\u00e4r felaktighet).<\/p>\n

<\/p>\n

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

<\/p>\n

Struktur<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Detta \u00e4r ett kluster f\u00f6r situationen n\u00e4r det finns tre fullt fungerande datacenter, d\u00e4r var och en har en fullt fungerande databasserver. I detta fall quorum device<\/em> \u00e4r inte n\u00f6dv\u00e4ndig. I ett datacenter finns det en master, och i de tv\u00e5 andra \u2014 slavar. Replikeringen \u00e4r synkron, i stil med ANY (slave1, slave2), vilket inneb\u00e4r att klienten f\u00e5r en bekr\u00e4ftelse p\u00e5 commit n\u00e4r n\u00e5gon av slavarna f\u00f6rst svarar att den har tagit emot commiten. Resurserna pekar p\u00e5 en float IP f\u00f6r master och tv\u00e5 f\u00f6r slavarna. Till skillnad fr\u00e5n Tuchanka4 \u00e4r alla tre float IP:er \u00e4r redundanta. F\u00f6r lastbalansering av read-only SQL-f\u00f6rfr\u00e5gningar kan man anv\u00e4nda sql proxy<\/em> (med separat redundans), eller tilldela h\u00e4lften av klienterna en slav float IP och den andra h\u00e4lften den andra.<\/p>\n

<\/p>\n

Fel p\u00e5 Tuchanka3<\/h3>\n

<\/p>\n

\"Modellering<\/p>\n

<\/p>\n

Vid ett fel i ett av datacentren finns det fortfarande tv\u00e5 kvar. I ett finns master och float IP fr\u00e5n master, medan det andra har en slav och b\u00e5da slavarnas float IP (instansen b\u00f6r ha dubbelt s\u00e5 mycket resurser f\u00f6r att ta emot alla anslutningar fr\u00e5n b\u00e5da slavarnas float IP). Mellan master och slav finns det synkron replikering. Klustret kommer ocks\u00e5 att bevara information om kommitterade och bekr\u00e4ftade transaktioner (ingen f\u00f6rlust av information) i h\u00e4ndelse av att tv\u00e5 datacenter f\u00f6rst\u00f6rs (om de inte f\u00f6rst\u00f6rs samtidigt).<\/p>\n

<\/p>\n

Jag har valt att inte inkludera en detaljerad beskrivning av filstrukturen och distributionen. De som vill experimentera kan l\u00e4sa allt detta i README. Jag ger bara en beskrivning av automatisk testning.<\/em><\/p>\n

<\/p>\n

Automatisk testningssystem<\/h1>\n

<\/p>\n

F\u00f6r att kontrollera klusterens felbest\u00e4ndighet har ett system f\u00f6r automatisk testning skapats. Det k\u00f6rs med ett skript. test\/failure<\/code>. Skriptet kan ta som parametrar de nummer av kluster som du vill testa. Till exempel, det h\u00e4r kommandot:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
kommer bara att testa det andra och tredje klustret. Om inga parametrar anges kommer alla kluster att testas. Alla kluster testas parallellt, och resultatet visas i tmux-panelen. Tmux anv\u00e4nder en dedikerad tmux-server, s\u00e5 skriptet kan k\u00f6ras fr\u00e5n default tmux, vilket ger en inb\u00e4ddad tmux. Jag rekommenderar att anv\u00e4nda en terminal i ett stort f\u00f6nster med liten teckenstorlek. Innan testningen inleds \u00e5terst\u00e4lls alla virtuella maskiner till en snapshot vid tidpunkten d\u00e5 skriptet avslutades. setup<\/code>.<\/p>\n
<\/p>\n
\"Modellering<\/p>\n
<\/p>\n
Terminals \u00e4r uppdelad i kolumner enligt antal testade kluster, som standard (i sk\u00e4rmdumpen) fyra. Inneh\u00e5llet i kolumnerna kommer jag att beskriva med exemplet Tuchanka2. Panelerna p\u00e5 sk\u00e4rmdumpen \u00e4r numrerade:<\/p>\n
<\/p>\n
    \n
  1. H\u00e4r visas statistiken f\u00f6r testerna. Kolumner:\n