DRBD 8.3.12 - magas Load

Linux-haladó

Help! Adott két noname azaz saját kezűleg összerakott "szerver", Core i7, Gigabyte P55A-UD4, 8GB RAM, 3xSamsung HD103SJ, 3xIntel PRO/1000 GT. Ebből két hálózati kártya keresztkábellel összekötve, bonding mode=0, full duplex. Szoftver oldalon CentOS 5, OpenVZ Kernel (2.6.18-274.18.1.el5.028stab098.1), Samba3, forrásból fordított DRBD 8.3.12 kernel modul, single-primary mode:protocol B (vagy A vagy C sajnos tökmind1). LAN oldali hálózat régi, 100 megabit. Storage oldalon (szoftver)md0->drbd->lvm->ext4.

Van, kb. 30 aktív felhasználó, akik régi XP+command.com+Clipper+DBF alkalmazást futtatnak, nappal humán terhelés, este automata feldolgozások a kettő között kell az LVM Snapshot a napi mentéshez. Ennek megfelelően a hálózat felől érkező terhelés zöme kismérteű 76-150 bájt közötti csomagokból áll.

Ha az első node egyedül van azaz a kettes node-on nem fut a drbd sem, akkor csúcsidőben is vígan kiszolgál minden kérést, a Load 0.7 és 2.6 között mozog a terhelés függvényében.

Ha a második node-on fut a DRBD (UpToDate/UpToDate), akkor meredeken felszökik a Load 10 fölé, és 10-17 között mozog a válaszidő ennek megfelelően brutálisan megnő, belassul mint a dög. Amint leállítom (drbdadm disconnect all) a kettes (Secondary) node-on a drbd-t, a primary nodeon azonnal meredeken visszaesik a load 0.7 és 2.6 közé, a válaszidő tökéletes lesz, mint a villám.

Ha a kettes node connected, akkor is csak a napközbeni terhelésnél száll el a Load, délután és este nem vészes, 2-7 közötti olyankor, miközben ekkor is, ha leállítom a kettest, akkor azonnal 1 alá esik a Load.

A bajom az, hogy protokol A esetén is ugyanez a helyzet, meg B esetén is. A C-t nem is ragoznám.

CPU terhelés elenyésző, legrosszabb esetben is még 90% idle a top szerint, még 17-es Load közben is, a swap-re nem kerül semmi, memóriából bő 6GB marad szabad az meg diszk cache (cached) a free szerint. Bár gondolom nem mérvadó, de ha áll a secondary, akkor az iostat/sar szerint az sdb, sdc (md0) és drbd eszközön alacsonyabb vagy sokkal alacsonyabb %util mint az md0(sdb1,sdc1) diszken. Ha kapcsolódva van a secondary akkor a drbd eszközön a %util már akkor is 100% ha a diszkeken csak 50-70% közötti. Igazából nem tudom a drbd esetén a %util mennyire valós mivel úgy tudom a drbd-nél nincs queue tehát nem tudom hogyan számolja ezt az értéket. Ja, elevator=deadline. iperf szerint a crosslink 925 Mbits/sec. top %wa szétkapcsolt állapotban mindig 10 alatt van, néha felugrik nulláról 1-3-8 de vissza is megy, míg kapcsolódva akár 30 fölé is megy.

Van-e valakinek ötlete? Előre is köszönet!

A következő lépés egy régebbi drbd verzió próbája lesz, egyelőre 8.3.10 lesz a következő, bár sok reményt nem fűzök hozzá.

szerk.: drbd.conf

  • 4435 megtekintés

( dikki | 2012. 04. 03., k – 15:05 )

van, keves neki a halozat, egyszeruen nem eleg gyors a drbd forgalma es emiatt megno a load, mert i/o-ra var. keves egyertelmubb eset van.

Bingó! Ezeket a változtatásokat eszközöltem azon felül, hogy 9000 lett az MTU a crosslinken (de gyanítom ez korábban is így volt, csak elfelejthettem beírni konfigba és ez veszett el szombaton a rebootnál).

net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.core.netdev_max_backlog = 30000

net.ipv4.tcp_window_scaling = 1
net.core.wmem_max = 12582912
net.core.rmem_max = 12582912
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912

Most teljesen jónak tűnik. Ugyan ma még a tegnap terhelés fele sem volt, jelenleg átlagosan 600 körül van a disk_ops, a Load meg 0.8 és 1.9 között. Szóltam, hogy kellene terhelni kicsit, 1200-ig sikerült felvinni és 3.2 volt a Load teteje. Azt gondolom ez így jó lesz, most jön az a bölcsesség, hogy nem piszkáljuk. Ámen.

3 db mezei 7200rpm-es sata diszkkel hoztad ezt össze?

Az szép, mert az a 3 diszk natív módon nem tud szumma 1500 iops-ot. Azaz egyfelől szénné vannak hajtva iops-ilag, másrészt valószínűleg ezt a teljesítményt is csak a bekapcsolt write-behind cache miatt tudod hozni (ami meg egy potenciális bomba).

3 db mezei 7200rpm-es sata diszkkel hoztad ezt össze?

Nem dehogy, kettővel, az elsőn van a root meg bő 600GB szabad hely. :) Erre volt keret, de ez is egy év volt mire lett rá, de akkor meg azonnal. A beüzemelés óta tervben van, hogy inkább RAID0 kéne inkább a mostani RAID1 helyett, hogy csökkenjen a terhelés a diszkeken. A jelenlegi elosztás megváltoztatása sem gond, a rootot is tudom mozgatni akár, de például egy RAID10-hez akkor is kéne még egy diszk, amit nem lesz könnyű megvetetni, de folyamatban van. Már emésztik. Mármint 1db-ot, a másik node az egy külön harc lesz majd. És ha az meglesz akkor az nyilván még mindig karcsú lesz ahhoz, hogy a write-behind cache kikapcsolható legyen. A másik lehetőség, hogy a mostani RAID1-et szétszedem és RAID0 lesz belőle, csak az így elég kockázatos bár ha a write-behind cache marad akkor lehet, hogy valójában tök mind1, hogy RAID10 4 diszkkel vagy RAID0 2-3 diszkkel.

Ellenben szerinted egy SSD meddig maradna életben ilyen terhelés mellett? Kinéztem egy Corsair Force3 GT 120GB-t, ebben szinkron Nand Flash van, de egyet is nehéz lenne megvetetni, ha meg évente kell újat venni akkor esélytelen, akkor fel sem vetem.

az iops-t kellene valahogy csökkentened.
a drbd felett lévő filerendszert noatime-mal csatoltad?
írtad az openvz kernelt, vannak esetleg konténereid? ha igen, asszem 'vzctl set $id --noatime yes --save'
a win klienseken nem tudom, hálózati fájlrendszer esetén van-e értelme, de ki lehetne próbálni az ntfsdisablelastaccessupdate bekapcsolását (http://technet.microsoft.com/en-us/library/cc959914.aspx)
az alkalmazáson ilyen szempontból nem lehetne tuningolni valamit?
valamit biztos segítene több memória is, többet cachelhetne a gép, talán csökkentené a random seekelést.
illetve ha van még más funkciója a szervernek, pl webszerver, adatbázis, stb azt érdemes lenne fejleszteni (mysql-nek sokkal több buffer cache és társai, webszervert memcached irányban bővíteni, stb)

"az iops-t kellene valahogy csökkentened."

(szoftver) RAID0 ?

"a drbd felett lévő filerendszert noatime-mal csatoltad?"

Igen, természetesen: acl,user_xattr,noatime,nodiratime

"írtad az openvz kernelt, vannak esetleg konténereid? ha igen, asszem 'vzctl set $id --noatime yes --save'"

Ennek (és a kliens oldali dolognak) utánajárok, 1db konténer van, abban fut a Samba, semmilyen más alkalmazás nem fut.

"az alkalmazáson ilyen szempontból nem lehetne tuningolni valamit?"

De lehetne sokat, csak örülnek ha működik, amikor nem akkor meg a szerver a szar. Nem igazán lehet átvinni semmit. A könyvtárstruktúrán sokat lehetne javítani, például nem kéne saját maguk alá szemetelni a TMP DBF-ekkel és nem lenne több tízezer fájl az adatkönyvtárakban amit a kolléga kézzel gyomlálgat néha.

Csak, hogy konstruktívabb legyek:

A mért 1500iops érzéki csalódás. Ennyit nem tud leadni a két diszk.
Az a disk ops/sec érdekes, de semmit mondó, mert nem tudni, hogy hol (értsd: melyik rétegben) mérte a rendszer. A két vacak sata diszkre fizikai képtelenség ekkora iops-ot ráküldeni.
Ez az érték még az előtt lett mérve, hogy bármi féle IO merge, vagy reordering történne, innentől kezdve a tényleges diszk IO ismeretlen.

[a többi okosságot töröltem, mert úgy látom végülis a jumbo frame hiánya volt a ludas.]

Hát, az volna a kérdés, hogy ez az egész konfig tulajdonképpen mire is volna jó.

Három út létezik:

- lemondasz az adatkonzisztenciáról (automatikus backupnak, failovernek innentől kezdve bizonyos esetekben használhatatlan lesz a rendszered, Murphy-törvénye értelmében kb. pont akkor nem lesz jó, amikor a legjobban kéne - tervezett mentéshez jó lesz, azaz ha minden mentés előtt szinkronizálod/szétkapcsolod, akkor okés, csak áramszünet/oprendszer crash ne jöjjön),

- lemondasz a teljesítményről (a write-behind cache-t kikapcsolod a diszkeken, ennek hatására tovább fog esni az írási teljesítmény - felére/harmadára/negyedére, cserébe áramszünet/oprendszer crash/stb. esetén is van egy működő mentésed/tartalékod, plusz ha valami oknál fogva nem lennének az ext4-ben az adatkonzisztencia funkciók bekapcsolva, akkor azokat be kéne: data=journal,journal_checksum,journal_async_commit,barrier=1), ha olyan szintű konzisztenciát akarsz, hogy amire a program egyszer azt mondta, hogy ki van írva diszkre, az egy failovernél ne tűnhessen el (felhasználónak visszajelez a program, majd crash/failover után nincs meg az adat), akkor ezen felül még szinkronra kell állítani a drbd-t, ami azzal jár, hogy minden diszkírás ideje (latency) kb. a 2-5-szörösére nő,

- zsebbe nyúlás történik, vesztek valami normális, iops-ot tudó cuccot.

Ez utóbbi lehet SSD-alapú (itt tényleg kérdéses a várható élettartam, de kb. ez a megfizethető szint), lehet HW RAID kártya BBWC-vel, lehet külső, intelligens storage eszköz, amiben van valamilyen akkumulátorral védett cache. Az árak nagyjából ebben a sorrendben emelkednek, az utolsó verzió, az már milliós.

"Hát, az volna a kérdés, hogy ez az egész konfig tulajdonképpen mire is volna jó."

Ez egy félig saját készítésű HA Cluster. :-) Az OpenVZ konténerben fut a Samba "A szerver". md0->drbd->lvm->ext4->VE->Samba. A konténerben veth interfész van, ami a hoston bridge-elve van a lan kártyával, így az IP cím a konténerben van így a konténerrel együtt megy az IP cím is. Az ötlet innen jött.

Maga a Cluster a RedHat Cluster egy része, cman+rgmanager+fenced. A fencing a soros porton egy-egy RPS-10. Nincs DLM meg GFS, az rgmanager alá megírtam az erőforrásokat (pl. openvz konténer) kezelő scripteket, jó sokat. Sokat teszteltem sok testhelyzetben, működik is (live migráció is van), ezzel (szerintem) nincs gond, persze brand cluster nyilván jobb, csak ezt így most nem merném GFS fölé tenni, mert szerintem megölnének. Meg úgysem lesz kettőnél több node. Külön szünetmentes van mindkettőn, egyelőre az a cache battery. Kici óccó.

Az egész lényege az, hogy ne legyen (jelentős) adatvesztés (ha nem live migráció történik hanem igazi failover akkor a DBF adatbázist úgyis újra kell indexelni, az utolsó rekord elvesztésébe nem halnak bele, ha más nem a programozó majd belefaragja, gyorsan megoldják, a DBF-el akkor is állandóan vannak gondok amikor szerver oldalon semmi gond nincs, tehát alkalmazás oldalon egy szerver failover fel sem tűnik) és baj esetén ne álljon le órákra. Az indexelés gyorsan megvan a felhasználók ezt képesek megoldani, a failover maga maximum 1 perc (de csak az IP MAC cím változása miatt ilyen sok) és automatikus. A problémát tehát a sok (kicsi) request jelenti.

"- lemondasz az adatkonzisztenciáról"

Ez egy járható út. :-D Délelőtt vizsgázik a jumbo frame. Elképzelhető egyébként, hogy ezt én januárban bekapcsoltam csak nem írtam be konfigba, mert 3 hónapot ment úgy, hogy sosem ment 7 fölé a Load és C protokollal. Csak most szombaton volt egy reboot és tegnap reggel jött a katasztrófa. Tehát holnap reggel lehet, hogy visszajön a múltheti állapotot. De én most naívan arra gondoltam, hogy a B protokoll is jó nekem, a másik vas alatt is van szünetmentes, ha a primary megpusztul igazából nem kritikus mert a másik node még él és kiírja a diszkre amit kell és majd ott feltámad a konténer. De simán lehet, hogy ebben nagyot tévedek.

"- lemondasz a teljesítményről"

Azt nem lehet. Ahogy eddig ment 3 hónapot úgy kb. 7-es Load körül azt még éppen elviselték néha szitkozódtak csak. Ez ennél lassabb nem lehet. Biztosan ne is gondolkozzak szoftver RAID0-ban? Crash esetére ahogy írtam, én a secondary node-ot gondoltam működő tartaléknak, feltéve, hogy nincs még valami amiről nem tudok és teljesen téves az elképzelésem. Az ext4 esetében én azt hittem a barrier=1 az már alapból így van, csak ext3-nál kell explicit megadni opcióként. ext4 esetén kell barrier=1, nem default? data=journal az volt, induláskor természetesen. Az első nap. Másnap már nem... journal_checksum,journal_async_commit ezek nincsenek. Utánajártam én is annó a konzisztencia témakörnek, csak a sebesség probléma miatt nem járható út.

Engem (hogy lépésről lépésre haladjak) az zavar, hogy ha áll a kettes node, akkor teljesen jó válaszidőket produkál és alacsony a Load. Ha igaz amit a DRBD dokumentációja ír, akkor a prokoll A esetén ugyanezt kéne hoznia. Ettől még persze nem akarok protokoll A-t használni, csak keresem a hibát, mert ehhez képest A esetén is elszáll a Load az egekbe. És ezt nem értem. Szerintem elsőként el kellene érnem, hogy összekapcsolódva akármilyen protokollal is, de hozza ugyanazt mint szétkapcsolódva. Ha a crosslink okozza a válaszidő növekedését, akkor elsőként azt kellene optikára cserélni mondjuk. Azt gondolom ugyanis ha ezt nem tudom elérni, akkor azt gondolom hiába osztom el az iops-t több diszkre, ha a DRBD összekapcsolt állapotban megfogja az egészet. Persze tévedhetek. Vagy az egészen biztos az, hogy összekapcsolt állapotban semmilyen linken és semmilyen protokollon nem lehet megoldani, hogy képes legyen a DRBD kezelni ezt az iops-t?

"- zsebbe nyúlás történik, vesztek valami normális, iops-ot tudó cuccot."

Külső storage abszolút nyerő lenne számomra, de a közeljövőben ez biztosan nem fog realizálódni. A HW RAID kártya viszont akkor fog következni, amikor majd elfogy minden más ötlet, bár ma még sajnos nem látom, hogy a HW RAID kártya a DRBD problémát hogyan fogja megoldani.

( informer v | 2012. 04. 04., sze – 01:15 )

nekem most ilyen beállításokkal megy:
(a rate-et veheted a te esetedben 220M-ra a 33M az szerintem egy nagyon erős fék! Dedikált loadbalance csatornán odaadhatod neki az egészet!)

common {
protocol C;
syncer { rate 500M; }
net {
allow-two-primaries;
.
.
.
max-buffers 8192;
max-epoch-size 16000;
unplug-watermark 4000;
sndbuf-size 2M;
}
.
.
.
>

a kedvedért invalidáltam egy kicsit és így sync-el:

7: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
ns:13324680 nr:0 dw:1379532 dr:12572563 al:254 bm:1252 lo:3 pe:61 ua:967 ap:0
[=>..................] sync'ed: 14.0% (8814/10239)M
finish: 0:00:55 speed: 162,112 (162,112) K/sec
resync: used:4/61 hits:92125 misses:92 starving:0 dirty:0 changed:92
act_log: used:0/127 hits:222598 misses:254 starving:0 dirty:0 changed:254

Köszi! Inkonzisztens állapot esetére van egy scriptem, amit elindítok abban van egy drbdsetup /dev/drbd0 syncer -r 200M parancs, hogy ne kelljen a részleteket fejben tartani. De végül is átírom a konfigban is, igaz, egyszerűbb.

"finish: 0:00:55 speed: 162,112 (162,112) K/sec"

Nálam ennek a felét hozta maximum, az első sync-nél 200M rate mellett. :)

( palotti | 2012. 04. 04., sze – 08:48 )

Szerintem meggondolandó lenne drbd helyett shared storage. Szegény ember vízzel főz, szóval ha redhat alapon gondolkozol akkor 4 disk, raid 10, ha 10-et nem tud a kártya akkor szoftveres csíkozás, gfs, nfs share, nagyobb fájlméret esetén ocfs is játszhat, de ocfst kis fájlok esetén nem javaslom. Ami viszont biztos: home pc alkatrészből épített szerver esetén ne várj egetverő teljesítményt (mint itt is bebizonyosodott). A döntéshozókkal kellene átbeszélni hogy miből mi építhető, vázold fel a lehetőségeket pro/kontra, válasszanak megoldást, megépíted, innentől az kérhető számon amiben megállapodtatok, ha pedig erősítés kell, akkor goto asztal, megbeszélés...
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

"A döntéshozókkal kellene átbeszélni hogy miből mi építhető, vázold fel a lehetőségeket pro/kontra, válasszanak megoldást, megépíted, innentől az kérhető számon amiben megállapodtatok, ha pedig erősítés kell, akkor goto asztal, megbeszélés"

Ma derült ki, hogy az IT kollégának írnia kell óránkénti bontásban, hogy mit csinál. Itt úgy gondolják, hogy a raklap rakodás/óra alkalmazható az IT-nél is. Én külsős vagyok, nekem csak annyi hír jött más irányból, hogy ne vigyek számlát, mert sokallni fogják. :)

Itt (is) a gazdasági vezető alá tartozik az IT. Ő ugye nem szakmabeli, ő számokat lát, az IT tehát csak egy nyűg ami miatt állandóan magyarázkodni kell felfelé, hogy miért olyan sok, ezért utálni kell. A kliensek nem hozzám tartoznak, de ez itt úgy megy, hogy venni valamit csak akkor ha valami elromlik. Plusz egyet tartaléknak vagy tesztelni arról szó sem lehet. Ha mégis kliens gépet kell venni (1db max. 3db), és van két ajánlat egy 52 ezer forintos és egy 56 ezer forintos/db, akkor hiába érvelsz, az 52 ezer forintos lesz. Kivéve mikor mégsem vesznek inkább semmit, hanem inkább átszervernek. Ennek megfelelően kliensek fagyogatnak is néha, olyankor zárolva marad inkonzisztens állapotban a DBF, a többiek sem tudnak dolgozni amíg a filelockot birtokló SMB processzt a rendszergazda le nem lövi (nincs idő timeoutokra, a telefon azonnal csörög) és nem indexelnek újra. Ennyit a failoverről is, amúgy. Egy hónapja van gond a számlázáson a nyomtatással, ott egy nagy teljesítményű mátrix nyomtató van, a számlákból véletlenszerűen kimarad egy-egy karakter, reprodukálhatatlan módon, mindig más, bár ez csak akkor okoz nekik gondot amikor pont az összegből tűnik el egy karakter, amúgy ignore, de így legalább nem napi sírás. Eredetileg kliens->CUPS(általam üzemeltetett fentebb említett szerveren)->print szerver->Printer volt, programozók szokás szerint mikor a saját problémájukba ütköznek jelezték: a szerver a szar. De a CUPS jobokból nem hiányoztak a karakterek. Ezután kliens->print szerver->Printer lett, a hiba maradt. Csodákra képes a legolcsóbb ZOTT printszerver. :))) Nem ragozom. Ez ilyen. Most jön majd az, hogy ha a kolléga nem tudja kitölteni a munkaidejét a gazdasági vezető számára is értelmezhető tevékenységgel, akkor a maradék időben havat fog lapátolni, stb. Ebben biztos vagyok, és ez még a jobbik eset lesz. :-/

( djsmiley v | 2012. 04. 05., cs – 22:25 )

Hi! Nem a témához tartozik, de a fejlesztő nem hallott még a Harbour Project-ről? Egész szépen lehet vele terminál módúvá varázsolni ilyen őskövület Clipper + DBF dolgokat. Az alá meg mehet a GFS is akár, bár meg tudja a kasztani a keresztbe-kasul fcntl() lockolás a DBF esetében :)

( Ago | 2012. 04. 05., cs – 23:09 )

EGyszerűen úgy, hogy nem hálózati probléma van, hanem a rendszerek - C protkoll esetén - az írásra várnak, és attól rohad le a rendszer. Ha nincs pénz SAS vinyókra, akkor javaslom az NL-SAS vinyókat. Nem sokkal drágábbak, mint egy _normális_ SATA vinyó, ellenben rögtön vagy 20%-kal jobb a teljesítményük. Igaz, csak 7200-on pörögnek, tehát elvileg nem szabadna jobbnak lenniük, de rögtön teljes SAS protokoll kezelés van, amivel pl jobban tudják optimalizálni a kihasználtságát a diszkeknek, szemben a SATA-val. A másik, hogy ehhez hozzácsapsz egy _rendes_ battery backup cache-sel rendelkező kártyát, egyből van egy jobb rendszered, ami sokkal gyorsabb. De ezt most ne úgy képzeld el, hogy mondjuk 7-es lesz a load, érzésem szerint csúcsidőben is sokkal kisebb lesz, mondjuk 3-as, mert nem fog a diszkekre várni. Minimum 256MB cache legyen a kártyán, és nézz utána ,hogy rendes raid kártya-e, nem valami szutyok. Ha a tulaj(ok) nem fogják fel, hogy a BMW-re nem telik, ha a core business nem megy - általáben ez áll a fillérbaszó viselkedés mögött - akkor meg egy idő után szerintem fontold meg a váltást valami normálisabb céghez.

( r3flow | 2012. 04. 06., p – 00:38 )

Hárman írtátok a BBWC-vel szerelt RAID vezérlőt, ezt a témakört körbejárom. A B protokoll (és az újjászületett jumbo frame, amit most időbe került volna újra feltalánom) a jelenlegi állapot, így nem megy 4 fölé a load, de nyilvánvaló, hogy ettől még továbbra is túlterhelt az I/O és világos, hogy a cél az adatvesztés elkerülése és a C protokoll. És persze nem lehet lassabb. :) Itt december végén váltottunk egy nagyon régi NetWare-ről a mostani megoldásra annak fényében, hogy 2 éve tervben van az alkalmazás cseréje egy korszerű PostgreSQL és kliens oldalon 32 bites változatra. Még az ígéretek ellenére nem valósult meg, jövőre már talán várható.

Az ottani főállású rendszergazda az alkalmazás támogatásával teljesen el van foglalva, én külsősként eseti támogatásként szerver oldalon segítek be, full time nem IT üzemeltetéssel foglalkozom hanem egyedi szoftver/hardver fejlesztéssel, máshol, plusz még egy külsős a klienseket üzemelteti. Ilyen szintű kakukktojásom már csak ez az egy van, korábban volt mellette még egy sok felhasználós szerver oldali üzemeltetés 8 évig (sendmail, squid, openvpn, konténerben, 2010 óta is ugyanez a HA megoldásom működött), de tavaly felmondtak minden korábbi külsős szerződést, átszervezés volt. Azóta vagy már le is lecserélték Windows Server + Exchange-re, vagy ha még nem, akkor ezután.

Tehát, köszönöm a hozzászólásokat!