Portál AbcLinuxu, 18. dubna 2024 08:54
Storage, který jsme si ukázali v předchozím zápisku, byl koncipován jako nejlevnější možné řešení pro dosažení co nejoptimálnějšího výkonu. Co na něm bylo lowcost?
Původní storage byl plně dostačující, ale úkol zněl jasně, pátý rok životnosti se blížil, takže nerozšiřovat, ale začít z čisté louky. Tím vznikl i prostor zužitkovat dosavadní zkušenosti a trochu to přiboostit.
Takže nový storage má spec:
Základ asi nemá smysl popisovat, AMD EPYC je jasná volba. Taktéž je jasná volba deska s PCIe 4.0, protože potřebujeme co největší propustnost kvůli NVMe a věcem okolo. 8x 32GB, protože osmikanálový EPYC nakrmíme osmi moduly. To nám dovolí do budoucna rozšířit storage aspoň na 350TB. Někdo by mohl namítnout, že už více ram přidat nemohu, ale takový růst dat je nepravděpodobný. Pokud by přecijen data rostly víc, tak výměna modulů nebude problém a současné se uživí jinde (máme více Supermicro s AMD EPYC, takže prostor je).
Má to jednoduché vysvětlení. Na celý storage/hw chceme záruku NBD (Next Business Day) po x let. A tyto Optane jsou lowcost/desktop (serverový jsou mnohem dražší, takže ano, jedná se o finanční úsporu). Takže i když dodavatel ze začátku říkal, že nám na ně NBD dá, tak asi prozřel, vystřízlivěl a dohodli jsme se, že NBD na disky zruší, cenu řešení včetně supportu nechá stejnou, jen nám dá navíc třetí Optane a jedině ty budou pod standardní zárukou. Z mé zkušenosti mohu říci, že toto si klidně lajznu. Ty disky jsou opravdu skvělý a nebojím se chcípání.
U.2 byl vybrán kvůli hotswapu. Kdyby opravdu něco, chci mít možnost ty disky vyndat/vyměnit za běhu.
Nu, jednoduše proto, že místo máme a U2 se lépe rozšiřuje (má více možností do něj naprat více věcí). Kdo má problémy s místem, tak do U1 by se to samozřejmě vešlo.
Toto bylo velké dilema, ale cena rozhodla. Oproti JBODu od Supermicro byla ta cena opravdu parádní. "102" v názvu pole udává počet možných disků. Dělají i menší variantu pro 60 disků. Podrobněji o tomto JBODu se dočtete níže.
Oba Optane pro SLOG jsou připojený přes NVMe na desce, takže NVMe na tom TriMode se nepoužívá. Každopádně použít tento řadič má dva důvody:
1) je ofiko podporovaný a s LSI není problém
2) podporuje PCIe 4.0, takže koupí staršího řadiče bychom se zbytečně do budoucna mohli omezit v podobě PCIe 3.0 only
Jednak to chtělo už SAS, aby šlo používat multipath a využívat tak i dva řadiče a mít tu komunikaci s diskama failoverovanou. WD proto, protože s ním mám vesměs dobré zkušenosti, a proto, že ten JBOD žere jen WD. 6TB varianta proto, protože na ten počet IOPS stačí, cena není špatná (je ještě výhodnější než u 4TB kapacity) a u této kapacity nespatřuji problém s výměnou/pomalostí resyncu apod. Dodavatel doporučoval, abychom koupili 8TB varianty, protože ty už v sobě mají Helium. Disky s ním mají nižší teploty a mnohem menší poruchovost. Cena, sizing a další věci ale rozhodly pro 6TB.
Oproti minulému storage je zapojení trochu jiné, vypadá takto:
Skládání vdevů po 8 discích se osvědčilo jako optimální, takže pool je poskládán takto:
5x RAIDZ2 (8xhdd), tj. celkem 40x SAS disk + 2x spare. Velikost poolu je tedy cca 218TB. Použitelných je cca 80-90%, tj. cca 175TB
Poslední scrub běžel 11:54:30. Na storage běží jedna VM s Windows Core jako backup proxy, nic víc, jinak slouží čistě jako úložiště pro zálohy. Výkon v IOPS apod. je podobný jako u prvního storage, přecijen ty Optane jsou podobný a sync jde přes ně, takže backup nyní běží bez problémů od 2,5Gbit do 6Gbit per server (podle toho, jaké možnosti má zdroj zálohování). Přechod na 40Gbit síť je v plánu, takže zatím vidím úzké hrdlo spíše v 10Gbit lince.
Stav poolu:
root@storage[~]# zpool status datastore1
pool: datastore1
state: ONLINE
scan: scrub repaired 0B in 11:54:30 with 0 errors on Sun Jan 31 20:54:32 2021
config:
NAME STATE READ WRITE CKSUM
datastore1 ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
gptid/e0c73b3f-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e11b87ec-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e155da8d-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e1ba807f-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e2085a42-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e244f725-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e25eb9a9-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e2f36486-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
raidz2-1 ONLINE 0 0 0
gptid/e1b4c16b-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e2d049dd-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e2bd2f36-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e34300d5-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e37918c0-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e3952071-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e3ddada3-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e43f013a-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
raidz2-2 ONLINE 0 0 0
gptid/e66787ec-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e6fad7ec-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e7030af7-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e78de0a9-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e7a41080-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e7e6ce17-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e8041a3d-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e8515c44-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
raidz2-3 ONLINE 0 0 0
gptid/e8ac1e51-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e914737e-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e93c2b35-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e97ec9c3-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e98d8e95-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e95eb55a-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/e9b53ca1-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ea2399d5-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
raidz2-4 ONLINE 0 0 0
gptid/eb4c05bc-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ebfc1f74-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ebf6e8ec-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ec581676-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ec81ebc7-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ec996a49-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ec853cf3-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ecbed015-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
logs
gptid/ec8a7f2c-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
gptid/ecc15c66-2971-11eb-ba5b-3cecef47a87c ONLINE 0 0 0
spares
gptid/ecd43c34-2971-11eb-ba5b-3cecef47a87c AVAIL
errors: No known data errors
Jelikož je to vesměs neprobádaná voda, tak pro zájemce mohu říci, že se mi to řešení líbí. Antivibrační systém mi přijde udělaný dobře. Dodávané lyžiny jsou opravdu pěkně naddimenzované, a to tak, že stojny v 1m racku jsme museli posunout na největší možné rozpětí, jinak by se nedaly uchytit. Tj. s 1m rackem to jde na milimetry a pole vyčuhuje jen nepatrně, resp. zadní kryt na rack se už nevejde, což nás netrápí.
Výhody
Nevýhody
Vesměs není moc co nastavovat, by default to nemá nastavené zóny, takže z tohoto pohledu to hned jede. Jediné co, tak nastavit IP, připojit k síti, změnit default hesla a nastavit monitoring přes web api.
Změna IPOba řadiče poslouchají na dhcp, takže připojit s notebookem, co poskytne dhcp lease. Default login na web interface je "admin:admin". Změnu nastavení sítě z dhcp na static se provede takto (je třeba dělat na jednotlivých řadičích zvlášť, tj. přepojit se kabelem):
curl -G -k -u admin:admin -H "Content-type: application/json" https://10.5.5.33/redfish/v1/systems/self/EthernetInterfaces/IOModuleAFRU |python -mjson.tool
{
"@odata.context": "/redfish/v1/$metadata#EthernetInterface.EthernetInterface",
"@odata.id": "/redfish/v1/Systems/Self/EthernetInterfaces/IOModuleA",
"@odata.type": "#EthernetInterface.v1_2_0.EthernetInterface",
"Name": "IOM A Ethernet Interface",
"Id": "IOModuleA",
"LinkStatus": "LinkUp",
"PermanentMACAddress": "00:0C:CA:07:08:12",
"SpeedMbps": 1000,
"HostName": "oobm-00:0C:CA:07:08:12",
"FQDN": "oobm-00:0C:CA:07:08:12.",
"FullDuplex": "true",
"IPv4Addresses": [
{
"Address": "10.5.5.33",
"SubnetMask": "255.255.255.0",
"AddressOrigin": "Dhcp",
"Gateway": "10.5.5.1"
}
],
"NameServers": [],
"Oem": {
"WDC": {
"Copyright": "Copyright \u00a9 2017-2020 Western Digital Corporation"
}
}
}
# změnit na statiku a vlastní IP:
curl -X PATCH --basic -v https://10.5.5.33/redfish/v1/Systems/Self/EthernetInterfaces/IOModuleARFU -H 'content-type: application/json; charset=utf-8' -u admin:admin --insecure -d '{"IPv4Addresses": [ {"Address":"192.168.50.81", "SubnetMask": "255.255.255.0", "AddressOrigin": "Static", "Gateway": "192.168.50.1"}]}'
Dokumentace viz:
Data60/102 - Configuring OOBM static IP Address using Redfish PATCH - Firmware Version 2.x
V základu jsou v řadiči založené 3 účty:
curl -G -k -u admin:admin -H "Content-type: application/json" https://192.168.50.81/redfish/v1/AccountService/Accounts |python -mjson.tool
{
"@odata.context": "/redfish/v1/$metadata#ManagerAccountCollection.ManagerAccountCollection",
"@odata.id": "/redfish/v1/AccountService/Accounts",
"@odata.type": "#ManagerAccountCollection.ManagerAccountCollection",
"Name": "Accounts Collection",
"Description": "Out-of-Band Management User Accounts",
"Members@odata.count": 3,
"Members": [
{
"@odata.id": "/redfish/v1/AccountService/Accounts/1"
},
{
"@odata.id": "/redfish/v1/AccountService/Accounts/2"
},
{
"@odata.id": "/redfish/v1/AccountService/Accounts/3"
}
],
"Oem": {
"WDC": {
"Copyright": "Copyright \u00a9 2017-2020 Western Digital Corporation"
}
}
}
Když se podíváme podrobněji, tak zjistíme:
https://192.168.50.81/redfish/v1/AccountService/Accounts/1 (admin, role: Administrator) https://192.168.50.81/redfish/v1/AccountService/Accounts/2 (operator, role: Operator) https://192.168.50.81/redfish/v1/AccountService/Accounts/3 (readonly, role: ReadOnly)
Je tedy potřeba změnit heslo u všech třech (heslo souhlasí vždy s loginem). Provedeme tedy takto:
curl -X PATCH --basic -v https://192.168.50.1/redfish/v1/AccountService/Accounts/2 -H 'content-type: application/json; charset=utf-8' -u admin:admin --insecure -d '{"Password":"SipkovaRuzenka123"}'
Nějaké foto z instalace:
Stále používám TrueNAS Core, od verze 12.0 se přešlo na OpenZFS 2.0, takže podpora nativního šifrování. Už žádné GELI. Používám tedy nativní šifrování a online kompresi.
Budoucnost je v Linuxu. FreeBSD je tedy postupně dodavateli opouštěno a TrueNAS je na řadě. Již teď se paralelně vyvíjí TrueNAS SCALE. Jedná se o Debian Bullseye + OpenZFS + nadstavba od TrueNAS. Většina kódu je společná, takže vymění motor a neměl by být takový problém. Na Linux se migruje ze spousty důvodů, ať už je to podpora dockeru/kubernetes, tak podpora kvm, linuxových kontejnerů, lepší podpora smb i nfs, lepší podpora hw a mnoho dalšího. V plánuje je i active-active režim. TrueNAS není jediný, kdo přechází na Linux, QNAP patří mezi další hráče, kteří už tak učinili.
Kdo nezná, tak multipath je možnost mít připojení zařízení přes více cest. SATA disky lze připojit jedním kabelem k jednomu řadiči. SAS disky lze připojit dvěma kabely k dvěma řadičům. Když chcípne řadič, tak pole by to mělo ustát. Další, v čem se SAS liší je v tom, že přes něj lze spravovat zařízení, třeba ten JBOD, viz sg3_utils a smp_utils a jejich nadstavba od WD v podobě WDDCS.
TrueNAS nemá problém, okamžitě pozná dva řadiče a automaticky nastaví multipath a vše funguje out of box. Ve světě FreeBSD se pro správu multipath používá "gmultipath", viz, jak to vypadá:
gmultipath list ... Geom name: disk42 Type: AUTOMATIC Mode: Active/Passive UUID: 053c34dc-29a5-11eb-ba5b-3cecef47a87c State: OPTIMAL Providers: 1. Name: multipath/disk42 Mediasize: 6001175125504 (5.5T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r0w0e0 State: OPTIMAL Consumers: 1. Name: da166 Mediasize: 6001175126016 (5.5T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: ACTIVE 2. Name: da167 Mediasize: 6001175126016 (5.5T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: PASSIVE 3. Name: da168 Mediasize: 6001175126016 (5.5T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: PASSIVE 4. Name: da169 Mediasize: 6001175126016 (5.5T) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r1w1e1 State: PASSIVE ...
Jak z výpisu můžete vidět, tak je vytvořeno multipath zařízení "multipath/disk42", jehož jsou součástí 4 disky. Ve skutečnosti je to jeden disk připojený přes 4 cesty. Prostě jsou mezi sebou proklemovaný do kříže 2x řadič na serveru a 2x řadič v poli.
Tentokrát jsem to vzal hodně šmahem, ale myslím si, že vše důležité již bylo řečeno v minulém zápisku. Pokud máte nějaké dotazy, tažte se.
Zdar Max
Tiskni
Sdílej:
3.3.2021 07:59
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
3.3.2021 08:37
Max | skóre: 72
| blog: Max_Devaine
3.3.2021 11:01
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
3.3.2021 10:44
xxxs | skóre: 25
| blog: vetvicky
3.3.2021 10:48
Max | skóre: 72
| blog: Max_Devaine
3.3.2021 10:50
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
=== START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 133 133 054 Pre-fail Offline - 93 3 Spin_Up_Time 0x0007 158 158 024 Pre-fail Always - 417 (Average 416) 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 13 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 128 128 020 Pre-fail Offline - 18 9 Power_On_Hours 0x0012 097 097 000 Old_age Always - 24132 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 13 22 Helium_Level 0x0023 100 100 025 Pre-fail Always - 100 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 1009 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 1009 194 Temperature_Celsius 0x0002 153 153 000 Old_age Always - 39 (Min/Max 25/46) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0A jsou rozhodne chladnejsi, nez klasicke disky.
3.3.2021 14:22
Max | skóre: 72
| blog: Max_Devaine
3.3.2021 18:18
Max | skóre: 72
| blog: Max_Devaine
Ten EPYC patří mezi nejlevnější CPU, není to žádný megaboost CPU. Jinak zapomínáš na online kompresy a šifrování přenášených dat + musí unést nějakou tu VM a zvládnout topku v podobě 15Gbit trafficu. Velikost záloh je cca podobná jako v předchozím zápisku. Tj. denně cca 2TB a jednou týdně dump 10TB databáze + pár věcí okolo. K tomu mám část vyhrazenou pro obnovu VM, takže částečně přes den to bude sloužít jako úložiště pro testovací VM (testování update/upgrade apod.). Třeba teď tam mám obnovený 6TB emailový systém a dalších 6 VM okolo, který to potřebuje k životu a budu na tom testovat upgrade na novější verze.
Pokud se podívám na aktuální stav těch dvou NVMe, tak už mají za tu chvilku pěkně naběháno:
Critical Warning: 0x00 Temperature: 41 Celsius Available Spare: 100% Available Spare Threshold: 0% Percentage Used: 0% Data Units Read: 20,959 [10.7 GB] Data Units Written: 118,014,644 [60.4 TB] Host Read Commands: 386,604 Host Write Commands: 477,363,227 Controller Busy Time: 432 Power Cycles: 11 Power On Hours: 2,667 Unsafe Shutdowns: 2 Media and Data Integrity Errors: 0 Error Information Log Entries: 0
Pokud bych se měl vyjádřit k tomu JBODu, tak uvidíme. Teď je tam 42ks disků, teplota nejstudenějšího disku je 28C, teplota nejteplejšího je 45C a větráky JBODu běží snad na nejnižší otáčky.
4.3.2021 10:25
Max | skóre: 72
| blog: Max_Devaine
3.3.2021 22:06
Gréta | skóre: 36
| blog: Grétin blogísek
| 🇮🇱==❤️ , 🇵🇸==💩 , 🇪🇺==☭
ato jakoby zustane takle ležet nebo seto strčí do racku nebo pověsí nazeď?? :O :O v těch točicích discích sou mechanický součástky těm je jako jedno když se disky takle třeba natočej vo 90 strupňů?? :O :O
3.3.2021 22:29
Josef Kufner | skóre: 70
4.3.2021 10:24
Max | skóre: 72
| blog: Max_Devaine
9.3.2021 12:02
Josef Kufner | skóre: 70
4.3.2021 10:08
Max | skóre: 72
| blog: Max_Devaine
storcli /c0 show all |grep -i temperature ROC temperature(Degree Celcius) = 53 storcli /c1 show all |grep -i temperature ROC temperature(Degree Celcius) = 54V místnosti chladíme na 18C. volně ložený temp sensor v racku ukazuje 21C.
a co tak slýchám, tak bezproblémový.Za mě si udělejte čárku k "problémový" LSI3008 a LSI3108 (provozovaný jako HBA). Musel jsem na discích vypnout zápisovou cache (cache_type = "write through") a NCQ (queue_depth = 1), jinak ten řadič tuhl. Sice ne trvale, ale dost dlouho na to, aby třeba vypadl disk z RAIDu
4.3.2021 11:58
Max | skóre: 72
| blog: Max_Devaine
4.3.2021 09:19
Max | skóre: 72
| blog: Max_Devaine
4.3.2021 10:20
Max | skóre: 72
| blog: Max_Devaine
aspoň 3 servery, spíše 4Ten čtvrtý je IMO navíc, pokud ho nepotřebujete kvůli kapacitě. Jinak pár let zpátky jsem byl na nějaké konferenci o úložištích - o Cephu tam mluvili nejvíc - a někdo z přednášejících měl spočítáno, že pokud z Cephu stavíte úložiště za účelem, který vám pokryje blackbox za půl milionu, tak se ten Ceph finančně nevyplatí. Zlom byl někde okolo 750 tisíc a nad to už Ceph vyšel cenově lépe. (Snad si ta čísla pamatuju dobře.)
výkon z toho nepůjde vyždímat takový jako u toho ZFSAFAIK Ceph nemá nic jako SLOG. (Teď jsem našel, že je to ve vývoji.) Má tiering, ale v dokumentaci je u toho hromada varování, že to s ním bude spíš horší, pokud zátěž není přesně taková, na jaké to bude fungovat
4.3.2021 11:45
Max | skóre: 72
| blog: Max_Devaine
sent 91,362,212 bytes received 385,674 bytes 423,777.76 bytes/sec
Oproti tomu ten samý rsync z jednoho adresáře pracovního stroje do jiného:
sent 91,362,533 bytes received 385,716 bytes 425,745.94 bytes/sec
Docela dobrá náhoda, že to vychází skoro stejně, ale je potřeba vzít do úvahy, že v tom druhém případě se na tom pracovním stroji zároveň zapisuje i čte, takže výkon RBD cca poloviční
Používám tedy nativní šifrování a online kompresy.Vizte poslední odstavec v https://www.abclinuxu.cz/blog/Max_Devaine/2019/9/zfs-stavba-zkusenosti-se-zfs-storage#2
4.3.2021 10:10
Max | skóre: 72
| blog: Max_Devaine
4.3.2021 10:14
cbrpnk | skóre: 8
| blog: bl0gium
4.3.2021 16:55
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
12.3.2021 14:56
Max | skóre: 72
| blog: Max_Devaine
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.