Lurdy

Még mindig kutyafuttában, mert borzasztóan nincs időm. Már megint.

Nagyon későn feküdtem, nagyon korán keltem – nem a legjobb előjelek egy Lurdy-házas Technet esemény előtt. A bevezető marketingszósz alatt simán el is aludtam.

A keynote technológiai mélységeket nem fenyegetett, de meglehetősen impozáns volt. És istenkisértés is egyben. Amennyi eszköz hadrendbe volt állítva, mind-mind elsőrendű játékszer a demóisten számára… szerencsére ma nem nézett be. (Bár hallottam róla, hogy reggel hétkor egy teljes áramszünet szinezett ősz csíkokat a csapattagok frizurájába. Már akinek van olyan.)

Igazából az első szünet után tértem magamhoz, szerencsére pont időben. Szép-szép a Windows7 (tényleg tetszik), de a magamfajta szívét a szerveroldal dobogtatja meg. A branchcache és a directaccess jópofa technológiák. Annyit tennék hozzá – laikusként – az előadáshoz, hogy a branchcache ránézésre inkább read-only dokumentumok (vezig utasítások, dokumentumtár, ISO doksik, DSL(1)) disztributálására lehetett kitalálva, hiszen ránézésére nincs megoldva a dokumentum lockolása a több forrású módosítás ellen.

(1) DSL (Definitive Software Library): A cég hivatalosan telepíthető szoftvereinek telepítő készletei.

A directaccess pedig szvsz ugyanúgy fog elvérezni, mint az IPsec policy vagy a NAP: túl bonyolult, túl nagy az üzemeltetési kockázata. Hiába szép az elv, hiába hoz megoldást számos problémára – ha az IT csoport nem mer belevágni. Mondhatnánk, hogy semmi baj, itt a remek lehetőség a megoldásszállító cégek számára – de ha az ügyfél még az üzemeltetéstől is tart, akkor nem lesz bevezetés.

A továbbiakban már nem mertem kísérteni az Istent, ebédszünetben hazapályáztam. Zombiként dőltem be az ágyba, aztán most indul az éjszakai műszak.

This entry was posted in IT.

12 thoughts on “Lurdy

  1. Már miért ne lenne megoldva a BC-nél a lockolás…? A “leltárkönyv” a központi szerveren van, onnan szedi a jogosultságokat, oda írja a lockot is, említette is gt, hogy wan kapcsolat nélkül nem működik, nem éred el a lokális cache-t. Megnyitod, a látszólagos helyen (a központi file serveren) ellenőrzi a jogosultságot, bejelöli a lockot, majd a tényleges adatot a szomszéd workstationról szedi el, mert az gyorsabb… Módosítás után a mentés viszont már lassú lesz, mert nem a szomszédra ment, hanem az eredeti helyre… Amikor meg más akarja megnyitni a már módosított doksit másik telephelyről, hiába van már nála a lokális BC-ben, a hash különbdöző lesz, ezért lassan fog megnyílni, mert a lokális verzió már elavult (abban igazad van, hogy gyakori módosítás esetén elvész a BC előnye, mert mindíg frissíteni kell a lokális cache-t és ez lassú, de lockolási problémák szerintem nem lesznek)

  2. Én ilyen lockolási opcióra nem emlékszem. Oké, hogy leltárkönyv, meg hash, minden oké, amit írsz… csak éppen a lock nem.

    Utánanéztem:
    “BranchCache only pulls down data from headquarters as the need arizes; ie., only when the user requests it. Because it operates as a passive cache, it uses less bandwidth between headquarters and the branch. BranchCache only caches read requests, so it will never interfere with a user saving a file.
    http://windows7news.com/2009/10/06/how-to-use-branchcache-in-windows-7/

  3. Ezt mondom én is… :)
    Lockról azért nem volt szó, mert azt intézi a file szerver, függetlenül a BC-től… Amikor megnyitsz egy file-t a BC-ből, a lock az eredeti helyén keletkezik. Ezért kell hozzá mindíg az élő WAN…

  4. BB: erről volt egy kis eszmecsere Tamással, s ha változott az állomány, akkor sem lesz olyan hú-de-lassú a letöltés, mert csak a különbözetet szedi le (nem volt erre idő ezt is ecsetelni, de van annyira intelligens, hogy az “alapot” BC-ből, a különbözet meg a szerverről). Persze, amíg el nem avul a BC.

  5. @BB: Igazabol ezzel csak egy problemam van: a konkurens feluliras. Oke, leszedi Anton a sajat cache-be a doksit, megnyitja, ir mondjuk az A1 mezobe 25-ot. Leszedi Borisz is, es o az A1 mezobe 32-t ir.

    Mindketten elmentik: mi tortenik? Ha Antontol akkor tolti le a cuccot Borisz, amikor az meg issza a kavejat, akkor meg az A1 mezo eredeti tartalmat latja, es o boldogan modositja 32-re. Parhuzamosan vele Anton ugy gondolja, hogy oda 25 valo. Viszont ha mindketten a kozponti tarra mentenek, akkor az egyik felulirja a masik munkajat (most teljesen mindegy, hogy verziokezelt vagy sem: felulirja), viszont mindketten abban a boldog hitben vannak, hogy az o szamuk a nyero (gondolom a kliens a sajat cache-ukbol mutatja a valtozast). Van arra valami mod, hogy a kliens ertesuljon errol? Vagy eleve RW lockkal nyilnak meg a doksik? akkor mi tobbletet ad ez a sima fajlszerveres megosztashoz?

  6. Szerintem mentésnél azért van egy ellenőrzés, hogy nem-e változott az állomány időközben. S ha igen, akkor visszakérdez gondolom.
    Ami plusszt ad, az, hogy telephelyben kell gondolkozni, ahol nem olyan nagy a sávszélesség, s csak a különbözetek mennek ide-oda… Nem a teljes állomány.
    Ha mondjuk PDF-ekről van szó, ami lehet nagy méretű is, akkor már látszik…

  7. @hrongyorgy: eleve rw lockkal nyit. Ezt a funkciót az eredeti file server adja. A BC nem új fájlmegosztási módszer, hanem cache módszer, ami az adott share-en levő file gyorsabb elérését teszi lehetővé. A lockok és egyéb file dolgok (pl. jogosultság) kezelését az eredeti forrásnál (file share) hagyja, csak az elérést gyorsítja fel. Ezért kell a működéséhez az élő wan kapcsolat: ha az nincs, nem engedi a lokális BC-ben levő példány megnyitását, pont azért, mert nem tudja, más megnyitotta-e RW-vel, vagy esetleg változtatta-e menet közben.
    A te példádnál: Anton megnyitja a file-t, amit a lokális BC-ből kap, mert igy gyorsabb. A megnyitáskor a BC megnézni az _eredeti helyen_, hogy van-e joga Antonnak megnyitni, más nem nyitotta-e meg, valamint hogy a BC-ben levő példány és az eredeti egyezik-e. Ha igen, megnyitja a lokális cache-ből, majd bejegyzi az _eredeti_ helyre, hogy a file-t Anton megnyitotta szerkesztésre. Anton beleír, közben Borisz is nyitná a file-t. Az ő telephelyén levő BC is megnézi az eredeti helyen a file-t, ellenőrzi a jogosultságot, majd látja, hogy Anton épp szerkeszti, tehát Borisznak már csak Read-only módon engedi megnyitni. UGyanúgy, mintha nem lenne BC és mindketten a lokális share-en érnék el a központban a file-t…

    “Akkor mi többletet ad ez a sima fájlszerveres megosztáshoz?” Sebességet. Nem a filekezelés módja változik, csak a file nem megy keresztül minden esetben a vékony WAN-on, hanem ha van rá lehetőség, a lokális cache-ből töltődik.

  8. Asteriksz: mentésnél nem a lokális cache-be ment, hanem az eredeti helyre. A következő megnyitáskor pedig minden BC-s telephely látja, hogy az eredeti változott és leszinkronizálja magához a változásokat.

  9. @BB: Aham, ez igy egesz jol hangzik. De ez akkor csak akkor jo, ha a head office-tol kell elkerni a fajlt, mert hiszen a branch office-nal sokkal gyorsabban es egyszerubben nyitja meg kozvetlen share megnyitassal… a branch office altal modositott head office-s fajlok meg nem tul suruek, szoval szerintem ellennenek akar e nelkul is… Nem tudom, en nem ertek hozza…

  10. @hrongyorgy: ellennének, de új koncepció van :-) (lásd pl directaccess…) Mindenki mobil, onnan dolgozik, ahonnan tud, ha többen tudnak ugyanabból a netkávézóból/kocsmából, már van jogosultsága a BC-nek… :)

Leave a Reply

Your email address will not be published. Required fields are marked *