Portál AbcLinuxu, 13. května 2025 23:50
Při použití kvalitního HW odpadají problémy se SW apod. Problémy jsou maximálně s nekompatibilitou ostatních FC zařízení komunikujích na jiné úrovni.
Single Controller je vždy levnější, ale zase při výpadku čekáte na servis. při dual controlleru máte do FC Switche připojeno přes 2 páry toto zařízení. Dá se i přes Dual Controller udělat HA CLuster apod.
Zálohování SAN - na druhé dedikované pole popř. do clusteru a následně do SAN páskového systému LTO.
Obyvklým je dávat vždy jeden cluster HA na 1x SAN i když pomocí SAN BLADE se dá docílit vícenásobné HA
SATA se používají pro velké pole ( disky ES ), SAS disky pomalu nahrazují výkonem disky FC
SAN lze bez problémů poskládat z kvalitních komponentů ( dělám to takto již celkem dlouho ), popř. lze vzít hotový výrobek od HP,DELL,SUN a ostatních.
Obyvklým je dávat vždy jeden cluster HA na 1x SAN i když pomocí SAN BLADE se dá docílit vícenásobné HA
Zajima me spis scenar: 2x Xen hypervisor server - iSCSI - 1x SAN
v pripade ze nepojede SAN = velky problem Lepe poridit jedno SAN s dual controlerem nebo nejak naconfigurovat 2x SAN cluster?Jak caste jsou hw problemy SAN?
Takze to vidim na nejake iSCSI + SuperMicro a OSS nebo Nexentu/Open-E
2 stroje se shodnym poctem disku - iSCSI target jako HA.
- data se zapisuji na oba SAN stroje (DRBD nebo neco podobneho) - jeden iSCSI target (IP) ktery bezi na SAN 1 a v pripade jeho nedostupnosti se presune na SAN - jeste me napada iSCSI multipath
Jeden SAN + jeho zaloha. V pripade hw padu SANu je potreba vymenit hw a pokud jsou necitelne disky tak obnovit kompletni SAN ze zalohy. Coz se muze rovnat nedostupnosti SAN/nemoznosti provozovat virtualy v radu hodin. Tohle se opravdu bezne toleruje v jinych firmach?
iSCSI dnes je celkem v kurzu, ale spousta HW nedělá iSCSI target jako iSCSI na HW, ale vytvoří si jen vlastní LUN SW na disku ( xx-TB fail na disku a v něm jsou další jednotky dělá to třeba takto WSS od MS ) a při zálohování se to chová celkem divně.
Proto bych iSCSI moc nedoporučoval, spíše jít cestou FC s tím, že následná konfigurace by byla řešena optikou přes nějaký switch od HP/CISCO. U iSCSI je jasné, že je tu možnost mít přřes iSCSI namapován celý systém vzdáleně přes IP, ale toto se dá
udělat i jinými prostředky. Stále je lepší mít nějaký FS na reálném systému.
SW na Disaster Recovery tak, aby to bylo ideálně obnovitelné bez nějaké ztráty pro Opensource moc není, spíše se používají komerční nástroje od NetVaultu,Symantecu,Legato nebo HP. Ale ty SW to je opravdu celkem slušný ranec
peněz. Bohužel freeware, který by dokátal toto no moc toho není.
1) IP-SAN = z hw hlediska se jedna o case + mb + cpu + RAM + RAID controler/y + disky a to cele je rizeno specializovanym OS/BIOS? Porad totiz nechapu ten vyznam dual controleru. Kdyz mi padne zakladni deska do ktere je zasazen controler tak je mi ten druhy stejne k nicemu ne? Nebo je architektura IP-SAN jina?
IP-SAN by melo slouzit pro vice fyzickych serveru, tedy umoznovat live migrace atd. Cimz se vzhledem k cene vylucuje FC reseni.
Koukam tedy po reseni typu OpenFiler v HA (2x server) aby byl zajisten beh virtualu i v pripade vypadku jednoho z mirroru(serveru) SAN.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.