Adott egy ceg, ahol leveleket archivalnak piler-rel, es nagyon bejott nekik. Viszont, hogy legyen redundancia is a dologban, ezert egy masik adatkozpontba is tennenek egy email archivumot (=egy 2. piler installacio). A VM-ek vmware 5.x-en futnak, a 2 adatkozopont kozott elegseges savszelesseg van. A kerdes tehat az, hogy lehetne ezt a legcelszerubben (=az egyszerubb jobb, a robusztusabb jobb, az olcsobb jobb) megvalositani?
Par otlet bemelegiteskeppen, mindegyiknek van pro es con oldala is:
#1: 2 egymastol teljesen fuggetlen piler telepites. Az exchange-ben az smtp journaling-nal 2 email cimet adunk meg, es "real time" mennek a levelek mindket archivumba. Ha az egyik elerhetetlen, addig az exchange tarolja a leveleket, ha visszajon, akkor tovabbitja fele.
PROS:
- nem kell a 2 archivum kozott szinkronizalni
- egyszeru konfig
CONS:
- az archivalas nelkuli felallashoz kepest 3x-osara emelkedik az exchange-en atmeno levelforgalom
- ha megall az egyik archivum, akkor eleg massziv queue alakulhat ki az exchange-en
#2: naponta 1x kiexportaljuk a leveleket az aktivnak kijelolt archivumbol, majd rsync, whatever, es importalas a masikba
PROS:
- (az elozohoz kepest) kisebb exchange terheles
CONS:
- az (aktiv) archivum leallasa eseten nem trivialis szinkronba hozni a 2 archivumot
- max. 24 ora elveszhet az archivumbol
#3: a #2 valtozata ugy, hogy a VM-ben levo file-okat (pl. rsync) ill. mysql adatbazist (pl. replikacio) masolod a masik adatkozpontba.
PROS:
- ???
CONS:
- nem real time, lehet adatvesztes
- ha meghal az (aktiv) archivum, nem trivialis a szinkronba hozas
#4: oldja meg a vmware (vagy egy raepulo termek, pl. veeam) a 2 VM szinkronban tartasat tokkal vonoval
PROS:
- remelhetoleg mindent korrekt modon atvisz
CONS:
- koltseg
- nem feltetlenul realtime
Kb. ennyi otlet elso nekifutasra. Te hogyan oldanad meg?
Hozzászólások
CONS:
> - az archivalas nelkuli felallashoz kepest 3x-osara emelkedik az exchange-en atmeno levelforgalom
Szamit? Valos terhelest okoz vagy csak a 10 egyszegbol helyett 30 egyseg lesz amellett, hogy 3000-et is siman vinne?
Amugy miert 3x-os?
> - ha megall az egyik archivum, akkor eleg massziv queue alakulhat ki az exchange-en
Mindket probleman segit, ha az xch es a piler koze beraksz egy smarthostot, de meg az xch-hoz kozel, mondjuk az esx-en.
Meg1 megoldas:
Block vagy fs szinten szinkronizalod akar real time, akar szakaszosan.
Pl. realtime: drbd, glusterfs, fhgfs, lsyncd (ide nem biztos, h jo).
Async modon, szakaszosan: glusterfs geo-replication, snapshot + rsync, snapshot + btrfs send/recv, snapshot + zfs send/recv.
En amugy az egyes fuggony mogotti josagot valasztanam, ugyanis azzal segitenek azon is, hogy ha az egyik site korrupt lesz.
tompos
hat szvsz erosen #1, a tobbi csak haxolas, ami vagy megy jol vagy nem. ha megall egyik archivalo, akkor azt csak el tudjak inditani rovid idon belul mashol (mivel virtualizalva van). ha meg ez ido alatt annyi level torlodik fel, akkor mar eleve nagy a forgalom amit az exchangenek birnia kene...
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Erosen az #5-re szavaznek:
Elvileg a piler DB-ban tarol mindent, nem? Valamint, ha jol emlekszem, tud Postgrest.
Szoval fogsz egy olyan telepitest, ahol PG van, leklonozod, beallitod az egyik DB-t masterre, a masikat meg slave-re. A slave-en levo piler maradhat inaktiv amig a master el.
Ha elszall, akkor a slave atveszi a szerepet, a DNS-t beallitod a slave cimere, teljesen transzparens lehet - az atallast nem szamitva - a kliensek iranyaba.
Pros:
-amig mindketto el, a ket DB osszedolgozik (gyorsabb tobb lekeresnel)
-teljesen eszrevetlen az atallas, ha jol csinalod
-real-time
-ha a slave elszall/leall vagy megszakad a kapcsolat, a hiba elharitasa utan magatol osszeszinkronizalja magat
-ertelmes DB engine, a teljesitmeny is nohet
Cons:
-a kb. 3 evvel ezelotti (8.3 vagy 8.4) PG-nel a visszaallas (hogy megint a master legyen a fonok) kicsit maceras volt, de a te megoldasaidnal ez komolyabban fennall. Azota persze fejleszthettek rajta..
-ha tervezesi hiba miatt MySQL kerult a gepekre Postgres helyett, most plusz DB konverzio is kell
--
The programmers of tomorrow are the wizards of the future. You know, you're going to look like you have magic powers compared to everybody else. -Gabe Newell
Az install doc szerint MySQL-t használ. Mondjuk nem rossz ez a "tervezési hiba miatt X került a gépekre" szöveg :)
BlackY
:-)
nem minden adatbazisban van, hanem a levelek file-okban, es a metaadatok mysql-ben (hehe, tervezesi hiba) + a sphinx indexek par nagyobb file.
Meg azert ennel is Cons, hogy az oda, majd vissza atallas azert nem trivialis, es manualiis melot igenyel.
Diktatorok kezikonyve
kossz az eddigieket, nekem az #1 ill. a #4 tunik vallalhatonak. Az illeto mindenesetre a #4-et valasztotta. Meg dolgozunk rajta.
Diktatorok kezikonyve
FIXME, de a veeam backup megoldas, semmi koze a szinkronban tartashoz. az a VMWare FT. ha csak az kell, hogyha meghal a hypervisor, akkor menjen ujra a pileres VM, arra ott a VMware HA.
melyik vmware verzioban mukodik az ft vagy a ha 2 adatkozpont kozott?
Diktatorok kezikonyve
Megy az, ha össze vannak kötve S2S VPN-el és van közös storage. FT-nél mondjuk kell rendes sávszél, de HA-hoz nem.
De erre az esetre sokkal inkább a replication illene.
Ha a pénz számit, akkor vsphere alapon, ott ingyen van :)
2 datacenternel a kozos storage elegge unortodox megoldas, raadasul az FT-re eleg szigoru megkotesek vannak, ketlem, hogy megvalosithato 2 datacenter kozott...
Diktatorok kezikonyve