2xftp szerver master+slave CARP

FreeBSD-all

Sziasztok,

van 2 FreeBSD 8 ftp rendszer CARP-pal master/slave modban.
Be kene implementalni az rsync-et ugy, hogy a /home a masterrol szikronizalva legyen a slave-re.
Ha switchover allna be (a master lennt van), a masik gep venne at az ftp szerepet.
A problema az (allitolag), hogy ha a master ujbol fenn van, a fajlokat, melyek a slaven vannak, szinkronizalni kene a masterre, hogy egyforma legyen a struktura.
hogyan lehetne ezt megoldani?
hogy mukodik az rsync? szerver+kliens modban - azaz demon fut a masteren es kliens a slave-en?
hogy kene felrakni es mit mindket rendszerre?

Total kezdo vagyok FreeBSD rendszeren, ugyhogy lassan magyarazzatok, ha lehet. :-)
koszi szepen a segitseget,

ardi

  • 8506 megtekintés

( andrej_ v | 2012. 01. 23., h – 10:27 )

Nézd meg a HAST-ot. A carp-pal ugye csak virtuális IP-t adsz ide-oda?

nem vagyok jartas CARP-ban, de amit olvastam, az szerint mindent CARP interfeszen vmi service fut
pl. carp0 ftp, carp1 tftp, carp3 scp es mindegyiken mas mas vrtualis ip van, ami teljesen mas, mint a master es slave sajat ip-je. (de azonos mindket gepen):
pl.
master ip xx.xx.xx.10
slave ip xxx.xx.xx.11

azonos mindeketton:
carp0 192.168.xx.1
carp1 192.168.xx.2
carp2 192.168.xx.3

Mi az a HAST es mire jo?

Ardi

Megiscsak probalkoznek azzal az rsync-kel. mindket rendszerre feltennem es manualisan lenne inditva attol fuggoen, melyik a master es melyik a slave.
bootolas utan a rendszer figyelne a sajat es a masik allapotat. ha a sajatja master, elinditja az rsync demont es a slaven meg egy 'megfigyelo' demont, mely lefigyelne, ki ftp-zett a masteren es melyik konyvar valtozott. ha valtozott es sikeres volt az ftp - minden sikeres ftp transzfer utan rsync-elnem a valtozast a slave-re. megoldhato ez?
kozben allandoan figyelnem, nem valtozott-e a slave masterre. ha igen, megfordulna a folyamat.
ha a master rebootolna pl. ftp transzfer kozben, a slave lenne a master es igy az ezen tett valtozasok rsync-kel mennenek a masik szerverre.
van itt vmi bibi?
ardi

Mielőtt ezt megtennéd googlizz rá a következőre: cluster rsync
Hátha megoldotta ez már valaki okosan.
Ha nem is pont ftp szervert clustereznek a problémák valószínűleg hasonlóak.

Szerk.:
Ezt nem ismerem pontosan, de hátha közelebb áll az igényeidhez: http://www.csync.org/
Illetve esetleg ez: http://oss.linbit.com/csync2/

mindjart jonne a kerdes:
A HAST leiras diszkeket emlit. A http://www.freebsd.org/doc/handbook/disks-hast.html szerinti leiras
ervenyes particiora is? Pl. /home felhasznalokat kulon particiora tennem es az ftp-s valtozasok szinkronizalodnanak.

>Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be a>ctive at any given time. The primary node, also called active, is the one which will handle all the >I/O requests to HAST-managed devices. The secondary node is then being automatically synchronized >from the primary node.

Most ha 2 ftp szervert akarok hasznalni es a slave-re kopirozok, akkor bibi van?

Egyeb problema:
>The only problem which remains unresolved is an automatic failover should the primary node fail.

Ardi

Nos, amit a leirasbol kimagoztam, aszerint 2xFreeBSD mint master+slave mukodik CARP-pal.
Hogy most mi koze van a carp-s ip-knek az egeszhez, ha a felhasznalok a masterre vagy slave-re nem a carp-os interfeszen jelentkeznek, nem tudom.
a masik (slave) ftp rendszer mint redundancy mukodik, ha a master kiesne.
nos a problema az, hogy a masteren futo rsync demon es a slave-en levo crontabos rsync szikronizalja a /home konyvtarat.
de ha leesik a master, a felhasznalok szamara meg elerheto a slave, ahova cuccokat rakhatnak fel.
a bibi az, hogyha a master ismet mukodik, a slave-re eredetieleg felrakott cuccokat szinkronizalni kene a masterre, hogy egyforma legyen a /home tartalma.
a bibi:ha ujbol el a master, a slave-n eltuntek a fajlok (a problema leirasa szerint), mivel a szinkronizacio csak a masterrol slave-re van konfiguralva.
ardi

"Hogy most mi koze van a carp-s ip-knek az egeszhez, ha a felhasznalok a masterre vagy slave-re nem a carp-os interfeszen jelentkeznek, nem tudom."

Szerintem egy cluster eseteben nem illik olyat csinalni. A virtualis IP-t kell odaadni a felhasznaloknak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tesztelesre, igen, esetleg. De felhasznaloknak nem szabad odaadni, mert akkor lofaszt er az egesz.

Amugy atgondolva, nem ertek egyet vl kollegaval. Erdemes a management IP-re is engedelyezni az FTP-t, mert igy meg lehet csinalni azt is, hogy amennyiben az FTP szerver eldoglott a masteren, vagy csak siman nem valaszol, automatikusan kivaltani a failovert. Azert nem csinalnam a virtualis IP-n keresztul, mert egyreszt nem tudom, milyen a halozati konfigotok, egyaltalan elerheto-e az az IP/interfesz belulrol, a masik, hogy a virtualis IP interfeszen akarmi is lehet, nem biztos, ha le van terhelve esetleg forgalommal, akkor feleslegesen rangatod at a timeout miatt.

Ehhez persze az kell, hogy a management IP az kulon interfeszen legyen (erosen ajanlott!!!!) mint a virtualis IP.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szerintem meg ha automatikus failovert akarsz, akkor használj valami rendes cluster framework-öt, és ne próbáld meg feltalálni újra a kereket ("kicsit sárga, kicsit savanyú, de legalább a miénk" stílusban), és tákolni valami scriptes szart, ami tizedannyit sem tud (megbízhatóság terén), mint amit mások már rég megcsináltak.

Szerintem.

Ez biztos. :) A slave-re alapból nem tudnak FTP-zni gondolom, csak ha már átvette az FTP IP-jét. A visszaállás mindenképp egy 

rsync --delete-after

jellegűt igényelne, úgy hogy addig a masteren áll az rsync. Ebből következik, hogy ha automatikusan indul az rsyncd a masteren és a carp akkor ott elég érdekes állapot jöhet létre.

Ezzel szemben ha van HAST akkor a master indulásakor, amikor ő lesz az elsődleges újra (bár ez gondolom beállítható), akkor különösebb extra nem történik mert blokk szinten ott lesz az ami eddig a slave alatt volt. Az más kérdés, hogy aki épp feltölt egy ilyen esetnél az nem fog örülni, de scriptelés nélkül Linuxon (pl. DRBD+heartbeat esetén) se lesz szépen rendesen működő.

most mi a biztos??

A HAST doksi elolvasása. :)

ha ftp master_ip, akkor a masterre jutok; ha ftp slave_ip, akkor a slave-re jutok a rakom a cuccokat.

Döntsd el, hogy load balance vagy failover vagy mindkettő kell. A carp alapvetően egy failover megoldás és a HAST is. Az rsync pedig nem pont arra született amit szeretnél.

mit is csinal az rsync --delete-after?? ezt vhogy nem ertettem. bocsi.

Teljes szinkront, amivel mindent törli ami a forráson nem volt ott. Logikusan így lesz szinkronban a két szerver, miután visszaállt a slave-ről a masterre a rendszer egy hiba után.

Részemről ennyi. :)

Ok, ok, en nem akarok senkit sem felmergesiteni - csak kerdeseket teszek fel es megoldasokat keresek.

a carp alapbol ugy van definialva, hogy hiba eseten a master rebootol es a slave veszi at a master funkciojat. jol ertem? es ha ujra beindul a master, akkor ismet masterre valik?

a load balance definicioja nem biztos, hogy tiszta szamomra.
elhesegetne vki ezeket a kodos felhoket a szemem elott?? :-)) koszonom,
Ardi

Ket fogalom letezik cluster temakorben: a failover es a load balancing.

Mindketto kozos tulajdonsaga, hogy a clusternek 1 azaz EGY darab olyan cime van, amit a felhasznalok hasznalnak, nem is tudnak arrol, hogy ott valojaban 1, 2, 3, n gep van.

A failover egy aktiv/passziv felallas, mindig egy node az aktiv, ezeken zajlanak a muveletek. Amikor az aktiv node kiesik, akkor a passziv node veszi at a helyet (failover), mindaddig, amig az aktiv node vissza nem jon (failback). Ez foleg a rendelkezesreallas novelesere alkalmas megoldas.

A load balancing - mint a neve is mutatja - terheleselosztasra szolgal. Ez egy aktiv/aktiv tipusu cluster megoldas, minden node aktiv, es a terheleseloszto (load balancer) megprobalja bizonyos algoritmusok menten elosztani a terhelest a node-k kozott. Itt az a fo, hogy a node-knak shared storage-n kell lenni, hogy pontosan ugyanazt az adatot lassak. Altalaban valamilyen shared iSCSI megoldast szoktak hasznalni hozza, vagy - ha nincs nagy veszelye a locknak - akkor NFS-t. Altalaban akkor hasznaljak, ha nagy terheles varhato, melyet 1 gep nem tudna kiszolgalni.

Fontos: ez affele konyhanyelven osszehordott info, hogy tobbe-kevesbe megertsd. Mindenkepp olvass utana mindket fogalomnak
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

loadbalance
megoldás arra, hogy a két gépet azonos szolgáltatásra egyidőben használd, igy megoszd a terhelést.

failover.
két gép egyazon elérés egymással felváltva biztosítja. Nálad ez ugy néz ki, hogy az ftp processz vagy az egyik, vagy a másik gépen fut, de mindketten ugyanazt az erőforrást irják és olvassák. ( A aktiv gép esetén B nem fogad kapcsolatot, nem nyul a diskhez és forditva ). A közös metszet az ip, amin az ftp fut ( A xor B ) használja.

Nos, a leirtak alapjan nem load-balancingrol van szo. azaz ha a master ujbol e'l, akkor ismet masterre valik.
en ertettem rosszul - azt hittem, hogy master reboot eseten a slave valik masterre'.

ami az ftp-zest illeti, szerintem is a felhasznalonak is virtualis ip-re kene ftp-znie.
szoval ftp carp0_ip, ha carp0 az ftp service a 'jo parancs'?

hogy oldhato meg azonban a nem szinkronizalt /home konyvtar a master+slave rendszeren?

Ardi

Az, hogy a két rendszer hogy vált egyik node-ról a másikra, általában meghatározható. Mi olyan rendszert építettünk, ahol úgy marad.

A megoldást már többen átküldték neked : HAST

Lényegében arról van szó, hogy a fájlművelet mindegyik eszközön megtörténik minden esetben. Csak A kiesés esetén B manageli tovább a kapcsolatokat, és ő irja-olvassa a disket.

Miért más:
A HAST maga manageli a szinkronizációt,
két crontab-ba helyezett rsync esetén pedig te. Ha jön az user, felmásolja a dolgait a B gépen, és A-n nem találja, morcos lesz. Így az adatot mindenhol őrizned kell, ergo rsync esetén azt is meg kell oldalnod, hogy lost állapot ne kerüljön a rendszerbe.

Szoval ha a HAST fele konvergalodom, akkor gondolom, mindket rendszerre fel kene tenni a geom_gate.ko modult es uj kernel kene generalnom.
ez nekem nagyon magas.
hogy nezem meg, hogy egyaltalan fenn van-e a gepeken a modul?
gondolom, jo lenne, ha a /home sajat particion lenne (meg jobb lenne sajat diszken - mert a leiras szerint particiora meg nem probaltak).
Ardi

szuper parancs - koszi a segitseget.
valami ilyesmit kerestem.

szerkesztve: megprobaltam megnezni, hogy benne van-e a carp, de nem kaptam valaszt.
Ezt allitolag belekompilaltak, ezert akartam megbizonyosodni rola.

kldstat -m carp
kldstat: can't find module carp: No such file or directory

jol csinalom?
Ardi

ha kell a carp, i386 eseten es ha fent van az /usr/src,

#cd /usr/src/sys/i386/conf
#cp GENERIC SAJATKERNEL
#echo 'device carp' >> SAJATKERNEL
#config SAJATKERNEL
#echo 'KERNCONF=SAJATKERNEL' >> /etc/make.conf
#cd /usr/src
#make kernel && reboot

reboot utan lesz carp-od.

#man carp
#man ifconfig
#man rc.conf

igy tudod letrehozni a carp ifacet:

#ifconfig carp0 create //stb. man carp ott latni fogod a parameterezesi lehetosegeket //

hameg indulasnal is kell a carp akkor igy:

#echo 'cloned_interfaces="carp0"' >> /etc/rc.conf
#echo 'ifconfig_carp0="inet x.x.x.x/x vhid x advskew x pass jelszo up"' >> /etc/rc.conf

hirtelen nagyvonalakban ennyi

hello macroharddoors,

koszi a kimerito valaszt - ez a kernelgeneralos resz megvan a manualban is, amit kezhez adtak.
de a Tied tomorebb es egyszerubb. :-))
en csak arra voltam most kivancsi, hogy kiolvashato-e paranccsal, hogy benne van-e az eppen aktualis kernelben a carp.
ugy latszik, hogy fajlokban kell keresni?
Ardi

na nem tudom milyen verzioju freebsd-d van, de pl. 8.2-nel nem kell kernelt porgetni a carp-hoz, ezt elfelejtettem leirni.

#kldload if_carp
#echo 'if_carp_load="YES"' >> /boot/loader.conf

ha keresel valamilyen modult ami esetleg betoltheto azt itt talalod:

#ls /boot/kernel | grep modulneve

vagy igy meg tudod nezni az adott kernelbe, benne van-e amit keresel (marmint nem modulkent):

#cat /usr/src/sys/`uname -m`/conf/`uname -i` | grep (ide amit keresel pl. options DEVICE_POLLING vagy akarmi)

( Sea-you | 2012. 01. 24., k – 08:04 )

Nem lenne egyszerubb NFSen tarolni a home-ot?

Én ezeket nem értem, amit szerintem az előttem kérdező sem (úgy némi fogalmam van a load balance-ról, nem sok):
- Legyen load balance az ftp NFS backend-el és ez biztosítja a redundanciát az ftp szerver esetében, okés (ez sem teljesen igaz mivel, ha meghal az egyik szerver, akkor ezt DNS szinten kezelni kell ha jól tudom, de ez most nem érdekes).
- Nade így a problémát arrébb toljuk egyel az NFS szerverre. Azt nem értem, hogy az hogy lesz redundáns.
- Akár load balance akár HA a szinkronizációt meg kell oldani, vagy kell shared storage + failover vagy shared storage + distributed filesystem vagy valami HAST, DRDB féle megoldás.

Benyög valaki egy ilyet, hogy NFS, de ennyi, azt nem hogy miként lesz az redundáns.

Feljebb ez a rész is ki van fejtve, igazából csak össze kellene foglalni egyben. Ha jól emlékszem az iscsi volt megadva, mint backend, ami a tárolást végzi. De pont azért ajánlottunk " nem azonos gépek közötti " block replikációt mert failover volt a kérdés.

A hup fórumok kicsit olyanok, mint az asszociációs játék. Talán azért, mert aki már egyszer megtervezett egy hasonlót nem feltétlen fogja lépésről lépésről elmagyarázni, mert valószínűleg az úgy abban a formában úgysem lesz jó. Vagy épp tök más a keret.

Jelen esetben szépen elkezdték megjelölni a lehetséges versenyző komponenseket. Nyilván a hogy lesz ebből rendszer kérdésre a válasz a manualokban, howtokban és esettanulmányokban van, amit valaki vagy dokumentál vagy nem, de az biztos.

Calamari arra gondolt, hogy oké hogy NFS-en lesznek a file-ok és lesz két FTP szerver, de az hogy mitől lesz failover ha pusztán NFS-re kerül a /home az nem derült ki. Nyilván úgy lesz, ha NFS szerverből is kettő van, erre írta hogy hátrébb toljuk a problémát. A topikindító a SPOF-ot (mert ez rövidítés még úgysem volt a topikban :) ) akarja szerintem megszüntetni.

Erre már a technikákat/lehetőségeket felvázoltuk páran, de _pontos_ igényeket még mindíg a topikindító tudja és neki kell ezt a saját igényei szerint összerakni. Az ilyen "lehet, hogy tenyleg vegig kell olvasnom a hast linket?" jellegűektől pedig mindíg kiráz kicsit a hideg.

Hát igen valóban.
Ha én csinálnék ilyet ftp HA cluster-t, akkor a lehető legegyszerűbb megoldást keresném meg.
Amennyiben megengedhető akár egy kis korlátozás árán is törekednék az egyszerűségre, főleg ha nem nincs sok tapasztalatom.
Bonyolult a HA cluster, akkor ne legyen, legyen egy hot backup és kész, majd egy évben 1-3 x amikor elromlik az egyik gép (legyünk optimisták) felhívnak aztán manuálisan átállítom a másikra.
Az átállás folyamatát leírom valahova, hogy a másik rendszergazda is meg tudja csinálni.
Az élesről folyamatosan megy az rsync a hot copy-ra...
Meg legyen egy backup szerver valahol máshol, nem kell ezt agyonbonyolítani.

Kétlem, hogy itt annyira extrém rendelkezésre állásra lenne szükség, hiszen ha az lenne a helyzet, akkor lenne pénz rendes redundáns tárolóra és olyan emberre aki ilyet csípőből összerak.

Ja meg még ezt biztos megnézném azért: http://oss.linbit.com/csync2/
Tudom én hogy biztonságos meg stabil az ilyen hálózaton működő blokk szintű replikáció, de azért megvannak a maga betegségei, nehézségei, szerintem nem éppen kezdőknek való.

Szerk:
Szerintem jó volt az rsync-es vonal, amin a topic nyitó elindult, az ő tudásához való (nem sértés) és itt egy picit félrevezették overkill technológiákkal.
Sorry, nem akarok flame-et csak ez az érzésem.