| Název: | Distribuce softwaru pomocí ZENworks |
| Autor: | David Čečelský |
| Publikováno: | Connect 8/2000, strana 77 |
V minulém čísle časopisu Connect! byl zveřejněn článek o produktech ZENworks, konkrétně o dvou nových přírůstcích v této řadě produktů - ZENworks for Servers a ZENworks for Networks. V tomto článku se zaměříme na nejzajímavější část produkt ZENworks for Servers (dále ZfS), kterou je elektronická distribuce software TED. Ve výše zmíněném článku byly popsány důležité NDS objekty - Distribution,Distributor, Subscriber,Channel, Server software package, se kterými systém TED pracuje a základní popis jeho funkce. Nebyla zde však zmínka ještě o jedné zbývající komponentě, kterou je objekt Proxy. Protože i tento prvek má při konfiguraci elektronické distribuce svůj velký význam, vysvětlíme si, k čemu se používá.
Objekt Proxy
Jedná se o NDS objekt představující NLM agenta, který běží na NetWare serveru a zprostředkovává službu proxy. Proxy služba spočívá v přijetí distribuce (Distribution) a informací od Subscriber a Distributor serverů a v jejich dalším zpracování.
Situaci si popišme pomocí následujícího obrázku. Představme si dvě lokality vzájemně propojeny pomalejšími linkami. V jedné lokalitě, kterou můžeme nazývat centrála, se nachází hlavní NetWare server, který je z hlediska ZfS nakonfigurován jako Distributor. Ve druhé lokalitě se nachází soustava NetWare serverů, na kterou budeme chtít distribuovat software. Nakonfigurujeme si tedy jeden ze serverů jako Proxy, ostatní budou v roli Subscriber. Distribuce software (balíčku SSP, souborů apod.) určená pro všechny servery vzdálené lokality pak bude putovat směrem k Proxy serveru, který je dále rozdistribuje na všechny Subscriber servery dané lokality. Znamená to tedy, že distribuce projde kanálem (v našem případě po síti WAN) pouze jedenkrát a ne tolikrát, kolik máme v dané lokalitě serverů. To je jistě velmi podstatný rozdíl, neboť např. dnešní SupportPack balíky pro systém NetWare 5 mají již stovky MB. Každý si lehce spočítá, že úspora komunikace je v tomto případě nezanedbatelná.
Konfigurace Proxy
Umístění Proxy serverů v rozlehlé síti je však potřeba plánovat velmi uvážlivě. Nejprve je nutné pochopit, jaký je algoritmus vyhledání Proxy serveru na síti před jeho vlastním využitím. Jakmile Subscriber server vznese požadavek na distribuci, distribuční server provede sérii dotazů do NDS na nejbližší Proxy server. Adresářový strom je prohledáván od kořene, tj. od objektu [Root] a porovnávají se plná jména objektů DN (Distinguish Name), kdy se vypočítává tzv. "fractional score". Podrobněji se výpočty zabývat nebudeme, neboť to není podstatné. Jakmile je nalezen Proxy server, vznese se dotaz, zda není ještě bližší Proxy server a takto pokračuje proces, vedoucí k nalezení nejvhodnějšího kandidáta na službu proxy. V TED architektuře znamená ovšem nejbližší (nebo nejvhodnější) kandidát ten server, který je vhodně umístěn ve stromě NDS, nikoli fyzicky nebo geograficky. Nerespektuje-li tedy design stromu NDS geografické uspořádání sítě, může být takováto volba Proxy serveru velice nesprávná.
Subscriber si dojedná a nastaví nejvhodnější Proxy server při svém prvním startu. Další dohledávání probíhá pouze v případě, kdy například dojde k odstranění objektu Proxy z NDS, změní se počet Proxy objektů, neshodují se Proxy List Revision Number hodnoty u objektu Subscription s hodnotami Proxy nebo Distributor objektů apod.
Z uvedeného popisu vyplývá, že konfigurace může být opravdu složitá. Navíc je třeba vzít v úvahu, že některé servery mohou plnit funkci Proxy a zároveň jsou nakonfigurovány jako Subscriber. To ovšem platí pro servery NetWare 5, neboť nižší verze NetWare nepodporuje současné zavedení více agentů. Samozřejmě je možná i konfigurace Distributor/Subscriber, to záleží na potřebách administrátora. Struktura může vypadat tak, jak je uvedeno na následujícím obrázku.
Na tomto obrázku je znázorněna situace, kdy jeden Proxy obsluhuje 3 servery typu Subsriber. Výkonnostní možnosti systému jsou však takové, že jeden Distributor, nebo Proxy server, může obsluhovat až 40 serverů typu Subscriber. Z toho také vyplývá, že jeden distribuční server může maximálně obsluhovat až 1600 serverů (40 x 40).
Velmi vhodné je také nastavit u Proxy serverů, kolik bytů za sekundu mají servery při přenosu přijímat, s ohledem na velikost přenášené informace. Jinými slovy můžeme velmi přesně určit rychlost přenosu a zamezit tak zahlcení použité komunikační linky.
Komprese a archivace
Je nutné také zmínit možnosti komprese a archivace dat, posílaných prostřednictvím systému TED. Je to další rys, který významným způsobem šetří komunikační nároky celého procesu distribuce. Pojem komprese snad není pro nikoho neznámý, řekněme si spíše něco o archivaci. Při tvorbě jakékoli distribuce (Soubor, skupina souborů nebo SSP) si distribuční systém vytvoří archiv této distribuce. Je to užitečné zejména proto, že přenos na cílové servery nemusí být z mnoha důvodů uskutečněn, nebo dokončen. Také se může stát, že přenos proběhne bez chyb, ale během přenosu je soubor poškozen a je na cílovém serveru nepoužitelný. Z uloženého archivu je možné proces kdykoli opakovat, aniž bychom museli distribuci definovat znovu.
"Patching"
Tento rys systému TED je určen k práci s obsáhlými distribucemi. Vezměme si příklad, kdy distribuujeme množinu souborů o velikosti 50 MB. Některé z těchto souborů ve zdrojové lokalitě podléhají změnám a tudíž je nutné distribuci provádět často a mnohdy je změna záležitostí pouze několika málo MB. Proč tedy znovu posílat po linkách 50 MB ? Distributor je natolik chytrý, že si udržuje kopii provedené distribuce a má tedy možnost provést porovnání. Na základě tohoto porovnání je pak na cílové servery poslána pouze ta část dat, kde došlo k nějaké změně.
Navíc distribuce, označené jako "Patche" mají jeden zajímavý bezpečnostní rys (Fault Tolerance), který funguje následovně. Je-li v momentě času distribuce Subscriber server vypnutý, nemůže pochopitelně distribuci obdržet. Při zapnutí se však server doptá svého nejbližšího Distributor/Proxy serveru. Na Proxy serverech je také k dispozici kopie poslední distribuce, není tedy nutné kontaktovat distribuční server a provádět nový přenos. Subscriber si navíc uloží u distribuce typu Patch číslo verze. Pokud se například stane, že cílový server přijde z různých důvodů o několik distribucí, může provést dotaz na Subscriber server, který mu sdělí, jaké soubory potřebuje pro nejaktuálnější verzi.
Checkpoint Restart
Tento další bezpečnostní rys jistě mnozí znají z prostředí inteligentních FTP klientů, stahujících velké soubory z Internetu. Jde totiž o zotavení po navázání spojení v průběhu distribuce. Je lina příklad přerušena distribuce 100 MB balíčku v momentě, kdy je již přeneseno 99 MB, pak po zotavení dojde ke stažení onoho jednoho chybějícího MB dat.
Rollback
Protože i administrátoři, kteří definují a vytvářejí distribuce, jsou jenom lidé, mohou se samozřejmě dopustit chyb. To má za důsledek, že se na mnoho serverů vyexpeduje něco, co úplně správně nefunguje. Pro tyto případy je k dispozici funkce "Rollback", která nám umožňuje návrat do původního stavu. Toto bude provedeno automaticky, pokud instalace balíčku proběhne nekorektně ,nebo pokud není distribuce z nějakého důvodu (chyby apod.) doinstalována. Máme však možnost ručního spuštění této funkce kdykoli, tj. i v případě, kdy instalace byla zcela v pořádku a software je funkční.
A co bude dál...
Na letošní konferenci BrainShare ve Spojených státech byla demonstrována další verze TED, která bude umět distribuovat na cílové počítače celý operační systém. Hovořilo se nejen o klientských systémech (Windows 95/98, Windows NT/2000 apod.), ale i o serverových platformách (např. Linux). Příjemně šokující byla zejména informace, že tato distribuce a celý proces přípravy "holé" stanice k použití bude trvat pouze několik minut ! Nabízí se otázka, odkud pochází tato technologie, která posune tento systém o značný kus dopředu? Každopádně se máme určitě na co těšit, neboť světlo světa by měla tato verze spatřit ještě v tomto roce.
