Oszd meg és uralkodj!

A valóság show-k részét képezik televízióink mindennapjának.

Hogy ez jó-e avagy rossz, sokan próbálják elemezni. Az viszont bizonyos, hogy gyártásuk során számos izgalmas technikai kérdés merül fel. Különösen a folyamatosan 24 órában képződő nyersanyag katalogizálása és vágása jelent nagy kihívást.

Magyarországon (és a világ más országaiban is túlnyomórészt) Avid vágórendszereket és megosztott háttértárakat használnak erre a célra.

A “megosztott háttértár” kifejezés korunk egyik divatszava. Sokan keverik és nem értik a különbséget az úgynevezett SAN rendszerekkel. A csoportmunka a lényeg, az hogy egyidejűleg többen dolgozhassanak ugyanazon a projekten vagy médián. Az informatika minél mélyebbre hatol a ma televíziójának infrastruktúrájában, annál többet fogunk találkozni ezzel a kifejezéssel. Terjedése megállíthatatlan, előnyei vitathatatlanok, kockázata pedig óriási. Ha működik csoda, ha csak egy kicsit is nem működik, rémálom. Igazi mindent vagy semmit szituáció!

Magyarországon 1998-ban jelent meg az első megosztott háttértár a Kecskeméti Városi Televízióban, a legutolsó pedig a napokban az Interaktiv Kft. székhelyén kezdte meg a TV2 számos produkciójának feldolgozását. Az elmúlt 5 évben drámai változásokon ment át a technológia, így talán eljött az ideje annak, hogy összefoglaljuk (a teljesség igénye nélkül) a legfontosabb ismérveit és ez elmúlt évek használatának tapasztalatait valamint megpróbáljuk egy kicsit megmagyarázni a különböző elnevezésket és általában megismerkedjünk a lényegesebb fogalmakkal.

1. Mit is osztunk meg?

Az informatikában általános céllal már sokkal korábban megjelentek ilyen tudású eszközök, de most kifejezetten a televíziós alkalmazásokat tekintjük át. Mivel megosztott háttértárnak nevezzük a technológiát, kézenfekvő, hogy a háttértárat osztjuk meg. Ilyenek voltak az első rendszerek 5 évvel ezelőtt.

Őket ezért “Volume Sharing” elnevezéssel illették. Ilyen esetekben nem tudták ketten egyidejűleg ugyanazt a file-t használni, de bizonyos korlátozásokkal tudtak egyidejűleg írni és olvasni a megosztott háttértáron. A napi használat során aztán hamar kiderült sokszor ez nem elég, jó lenne ugyanazt a file-t is egyszerre többfelé is használni. Ekkor jelentek meg a “File Sharing” avagy file megosztó szoftverek, amelyeknek segítségével lehetséges volt az egyidejű file használat. Aztán persze kiderült, ez sem elég. Sok esetben jó lenne, ha az adott vágandó anyagot is többen tudnák egyidejűleg használni. Ehhez már nem volt elég a háttértárat és a mediát megosztani, szükség volt a vágás adatait tartalmazó, projekt file megosztására, mert így egyidejűleg többen is tudták ugyanazt a mozit vágni. A “Volume Sharing” és a “File Sharing” szoftverek esetében még lehetséges volt a vágórendszer gyártója nélkül is létrehozni a megosztást. A projekt file-ok vagy a binek megosztása már nem lehetséges a vágórendszer gyártóinak közreműködése nélkül. Ezt nekik kifejezetten meg kell engedni. Ezért aztán a fejlesztés egy része is a gyártók kezébe került át.

2. Miért nem elegendő az operációs rendszer megosztóképességét használni?

Azért mert a hagyományos kliens-szerver struktúra lassú és nem elegendően megbízható erre a célra.

Amikor a 90-es évek elején először kezdtek erről gondolkodni, akkor még nem sejtette senki, hogy ilyen esetekben nem “Media Server”-ekről kell majd beszélni. Az első csoportmunkát támogató rendszereknek a lelke a media szerver volt. Az első “Media Server” installáció az Avid rendszere volt a CNN fn televízióban.

Habár a tömörítéses eljárások hatására a video digitalizálás során egyre kisebb és egyre jobb minőségű nemlineáris vágás vált lehetővé, azért még így is igen nagy mennyiségű adatot kell feldolgozni. A media szerveres struktúrában minden médiát a szerver háttértárán tároltak és ehhez a vágórendszerek, mint kliensek fértek hozzá. Ez a kliens – szerver architektúra lényege. A dolog egészen jól működött. Apró szépséghiba volt csupán, hogy nagy tudású, millió dolláros szerver kellett a feladat megoldásához, a millió dolláros háttértár és az igen drága, távközlésből átvett, úgynevezett ATM hálózatos megoldás mellett. A futballcsapatnyi, igen speciális tudással kiképzett, a Unix rendszerek minden csínyját-bínyját ismerő informatikusokról pedig ne is beszéljünk.

Azért volt minderre szükség, mert a szerveren a médiát és annak meta-adatait, valamint a hozzáférési jogosultságok változását is követni kellett. Minden videót óriási sávszélesség igénnyel át kellett tuszkolni a szerver adatbuszain. Tovább nehezítette a helyzetet, hogy a szerverek valamilyen Unix operációs rendszert használtak, általában minimum 8 proceszorral és igen különleges, ennek megfelelően drága buszrendszerrel, hogy a nagy adatmennyiséget kezelni tudják. A kliensek (a vágógépek) viszont vagy Windows vagy Mac operációs rendszerrel rendelkeztek. Ez aztán újabb, jelentős bonyodalmat jelentett. Sajnos ekkortájt a megfizethetőbb Windows NT operációs rendszerű, Intel processzoros rendszerek nem voltak elegendően gyorsak (és megbízhatók sem) a Unix rendszerek kiváltására. A sok nyűg ellenére is számos előnye volt az így kialakított produkciós folyamatnak, így aztán több tucatnyit is eladtak ezekből a rendszerekből a különböző, nem túl nagyszámú gyártók.

1. ábra: Media szerveres rendszer elvi blokk diagramja

Az implementálásnál alapvető nehézséget okozott még a gépek közötti hálózati összeköttetés. A 100 Mbps átvitelű Fast Ethernet rendszerek még csak ekkor voltak terjedőben, az általánosságban is elterjedt hálózat inkább csak 10 Mbps Ethernet volt, azon pedig fizikai képtelenség lett volna megoldani a problémát. Így kezdték el használni a 155 Mbps átviteli sebességű, távközlésben használt és elég jól szabványosított ATM hálózatot a media hálózati kezelésére és meghagyták a sokkal kisebb átviteli sebességet igénylő metaadat kezelést az Ethernet hálózatnak. Az Ethernettel volt még egy másik alapvető probléma. A hálózatra kerülő adatok csomagolásával a kliens vagy a szerver processzorának kellett megküzdenie, tovább csökkentve ezzel a a media feldolgozására rendelkezésre álló amúgy sem túlságosan bőséges processzorteljesítményt. Az ATM hálózat esetében a hálózati csomagok kialakításának jelentős része a hálózati kártyán és nem a PC processzorának igénybevételével történt.

Szerencsére az informatika fejlődése nem állt meg.

3. Fibre Channel és SAN

Az 1997 táján megjelenő Fibre Channel rendszerek a fent felsorolt problémák jelentős részének kezelését számottevően megkönnyítették. Elméletileg 1000 Mbps átviteli sebességgel rendelkeztek. Akár IP, akár SCSI protokoll szerinti átvitelre képesek voltak, mindezt úgy, hogy ehhez szinte semmilyen processzor teljesítményre sem volt szükség, hiszen a kártyán lévő processzorok csináltak mindent. Így tehát akár hálózati kapcsolat kialakítására, akár háttértár csatlakoztatására alkalmasak voltak. Mód nyílott tehát olyan nagy sebességű hálózat kialakítására, ahol a háttértárakat nem kellett valamilyen PC-re csatlakoztatni és az operációs rendszeren keresztül elérhetővé tenni a hálózat más gépei számára, hanem közvetlenül a hálózathoz csatlakoztathatók voltak egy kapcsolóberendezésen keresztül. Így keletkezett a SAN vagyis Storage Area Network. Alapvető tény, amit érdemes megjegyezni: minden SAN rendszer lehet megoszott háttértáras rendszer, de nem minden megosztott háttértáras rendszer SAN.

2. ábra: SAN rendszer elvi blokk diagramja

Mint a 2. ábrán látható, itt a háttértárak közvetlenül a Fibre Channel switchhez csatlakoznak, nem pedig, mint az 1. ábrán látható, a Media szerverhez. Sőt, itt egyáltalán nincs is média szerver! Va viszont helyette File Manager, amit más elnevezés szerint metadata kontrollernek is szokás hívni. Nem szükséges Ethernet hálózat a meta-adatok kezeléséhez, habár vannak olyan rendszerek, ahol lehetséges ezeket Ethernet hálózaton keresztül továbbítani. Ezt hívja a szakzsargon “out of band” vagyis sávon kívüli adatkezelésnek.

4. A Fibre Channel rendszer építőelemei a következők:

- Rézkábelek DB9 vagy HSSD csatlakozóval. Max. 25m távolságig

- Hosszabb  távolságokhoz az SC illetve az újabb 2 Gb átviteli sebességű rendszereknél SF-LC csatlakozó terjedt el az üvegszálas kábelezésnél, az ATM-nél használt ST csatlakozással szemben.

- Multimódusú üvegszálas kábel, 2 km-nél rövidebb távolságokhoz. Belső átmérô 62.5 vagy 50 mikron, a fény egyenesen és különböző szögekben egyaránt terjedhet benne, így a diszperzió miatt gigabites sávszélességet csak 200 m távolság alatt nyújt

Mono (“Single”) módusú üvegszálas kábel nagy távolságokhoz, 7 vagy 9 mikron a belső átmérője, csak egy fénysugár továbbítható benne, így nincs benne szóródás. Átviteli távolsága csak a lézer teljesítményétől vagy a vevő érzékenységétől függ.

- Diszktömbök. Itt kapcsolódnak a merevlemezes egységek össze a beépített Fibre Channel hurokhoz vagy a switchhez. Ha a diszk nincs a csatlakozósoron jelen akkor automatikusan záródik a hurok. A diszktömbök csatlakozhatnak a switchhez közvetlenül és csatlakozhatnak hurkon keresztül egymáshoz is. Ha hurkolva csatlakoznak egymáshoz, akkor az eredő sávszélesség a hurok sávszélessége marad, ezért így a rendszer sebessége nem, csak tárolókapacitása bővíthető. Amikor akár tucatnyi terabájtnyi anyagot kell kezelnünk nagyon fontos a védelem. Különböző RAID eljárásokat szoktak erre a célra használni, legelterjedtebbek a RAID 3 és 5 illetve tükrözéses (RAID 1) különböző változatai. Általában melegen cserélhetőek a tápegységek és a meghibásodott diszkek is. Sok esetben még a RAID controller kártya memóriájában lévő, a merevlemezre nem írt adatok védelméről is gondoskodnak speciális memóriákon keresztül. Ma már rendelhetőek olyan diszktömbök is, amelyek olcsó IDE meghajtókat használnak, úgynevezett FIBRE-IDE Bridgen keresztül, ami lehetővé teszi igen olcsó sok terabájtnyi kapacitás felépítését. A gyakorlati tapasztalatok azt mutatják, hogy nagyon közel a natív Fibre diszktömbök sebességéhez. Ma már nem ritkaság a 2 Gb csatlakozású tároló sem. Persze tudnunk kell még, hogy ha egy 2 Gb-es hurokra 1 és 2 Gb átvitelű rendszereket egyaránt felteszünk, akkor a hurok csak 1 Gb átviteli sebességgel fog működni.

- Szoftver driver. Azon meghajtó szoftverek összesége, amelyek lehetôvé teszik az interfész kártya használatát. A legtöbb operációs rendszerhez adnak ilyen szoftvereket az interfész kártyák gyártói: Windows NT, 2000, XP AIX, Solaris, Irix, HPUNIX, Linux, Mac OS 9 és X. Általában SCSI, IP és ATM protokollt támogatnak.

- Host Bus Adapter (HBA). Interfész kártya, hasonló a SCSI vagy a Network Interfész Adapter kártyákhoz. Mind réz, mind üvegszálas kábelhez használhatók. Általában PCI buszos, de kapható Sbus, MCA, EISA, GIO, HIO, PMC buszcsatlakozással is.

- Extender. A multi módusú összeköttetést konvertálja single módusúra és megnövelt teljesítménnyel akár 30 km távolságra is átviszi azt.

- Gigabit Interface Converter (GBIC). A réz csatlakozó felülethez csatlakoztatva azt optikai csatlakozásra konvertálja. A GBIC HSSD csatlakozót, a Media Interface Adapter (MIA) DB9 csatlakozót használ. Igy gazdaságosan keverhető egymással a rövid távolsághoz a réz, hosszabb távolsághoz az optikai csatlakozó felület.

- FC HUB. Kapcsoló elem, melyeknek segítségével a végpontokat csatlakoztatjuk a hurokhoz. Általában kevesebb, mint 10 portja van, max 127 portig stackelhetô. Támogatja a meleg, vagyis működés közbeni csatlakoztatást. Érzékeli ha a végpont üzemen kivül van és annak portját lekapcsolja a port bypass circuit (PBC) segítségével. Általában nem javasolt használata broadcast rendszerek esetében, ahol közvetlenül adásba is játszanak, mivel a portok ki – és bekapcsolásakor minden portot végig ellenőriz a rendszer és amíg az ellenőrzés tart (néhány másodperc is lehet), addig a portokon kimaradhat vagy megszűnhet az adatforgalom. Ez azt jelenti, hogy jobb esetben az éppen kijtászást végző gép vagy video szerveren kimaradhatnak másodpercek is a kijátszás során. Ebben az esetben a video szerver beállításának függvényében az leállíthatja a kijátszást, hiszen “drop”-olt képkockákat érzékelt és azt hiheti, hogy hiba van, a diszk alrendszer nem adja elég gyorsan a video streamet. Kicsi 2-3 kliensen rendszereknél még így is reális alternatíva lehet a hub, hiszen számottevően olcsóbb, mint a switch.

- Switch. Igen nagy sávszélességű és rendelkezésreállású kapcsoló berendezés, 8 és 16 porttal általában, de léteznek nagyvállalati rendszerekhez nagyobbak is. Tipikus frame kapcsolási idő kisebb, mint 1 mikrosec. Stackeléssel összesen 16 millió címből álló rendszerek is felépithetők segítségével. A switchekben általában cserélhető GBIC-ek (lásd fentebb) biztosítják a különböző réz vagy üvegszál összeköttetések egyidejű használatát.

- SCSI Bridge. A meglévő SCSI háttértárakat kapcsolja a Fibre Channel rendszerhez. Archiválásnál is szokták használni, a SCSI interfészt használó robotos könyvtárak rendszerbe illesztésénél.

- Router/LAN Switch vagy Gateway vagy Port Server. Interfész a Fibre Channel rendszer és hagyományos LAN között.

- Switch WAN Extender. Nagy távolságú összeköttetéshez szükséges eszköz. ATM szolgáltatást is igénybe lehet venni a segítségével. Mivel sebessége nagyobb lehet, mint az ATM-é, így többszörös ATM kapcsolat használható a teljes sebességű összeköttetéshez.

- Manager szoftver. Itt most kivételesen nem a file manager szoftverről van szó. Inkább a megosztott területekhez történő hozzáférés szabályozásáról. Ezzel a szoftverről hozhatók létre a megosztott virtuális vagy valós partíciók, itt kell, hogy managelhető legyen a RAID védelem. A fejlettebb rendszerek esetében RAID rugalmasan konfigurálható, akár használat közben is. Itt biztosíthatók és állíthatók be a különböző hozzáférési jogosultságok, ami csoportmunka esetében nagyon fontos. Szintén itt állítható, be, hogy mely kliensek kapjanak garantált sávszélességet, melyek nem. A jobb rendszerekben lehetséges automatizmusok használata, például be tudjuk állítani, hogy az aznap digitalizált anyagok automatikusan mindig RAID védelem alatt legyenek vagy hogy a projekt file-ok és time-code alapján vissza nem digitalizálható file-ok is külön védelmet kapjanak. Szintén fontos, hogy a manager szoftver IP-alapon távmenedzselni is tudjon, vagy adott előre definiált hibák esetén email vagy SMS üzeneteket küldjön az operátornak.

5. File Manager

Ne felejtkezzünk meg persze az 1. kérdésben említett különböző megosztási módszereket végző alkalmazásokról sem. Ezeket általában a File Manager (vagy más néven Meta-adat Controller) gépen futtatják és megvásárlásuk kliens szám alapján történik. Ha 9 vágógépet szeretnénk csatlakoztatni egy megosztott háttértárhoz, akkor általában 10 licenszet szükséges vásárolni (9 kliens plusz a File Manager). Ilyen szoftver az Avid Unity rendszerének File Managere, ami kifejezetten video felhasználásra optimalizált és akár Windows NT, 2000, XP és Mac OS 9 operációs rendszerű kliensekkel és Windows NT szerverrel műkődik. Az IBM tulajdonban lévő, korábban Mercurynak hívott Tivoli Sanergy nevű alkalmazása (általános infomatikai célokra készült, de a televíziózásban általában Matrox Digisuite kártyát használó rendszerekhez illetve grafikai és animációs rendszerekhez terjedt el), szinte minden ismert operációs rendszerrel használható, valamint említést érdemel még a Centra Vision alkalmazása, ami a Sanergyhez hasonló. Általában 600.000 és 1.500.000.- Ft körül kell kliens licenszenként számolni az árat. Ettől olcsóbb kategóriába tartozik a Charismac és a Rorke egy-egy alkalmazása. A Charismac Mac OS 9 és X illetve Windows NT rendszereken használható (Windows XP fejlesztés alatt) és nem igényel külön File Managert, a kliens gépeken fut. A “Volume Sharing” alkalmazások közé tartozik az ATTO Accelware nevű szoftvere. Vannak még további esetleg említést érdemlő gyártók, de a felsoroltak tekinthetők a legelterjedtebbeknek. Említsük meg azokat a rendszereket is, ahol speciális szoftverek segítségével a Fibre Switchben futó kis alkalmazások (appletek) végzik el a file megosztás feladatát. Ezek a legdrágábbak, de ebben az esetben a megbízhatóság növekszik azzal, hogy még a File Manager PC is elhagyható.

6. Redundancia avagy essünk-e pánikba, ha valami meghibásodik?

Kulcsfontosságú kérdés.

Amikor mindent egy helyen, a megosztott háttértáron tárolunk, akkor hiba esetén bizony van veszíteni valónk. A bekövetkező hibára persze fel tudunk készülni. Szokás már a rendszerünk tervezésekor mérlegelni a különböző lehetőségeket.

Minél nagyobb a rendszerünk, annál több gondosságot kíván a tartalékolás megtervezése.

Alapvetően kétféle módon tehetjük: eszközszintű és rendszerszintű tartalékolás segítségével.

Eszközszintű tartalékolás. Azt jelenti, hogy az eszközön belül a meghibásodásra leghajlamosabb alkatrészeket tartalékoljuk. Ezek lehetnek tápegységek, merevlemezes meghajtók, interfész kártyák, RAID vezérlő kártyák. Általában, de nem mindíg melegen vagyis az eszköz kikapcsolása nélkül cserélhetőek. Különösen fontosak és viszonylag kevés figyelmet szoktak kapni a RAID vezérlő kártyák és memóriáik, amik 128 MB és 512 MB közötti adatot szoktak tárolni. Ha a vezérlő memóriájában lévő adatokat nem mentjük folyamatosan vagy merevlemezre vagy egy másik, külön akkumulátorral rendelkező memóriába, akkor nem fogjuk tudni visszaállítani a tárolórendszerünk tartalmát, csak igen nagy nehézségek és sok-sok szerencse által, még akkor is ha két vezérlő kártyát használunk párhuzamosan.

Rendszerszintű tartalékolás. Kétféle megoldás lehetséges: a fontosabb eszközöket duplikáljuk (vagy nagy rendszerben n + 1 módon tartalékolunk, ami azt jelenti, hogy mondjuk 8 eszközhöz egy kilencediket biztosítunk általános tartalékként, feltételezve, hogy nem hibásodik meg egyszerre egynél több eszköz) illetve a rendszer egészének munkafolyamatai kialakítása során menekülési útvonalakat tervezünk, amelyek ugyanolyan vagy csökkentett funkcionalitással működnek. Ez utóbbi megoldás komoly munkafolyamat-analízist és stratégiai döntéseket igényel, amelyeket aztán részletesen meg kell ismertetni és be kell gyakoroltatni a felhasználókkal. A duplikálásnál leginkább a file managert, a switchet és a gépekbe helyezett FC interfészkártyát szokás figyelembe venni. Ebben az esetben bármely felsorolt elem meghibásodik, azonnal rendelkezésre áll egy tartalék útvonal. Az átkapcsolás az elsődleges és a másodlagos útvonal között általában automatikusan történik, sok esetben nem is észrevehető a felhasználók számára. A legtöbb esetben azonban az átkapcsolás pár másodpercet igénybe vehet és ebben az esetben a rendszer néhány elemének működése leállhat.

Az esetek túlnyomó többségében az eszköz – és rendszerszintű tartalékolás kombinációját használják. Vagy egyiket sem, bízván a jövőben és a jószerencsében.

3. ábra: tartalékolás 1

A 3. ábrán egy több szintű, eszközszintű és rendszerszintű n+1 tartalékolást és duplikálást egyaránt használó rendszer vázlatát láthatjuk. A két csatornás adásrendszer két szerverének a tartaléka egy harmadik szerver, amely egyben normál esetben a beírást végzi, de vészhelyzetben tartalék kijátszó csatorna, illetve a File Manager tartaléka is egyben. Mint az az ábrán látható mind a szerverekben, mind a File Managerben két FC interfész kártya van, így egyidejűleg mindkét switchhez tudnak csatlakozni. Természetesen minden eszközben melegen cserélhető tartalék tápegység is van, illetve a PC-kben az operációs rendszer egy másik merevlemezre RAID 1 eljárással tükrözött. A médiát RAID 3 eljárással védett disztömbökön (kettő darabon) tároljuk. Ez azt jelenti, hogy diszktömbönként egy paritás és egy meleg tartalék meghajtót használunk el. A meleg tartalék meghajtó azt jelenti, hogy ha a meghajtók közül egy meghibásodik, akkor a rendszer a paritás meghajtó segítségével azonnal megkezdi a meghibásodotton lévő adatok átmentését az üres meleg tartalék meghajtóra. Így az összesen 20 meghajtó közül összesen 16-ot tudunk felhasználni media tárolására. 4 válik a tartalékolás áldozatává.

4. ábra: hírrendszer tartalékolás elvi blokk diagramja

7. SAN vagy megosztott háttértár csak Fibre Channelen?

Nem. Számos egyéb kombináció is lehetséges.

Az első, igaz még meglehetősen kezdetleges “Volume Sharing”-et tudó FireWire-alapú rendszer még 2000-ben megjelent, ilyet használ például a Magyar Televízió Soproni Regionális Studiója, a Micronet SANCube termékéről van szó. Itt IDE merevlemezek csatlakoznak egy FireWire – IDE bridgen keresztül egy FireWire hubhoz, majd a Apple Powermac G4 gépek alaplapi Firewire csatlakozásához.

Szintén FireWire diszkek megosztását is el tudja végezni az előző pontban említett Charismac szoftvere is. Az általuk módosított, un “multi-initiator” FireWire-IDE bridgek egyidejűleg több diszk címzését is el tudják teljes sebességgel látni hubokon keresztül. A FireWire rendszerek nagyon olcsók lehetnek, de néhány kompromisszumot használatukkor figyelembe kell venni:

- Korlátozott sávszélesség: a kliensek számára a bridgek és a 1394a szabvány okozta korlátok miatt nem áll rendelkezésre több, mint 40 MB/s. Ez a gyakorlatban 3-4 DV25 tömörítést használó kliensre korlátozza a rendszer nagyságát. A közeli jövőben ebben is változás várható, az új Apple Powermac és Powerbook gépekben már a mostaninál kétszer gyorsabb 800 Mbps átvitelű FireWire rendszer van, így mind a csatlakoztatható kliensek, mind a kisebb tömörítést használó montírozók használata is elképzelhető lesz hamarosan.

- Kábelhossz: a jelenlegi technológia szerint gyakorlatilag 10m lehet maximum egy-egy kliens ág kábeleinek hossza, és már ehhez is speciális kábelek kellenek. Az előző pontban említett 800 Mbps átvitelű új szabvány ebben is változást hoz majd, hiszen mind cat 5 kábel, mind üvegszálas összeköttetést is meg enged majd.

- Hub okozta problémák. Előfordulhat, hogy a FireWire hub-hoz csatlakoztatott kliensek bármelyikének újraindítása esetén néhány másodpercig megáll az adatforgalom a hub összes portján, ugyanúgy, mint a Fibre Channel hubok esetében.

- Nem lehetséges garantált sávszélesség. A Fibre Channel rendszerekben a management szoftverek segítségével lehetséges fontosabb kliensek és partíciók számára garrantált sávszélességet biztosítani.

- Nincs management szoftver. Igen korlátozottak a management lehetőségek, gyakorlatilag csak a hozzáférés szabályozására van lehetőség

- Nincs redundancia. Általában még a diszktömb RAID védelme sem lehetséges. Legfeljebb a HUB duplikálható, de a cseréje a rendszer teljes leállítása után lehetséges csak.

-

További lehetőség az Ethernet (akár 100, akár 1000 Mbps) alkalmazása. Ilyen rendszer az Avid LANShare termékcsaládja. Az Avid az egyszerű Ethernet hálózatot és Cat 5. kábelezést úgy használja, mintha az Fibre Channel rendszer lenne. Így igen olcsón jelentős megosztott kapacitás építhető ki. A LANShare egyidejűleg 10 DV (vagy nagyobb tömörítésű offline) tömörítésű kliens használatát teszi lehetővé, egyszerű Cat. 5 kábelezés használatával Fast Ethernet hálózaton keresztül. A dual processzoros File Manager CPU egybe van építve a 640 GB kapacitású IDE (SCSI-IDE bridget használó) háttértárral, üvegszálas Gigabites SX uplinken keresztül csatlakozik a 24 portos Ethernet switchhez, melyre a kliensek is csatlakoznak. Ugyanaz a File manager alkalmazás, az Avid Unity rendszere fut, mint a nagy Fibre Channeles Unity rendszereken, nem operációs rendszer végzi a megosztást, ezért nem kliens – szerver architektúráról beszélünk. A Unity szoftver biztosítja a kliensek számára a garantált sávszélességet is, ugyanúgy, mint a Fibre rendszereken. RAID védelem is lehetséges. Tartalékolási lehetőség korlátozott.

Eggyel nagyobb testvére a LANShare EX már kombinálni tudja a Fibre, a Gigabit és a Fast Ethernet klienseket és így egészen nagy kapacitású és kliens számú megosztott háttértáras munkacsoportok alakíthatók ki. Itt is az előzőekben már megismert Unity szoftver fut.

5. ábra: LANShare EX Ethernet switch-csel

A szintén dual processzoros CPU már 1.92 TB IDE (itt is SCSI-IDE bridget használ) háttértárral van egybe építve. A hírek szerint nemsokára megjelennek majd a 2.88 Terabyte, 3.5 Terabyte alapkapacitású rendszerek is. A merevlemezek mellett még három PCI buszos két csatornás Fibre Channel interfész kártya is helyet kaphat a gépben. Így switch nélkül is 6 Fibre Channel kliens csatlakoztatható a rendszerhez vagy külső, Fibre csatlakozást használó további háttértárakkal bővíthető. A jelenleg kapható LANShare EX maximális kapacitása így 3 TB lehet. Ebben a konfigurációban az egyidejű DV vagy offline kliensek száma akár 26 is lehet. A rendszer rendelhető 24 - portos Fast Ethernet vagy 12-portos Gigabites Ethernet switchekkel is. A 6. ábrán látunk erre az alkalmazásra példát.

6. ábra: LANShare alkalmazási példa helyi televíziós szituációban

Ez utóbbi konfiguráció egyedülálló a televíziózás világában. Amennyiben a kliens gépeket ellátjuk az Alacritech Gigabites Ethernet kártyáival, akkor gyakorlatilag teljesen Fibre Channel funkcionalitású rendszert kapunk. Az Alacritech kártyák ugyanúgy viselkednek, mint a FC kártyák, mert egyedüliként az Ethernet kártyák között, nem a CPU kell, hogy elvégezze az IP paketek csomagolását, hanem, mint az a Fibre rendszerekben történik, a hálózati kártya végzi ezt el. Így a CPU terhelése teljesen elhanyagolható és sokkal nagyobb gyakorlati sávszélesség érhető el a rendszerben. Különösen fontos ez a veszteségmentes tömörítésű vagy tömörítetlen anyagok kezelése esetén.

A Fibre Channeles rendszerek egy része kiegészíthető még Port szervereknek nevezett eszközökkel. Ezek teszik a Fibre rendszert láthatóvá más, egyszerű Ethernet hálózatot használó, nem video hanem archiváló vagy grafikus vagy esetleg valamilyen MPEG enkódolást végző, garantált sávszélességet nem igénylő kliensek vagy további munkacsoportok felé. Ennek részletes ismertetése meghaladja ezen írás kereteit, de talán az 7. ábra jó képet adhat a lehetőségek széleskőrű és rugalmas mivoltáról.

7. ábra: Media Network

8. Néhány tanács kezdőknek.

- Bízzuk magunkat tapasztalt szakértőkre. Habár a Fibre Channel elég jól szabványosított rendszer és a SAN is elég jól ismert informatikai architektúra, mégis nagyon könnyen lehet egymással nem tökéletes harmóniában működő rendszerelemekből építkezni. Akár sok milliósat is lehet tévedni.

- A fentiek függvényében lehetőleg olyan gyártótól válasszunk eszközt, aki maga szállítja a megosztott háttértáras rendszert és a rátelepítendő alkalmazást is. Akkor lényegesen nagyobb az esély, hogy komoly tesztelésen esett át a megvásárolni akart konfiguráció. Lehet, persze, hogy ez drágább lesz, mint válogatni a gyártók között.

- Mindíg legyünk azzal tisztában, mit akarunk csinálni. Szánjunk időt a munkafolyamataink kigondolására.

- Ha 1:2 dual streames vagy ne adj’ Isten dual streames tömörítetlen rendszerekből akarunk többet is megosztott háttértáron használni, különösen gondosan járjunk el. Itt már olyan nagy sávszélességekről beszélünk, ahol a tervezés és a rendszer elemeinek megválasztása kiemelt fontossággal bír.

- A háttértár nemcsak tárolásra kell. A merevelemezek biztosítják a sávszélességet az alkalmazások és a rendszer számára alapvetően. Amit ők nem állítanak elő, azt elosztani sem lehet.

- Ne lepődjünk meg, ha az általunk tervezettől a gyártó lényegesen több háttértárat akar eladni. Ez nem a gyártók eredendő gonoszságának vagy kapzsiságának köszönhető. Ők tudják, hogy sokszor a gyakorlatban lényegesen nagyobb számú hard diszkkel biztosítható csak üzembiztosan a kívánt sávszélesség. Különösen igaz ez a tömörítettlen video vagy a video szeerverek esetében.

- Ügyeljünk a kábelezés minőségére. Idehaza kevesen vannak, akik megbízhatóan tudnak üvegszálas rendszereket szerelni. Soha ne felejtkezzünk el a szerelés után megméretni és ellenőrizni a csatlakozásokat.

- Ne installáljunk a PC-re lehetőség szerint csak olyan alkalmazást, amit a gyártó jóváhagyott. Egy Photoshop is előre nem látott bonyodalmat tud okozni.

- Ne terheljük a rendszert lehetőleg kicsi, pár tíz- vagy száz kilobájt méretű file-ok használásával. A megosztott háttértáras rendszerek kifejezetten nagy file-ok kezelésére optimalizáltak, komoly problémát jelenthet, ha nem így teszünk.

- Ne internetezzünk és ne emailezzünk lehetőleg a rendszer egyetlen eszközével sem, de különösen ne a File Managerrel. Egy vírus miatt több terabájtnyi médiát elveszíteni nagyon kellemetlen tud lenni.

- Ne nyúljunk feleslegesen a File Managerhez. Ne kisérletezzünk. Ne állítgassuk át az adminisztrátori jelszót. Ha változtatunk, akkor a változásról valahol tegyünk le valamilyen emlékeztetőt.

- Győződjünk meg a kliensként használt gépek operációs rendszereinek korlátairól. Egy Mac OS 8 operációs rendszert használó kliens gép nem tud majd mit kezdeni egy 10 Terabyte – os partícióval, mert ez sokkal nagyobb, mint amit kezelni tud. Ha 4 GB-os partíciónként kell felmountolnunk a kliens gépen, akkor mintegy 2500 partíciót látnánk.

- Szintén fontos meggyőződni a File Manager media management korlátairól. Van olyan nagy nevű gyártó által árult megosztott háttértáras rendszer, amelyik pár tízezer file-t láthat csak egyszerre. Ha ebben a rendszerben mondjuk egy 1 órás animációt teszünk a megosztott háttértárra, ami 90.000 framet (90.000 grafikus file-t) jelent, akkor komoly problémánk lesz.

- Csak olyan eszközök anyagait érdemes megosztani, amelyek egymással kompatibilisak. Sokszor nem elég a media kompatibilitás, szükséges a projekt kompatibilitás is az igazán hatékony munkához.

- Ne építsünk redundancia nélkül rendszert, ha adásba is akarunk játszani a megosztott háttértárról. Ha nem is építünk teljesen tartalékolt rendszert, de egy merevlemez, egy Fibre Channel interfész kártya mindíg legyen a raktárban.

- Próbáljunk olyan helyet találni, ahol már használják, amit meg akarunk venni. Faggassuk ki az ott dolgozókat, de ha lehet ne azt, aki a döntést hozta, inkább azokat akik naponta dolgoznak rajta.

- És végül: ne felejtsük, hogy tartalékolás nélkül előállhat a Mindent vagy Semmit helyzetből a Semmi állapota, ha figyelmetlenek vagyunk.

Ujságcikkekhez vissza

További információ:

Penna-Média Kft.

Budapest

Törökvész u. 95-97/D

T: 325 8772

F: 325 9430