ZFS : Stavba a zkušenosti se ZFS storage (2)

3.3.2021 01:14 | Přečteno: 4076× | linux | poslední úprava: 4.3.2021 10:09

V prvním zápisku ZFS : Stavba a zkušenosti se ZFS storage jsme si ukázali lowcost řešení, nyní jdeme o stupínek výše.

Proč to bylo minule lowcost?

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?

• SLOG byl složen jen z jednoho disku (1x PCIe Optane), takže pokud by umřel, tak dojde k nekonzistenci poolu (z mé zkušenosti z pokusů jsem ani při simulovaném chcípnutí SLOGu nezaznamenal problém)
• byl použit Optane do PCIe, protože server neměl k dispozici NVMe připojení, takže v případě vadného Optane je nutná odstávka storage
• storage měl v sobě jen jeden řadič, takže nebyl failoverovaný + komunikace s disky jede jedním kanálem, který může vykazovat nějaké chyby a je to pak další problém k řešení
• byly použity SATA disky, ač s podporou TLER, tak stále mají jeden komunikační kanál
• pole šlo už rozšířit jedině tak, že by se přidalo další šasi a další řadiče

Jak tedy nově?

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:

• Supermicro H12SSW-iN
• AMD EPYC2 Rome (SPA3 LGA) 7302P
• Mellanox ConnectX®-3 EN MCX312A-XCBT
• 2x LSI TriMode 9400-8i8e(3416) SAS3/NVMe HBA
• 8x 32GB 3200MHz DDR4 ECC Registered 2R×4
• 3x Intel Optane SSD 905P Series 480GB (U.2)
• 42x 6TB WDC Ultrastar 7K600/HC310 - 7200rpm, SAS3, 512e, 256MB
• Case Supermicro SC826BE1C-R920WB 2U
• JBOD WD Ultrastar Data102

Proč se vybralo to, co se vybralo?

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).

Proč 3x Intel Optane SSD 905P Series 480GB

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.

Proč U2 case a né U1?

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.

Proč JBOD WD Ultrastar Data102?

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.

Proč LSI TriMode 9400-8i8e?

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

Proč 6TB WDC Ultrastar 7K600/HC310 - 7200rpm, SAS3

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.

Jak vypadá zapojení?

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

Zpět k JBODu WD Ultrastar Data102

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

• cena je velmi příznivá, skoro poloviční oproti JBOD od Supermicro a na míle daleko od HPE
• dvě nezávislá duální napájení
• dva nezávislé řadiče
• podpora zón a multizón
• možnost připojení až 6 hostů (přes SAS)
• každý řadič má ethernet pro správu, tzn. celkem dva porty
• antivibrační systém se zdá býti na velmi slušné úrovni (koneckonců se tím i WD chlubí)

Nevýhody

• do pole lze osadit jen disky od WD (to nás netrápí, protože k podobným účelům jsme je vždy kupovali od této značky)
• nemá web a ani pořádnou konzolovou správu, resp. pro web je poskytováno jen Redfish API (takže se tahají a posílají data v JSON, tzn. buď z command line, nebo přes devel mod ve web prohlížeči, existuje ještě nějaké universální cli od Redfishe, to se bude ještě testovat), z konzole lze spravovat přes SAS komunikační kanál
• vzhledem k velikosti je JBOD určen pro 120cm hluboké racky, do 100cm se nevejde, takže vyčuhuje
• horní kryt má magnetické čidlo, stačí trochu posunout krytem a větráky se rozjedou naplno

Konfigurace Redfish interface

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 IP

Oba ř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

Změna výchozího hesla

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:

TreueNAS Core a budoucnost?

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.

Multipath

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.

Závěr

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        

Komentáře

[Ruža Becelin]

> 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.

Tady souhlasim, navic 8TB disky mivaji nejlepsi pomer cena/TB. Asi jak kde.

My budeme stavet AiO NAS s 48x WD Gold 18TB, tak uvidime. Kazdopadne diky za tipy ohledne podvozku, na EPYCu to planujeme taky, a vypada to, ze jsme vybrali rozumne

[Max]

Také ZFS? Pokud ano, použijete i nějaké SSD na SLOG a jak případně plánuješ skládat pool? Jen se ptám.
Díky
Zdar Max

[Ruža Becelin]

Dobra otazka, pujde na to GlusterFS,ktery normalne provozujeme s XFS, ale jak se divam, ZFS je podporovane, takze tomu dame sanci.

Deska na EPYC ma 1 port na NVMe, kam pujde OS, a 4x SATA + 2x PCIex 4.0, coz nabizi solidni moznosti pro cache.

Rozlozeni poolu (v pripade, ze bychom zvolili ZFS) jeste nemame rozmyslene.

[Pavel Křivánek]

Jak je to s životností takových disků? Helium je potvora a časem zákonitě vyprchá.

[xxxs]

uz su na trhu nejaky cas. zatial nie je problem. moralne zastara skor ako sa stihne prejavit fyzika.

[Max]

Přesně jak píše xxxs. Vypadá to, že mají nižší teploty, menší poruchovost a lepší životnost než normální disky. Ostatně, nedávali by na ně záruku 5 let, kdyby byl s životností nějaký problém.
Osobně bych se toho tedy nebál. Kdybych měl na výběr bez helia a s heliem, tak jdu do helia.
Další věcí je, co je v tom reálně za plyn / v jaké koncentraci. Představa, že je tam čisté helium nemusí být pravdivá (je to jen zamyšlení, nebádal jsem po tom).
Zdar Max

[Ruža Becelin]

Zivotnost je zatim OK, po dvou letech se hladina ani nehnula:

=== 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       -       0

A jsou rozhodne chladnejsi, nez klasicke disky.

[j]

"...a mít tu komunikaci s diskama failoverovanou. "

Sak to stejne nemas, coz je presne ten rozdil v ty cene proti HP a spol. Mas tam SPOF v podobe MB, CPU, RAMky ... cokoli z toho pojde === pole lehne.

U tech "drahych" poli tam mas proste dve PCcka (vcetne vlastni ramky, cpu a radice) a kazdy jedno muzes vytrhnout a vymenit. Dal je to samo zapojeny do dvou swichu, takze ani tam neni SPOF. A typicky pak nekde za tim mas servery v clusteru, takze ani tam ti neva kdyz neco lehne.

"do pole lze osadit jen disky od WD"

Pokud sem neco neprehlid, tak "JBOD WD Ultrastar Data102" je jen tupa krabice na disky. A tudiz o tom jaky disky ano a jaky ne rozhoduje radic. Takze mozna je to spis "jen disky od WD v ramci supportu".

---

Dete s tim guuglem dopice!

[Max]

Nikdo ale nerozporuje, že pole od NetAppu, HPE aj. jsou failoverovaný ještě dál. To je snad jasný. Jsou to většinou dva plnohodnotné servery, mezi kterými je udělaný buď interní propoj, nebo externí (=kabelové propojení řadičů).
Já jsem jen zmínil rozdíl od předchozího modelu pole, který jsem popisoval v předchozím článku.

Ten JBOD není jen šasi, jak píši, má to OOBM, podporuje to konfiguraci zon a multizon, acl apod. Je pravda, že jsem do toho nezkoušel strčit jiný disk (ani nevím, zda tu jiný mít budu), ale možnosti, jak si to ten jbod může pohlídat, rozhodně má.
Zdar Max

[ET]

neplanujes pak nejaky perf grafiky z provozu, pac mi prijde, ze:

* ten EPYC2 na "par plotnacu" (a jednu vm) jako over-kill

* tem plotnacum uprostred ty "JBOD kastle" bude vedro (i kdyz bude v lednici 20C)

mozna se pletu, jen by me to zajimalo (a chapu, ze to neni investice na 1 rok a nevim, co na tom chces dalsiho v budoucnu provozovat)

jinak to mas pekny ;)

[Max]

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.

Zdar Max

[ET]

nice, thx

a mas tam rozjety nejaky monitoring? celkem by me zajimalo, kolik z toho CPU (orientacne) vyuzijes pri tyhle zatezi - tj. 15gbs + komprese (AES[NI] asi nebude cpu killer a je uz celkem bezny)

kolik mas beznou teplotu v lednici (serverovne)? 45C na plotnaci mi prijde uz trochu na hrane, ale kdyz to videj vetraky jinak, tak snad ok

[Max]

V místnosti 18C, zatížení CPU nula nula nic, ale 15Gbit tam ještě v plném proudu nešlo.
Zdar Max

[Gréta]

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

[Josef Kufner]

Není dobré s nima hýbat za provozu, ale jinak to je jedno.

[Max]

I samotné desktopové skříně jsou koncipovány různě. Některé mají uložení disků na ležato, jiné na stojáka. Rozdíl v životnosti by snad neměl být. Někdo by mohl říci, že na stojáka tam bude větší tlak na opotřebení ložisek, ale v reálu jsem neslyšel o tom, že by to měl být problém.
Zdar Max

[j]

"větší tlak na opotřebení ložisek"

Nebude, je to jedno, sak maj stejne vsechny ty loziska fluidni, takze by ke kontaktu vubec dochazet nemelo. A nevadi jim ani to ze bys snima hejbal, pokud nepresahnes mezni Gcka. Pak to odnesou plotny a hlavicky.

Pri tomhle usporadani bych videl problem spis prave v tom, ze ty disky uvnitr budou dostavat naprdel teplotne. Rozdil skorem 20 stupnu mezi vnejsima a vnitrnima je dost a to pocitam ze nic moc nedelaj. Nemyslism si ze by libovolny vetraky byly schopny v tomhle usporadani vyrobit nejakej pruvan.

---

Dete s tim guuglem dopice!

[Josef Kufner]

Mezní G jsou uvedena pro vypnutý stav, kdy se netočí a hlavičky jsou zaparkované. Gyroskopický efekt je ošklivá věc a plotnám se to nebude líbit. Ty hlavičky létají velmi nízko a opravdu nechceš, aby se dotkly povrchu. Není to o tom, že by se disk rozbil jen s ním trochu šoupneš, ale některé notebooky třeba mají akcelerometry a zaparkují hlavičky, když detekují pád. (V dobách SSD už to ale není moc relevantní.)

[johnyK]

my jsme po letech abstinence zase koupili LSI RAID Controler. A vlastne jsem ani nebyl prekvapen, kdyz jsem na chladici zmeril 90 °C. (pro 22 °C okolo - jak to asi bude vypadat v lete?) Na netu jsou miliony stiznosti, ze se vlastne prehrivaji vsechny radice (HP, Dell ...)

Mate take takove zkusenosti? Autor rika, ze LSI zadny problem? Jak je to s teplotami? Me to prijde, ze je to moc, i kdyz v technickych listech jsou teploty kolem 100 °C jeste jako povolene.

[Max]

LSI je dost dobrý HBA, je podporovaný, a co tak slýchám, tak bezproblémový. Osobně ho vídám všude, i integrovaný na supermicro deskách. Pokud jde o ty LSI HBA zmíněné v zápisku, tak teplota je úplně ok:

storcli /c0 show all |grep -i temperature
ROC temperature(Degree Celcius) = 53

storcli /c1 show all |grep -i temperature
ROC temperature(Degree Celcius) = 54

V místnosti chladíme na 18C. volně ložený temp sensor v racku ukazuje 21C.

Problémy s teplotou při běžném provozu jsme snad nikdy nezaznamenali. Jednou se podělali klimatizace a v serverovně bylo asi hodinu kolem 40C, teplota komponent v serverech šla k 80C při plných otáčkách větráčků, a i tak nebyl problém. Jaké byly teploty na řadičích (většinou HPE SmartArray P420i apod.) ale nevím.

Jinak musím říci, že mi máme HBA, ty mluvíš o Raidu, takže tam to bude trochu jiné. Naposledy jsme brali LSI MegaRAID SAS9341-8i, tam jsou teploty kolem 56C (teplota v racku 19,5C).
Zdar Max

[trekker.dk]

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

[Max]

A co to bylo za disky?
Zdar Max

[trekker.dk]

SSD Samsung (SM863 a podobné) - a rotační nějaké Toshiba (podle toho, kdo ještě rotační disky v dané době vyráběl.) U těch SSD se to dělo častěji, co jsem vypátral (byly to teda většinou debaty typu "za úplňku obětujte černou slepici" z různých diskuzí), tak jako největší podezřelý se jevil příkaz k synchronizaci cache disku. Což by odpovídalo, protože na těch SSD leží databáze, takže tenhle příkaz bude častější než u těch rotačních.

[Bebín]

Hezké, ale zastaralé. Měl by ses podívat na CEPH a neřešit věci jako multipath, neflexibilní ZFS nebo úzké hrdlo 10 GBit per stroj.

[Max]

Poskládat podobně výkonné pole na CEPH vyjde o dost dráž a ve finále to pro tento účel nepřinese nic navíc.
Zdar Max

[trekker.dk]

Odstraníte nějaký ten SPOF, ale jinak jo, bylo by to dost drahé.

Nemůžu to teď vyzkoušet - zjistil jsem, že nemám celý testovací cluster zkonvertovaný na bluestore - ale krom ceny bych si tipnul, že by si to ani moc nerozumělo s výkonem. RBD má výchozí velikost bloku 4M a cokoliv menšího AFAIK znamená přepis celého bloku, protože ochranné součty. A dokopat klienty k tomu, aby posílaly 4MB velké bloky, je nereálné, v Linuxu je napevno nastaveno, že disky mají bloky o velikosti 4kB nebo 512B. (Což částečně může pořešit slučování operací, ale jen částečně.)

Plus se zpravidla nepočítá s tím, že "disk" je celý cluster a že se tam mají hrnout požadavky po desítkách.

[Max]

Jinak ještě doplním, že pro menší nasazení ti stačí dva servery jako storage, děláš sync active-pasive, případně active-active (pokud to to řešení umožňuje). Když padne jeden server, nebo jedna lokalita, jsi v pohodě. Aby jsi tento druh failoveru pokryl Cephem, tak v každé lokalitě musíš mít aspoň 3 servery, spíše 4. Je jasné, že Ceph nabízí jiné možnosti, ale je to názorná ukázka toho, jak ta cena/režie nejsou zanedbatelné (8 serverů vs 2, tj. více zabraného místa v racku, více žraní proudu, více žraní/dimenzování klimy na uchlazení místnosti atd.). V případě Cephu může podvádět a mít více nodů na jednom fyzickém železe, ale jaký to pak má reálně smysl, případně budou tam mnohem větší režie na provoz / ten výkon z toho nepůjde vyždímat takový jako u toho ZFS.
Zdar Max

[trekker.dk]

aspoň 3 servery, spíše 4

Ten č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 ZFS

AFAIK 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

[Max]

Ten zlom 750k podle mě neodpovídá, bude mnohem vyšší, tedy pokud budeme chtít být k těm jiným řešením féroví. Pokud stavím něco od nějakého vendora, tak věř, že sundat z pricelistu 70% i více nemusí být problém.
Zdar Max

[trekker.dk]

Jak jsem koupil, tak prodávám - teda jak říkám, pokud si ta čísla pamatuju dobře, ale určitě to bylo pod 1M. A nemyslím si, že to bylo porovnáváno s ceníkovou cenou těch blackboxů.

Jinak jsem udělal výkonový pokus - rsync adresáře, ve kterém mám zdrojáky, tj. spousta malých souborů a git archivy, z pracovního stroje na zálohu - filesystém připojený na RBD. Změny asi za 3/4 roku:

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í

[plostenka]

RBD je urcene na zviditelneni pole pres sit, takze pochopitelne na localhostu bude mit mizerny vykon v porovnani s lokalnim RAIDem.

[trekker.dk]

To samozřejmě ano, nicméně i když se síť vyloučí, tak ten výkon je furt horší než lokální disky. A je to z principu, zaokrouhlení zápisů na 4MB nahoru se prostě někde poznat musí.

[trekker.dk]

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

[Max]

No tvl, zásah do černého. Je vidět, že v případě jazyků nebudu nikdy patřit mezi nejostřejší pastelky v penále :-/
Zdar Max

[cbrpnk]

Chcel som pôvodne písať blogový zápisok o nasadení TrueNAS Core na zálohovaci server pre malú firmu (HP Microserver Gen 8 i3 s 8BG RAM + 256GB NVME cache + 3 x 8TB HDD (14TB space) v RAIDZ1) ale nejako ma to prešlo

[Ruža Becelin]

Proc? Kazda zkusenost dobra

[loco]

No, mě by to i zajímalo, nejsem v tom moc kovanej. Mám Microserver Gen8, tu zeleninu 1610T jsem vyměnil za Xeon E3 1220L V2, a mám tam 8GB RAM. Dřív jsem jel RedHat 7.x, pak jsem přešel na FreeNAS (ZFS), a teď jedu už nějakou dobu debian. Mám tem jenom nextcloud plus nějaký nfs a smb share. Stačila by ta RAM pro to ZFS? Mě to s tím vycházelo celkem na hraně dle doporučení, a to jsem tam měl pouze 2xTB disky, ale zase žádnej velkej nápor uživatelů nehrozil. FreeNAS jsem opustil proto, že se mi v té době nepodařilo rozjet nextcloud v té virtualizaci s certifikátem ..., a taky jsem si myslel že mám potřebu běhu dalších virtualizovaných kontejnerů v dockeru, a na linuxu mi to přišlo jednodušší.

[Max]

Jak reálně s pamětí máš myslím přehledně popsáno v minulém zápisku: Kolik je potřeba paměti?.
Pokud jde o ZFS, tak to si můžeš provozovat i na tom Debianu.
Zdar Max

[loco]

Díky, to jsem přehlédl.

Mrkl jsem na to a to doporučení v tom předchozím zápisku, odpovídá tomu co doporučoval Freenas, pro 8TB ~ 8GB za předpokladu nízké režie os. Co mě spíš děsí, že když dojde RAM tak se to sesype... Když bych to osadil 4x4TB, tak jsem na tom co to zhruba alokovalo dle zápisku. K tomu tam byl tenkrát ten Celeron... S problémy s ext4fs si umím poradit ale zfs moc ošahané nemám. Teď mám problém, že na Big Sur mi přestal jet time machine na nfs share a lidi co to rozchodili, měli úspěch jenom na zfs a možná btrfs. Proto o něm zase uvažuji, ale přidávat paměť na to domácí nasováni se mi moc nechce, už jenom nové disky budou pěkných pár tisíc.

Žďár, jdu na to mrknout hlouběji.