Eh, dakle, rijesio problem sa clusterima. Sada to sve treba redovno backupovati.
Treba mi rjesenje za slijedeci problem:
Dva node-a su u active/passive mode-u, sa drbd diskom kao dijeljenim medijem. Ono sto bi backup program trebao da uradi je
Any ideas?
Da ne idemo skroz iz pocetka, vec sam setup-ova iSCSI, nalazi se na 192.168.4.253.
Kada uradim:
ne dobijem nista kao rezultat.
root@webnode1:/ # iscsiadm -m node
iscsiadm: no records found!
Gdje bi mogao biti problem?
ako procitas zadnji dio na ovom linku
http://wiki.linuxquestions.org/wiki/Iscsiadm
vidjeti ces da je tamo ovo sto ti imas navedena kao uobicajeni problem
Ove http://linux.die.net/man/8/iscsiadm primjere si vjerovatno vec koristio 
…haj napisi sta je rijesenje
Rjesenje je kod mene bilo jednostavno, pobrisao RAID Array-e sa iSCSI-a i napravio nove. RAID Array-i su vec ranije bili setupovani i na njima je bio neki test dump ali nama nista bitno. Tako da sam ih mogao komotno pobrisati. Sad ne znam kakvo bi rjesenje bilo da sam morao sacuvati RAID Array-e.
Sada ih iscsiadm cita bez problema.
I dalje mi treba savjet oko backup programa, sta koristiti i kako rijesiti identifikaciju aktivnog node-a.
Super 
ne kontam zasto ti treba neki poseban mehanizam za odredjivanje aktivnog noda…znas koji je aktivni i on bi trebao da to bude (skoro) uvijek.
Jedino ako ti je mreza losa i fluktuacije izmjene aktivnog-pasivnog hosta cesta, tada bih tome posvecivao puno paznje ( i koristio mozda rhcs/gfs2 ,ali to je stvar izbora ). Osobno bih se bazirao da master bude uvijek master :), drbd mislim da ne radi preko "vecih geografskih razdaljina " tako da se hostovi vjerovatno nalaze u istom rack-u. Tj. osigurati da nema bas puno izmjena maste-slave…namjera ti je da slave “proradi” jedino kada maste ode na spavanje
Dalje, kako cesto imas namjeru praviti backup , i da li drbd dio imas na svakom od hostov-a ( znaci hostovi su nezavisni od bilo cega ostalog ) ili si drbd postavio izvan hostova ne neki storage ( host1 i njegov drbd na eg. lv1, disk za host2 i njegov drbd dio na neki drugi logical volume ( lv )
Ako su drbd diskovi van hostova i “mountani” sa storage-a, moguca opcija moze biti da pravis mirror drbd dijela direkt na storage-u…
hth
DRBD je poseban HDD ali nije neovisan od node-ova. U principu, ne bi trebalo da bude cestih smjena, diskovi su povezani direktno preko zasebne mrezne karte a mreza je dosta stabilna s obzirom da je rack u racunarskom centru.
Backup bih radio ovako:
full backup jednom sedmicno
incremental jos nisam odlucio, mozda jednom dnevno
I oko ovoga mi treba savjet. Naime, ono sto bi se trebalo backupovati su online stores. Dakle razlicite baze podataka. Koliko to cesto treba backupovati, kakva je praksa?
I da li da radim incremental ili differential backup?
[quote=Amar]DRBD je poseban HDD ali nije neovisan od node-ova. U principu, ne bi trebalo da bude cestih smjena, diskovi su povezani direktno preko zasebne mrezne karte a mreza je dosta stabilna s obzirom da je rack u racunarskom centru.
Backup bih radio ovako:
full backup jednom sedmicno
incremental jos nisam odlucio, mozda jednom dnevno
I oko ovoga mi treba savjet. Naime, ono sto bi se trebalo backupovati su online stores. Dakle razlicite baze podataka. Koliko to cesto treba backupovati, kakva je praksa?
I da li da radim incremental ili differential backup?[/quote]
ako koristis mysql onda trazi neko rijesenje koje ce ti biti specificno za mysql , ja bi ti preporucio da dump-as uvijek bazu (tu ti neki incr. ili diff backup tesko ide). zavisi zapravo koje tabele u mysql-u koristis (myisam mozes samo kopirat, za innodb je malo teze trebaju ti logovi ako ih hoces rucno kopirat (mislim bez dumpa)) itd…
sto se tice kako odredit koji je node active , veoma jednostavno imas vec shared ip i uvijek se nalazi na active node-u tako da …
ah ja zaboravih te pitat : a zasto koristis iscsi ?
@maher_
koristimo mysql i magento. Magento cini mi se pravi razlicite tabele, siguran sam i innodb i myisam.
Za active si naravno upravu, odlicna ideja, radim samo backup sa odredjene IP adrese i tako sam siguran da radim backup aktivnog node-a.
Ako su logovi problem, mogu raditi backup cijelog filesystema, sto se prostora tice nije problem, imamo 8 TB u RAID10.
A mislio sam da je iscsi dobro rjesenje. Nemamo love da uzmemo neko profi backup rjesenje, iscsi je jeftin a omogucava network backup. Mislis da je lose rjesenje?
[quote=Amar]@maher_
koristimo mysql i magento. Magento cini mi se pravi razlicite tabele, siguran sam i innodb i myisam.
Za active si naravno upravu, odlicna ideja, radim samo backup sa odredjene IP adrese i tako sam siguran da radim backup aktivnog node-a.
Ako su logovi problem, mogu raditi backup cijelog filesystema, sto se prostora tice nije problem, imamo 8 TB u RAID10.
A mislio sam da je iscsi dobro rjesenje. Nemamo love da uzmemo neko profi backup rjesenje, iscsi je jeftin a omogucava network backup. Mislis da je lose rjesenje?[/quote]
iscsi nije lose rjesenje samo mi se cini u tvom slucaju overhead. koristi nesto jednostavno kao npr. bacula ili rsync+ssh ako hoces vec da kupis file-ove sa filesystem-a. problem ako budes backupiro cijeli filesystem jeste da ako budes htio restorati iz backupa npr. samo jednu mysql tabelu onda ces morat cijeli mysql restorat ili na live system ili na neki treci system i od tamo dumpat table i importovat na live system. razmisli malo sta bi ti bilo najefikasnije , npr. sa mysql dumpom mozes dumpat u zasebne fajlove zasebne tabele tako da ti restore u tom slucaju brze ide ili napravi “test cluster” (sto ti preporucujem) na kojem ces radit testiranje update-a i restore backupa itd … i na “live” system samo ono sto si siguran da ce radit.
Pa mozda je overhead ali vec ga imamo i bolje da ga koristim nego da stoji onako. A test system naravno postoji tako da cu prvo sve na njemu testirati i tek onda ubacivati u live system. Tesko da ce se desiti da riknu oba node-a, tako da je backup zaista posljednje rjesenje.
Nego koji backup program da koristim u mojoj situaciji?
Pitanje, mogu li u svakom slucaju baculu koristiti? Samo kao target navedem iSCSI (koji ce ionako biti mountan na lokalnom sistemu)?
Rijeseno preko open-iscsi-a i rdiff-backup-a. Bacula je genijalan projekat ali zahtjeva puno vremena (koje nemam) za konfiguraciju. Definitivno cu je koristiti u buducnosti. Mysql backup odradjen preko automyslqbackup skripte koju sam nasao na www.debianhelp.co.uk.
Uglavnom, ostaje jos monitoring i zavrseno.