Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Linux HA

8 views
Skip to first unread message

Kollár Csaba

unread,
May 13, 2013, 2:43:11 PM5/13/13
to

Kicsit elkényelmesedtem az utóbbi időben a vSphere FT, HA, és társai
miatt, viszont most kéne csinálnom két fizikai szerver között egy
egyszerű failover megoldást.

A konkrét feladat: ha lerohad az 1-es gép, a 2-es vegye fel az IP címét.
Továbbá ha az 1-es időközben mégis élő állapotba kerül valami miatt,
akkor ne legyen ebből galiba. Adatokat nem kell szinkronizálni köztük,
kisebb fajta appliance (szerű) rendszerek, fix configokkal, egy külső
adatbázisban tárolnak mindent.

Régebben használtam DRBD-t, Heartbeatet, az előbbi jelen esetben nem
szükséges, az utóbbihoz viszont 2011 óta nem nyúltak (persze ettől még
lehet jó). Mi manapság erre a best practice, azon kívül hogy nekiállok
scriptelni, vagy használom a rég Heartbeatet?


--
Chal
--
linux-flame lista - linux...@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux-flame

Szládovics Péter

unread,
May 13, 2013, 3:17:08 PM5/13/13
to

2013-05-13 20:43 keltezéssel, Kollár Csaba írta:
> Kicsit elkényelmesedtem az utóbbi időben a vSphere FT, HA, és társai
> miatt, viszont most kéne csinálnom két fizikai szerver között egy
> egyszerű failover megoldást.
>
> A konkrét feladat: ha lerohad az 1-es gép, a 2-es vegye fel az IP
> címét. Továbbá ha az 1-es időközben mégis élő állapotba kerül valami
> miatt, akkor ne legyen ebből galiba. Adatokat nem kell szinkronizálni
> köztük, kisebb fajta appliance (szerű) rendszerek, fix configokkal,
> egy külső adatbázisban tárolnak mindent.
>
> Régebben használtam DRBD-t, Heartbeatet, az előbbi jelen esetben nem
> szükséges, az utóbbihoz viszont 2011 óta nem nyúltak (persze ettől még
> lehet jó). Mi manapság erre a best practice, azon kívül hogy nekiállok
> scriptelni, vagy használom a rég Heartbeatet?

Több oka szokott lenni annak, ha valamihez nem nyúlnak. Ezek közül az
egyik az, ha nincs, aki hozzányúl, de az is ok, hogy nincs rá szükség ;)
Nem tudom, a Heartbeat esetén mi a pálya, de nekem szokott működni jól :)

Mellesleg, ha már vmware... Azt szoktad-e nézni, hogy mi a default lan
interface amikor VM-et csinálsz? e1000 (nem a vmxnet)... Az konkrétan
2002-es.

Kollár Csaba

unread,
May 13, 2013, 3:25:35 PM5/13/13
to

On 2013.05.13. 21:17, Szládovics Péter wrote:
> Több oka szokott lenni annak, ha valamihez nem nyúlnak. Ezek közül az
> egyik az, ha nincs, aki hozzányúl, de az is ok, hogy nincs rá szükség ;)
> Nem tudom, a Heartbeat esetén mi a pálya, de nekem szokott működni jól :)

Köszi, maradok ennél. Egyébként opensource projecteknél nem annyira
rossz beidegződés ez talán :) Persze nem élből utasítom el, de azért van
egy egészséges gyanakvás mindig ilyen eseteben.

> Mellesleg, ha már vmware... Azt szoktad-e nézni, hogy mi a default lan
> interface amikor VM-et csinálsz? e1000 (nem a vmxnet)... Az konkrétan
> 2002-es.

Mármint mi 2002-es?


--
Chal

Mezei Zoltan

unread,
May 13, 2013, 3:43:50 PM5/13/13
to

2013/5/13 Kollár Csaba <csaba....@enternet.hu>
> Régebben használtam DRBD-t, Heartbeatet, az előbbi jelen esetben nem szükséges, az utóbbihoz viszont 2011 óta nem nyúltak (persze ettől még lehet jó). Mi manapság erre a best practice, azon kívül hogy nekiállok scriptelni, vagy használom a rég Heartbeatet?

Csinálhatod Heartbeat helyett RHCS-sel is. Ez szerintem a Te esetedben
semmi előnnyel nem jár, de megteheted! :-)
--
Zizi

"...nálatok a cégnél múltból nagyon sok van..."

Szládovics Péter

unread,
May 13, 2013, 3:49:24 PM5/13/13
to

2013-05-13 21:25 keltezéssel, Kollár Csaba írta:
> On 2013.05.13. 21:17, Szládovics Péter wrote:
>> Több oka szokott lenni annak, ha valamihez nem nyúlnak. Ezek közül az
>> egyik az, ha nincs, aki hozzányúl, de az is ok, hogy nincs rá szükség ;)
>> Nem tudom, a Heartbeat esetén mi a pálya, de nekem szokott működni
>> jól :)
>
> Köszi, maradok ennél. Egyébként opensource projecteknél nem annyira
> rossz beidegződés ez talán :) Persze nem élből utasítom el, de azért
> van egy egészséges gyanakvás mindig ilyen eseteben.
>
>> Mellesleg, ha már vmware... Azt szoktad-e nézni, hogy mi a default lan
>> interface amikor VM-et csinálsz? e1000 (nem a vmxnet)... Az konkrétan
>> 2002-es.
>
> Mármint mi 2002-es?

Az e1000 drivere.

Mezei Zoltan

unread,
May 13, 2013, 3:46:20 PM5/13/13
to

2013/5/13 Szládovics Péter <pe...@szladovics.hu>:
> Mellesleg, ha már vmware... Azt szoktad-e nézni, hogy mi a default lan
> interface amikor VM-et csinálsz? e1000 (nem a vmxnet)... Az konkrétan
> 2002-es.

Mert e1000-hez minden régi OS-ben van driver/modul, vmxnet-hez meg
nincs. Egyébként meg van pár olyan workload, ami vmxnet-tel jobban
megy, és még nem találtam olyat, ami e1000-rel jobban menne, szóval
szerintem nem a jólműködőség, hanem a támogatás volt az irányadó...
--
Zizi

"...nálatok a cégnél múltból nagyon sok van..."

Szládovics Péter

unread,
May 13, 2013, 3:53:31 PM5/13/13
to

2013-05-13 21:46 keltezéssel, Mezei Zoltan írta:
> 2013/5/13 Szládovics Péter <pe...@szladovics.hu>:
>> Mellesleg, ha már vmware... Azt szoktad-e nézni, hogy mi a default lan
>> interface amikor VM-et csinálsz? e1000 (nem a vmxnet)... Az konkrétan
>> 2002-es.
> Mert e1000-hez minden régi OS-ben van driver/modul, vmxnet-hez meg
> nincs. Egyébként meg van pár olyan workload, ami vmxnet-tel jobban
> megy, és még nem találtam olyat, ami e1000-rel jobban menne, szóval
> szerintem nem a jólműködőség, hanem a támogatás volt az irányadó...

Konkrétan: e1000 drivere 2002-es, nem nyúltak hozzá, mert _jó_.
A vmxnet meg enyhén szar.
Egy példa, amin konkrétan szoptunk durvát:

Virtuális connection broker VDI-hoz -> SCB -> VDI sessionök.
Amíg a CB interface-ei vmxnet-ek voltak, csinált olyat, hogy tömegesen
dobta el a VDI sessionöket a CB. Amióta e1000-re került a forgalom,
valahogy megszűnt ez a hiba.
Úgyhogy a jobban megy vs. megbízhatóbb versenyben az e1000-es nyert.

Tamas Papp

unread,
May 14, 2013, 2:50:20 AM5/14/13
to

On 05/13/2013 08:43 PM, Kollár Csaba wrote:
>
> Kicsit elkényelmesedtem az utóbbi időben a vSphere FT, HA, és társai miatt, viszont most kéne
> csinálnom két fizikai szerver között egy egyszerű failover megoldást.
>
> A konkrét feladat: ha lerohad az 1-es gép, a 2-es vegye fel az IP címét. Továbbá ha az 1-es
> időközben mégis élő állapotba kerül valami miatt, akkor ne legyen ebből galiba. Adatokat nem kell
> szinkronizálni köztük, kisebb fajta appliance (szerű) rendszerek, fix configokkal, egy külső
> adatbázisban tárolnak mindent.
>
> Régebben használtam DRBD-t, Heartbeatet, az előbbi jelen esetben nem szükséges, az utóbbihoz viszont
> 2011 óta nem nyúltak (persze ettől még lehet jó). Mi manapság erre a best practice, azon kívül hogy
> nekiállok scriptelni, vagy használom a rég Heartbeatet?
>

Vagy heartbeat v1-et hasznalj, vagy corosync, pacemaker.
Alternativ megoldasok vannak meg, mint pl. a carp.

udv,
t

Kiss Gabor

unread,
May 14, 2013, 4:46:47 AM5/14/13
to


On 05/14/2013 08:50 AM, Tamas Papp wrote:
> Vagy heartbeat v1-et hasznalj, vagy corosync, pacemaker.

Az öreg heartbeat nálam jól megy.

A corosync szétesett folyton. Kézzel kellett korrigálni hetente hatszor.
Végül teljesen megdöglött.
(Teljesen süket vagyok a témához, nem tudom melyik komponens
miért felelős. Az is lehet, hogy pacemakert kellett volna mondanom. :)

g

Tamas Papp

unread,
May 14, 2013, 5:08:05 AM5/14/13
to

On 05/14/2013 10:46 AM, Kiss Gabor wrote:
>
>
> On 05/14/2013 08:50 AM, Tamas Papp wrote:
>> Vagy heartbeat v1-et hasznalj, vagy corosync, pacemaker.
>
> Az öreg heartbeat nálam jól megy.
>
> A corosync szétesett folyton. Kézzel kellett korrigálni hetente hatszor.
> Végül teljesen megdöglött.

Olvastam/hallgattam par sztorit, ahol kritikus kornyezetben megy, szoval feltetelezem, meg lehet
csinalni tisztessegesen.
De sajnos en sem igazan ertek hozza.
Ill. lehetoseg szerint en elevel nem szoktam az automatikusa failovert valasztani, hacsak nem muszaj.

> (Teljesen süket vagyok a témához, nem tudom melyik komponens
> miért felelős. Az is lehet, hogy pacemakert kellett volna mondanom. :)

Szinten zenesz. Folyton keverem oket.


t
0 new messages