Sissejuhatus

Mõni aeg tagasi anti mulle ülesanne töötada välja tõrkeotsingu klaster PostgreSQL, mis töötab mitmes andmekeskuses, mis on ühendatud fiiberopsuga samas linnas ja suudavad taluda ühe andmekeskuse rikkeid (näiteks elektrikatkestusi). Valisin veataluvuse eest vastutava tarkvarana Südamestimulaator, sest see on RedHati ametlik lahendus tõrkesiirdeklastrite loomiseks. See on hea, kuna RedHat pakub sellele tuge ja kuna see lahendus on universaalne (modulaarne). Selle abiga on võimalik pakkuda tõrketaluvust mitte ainult PostgreSQL-ile, vaid ka teistele teenustele, kasutades kas standardmooduleid või luues neid konkreetsete vajaduste jaoks.

Sellele otsusele kerkis mõistlik küsimus: kui tõrketaluv on tõrkeotsinguklaster? Selle uurimiseks töötasin välja katsestendi, mis simuleerib erinevaid tõrkeid klastri sõlmedel, ootab taastumist, taastab ebaõnnestunud sõlme ja jätkab testimist tsüklina. Algselt kandis see projekt nime hapgsql, kuid aja jooksul hakkas see nimi, millel on ainult üks täishäälik, igav. Seetõttu hakkasin nimetama tõrketaluvaid andmebaase (ja neile osutavaid ujuv-IP-sid) krogan (tegelane arvutimängust, milles kõik olulised organid on dubleeritud) ning sõlmed, klastrid ja projekt ise tuchanka (planeet, kus kroganid elavad).

Juhtkond on nüüd heaks kiitnud avage projekt avatud lähtekoodiga kogukonnale MIT-i litsentsi alusel. README tõlgitakse peagi inglise keelde (kuna põhikasutajateks on eeldatavasti Pacemaker ja PostgreSQL-i arendajad) ning otsustasin välja anda README vana venekeelse versiooni (osaliselt) selle artikli kujul.

Klastrid juurutatakse virtuaalsetesse masinatesse VirtualBox. Kokku juurutatakse 12 virtuaalmasinat (kokku 36GiB), mis moodustavad 4 tõrkesiirdeklastrit (erinevad valikud). Esimesed kaks klastrit koosnevad kahest PostgreSQL-serverist, mis asuvad erinevates andmekeskustes, ja ühisest serverist tunnistaja c kvoorumi seade (majutatakse odavas virtuaalmasinas kolmandas andmekeskuses), mis lahendab ebakindluse 50% / 50%hääle andmisega. Kolmas klaster kolmes andmekeskuses: üks ülem, kaks alamseadet, nr kvoorumi seade. Neljas klaster koosneb neljast PostgreSQL-serverist, kaks iga andmekeskuse kohta: üks juht, ülejäänud on koopiad ja samuti kasutatakse tunnistaja c kvoorumi seade. Neljas elab üle kahe serveri või ühe andmekeskuse rikke. Seda lahendust saab vajadusel suurendada, et saada rohkem koopiaid.

Ajateenistus ntpd samuti konfigureeritud ümber veataluvuseks, kuid see kasutab meetodit ntpd (orb režiim). Jagatud server tunnistaja toimib keskse NTP-serverina, jaotades oma aja kõikidele klastritele, sünkroonides seeläbi kõik serverid üksteisega. Kui tunnistaja ebaõnnestub või osutub isoleerituks, siis hakkab üks klastri serveritest (klastri sees) oma aega jagama. Täiendav vahemälu HTTP proxy ka üles tõstetud tunnistaja, selle abiga saavad teised virtuaalmasinad juurdepääsu Yumi hoidlatele. Tegelikkuses majutatakse selliseid teenuseid nagu täpne aeg ja puhverserver suure tõenäosusega spetsiaalsetes serverites ja kabiinis, kus neid majutatakse. tunnistaja ainult virtuaalmasinate arvu ja ruumi säästmiseks.

Versioonid

v0. Töötab koos CentOS 7 ja PostgreSQL 11-ga VirtualBox 6.1-s.

Klastrite struktuur

Kõik klastrid on loodud paiknema mitmes andmekeskuses, mis on ühendatud üheks tasaseks võrguks ja peavad taluma ühe andmekeskuse rikkeid või võrguisolatsiooni. Sellepärast on võimatu eest kaitsmiseks kasutada lõhenenud aju nn standardne südamestimulaatori tehnoloogia STONITH (Shoot The Other Node In The Head) või vehklemine. Selle olemus: kui klastri sõlmed hakkavad kahtlustama, et mõne sõlmega on midagi valesti, see ei reageeri või käitub valesti, siis lülitavad nad selle sunniviisiliselt välja välisseadmete, näiteks IPMI või UPS-i juhtkaardi kaudu. Kuid see töötab ainult juhtudel, kui IPMI-serveri või UPS-i ühe tõrke korral jätkavad need tööd. Samuti kavatseb see kaitsta palju katastroofilisema rikke eest, kui kogu andmekeskus ebaõnnestub (näiteks on pingevaba). Ja sellise keeldumisega kõike stonith-seadmed (IPMI, UPS jne) ka ei tööta.

Selle asemel põhineb süsteem kvoorumi ideel. Kõigil sõlmedel on hääl ja töötada saavad ainult need, mis näevad rohkem kui pooled sõlmedest. Seda numbrit nimetatakse "pool + 1". kvoorum. Kui kvoorumit ei saavutata, siis sõlm otsustab, et on võrguisolatsioonis ja peab oma ressursid välja lülitama, st. see on nii lõhenenud aju kaitse. Kui selle käitumise eest vastutav tarkvara ei tööta, peaks toimima näiteks IPMI-l põhinev valvekoer.

Kui sõlmede arv on paaris (klaster kahes andmekeskuses), siis võib tekkida nn määramatus 50% / 50% (viiskümmend viiskümmend), kui võrguisolatsioon jagab klastri täpselt pooleks. Seetõttu paarisarvu sõlmede puhul lisatakse see kvoorumi seade - vähenõudlik deemon, mida saab käivitada kolmanda andmekeskuse kõige odavamas virtuaalmasinas. Ta annab oma hääle ühele segmendile (mida ta näeb) ja lahendab sellega 50%/50% määramatuse. Helistasin serverile, kus kvoorumiseade töötab tunnistaja (terminoloogia repmgr-ist, mulle meeldis).

Ressursid võivad liikuda ühest kohast teise, näiteks vigasetest serveritest teenindatavatesse serveritesse või süsteemiadministraatorite käsul. Selleks, et kliendid teaksid, kus neile vajalikud ressursid asuvad (kuhu ühendada?), ujuv IP (ujuv IP). Need on IP-d, mida Pacemaker saab sõlmede ümber liigutada (kõik on lamedas võrgus). Igaüks neist sümboliseerib ressurssi (teenust) ja asub kohas, kus peate sellele teenusele (meie puhul andmebaasile) juurdepääsu saamiseks ühenduse looma.

Tuchanka1 (tihendatud skeem)

Struktuur

Idee seisnes selles, et meil on palju väikese koormusega väikeseid andmebaase, mille jaoks on kahjumlik hoida spetsiaalset alluvserverit hot standby režiimis kirjutuskaitstud tehingute jaoks (pole vaja sellist ressursside raiskamist).

Igal andmekeskusel on üks server. Igal serveril on kaks PostgreSQL-i eksemplari (PostgreSQL-i terminoloogias nimetatakse neid klastriteks, kuid segaduse vältimiseks nimetan neid eksemplarideks (analoogiliselt teiste andmebaasidega) ja Pacemakeri klastreid nimetan ainult klastriteks). Üks eksemplar töötab põhirežiimis ja ainult see pakub teenuseid (ainult ujuv-IP viib selleni). Teine eksemplar töötab teise andmekeskuse alluvana ja pakub teenuseid ainult siis, kui selle ülemseade ebaõnnestub. Kuna enamasti osutab teenuseid (teostab päringuid) ainult üks kahest eksemplarist (ülemasin), optimeeritakse kõik serveri ressursid ülemseadme jaoks (mälu eraldatakse vahemälu jagatud_puhvrite jaoks jne), kuid nii, et teine ​​eksemplar tal on ka piisavalt ressursse (kuigi failisüsteemi vahemälu mitteoptimaalseks tööks) juhuks, kui mõni andmekeskus peaks ebaõnnestuma. Alamseade ei paku teenuseid (ei täida ainult lugemiseks mõeldud päringuid) klastri tavapärase töötamise ajal, nii et samas masinas pole ülemseadmega ressursside pärast sõda.

Kahe sõlme puhul on tõrketaluvus võimalik ainult asünkroonse replikatsiooni korral, kuna sünkroonse replikatsiooni korral viib alamseadme rike ülemseadme seiskumiseni.

tunnistajaks jätmine

tunnistamata jätmine (kvoorumi seade) Kaalun ainult Tuchanka1 klastri puhul, sama lugu on kõigi teistega. Kui tunnistaja ebaõnnestub, ei muutu klastri struktuuris midagi, kõik töötab edasi samamoodi nagu töötas. Kuid kvoorumiks on 2 kolmest ja seetõttu saab iga järgmine ebaõnnestumine klastri jaoks saatuslikuks. See tuleb ikka kiiresti ära teha.

Tagasilükkamine Tuchanka1

Tuchanka1 ühe andmekeskuse rike. Sel juhul tunnistaja annab oma hääle teise andmekeskuse teisele sõlmele. Seal muutub endine alluv ülemaks, mille tulemusena töötavad mõlemad ülemad samas serveris ja nende mõlema ujuv-IP-d osutavad neile.

Tuchanka2 (klassikaline)

Struktuur

Kahe sõlme klassikaline skeem. Peremees töötab ühel, ori teisel. Mõlemad saavad taotlusi täita (alamseade on ainult lugemiseks), nii et mõlemale osutab ujuv IP: krogan2 on ülem, krogan2s1 on alam. Nii ülem- kui ka alluval on veataluvus.

Kahe sõlme puhul on tõrketaluvus võimalik ainult asünkroonse replikatsiooni korral, sest sünkroonse replikatsiooni korral viib alamseadme rike ülemseadme seiskumiseni.

Tagasilükkamine Tuchanka2

Kui üks andmekeskustest ebaõnnestub tunnistaja hääletada teise poolt. Ainsas töötavas andmekeskuses tõstetakse ülem-IP ja mõlemad ujuv-IP-d osutavad sellele: ülem ja alam. Muidugi peab eksemplar olema konfigureeritud nii, et sellel oleks piisavalt ressursse (ühenduslimiidid jne), et üheaegselt vastu võtta kõiki ühendusi ja päringuid ülem- ja alam-IP-lt. See tähendab, et normaalse töö ajal peaks sellel olema piisav varu piirmäärade jaoks.

Tuchanka4 (palju orje)

Struktuur

Juba teine ​​äärmus. On andmebaase, millel on palju kirjutuskaitstud päringuid (tüüpiline suure koormusega saidi juhtum). Tuchanka4 on olukord, kus selliste päringute käsitlemiseks võib olla kolm või enam orje, kuid siiski mitte liiga palju. Väga suure hulga orjade puhul on vaja leiutada hierarhiline replikatsioonisüsteem. Miinimumjuhul (pildil) on mõlemal andmekeskusel kaks serverit, millest igaühel on PostgreSQL-i eksemplar.

Selle skeemi teine ​​omadus on see, et siin on juba võimalik korraldada üks sünkroonne replikatsioon. See on konfigureeritud replikeerima võimaluse korral teise andmekeskusesse, mitte ülemseadmega samas andmekeskuses asuvasse koopiasse. Ülem ja iga alam on tähistatud ujuva IP-ga. Igatahes tuleb orjade vahel teha mingisugune taotluste tasakaalustamine sql puhverserver, näiteks kliendi poolel. Erinevat tüüpi kliendid võivad nõuda erinevat tüüpi sql puhverserver, ja ainult kliendi arendajad teavad, kes millist neist vajab. Seda funktsiooni saab rakendada kas välise deemoni või klienditeegi (ühenduskogumi) jne abil. Kõik see ei kuulu andmebaasi tõrkesiirdeklastri (tõrkesiirde klastri) ulatusse SQL-puhverserver saab rakendada iseseisvalt koos kliendi tõrkesiirdega).

Tagasilükkamine Tuchanka4

Kui üks andmekeskus (st kaks serverit) ebaõnnestub, hääletab tunnistaja teise poolt. Selle tulemusel töötavad teises andmekeskuses kaks serverit: ülem töötab ühel ja ülem float IP osutab sellele (lugemis-kirjutamistaotluste vastuvõtmiseks); ja teises serveris töötab sünkroonse replikatsiooniga alam ja üks alluvatest ujuv-IP-dest osutab sellele (kirjutuskaitstud päringute jaoks).

Esimene asi, mida tuleb märkida: mitte kõik alluva ujuv-IP-d ei tööta, vaid ainult üks. Ja selleks, et sellega õigesti töötada, on see vajalik sql puhverserver suunas kõik päringud ümber ainsale järelejäänud ujuv-IP-le; ja kui sql puhverserver ei, saate ühenduse URL-is loetleda kõik ujuv-IP-alased, eraldatuna komadega. Sel juhul koos libpq ühendus luuakse esimese töötava IP-ga, nagu seda tehakse automaatses testimissüsteemis. Võib-olla teistes raamatukogudes, näiteks JDBC-s, see ei tööta ja on vajalik sql puhverserver. Seda tehakse seetõttu, et alluvate serverite ujuv-IP on keelatud üheaegselt ühes serveris tõusta, nii et need jagunevad ühtlaselt alamserverite vahel, kui neid on mitu.

Teiseks: isegi andmekeskuse rikke korral säilib sünkroonne replikatsioon. Ja isegi kui ilmneb sekundaarne tõrge, st üks kahest serverist allesjäänud andmekeskuses ebaõnnestub, säilitab klaster, kuigi ta lõpetab teenuste osutamise, siiski teavet kõigi sooritatud tehingute kohta, mille puhul ta kinnitas kinnituse (seal on puudub teave sekundaarse rikke kohta).

Tuchanka3 (3 andmekeskust)

Struktuur

See on klaster olukorrale, kus on kolm täielikult toimivat andmekeskust, millest igaühel on täielikult toimiv andmebaasiserver. Sel juhul kvoorumi seade ei ole vajalik. Ülem töötab ühes andmekeskuses ja alluvad töötavad kahes teises. Replikatsioon on sünkroonne, tüüp ANY (slave1, slave2), see tähendab, et klient saab täitmiskinnituse, kui mõni alluvatest vastab esimesena, et ta on kohustuse vastu võtnud. Ressursidele osutab üks ülem- ja kaks alam-IP-i. Erinevalt Tuchanka4-st on kõik kolm ujuv-IP-d tõrketaluvad. Kirjutuskaitstud SQL-päringute tasakaalustamiseks võite kasutada sql puhverserver (eraldi tõrketaluvusega) või määrake poolele klientidest üks alam-IP-ujuk ja teine ​​teisele poolele.

Tagasilükkamine Tuchanka3

Kui üks andmekeskustest ebaõnnestub, jääb alles kaks. Ühes tõstetakse ülem- ja ujuv-IP-d, teises alam- ja mõlemad alam-ujuvad IP-d (eksemplaril peab olema kahekordne ressursivaru, et aktsepteerida kõiki ühendusi mõlemalt alam-ujuvalt IP-lt). Sünkroonne replikatsioon ülemate ja alamseadmete vahel. Samuti salvestab klaster teabe sooritatud ja kinnitatud tehingute kohta (info ei kao) kahe andmekeskuse hävimise korral (kui neid ei hävitata samal ajal).

Otsustasin mitte lisada failistruktuuri ja juurutamise üksikasjalikku kirjeldust. Kui soovite ringi mängida, saate seda kõike lugeda LOEMEES. Annan ainult automaatse testimise kirjelduse.

Automaatne testimissüsteem

Erinevate rikete imitatsiooniga klastrite tõrketaluvuse kontrollimiseks tehti automaatne testimissüsteem. Käivitatud skripti järgi test/failure. Skript võib võtta parameetritena klastrite arvu, mida soovite testida. Näiteks see käsk:

test/failure 2 3

testib ainult teist ja kolmandat klastrit. Kui parameetreid ei täpsustata, testitakse kõiki klastreid. Kõiki klastreid testitakse paralleelselt ja tulemus kuvatakse tmux paneelil. Tmux kasutab spetsiaalset tmux-serverit, nii et skripti saab käivitada vaike-tmux-i alt, mille tulemuseks on pesastatud tmux. Soovitan kasutada terminali suures aknas ja väikese kirjatüübiga. Enne testimise alustamist muudetakse kõik virtuaalsed masinad skripti lõppemise ajal hetktõmmisteks setup.

Terminal on jagatud veergudeks vastavalt testitud klastrite arvule, vaikimisi (ekraanipildil) on neid neli. Kirjeldan veergude sisu, kasutades näitena Tuchanka2. Ekraanipildil olevad paneelid on nummerdatud:

1. Siin kuvatakse testi statistika. Kõlarid:
   • ebaedu — tõrget emuleeriva testi nimi (funktsioon skriptis).
   • reaktsioon — aritmeetiline keskmine aeg sekundites, mille jooksul klaster on taastanud oma jõudluse. Seda mõõdetakse tõrget jäljendava skripti algusest kuni hetkeni, mil klaster taastab oma tervise ja suudab teenuseid jätkata. Kui aeg on väga lühike, näiteks kuus sekundit (see juhtub klastrites, kus on mitu orja (Tuchanka3 ja Tuchanka4)), tähendab see, et tõrge sattus asünkroonsele orjale ega mõjutanud jõudlust kuidagi, puudusid klastri oleku lülitid.
   • kõrvalekalle - näitab väärtuse levikut (täpsust). reaktsioon standardhälbe meetodil.
   • loe Mitu korda seda testi on tehtud.
2. Lühike logi võimaldab teil hinnata, mida klaster praegu teeb. Kuvatakse iteratsiooni (testi) number, ajatempel ja toimingu nimi. Liiga pikk täitmine (> 5 minutit) viitab mingile probleemile.
3. süda (süda) on praegune kellaaeg. Visuaalse jõudluse hindamiseks meistrid praegune kellaaeg kirjutatakse pidevalt selle tabelisse, kasutades master's float IP-d. Kui see õnnestub, kuvatakse tulemus sellel paneelil.
4. lööma (pulss) - "praegune aeg", mille stsenaarium varem salvestas süda meisterdada, nüüd lugeda alates ori oma ujuva IP kaudu. Võimaldab visuaalselt hinnata alluva ja replikatsiooni jõudlust. Tuchanka1-s pole ujuva IP-ga orje (teenuseid pakkuvaid orje pole), kuid on kaks eksemplari (DB), seega seda siin ei kuvata löömaJa süda teine ​​aste.
5. Klastri oleku jälgimine utiliidi abil pcs mon. Näitab struktuuri, ressursside jaotust sõlmede kaupa ja muud kasulikku teavet.
6. See kuvab süsteemi jälgimise igast klastri virtuaalmasinast. Selliseid paneele võib olla rohkem – mitu virtuaalmasinat klastris on. Kaks graafikut CPU koormus (kaks protsessorit virtuaalmasinas), virtuaalmasina nimi, Süsteemi koormus (nimega Load Average, kuna selle keskmine kestus oli 5, 10 ja 15 minutit), töötlevad andmeid ja mälu eraldamist.
7. Teste sooritava skripti jälgimine. Rikke korral - äkiline töökatkestus või lõputu ootetsükkel - näete siin selle käitumise põhjust.

Testimine toimub kahes etapis. Esiteks läbib skript igat tüüpi teste, valides juhuslikult virtuaalse masina, millele seda testi rakendada. Seejärel viiakse läbi lõputu testimise tsükkel, iga kord valitakse juhuslikult virtuaalsed masinad ja rike. Testskripti järsk lõpetamine (alumine paneel) või lõputu millegi ootamine (> 5 minutit aega ühe toimingu sooritamiseks, see on jäljelt näha) näitab, et mõned selle klastri testid on ebaõnnestunud.

Iga test koosneb järgmistest toimingutest:

1. Funktsiooni käivitamine, mis jäljendab viga.
2. Valmis? - klastri tervise taastamise ootamine (kui kõik teenused on osutatud).
3. Kuvatakse klastri taastamise ajalõpp (reaktsioon).
4. Määrama - klaster on "remonditud". Pärast seda peaks see naasma täielikult töötavasse olekusse ja olema valmis järgmiseks rikkeks.

Siin on testide loend koos nende tegemise kirjeldusega:

• Kahvelpomm: loob kahvlipommiga "Mälu otsas".
• Ruum on otsas: kõvaketas on täis. Kuid test on pigem sümboolne, kuna testimise käigus tekkiva ebaolulise koormuse juures kõvaketta ületäitumisel PostgreSQL tavaliselt ei vea.
• Postgres-KILL: tapab käsuga PostgreSQL killall -KILL postgres.
• postgres-STOP: riputab PostgreSQL-i käsuga killall -STOP postgres.
• Väljalülitamine: "vabastab" virtuaalmasina käsuga VBoxManage controlvm "виртуалка" poweroff.
• lähtestama: laadib virtuaalse masina käsuga uuesti VBoxManage controlvm "виртуалка" reset.
• SBD STOP: peatab SBD deemoni käsuga killall -STOP sbd.
• Lülita välja: SSH kaudu saadab virtuaalmasinale käsu systemctl poweroff, lülitub süsteem elegantselt välja.
• ühenda lahti: võrgu isoleerimine, käsk VBoxManage controlvm "виртуалка" setlinkstate1 off.

Lõpetage testimine kas standardse tmuxi käsuga "kill-window" ctrl-b&või käsuga "detach-client" ctrl-bd: samal ajal on testimine lõppenud, tmux suletakse, virtuaalmasinad lülitatakse välja.

Testimise käigus tuvastatud probleemid

• Praegusel hetkel valvekoera deemon sbd peatab vaadeldud deemonid, kuid ei külmuta neid. Selle tulemusena on vead valesti välja töötatud, mis viib ainult külmumiseni Corosync и Südamestimulaator, aga mitte rippuma sbd... Kontrollimiseks Corosync juba on PR#83 (GitHubis kl sbd), filiaali vastu võetud meister. Nad lubasid (PR#83), et Pacemakeri jaoks on midagi sarnast, ma loodan, et selleks ajaks Punane müts 8 teeb. Kuid sellised "rikked" on spekulatiivsed, neid on lihtne kunstlikult jäljendada, kasutades näiteks killall -STOP corosynckuid ei kohtu kunagi päriselus.

• У Südamestimulaator jaoks mõeldud versioonis 7 CentOS valesti seatud sync_timeout у kvoorumi seade, tulemusena kui üks sõlm ebaõnnestus, taaskäivitus teine ​​sõlm teatud tõenäosusega, kuhu peremees pidi kolima. Kõvendatud suurendusega sync_timeout у kvoorumi seade juurutamise ajal (skriptis setup/setup1). Seda muudatust arendajad ei aktsepteerinud Südamestimulaator, selle asemel lubasid nad taristu selliselt ümber töötada (mingis määramatus tulevikus), et see aeg arvutatakse automaatselt.

• Kui määrasite andmebaasi konfigureerimisel, et LC_MESSAGES (tekstisõnumid) Unicode'i saab kasutada näiteks ru_RU.UTF-8, seejärel käivitamisel postgres keskkonnas, kus lokaat ei ole UTF-8, näiteks tühjas keskkonnas (siin südamestimulaator+pgsqlms(paf) algab postgres) logis on UTF-8 tähtede asemel küsimärgid. PostgreSQL-i arendajad ei leppinud kunagi kokku, mida sel juhul teha. See maksab, peate panema LC_MESSAGES=en_US.UTF-8 DB eksemplari konfigureerimisel (luumisel).

• Kui wal_receiver_timeout on seatud (vaikimisi on see 60 s), siis PostgreSQL-STOP testimisel masteris tuchanka3 ja tuchanka4 klastrites Replikatsioon ei loo uuesti ühendust uue juhtseadmega. Sealne replikatsioon on sünkroonne, seega ei peatu mitte ainult alam, vaid ka uus ülem. Saab, määrates PostgreSQL-i konfigureerimisel wal_receiver_timeout=0.

• Aeg-ajalt jälgisin PostgreSQL-i replikatsiooni rippumist ForkBombi testis (mälu ületäitumine). Pärast ForkBombi ei pruugi alluvad mõnikord uue ülemseadmega uuesti ühendust luua. Olen seda näinud ainult tuchanka3 ja tuchanka4 klastrites, kus replikatsiooni sünkroonsuse tõttu jäi master rippuma. Probleem kadus iseenesest, pärast pikka aega (umbes kaks tundi). Selle parandamiseks on vaja rohkem uuringuid. Sümptomid on sarnased eelmisele veale, mis on põhjustatud erinevast põhjusest, kuid samade tagajärgedega.

Krogan pilt tehtud hälbiva kunsti autori loal:

Allikas: www.habr.com