Vállalati fájlmegoldások kihívásai

Egy nagyvállalati fájlstruktúrát kialakítani sokkal inkább szervezési, semmint technológiai kihívás. Talán pont ez az oka, hogy ilyet senki nem szeret csinálni. Pedig hát hol itt a gond? Lássunk párat:
Ha olyan mappastruktúrát akarok kialakítani, ami tükrözi a vállalat szervezeti felépítését, arra vannak nagyon jó bevált sablonok. Ha olyat akarok építeni, amelyik illeszkedik a vállalat földrajzi elhelyezkedéséhez, arra is vannak régi jó megoldások, és arra is, ha ki szeretném használni a már kiépített hálózati struktúra által biztosított előnyöket (vagy csupán illeszkedni szeretnék a meglévő adottságokhoz.) De ha valaki olyan struktúrát szeretne, amelyik a fenti kívánalmaknak egyszerre felel meg, és akár támogatja a felhasználók mozgását is az egyes telephelyek között (bármelyik telephelyen is legyen, az adatait ugyanolyan gyorsan érje el, mint bárhol máshol), akkor bizony fel van adva a lecke és bizony nem lesz egyszerű megoldani.

Természetesen mindenre lehet találni megoldást, aminek az eredménye egy szinte már átláthatatlan bonyolultságú mappastruktúra, ami redundánsan tartalmaz adatokat, számos redundáns fájlkiszolgáló (nagy áramfogyasztással, hardver és licenszköltségekkel), akik egymással állandó replikációs kapcsolatban állnak és folyamatosan terhelik a hálózatot, és végül külső beszállítók drága szoftverei segítettek abban, hogy az archiválandó adatokat más helyen tárolhassuk.
A fenti problémákra az eddig használatos eszközkészlettel nem lehetett kielégítő megoldást találni, ezért a Windows Server 2008 R2-ben számos olyan újítást és teljesen új technológiát fejlesztettek ki, amelyek a meglévő legégetőbb problémákra tökéletes megoldást nyújtanak.

BranchCache és a vándorló felhasználók
A legnagyobb problémát fájlrendszerek tervezésekor a kisméretű, lassú adatkapcsolattal rendelkező telephelyi adatok kezelése és a telephelyek között vándorló felhasználók fájlhozzáféréseinek a gyors megoldása okozza. Ennek kezelésére eddig meglehetősen jó megoldás volt az Offline fájlok használata, a Windows 7-ben a transparent caching-gel már szinte tökéletes megoldásnak lehetne mondható, de szerencsére még ezt is lehetett tovább fokozni.
Tegyük fel, hogy van két munkaállomás egy olyan telephelyen, ahol nincs helyi fájlkiszolgáló. Az egyik munkaállomás megnyit egy fájlt a központi fájlkiszolgálóról, az lecsorog a WAN vonalon, és máris olvasható/módosítható. Ekkor a másik munkaállomás is meg szeretné nyitni ugyanazt a fájlt a központi fájlkiszolgálón. Mi történik, ha régi fájlkiszolgálónk van? Ugyanaz, mint a másiknál, a fájl a központból megint lecsorog a WAN vonalon, és utána lehet dolgozni vele. Mi történik, ha Windows Server 2008 R2 van a fájlkiszolgálón, Windows 7 a klienseken és be van kapcsolva a BranchCache funkció ezen a környezeten? Akkor a Windows 7 kliensek fájlmegnyitás előtt mindig megkérdezik a velük egy telephelyen (AD site-ban, IP alhálózaton) lévő munkaállomásokat, hogy ez a fájl nincs nálatok véletlenül? Ha igen, akkor add ide légy szíves (már ha van a fájlhoz egyáltalán jogom), nem akarom a WAN vonalon letölteni. Vagyis a második esetben már nem terheltük a WAN vonalat, de a második kliens is megnyitotta a fájlt. Ezzel a megoldással az eddigi tapasztalatok szerint fájlhasználati szokásoktól függően 40-70%-kal csökkenthető egy kis telephely WAN hálózati forgalma!
Ezt még úgy tudjuk fokozni, hogy elhelyezünk itt egy kiszolgálót, aki ugyanezt a BranchCache funkciót végzi el, csak nagyobb a tárterülete (így a cache, vagyis az átmenei tároló mérete is, mint a munkaállomásokénak), ebben az esetben a kliensek nem egymást, hanem a cache kiszolgálót kérdezgetik, cserébe minden, a WAN kapcsolaton letöltött fájlt odaadnak neki a cache-be megőrzésre.
Igen, itt használtunk egy kiszolgálót. Viszont nem kell adminisztrálni, csoportházirendből megadható, hogy ez a kiszolgáló ennek a területnek a BranchCache kiszolgálója, mindenki ide forduljon. Nem kell a kiszolgálón megosztásokkal bajlódni, DFS kapcsolatokat adminisztrálni, fájlstruktúrákat gondozni. Amihez a központban joga van egy felhasználónak, azt tudja a BranchCache kiszolgálón is elérni.
 

FCI, az új varázsszó
Van két számos olyan probléma, ami a rendszergazdák életét nagyon megnehezíti, ez pedig a fájlok besorolása különféle szempontok szerint. Például szeretnék minden olyan fájlt, ami 3 hónapnál idősebb és 10 MB-nál nagyobb, tömörítve, olcsó, lassú tárhelyen tárolni. Ez még nem is olyan nagy kihívás, pár óra és megvan vele az ember. De ha azt kérik, hogy minden olyan dokumentumot, ami üzletleg titkos adatokat tartalmaz, azokat titkosítsd Rights Management szolgáltatással és csak olvasásra legyen elérhető. De honnan tudom, hogy titkos adatot tartalmaz? Hát onnan – mondják – hogy bele van írva, hogy Titkos valahol a dokumentum elején. Ez igazi lehetetlen küldetés, de az üzletnek ez csak egy egyszerű elvárás, nem tudhatják, mekkora adminisztratív munkát jelent ez, már ha egyáltalán megoldható. Nagyon gyakran más gyártók célirányos termékei sem tudják ezt.
Ezeknek a problémáknak a gyors, egyszerű megoldására került a Windows Server 2008 R2-be a File Classification Infrastructure (FCI – fájl besoroló/osztályozó infrastruktúra). Az FCI lényege az, hogy lehetővé teszi, hogy a fájlok elhelyezkedésétől, tulajdonságaitól vagy tartalmuktól függően különféle paraméterekkel felruházhatók, besorolhatók, majd később ezen tulajdonságok alapján különféle műveletek végezhetők velük. Például amelyik fájl tulajdonosa a vezérigazgató, az automatikusan titkosításra kerül, vagy amelyikben szerepel a felvásárolni szó, akkor azokhoz hozzá kell rendelni a kereskedelmi osztály munkatársait olvasási joggal, és erről őket értesíteni is kell emailben. Igazából tetszőleges fájlbesorolási esetet elképzelhetünk, azt nagy valószínűség szerint a termék végre tudja hajtani, de ha nem, akkor publikálva van a termékhez egy API, amin keresztül beilleszthetjük a saját megoldásunkat, de már számos cég készített olyan megoldást, amelyek különleges üzleti igényekre adnak megfelelő megoldást.
Fontos megjegyezni, hogy a besorolt fájlok a besorolási paraméterüket, „bélyegüket” megőrzik, magukkal viszik akkor is, ha az addigi helyről elkerülnek. A besorolási paramétereket csak a fájlkiszolgáló adminisztrátora tudja eltávolítani.

Replikációs újdonságok
A DFS technológia rengeteg olyan könnyítést hozott a rendszergazdák életébe, amelyek korábban komoly fejfájásokat okoztak. Például nem lehetett több fájlkiszolgáló megosztásait egységes mappaszerkezetbe illeszteni. De azért pár elvarratlan szál még mindig maradt. Komoly teljesítményproblémák adódtak olyan igazán nagyméretű DFS fájlrendszerekben, amelyek akár több ezer megosztás linkjeit tárolták. Az Windows Server 2008 R2 fájlszolgáltatásában tesztelték, hogy több mint 1,3 millió megosztáslinket is képes kezelni érdemleges teljesítménycsökkenés nélkül.
Másik komoly probléma volt a DFS infrastruktúra nagy rendelkezésre állásúvá tétele. Volt egyfajta megoldás, hiszen megadhattunk több kiszolgáló, akik kiszolgálják a DFS-N-t, vagyis a DFS névteret, de ha át kellett állni egyik pillanatról a másikra egyik kiszolgálóról a másikra plédául hálózati hiba miatt, akkor a replikációs kapcsolatokat a rendszergazdának manuálisan kellett reset-elni. Az R2-ben a DFS infrastruktúra elemei már igazi fürtökbe rendezhetők, ami valós magas rendelkezésreállást biztosíthat, sőt egy replikált DSF mappa már fürtözött erőforrásként is szerepel, így akár replikált mappánként megadható, hogy a fürt melyik kiszolgálója melyik mappa kéréseit szolgálja ki.
Fontos újítás a csak olvasásra használható DFS kiszolgáló (Read-only DFS) amely tartalma nem módosítható vagy törölhető, függetlenül attól, hogy a mappa vagy fájl eredeti helyén a felhasználónak joga van annak a módosítására. Ezzel a megoldással a DFS-en tárolt adatokat egyszerűen tudjuk felkínálni olvasásra anélkül, hogy a módosítási jogokat el kellene vennünk a felhasználóktól, és megoldottnak vehetjük a véletlen fájltörlés azonnali replikációját a DFS rendszerünkben.

Együttműködés más platformokkal
Vállalati fájlrendszert heterogén fájlkiszolgálók felhasználásával építeni nagyon nehéz, mert számos limitációval kellett eddig szembenézni: nem voltak támogatva a Unix netgroup-ok, az NFS távoli menedzsmentje nem volt támogatott, és a Windows és Unix felhasználók összerendelési is csak a Unix klienseken és NFS alapú hozzáféréssel volt támogatva. A Windows 7 és a Windows Server 2008 R2 megjelenése nagymértékben bővítette a különböző platformokal történő együttműködés lehetőségét. A NIS-ben konfigurált és az RFC 2307-nek megfelelő netgroup-ok már adminisztrálhatók az NFS-en keresztül, és támogatott a Kerberos 5 és Kerberos5 integrity alapú hitelesítés NFS alatt is.
Mit jelent mindez nekünk? Ezentúl a Windows Server 2008 R2 alapú fájlszolgáltatás lehet kiszolgálója Unix, Lunix, MacOS, Windows klienseknek, Unmapped Unix User Access (UUUA) felhasználásával tárolóplatformja lehet az előzőekkel együtt még Sun Solaris NFS klienseknek is.

Összegzés
Az R2 és a Windows 7 új fájltárolási megoldásai nagyon sok terhet le tudnak venni a rendszergazdák válláról, sokkal gyorsabb felhasználói élményt biztosítanak különböző platformú felhasználóknak egyaránt, de ehhez nélkülözhetetlen a jelenlegi fájlrendszerek tudatos, az R2 képességeire alapozott rekonstrukciója. A fájl- és mappa tervezésénél ezentúl nem kell tekintettel lenni a telephelyi elrendezésre vagy a vándorló felhasználókra: a BranchCache és Transparent Caching technológia biztosítja a felhasználók fájljainak gyors elérését a központban, a telephelyeken és ezek között vándorolva egyaránt.