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.

12 Comments

  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: azt én is sejtettem, hogy a megosztásra ment, de nem tudtam az RW lokkot. Így azt hittem, hogy egyik módosíthat, míg a másikon nyitva van. De így már világos.

  10. @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…

  11. @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… :)

  12. Ja, persze tavmunka. Hat, akkor ez is egy felesleges feature. Inkabb a tobbeves csontvazakat rugdalnak mar ki a szekrenybol.

Leave a Reply to Asteriksz Cancel reply

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

Discover more from MiVanVelem

Subscribe now to keep reading and get access to the full archive.

Continue reading