Tákolt távoli tükör (storage)

Linux-haladó

Sziasztok,

Adott nekem 2db storage, az egyszerűség kedvéért nem nevezek meg pontos típust, stb. Lényeg h. elég régi mindkettő, ugyanazon típus és sajnos nincsen hozzá távoli tükrözés license, de nincs "kedve" a cégnek venni.
Hogyan oldanátok meg a két cucc tükrözését? A storage kb. 300m-re van B storage-től, mindkettő iscsi-n kommunikál saját vlanban, amit a szerverek akik kiszolgálnak látnak, működik is a dolog, mindenki lát mindenkit.
A két cucc összetükrözésére és 3 lehetséges megoldást látok:

  • drbd (primary/secondary)
  • lvm
  • mdadm (elvileg a kettőről tudnék szinkron olvasni ha mondjuk raid1, de nem tudom hogy bírja a széthullást, stb., nem jobb-e a drbd?)

Ki hogyan csinálná? :)

Köszi,
Zoli

  • 1705 megtekintés

( vl v | 2010. 11. 10., sze – 11:03 )

Ha szinkron másolatot akarsz:

Hoszt-oldali tükrözés.
Ez lehet mdadm (RAID1) vagy LVM tükrözés. Ha kell LVM (is), akkor egyértelműen az LVM natív tükrözését használnám, az ugyanis csak a felhasznált területet tükrözi újra.

Ha aszinkron másolatot akarsz:

drbd

A két megoldás alapvetően különbözik, amire jó az egyik, arra nem jó a másik.

( asm v | 2010. 11. 10., sze – 11:20 )

Biztos hogy szinkronban szeretned hasznalni a ket storage-ot?
Lehet hogy jobban jarnal, ha a tavolabbik storage-ra egy rendszeres snapshotot keszitenel mondjuk LVM segitsegevel. Igy ha a szerver oldalon tortenik vmi gubanc (fs crash, veletlen torles, etc.), akkor mindig lesz mentesed egy korabbi konzisztens allapotrol, tehat a backup reszet is kipipalhatod.
Szerintem a szinkron hasznalat elsosorban clusterezeskor elonyos, amihez meg specialis fs is kell (pl. gpfs)...

Ő nyilván a multi-access diszkre gondolt, amikor a clusterezést említette...

Mondjuk szerintem nem kéne olyan dolgokat felvetni szegény tapasztalatlan kezdőnek, amivel úgy sem tud mit kezdeni. A multi-access diszk + cluster + clusterfs, az pilótavizsgás, és orbitális szopások tudnak ott lenni.

Tény. :)
Egyébként üzemeltetek ilyet is, csak itt most tákolni kellene. Egyébként mehetne az egész clvm + gfs2 alapon is, vagy akár ibm gpfs alapon is, replikációval megspékelve, lehet itt durvulni.
Nekem egy egyszerű HA megoldás kellene, tehát ha storage1 eldurran, akkor legyen storage2 egész röviden. Lesz rajta mondjuk lvm, arról mennek ovz gépek és öröm és bódogság :)

A döntésnek vannak "következményei". Az aszinkron döntés következménye pl., hogy ha megdöglik a "primary" diszked, akkor el fognak veszni adatok, azok, amiket még éppen nem szinkronizált át a rendszered. Ha ez egy weboldal, ami kb. read-only, és csak a webadmin szokta néha cserélgetni a html fájlokat, akkor nem látok ezzel problémát. Ha ez egy webshop, akkor számítsál dühödt felhasználókra, akik hiányolják a visszaigazolt megrendeléseiket, amik "egyszercsak" eltűntek a rendszerből.

A mirror a kívánalom :) Viccet félretéve, ha netán nő a terhelés, sok írás történik, akkor bukom az rsyncet, mert sok cput és io-t fog enni, jobb felkészülni és később még mindig megléphetem h. átkapcsolom a drbd-t syncre pl.
Esetleg kapásból synccel csinálnom és nem fenyeget az inkonzisztencia, ha meg szar a performancia, akkor el lehet gondolkodni akár az rsyncen is, de az async megoldáson is.

Ha az rsync-et nem ssh-n keresztul tolod, akkor nem gondolnam, hogy sokkal tobb cput fogyasztana. Ha gyakori lesz az rsync-eles, akkor a kernel ugyis a cache-ben tartja az fs dir strukturat, nem fogja minden alkalommal vegigjarni az egeszet.

"jobb felkészülni" vs. "fsck and pray" :)

Es hogy szeretnetek backupolni/archivalni? Mert pl. szinkron esetben a backup musthave + archivalas. Aszinkron esetben megfelelo snapshot modszerrel akar kivalthato a backup is, igy csak az archivalast kell megoldani egy harmadik helyre.

( LZ | 2010. 11. 10., sze – 11:25 )

Mekkora és milyen sávszél áll rendelkezésre a két storage között ?

( egeresz | 2010. 11. 10., sze – 11:32 )

vegyetek bele remote mirror licenszt, vagy vegyetek egy masik storaget amiben van, azzal jarsz a legjobban.

ha host oldalon tukrozol (lehetseges) akkor sok-sok helyen kell tukrot definialni. Mindegyiket karbantartani.

En konkretan a drbd -t javaslom, ugyanis egyetlen masik (md, lvm) nincs felkeszitve a tavolsag miatti eltero valaszidok miatti iszonyatos gubancokra.

Azt is lehet csinalni, hogy beraksz egy proxy storaget, ami kap a valodi storage-tol LUN-t iscsi-n, es tovabad LUN-t iscsi-n, es a ketto kozott meg elvegzi a tukrozest a tavoli telephelyen levo parjaval.
Barmit csinalsz, baromi maceras. Rengeteg kezi reszeles kell hozza, es a vegeredmeny nagyon instabil lesz.

Ha van egyetlen fontos szolgaltatasod (es az pont egy oracle db) azzal meg lehet csinalni, hogy az egyik log/journal a tavoli storage-re menjen, es attolsz napi mentest is a tavolira. Akkor valahogy ugyan, de el lehet inditani a szolgaltatast a lokalis halala eseten.

A volume groupok konfigurációja magán a volume groupot alkotó diszken van, ezért ha az egyik szerverről át kell rakni a volume groupot a másikra, az "viszi magával" a konfigurációját.
Ha módosítasz valamit az egyik gépen levő vg-n, azt nem kell a többin is módosítani.

A 12 lun 2 db iSCSI storage-on van, ami a 8 szervertől független, tehát tetszés szerint lehet a diszkeket ide-oda pakolgatni.
A lényeg, hogy az egy volume groupba tartozó diszkek lehetőleg együtt mozogjanak.

Tehát csak a mount pointokat kell karban tartani, de ez meg sehogy nem úszható meg.

Modern linuxszal letrehozottat ertelmezni tud egy nehany eves kernel?

Jó eséllyel gondok lesznek. Ha nem konkrétan a formátummal, akkor a bugokkal. Szinte minden évben találnak olyan szintű VM/FS bugokat a kernelben, ami után én nem mernék jó szívvel régebbi kernelt használni fontos, éles rendszer alatt.

Pl. linuxszal letrehozott LVM configot AIX is tud kezelni?

Semennyire. Az, ami ezt platformok között tudja, azt úgy hívják, hogy Veritas Volume Manager, meg Veritas File System (VxVM, VxFS). Sok pénzért árulják.