Velký třesk ve vpsFree.cz (diskuse)

[junckritter]

Uz zase sa v Prahe robia velke zmeny a u nas nic :)) Inak drzim palce a budem sledovat, vyzera to na dost roboty.

[dementni.lojzik]

Zajímá vás, jak se to bude vyvíjet? Chcete sledovat průběh?

ano, nicmene bych uvital obsahlejsi komentar.. napr. proc jste zvolili OCFS2 (jsou nejake alternativy, jestli ano, proc tato volba?) a pod. Ne snad z duvodu, abych rejpal, ale abych se neco priucil. Pro me je toto zcela neznama zeme (terra incognita), takze uvitam jekekoli vysvetlujici komentare - klidne v poznamkach pod zapiskem, aby to nerusilo ostatni, problematiky znale.
PS. (pro vsechny, co mi chcou odpoved STFG): ja vim, vsehcno jde vygooglit, ale to bych asi nedelal nic jineho

[snajpa]

OCFS2 - jednak jede pod Debianem líp než GFS2 a jednak je podle benchmarků o něco lepší ve čtecích operacích (které u nás převažují).

Jinak pak existují ještě distribuované FS, jako Lustre (kernel záležitost, pro větší clustery) a třeba GlusterFS (co jsem ho zkoušel naposled, tak se na něj nedalo spolehnout) a mnohé další, jenže nic z toho nevyhovuje naším potřebám, takže v podstatě nebylo na výběr než OCFS2.

[trekker.dk]

Hm, nedávno jsem na drbd-users zachytil tohle zprávu s nadpisem "Server reboot on DRBD heavy load problem" Někdo měl problém s tím, že se mu server seká, když používá DRBD a OCFS2 ve velké zátěži. Poslal backtrace z dmesg

[55921.465065] Call Trace:
[55921.465065]  [<ffffffffa0449421>] ? ocfs2_compute_replay_slots+0x31/0x10f [ocfs2]
[55921.465065]  [<ffffffffa0449421>] ? ocfs2_compute_replay_slots+0x31/0x10f [ocfs2]
[55921.465065]  [<ffffffffa044ccec>] ? ocfs2_journal_load+0x1d0/0x2b1 [ocfs2]
[55921.465065]  [<ffffffffa0473525>] ? ocfs2_fill_super+0x19a2/0x2101 [ocfs2]
[55921.465065]  [<ffffffff8118aa8f>] ? snprintf+0x36/0x3b
[55921.465065]  [<ffffffff810e9f9e>] ? get_sb_bdev+0x137/0x19a
[55921.465065]  [<ffffffffa0471b83>] ? ocfs2_fill_super+0x0/0x2101 [ocfs2]
[55921.465065]  [<ffffffff810e9675>] ? vfs_kern_mount+0xa6/0x196
[55921.465065]  [<ffffffff810e97c4>] ? do_kern_mount+0x49/0xe7
[55921.465065]  [<ffffffff810fdabb>] ? do_mount+0x75c/0x7d6
[55921.465065]  [<ffffffff810d829a>] ? alloc_pages_current+0x9f/0xc2
[55921.465065]  [<ffffffff810fdbbd>] ? sys_mount+0x88/0xc3
[55921.465065]  [<ffffffff810089c2>] ? system_call_fastpath+0x16/0x1b
[55921.465065] Code: 0f 1f 44 00 00 49 89 c7 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 b0 ea 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 11 83 ca ff 44 89 f6 48 89 ef e8 a1 f1
[55921.465065] RIP  [<ffffffff810dffaa>] __kmalloc+0xd3/0x136
[55921.465065]  RSP <ffff880103e21ba8>
[55921.465065] ---[ end trace 3f96fca7c9cbfb04 ]---
[55941.839304] o2net: accepted connection from node mail02.fxclub.org (num 1) at 192.168.1.2:7777
[55946.003594] o2dlm: Node 1 joins domain E4B99C68B65449068DC403326917DC29
[55946.003673] o2dlm: Nodes in domain E4B99C68B65449068DC403326917DC29: 0 1

Reakce z konference...

Having built Oracle RAC clusters with OCFS and OCFS2, I would say that OCFS2 just isn't of stable quality, and is only suitable for light use. There have been open, outstanding bugs with no development for years. You should try GFS2 which is production ready.

[CEST]

Me by jeste zajimalo, jak budete resit instalaci OCFS2 - z balicku lenny nebo nejaky vlastni kompilace?

Stejne tak iSCSI. Kdyz jsem ho naposledy zkousel, melo to dost problemy, takze jsme zustali u image pres NFS (pro XEN) a NFS pro VMware.

Napises, jak jste instalovali a jakou mate stabilitu? Pokud ten OCFS2 s DRBD nebude moc stabilni, jak pise trekker, tak je to dost na nic.

Me ted zrovna dost zlobi XEN na Lennym. Dva servery se dost casto jen tak restartujou. Driv to pres DRBD 8.0.X shazovalo i dalsi servery, to jsem snad vyresil novejsim DRBD 8.3.7 z backports. Pak jsem zkousel na XENu napinovat VCPU napevno na phys CPU (nasel jsem nejaky zpravy, ze kdyz to prideluje XEN dynamicky, tak to obcas chcipne), ale ani tak to nepomohlo. Ted zkousim XEN4. Jinak servery s DRDB, ale bez XENu, behaji dobre a jeden XEN server bez DRBD mel hodne velkej uptime (tusim pres 2 roky), ale ted nam presouvali server, takze uptime je opet na nule.

[trekker.dk]

Ted zkousim XEN4.

To jsem nedávno dělal taky. Oproti 3.x Xen 4 výkonnostně propadl.

[Michal Fecko]

Cislo styri asi vazne nebude 2x stastne...

[dik]

mimochodem jak řešíte fencing? dik

[snajpa]

To ještě není jisté, buďto použijeme heartbeat (resp. Linux-HA), nebo si napíšeme vlastní kus softwaru. Jde o to, jak se co bude dát ohnout pro naše potřeby.

[Vskutečnosti Saýc]

To je ta prace kvuli ktery je dobry bejt admin :) Zajimavy, neco takovyho jsem delal pro <nejmenovanej server s mrtvolama a pornem>, jenom s jinym storage, rad si poctu o vasem.

Ten storage server krici ZFS! Ale pokud to nechcete sdilet pomoci NFS, tak se neda nic delat, hosi z Lustre se na tu solarisovou verzi vykaslali kdyz byli jeste pod Sunem, takze ted uz nikdy nebude. No, jeste se da pouzit solaris jako storage a ESXi jako hypervizor (jestli ho neprestali nabizet), ale to je na dlouhy lokte.

Kazdopadne zajimavy tema. Treba by vam aji redakce abcl vydala "pripadovou studii" jako clanek, pokud doplnite nejaky manazersky kecy o usporenych procentech.

[kyytaM]

Raid6, na tom drbd a este aj OCFS2. :) Write operacie asi nebudu zrovna 2x rychle. :D

Kazdopadne drzim palce, hlavne ked zacnu vyskakovat vseliaki kostlivci v podobe roznych bugov. Hlavne potesi ked sa dofacji OCFS2. :)

O cLVM ste neuvazovali?

[dik]

...ještě by panové mohli do svého řešení zapracovat deduplikaci ,ale pak by to bylo ultra pomalé :) V současné době se pokouším stavět pokusné HA iscsi storage , a sám jsem zvědav jak se to bude/nebude chovat. Kuchařka: glustefs 3.x , iscsi target stgt do souborů + opendedup nebo lessfs no a multipath přístup :)

Mimochodem jaké máte zkušenosti s přístupem přes nfs3/4 na xen image. Je to stabilní?

dik

[Martin Seman]

ked chcete failover a shared filesystem, idealne by bolo redhat cluster + gfs

[Limoto]

Dík za dokumentaci

[VSi]

Rozhodně vám patří dík, že se dělíte o zkušenosti z takové akce, a že testuje v reálném provozu ne zcela běžné technologie, které (zatím ) bohužel nefugují vždy na 100 %.

Sám bych se v této konfiguraci rozhodně bál OCFS2, zvlášť v kombinaci s DRBD a ještě iSCSI. Navíc stav těchto "enterprise" věcí v Debianu lenny je z mé zkušenosti občas dost žalostný. Existuje prostě moc kombinací nastavení, hardwaru, a samotných technologií, a málo uživatelů, aby se na to dalo bez důkladného testování spolehnout. Na tohle je možná lepší CentOS / RHEL / SLES. Já takhle musel na Debianu použít Xen z testingu (kde zas bohužel už není aktuálně stabilní řada 3.4), vlastní Xen Dom0 jádro a vlastní balíček DRBD 8.3.7 (z debianní verze nešel ani zkompilovat modul).

Co by mě zajímalo (možná námět o čem se více v budoucnu rozepsat):

• Proč relativně riskantní volba clusterového FS? Technologie je to asi ideální, ale sám bych tomu v kobinaci s DRBD produkční systém nesvěřil. Proč neudělat LVM + iSCSI nebo AOE export pro každy virtualizační node nebo pro každý VM (neflexibilní, plýtvání místem)? Proč nepoužít raději NFS (asi nespolupracuje s OpenVZ)?
• Jak je řešená redundance připojení do sítě datacentra? Máte 2 linky na stejný L2 segment? Nebo je to nějak routované? OSPF budete používat mezi vlastními routery a stroji? Není jednodušší redundanci řešit na L2 pomocí spanning tree?
• V čem zklamal Mikrotik RouterOS? Dost lidí si stěžuje právě na OSPF, pokud to není mikrotik-only síť.
• Storage servery máte 2? Pro DRBD není ideální použít jako "záložní" nějaký pomalejší systém, HW RAID na obou strojích je pro rozumný výkon nutnost (kvůli zápisu synchronizační bitmapy).

[trekker.dk]

vlastní balíček DRBD 8.3.7 (z debianní verze nešel ani zkompilovat modul).

Oprava se nechá najít na netu, je to něco 2 odstraněné, 6 přidaných řádků. Nicméně mám ten pocit, že to ani není potřeba, DRBD ovladač se backportuje i do jádra 2.6.32 ve stable.