Sziasztok!
2 szolgáltatónál van 1-1 szerver (fizikailag 2 külön szerverteremben). Apache2, PHP5, MySQL5 fut rajtuk.
Miként lehetne megoldani, hogy egymás backupjai legyenek? Ha az egyik kiesik, a másik vegye át a helyét.
Eddig dual masteres mysql replikációval van megoldva, és unisonnal, de úgyérzem, valahogy nem az igazi.
Mit tudtok javasolni?
Drbd neten keresztül mennyire jó megoldás? (Mekkora sebesség kell? Mit szól hozzá a mysql?)
- 2443 megtekintés
Hozzászólások
Normalisan beallitott es monitorozott master-master MySQL jo lehet.
Drbd helyett en glusterfs-t neznem meg.
Hogy fogjak a kliensek megtalalni a gepet amin eppen a fut a szolgaltatas?
- A hozzászóláshoz be kell jelentkezni
A glusterfs-el csak ovatosan, van par sajatossaga (pl. nem kezeli a split-braint, nem kezel explicit file-verziokat (csak local mtime alapjan), es nem szinkronizal vissza rogton, ha visszajott a kiesett node), ami ilyen kornyezetben tud meglepeteseket okozni.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
GlusterFS 2.0.0rc1 Announcement
We are happy to announce the first RC release of GlusterFS v2.0. This is a major improvement towards small-file-performance and scalability. Unify has a better scalable alternative called "Distribute", an elastic hash based algorithm. AFR has been renamed to "Replicate" for simplicity. v2.0 is backward compatible with v1.x disk layout. We are eagerly waiting to hear feedback from the community before we call it a stable v2.0.0 release. Link to download GlusterFS v2.0.0rc1
* New to this release: distribute - elastic hash based scheduling for linear scalability
* storage/bdb - distributed BerkeleyDB based storage backend for very small files
* binary protocol - bit level protocol headers (CPU and network effecient)
* mod_glusterfs - GlusterFS Apache / Lighttpd module for web embeddable storage
* Non-blocking I/O - highly responsive socket I/O
* enhanced replicate - atomic writes to handle power-loss, split-brains
* HA - high availability translator
* NUFA - Non-Uniform-File-Access translator for cloud/HPC storage
* root squash - NFS root squashing and uid/gid mapping
- A hozzászóláshoz be kell jelentkezni
Szerintem is maradj a mysql m2m replikacional.
nekem tobb szerver par eseteben is nagyjabol korrekten mukodik nehany eve.
Sosem volt vele olyan problema amit nem a programozok okoztak :-D
Az megosztott fajlrendszert nem eroltetnem, ha nem felteltenul muszaj.
Rendesen megcsinalni draga. Nem rendesen meg csak a szivas mennyiseget noveli.
Interneten at eleve maceras a storage megosztas.
Elofordulhat, hogy mind a ket szerver el es elerhato kivulrol, de egymast nem latjak. Ezzel mit kezdesz?
Talan jobban jarsz, ha az alkalmazast arra terelgeted, hogy az adatainak minel nagyobb reszet tartsa adatbazisban.
- A hozzászóláshoz be kell jelentkezni
Mi a közös storage? Vagy folyamatosan szinkronizálsz a két gép közt?
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Ezen en is elgondolkodtam, gondolom az unison a szinkronizalo program.
- A hozzászóláshoz be kell jelentkezni
Mennyire fontos ez a szervíz? Mennyit állhat a rendszer? közös storage ra csatlakozik? van rá pénzetek, vagy tanulás miatt kell, vagy tényleges production rendszer?
- A hozzászóláshoz be kell jelentkezni
Közös storage nincs, mivel fizikailag 2 külön helyen vannak a szerverek (ha az egyik szolgáltató/szerverterem kiesne...)
Leállás nem nagyon engedhető meg. Nem tanulásra kell, élesben megy a cucc.
Jelenleg az unison szinkronizál 5 percenként, de jó lenne realtime-ban.
A kliensek egy webszerver felé mennek, ahol egy php-t hívnak meg. A php megnézi az első szervert, hogy megfelelő tartalmat ad -e vissza (a kimenetben megtalálható -e egy bizonyos karaktersorozat), ha nem, akkor megnézi a másikat is. Ennek megfelelően redirect-el egyik vagy másik szerverre, esetleg egy hibaoldalra.
Talán egy apache-proxy jobb lenne?
Pénz keríthető rá, mert elég fontos szolgáltatása az ügyfélnek.
- A hozzászóláshoz be kell jelentkezni
master - slave mysql felallas es mondjuk egy sqlrelay?
- A hozzászóláshoz be kell jelentkezni
"A kliensek egy webszerver felé mennek, ahol egy php-t hívnak meg."
Es ez a webszerver nem halhat meg? Vagy az mar nem a tietek?
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Reménykedünk benne, hogy az nem áll le. Az nem nálunk van, hanem egy tárhelyszolgáltatónál.
A gond főként az, hogy nem sima backup kell, mert ha lehal az egyik gép, akkor a másikon folytatni szeretnék a munkát. Tehát az sql-ben is ott kell folytatni, ahol a másiknál megállt.
SQLrelay csak akkor lenne jó, ha nem az egész gép hal le, hanem csak az egyiken az sql, nem?
- A hozzászóláshoz be kell jelentkezni
Két igényt vettem ki a leírásodból.
Az egyik a szolgáltatás gyors helyreállítása egy esetleges HW meghibásodás, a másik pedig a szolgáltatás nyújtása az elsődleges szolgáltató/gépterem "meghibásodása" esetén.
Az első igényre egy HA cluster lehet a megoldás, ami adott helyszínen megtalálható géptöbbesen - jellemzően két gép alkot egy clustert, de természetesen lehetnek többen is - és közös tárolóeszközön alapul, mely konfigurációtól függően legalább egy meghibásodást garantáltan elvisel.
A másik igényre egy disaster site-on lévő backup rendszer a megoldás, mely akkor veszi át a munkát, amikor az elsődleges cluster ebben akadályoztatva van. Ez utóbbi lehet egyedülálló gép is, de jobb ha ez is cluster.
A két megoldás - HA cluster vs. backup server @ disaster site - között a leglényegesebb különbség a szolgáltatás helyreállításának ideje és módja esemény idején. Ez HA cluster esetén automatikus és a szolgáltatás csak addig áll, míg az azt nyújtó alkalmazás elindul. (kicsit tovább, de nem lényegesen)
A backup rendszerre való átállás esélyesen emberi beavatkozást igényel, de ilyen helyzetben amúgy is kerülendő az automatizálás.
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Hazabeszélek, de ha kritikus a szolgáltatás, akkor megkeresném az IBM et, HACMP dual site megoldást neked találták ki.
- A hozzászóláshoz be kell jelentkezni
üdv
tárgyaban említett projektel lenne dolgom mostanában 2. napja
a lényeg:
alkalmazás szerverek legyen 2/3/4 stb jelenleg egyenlőre 2 gépen tesztelem.
http://www.linux-ha.org/ClusterIP
Gép1:
eth0 192.168.124.131
eth0:0 192.168.124.200
iptables -I INPUT -d 192.168.124.200 -i eth0 -p icmp -j CLUSTERIP \
--new --clustermac 01:02:03:04:05:06 --total-nodes 2 \
--local-node 1 --hashmode sourceip
ha.cf
use_logd_yes
bcast eth0
node node1 node2
crm on
authkeys
auth1
1 sha kulcs
gép2:
eth0 192.168.124.132
eth0:0 192.168.124.200
iptables -I INPUT -d 192.168.124.200 -i eth0 -p icmp -j CLUSTERIP \
--new --clustermac 01:02:03:04:05:06 --total-nodes 2 \
--local-node 1 --hashmode sourceip
ha.cf
use_logd_yes
bcast eth0
node node1 node2
crm on
authkeys
auth1
1 sha kulcs
felvettem a resource szabályokat, szép zöld minden (pipa) de ha megpingelem a 192.168.124.200 nem kapok választ.
a cib.xml frissül kommunikálnak egymással a gépek, hibaüzenetet ezzel kapcsolatban nem láttam a logokban
konfigjaim nagyon egyszerűek:
/var/lib/heartbeat/crm/ -ben az XML-ek folyamatosan frissülnek.
általában a 192.168.124.131-re kapcsolódva szerkesztgetem.
amit még észrevettem, hogy ha reloadolom a resourcokat (GUIs Menedzserből), frissül minden, de pl eggyik gépen elveszítem at eth0:0 -t, valamint ha kikapcsolom őket a heartbet leáll az eggyiken, de a másikon sehogy sem akar leállni.
heartbeat csomag + ubuntu 8.10 server
valahol a megoldás közelében járok, de nem tudom jó e eggyáltalán ez a konfigurációm?
valami őtlet?
+IPaddr2
- A hozzászóláshoz be kell jelentkezni