>=100Gbit/s lehetseges?

ZFS Fan Club

kene nekem siman backup tarolasra valami tarolo. a feltetelek:

- legalabb 1PB hasznalhato hely
- 100Gbit/s-et tudjuk koppantani par (10-20) streammel

kerestem friss infokat, de sehol nem talaltam sebesseget ekkora tombokre. meg lehet ezt ZoL-lal csinalni?

  • 1591 megtekintés

( gyuri23 | 2019. 10. 15., k – 22:11 )

A PB-vel nincs gond, de ha jól számolok 12.500 MB/s io sebesség kéne. Létezik egyáltalán olyan kontroller ami ezt megközelíti?
Ezt írni vagy olvasni kéne?

A TrueNAS M50-be 4x100GbE kártya mehet, csak SSD-vel talán.
https://www.ixsystems.com/truenas/

12Gbit/s van a diszk fele (ami olcso SATA eseten jo 6Gbit/s-nek is, de ez is boven sok HDDhez), viszont egy LSI HBA-ra mehet 1024 diszk is (expanderrel persze), a chipen belul sokkal nagyobb adatforgalmat tud nyilvan.

a KISTIsek szerint is eleg, de egy 9405W-16i-nek x16os PCI-e (v3) csatija van (ebbol van e verzio amin kulso SFF csati van)

namost ha van gepem amibe belemegy 3 ilyen HBA + 2db 100GbE-s kartya, akkor a (raw) savszel nem gond.

Néztem a doksiját, az triviális, hogy tudja a 1024x12Gbit-et? A switchek doksija megadja a max "áteresztő" teljesítményt, de kontrollereknél ez nem szokás, vagy én nem látok a sorok között. Ha viszont tudják a maximumot akkor mi indokolja az árkülönbséget a HBA kontrollereknél?

sehol nem mondtam, hogy 1024x12Gbitet tud. azt mondtam, hogy 1024 eszkozt kepes enumeralni, viszont ugye a kartyabol a diszkek fele 4db miniSAS csatlakozo megy (azt, hogy egy SFF-8643 csatin mekkora az atviheto savszel, itt hagyom Neked vegiggondolni), az alaplap fele meg PCI-e v3 x16.

a kontrollereknel az arkulonbseg abbol adodik, hogy a tri kontroller (amit linkeltem) tud NVMe-t is, illetve x16 - a legtobb HBA x8.

de siman lehet, hogy 4db x8-as kontroller jobb (az Exos dobozbol 8db miniSAS csati jon ki), viszont nem biztos, hogy lesz ennyi PCI-e helye az embernek egy dobozban (4db x8 2db x16 kene eddig)

nem olyan bonyolult ez:

- a diszk 6 v 12 Gbit/s-et tud, attol fuggoen, hogy SATA vagy SAS
- a kontrolleren ha megnezed, ez van: "4 Mini-SAS HD x4 SFF-8643", azaz fizikailag 4db SFF-8643 csati, de csatinkent 4 lane, azaz 4*4*12 = 192Gbit/s
- lefele x16 PCI-e v3, tehat 128Gbit/s

ha SAS diszk seq read/writeba tud >=200MB/s (>=1.6Gbit/s) -et, akkor az 4U106-os chassis elvileg tud 106*1.6 = 169.6Gbit/set.

ezert elgondolkodtato venni 90/106 diszkes JBODot, rarakni a gepre, berakni zraid2/3-be a diszkdobozon beluli zonakat (a 2/4/8 SAS portok zonazva vannak), es megnezni mi jon ki belole...

( NagyZ v | 2019. 10. 15., k – 23:09 )

na, talaltam friss prezit, ok a seagate Exos 4U106-jat hasznaljak (az IBM ESS GLxC -ben is ez van OEMezve), ZFS-sel, dobok egy levelet neki, megkerdezem mik a tapasztalatok azota :)

( balsa | 2019. 10. 15., k – 23:29 )

Isilon. Nekünk netto 800 TB van, hasít.

na meselj, miert ne akarnek GPFS-t, nagyon felkeltetted az erdekelodesemet ;-)

az Exos biztos, hogy nem kerul ennyibe, a 90 diszkes 5U-s Supermicro kb $8k halandok szamara (ertsd: bemesz a sarki PC boltba), szerintem $15k-nal nem dragabb (de nincs ra aram).

egy 90x14TB Supermicro JBOD olcsobb, mint amit linkeltel (szinten sarki pc bolt ar, netrol, nem kertem be arajanlatba SM-tol)

reg nem olvastam ekkora FUD-ot ;-)

ez valami regi verzio lehet, amirol beszelsz, de ha ezt elso kezbol lattad sajat clusteren akkor gondolom tudnal adni IBM defect szamokat is hozza, hogy megnezzem?

az ESS-t (es igazabol barmilyen GPFS clustert) el lehet erni
- nativan GPFS kliensekkel
- NFSen keresztul
- SMBn keresztul
- Swiften keresztul

tehat egyaltalan nem kotelezo neked egy SMB-n hasznalni, de tudok olyan nagy ugyfelet, aki ugy hasznalja, es elegedett.

cegen belul mi voltunk a legelso 4xESS GS4S szallitmany (blogomban vannak kepek meg leiras), RoCEv2-vel hasznaljuk sokszor 100Gbiten, es teszi a dolgat rendesen. nem azert akarnek pancsolni ZFS-sel mert rossz az ESS, hanem szimplan szivesebben vennek mas dolgokat is a budgetbol, ha ki tudom elegiteni a backup igenyeket mashogy. ezert szuletett ez a topic, hogy gyakorlati tapasztalatokat olvassak nagyon suru ZFS tombokkel kapcsolatban.

keves eselyt josoltam annak, hogy barki hasznal itt ilyet, de a hup mar tobbszor meglepett ,gondoltam hatha... :)

FUD ???
Látod ez a különbség köztünk, hogy te tudsz ügyfélről, én meg 12 és 17 között 5 évig ügyfél voltam.

A natív GPFS kliensről annyit, hogy arra nem volt képes az IBM, hogy Windows-on az általa 3 partyként használt unix runtime-ot támogassa, ami emiatt bezárt, és évekig runtime nélkül árulta azt.

""de tudok olyan nagy ugyfelet, aki ugy hasznalja, es elegedett.""

Én meg csak olyan ügyfélről tudok aki szerint ez szar (samba+ctdb), és itt most a világ egyik legnagyobb media csoportjáról beszélünk. De ha nekem nem hiszel, nézd meg a piaci részesedését a terméknek.

""keves eselyt josoltam annak, hogy barki hasznal itt ilyet""

Egyetértek, de b*ki szerinted miért van ez így?

""IBM defect szamokat""

Hogy mit? Bárcsak lenne egyáltalán support felülete az IBM-nek, de ez a cég még erre sem képes, mert a mai napig e-mailen kommunikálunk.

De hogy teljes legyen a FUD:

Már 3.hete várjuk a "next day guaranteed fix" supporttal rendelkező storage-ünk csere tápját (01SWX4D,740).

Vagy egy évig szar volt az LTO-6 driveok firmware-je és kapaszkodj meg, mivel késtünk a support hosszabbítással, nem volt hajlandó supportot kötni rá a cég, mert hogy rosszak.

az elso pontra: en is ugyfel vagyok, a mellett, hogy belul ulok, es latom a jot/rosszat - a mi prod rendszerunk is ESS-en fut.

ja, nem mondtad, hogy Windows. azon nem lattam, siman elhiszem neked, hogy ott vannak limitacio.

a "hasznal ilyet" az nem a GPFS-re vonatkozott, hanem >=1PB tarolora. hogy ez miert van, nem tudom. Te tudod?

IBM-nel _szoftver_ defectet (nem HW defectet) lehet nyitni webes feluleten, kapsz egy TS azonositot, amit lehet trackelni, erre gondoltam.

""ja, nem mondtad, hogy Windows. azon nem lattam, siman elhiszem neked, hogy ott vannak limitacio.""

Windows csak a kliens, az nsd szerver természetesen RH volt. Egyébként azért sem szerencsés a natív GPFS kliens használat, mert egy deadlock után az összeset indíthatod újra gépestől.

"" Te tudod?""

Media körben ez teljesen megszokott (mármint a 1PB), a miénk egy kifejezetten kis Isilon install a 10 node-al. A ZFS-es témára visszatérve jellemzően ekkora tárterületet már egyszerre több gép használ. Korábban blokkos eszközöket értek el osztott fájlrendszerekkel, de ez már erősen visszaszorult, ma sw defined storage-ok vannak amiket fájlmegosztási protokolokkal érnek el (cifsv3 nfsv4 s3). Ha belegondolsz életveszély kiadni blokk szinten egy storage-et bármely kliens számára.
A ZFS egy kissé zsákutca, mert vagy saját fs-t használnak belül (lsd Isilon) vagy a JBOD kernel szinten is még JBOD egyenként saját fs-el, mert úgyis az sw lesz az interfész kifelé.
A különálló JBOD doboz pedig azért nem pálya, mert nem csak a disket, hanem a cpu/mem-et is kell skálázni. Maradnak sokdiszkes szerverek.

"" a mi prod rendszerunk is ESS-en fut. ""

De le merném fogadni, hogy blokkos eszközként használjátok.

quoteolni amugy a hup motorjaval lehet rendesebben :P

Egyébként azért sem szerencsés a natív GPFS kliens használat, mert egy deadlock után az összeset indíthatod újra gépestől.

milyen GPFS verzio amugy?

Media körben ez teljesen megszokott (mármint a 1PB), a miénk egy kifejezetten kis Isilon install a 10 node-al. A ZFS-es témára visszatérve jellemzően ekkora tárterületet már egyszerre több gép használ. Korábban blokkos eszközöket értek el osztott fájlrendszerekkel, de ez már erősen visszaszorult, ma sw defined storage-ok vannak amiket fájlmegosztási protokolokkal érnek el (cifsv3 nfsv4 s3). Ha belegondolsz életveszély kiadni blokk szinten egy storage-et bármely kliens számára.
A ZFS egy kissé zsákutca, mert vagy saját fs-t használnak belül (lsd Isilon) vagy a JBOD kernel szinten is még JBOD egyenként saját fs-el, mert úgyis az sw lesz az interfész kifelé.
A különálló JBOD doboz pedig azért nem pálya, mert nem csak a disket, hanem a cpu/mem-et is kell skálázni. Maradnak sokdiszkes szerverek.

az, hogy tobb gep eri-e el az teljesen mas kerdes attol, hogy hanyan hasznaljak. en nagyon nem ertek ezzel egyet, hogy eletveszely lenne blokkot kiadni, nem is ertem mire gondolsz. azzal sem ertek egyet, hogy a CPU/diszket kell skalazni. csupan azert kell skalazni, mert szar a szoftver, bloatware, komplex, stb. az egyik kutatasi projektem pont erre iranyul, de itt van az SPDK-sok eredmenye, 10.39M IOPS egyetlen egy magon(!).

We set out with the wild goal of 10 million NVMe I/O per second on a single Intel® Xeon® core. The processor we used for testing was an Intel® Xeon® Platinum 8280L (Cascade Lake) which runs at 4.0GHz under turbo. This means we have only 400 core clocks (100ns) to work with for every I/O. This is, obviously, a really small budget. But we were able to hit our goal with a little room to spare.

szoval ja, a sok bloatware miatt kell 5x akkora gep, mint ami kene. a Ceph-es eloadasom jovoheten jol mutatja ezt, elfogy a CPU lenyegeben alatta...

De le merném fogadni, hogy blokkos eszközként használjátok.

nyertem akkor egy sort?

- hasznaljuk fajlrendszerkent VMek ala (sima fajlok rajta a VMek diszkjei)
- hasznaljuk VMware ala NFS-en felcsatolva
- hasznaljuk kuberneteshez NFS-sel szinten