Hello, cluster-el kapcsolatban lenne nehany kerdesem: - van valamilyen lehetoseg a session-ok atvitelere HA modban? - van valamilyen mod a node-ok kozott a konfigok terjesztesere, illetve ennek valamilyen szabalyozasa? Arra gondolok, hogy a konfig modositas replikalodjon at az inaktiv node-okra is, de adott esetben: - legyen kesleltetes - legyen archivalas tehat valamilyen "katasztrofa" eseten vissza lehessen allni egy korabbi allapotra mondjuk az idokozben aktiv node-da valt eszkozon. Koszonom: a.
On Wed, 2009-02-11 at 11:12 +0100, Hegedüs Ervin wrote:
Hello,
cluster-el kapcsolatban lenne nehany kerdesem:
- van valamilyen lehetoseg a session-ok atvitelere HA modban?
nincs. proxy alapu tuzfalaknal ez maximum adminisztrativ failover eseten lehetseges (tehat, amikor mindket gep meg el, es explicit kered, hogy alljon at egyik a masikra). csomagszurt forgalom eseten technikailag megoldhato, de meg a kereskedelmi Zorp sem tartalmaz ilyen megoldast. A GPL kapcsan meg tudod nezni a conntrackd-t, az tunik mostanaban leginkabb fejlesztett dolognak.
- van valamilyen mod a node-ok kozott a konfigok terjesztesere, illetve ennek valamilyen szabalyozasa? Arra gondolok, hogy a konfig modositas replikalodjon at az inaktiv node-okra is, de adott esetben: - legyen kesleltetes - legyen archivalas tehat valamilyen "katasztrofa" eseten vissza lehessen allni egy korabbi allapotra mondjuk az idokozben aktiv node-da valt eszkozon.
ilyen van a ZMS-ben. a konfig feltolteskor megadhatod, hogy a cluster melyik node-jaira keruljon fel a konfig, es a ZMS azt is megjegyzi, hogy melyik node-okra teritett mar eddig. -- Bazsi
Hello,
- van valamilyen lehetoseg a session-ok atvitelere HA modban?
nincs. proxy alapu tuzfalaknal ez maximum adminisztrativ failover eseten lehetseges (tehat, amikor mindket gep meg el, es explicit kered, hogy alljon at egyik a masikra).
koszonom,
csomagszurt forgalom eseten technikailag megoldhato, de meg a kereskedelmi Zorp sem tartalmaz ilyen megoldast.
A GPL kapcsan meg tudod nezni a conntrackd-t, az tunik mostanaban leginkabb fejlesztett dolognak. igen, errol mar olvastam, azert koszonom.
- van valamilyen mod a node-ok kozott a konfigok terjesztesere, illetve ennek valamilyen szabalyozasa? Arra gondolok, hogy a konfig modositas replikalodjon at az inaktiv node-okra is, de adott esetben: - legyen kesleltetes - legyen archivalas tehat valamilyen "katasztrofa" eseten vissza lehessen allni egy korabbi allapotra mondjuk az idokozben aktiv node-da valt eszkozon.
ilyen van a ZMS-ben. a konfig feltolteskor megadhatod, hogy a cluster melyik node-jaira keruljon fel a konfig, es a ZMS azt is megjegyzi, hogy melyik node-okra teritett mar eddig.
es a "katasztrofa-tures", tehat a replikacio kesleltetes, illetve valami fele konfig-rollback? A ZMS-t nem ismerem, ezek valamilyen modon ervenyesitheto funkciok benne? Koszonom: a.
Balazs Scheidler wrote:
On Wed, 2009-02-11 at 11:12 +0100, Hegedüs Ervin wrote:
Hello,
cluster-el kapcsolatban lenne nehany kerdesem:
- van valamilyen lehetoseg a session-ok atvitelere HA modban?
nincs. proxy alapu tuzfalaknal ez maximum adminisztrativ failover eseten lehetseges (tehat, amikor mindket gep meg el, es explicit kered, hogy alljon at egyik a masikra).
Ennek van valami elvi oka is, vagy csak a linux nem tamogatja? -- Gabor HALASZ <halasz.g@freemail.hu>
On Wed, 2009-02-11 at 15:50 +0100, Gabor HALASZ wrote:
Balazs Scheidler wrote:
On Wed, 2009-02-11 at 11:12 +0100, Hegedüs Ervin wrote:
Hello,
cluster-el kapcsolatban lenne nehany kerdesem:
- van valamilyen lehetoseg a session-ok atvitelere HA modban?
nincs. proxy alapu tuzfalaknal ez maximum adminisztrativ failover eseten lehetseges (tehat, amikor mindket gep meg el, es explicit kered, hogy alljon at egyik a masikra).
Ennek van valami elvi oka is, vagy csak a linux nem tamogatja?
TCP allapotot atvinni csak ugy lehet, ha "befagyasztod" az adott kapcsolaton valo kommunikaciot, azaz az eppen "uzemelo" node-nak el kell ernie, hogy a masik oldal _ne_ kuldjon tobb adatot (pl. levagja a window-t 0-ra) Minden egyeb esetben az allapot migralassal az a baj, hogy johet egy ujabb csomag, ami modositja az allapotot. Alternativ megoldas az, hogy az egyes csomagok feldolgozasat keslelteted, ameddig az allapot szinkronizacio meg nem tortent. Ez viszont komoly teljesitmenyvesztest jelent (pl. mert addig nem kapja meg a stack az altala eppen vart ACK csomagot, amig az ezt okozo csomagot at nem kuldte a slave-nek, es az nem igazolta vissza). Szoval a lenyeg, hogy az egyetlen mukodokepes, es nagy teljesitmenyu megoldas aktiv kozremukodest igenyel az eppen aktiv node-tol, amit az nem tud megtenni ha eppen egy panic miatt villogtatja a billentyuzed ledjeit. :) -- Bazsi
Balazs Scheidler wrote:
TCP allapotot atvinni csak ugy lehet, ha "befagyasztod" az adott kapcsolaton valo kommunikaciot, azaz az eppen "uzemelo" node-nak el kell ernie, hogy a masik oldal _ne_ kuldjon tobb adatot (pl. levagja a window-t 0-ra)
Minden egyeb esetben az allapot migralassal az a baj, hogy johet egy ujabb csomag, ami modositja az allapotot.
Akkor elvi problema nincsen, pl a Tandem fele NonStop OS meg letezo termek a HPnal. -- Gabor HALASZ <halasz.g@freemail.hu>
participants (3)
-
Balazs Scheidler
-
Gabor HALASZ
-
Hegedüs Ervin