Szegeny ember vizzel foz. Kepbejon a drbd.
A net teli van leirasokkal hogy kell egy nfs servert drbd-vel osszehazasitani. Ez nekunk jo is, csak nfs helyett egy mfs masterunk van.
Hat elso korben kellett egy drbd, ez sima ugy. Ket dolog fontos benne:
handlers {
...
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
disk {
fencing resource-only;
}
Osszesynceltek, majd kerult ra egy ext4 fs.
A moosefs master masik problemaja, hogy a chunkszervereket nemlehet csoportokba szervezni (pl hw felepites szerint), hogy adott fajlokat adott csoport taroljon. pl /x tartalma az A-B-C gepeken van, mig a /y tartalma a D-E-F gepeken. Ez megoldhato ha tobb fuggetlen master fut, es ehhez kapcsolonak a fuggetlen chunkszerverek.
A debian csomagolt moosefs ezt nem tamogatja, de szerencsere a master processt el lehet inditani fuggetlen beallitasokkal, amik nem zavarjak egymast.
A beallitasok a /etc/mfs/foo konyvtarba kerul, a data fajlokat az /srv/mfs/foo konyvtarba teheti, es kapott egy sajat init.d-t is mfs-master-foo neven. (a fenti drbd a /srv/mfs-re lett csatolva)
Az /etc/rc*-kbe nemkell linkelni, hiszen ezek nem indulaskor fognak elindulni, hanem a pacemaker inditja oket.
A corosync + pacemaker telepites utan itt a teljes crm config:
node mfs-master1
node mfs-master2
primitive drbd_moosefs ocf:linbit:drbd \
op monitor interval="10s" \
params drbd_resource="mfs"
primitive fs_moosefs ocf:heartbeat:Filesystem \
op start interval="0" timeout="60" \
op monitor interval="10" \
op stop interval="0" timeout="120" \
params device="/dev/drbd/by-res/mfs" directory="/srv/mfs" fstype="ext4" options="noatime,nodiratime" \
meta target-role="Started"
primitive lsb_moosefs_foo lsb:mfs-master-foo \
op monitor interval="5s"
primitive lsb_moosefs_bar lsb:mfs-master-bar \
op monitor interval="5s"
primitive vip_moosefs ocf:heartbeat:IPaddr \
op monitor interval="5s" \
params ip="1.2.3.4" cidr_netmask="26"
group lsb_group lsb_moosefs_foo lsb_moosefs_bar
ms ms_drbd_moosefs drbd_moosefs \
meta master-max="1" clone-max="2" master-node-max="1" clone-node-max="1" notify="true"
colocation fs-moosefs-with-ip inf: fs_moosefs vip_moosefs
colocation fs-moosefs-with-lsb inf: fs_moosefs lsb_group
colocation ms-drbd-moosefs-with-fs-moosefs inf: fs_moosefs ms_drbd_moosefs:Master
order fs-moosefs-before-lsb inf: fs_moosefs:start lsb_group:start
order ip-before-lsb inf: vip_moosefs:start lsb_group:start
order ms-drbd-moosefs-before-fs-moosefs inf: ms_drbd_moosefs:promote fs_moosefs:start
property stonith-enabled="false" \
no-quorum-policy="ignore" \
stop-all-resources="false"
Miutan minden jol megy, akkor elindulnak valamielyik node-on a master-ek, a virtualis ipn el lehet oket erni (itt most 1.2.3.4)
Online: [ mfs-master1 mfs-master2 ]
fs_moosefs (ocf::heartbeat:Filesystem): Started mfs-master1
vip_moosefs (ocf::heartbeat:IPaddr): Started mfs-master1
Master/Slave Set: ms_drbd_moosefs
Masters: [ mfs-master1 ]
Slaves: [ mfs-master2 ]
Resource Group: lsb_group
lsb_moosefs_foo (lsb:mfs-master-foo): Started mfs-master1
lsb_moosefs_bar (lsb:mfs-master-bar): Started mfs-master1
TODO:
tovabbi corosync node-ok beallitasa, hogy meglegyen a szavazasos moka, de ilyenkor be kell allitani hogy a drbd csak adott ket node-on futhasson:
location ms-drbd-placement ms_drbd_moosefs rule -inf: \#uname ne mfs-master1 and \#uname ne mfs-master2
- Elbandi blogja
- A hozzászóláshoz be kell jelentkezni
- 1378 megtekintés
Hozzászólások
na, miert nem jott be a ceph? nalam vigan duruzsol. egyetlen egy dolgot nem tudtam megoldani, hogyha iSCSI-n kirakom VMWare ala, akkor _nagyonnagyon_ lassu, es nem tudom mit kene tuningolni rajta, hogy ne 20kb/s legyen.
- A hozzászóláshoz be kell jelentkezni
Pedig ez mondjuk eléggé fontos lenne, mondhatni ésszerű felhasználás.
De ha már ennyit sztárolod itt a ceph-et, lassan nekem is meg kellene néznem, mit tud...
- A hozzászóláshoz be kell jelentkezni
igy van, esszeru felallas, es megy is tokeletesen minden mas rendszer alol, kiveve a vspheret...
- A hozzászóláshoz be kell jelentkezni
te block devicekent hasznalod. nekunk viszont a cephfs kene (tobb helyrol kell elerni a fajlokat).
osd-k neha random elszalltak ( assert() -> dump -> exit )
osd node-ok hw-je lighty-val ki tud szolgalni ~2Gbit forgalmat alacsony cpuval. cephfs 5 db ilyen node-dal, szumma max ~6G es cpu az egekben... :(
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
ne azt ird akkor, hogy "amig a cephbol nem faragnak stabil valamit", hanem hogy a cephfs-bol :-)
btw, vmware-es iSCSI dologra vki otlet?
- A hozzászóláshoz be kell jelentkezni
Feltételezem nézted már tcpdump-pal, hogy van-e valami hálózati oka, mondjuk frame size, vagy ilyesmik.
Mondjuk a helyedben összehasonlítanám egy működő initiator és egy vmware forgalmát eltérés után kutatva.
Szerk: amúgy milyen rétegeid vannak, min keresztül ajánlod ki a az rbd-t iSCSI-n?
- A hozzászóláshoz be kell jelentkezni
neztem tcpdumppal, es mindenutt jumbo frameket hasznalok, hasznalja is a rendszer oket, csak egyszeruen nem erolteti meg magat. :)
tgt-ben van nativ rbd tamogatas, azzal is probaltam, meg ugy is, hogy rbd blokk eszkozt ajanlottam ki targetcli-vel, ugyanaz az eredmeny.
- A hozzászóláshoz be kell jelentkezni
Te milyen hw tamasztekkal hasznalod (switch/kartya/etc.-re gondolva)? Ismerosoknel okoz nemi problemat a magas disk latency ami jopofa iowait-ben jon elo.
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
10G-s ethernet van, Chelsio T420-CR kartyakkal. a journal SSD-re megy (intel 520, samsung 840pro), es mondom, erdekes, hogy mas initiatorral nezve jo a teljesitmeny, csak a vmwaret nem szereti. majd kinyitom a low level tuning guideot es megnezem miket lehet ott allitani, de ha jol emlekszem, alapbol 128k-s blokkal mukodik a software initiator vmware alatt, ami azert jo par MB/s-re eleg kene, hogy legyen, nem 20KB/s :)
- A hozzászóláshoz be kell jelentkezni
Ahh, ertem, koszi. Ha jol latom ezek sfp+ -os kartyak, gondolom direct attach. Head-ek, storage-ok direktben vagy switchel vannak osszehuzva?
Ismeros kert segitseget, en szinten sfp+, illetve da copper -t ajanlottam neki (a mostani rendszeruk ha jol vettem ki natur ethernet).
Ok kvm-et hasznalnak (proxmox), vmware -rol nem tudok nyilatkozni:)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
SFP+ igen, de nincs semmi direct attach, egy cisco switchen lognak; a switch loadja nem magas, iperf-el ki tudtam huzni a 10 gigat minden iranyban.
- A hozzászóláshoz be kell jelentkezni
teszt keppen kiprobaltam az rbd+ext4 parost is, sajna az is keves volt. de iszonyat gyorsan fejlesztik, tehat majd ~3-4 honap mulva ujbol megnezzuk.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
mit jelent a keves, szamokban? es mi az, amit elvartal volna?
- A hozzászóláshoz be kell jelentkezni
mint irtam, a hw-bol kijott ~2Gbit (web, 500 cliens, full random access 50-500M-as fajlokkal) alig eszreveheto cpu hasznalat mellett.
igy az 5 node-bol ki kellett volna jonnie a 10G-nek. helyette kb osszvissz 6G jott, a osd node-okon 40% cpu (user+system asszem), a client nodeon meg 100% cpu (nagyreszt iowait)
pedig volt jatek readahead-dal, tobbszoros mount fuggetlen tcp kapcsolattal, meg egy tesztprogit is irtam libcephfs-sel directben olvasta a fajlokat.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni