PowerShell 2.0 Dohledování serverů

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

PowerShell 2.0 – Dohledování serverů Diplomová práce

Autor:

Bc. Tomáš Hypš Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš Petrovický

duben, 2012

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen/a se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 23.4.2012

Tomáš Hypš

Poděkování:

Děkuji vedoucímu práce panu inţenýru Vladimíru Benešovi, za jeho přístup a vedení diplomové práce. Dále děkuji své manţelce Veronice za velkou podporu, prostor a toleranci.

Anotace práce Tato diplomová práce na téma PowerShell 2.0 – Dohledování serverů se zabývá novými funkcemi skriptovacího prostředí Windows Powershell 2.0 a analyzuje jejich funkcionalitu. V praktické části dojde k volbě metodiky, návrhu a vývoji dohledovacího nástroje běţícího v představeném skriptovacím prostředí a na závěr k vyhodnocení testovacího provozu v reálném prostředí banky. Klíčová slova: PowerShell 2.0, WMI, vzdálená správa, skriptování, skriptovací prostředí, dohledování serverů, monitoring, klient-server, metodiky vývoje, UP

Annotation This thesis on the topic of PowerShell 2.0 – Server monitoring analyses new features of the Windows PowerShell 2.0 scripting environemt and their associated functions. In the practical section, a methodology will be selected, and the server monitoring tool which runs in this scripting environment will be designed and developed. In conclusion, the test operation will be evaluated in the context of a real-life banking environment. Keywords: PowerShell 2.0, WMI, remote management, scripting, scripting environment, server monitoring, client-server, development methodologies, UP

Obsah ÚVOD ..................................................................................................................................................................... 7 ZVOLENÉ METODY ZPRACOVÁNÍ............................................................................................................... 8 1

NOVÉ FUNKCE JAZYKA OPROTI POWERSHELLU VERZE 1.0 ................................................... 9 1.1

POWERSHELL 1.0................................................................................................................................... 9

1.2

POWERSHELL 2.0................................................................................................................................. 10

1.2.1

Instalace a konfigurace Powershell 2.0 ....................................................................................... 11

1.2.2

Vzdálená správa ........................................................................................................................... 12

1.2.3

Spouštění úloh (Jobs) na pozadí ................................................................................................... 18

1.2.4

Nové příkazy a funkce WMI .......................................................................................................... 20

1.2.5

Get-WinEvent ............................................................................................................................... 23

1.2.6

Výstup do grafického Gridview .................................................................................................... 24

1.2.7

Zpracování událostí ...................................................................................................................... 27

1.2.8

Transakce ..................................................................................................................................... 30

1.2.9

Moduly.......................................................................................................................................... 32

1.2.10

Windows powershell ISE .............................................................................................................. 33

1.2.11

PowerGUI script editor ................................................................................................................ 34

1.2.12

Další rozšíření a podpora služeb Windows .................................................................................. 34

1.3 2

POPIS REÁLNÉHO PROSTŘEDÍ BANKY A ZADÁNÍ POŽADAVKŮ NA PRODUKT ................ 36 2.1

3

SHRNUTÍ.............................................................................................................................................. 35

POPIS BANKOVNÍHO PROSTŘEDÍ .......................................................................................................... 36

2.1.1

Popis oddělení Application Servers Support ................................................................................ 37

2.1.2

Přehled činností oddělení správy aplikačních serverů ................................................................. 38

2.2

SERVERY ODDĚLENÍ SPRÁVY APLIKAČNÍCH SERVERŮ ......................................................................... 41

2.3

ZADÁNÍ VÝVOJE .................................................................................................................................. 41

VÝBĚR METODIKY VÝVOJE PRODUKTU ....................................................................................... 43 3.1

SPECIFIKA SKRIPTOVÁNÍ NEJEN V POWERSHELLU ............................................................................... 45

3.2

DOSAVADNÍ PŘÍSTUP K VÝVOJI SKRIPTŮ ............................................................................................. 45

3.3

VOLBA METODIKY .............................................................................................................................. 46

3.4

STRUKTURA METODIKY UP A JEJÍ ÚPRAVA ......................................................................................... 46

3.4.1

Fáze zahájení (inception) ............................................................................................................. 48

3.4.2

Fáze rozpracování (elaboration) .................................................................................................. 49

3.4.3

Fáze konstrukce (construction) .................................................................................................... 49

3.4.4

Fáze zavedení (transition) ............................................................................................................ 50

3.4.5

Úprava metodiky - dovětek ........................................................................................................... 50

3.5

POUŢITÍ NÁSTROJŮ .............................................................................................................................. 51

3.6

SHRNUTÍ.............................................................................................................................................. 51

4

VÝVOJ PRODUKTU ................................................................................................................................ 52 4.1 4.1.1

Požadavky..................................................................................................................................... 54

4.1.2

Návrh architektury ....................................................................................................................... 57

4.1.3

Neúspěšný test funkce ................................................................................................................... 58

4.1.4

Uživatelské rozhraní ..................................................................................................................... 60

4.1.5

Vyhodnocení fáze „Zahájení“ ...................................................................................................... 62

4.2

5

6

FÁZE „ZAHÁJENÍ“ ............................................................................................................................... 52

FÁZE ROZPRACOVÁNÍ .......................................................................................................................... 63

4.2.1

Server: modul Řídící cyklus ......................................................................................................... 64

4.2.2

Server: modul Spouštěč testů....................................................................................................... 65

4.2.3

Server: modul Vyhodnocovací modul ........................................................................................... 66

4.2.4

Server: modul Komunikační, pro posílání SMS ........................................................................... 67

4.2.5

Server: testy PING a UPTM ......................................................................................................... 68

4.2.6

Implementace testu DISK ............................................................................................................. 69

4.2.7

Sdílené úložiště: Struktura ............................................................................................................ 69

4.2.8

Klient: Řídící cyklus ..................................................................................................................... 71

4.2.9

Klient: Vyhodnocovací modul ...................................................................................................... 73

4.2.10

Klinet: Operativní modul.............................................................................................................. 74

4.2.11

Vyhodnocení fáze “Rozpracování” .............................................................................................. 75

NASAZENÍ PRODUKTU DO PROVOZU ............................................................................................. 76 5.1

SERVER ............................................................................................................................................... 76

5.2

KLIENT ................................................................................................................................................ 78

5.3

NÁMĚTY A ROZŠÍŘENÍ ......................................................................................................................... 78

VYHODNOCENÍ UŽITEČNOSTI PRODUKTU .................................................................................. 79

ZÁVĚR ................................................................................................................................................................. 80 SEZNAM POUŽITÉ LITERATURY ............................................................................................................... 82 SEZNAM POUŽITÝCH OBRÁZKŮ ................................................................................................................ 84 PŘÍLOHA Č. 1 .................................................................................................................................................... 86

Úvod Cílem této práce je vývoj dohledovacího nástroje pro servery běţící na platformě MS Windows v skriptovacím prostředí Windows PowerShell 2.0. Výběrem tohoto tématu, jsem chtěl reagovat na neuspokojivý stav dohledování serverů v naší organizaci a zároveň jsem chtěl navázat na mou původní bakalářskou práci, která se věnovala Windows Powershellu 1.0. V teoretické části diplomové práce seznámím odbornou veřenost s novými funkcemi a příkazy skriptovacího prostředí Windows Powershell 2.0. Při jejich popisu zároveň ověřím, jejich funkcionalitu a dokáţi jejich vyuţití. V praktické části diplomové práce nejprve představím provozní prostředí bankovní organizace a vysvětlím i důvody pro zadání poţadavku na vývoj nového dohledovacího nástroje. Vyběr metodiky vývoje produktu přizpůsobím zadání, povaze a vlastnostem projektu stejně tak, jako vlastnímu skriptovacímu prostředí, ve kterém bude výsledný produkt spuštěn. Struktura upravené metodiky, postupy a doporučení vytvoří základní metodický rámec mého vývoje. Pouţitím analytických a návrhových diagramů jazyka UML spolu s praktickými ukázkami programového kódu Powershellu, vysvětlím činnosti jednotlivých modulů, čímţ završím vývojovou fázi. V závěru práce provedu spuštění nástroje na vybraném vzorku serverů v reálném provozu a zhodnotím tak jeho funkcionalitu, vhodnost výběru metodiky i úspěšnost celého vývoje.

7

Zvolené metody zpracování K teoretické části diplomové práce jsem zvolil dva přístupy. Na jednu stranu chci představit nové funkcionality skriptovacího prostředí Windows Powershell 2.0, na stranu druhou chci ale i prakticky ověřit jejich pravdivost. Nezřídka se totiţ stáva, ţe prezentované informace jsou v rozporu se skutečností a proto by mohly být mé testy zajímavým přínosem i v této teoretické části. Určit, kterým z nových příkazů a funkcí se budu v této práci věnovat, mi pomohl oficiální dokument „About Windows Powershell 2.0“[11], který je součástí nápovědy samotného skriptovacího prostředí. Přesto jsem z něj vybral jen ty novinky, které jsem původně chtěl vyuţít ve vývoji dohledovacího systému. V praktické části mé diplomové práce, vyuţívám pro vlastní vývoj metodiku unifikovaného vývoje aplikací a samotnému výběru metodiky zde věnuji celou 3. kapitolu. Vývoj dohledovacího nástroje je řízen upravenou metodikou UP, která vytvořila dobrý metodický základ pro celý vývoj, coţ i v závěru diplomové práce hodnotím.

8

1 Nové funkce jazyka oproti PowerShellu verze 1.0 1.1

Powershell 1.0

Představení skriptovacího prostředí Microsoft Powershell 1.0 bylo v roce 2006 dlouho očekávanou infůzí do světa automatizace úloh systémových administrátorů na platformě operačních systémů rodiny Microsoft Windows. Jedná se o prostředí příkazového řádku, kde nehraje prim vizuální stránka, ale rychlost a provázanost jednotlivých mechanizmů tohoto prostředí. Powershell je postaven na běhovém prostředí DotNet Framework (min. 2.0) a spolu s vyuţitím dalších funkcí a rozhraní operačního systému, jako jsou WMI (Windows Management Instrumentation) či COM objekty, utváří poměrně všestranný a kompaktní nástroj pro správu systémů MS Windows se silnou podporou automatizace administrátorských úloh. Jak popisuji a porovnávám ve své bakalářské práci [3], do té doby byla jednotlivá skriptovací prostředí buď příliš sloţitá, neţ aby se dala pouţít v rámci rychlé správy, nebo omezená v šíři svého pouţití. Skriptovací prostředí Powershell mne však jiţ tehdy přesvědčilo o svých moţnostech a pestrosti vyuţití a dá se říci, ţe tak celosvětově vyplnilo pomyslnou díru v oblasti automatizace rutinních činností a operativních úkonů systémových administrátorů na platformě operačních systémů rodiny Microsoft Windows. Jednoduchost, efektivita a rychlost jednotlivých příkazů v prostředí Powershell, alespoň co do srovnání s rychlostí standardními „klikacími“ cestami přes grafické uţivatelské rozhraní, či jinými skriptovacími jazyky, je nadmíru uspokojivá, a moţnosti snadného vyuţití rozhraní WMI konečně otevřelo cestu pro celou řadu i méně zkušených administrátorů. Velkou devizou Powershellu je taktéţ jednoduchá konstrukce podmínek, cyklů a deklarace proměnných. Všechny jmenované oblasti jsou přímo předurčeny k rychlému a snadnému pouţívání a obecně by se dalo říci, ţe konstrukce jazyka je v optimálním poměru sloţitosti a snadnosti pouţití. Nicméně hlavní trumf celého tohoto prostředí tkví ještě v něčem jiném. Je tím plná objektová orientace, respektive plné objektové prostředí. Všechna data, získávaná jednotlivými příkazy jsou v zásadě objekty se všemi vlastnostmi, metodami a funkcemi tomu náleţející. Powershell na rozdíl od standardních nástrojů OS Windows či aplikací

9

z administrátorských balíčků, jako např. Windows Resource kit, nepřevádí výstupy do textové formy, ale dále s nimi pracuje jako s objekty, coţ zcela změnilo pohled nejen na vlastní skriptování, ale i na způsob pohledu na systému jako takový. Nicméně přes všechny klady, které jsem výše uvedl, trpěl Powershell 1.0, coby mladý produkt, jistými chybami a nepochopitelnými omezeními. Zejména oblast vzdálené správy byla doslova tragedií. Podpora byla omezena víceméně pouze na pouţití rozhraní WMI, které je na jednu stranu velmi silný a všestraný nástroj, ovšem na druhou stranu, pro celou řadu úkonů, moţná aţ zbytečně sloţité. Nemám teď na mysli syntaxi pouţití, ale fakt, ţe mnohá data, získávaná z tohoto rozhraní, nejsou plně kompatibilní s daty uţívanými interními příkazy Powershellu a musejí být konvertována do akceptovatelných forem, coţ jen zesloţiťuje celou práci1. Pro administrátorskou obec tak byla skutečný překvapením absence parametrizovaného vzdáleného připojení u standardních příkazů, na které jsou uţivatelé MS Windows systémů zvyklí a které například zmiňnované rozhraní WMI má jiţ mnoho let. Odstranění tohoto nedostatku bylo slibováno do verze Powershell 2.0, kdy by za pomoci sluţby WinRM (Windows Remoting Management) bylo moţné dosáhnout právě vzdálené správy. V závěru své bakalářské práce jsem přesto vyzdvihoval sílu prostředí Powershellu a podal námět ke zkoumání této problematiky z pohledu dalších funkcí Powershellu, nejlépe ve verzi 2.0, se zaměřením na správu vzdálených systémů, popř. administraci operačních systémů MS Windows Server 2008 s podporou technologie Hyper-V[3]. A protoţe se navíc Powershellu, resp. skriptování v něm, věnuji a zatím si stále myslím, ţe je to prostředí, které má budoucnost, rozhodl jsem se navázat na svou bakalářskou práci a nejenom popsat nové prostředí Powershell 2.0, ale i jej pouţít při návrhu nového dohledovacího nástroje.

1.2

Powershell 2.0

Windows Powershell 2.0 je zpětně kompatibilní produkt, coţ znamená, ţe všechny příkazy, resp. cmdlety, a jejich funkce a metody které byly navrţeny pro Powershell 1.0

1

V tomto případě jiţ nemá cenu mluvit jen o samotných příkazech, protoţe v rámci získaných informací

z rozhraní WMI, musí dojít téměř vţdy k dalšímu zpracování a pro řádkové akční uţití je toto jiţ méně vhodné.

10

fungují i ve verzi nové. Celá řada „starých“ cmdletů doznala určitých změn, přibyly nové funkcionality více či méně rozšiřující působnost konkrétních příkazů a samozřejmě se objevily i příkazy zcela nové, reflektující očekávání a poptávku rychle vzrůstající administrátorské obce systémů MS Windows.

1.2.1

Instalace a konfigurace Powershell 2.0

Vlastní instalace Powershellu je určena pouze pro systémy MS Windows XP, MS Server 2003 a MS Windows Vista. Systémy MS Windows 7 a MS Server 2008. mají jiţ Powershell 2.0 implementován jako základní vybavení systému. Pokud pracujeme na OS Windows XP, je zapotřebí mít nainstalován opravný balík Service pack 3, který se dá nainstalovat jednoduše přes sluţbu „Windows update“, nebo ručně ze stránek společnosti Microsoft. Dále je potřebná verze .NET Frameworku minimálně 2.0 nebo vyšší. Pokud si nejsme jisti verzí, zjistíme tyto informace asi nejlépe z registru Windows, viz Obrázek 1. Obrázek 1.

Výpis instalovaných verzí .NET Framework a určení aktuální pouţívané

Zdroj: MALINA, Patrik. Jak vyzrát na Windows PowerShell 2.0[5]

Na stránce http://support.microsoft.com/kb/968929 [13] nalezneme

nejen všechny

instalační balíky pro Powershell 2.0, včetně podpůrných balíků WinRM či BITS 4.0, ale hlavně detailní popis co vše je potřeba pro instalaci, resp. před instalací udělat. Zkráceně, WinRM 2.0 a Powershell 2.0 se dá provozovt na následujících operačních systémech[13]: Windows Server 2008 with Service Pack 1, Windows Server 2008 with Service Pack 2, Windows Server 2003 with Service Pack 2, Windows Vista with Service Pack 2, Windows Vista with Service Pack 1, 11

Windows XP with Service Pack 3, Windows Embedded POSReady 2009, Windows Embedded for Point of Service 1.1. Zatímco vlastní instalace probíhá víceméně bez potíţí, alespoň co jsem měl moţnost ověřit na desítkách instalací, Microsoft překvapil hned v první věci s instalací spojenou a to s vlastním umístění nainstalovaných souborů. Tam kde bychom asi očekávali verzované umístění, se Powershell 2.0 nainstaluje automaticky do původní adresářové struktury. Obrázek 2.

Cesta k souborům Windows Powershell 2.0

Zdroj: Vlastní tvorba

Pro konfiguraci uţivatelských profilů, i nadále platí, ţe proměnná $profile je přednastavena a je potřeba provést vytvoření vlastního souboru, coţ se od původní verze nijak neliší. Pojďme se nyní podívat na některé z novinek, které pro nás programátorský tým společnosti Microsoft připravil. Jako inpirace nám pro výběr jednotlivých témat poslouţí interní dokument vlastního prostředí Powershellu About_Windows_Powershell_2.0 [11].

1.2.2

Vzdálená správa

Asi největším lákadlem nové verze skriptovacího prostředí Powershellu 2.0 byl proklamovaný Windows remoting, neboli vzdálená správa. Jak jsem jiţ zmiňoval v předešlých odstavcích, absence této sluţby v Powershellu 1.0 byla substituována rozhraním WMI, které pro přístup k jiným systémům vyuţívá jednoduchý parametr “-computername ”. Vzdálená správa v Powershellu 2.0 by se dala primárně rozdělit na čtyři kategorie. S vyuţitím WMI Bez vyuţití WinRM S vyuţitím WinRM interaktivním připojením S vyuţitím WinRM mimo interaktivní relaci Abychom si co nejlépe demonstrovali rozdíly v uţití vzdálené správy v kaţdé kategorii, provedeme výpis běţících procesů a naznačíme, jak můţeme dále tento výpis zpracovávat. Zajímavé také bude, zkusit přistoupit ke vzdálenému systému pod jiným uţivatelem, neţ pod jakým máme spuštěnu aktivní relaci. 12

S využitím WMI Pouţití rozhraní WMI se v pouţití příliš neliší od předešlé verze Powershellu 1.0. O změnách, které přinesl Powershell 2.0 do WMI budu mluvit v samostatné kategorii. Pro naši demonstraci vyuţijeme třídu Win32_Process a budeme rovnou hledat procesy s názvem powershellu na vzdáleném počítači. Příkaz bude následující: PS> Get-WmiObject win32_process –cn ap468288 –filter „name=‘powershell.exe‘“ | select-object –first 1 | fl *

Obrázek 3.

Výpis procesů Powershell.exe ze vzáleného počítače pomocí rozhraní WMI


Z obrázku je patrné, ţe nám rozhraní WMI zpřístupnilo poměrně slušné mnoţství informací o konkrétním procesu, včetně čísel spojených s vytíţeností paměti, procesoru a jiných informací o procesu na hostitelském systému. Co se týká dalšího zpracování, buď vyuţijeme metody třídy WMI, například metoda Terminate() je pro ukončení procesu, nebo získané informace zpracujeme dále ve skriptu a pouţijeme některý z níţe popisovaných způsobů WinRM. Ukázka ukončení procesu pomocí WMI je na obrázku 4.Další drobné nekompatibility se dají odstranit vhodně 13

zvolenou konverzí proměnné, například vyuţití časových informací z rozhraní WMI se musí převádět pomocí metody .ConvertToDateTime(). Teprve poté se dají vyuţít působivé časové funkce Powershellu. Obrázek 4.

Aplikace metody Terminate() na vzdáleném serveru


Rozhraní WMI nám nabízí ještě další zajímavou a v praxi často pouţívanou funkci. Přístup ke vzdálenému systému pod jiným uţivatelským jménem (credentials)2. Následující příkaz nás vyzve k zadání uţivatelského jména a hesla přes standarní zabezpečené windows grafické rozhraní. PS 1 Z:\DP > Get-WmiObject win32_operatingsystem -ComputerName ap468288 Credential $admin

1. Bez využití WinRM Jedná se o podobné řešení, jako u výše zmíněného WMI alespoň tedy co do pouţití jména vzdáleného systému v podobě parametru. Bylo pro mě zklamáním, ţe tuto funkcionalitu zabudoval programátorský tým pouze do tří příkazů, coţ z celkového počtu 236 příkazů, resp Cmdletů, je přinejmenším ostudné mnoţství. Get-Process Get-Service Get-Eventlog Pro ověření funkcionality tedy pojďme ověřit příkaz Get-Process a to v následujícím formátu: PS> Get-Process –cn ap468288 powershell* | select-object –first 1 | fl *

Z níţe uvedeného obrázku 5 je na první pohled patrná strohost výpisu a absence celé řady poloţek, které jsou však při výpisu z hostitelského počítače k dispozici. V porovnání s výpisem přes WMI, je absence o detailech vlastního souboru který spustil daný proces, datumu spuštění procesu či vyuţití procesoru, téměř aţ nepochopitelná. Další špatnou informací budiţ fakt, ţe ačkoliv se na rozdíl od WMI rozhraní jedná

o

interní příkazy Powershellu, uţití jakýchkoliv dalších výkonných funkcí, jako například

2

Parametr –Credentials byl přístupný uţ ve verzi PowerShell 1.0.

14

příkaz Stop-Process či metoda .kill(), které fungují pro lokální výpis korektně, je nemoţné pouţít, a skončí chybovou hláškou. Obrázek 5.

Výpis konkrétního procesu ze vzdáleného systému pomocí Get-Process


Poměrně velkým nedostatkem je absence přístupu pomocí jiného uţivatelského oprávnění. Na jednu stranu je pravda, ţe si můţeme spustit konzolu s právy administrátora, ale na druhou stranu právě Microsoft neustále nabádá ke zvyšování bezpečnosti práce

a

například jiţ mnohokrát zmiňované rozhraní WMI, právě tento parametr má. Jedinou výhodu, kterou spatřuji v uţití tohoto způsobu, je rychlost a snadnost pouţití filtru. S využitím WinRM interaktivním připojením Připojení na vzdálené systémy, by tedy mělo být stěţejním kamenem nové verze Powershellu 2.0. Pro připojení vyuţívá sluţbu WinRM (Windows Remote Managment) přes kterou je zajištěna komunikace mezi ovládajícím a ovládaným počítačem. Toto spojení probíhá na protokolu http, případně zabezpečeně přes SSL, coţ zajišťuje nejen 15

vysokou míru zabezpečení, ale dovoluje to i překlenout tradiční obtíţe v podobě firewallů či jiných filtrování síťového přenosu[5]. Vlastní nastavení remotingu se dotýká jen těch počítačů, na které se chceme přihlašovat nebo je vzdáleně spravovat pomocí Powershellu. Stanice, které pro vzdálenou správu pouţíváme, ţádné speciální nastavení nepotřebují. Vzdálená správa, resp. její konfigurace, je závislá na faktu, zda se pohybujeme v doménovém prostředí nebo ne. V doménovém prostředí je řízení přístupu postaveno na právech v rámci vlastní domény, včetně vlivu globálních a lokálních politik. V případě konfigurace remotingu mimo doménu, je třeba pro kaţdou jednotku na kterou se chceme připojit, nastavit konkrétní jména administrátorských stanic, které k nim budou vzdáleně přistupovat. Následující příklad nám ukazuje vlastní proces konfigurace vzdáleného přístupu pro doménový počítač. K tomuto účelu pouţijeme příkaz Enable-PSRemoting. Pokud bychom ještě přidali parametr „–Force“, nastavení by se provedlo s automaticky kladnými odpověďmi a jiţ by se na nic neptalo. Obrázek 6.

Svolení ke vzdálené správě


16

Vlastní interaktivní připojení můţeme ještě rozdělit na jednorázové a přetrvávající. Navázání jednorázového připojení je realizováno na obrázku 7. Třetí aţ pátý nečíslovaný řádek, který je uvozen názvem stanice, dokazuje úspěšné navázání spojení. Exitem jsme se dostali zpět na původní stanici a připojení bylo definitivně odpojeno. Pokud bychom spustili jakýkoliv persistentní proces na vzdáleném počítači, odpojením se logicky tento proces také ukončí. Obrázek 7.

Jednorázové interaktivní připojení pomocí WinRM


Přetrvávající připojení vytváříme pomocí příkazu New-PSSession, viz obrázek 8. Vstupujeme stejně, jako v předchozím případě, tedy příkazem Enter-PSSession, avšak s tím rozdílem, ţe změny provedené v dané relaci jsou persistentní. Npříklad změna v adresářové struktuře, provedená na prvním nečíslovaném řádku, přetrvala i po následném odpojení (exit) a opětovném navázání spojení. Na 5. řádku, příkazem Remove-PSSession definitivně ukončíme spojení se vzdáleným počítačem, podobně jako v předchozím případě Exit-PSSession. Obrázek 8.

Přetrvávající interaktivní připojení pomocí WinRM


17

Co se týče otázky vyuţití dalších CMDLETů a navazujících metod a funkcí, v obou případech je pouţití bez omezení, protoţe z pohledu jednotlivých příkazů, se tyto spouštějí vlastně lokálně. Tématice

PS-Remotingu se velmi důkladně věnuje komunita Powershellu na svých

stránkách Powershell.com [15]. S využitím WinRM mimo interaktivní relaci Poslední způsob je pouţíván zejména pro automatizované spouštění dávek příkazů či celých skriptů na více vzdálených stojích. Opět se k tomuto účelu vyuţívá navázání jednorázového nebo přetrvávajícího spojení, jen spouštění příkazů je uvozeno příkazy Invoke-*. Následující obrázek nám demonstruje, co by se stalo, kdybychom pouţili příkaz z 2. řádku. Parametr –WhatIf, známý jiţ z Powershellu 1, nám příkaz ve skutečnosti neprovede, jen nám popíše, co by se stalo kdybychom tam pojistný parametr nedali. Třetí řádek ukazuje příklad spuštění skriptu test.ps1 tentokrát na třech různých počítačích ap1-ap3. Podmínkou samozřejmě je, ţe na všech vzdálených počítačích, musí být povolen PS-Remoting příkazem Enable-PSRemoting. Obrázek 9.

Ukázka pouţití automatizovaného spouštění na vzdálených systémech


1.2.3

Spouštění úloh (Jobs) na pozadí

Jedná se opět o velmi zajímavý prvek, který rozšiřuje moţnosti jinak sekvenčního příkazového prostředí. Jedná se o šestici příkazů Start,Stop,Get, Remove,Receive a Wait s příponou –Job. Pomocí příkazu Start-Job tedy můţeme spustit na pozadí příkaz nebo sekvenci příkazů u kterých očekáváme delší časový průběh a na které by musel skript zbytečně čekat. Výsledek těchto příkazů si můţeme vyzvednout aţ později. Právě v těchto případech mluvíme o paralelyzaci úloh, kdy se spuštěním JOBu rozdvojí pracovní úloha. Následující příklad demonstruje pouţití těchto příkazů viz obrázek 10. Na řádce 1, vytváříme instanci na Job1 pod proměnnou $Jobik. Druhý i třetí řádek nás informuje o skončení úlohy. Ve čtvrtém řádku vybíráme výsledek úlohy a vypisujeme jen Jméno a ID 18

procesu. Zajímavostí je, ţe výsledek úlohy se nám objeví jen jednou, pokud tedy nepouţijeme parametr –keep, který zajistí, ţe si systém drţí proměnnou i po jejím vybrání. PS 1 C:\ Receive-Job 1 –Keep | ft name,id –AutoSize

Takto by vypadal příkaz, který by drţel informaci o výsledku i po jeho vyzvednutí. Pátý řádek maţe konkrétní úlohu ze seznamu úloh. Zajímavostí je taktéţ fakt, ţe číslování jednotlivých úloh je pouze lichými čísly a ţe číslování je stále se navyšující v rámci kaţdé samostatné instance Powershellu. Obrázek 10.

Ukázka spuštění úlohy na pozadí systému


Při implementaci paralelyzace, tedy násobného spouštění dalších úloh paralelně k úloze hlavní v praktické části diplomové práce, přišel jsem na několik zajímavých poznatků. Předně spuštěná úloha (job) běţí v izolovaném reţimu, coţ znamená, ţe ani uţivatelský a dokonce ani společný profil Powershellu se při spuštění nenačítají. To má své opodstatnění, nicméně o této skutečnosti, jsem předem nevěděl a ani jsem na oficiálních stránkách nenašel ţádné vysvětlení. Z toho plyne, ţe pokud chcete zavolat například nějakou funkci uvnitř skriptu, nebo společnou funkci uloţenou právě v uţivatelském profilu, obdrţíte chybovou hlášku, ţe volaná funkce není funkce, modul, či cmdlet a nemůţe být spuštěna.

19

Řešením je mnou přehlídnutý parametr –inicializationScript{} do jehoţ těla můţeme vloţit samostatné funkce, případně celý připravený skript, a vlastní úloha, která bude volat přáv takto iniciované funkce, jiţ proběhne úspěšně. Druhý problém, je spojen s problémem kompatibility na systémech Windows XP při spuštění příkazu GET-WMIOBJECT na vzdálený počítač uvnitř naplánované úlohy. Tomuto problému se budu na příkladu věnovat přímo v praktické části viz kapitola 4.1.3.

1.2.4

Nové příkazy a funkce WMI

Jak bylo jiţ demonstrováno, rozhraní WMI je velmi silným nástrojem, pomocí kterého můţeme řešit celou řadu úkonů. Doposud se vyuţíval v Powershellu pouze příkaz GetWMIObject pomocí kterého jsme mohli přistoupit k jednotlivých třídám rozhraní a získávat z nich potřebné informace, případně vyuţít definované metody, jako v případě ukázky ukončení procesů pomocí metody Terminate(), viz Obrázek 4. Set-WmiInstance Pokud jsme nuceni persistentně uloţit nějakou informaci do repositoru rozhraní WMI, můţeme k tomu vyuţít standardní postup, který se však skládá minimálně ze tří samostatných kroků. Nejprve si musíme otevřít instanci třídy viz níţe uvedený příklad volání třídy Win32_OperatingSystem. Ve druhém řádku upravíme jeden z parametrů a na dalším řádku voláme metodu put (), která změnu uloţí. $os = Get-WmiObject –class win32_operatingsystem $os.Description = "MyNewDescription" $os.put()

Příkaz Set-WmiInstance dělá vlastně to samé, jen se jedná o jednořádkovou funkci a tudíţ lépe vyuţitelnou pro dávkové zpracování či zpracování pro více počítačů najednou v rámci operátorské konzoly. Modifikace instance se dá provést pomocí parametrů –class, tedy stejně jako při volání Get-WmiObject, nebo pomocí relativní cesty –Path. Ačkoliv se o tom v oficiální nápovědě příkazu nepíše, dá se volání –class pouţít jen pro úzkou skupinu WMI tříd. Právě v nápovědě jsou uvedeny jako příklady fungování jen třídy Win32_WmiSettings a Win32_Environment. U většiny ostatních tříd dostaneme chybovou hlášku a volání musíme nahradit relativní cestou ke konkrétní třídě. Alespoň takto radí Ed Wilson z Microsoftu [21].

20

Obrázek 11.

Pouţití příkazu Set-WmiInstance

Zdroj: Vlastní tvorba, inspirováno Edem Wilsonem [21] a Richardem Siddawayem [18]

Tato tvrzení jsem demonstroval na obrázku 11. Na řádce 2, jsem se pokusil provést úpravu stejným způsobem, jako je uvedena pro obě výše zmíněné třídy v nápovědě systému a skutečně jsem obdrţel chybovou hlášku. Úpravu jsem proto provedl dle návodu Eda Wilsona a nahradil jsem parametr –class, parametrem –Path a dodal příslušnou hodnotu voláním vloţeného příkazu. Celková změna parametru tentokrát proběhla úspěšně. Na řádku 4 jsem pro zajímavost vypsal, jak vypadá hodnota relativní cesty ke třídě Win32_OperatingSystem. Na blogu Richarda Siddawaye [18] jsem ještě našel inspiraci pro jiné, z mého pohledu, nejelegantnější řešení, coţ jsem demonstroval na řádku 5. Přkazem Get-WmiObject vyhledáme třídu a příkaze Set za rourou proměnou změníme. Myslím, ţe tímto příkladem můţeme opět demonstrovat úţasnou flexibilitu tohoto skriptovacího prostředí.

Invoke-WmiMethod Dalším velmi zajímavým příkazem je cmdlet Invoke-WmiMethod, který nám dovoluje volat metody vybrané WMI třídy. Následující příklad nám opět odkrývá zajímavou skutečnost. Příkazem na první řádce, jsme získali seznam veřejně dostupných metod pro třídu Win32_Process. Na řádce 2, jsme si však ukázali výpis statických metod pro danou třídu. Zde se nachází metoda Create(). Třetí řádek demonstruje spuštění procesu aplikace

21

Notepad.exe na hostitelském počítači pod právy, které má vlastní instance konzoly Powershellu. Proces byl vytvořen pod ProcessID 5984 a aplikace se vizuálně spustila. Obrázek 12.

Příklad pouţití příkazu Invoke-WmiMethod


U spouštění procesů touto metodou ještě chvíli zůstaneme. Pokud zavoláme stejný příkaz na vzdáleném systému pomocí parametru –computername, volaná aplikace se sice nastartuje, ale nespustí se vizuálně. To nám poskytuje moţnost spouštět určité procesy (typicky skripty spojené s inventurou systému) na pozadí systému bez interakce s přihlášeným uţivatelem.

Remove-WmiObject Posledním, z přírůstků do rodiny WMI příkazů, je Remove-WmiObject. Jeho funkce spočívá v ukončení instance dané třídy. Příkaz de facto substituuje funkci hromadné aplikace metody terminate(), kterou jsme si předvedli výše na příkladu „Aplikace metody Terminate() na vzdáleném serveru“, viz Obrázek 4. Následující aplikace příkazu je určitě daleko pohodlnější a hlavně rychlejší na pouţití zejména z pohledu rychlých operačních zásahů administrátora.

22

PS > Get-WmiObject Win32_Process -filter "name='notepad.exe'" | RemoveWmiObject

Vyuţití není určeno jen pro procesy, ale často bývá pouţit například pro mazání adresářových struktur.

1.2.5

Get-WinEvent

Tento příkaz, jako jeden z mála, nemá zpětnou kompatibilitu na starší operační systémy a je určen výhradně pro operační systémy Windows Vista a vyšší (Windows 7, Windows Server 2008). V těchto operačních systémech je aplikován nový způsob ukládání záznamů událostí (logů), který zřejmě postupně nahradí původní klasické “binární” formáty z dřívějších variant Windows. Nový způsob uloţení dat je doprovázen příchodem nového příkazu GetWinEvent v Powershellu 2, který umoţňuje jejich zpracování a prohledávání. Je schopen poradit si se všemi logy a díky novému způsobu uloţení dat – do formátu XML – jej můţeme pouţít i k prohledávání pomocí pokročilejších dotazů. [5] Z výše zmíněné citace Patrika Maliny by se dalo předpokládat, ţe Get-WinEvent tak v budoucnu nahradí dosavadní příkaz z Powershellu 1.0 Get-Eventlog. Při té příleţitosti mne napadla myšlenka porovnat rychlost obou přkazů, ale protoţe jsem neměl k dispozici vhodné prostředí, pouţil jsem experimentální měření z blogu Marka Berryho [8]. Jeho kritérium pro pokus byl report všech kritických událostí a výstraţných upozornění ze všech logů ze vzdáleného systému za posledních 24 hodin. Berry zde měřil hlavně čas, za jak dlouho si příkazy se stejnými parametry pro vyhledávání, poradí s výpisem poţadovaných dat. Následující tabulka ukazuje rychlost výpisu výše uvedených událostí z Aplikačního logu, který měl velikost 20MB a obsahoval přes 53 tis. záznamů.3 Obrázek 13.

Tabulka č. 1 experimentálního meření výpisu událostí systému Time Elapsed – Local

Time Elapsed – Remote

Get-EventLog

0:00:16

0:05:34

Get-WinEvent

0:00:05

0:00:27

Application log: Warnings and Errors

Zdroj: Blog Marka Berryho, MCB Systems [8] 3

Čas je v tomto případě ve formátu H:MM:SS

23

V tomto případě Get-WinEvent fungoval dle předpokladu mnohonásobně rychleji neţ GetEventlog, zejména vzdáleného systému. Jak však Berry zmiňuje dále, pokud zmíněné operační systémy Windows Vista a vyšší zaznamenají bezpečnostní chybu „Security failure“, je tato událost zapsána do úrovně Event Level 0, coţ je také značeno jako LogAllways a znamená to, ţe tato událost nemůţe být filtrována z důvodu probíhajícího uveřejňování. Coţ ovšem znamená, ţe událost na této úrovni nemůţe být filtrována pomocí klíčových slov[8]. Proto musel být pouţit následující filtr pro Get-Eventlog Where { (“FailureAudit” -eq $_.EntryType) }

a následující XML filtr pro Get-WinEvent. band(Keywords,4503599627370496)

Oba filtry fungovaly dobře, jediný problém je v rychlosti filtrování. Příkaz Get-WinEvent byl mnohanásobně pomalejší. Následující tabulka zobrazuje měření získání 24.000 záznamů bezpečnostních chyb z logu systému SBS 2008, jehoţ velikost byla 128 MB a obsahoval kolem 280.000 záznamů [8]. Obrázek 14.

Tabulka č. 2 experimentálního meření výpisu událostí systému

Security log: Audit Failures

Time Elapsed – Local

Time Elapsed – Remote

Get-EventLog

0:01:57

0:30:44

Get-WinEvent

0:09:46

1:04:16

Zdroj: Blog Marka Berryho, MCB Systems [8]

Z výsledků je patrno, ţe právě tady příkaz Get-WinEvent prohrál, vzdálený server byl dvakrát pomalejší a pro lokální měření dokonce čtyřikrát. Touto demonstrací však nechci upírat jednoznačný přínost jak novému systému skladování záznamů systému, tak představené funkci. Protoţe právě rychlost je vekým úskalým pro vzdálené volání „staré“ funkce Get-EventLog, kdy v prostředí našeho podniku, je reakční doba, závislá na sloţitosti dotazu vţdy v řádech minut.

1.2.6

Výstup do grafického Gridview

Rozhodně zajímavou cestou, jak rychle přefiltrovat nějaké objemné výstupy pomocí vizuální techniky v jinak řádkovém světě Powershellu, je příkaz Out-GridView.

24

Připravená, ale neformátovaná4 data, posíláme z řádky či skriptu do samostatného okna grafického prostředí, které vyţaduje instalaci minimálně DotNet Framework 3.5 na hostitelském systému. Vlastní GridView nám umoţňuje: schovávat jednotlivé sloupce výstupu (vlastnosti sledovaného objektu), aplikovat kriteriální filtry pouţívat rychlé filtrování řadit data sestupně/vzestupně kopírovat data do schránky Okno GridView aktivujeme na konci příkazového řádku, typicky jako následující příklad rozšířeného výpisu procesů, běţící na aktuálním počítači. PS> Get-Process | select * | Out-GridView

Rozšířeným výpisem mějme na mysli výpis všech vlastností procesu. To nám umoţňuje provést rozšířené filtrování. Na následujícím obrázku jsem aplikoval sekvenci filtrů, pomocí níţ jsem náhodou zjistil dva zapomenuté skryté běţící procesy Powershellu, spuštěných v rámci experimentů předešlého dne. Nicméně, zde je postup, jak jsem demonstrativní filtry postupně aplikoval. 1) Nejprve jsem se zajímal, jaké všechny procesy jsou podepsány firmou Microsoft. Tato informace je obsaţena ve sloupci Company. Přidal jsem tedy kriteriální filtr pro sloupec Company, který obsahuje řetězec „Microsoft“ 2) Poté jsem ze seznamu vypsaných asi 30 procesů, chtěl vypsat jen procesy se jménem Powershell. Pro tento účel jsem vybral pouţití rychlého filtru (quick filter), kde jsem pouţil podmíněné pouţití jen pro sloupec „Name“. 3) Protoţe výpis ukazoval 4 procesy, ačkoliv spuštěná okna byla jen dvě, vyuţil jsem další kriteriální filtr nad oknem MainWindowTitle, kde mne zajímala prázdná hodnota. Sloupec ID jsem metodou „Drag&Drop” čistě z estetického důvodu přesunul před sloupec Path.

4

Neformátovanými daty jsou myšlena data, na která jsme nepouţili příkazy začínajícími slovesem Format-*

25

Obrázek 15.

Aplikace různých filtrů v tabulce GridView


V konzole Powershellu jsem následným výpisem Get-Job dostal informaci o dvou běţících úlohách. Jejich zastavením a smazáním oba výše uvedené procesy zmizely. Řazení dat v GridView však odkrylo i několik skrytých chyb. Předně se dají řádky třídit (vzestupně/sestupně) jen v rámci jednoho sloupce. Funkce vícečetného řazení, jak ji známe např. z aplikace Microsoft Excel, se nedá provést, coţ je určitě nevýhoda a v případě takové potřeby nás to logicky nutí k alternativním způsobům zpracování, jako např manuálnímu odkopírování data z GridView právě do Excelu. Daleko větší nepříjemnost s řazením spojená je řazení čísel s desetinnou čárkou. Jak ukazuje následující obrázek a), tato čísla jsou ve skutečnosti povaţována za text a jsou proto řazena po jednotlivých sloupcích znak po znaku. Nejprve čísla, čárka a nakonec mezera viz 7. záznam na příkladu A. Obrázek 16.

A)

Ukázka řazení zobrazených dat a) s desetinnou čárkou, b) bez čárky

B) Zdroj: Vlastní tvorba

26

Jak jsem jiţ zmínil, nemoţnost aplikování vícenásobného řazení by se dala obejít pomocí aplikace MS Excel. Bohuţel, ani zde se čísla s desetinnou čárkou nechovají zcela seriózně. Čísla v řádech tisíců5, nemají aplikovánu mezeru standardním symbolem „space“ a tak MS Excel 2003 nedokáţe toto číslo převést na číselný formát ani za pomoci následující „očistné“ formule[12]. =VALUE(TRIM(CLEAN(A1)))

To je samozřejmě velmi nepříjemná vlastnost, se kterou se prozatím musí v případě pouţívání GridView počítat. Na druhou stranu vícenásobný filtr pouţitelný v řádce „quickfiltru“ je velice zajímavý a z hlediska rychlého hledání i velice zajímavý, takţe níţe uvedeným filtrem, jsem dosáhl stejného výsledku, jako v případě obrázku 15. mainwindowhandle:"0" pow

1.2.7

Zpracování událostí

Ačkoliv běţný systémový administrátor na rozdíl od běţných programátorů nepracuje příliš často s něčím, co je nejen v systému Winodws jinak běţná technika zvaná „událostmi řízené programování“, jak si dále ukáţeme, nejedná se o zcela zbytečnou inovaci, kterou do Powershellu 2.0 tvůrci zahrnuli. Ačkoliv starší skriptovací prostředí (např. WSH, VBScript) dokázala pracovat s událostmi systému, v Powershellu 1.0 přímočaré nástroje, vedoucí k odhalení konkrétní události systému, ţádné nebyly. Verze 2 tak přináší novinky, které nám umoţňují sledování a zpracovávání událostí a to hned přes dvě běţná rozhraní: WMI a vlastní .NET Framework. Obě tato rozhraní jsou programátory hojně vyuţívaná a tak byl vývoj v tomto směru celkem logickým pokračováním rozšiřování Powershellu[5]. Jak dále píše Malina, „Sledování a zpracovávání událostí pracuje obecně na principu jakéhosi „předplatného“ či předchozí registrace – ţádné rozhraní nám nemůţe průběţně vracet informace o všech moţných událostech a pouze čekat, ţe něco z této záplavy vyuţijeme – jednalo by se o čirou „výkonnostní sebevraţdu“. Událost, která nás ve skriptu zajímá, musí být předem „objednána“ – musíme zaloţit přesnou registraci, která určí, o jaký typ události máme zájem a kdo ji následně bude zpracovávat“[5].

5

Na obrázku A má proces Rtvscan hodnotu CPU(s) = 4 870,81

27

Jak bylo řečeno, máme k dispozici hned dvě rozhraní, přes které můţeme události monitorovat. Jako první si pojďme ukázat hlídání ukončení konkrétního procesu kalkulačky pomocí .NET Frameworku. Jak je patrno z následujícího příkladu, aplikaci calc.exe nejprve spustíme a na tento proces zaregistrujeme sluţbu hlídání události „exited“ s následným výpisem textu „Kalkulačka ukončena!“. Obrázek 17.

Příklad zpracování události přes .NET Framework

Zdroj: Vlastní tvorba inspirovaná příkladem Patrika Maliny [5]

Zajímavou vlastností tohoto příkladu je fakt, ţe výše demonstrované hlídání procesu je vázáno na konkrétní proces, v tomto případě ke kalkulačce s ID procesu 2124. Pokud bychom následně spustili další kalkulačku, tento hlídací skript nám uţ nic neprovede a dá se tedy říci, ţe po jednom pouţití je vhodný tak akorát ke smazání. Příkaz RegisterObjectEvent nám dokonce ani nedovolí vloţit jako vstupní parametr kolekci objektů, je tedy striktně vázán jen na jeden objekt. Pro případ, ţe bychom chtěli hlídat nějaké události přece jen trochu obecněji, musíme se uchýlit opět k rozhraní WMI, kde máme na výběr hned několik cest jak zpracovat “objednané” události. První metodou, kterou si nyní předvedeme, je zápis do globální proměnné. Globální proměnnou zde musíme pouţít proto, ţe proměnná $event vyniká automaticky uvnitř bloku –Action{} a jedinou cestou, jak zviditelnit tuto událost je uloţit ji právě do globální proměnné, která mění dosah působnosti i na naší interaktivní relaci. 28

Následující příklad tedy vyuţívá příkaz Register-WmiEvent a v rámci 3 vteřinového intervalu kontroluje změnu, resp. hledá ukončený proces a tuto skutečnost uloţí do proměnné $global:udalost. Obrázek 18.

zpracování události přes WMI pouţitím globální proměnné


Další moţností je tzv. inventura zastavených procesů, kdy bude vyuţívat příkaz Get-event, viz obrázek 19. Opět vytvoříme registraci hlídání ukončení procesů přes rozhraní WMI, jen vynecháme klauzuli –action. Get-EventSubscriber nám ukazuje, ţe „hlídací pes“ s názvem „hlidaniprocesu“ je aktivni. Následně ukončíme činnost programů calc.exe

a

mmc.exe. Tyto procesy jsem sice měl jiţ spuštěny, nicméně tento příklad funguje i pro nově spuštěné procesy. Příkaz Get-event | measure nám provede výčet událostí. Jak je patrno, došlo ke dvěma událostem, které splňují podmínku registrované hlídací sluţby. Následující příkaz, ačkoliv vypadá velmi sloţitě, jen vypisuje události sluţby „hlidaniprocesu“, vypíše jen události né starší dvaceti minut, a následuje rozbalování zapouzdřených objektů, aţ se nakonec dostaneme na seznam vlastností WMI třídy Win32_Process, odkud jsem pouţil jen poloţky Caption a ExecutablePath.

29

Obrázek 19.

Zpracování události přes WMI pouţitím fronty událostí


1.2.8

Transakce

Jednou z dalších novinek, které poskytuje Powershell 2.0 je model řízení příkazů pomocí transakcí. Jedná se o stejný, resp. podobný model, jaký je znám z databázového prostředí a umoţňuje nám zadávat určité příkazy které v případě uspokojivého výsledku, buď potvrdíme – u databází klasickým COMMIT v Powershellu příkazem CompleteTransaction – nebo provedeme návrat k původním hodnotám. Typický příklad vyuţití transakcí, popisuje jeden z tvůrců Powershellu Don Jones na stránce[10] věnované této problamatice. “Předpokládejme, ţe píšete skript, který má upravit několik klíčů v registrech. Jedna úprava, ale skončí chybou díky nedostatečným právům nebo tak podobně. Pokud se toto 30

ale přihodí, nechcete aby se uloţila ţádná z těch provedených změn. Prostě jen chcete aby se změny provedly jen pokud se úspěšně provede kaţdý dílčí příkaz. Tak to je přesně to, co transakce shellu mohou poskytnout.“ [10] Jak však dále v textu zmiňuje, transakce jsou určeny pro Windows Vista a vyšší systémy a podpora transakcí na niţší systémy nebyla implementována. Systém transakcí spočívá se spuštění vlastní transakce příkazem Start-Transaction. Pokud spustíme transakci bez jakýchkoliv parametrů, můţeme řídit, které příkazy se vykonají v „chráněném reţimu“ a které prostě provedeme. Chráněným reţimem mějme na mysli příkazy, které podporují parametr –useTransaction. Druhou variantou, je spuštění transakce v „nezávislém“ reţimu a tehdy se automaticky předpokládá, ţe pokud spouštěný příkaz podporuje transakční zpracování, provede se tak. Obrázek 20.

Ukázka pouţití transakcí v Powershellu


Na výše uvedeném příkladu, pořízeným pro tyto účely na operačním systému Windows 7 Ultimate, vidíme snadnost pouţití transakcí. Nejprve jsme nastartovali transakci a následně pomocí příkazu New-ItemProperty vytvořili novou vlastnost klíče “HKey-CurrentUser\Test” pojmenovanou “Pokus” s hodnotou “Transakce”. Celý tento příkaz jsme spustili ve chráněném reţimu transakce. Následný výpis nám potvrdil případnou úspěšnost tohoto příkazu. Následuje ukázka výpisu hodnoty této přidávané vlastnosti. Protoţe transakci jsme ještě stále nepotvrdili, ve skutečnosti se neprovedla, o čemţ máme důkaz v podobě prázdného výpisu proměnné klíče. Následuje výpis Get-ItemProperty tentokrát 31

s parametrem –UseTransaktion s úspěšným výpisem hodnoty. Následuje potvrzení transakce příkazem Complete-Transaction a ověření v podobě dalšího výpisu proměnné, tentokrát jiţ bez transakčního parametru.

1.2.9

Moduly

Pojetí modulů v powershellu se opírá o uţitečné kusy kódu, které po uloţení na konkrétní místo v adresářové struktuře, můţeme snadno vyuţívat jak v rámci operativní konzoly, tak v rutinních skriptech. Jasná praměnící výhoda modulů oproti standardním snap-inům spočívá hlavně v tom, ţe moduly jsou psány ve vlastním jazyku Powershell a nepotřebují ţádné další konverze či kompilace. Dá se tedy říci, ţe po zavedení této výtečné funkce, se moduly staly velmi uţitečnou pomůckou i běţným administrátorům. Powershell eviduje na 7 cmdletů, které nějakým způsobem obsluhují moduly systému. Následujícím příkladem si ukáţeme jednoduché pouţití modulů. Nejprve jsem do standardní veřejné cesty C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\, kam se ukládají moduly pro všechny uţivatele systému, vytvořil sloţku „Textove“ a do ni jsem uloţil skript „Znakovani.psm1“. Kód funkce uvnitř souboru je následující: function SpoctiZnaky { foreach($arg in $args) { $text += $arg } return $text.length }

Dále jsme naimportovali tento modul do systému Powershellu a od té doby jej můţe volat z řádky nebo ze skriptů a samozřejmě i zde platí, ţe jednoznačný výskyt jména funkce doplní automaticky celé jméno po zmačknutí klávesy tabelátoru. Zkouška v podobě sečtení znaků řetězce proběhla v pořádku a následně jsme modul odebrali (jen z proměnných systému, nikoliv z disku). Jako zajímavost jen dodám, ţe pokud bych v příkladu níţe neuvedl uvozovky, budou se počítat jednotllivá slova jako samostatné argumenty a sečte se skutečný počet znaků bez mezer.

32

Obrázek 21.

Pokuţití modulů v Powershellu 2.0


Patrik Malina shrnuje téma modulů následovně: „Moduly v Powershellu 2 jsou vlastně zhmotněním myšlenek objektově orientovaného přístupu a jakési stavebnicové filozofie, která je blízká i mnoha jiným, prověřeným skriptovacím jazykům. Moduly dávají velkou příleţitost všem tvůrcům v Powershellu připravit zajímavý kód pro distribuci bez hranic – knihovny v podobě modulů poslouţí tam, kde bylo dříve potřeba psát kód ve vyšším jazyce, jako třeba C#.“[5]

1.2.10 Windows powershell ISE Pokud zde popisujeme novinky Powershellu 2.0, nemůţeme opominout Windows PowerShell Integrated Script Environment, zkráceně ISE. Jedná se o grafickou aplikaci, viz obrázek 22, ve které můţeme nejen spouštět příkazy Powershellu v operačním okně (spodní část aplikace) s výstupem do střední části aplikace, ale můţeme rovnou i psát příkazy a ukládat je do skriptů v její horní části a poté je spouštět opět s primárním výstupem do středního panelu. Pravdou nicméně je, ţe ISE je co do porovnání s existujícími editory poměrně chudý příbuzný, který například nemá automatickou nápovědu pro syntaxi jednotlivých příkazů, debuger je omezen jen na čárkovou a závorkovou syntaxi nebo moţnosti nastavení vlastního programu, nicméně pokud si nechceme nebo nemůţeme nainstalovat nějaký jiný program třetí strany, jistě tento produkt stojí za zkoušku. 33

Obrázek 22.

Ukázka pouţití Powershell_ISE


1.2.11 PowerGUI script editor Pokud jsme si však představili Powershell ISE, nemohl bych klidně spát, pokud bych alespoň nezmínil existenci více méně dnešního standardu administrátorů vyuţívající Powershell 2.0 a to PowerGUI Script Editor. Jedná se o freewareový produkt Powershell komunity registrované pod názvem PowerGUI [14] Tento editor má integrovaný systém automatické nápovědy syntaxí příkazů, podporuje rozšířený debugging skriptů a systém zvýrazňování párových závorek, coţ je nedocenitelná pomůcka při psaní rozsáhlých skriptů či sloţitých příkazů.

1.2.12 Další rozšíření a podpora služeb Windows Na závěr představení Powershellu 2.0 musíme ještě zmínit moţnosti rozšíření o balíčky či sady příkazů na podporu nejrůznějších sluţeb systémů MS Windows, které však nebyly standardně implementovány a jejich rozšíření je v působnosti kaţdého uţivatele. Většina rozšíření jsou připravena jako *.msi instalační balíček a k instalaci stačí jen konkrétní soubor stáhnout, spustit a projít triviálním průvodcem. Můţeme tak nainstalovat balíky pro podporu sluţeb webového serveru IIS, databází jako např. SQLServeru, sluţeb poštovního serveru MS Exchange, doménové databáze Active Directory, Microsoft SharePoint, správy Clusterů systému MS Windows anebo podpory a správy virtualizace přes Hyper-V. Kdyţ jsem se dotknul virtualizace, tak stále ještě 34

největším a dominantnějším konkurentem je společnost VMWare, která má taktéţ k dispozici obsáhlý administrátorský balík s podporou sluţeb stejnojmenného produktu. Díky otevřenosti tohoto prostředí a konečně i moţnostem tvroby vlastních cmdletů případně modulů, jsou nedocenitelným zdrojem nápadů právě komunitní weby a blogy, které přinášejí nejrůznější cesty jak překlenout ještě stále existující úskalí tohoto výjimečného produktu, na který systémoví administrátoři systémů MS Windows tolik let čekali.

1.3

Shrnutí

Skriptovací prostředí Powershell 2.0 se svými novými funkcemi jen rozšířil mnohá úskalí původní verze Powershellu. Moţnosti pouţití paralelizace úloh pomocí spouštění “JOBů” na pozadí, vzdálený remoting a mnoho dalších zajímavých funkcionalit prostředí mne příjemně překvapily. Na druhou stranu nepopírám jisté sklamání z nedostatečné zpětné kompatibility pro systémy Windows XP a Windows Server 2003, která mi způsobila ve vývoji dohledovacího nástroje jisté, ne však neřešitelné problémy. Nicméně si myslími, ţe pro správu systémů a domén jak jmenovaných starších systémů tak novějších jako jsou Windows 7 a servery MS Windows 2008, je toto prostředí velmi dobře připraveno a podle mnohých reakcí administrátorů a komunit na internetu, funguje nad očekávání rychle, efektivně a spolehlivě.

35

2 Popis

reálného

prostředí

banky

a

zadání

požadavků na produkt Vtéto kapitole si představíme reálné prostředí nadnárodní bankovní organizace, seznámíme se s praktikami dohledování serverů a povinostmi administrátorů vybraného oddělení i s dosavadními špatnými zkušenostmi s centralizovanou dohledovací sluţbou podniku. Na závěr kapitoly specifikuje zadání vývoje nového dohledovacího systému v představeném, interpretovaném prostředí Powershell 2.0.

2.1

Popis bankovního prostředí

Síťové prostředí nadnárodního bankovního institutu ABCBank6 se sídlem v německém Frankfurtu nad Mohanem, je rozprostřeno napříč všemi světadíly a dceřiné pobočky zastupují banku v desítkách států po celém světě. Jednotlivé státy jsou z pohledu sítě propojeny přes tři základní infrastrukturní body, Evropské státy aţ po Arabské emiráty jsou napojeny do německého Frankfurtu, Asijské státy aţ po Nový Zéland jsou propojeny do Singapuru a Amerika má hlavní centrum přímo v New Yorku. Všechny tyto tři uzly jsou propojeny páteřními linkami do mateřského Frankfurtu. Z pohledu doménového se ABCBank jiţ přes 7 let snaţí o centralizaci všech MS Windows domén, které se před příchodem projektu s názvem ABCWin7, vyšplhaly téměř ke dvěma stovkám jenom v Německu. U dceřiných poboček v zahraničí byl standard mít jednu a více svých vlastních izolovaných domén. K podtrţení tohoto kritického stavu jen zmiňme, ţe téměř všechny domény, provozované na nejrůznjších platformách, měly vlastní správce a lokální IT oddělení. Projekt ABCWin přinesl bezpochyby určité pozitivní výsledky a v současné době přeţívá jen minimální mnoţství těchto starých domén. Současná podpora globálního IT oddělení, alespoň z pohledu serverů a clientů pracujících na operačních systémech MS Windows,

6

Skutečné jméno banky, jsem z důvodu zmiňování jistých informací, které by mohli být vnímány jako

citlivé, zaměnil. 7

ABCWin je projekt migrace izolovaných domén na bázi MS Windows (NT,2000,2003) do jedné centrální

domény běţící na serverových systémech MS Windows 2003.

36

je určena jen pro centrální doménu ABC, která je skutečně velká. Pro lepší představu si uveďme některá čísla, demonstrující velikost této domény: doména ABC běţí na 70 doménových kontrolerech ve 34 státech, doména eviduje přes 100 tis. uţivatelských účtů, je zde několik stovek tisíců skupin zajišťující přístuppová oprávnění pro uţivatele a nejrůznějí bankovní aplikace, ve velmi rozvětvené struktuře organizačních jednotek je evidováno přes 55 tis. klientských stanic, a je zde evidováno přes 7,5 tisíce serverů s OS MS Windows Server 2003, mezi něţ patří aplikační servery, fileservery I doménové kontrolery Před 5 lety byla podepsána outsourcingová smlouva se společností DEFcompany8 v rozsahu správy domény, doménových kontrolerů, file serverů, správy clientských stanic, správy centrálního síťového instalačního systému a zároveň se tato firma stala hlavním dodavatelem HW. Působnost této smlouvy byla rozšiřována i na jednotlivé neněmecké země tak, jak byly postupně migrovány do centrální domény. Všechna zbývající IT oddělení banky nyní zajišťují kritické IT sluţby jako chod sítí, provoz systémů jiných platforem (UNIXové prostředí), správa databází a DWH, podporu bankovních aplikací a sluţeb a dohledu nad vlastní správou centrální ABC domény. Tato oddělení sice mají své primární sídlo v mateřském Frankfurtu, odkud se řídí chod IT v celém podniku, řada oddělení však v závislosti na povaze práce, celé řadě interních podmínek a dostupných financích, rozšířili svou působnost do Prahy, kde v roce 2005 vzniklo detašované IT centrum. V tomto centru se nacházejí specialisté na MS Windows aplikační servery, oddělení podpory datových sítí, databází Sybase, Oracle a MS SQL, dále je zde oddělení podpory bankovních aplikací a aplikací IB(investment banking), oddělení správy serverů na platformě UNIX a velmi početné oddělení vývoje bankovních aplikací. Toto centrum dosáhlo letos v lednu počtu 130 IT specialistů.

2.1.1

Popis oddělení Application Servers Support

Jedním ze jmenovaných oddělení je i tým s názvem Application Server support, které se zabývá podporou všech evropských neinvestičních applikačních serverů na platformě MS Windows v produkčním prostředí výše zmíněné centrální domény této banky. Toto oddělení čítá celkem 13 zaměstnanců, přitom pouze 3 pracují na detašovaném pracovišti v Praze, jehoţ členem jsem i já, zbylých 10 kolegů pracuje ve Frankfurtu. Základní

8

Obdobně, jako u jména banky, mi bylo doporučeno jméno outsourcingového partnera také nezmiňovat.

37

činností tohoto oddělení je správa a dohled níţe kategorizovaných serverů a zajištění jejich funkčnosti po stránce hardware a operačního systému. Do portfólia serverů tohoto oddělení tak patří: aplikační servery, které primárně poskytují uţivatelské klient/server aplikace, databázové servery běţící na operačních systémech rodiny MS Windows, servery určené pro centrální zálohování, tzv media servery, servery pro řešení obnovy po katastrofách, tzv Disaster recovery solution (DR), případně další servery se zvláštním důvodem pro zařazení právě mezi servery aplikační.

2.1.2

Přehled činností oddělení správy aplikačních serverů

Mimo činností spojených převáţně se správou DR řešení nebo poradenstvím v oblasti tvorby architektury lokálních aplikačních serverů pro jednotlivé pobočky, provádějí administrátoři zmíněného oddělení na svých serverech následující činnosti: Instalace / reinstalace serverů na úrovni OS Instalace nových serverů se provádějí pomocí poměrně propracovaného a vcelku dobře fungujícího systému vzdálených instalací s názvem DiWebLaus9 a pro nově instalované servery pomocí interního instalačního systému Gamin, resp. nového instalačního prostředí pro servery od firmy BladeLogic, pomocí kterého se i instaluje nejnutnější programové vybavení serveru. Správa a konfigurace virtuálních ESX serverů společnosti VMWare Oddelení má na starost správu šestnácti velkých ESX serverů poskytující virtuální řešení pro svěřené aplikační servery. Vymezení administrátoři nejen spravují vlastní ESX servery, ale podílejí se i na plánování a konzultacích ve smyslu rozšiřování poskytovaných sluţeb interním klientům. Instalace, správa a dohled virtuálních serverů na provozovaných ESX serverech Virtualizace nebo také sluţba poskytování virtuálního řešní pro aplikační servery je další ze zajímavých činností našeho oddělení. A čkoliv se primárně jedná o záloţní servery, tzv. disaster recovery servery, sluţba virtualizace produkčních serverů se pomalu rozbíhá a letos se stala i pilotním projektem našeho oddělení pro následující 2 roky.

9

DiWebLaus byl původně určený pro komplexní správu uţivatelů, uţivatelských stanic, instalace a patching

serverů, správu tiskáren a dalších zdrojů. Kdyţ s příchodem outsourcingu došlo na rozdělování odpovědnosti, rozhodlo se o zrušení tohoto systému s tím, ţe obě společnosti přejdou na jiné systémy.

38

Kontrola a dohled technického stavu serverů (HW) Vzhledem k tomu, ţe přístup k vlastním fyzickým komponentám serverů, resp. k jejich stavům či logům je velkými výrobci velmi střeţen, o dohled se starají dodané programy. Vzhledem k tomu, ţe ABCBank se snaţí o plošnou standardizaci HW, v produkčním prostředí jmenovaného oddělení jsou jiţ historicky výhradně servery firmy HP. K dohledu je vyuţívána aplikace HP System Inside Manager. Dohledování se provádí manuálně, a není doposud implementována moţnost zasílání SMS/Emailů o kritických stavech dohledovaných serverů. V případě zjištění skutečné HW závady se kontaktuje, přes interní systém poţadavků, externí dodavatel serveru a následně se koordinuje a dokumentuje vlastní oprava. Spolupráce na nejrůznějších bankovních projektech Několikrát do roka se kaţdý z nás účastní nějakého bankovního projektu, který tedy potřebuje konzultanty z oblasti naší správy, kde pomáháme s návrhem řešení, časovými odhady a sdílením zkušeností z jiných projektů. Pravidelná pohotovost na telefonu (On-Call sluţba) Pro případy neočekávaných chyb ana serverech, aplikacích a jiných sluţbách, je v ABC bank vypracovaný systém pohotovostí, kdy jsou pro kaţdou oblast sluţeb jmenovaní zástupci. Tito mají za povinnost, na zavolání zkontrolovat problém a zareagovat dle dohodnutých pravidel a povaze rizikovosti konkrétního severu. Kontrola běţícího systému na úrovni operačního systému (OS) V současné době se vyuţívá dohledovacího systému Tivoli Monitoring společnosti IBM. Ačkoliv je tento produkt velmi všestraný, implementace v ABCBank je poměrně nešťastná a spolehlivost celého systému je limitována vlivem zaškolených operátorů v detašovaném dohledovacím centru v Singapore, kteří sledují 24/7 konzoly systémů a ručně vyhodnocují nastálé události a manuálně přeposílají emaily nebo alarmy na příslušná oddělení. Připočteme-li nízkou míru flexibility, při tvrobě individuálních poţadavků, musím bohuţel konstatovat, ţe chybovost tohoto systému je díky lidskému faktoru poměrně vysoká. Protoţe se ale jedná o obecný fakt, většina oddělení dohleduje jim svěřené servery svými vlastními prostředky a dohledovacími nástroji. Kontrola restartu systému Oficiálně by měl tuto kontrolu opět řešit Tivoli monitoring, nicméně skutečnost je taková, ţe i přes četná upozornění, se informace o kritických stavech systémů k administrátorům dostávají se zpoţděním a někdy se nedostanou vůbec. Proto tuto sluţbu řešíme pomocí 39

skriptů v prostředí Powershellu, bohuţel zde nejsme jako oddělení jednotní. Německý tým stále spoléhá se oficiální dohled pomocí Tivoli a doplňkově generují pomocí Powershellu ranní a večerní reporty, které posílají přes email. Naše oddělení se naopak pokusilo situaci vyřešit pomocí komplexnějšího systému dohledu skripty v Powershellu 1.0 s funkcí zasílání SMS zpráv. Kontrola diskových kapacit serverů Tato činnost je také oficiálně řešena jen pomocí centrálního dohledu systémem Tivoli monitoring. Německá část týmu se opět spoléhá na jejich pravidelný Powershell reporting (2x denně), my v Praze pouţíváme samostatný skript, který projde seznam serverů a zobrazí poţadované informace. Tento skript však není nijak zakomponován do dohledovacího systému a musí se spouštět ručně – tedy nepravidelně. Pro servery VMWare vyuţíváme dohled pomocí administrátorské konzoly, nicméně díky nepřehlednosti všech serverů a jejich sloţité adresářové struktuře, není dohled pomocí tohoto nástroje příliš vhodný. Pravidelné instalace bezpečnostních záplat Instalace bezpečnostních záplat probíhá opět plošně, avšak jiţ výrazně flexibilněji. Při zavádění serveru do podnikové databáze dohledovaných serverů ABCWin-DB10, dochází s provozovatelem serveru k domluvě na časovém intervalu pro pravidelnou údrţbu serveru včetně moţnosti restartu systému. Pokud některé záplaty vyţadují restart systému, jsou instalovány jen v rámci tohoto časového okna. Samozřejmě, ţe v případě nutnosti instalace nějaké kritické záplaty, je moţné kontaktovat provozovatele serveru a domluvit individuální čas vyjímečného restartu. Spolupráce na odstraňování problémů vzniklých na úrovni aplikačního SW Při zjišťování závad na těchto byť standardizovaných serverech, není někdy jasné, proč se některé chyby objevují, a není tak jednoduché určit podstatu problému. Bohuţel tendence mnoha oddělení je spíše problémy neřešit a poslat „černého Petra“ na někoho jiného.

10

Jméno databáze koresponduje s projektem migrace domén. Navíc je obecně dodrţované pravidlo a vyuţíváno jak v pozitivním, tak bohuţel hlavně v tom negativním smyslu, a to ţe server banky, který není v databázi ABCWin-DB, neexistuje. Bohuţel tato dabáze není propojena s ţádným jiným systémem a tak se musí servery vkládat ručně. Jen podotknu, ţe momentálně neexistuje ţádné sběrné místo, které by se staralo o vklad nových a úpravy stávajících serverů a tak je to v působnosti kaţdého administrátora. Bohuţel, ne všichni co mohou instalovat servery mají i přístup do této databáze.

40

2.2

Servery oddělení správy aplikačních serverů

Oddělení správy aplikačních serverů má celkově na starost přes 300 reálných serverů a přibliţně 200 virtuálních serverů, běţící na VMWare řešení. Náš praţský tým má zodpovědnost nad dohledem 58 fyzických produkčních serverů mimo území SRN a 20 virtuálních produkčních serverů. Nad ostatními servery máme jen zástupný, tedy pomocný dozor pro případ absence německých kolegů či velkého mnoţství problémů.

2.3

Zadání vývoje

V listopadu 2011 jsme na měsíční schůzce s naším liniovým vedoucím dostali úkol, vţdy v co nejkratší časové lhůtě zkontrolovat restarty serverů, a provést analýzu důvodu takového restartu. V případě, ţe by se jednalo o neočekávaný restart způsobený aplikacemi, resp. nezpůsobený technickým stavem serveru, dostali jsme za úkol informovat vedoucího o tomto stavu a to i v rámci nočních pohotovostí. Důvody byly hlavně politické, nicméně jeho doporučení vyuţít funkce dohledovacího systému Tivoli jsem mu vymluvil výše popsanými argumenty a navrhl vyuţití dohledování pomocí nového dohledovacího systému v prostředí Powershell 2.0, který bych pro naše oddělení napsal. Nicméně tím, ţe jsem se jiţ v minulosti podílel na několika projektech, kde jsem právě pomocí Powershellu přinesl rychlá a efektivní řešení, vedoucí s mým návrhem souhlasil a pověřil mne vlastním vývojem, nicméně stanovil podmínku, ţe vývoj tohoto produktu nesmí výrazně omezit mou rutinní práci a ţe finální verzi produktu odzkoušíme nejprve v rámci praţského oddělení, resp. dohledem neněmeckých serverů a teprve pokud bude funkcionalita v pořádku, bude nasazena také pro německý tým. Také jsem vedoucímu sdělil, ţe jsem si toto téma vybral pro svou diplomovou práci a seznámil jsem ho s osnovou této práce a záměrem a také s představou, jak by měl nový dohledovací systém fungovat. Následující poţadavky jsou ty, na kterých jsme se s mým liniovým vedoucím shodli, resp. Které by on od systému očekával. Nicméně jeho poznámku, abych bez obav implementoval i další funkce, které ovšem nebudou nijak modifikovat dohledované systémy, jsem vzal jako projev jeho důvěry.

41

Zde je tedy soupis poţadavků na nový dohledovací systém oddělení správy aplikačních serverů, které povaţoval můj liniový vedoucí za klíčové: 1) Nepřetrţité dohledování systémem 24/7 všech námi spravovaných serverů. K dispozici mi bude jeden z aplikačních serverů našeho oddělení, který je připojený na páteřní lince v německém Frankfurtu. 2) kontrola posledního pádu/restartu serverů s okamţitým SMS reportem. Sluţbu konající administrátor bude na takovou událost reagovat co nejdříve, prověří důvod restartu a případně bude reportovat vedoucímu (viz výše) 3) kontrola volného místa na discích serverů. Vzhledem k častým problémům s konfliktem antivirového programu Symantec a aplikace NetBackup a následným zaplnění disku „C:“, je report o sniţujícím se volném prostoru na našich serverech funkcí ţádanou 4) Programový kód bude komentován v angličtině a po dodělání musím dodat popis jednotlivých funkcionalit.

42

3 Výběr metodiky vývoje produktu Z výše uvedeného seznamu poţadavků je patrné, ţe vlastní zadání je velmi volné, ţe zde není kladen důraz na čas ani zdroje, ale hlavní prioritou tohoto projektu budou spíše dobře zvolený architektonický návrh, vyšší míra funkčnosti a snadná rozšiřitelnost celého systému. Na základě zkušeností a také několika dřívějších verzí programu jsem dospěl k závěru, ţe určitou metodiku vývoje zvolit přece jen musím, protoţe propojení více klientů s dohledovacím serverem, jiţ přesahuje hranice standardního skriptu a vyţaduje detailnější analýzu i návrh. Protoţe je pouţívání Powershellu v naší firmě na vzestupu, dají se předpokládat další poţadavky na rozšíření tohoto monitorovacího systému. A pokud nechci tento systém učinit nepřehledným s celou řadou zpětně těţko identifikovatelných funkcí, musím zvolit metodiku, která mi pomůţe nejen snáze pochopit, vytvořit a implementovat jednotlivé poţadavky do nového IS, ale dovolí mně i kolegům v budoucnosti jednoduše provádět změny v kódu a snadno se v něm orientovat. Na výběr v úplném úvodu byly dvě cesty, respektive dva přístupy[2]: Úkolocentrický přístup (Work-Down) Hodnotocentrický přístup (Value-Up) Obrázek 23. Úkolocentrický a hodnocentrický přístup

Zdroj: Sam Guckenheimer a Juan J. Perez [2]

Úkolocentrický přístup je tradiční přístup vývoje projektů, jehoţ principy se pouţívají jiţ desetiletí, kdy je kladen důraz na zkušenost, důkladnost návrhu, malou rizikovost. Jak popisují Sam Guckenheimer a Juan J. Perez ve své knize.

43

„Naneštěstí pochází většina obecně přijímaných znalostí o vedení projektů ze světa silnic a mostů. V tomto světě je návrh spojen s malými riziky, jeho cena je v porovnání s budováním nízká a jen zřídkakdy lze hodnotu dodávat inkrementálně.“ [2] Oproti tomu hodnotocentrický přístup se orientuje na vlastní vývoj, zaměřuje se na vytváření hodnoty, zapojuje zákazníka do častých konzultací a sdílí se s ním vlastnictví projektu. Ve vývoji se dá očekávat nejistota a větší či menší problémy, ale na ty by měl být vývojový tým díky analýze připraven a být schopen je řešit. V neposlední řadě, je kaţdý projekt vývoje SW jiný a na kaţdý jsou nasazeny jiné metodiky a postupy, které lépe vyhovují povaze konkrétního projektu. Výkon celku má za úkol povzbudit efektivitu a morálku jednotlivců i celku samotného. Cesta agilního vývoje nebo také vývoje na principu zmíněného hodnotocentrického přístupu, se mi zdála být vhodnou volbou. Při studiu metodik, jsem však narazil na několik faktů, které volbu zesloţiťovaly. Všechny standardní agilní metodiky, jako metodika extrémního programování (XP) [4][7], metodika SCRUM development process[4][7], Microsoft Solution Framework for Agile Software Development[2], Feature Driven Development[4][7], Test Driven Development[4] a Unified Process(UP)[1] počítají s vícečetným týmem a kaţdá metodika tak předepisuje, jaké všechny činnosti, procesy a úlohy má ta která role na projektu vykonávat, řídit a kontrolovat. Metodické procesy postupy primárně pomáhají v koordinaci všech těchto činností, tvorbě procesu komunikace, vývoje a testování a následné nebo kontinuální tvorbě projektové dokumentace. Protoţe však budu na tvorbě systému pracovat sám, snaţil jsem se sehnat vhodnou metodiku pro jednoho programátora, která mne nebude příliš byrokraticky zatěţovat, a zároveň mi pomůţe ve vlastním vývoji. Na otázku, která z agilních metodik je vhodná pro jednoho programátora, se pokusil odpovědět Ondřej Bechný ve své diplomové práci v rámci akademického roku 2010/11[7]. Rozebírá zde vyuţití jednotlivých agilních metodik a porovnává klady a zápory metodik XP, SCRUM a OpenUP pro vyuţití jedním progrmátorem. Ve své práci mimo jiné zmiňuje různé negativní aspekty ovlivňující samostatného programátora v metodickém procesu vývoje softwaru jako absence jednotlivých rolí na projektu, nedostatek reflexe ať uţ v návrhu, dokumentaci nebo výsledném kódu, tendence věnovat se méně důleţitým či zábavnějším úkolům a činnostem, vytrácející se motivace, absence týmové konzultace, nehospodárné vyuţívání času či nedostatečné prioritizování úkolů a jiné. Jeho finální 44

doporučení v podobě návrhu vlastní metodiky „One-man Oriented Software development Methodology“ vychází primárně z procesního rámce SCRUM s moţností vyuţití prvků metodiky extrémního programování.

3.1

Specifika skriptování nejen v Powershellu

Dalším neméně důleţitým poznatkem bylo, ţe většina uvedených metodik je, z mého pohledu, přizpůsobena na vývoj softwaru vyššími programovacími jazyky, kde vývojářská studia umoţňují kooperaci programátorů, verzování, debugování, (reverzní) inţenýring kódu, návrhy s následným generováním programového kódu a mnoho dalších jistě uţitečných funkcí. Pro výběr mé metodiky tak vznikla otázka, jak se liší skriptování od tradičního objektového programování a zda tento rozdíl bude mít nějaký zásadní vliv na vlastní výběr metodiky. Interpretovaný jazyk Powershell všechny tyto funkce postrádá nebo je jejich síla výrazně omezena. Na druhou stranu je skriptování z určitého pohledu jednodušší v tom, ţe se nemusíme tolik zabývat analýzami a samostatnými návrhy, definováním proměnných, tvorbou tříd a jejich následnou implementací, ale naopak se daleko více a hlavně přímějšími cestami, orientujeme na konečný výsledek. Tímto tvrzením se dle mého soudu ztotoţňujeme s výše popsaným hodnotocentrickým přístupem, který je také více neţ co jiného zaměřen na výsledek a tedy uspokojení zákazníka.

3.2

Dosavadní přístup k vývoji skriptů

Čím více jsem jednotlivé metodiky studoval, tím více jsem docházel k závěru, ţe není, aţ tak důleţité jakou konkrétní metodiku zvolím, ale jaký přístup vývoje praktikuji a jak moc bude tento vývoj ve shodě s postupy zvolené metodiky coţ se ve výsledku projeví na míře úpravy vybrané agilní metodiky. Stejně jako většina skriptařů, nad „malými“ skripty obvykle nikdy moc nepřemýšlel, pouţil jsem pár podmínek, vyzkoušel funkcionalitu příkazů a vloţil je do skriptu, který jsem jednoduše spustil. V lepším případě, jsem ošetřil některé potenciální chyby v kódu a sníţil tak míru rizik selhání skritpu. Vím, ţe to není příliš sofistikovaný způsob vývoje, ale pro účely administrátora a rychlé odezvy na vzniklý problém, byl dostatečný.

45

Protoţe uţ ale mám zkušenosti s tvorbou větších skriptů, které měli řádově stovky řádků, vím, ţe určitý metodický postup je potřeba. Zejména tvorba UML diagramů mi pomáhá uvědomit si jednotlivá rizika, rozsah poţadavků a budoucí funkcionalitu systému v celé její šíři. Začal jsem proto pouţívat jazyk UML a jeho analytické a návrhové diagramy, které jsem jiţ několikrát pouţil pro komunikaci se svými německými kolegy. Postupně jsem také vypracoval vlasní postup tvorby kódu, při které si obvykle nejprve namodeluji problém v jazyce UML, zanalyzuji poţadavky a teprve následně vytvořím hrubou kostru kódu se všemi jeho základními podmínkami a cykly. Do kódu umístím informativní zprávy a otestuji plnou funkcionalitu skritpu (tedy alespoň z pohledu průchodnosti jednotlivých cest). A pokud jsem s tímto stavem spokojen, implementuju samostatně odzkoušené funkce Powershellu do kódu a provedu znovu otestování všech cest, tentokrát jiţ s reálnými výsledky.

3.3

Volba metodiky

Na základě výše uvedených skutečností, jsem se nakonec rozhod pro volbu metodiky UP (Unified Software Developemnt Process), kterou však budu muset, pro její přílišnou snahu o formalizování projektu, upravit a přizpůsobit svému vývoji. Jako rámec je ale metodika UP dostatečně přizpůsobivá a lze ji poměrně dobře upravit kaţdému projektu a přizpůsobit jeho specifickým vlastnostem a poţadavkům. Toto potvrzuje i Jim Arlow ve své knize [1]: “Metodika UP je obecnou metodou tvroby softwaru. Pro kaţdou organizaci stejně jako potom pro kaţdý jednotlivý projekt je tedy třeba vytvořit její novou instanci. Tím se uznává, ţe kaţdý softwarový projekt se od ostatních liší a ţe model „tato košile padne všem“ zde rozhodně neplatí.” Pojďme se tedy podívat, jakou strukturu metodika UP má, jakým způsobem probíhá standardní vývoj a jak jsem metodiku upravil pro náš konkrétní projekt.

3.4

Struktura metodiky UP a její úprava

Metodika UP je zaloţena na iterativním, tedy přírůstovém procesu. Pro správné pochopení metodiky, je potřeba porozumět nejprve vlastním iteracím. Základní myšlenka je velice prostá – historie nám ukazuje, ţe člověku se obecně vzato lépe řeší menší problémy neţ 46

větší. U velkého softwarového projektu se tedy snaţíme o to, abychom rozdělili velké úkoly na menší, samostatné projekty, kde bude snazší nejen řízení, ale hlavně dokončení. No a právě kaţdý z těchto projektů je povaţován za iteraci [1]. Struktura metodiky UP má následující čtyři základní fáze[1]: zahájení (inception) – období plánování, rozpracování (elaboration) – období architektury, konstrukce (construction) – počátky provozuschopnosti, zavedení (transition) – nasazení produktu do uţivatelského prostředí. K určení doby přechodu, mezi jednotlivými fázemi, nám v metodice UP slouţí tzv. milníky. Jejich význam je v celé metodice opravdu klíčový. Splnění podmínek přidruţených kaţdému milníku je svým způsobem propustka do další vývojové fáze. Tyto podmínky fakticky odráţejí celý smysl agilního vývoje tím, ţe se soustředí daleko více na cíl a nikoliv jen na výsledky. Metodika UP v rámci kaţdé iterace, ale i v rámci celého procesu, rozlišuje pět základních postupů [1]: poţadavky (requirements) – Zachycují to, co by měl systém dělat, analýza (analysis) – vybroušení poţadavků a jejich strukturování, návrh (design) – realizace poţadavků v architektuře systému, implementace (implementation) – tvorba softwaru, testování (test) – ověření, zda implementace funguje tak, jak se od ní očekává. Následující obrázek nám demonstruje míru jednotlivých postupů v rámci kaţdé vývojové fáze. Nutno upozornit, ţe se jedná o jeden z moţných scénářů a v duchu slov Jima Arlowa, se i tento graf, bude projekt od projektu lišit.

47

Obrázek 24.

Fáze podle metodiky UP

Zdroj: Fáze metodiky UP [9]

Nyní se podíváme na jednotlivé fáze trochu podrobněji a řekneme si, jaké jsou milníky stanovené metodikou a jednotlivé podmínky přechodu kaţdé fáze upravíme na míru našemu projektu.

3.4.1

Fáze zahájení (inception)

Hlavní důraz této fáze je kladen na postupy vedoucí ke specifikaci poţadavků a jejich analýze. Zároveň však do této fáze mohou spadat i návrhářské či implementační práce, pokud je jejich pouţití v souladu s rozhodnutím vytvářet technický prototyp. Jak je vidět I na obrázku 24, v této fázi obvykle nedochází k testování, protoţe se předpokládá, ţe jediné artefakty této fáze, tedy softwarové prototypy, budou stejně zahozeny[1]. Tato fáze obsahuje[1]: tvorbu podmínek proveditelnosti – to můţe zahrnovat návrh určitých technických prototypů, které pomohou ověřit validitu technologických rozhodnutí, zachycení podstatných poţadavků, které později pomohou definovat rozsah vznikajícího systému, označení kritických rizik.

48

Jak jsme si jiţ řekli, metodika UP je zaměřena hlavně na cíle. Proto milníkem této fáze bude dosaţení stanovených cílů formou splnění určených podmínek, případně mnoţinu výsledků, které pomohou tyto podmínky splnit. Následující podmínky budeme brát na zřetel pro splnění podmínek milníku této fáze vývoje[1]: s uţivateli a zainteresovanými osobami byly dohodnuty zachycené klíčové poţadavky formou UML diagramů a slovníku, potvrzení proveditelnosti obsaţené v předloţeném prototypu, náčrt architektury systému.

3.4.2

Fáze rozpracování (elaboration)

Hlavním cílem fáze rozpracování je tvorba spustitelného architektonického základu, tj skutečný spustitelný systém, sestavený na základě specifikované architektury. Jiţ se nebude jednat o prototyp[1]. V rámci jednotlivých postupů této fáze, se budeme soustředit na následující aktivity[1]: poţadavky – upřesnění rozsahu systému a poţadavků na něj analýza – stanovení toho, co budeme tvořit návrh – tvorba stabilní architektury implementace – tvorba spustitelného základu testování – testování architektonického základu Milníkem této fáze je architektura. Chceme-li povaţovat tento milník za dosaţený, musíme splnit následující podmínky[1]: byl vytvořen dostatečně robustní architektonický základ, spustitelný základ ukazuje, ţe byla rozpoznána a vyřešena důleţitá rizika,

3.4.3

Fáze konstrukce (construction)

Cílem konstrukční fáze, je splnit všechny poţadavky analýzy a návrhu a vyvinout ze spustitelného základu vytvořeného ve fázi rozpracování konečnou verzi systému. Klíčovým zadáním konstrukční fáze je zachování integrity architektury vytvářeného systému[1]. Co budeme dělat v rámci jednotlivých postupů[1]: Poţadavky – odhalit veškeré poţadavky, které byly v předchozích fázích přehlédnuty Analýza – dokončit analytický model. Návrh – dokončit model návrhu 49

Implementace – zajistit počáteční provozní způsobilost Testování – testovat funkční variantu Milník, je v této fázi v podstatě jednoduchý[1]: Softwarový produkt je dostatečně stabilní a na úrovni, aby jej bylo moţno nasadit na počítačích uţivatele,

3.4.4

Fáze zavedení (transition)

V této fázi klademe důraz na implementaci a testování. Je připraven vhodný návrh, který pomůţe odstranit veškeré závady nalezené při testování. Existuje velká pravděpodobnost, ţe se v této fázi generuje jen minimum nových poţadavků a minimálně se analyzuje. Je-li tomu naopak, projekt se obvykle nachází ve svízelné situaci[1]. Milník této fáze je pravděpodobně jasný. Produkt je hotov, je nasazen u uţivatele a ten je s tímto spokojen[1].

3.4.5

Úprava metodiky - dovětek

Tím, ţe metodika UP je hodně orientovaná na detailní rozpracování všech poţadavků, coţ zároveň počítá mnohačetným týmem, rozhodl jsem se pro aplikování jednotlivých metodických pokynů, jen v rozsahu nezbytném pro vlastní vývoj. Jak jsem popsal výše, skriptování je odvětvím programování, kde dynamika a rychlost pouţití zapouzdřených příkazů, je nejen hlavní devizou psaní programového kódu, ale i nezbytným předpokladem pro volnější formu vlastního psaní skriptů. Proto se v kapitole věnované vývoji, budeme zaobírat analytickou a návrhovou fází metodiky, kde nám jednotlivé diagramy jazyka UML mají pomoci pochopit vazby a poţadovanou funkcionalitu kaţdého samostatného modulu, případně jejich interakci v rámci celého dohledovacího systému. Jednotlivé poţadavky zaznamenáme do katalogu poţadavků, nicméně vedení takového katalogu je při vývoj ve skriptovacím prostředí s jedním programátorem a navíc v podmínkách našeho projektu trochu diskutabilní. Obecná teorie mluví o tom, ţe katalog pomáhá v koordinaci činností uvnitř týmu, zvedá nebo pomáhá udrţovat morálku, slouţí jako podklad pro stanovení ceny a vymezení šíře celého projektu a hlavně neustále vidíme, v jaké fázi se momentálně nacházíme. Jenţe samotný programátor nejlépe ví, v jaké fázi se nachází, protoţe za něj nikdo jiný práci neudělá.

50

Rozhodl jsem se zaznamenat do katalogu poţadavků jen ty funkční poţadavky, které budou zpracovány do diagramů uţití případně návrhu diagramu nasazení. Jejich rozpracování, však bude závislé na povaze kaţdého poţadavku a roli, kterou bude v celém systému mít.

3.5

Použití nástrojů

Pro vlastní vývoj je dnes asi nejpouţívanější a z mnoha pohledů i nejuniverzálnější vývojovým nástrojem PowerGUI Script Editor[14]. Tento produkt umí nejen barevně odlišit jednotlivé segmenty kódu podle funkčnosti, ale umí i zobrazovat kontextovou nápovědu, automatické doplňování příkazů, zvýrazňování párových závorek, případně některé další funkce. Pro tvorbu diagramů UML pouţiji sofistikovaný produkt Visual paradigma, jehoţ plnou funkcionalitu a široké moţnosti, díky vývojovému prostředí Powershell, sice nevyuţiji, nicméně jiţ jsem si na tento produkt zvykl a při porovnání s jinými vyzkoušenými programy, mi připadá ovládání velmi intuitivní.

3.6

Shrnutí

Zda byla volba metodiky unifikovaného vývoje aplikací vhodně zvolenou metodikou, se přesvědčíme v následující kapitole. Myslím si však, ţe upravená metodika spolu s navyklým stereotypem vývoje kódu ve skriptovacím prostředí viz kapitola 3.2, vytvoří silnou základnu pro vývoj stabilního a spolehlivého dohledovacího systému.

51

4 Vývoj produktu V této kapitole se budeme v duchu popsané metodiky věnovat vlastnímu vývoji dohledovacího systému. Projdeme jednotlivé fáze vývoje, zastavíme se u zajímavých momentů, podíváme se na analytické i návrhové diagramy a samozřejmě se budeme věnovat pouţití příkazů a funkcí skriptovacího prostředí Powershellu.

4.1

Fáze „Zahájení“

Na úvod si zopakujme, co je cílem této fáze. Jedná se o naplnění podmínek přechodu do další vývojové fáze projektu. Tyto podmínky jsou: 1) S uţivateli a zainteresovanými osobami byly dohodnuty zachycené klíčové poţadavky formou UML diagramů a slovníku 2) Potvrzení proveditelnosti obsaţené v předloţeném prototypu 3) Náčrt architektury systému Protoţe uţivatelské poţadavky, jsou logicky tím jádrem celého vývoje, je vţdy potřeba zanalyzovat nejprve tyto poţadavky, rozepsat jejich smysl a funkcionality a shodnout se zadavatelem, resp. zákazníkem, ţe právě tyto poţadavky jsou ty, které si skutečně přeje. K tomuto účelu nám nejlépe poslouţí digramu případu uţití (Use Case), který je dostatečně jednoduchý aby mohl slouţit jako rozhraní mezi sloţitým programátorským chápáním a uţivatelským naivismem. V našem případě, je situace o trochu komplikovanější v tom, ţe na projektu jsem sám a ţe zadavatele práce, tedy mého liniového vedoucího, vlastní vývoj příliš nezajímá. Navíc celým vývojem pověřil mne samotného. Do tohoto projektu jsem vstupoval s jistými vizemi, které by měly pomoci nejen opravit stávající monitorovací systém, ale hlavně zvýšit hodnotu našeho oddělení v rámci hodnocení celé banky. Tyto vize a ideje ohledně nového dohledovacího systému bych zformuloval do následujících bodů: Paralelizace dohledovacích testů – testy nám do současnosti běhaly sekvenčně, tedy jeden za druhým, coţ velmi zpomalovalo reakce celého systému na jiné poţadavky. Rozdělení aplikační logiky mezi server a klienta – do současnosti běţel jen jeden systém na kaţdém dohledovacím stroji administrátora. Synchronizaci zobrazovaných událostí – současné skripty spuštěné na různých počítačích logicky vracely události asynchronně a díky sekvenčnímu spouštění 52

testů, docházelo k rozdílu času o nějaké události i v řádu desítek minut. Chtěl bych, aby byla doba zobrazení co nejvíce synchronizovaná. Optimalizovat řídící cyklus – řídící cyklus dosavadního monitoringu má se všemi kontrolními mechanizmy přes 160 řádek. Chtěl bych zachovat řídící cyklus co nejčistší a co největší mnoţství kódu tak vloţit do samostatných funkcí. Vytvořit cyklus, do kterého by bylo moţné vstoupit stiskem klávesy a spustit tak poţadovanou funkci – v současném systému jsme vyuţívali buď kontinuálního cyklu, nebo dotazu s povinným vstupem (read-host). Nyní se pojďme podívat na původní poţadavky, resp. na zadání dohledovacího systému, které byly dohodnuty s liniovým vedoucím. Tyto bychom mohli jen těţko vloţit přímo do katalogu poţadavků, a proto budeme muset nejprve provést dekompozici a vytvořit blíţe specifikované poţadavky tak, aby vyhovovaly skutečným potřebám našeho oddělení. Připomeňme si nejprve původní zadání: 1) Nepřetrţité dohledování systémem 24/7 všech námi spravovaných serverů. K dispozici mi bude jeden z aplikačních serverů našeho oddělení, který je připojený na páteřní lince v německém Frankfurtu. 2) kontrola posledního pádu/restartu serverů s okamţitým SMS reportem. Sluţbu konající administrátor bude na takovou událost reagovat co nejdříve, prověří důvod restartu a případně bude reportovat vedoucímu (viz výše) 3) kontrola volného místa na discích serverů. Vzhledem k častým problémům s konfliktem antivirového programu Symantec a aplikace NetBackup a následným zaplnění disku „C:“, je report o sniţujícím se volném prostoru na našich serverech funkcí ţádanou 4) Programový kód bude komentován v angličtině a po dodělání musím dodat popis jednotlivých funkcionalit. Abych však alespoň částečně eliminoval rizika projektu popsaná v práci diplomové práce Ondřeje Bechného [7], rozhodl jsem se alespoň v těchto případech vyuţít mé kolegy, kteří budou celý systém v budoucnu také vyuţívat a klasifikace „zákazníci“ je pro ně tak nasnadě. Přestoţe jejich „vlaţný“ přístup k celému vývoji znamenal pro celý projekt jen minimální pomoc, poţadavky na klientský systém jsme nakonec sestavili společně.

53

4.1.1

Požadavky

Poţadavky, na kterých jsme se s kolegy shodli, jsem zaznamenal do následujícího diagramu uţití (UseCase diagram), podle kterého jsem dále postupoval ve vlastním vývoji. Obrázek 25.

Případy uţití – klientská strana

Zdroj: Vlastní tvorba v programu Visual Paradigm

Pojďme se nyní podívat na stranu serverovou. Obdobně jako u klienta i serverový návrh v podobě UseCase diagramu poslouţil jako následné vodítko pro návrh celého systému a i vlastní vývoj.

54

Obrázek 26.

Případy uţití – serverová strana


Jednotliví aktéři systému zde mají celou řadu podmíněných rozšiřujících činností, které spolu souvisí. Následující scénář pro poţadavek SpustitTesty modeluje interakci mezi jednotlivými aktéry systému a dohledovaným serverem. Aby nedošlo ke zpochybení následujícího scénáře, rozvedu ještě jednu myšlenku, která mě taktéţ vede celým tímto vývojem. Na následujícím obrázku č. 27 se objevuje ještě jeden aktér. Je tím „Spouštěč testů“, který by měl slouţit jako rozhraní mezi řídícím cyklem a vlastními testy. Mělo by se jednat o jistou formu optimalizace kódu a to tak, ţe bude ve výsledku tomuto spouštěči jedno, jaký test má spustit, pokud tento bude splňovat vtupní podmínky.

55

Obrázek 27.

Scénář poţadavku „SpustitTesty:UPTM“

Zdroj:Vlastní tvorba

Navazující scénář, by měl mapovat cestu vyhodnocení takového testu, které opět probíhá v reţii serveru, resp. dohledovacího systému. Výstupem tohoto procesu jsou další tři soubory, které budou zpracovány jinými moduly, ať uţ na straně serveru nebo straně klienta. Obrázek 28.

Scénář vyhodnocení testu UPTM na serverové straně


56

4.1.2

Návrh architektury

Výše uvedené scénáře a diagramy případů uţití mi velmi pomohli v úvahách nad fungováním celého systému. Proto logickým vyústěním této analytické fáze, budiţ první návrh architektury. Ve skriptovacím prostředí Powershellu, se dá jen těţko vyuţívat dědičnost tříd a jiné funkční prvky diagramu nasazení, přesto jsem si dovolil vyuţít tento diagram, k vizualizaci jednotlivých komponent, které se budou podílet na celém budoucím systému. Tyto komponenty budou ve výsledném skriptu reprezentovány jednotlivými či spojenými funkcemi, které bude volat řídící skript a to jak na straně klienta, tak na straně serveru. Obrázek 29.

Návrh diagramu nasazení

Zdroj: Vlastní tvorba v programu Visual Paradigm

Pojďme se nyní podívat na jednotlivé artefakty a uzly zběţně si popíšeme jejich funkcionality. Tento seznam by nám měl trochu více zpřesnit představu o budoucím systému.

57

Tabulka 1. Popis uzlů, komponent a artefaktů diagramu nasazení Řídící cyklus serveru

bude reprezentován nekonečnou smyčkou, která bude, na základě splnění přednastavených kritérií, spouští spouštěč testů.

Spouštěč testů

bude modul, který bude spouštět konkrétní testy. Tyto testy budou spouštěny pomocí volaného PowerShell skriptu(JOBy), tedy s paralelním voláním, čímţ se nejen zajistí minimální časová ztráta hlavního cyklu, ale i výrazně rychlejší dodání výsledku testování. Protoţe nevíme, kolik serverů budeme v budoucnosti kontrolovat, nemůţeme spouštět pro kaţdý server samostatný skript(job). (Ten zabere 30-40MB paměti). Budeme proto muset vytvořit konfigurovatelný systém spouštění určitého počtu serverů pro kaţdý test, abychom sníţili náročnost celého systému na zdroje serveru. testy malého počtu serverů budou po ukončení uloţeny do souborového systému a následně zpracovány jinými moduly.

Testovací skript

Vyhodnocovací modul bude kontrolovat adresářové struktury a zpracovávat vytvořené soubory s výsledky testů. Modul část informací poskytne globálním proměnným a část poskytne klientům v podobě nových souborů, zapíše do historie nebo předá komunikačnímu modulu. bude mít na starost komunikaci mezi aktéry systému. Představa je Komunikační modul taková, ţe klient bude veškeré činnosti ovlivňující systém provádět výhradně přes serverovou část systému. Dále je potřeba zajistit časový soulad moţných konfliktních situací v celkové komunikaci a proto bude komunikace fungovat na principu transakčního zpracování. Dále bude zajišťovat zasílání SMS/EMAIL informací administrátorům. Řídící modul klienta

bude stejně jako u serveru co nejjednodušší a bude zajišťovat spouštění jednotlivých modulů na základě podmínek.

Vyhodnocovací modul bude načítat informace ze sdíleného úloţiště a transformovat je do uţivatelského rozhraní. Operativní modul

pak umoţní klientovi reagovat na nastálé údálosti, filtrovat informace, zobrazovat historii a informovat ostatní klienty o činnostech na konkrétních serverech.

File server Dohledované servery SMS brána

sdílené úloţiště tvoří komunikační rozhraní mezi serverem a klintem. jsou obejkty našeho snaţení je rozhraní, přes které bude náš systém posílat SMS a emialy, je reprezentováno MRELAY serverem. Zdroj: Vlastní tvorba

4.1.3

Neúspěšný test funkce

Jak i metodika UP doporučuje a pokud to projekt dovoluje, je vhodné zhotovit prototypy, které poslouţí nejen k prezentaci jednotlivých funkcí zákazníkovi, ale i k otestování jednotlivých, předpokládaných, pouţitých funkcí. Původně jsem si myslel, ţe toho není potřeba, nicméně díky dále popsaným problémům, jsem došel k praktickému poznání, ţe

58

tento krok není bezúčelný. Pojďme tedy opět konečně k Powershelu a podívejme se na zásadní problém, který poznamenal další vývoj. V kapitole 1.2.3, jsem se věnoval procesu spouštění úloh na pozadí pomocí příkazů StartJob. Funkčnost byla tehdy odzkoušena dle doporučených příkazů, nicméně teprve aţ při testování funkcí, které jsem chtěl pouţít pro náš účel, jsem narazil na nevyřčená omezení a nakonec i na fatální selhání. Většinu chyb, respektive nezvyklostí, jsem do kapitoly dopsal, nicméně u následujícího problému jsem nebyl schopen najít řešení a protoţe se jednalo v mém konceptu o zásadní funkci, musel jsem cestu spouštění jobů opustit a hledat jinou alternativu. Předmětem neúspěšného testu bylo ověření, zda mohu spustit job, zjistit poslední restart serveru a vybrat tuto informaci. Ve výše uvedeném scénáři, je uţ pouţit XML soubor, tak jak jsem systém ve výsledku navrhl, nicméně funkce jobů měla být taková, ţe výsledky budou v paměti serveru a ten si je bez čekání a diskových operací převezme a vyhodnotí, podobně jako je naznačeno ve scénáři. Příkazy pro získání posledního restartu (uptime) jsou následující: Obrázek 30.

Výpis posledního restartu vzdáleného serveru


Náš dohledovací systém, by však měl podle mých představ spouštět jednotlivé úlohy paralelně, se smyslem získání informace co nejdříve. Pro vaši představu, získání výše uvedené informace ve „starém“ systému, trvá v naší nadnárodní síti 1-3 vteřiny na server, coţ by při počtu 100 serverů znamenalo časový interval 100-300 vteřin. Pro demonstraci chyby jsem výše uvedené příkazy vloţil do dvou souborů, kde jeden skript LOCAL.PS1 se dotazuje na poslední restart hostujícího počítače, tj. není zde uveden parametr pro vzdálené přihlášení, a druhý soubor REMOTE.PS1, který naopak tento parametr má. Oba jsem spustil tou nejjednodušší metodou na pozadí a výsledek nechal zobrazit. Job, který vyuţívá parametr pro vzdálené připojení (-computername), zůstane ve stavu „running“ a nikdy neskončí viz obrázek 31. Diskusní fóra se shodují v tom, ţe problém 59

nastává jen na operačních systémech XP a Server 2003, nicméně se různí v tom, co je příčinnou. Oficiální informace jsem ţádné nenašel a tak jsem tento problém musel opustit jako nevyřešen. Obrázek 31.

Demonstrace chyby Powershellu na Windows XP


Touto chybou, byla ale ohroţena realizace mé snahy o paralelizaci monitoringu a vznikla tak otázka, zda má Powershell další obdobnou funkci vhodnou pro paralelní spouštění. Nakonec jsme našel funkci, dostupnou jiţ v Powershellu 1.0 a tou je volání další instance Powershellu s parametrem na spuštění poţadovaného skriptu. PS> start-process powershell.exe -argumentlist ".\local.ps1"

Ačkoliv jsem si původně myslel, ţe tím bude narušen celý můj dosavadní návrh, nedošlo prakticky téměř ke změně. Všechny testy potřebných funkcí prošly jiţ bez větších problémů, a proto jsem se začal soustředit na prototyp uţivatelského rozhraní.

4.1.4

Uživatelské rozhraní

U diagramu případu uţití víme, co by měl systém dělat a jak by měl reagovat na klientské dotazy. V tomto případě jsem se nechal poučit z dosavadní verze pouţívané naším oddělením. Zde nám totiţ chyběl vizuální přehled serverů a jejich stavů. Ve výpisu sice byly jednotlivé servery s událostmi řazenými podle závaţnosti, ale popravdě i v konzole bychom ocenili trochu té vizualizace. Teprve aţ nedávno jsem se ze skriptu jednoho mého kolegy z Německa dozvěděl o parametru NoNewLine u příkazu Write-Host. Tento parametr způsobí, ţe se text neodřádkuje a konzole čeká na další text zakončený odřádkováním. Okamţitě se mi tehdy spojila tato funkce s tímto projektem a rozhodl jsem se ji implementovat. Spolu s vyuţitím 60

parametrů –ForegroundColor pro obarvení textu, či parametru –BackgroudColor pro obarvení textového pozadí, se nabízí poměrně široké moţnosti vizualizace různých stavů serveru. Stavy serverů, které nás zajímají, které budeme monitorovat a které bychom chtěli zobrazit v uţivatelské konzoli najednou, jsou následující: Stav normální – server bude v tomto stavu, pokud budou všechny testy úspěšné Stav nedostupnosti (unavailable) – neodpovídá na test PING Stav restartován – test UPTM vyhodnotí restart serveru Stav restartován za posledních 48 hodin – vyhodnotí klient Stav výstrahy (warning) – jakýkoliv stav, který není kritický Stav opravy (rezervace) – server si rezervoval administrátor Nyní se podíváme, jaké moţnosti vizualizace máme. Na základě testů, bychom se měli vejít se zobrazením serveru do 12-15 znaků. Přičemţ název serveru je vţdy dlouhý 8 znaků. Proto jsem navrhl zobrazit kaţdý server v délce 14 znaků, coţ nám umoţňuje 3+8+3 znaky. Teoreticky, bychom tak mohli signalizovat aţ čtyři různé stavy najednou. Pokud tedy vezmeme v potaz, ţe 1 a 1 znak budou slouţit pro oddělení serverů, tak nám zůstávají jen 2 a 2 znaky na kaţdé straně názvu serveru. Místa na signalizaci: 2 znaky nalevo od serveru, 2 znaky na pravo od serveru, barvu písma, barvu pozadí. Další otázkou bylo, kolik serverů se nám vejde na jednu řádku. Řešením je získání informace o aktuálním okně. Příkaz pro tuto informaci je následující: PS> $Host.UI.RawUI.WindowSize.Width

Tím, ţe konzola běţí v terminálovém reţimu a nikoli v grafickém jako například MS Word, je výsledkem skutečný počet znaků zobrazitelných na jedné řádce a od této hodnoty se můţe dále odrazit v dalších úvahách. Výsledný návrh úvodní konzoly dohledovacího systému v prostředí Powershellu, je zachycen na následujícím obrázku.

61

Obrázek 32.

Prototyp klientské konzoly dohledovacího systému


Jednotlivé servery jsem ztvárnil v následujících barvách. TmavěZelená – server který je v pořádku Červená – server který bude nedostupný nebo restartovaný Ţlutá – upozornění Zelená s hvězdičkou – restarty v rámci posledních 48 hodin Pod výpisem serverů zřejmě bude detailní výpis jednotlivých událostí. V takovém stavu, by měla konzole cyklicky kontrolovat nové stavy serverů nebo uţivatel stiskne enter a spustí tak operativní modul.

4.1.5

Vyhodnocení fáze „Zahájení“

Myslím si, ţe milník pro přechod do fáze rozpracování, byl naplněn bezezbytku. Nejen ţe jsme si ujasnili jednotlivé poţadavky na systém jak ze strany serveru tak, ze strany klienta, ale navíc jsme si ukázali i předpokládaný průběh jednoho z testů. Testováním funkcí jsme přišli na chybu v prostředí Powershellu, která by nás mohla při vývoji nemile překvapit. Nicméně jsme nalezli jeho alternativní řešení, které ani příliš nezměnilo podobu původního návrhu. Vizualizace klientského systému s vyuţitím obarvených textů v řádkách pomohla k lepší představě podoby klientské části systému.

62

4.2

Fáze rozpracování

Zatímco v předcházející kapitole, jsme se věnovali analýze, v této fázi se jiţ budeme věnovat hlavně praktickému vyuţití Windows Powershellu 2.0 nebo pokud to bude výhodnější, předvedeme si ještě některý návrhový diagram jazyka UML, který nám lépe vysvětlí činnost nebo stav konkrétní komponenty. Dále propojíme oba systémy, tedy jak klientský tak serverový pomocí sdíleného úloţiště a zapojíme modul na posílání SMS. Ke konci této fáze se pokusíme po vzoru testu PING implementovat test DISK pro kontrolu stavu volného místa na serverech a provedeme vyhodnocení sloţitosti implementace. Jsem přesvědčen, ţe není nutné zde do detailu popisovat celý vývoj, zobrazovat všechny pouţité diagramy a navrţené i zavrţené scénáře a nápady. Omezím se proto jen na popis důleţitých částí a zajímavých řešení finální verze dohledovacího produktu. Tím pádem ale podmínky pro dosaţení milníku této fáze rozšířím o podmínku, která náleţí fázi konstrukce: 1) Byl vytvořen dostatečně robustní architektonický základ, 2) Spustitelný základ ukazuje, ţe byla rozpoznána a vyřešena důleţitá rizika, 3) Softwarový produkt je dostatečně stabilní a na úrovni, aby jej bylo moţné nasadit na počítačích uţivatele. Pro náš projekt tedy stanovme, ţe pro úspěšné dokončení této fáze musíme splnit následující poţadavky. Strana serverová: Funkční základní modul Řídící cyklus, Funkční modul Spouštěč testů, Funkční modul Vyhodnocovací modul, Funkční modul Komunikační, pro posílání SMS, Funkční testy PING a UPTM, Implementace testu DISK Struktura sdíleného úloţiště. A na straně klientské: Funkční Řídící cyklus, Funkční Vyhodnocovací modul, Funkční Operativní modul.

63

4.2.1

Server: modul Řídící cyklus

Ideu jsme si jiţ nastínili, mělo by se jednat o neustálý cyklus, který bude řídit chod celé serverové části dohledovacího systému. Zároveň jsme si řekli, ţe se pokusíme udrţet co největší „čistotu“ kódu v něm pouţitou a veškěré činnosti se budeme snaţit volat jen předdefinovanými funkcemi. Protoţe vlastní kód je sloţen jen z několika podmínek a volání dalších funkcí, zobrazím jej v podobě diagramu aktivit. Hlavní cyklus je v kódu reprezentován podmíněným cyklem WHILE, a podmínky pro aktivaci jednotlivých testů jsou řešeny jednoduchými IF. Tím, ţe jsem v kódu nepouţil IFELSE, dávám moţnost spustit i více testů najednou. S touto informací se musí počítat, při konfiguraci serveru a výpočtu kolik pararelních testů se můţe najednou spustit. Podmínky spuštění testů jsou řízeny proměnnými $ROUNDP(ping), $ROUNDU(uptm) a později $ROUNDD(disk), které se navyšují kaţdé kolo a při dosaţení limitu, je konkrétní test předán spouštěči testů. Obrázek 33.

Diagram aktivit řídícího cyklu


64

4.2.2

Server: modul Spouštěč testů

U tohoto modulu se ale jiţ na vlastní kód podíváme. Tím, ţe se jedná o první obrázek celé funkce, ponechal jsem kód tak, jak je navrţen v systému. V případech dalších ukázek, jiţ budu ukazovat jen podstatné detaily. Ve funkci je vizuálně oddělena deklarovací povinnost11, a proto vidíme, jaké všechny globální proměnné vstupují do hry. Jediná výjimka je $global:workPath, která je platná vţdy a všude a nemá význam ji přepisovat. Následuje větvení SWITCH, které zpracovává parametr volání funkce $CHOICE a vybírá konkrétní skript do proměnné $SCRNAME. Následný cyklus FOREACH načítá jeden server za druhým a řadí je do pole $SRVS. Pokud je toto naplněno nebo pokud se jedná o poslední server na seznamu, uzavře vlnu (wave) a nastartuje nové prostředí POWERSHELL s parametrem skriptu a skupinou serverů určených ke konkrétnímu testu. Obrázek 34.

11

Modul Spouštěč testů (funkce fTest-Launcher)

Tím myslím pravidlo, které jsem se rozhodl dodrţovat, a to, ţe na začátku kaţdé funkce, musí být převod

všech funkcí na interní proměnné, které jsou pouţitelné jen uvnitř funkce a neopouští ji.

65


4.2.3

Server: modul Vyhodnocovací modul

Zpracování tohoto modulu, bylo vlastně nejnáročnějším procesem na straně serveru. Tento modul totiţ ve výsledku musí zastávat následující poţadavky: Kontrolovat změnu seznamu serverů – pokud by došlo ke změně seznamu serverů, bude tento znovu načten a celý dohledovací systém se změnou serveru musí umět pracovat. Kontrolovat UPTM testovací adresář – do tohoto adresáře (wmiupt) se ukládají výsledky UPTM testu pro všechny servery Zpracovat UPTM soubory – výsledkem tohoto zpracování bude hned několik souborů. Export do XML souboru s informací o restartech všech serverů (slouţí pro klienta), identifikace restartu serveru (porovnáním starého a aktuálního datumu), vygenerování souborů pro klienta, pro SMS modul a pro transakční systém se zápisem do historie. Zpracovat transakční soubory – pokud se objeví soubory v konkrétním adresáři, modul je načte, zapíše do historie a soubor smaţe. Kontrolovat uživatelské vynucení testů – tehdy změní např proměnnou $forceUPTM = $true a řídící modul spustí nuceně test. Exportovat historii – při zápisu do historie, respektive zpracování všech transakcí, exportuje historii pro ostatní klienty, případně pro případ pádu či ukončení serveru aby ji mohl opět načíst. Pojďme se ještě zastavit u tohoto modulu, protoţe zde jsem musel odvést nejvíce práce a jsou zde i nejzajímavější části serverového skriptu a i logiky jako takové. Hned první poţadavek na načítání seznamu serverů je velmi zajímavý. Jak vymyslet systém, který dohleduje servery, předává informace klientovi, vede záznamy a historii, ale přitom ho můţeme kdykoliv systému změnit pod rukama? Řešení je následující. Server udrţuje informaci jen o restartech aktuálních serverů v proměnné typu pole (array). Pokud se tedy změní seznam serverů (textový soubor změní vlastnost LastWriteTime), vygeneruje se nové pole a spustí se automaticky nový test UPTM, čímţ opět naplníme toto pole. Navíc všechny proměnné systému, ať uţ serveru nebo klienta, jsou potřebné jen pro aktuální zobrazení a jakýkoliv výpadek nebude mít vliv na ztrátu stavu.

66

4.2.4

Server: modul Komunikační, pro posílání SMS

Zásadní otázky, které jsem musel vyřešit v rámci tohoto modulu, byly dvě. Jednou byla komunikace klienta a serveru a druhá byla SMS systém. Komunikaci klientů a serveru jsem nakonec vyřešil na principu „transakcí“. Nerad bych přivedl čtenáře v omyl, a proto hned mírnou mystifikaci vysvětlím. Transakční zpracování v tomto pojetí je spíše myšleno jako dávkové zpracování poţadavků s časovým razítkem, v tom pořadí, v jakém byly vyvolány. Není zde však ţádný tradiční systém zajišťující kontrolu zpracování a potvrzování platnosti celé operace. Chápu proto, ţe by mohl v tomto ohledu vzniknout názorový spor, proto prosím za prominutí a akceptace slovíčka „transakce“. Princip „transakcí“ je následující. Všechny moduly, funkce ale i samostatné skripty (pokud k tomu mají důvod) mohou vyuţít funkci fGenerate-Transaction12. Tato má na starost vygenerovat soubor do adresáře $global:WorkPath\Transactions. Tvorba samotného souboru je demostrativně popsána v následujícím příkladu. Obrázek 35.

Vytvoření transakčního souboru


Obdobně jsem musel vyřešit posílání SMS,ačkoliv jeden zásadní rozdíl zde je. Zatímco historie a zpracování transakčních souborů je podmíněno co nejkratší dobou zpracování, SMS modul naopak potřebuje počkat pro načtení všech případných reportu-hodných událostí. Pokud například probíhají plánované restarty serverů, jejich faktický restart je spuštěn ve stejný čas skripty, ale jejich skutečné opětovné naběhnutí je uţ rozdílné a to

12

Rovnou přiznávám, ţe elegantnější řešení by bylo pouţití modulu viz kapitola 1.2.9, ale protoţe nechceme

zatěţovat klienty ani server instalací samostatných souborů někam do dresářové struktury, rozkopíroval jsem kód funkce do všech zmíněných entit systému

67

v závislosti na čase ukončování běţících sluţeb. Nicméně rozmezí je obvykle 1 aţ 2 minuty. Kdyby ale SMS modul reagoval na kaţdou událost okamţitě, přišlo by nám při 20 restartech 20 SMS zpráv. Proto se SMS modul spouští jednou za 60 sec a obsahuje vnitřní vyhodnocovací funkci na typ SMS zpráv, která zprávy třídí a počítá. Pokud je celkový počet událostí větší jak 6, SMS zpráva obsahuje jen počty jednotlivých událostí, pokud méně neţ 6, do SMS zprávy jsou vloţeny i detaily.

4.2.5

Server: testy PING a UPTM

Předně je potřeba říci, ţe oba testy se svou strukturou a funkcionalitami poměrně liší. Zatímco test UPTM pouze získává informaci o restartu z dohledovaného serveru a předá ji prostřednictvím souboru vyhodnocovacímu modulu serveru, test PING řeší veškerou práci sám a server, vyjma zpracování transakcí a posílání SMS nepotřebuje. Vznikli nám tím dva implementační vzory, pomocí nichţ budeme moci do budoucna rozšířit funkcionalitu systému. Pojďme se tedy podívat na test PING, který řeší dostupnost serveru. Následující stavový diagram popisuje jednotlivé stavy dohledovaného serveru, kterými můţe procházet při opakovaném spouštění testu. Právě podle tohoto diagramu byl i navrţen skript PPING.PS1. Obrázek 36.

Stavový diagram testu PING


68

4.2.6

Implementace testu DISK

Právě výše popsaný test mi přišel jako ideální vzor pro zavedení testu, o kterém jsme si jiţ několikrát řekli. Test DISK má za úkol kontrolovat nedostatečné volné místo na logických discích dohledovaných serverů. Logika, respektive stavový model je obdobný jako u popsaného testu PING. U obou těchto testů platí „presumpce funkčnosti“. To znamená, ţe pokud klient neobdrţí nějakou informaci, je server povaţován za funkční a vyhovující. Pokud se však na serveru objeví chyba v podobě nedostatečného místa (< 1GB), vytvoří se do sloţky testu určené ($global:workPath\pdisk) XML soubor s názvem konkrétního serveru. V tomto souboru je export informací z následující WMI funkce. $disks = get-wmiobject win32_logicaldisk | ?{$_.Drivetype -eq 3} … # Vyhodnocení stavu, případně export $disks | Export-Clixml $global:workpath\pdisk\$server

Tím, ţe test DISK je spouštěn jen jednou za 30 minut, je tento soubor vţdy přepsán, respektive smazán a znovu vytvořen. Důvodem je níţe popsaný systém dohledování sloţek pomocí klientského vyhodnocovacího modulu a je na administrátorech, aby nalezli příčinu a místo na serveru uvolnili. V případě, ţe hodnota disku klesne pod 500 MB, test navíc odešle SMS o tomto stavu. Na straně klienta, se do vyhodnocovacího modulu vloţil jen jednoduchý podmíněný export z načtené hodnoty XML souboru viz níţe, kde $_ reprezentuje testovaný soubor v uvedeném adresáři. Protoţe jsou v exportu informace o všech discích serveru, necháme si vypsat je ty, které splňují původní podmínku, tedy jsou menší neţ 1000 MB. $disks = Import-Clixml $global:workpath\pdisk\$_ $disks | %{ [int]$size = ($_.freespace / 1MB) if($size -le 1000) { write-host " $($_.deviceID) $size MB" -ForegroundColor yellow -NoNewline } }

4.2.7

Sdílené úložiště: Struktura

Téměř v kaţdé kapitole, kde popisuji fungování dohledovacího systému se zabývám předáváním nějaké informace a to ať uţ klientovi, serveru nebo SMS modulu. Je tedy zcela logické, ţe musela být vyřešena stuktura tohoto místa a ošetřena rizika s tím spojená.

69

Sdílené úloţiště je vymezeno globální proměnnou $global:workPath, která určuje konkrétní místo na konkrétním serveru a je společná pro všechny entity dohledovacího systému. $global:workPath = "\\SV079437\CBOUXXXXX02G0G6ZZZZ734ZZX$\monitor"

Proto pokud se jakýkoliv modul odkazuje na nějaký soubor nebo adresář, vţdy pouţívá právě tuto cestu. Zajištění struktury adresářů a povinných souborů je jedním z rizik celého dohledovacího systému. Snaha o sníţení rizika vyústila v implementaci samostatné funkce, která kontroluje následující oblasti: Adresářovou strukturu, která je potřebná pro většinu entit systému. Adresářovou strukturu, potřebnou pro klientskou část systému Adresářovou strukturu, potřebnou pro Serverovou část systému Kritické soubory – jejich absence způsobí zastavení serveru Soubor s historií systému, jehoţ znovuvytvoření není kritické pro činnost systému Obrázek 37.

Optimalizované zobrazení funkce fCheck-FolderStructure


70

4.2.8

Klient: Řídící cyklus

Pojďme se nyní podívat na klientskou stranu dohledovacího systému. Stejně jako u serveru, i klient je dle návrhu řízen „řídícím cyklem“. Následující výtah z kódu ukazuje, jednoduchost celého cyklu.

Máme zde celkem šest funkcí v tyrkysové barvě (pomiňme interní funkci CLS na smazání obrazovky), z nichţ první jsme si jiţ popsali u serveru a následující tři slouţí pro zobrazování a zároveň pro vyhodnocování stavů dohledovaných serverů, případně systému samotného. Funkci operačního modulu (fStart-OperationalModul) si popíšeme v následující kapitole. V rámci této kapitoly věnované řídícímu cyklu se pojďme podívat na funkci fWaitBreakKeyPressMainCycle. Jako základ této funkce jsem vyuţil stavovou vlastnost uţivatelského rozhraní UI.RawUI chráněné proměnné $host13, pro zjištění právě stisknuté klávesy. U této vlastnosti nejprve zjišťujeme stav vlastnosti UI.RawUI.KeyAvailable, která nabývá jen TRUE/FALSE a sděluje, jestli je nějaká klávesa stisknutá či nikoliv. Funkce ReadKey() načte hodnotu klávesy do proměnné $key. if ($Host.UI.RawUI.KeyAvailable) { $key = $Host.UI.RawUI.ReadKey("includeKeyDown,NoEcho").Character break; } $Host.UI.RawUI.FlushInputBuffer()

13

$host je proměnná s nedovoleným přepisem, která reprezentuje aktuální instanci spuštěného Powershellu a

zajišťuje všechny funkce s tímto „oknem“ spojené.

71

Pokud tuto funkci vloţíme do cyklu, bude nám systém jen kontrolovat, zda nedošlo ke stisku a zde bude záviset na frekvenci kontroly. Já nakonec nastavil kontrolu kaţdých 100 milisekund, coţ zajišťuje dostatečnou periodiku pro kontrolu i rychlého stisku klávesy. Pokud ţádná klávesa stisknuta není, systém spouští kaţdé 2 sekundy vyhodnocovací test. Další otázkou bylo potřeba vyřešit frekvenci přepisů klientské obrazovky. Původní návrh počítal s přepisem kaţdých 10 sekund. Jenţe vizuálně není tento efekt příliš pěkný14, a tak jsem zvaţoval redukci frekvence přepisu obrazovky na minimum. Postupně jsem testováním a implementací vyhodnocovací funkce fCheck-Change docílil stavu, ţe se konzola obnovuje jen v případě takové změny, která má skutečný vliv na zobrazované informace. Funkce přitom kontroluje stav 6 unikátních míst na sdíleném úloţišti kaţdé 2 vteřiny. Malá nepozornost můţe způsobit zástavu klienta, ale klient o tom nebude nijak spraven. Jedná se aktivaci funkce Quick-Copy (ve vlastnostech terminálového okna). Pokud si totiţ omylem označíme např. jeden znak v terminálovém okně myší (inverze do bílé barvy), konzola se zastaví a do stisku klávesy „enter“ či „esc“ nedělá nic. Abychom předešli nepříjemnému zjištění, ţe nám skript pár hodin nejede, implementoval jsem zobrazování teček, symbolizující čekání na reakci, viz následující obrázek, klientské konzoly dohledovacího systému. Obrázek 38.

Ukázka konečné podoby klientské konzoly


14

Ačkoliv vlastní přepis trvá jen několik milisekund, je viditelný a také trochu záleţí na mnoţství serverů.

Při pokusu zobrazit cca 200 serverů uţ bylo zpoţdění přepisu výrazně citelné.

72

V rámci testování přepisu, jsem já, ale i kolegové došli k závěru, ţe tím, ţe se konzola přepisuje jen jednou za 15 minut, pokud nenastane nějaká událost, a protoţe máme všichni tyto konzole na zvláštním monitoru, periferním citlivým viděním vţdy zaregistrujeme přepis a konzolu zkontrolujeme. Na základě rozšiřujících poţadavků mých kolegů, jsem ještě implementoval kontrolu poslední verze klienta, viz levý horní roh na obrázku 38.

4.2.9

Klient: Vyhodnocovací modul

Tento modul je sloţen ze dvou důleţitých funkcí. O jedné jsem se jiţ zmínil v předešlé kapitole, druhá se spouští jen podmínečně. fCheck-Change – sleduje změny v adresářové struktuře fChange-State - provede změny ve vizualizaci serverů na základě souborů v hlídané adresářové struktuře. Právě funkce fChange-State opět vyuţívá persistentní adresářovou strukturu. Je tedy jedno, kdy skript spustíme, vţdy se nám zobrazí stejný stav. O rozdělení sufixů a prefixů serverového jména se postará následující kód. if(test-path $global:workPath\PPING\$server){$srv.sufix = "-U"} elseif(test-path $global:workPath\PUPTM\RBT$server*){$srv.sufix = "-R"} elseif(test-path $global:workPath\PUPTM\WMI$server*){$srv.sufix = "-W"} elseif(test-path $global:workPath\PDISK\$server*){$srv.sufix = "-W"} else {$srv.sufix = " "} if($hoursleft -le 48) {$srv.prefix = " *"} else {$srv.prefix = " "} if(test-path $global:workPath\FIXING\$server){$srv.fixing = 1} else {$srv.fixing = 0}

Kontrola uvedených změn v adresářové struktuře je postavená na změně posledního datumu zápisu (LastWriteTime) do sdílené sloţky. Pro účely našeho monitoring je tento stav plně vyhovující. Pokud například přestane fungovat nějaký server, vytvoří se soubor s názvem konkrétního serveru do sloţky PPING. Soubor, ale i sloţka získají stejné datum posledního zápisu a vyhodnocovací modul zareaguje na změnu obnovou konzoly.

73

4.2.10 Klinet: Operativní modul A na závěr si popíšeme modul, který má nastarost interakci uţivatele s dohledovacím systémem. Právě zde by se měly promítnout všechny původní poţadavky na systém, které jsme si definovali v kapitole Poţadavky. Do operativního menu se dostaneme pomocí stisku jakékoliv klávesy, nicméně nápověda nás vyzývá k pouţití ENTERu viz obrázek 38. Zobrazí se nám výpis činností, které můţeme jako klienti provést. Obrázek 39.

Výřez z konzole uţivatele


Všechny funkce „P-U-D-S-H“ jsou realizovány jednoduchou podmínkou stisknuté klávesy $key a spouštějící většinou jednořádkový kód, kdy P-U-D spouští nařízené kontroly a H zobrazí historii do Out-GridView výstupu. Funkce výpisu restartu serverů [S], se realizuje v rámci klientské konzoly a její průběh je zaznamenán na obrázku v příloze č.1. Po stisku klávesy S následuje dotaz, kolik dní zpátky si přejeme vidět restarty a na základě této informace vypíše poţadované servery datumy a přepočtem na dny a hodiny. Posledních 48 hodin je řešeno vizuálním zvýrazněním, aby bylo patrné, které systémy byly restartovány. Funkce „A-L-F“ mají momentálně na starost jen obsluhu UPTM testu. [A] akceptace jednoho serveru – uţivateli se vypíší všechny akceptovatelné servery s pořadovým číslem. Klient jen vybere číslo, na následující dotaz doplní krátký komentář a enterem se dostane zpátky to konzole. Akceptace zapíše tuto skutečnost do historie pomocí transakčního souboru. [L] akceptace všech serverů – pro případy hromadných restartů nám tato funkce nabídne rychlou formu akceptace. [F] opravování – V případě potřeby, lze označit server na které provádíte nějakou činnost. Stejně jako v případě A, se zobrazí seznam serverů a my si vybereme jeden server. 74

4.2.11 Vyhodnocení fáze “Rozpracování” Cílem této fáze bylo, nejen postavit robustní architektonický základ, který nejen ukáţe správnost jednotlivých rozhodnutí a vlastní funkcionalitu skriptu a pomůţe identifikovat rizika, která projektu hrozí, ale vytvoří jiţ dostatečně silný a stabilní produkt, který budeme moci nasadit na počítačích zákazníka. Popsali jsme si i nasazení dalšího modulu, jehoţ implementace byla velmi triviální a to jak na straně serveru, tak klienta. Pokud pro jakékoliv další testy bude platit zmíněná „presumpce funkčnosti“, je tento model nasazení velmi vhodný a jeho pouţití rychlé a účinné pouţití mohu jen doporučit. Finální verze produktu je, dle mého soudu dostatečně stabilní a svou funkcionalitou pokrývá všechny původní poţadavky. Při vlastním vývoji jsem pouţil celou řadu diagramů UML jazyka, které jsem aplikoval jako analytické či návrhové modely a na jejich základě, jsem vytvářel konkrétní zdrojový kód. Myslím si, ţe navrţená metodika splnila svá očekávání a ţe vývoj proběhl dle předpokladů a dá se vyhodnotit jako úspěšný. Na závěr překládám, spíše jen informativně, údaje o velikosti jednotlivých skriptů, tedy výsledných artefaktů, nutných pro běh dohledovacího systému. Hlavní serverový skript Klientský skript Test PING Test UPTM Test DISK SMSmodul Celkem

- má celkem 501 řádek kódu, 19 487 bytes - má celkem 568 řádek kódu, 19 451 bytes - má celkem 155 řádek kódu, 5 683 bytes - má celkem 68 řádek kódu, 2 088 bytes - má celkem 156 řádek kódu, 5 007 bytes - má celkem 78 řádek kódu, 2 818 bytes 1526 řádek kódu, 54 534 bytes

75

5 Nasazení produktu do provozu V této krátké kapitole se podíváme na nasazení produktu do provozu a odzkoušení všech funkcionalit na samotných zákaznících. Metodika UP říká, ţe tato fáze končí tím, ţe jsou splněny všechny poţadavky, produkt je spuštěn v reálním provozu a zákazník je spokojený. Podíváme-li se do původního zadání, liniový vedoucí chtěl, aby testování proběhlo nejprve na praţských serverech, tedy zmíněných 79 strojích, a tepre později, pokud bude vše v pořádku, nasadíme produkt pro celý německý tým. Na začátku dubna jsme se s vedoucím dohodli, ţe testování bude probíhat další 3 měsíce, coţ by nám mělo poskytnout čas na opravu případných chyb a rozšíření funkcionality dle nových poţadavků. Proto fáze „Zavedení“ dle metodiky UP bude dokončena aţ ex post, po odevzdání diplomové práce.

5.1

Server

Serverový skript, byl otestován na systémech MS Windows XP I MS Windows Server 2003. Serverová strana byla testována po dobu 14. dní a to jak spuštěním v konzole, tak jako úloha na pozadí systému spuštěná za pomoci „Plánovače úloh.“(Job Scheduler). Na serverové straně jsem za celou dobu testování nenarazil na váţnou chybu. Na následujícím obrázku je graf vytíţenosti systému Windows XP, po spuštění dohledovacího systému. Konfigurace dohledovacího systému byla nastavena na 8 serverů do jedné vlny, coţ je reţim úsporného zatíţení (tj. se spustí jen 10 skriptů s testy). Obrázek 40.

Zatíţení CPU a RAM při spuštění 10 úloh na jednou.

Zdroj: vlastní tvorba

76

Přesto je na obrázku patrné vysoké zatíţení procesorů ve chvíli spouštění právě těch deseti testů v jeden okamţik. Při spuštění 20 testů je špička širší a i červená linka kernelu procesoru vyběhne na několik vteřit aţ k 60 procentům. Kdyţ jsem však do modulu spouštěče umístil vteřinovou pauzu pro spouštění testů, reţije na vyuţití procesoru výrazně klesla. Obrázek 41.

Zatíţení CPU a RAM při spuštění 10 úloh se vteřinovou pausou.


Následující obrázek zachycuje první minutu spuštění serveru dohledovacího systému ve vizuálním reţimu konzoly (tedy ne přes plánovač úloh). ForceUPTM spouští test vţdy při prvním spuštění konzoly, dále v testu kola vţdy vidíme, kdy bude jaký test spouštěn. PING a SMS kaţdých 60 sekund, UPTM kaţdých 600 sekund a DISK kaţdých 1800 sekund. Obrázek 42.

Ukázka konzoly serveru

Zdroj: Vlastní tvroba

77

5.2

Klient

Návrh a realizace klienta mne i mé kolegy uspokojuje. Schopnost konzole reagovat na vnější podněty během 2 vteřin je určitě vítaná, navíc je tímto i splněna podmínka synchronizace klientů. Protoţe v tom největším rozptylu, se bude jednat právě je o dvě zmíněné vteřiny, které mohou dva klienty dělit od zjištění nějaké změny na dohledovaných serverech. Zatímco u serveru byl kladen důraz hlavně na funkčnost, a ta se prozatím prokazuje, u klienta byly ve fázi testování prováděny hlavně vizuální změny. Z pohledu funkčnosti, jsme narazili na jeden jediný problém, který je spíše vizuálního charakteru, neţ ţe by měl zásadní vliv na nefunkčnost systému. Ve chvíli, kdy se spustí na serveru test UPTM a vyhodnocovací modul začne zapisovat výsledky do XML souboru, klient se pokusí ze souboru číst a pokud dojde k souběhu dotazů na čtení a zápis, klientovi je zamítnut přístup, proměnné ze souboru se nenačtou a klient vidí celou stránku chybových hlášek. Modul ale díky chybějící informaci automaticky spustí načtení znova a to se jiţ podaří. Nicméně je to chyba, kterou nemám vyřešenou ve chvíli ukončení změn zdrojového kódu za účelem dopsání diplomové práce a budu se jí věnovat aţ později.

5.3

Náměty a rozšíření

Pro příští měsícíce jsem se rozhodl, implementovat testy na vyuţití procesoru (CPU) a paměti (RAM), a implementovat systém zpětné kontroly dostupnosti serverové strany dohledovacího serveru. Tato funkcionalita by měla zjistit redundanci serveru pro případ neočekávaného výpadku. Dále bych rád implementoval modul, který bude vyhodnocovat Event-Logy, protoţe právě navrţený dohledovací systém je nyní přímo stvořen k této časově velmi náročné operaci. Ruční vyvolání příkazu Get-EventLog ze vzdáleného serveru zabere (v závislosti na specifikách dotazu) něco mezi 1 aţ 6 minutami. Coţ je velký časový interval, ale právě navrţený dynamický systém, by měl takovýto úkol dobře zvládnout.

78

6 Vyhodnocení užitečnosti produktu Pokud bych se vrátil do třetí kapitoly, kde jsem popisoval naše oddělení a systém dohledování serverů, musím jen konstatovat, ţe tvorba tohoto produktu rozhodně nebyla, z pohledu vyuţitelnosti, ztrátou času. Navrţený systém, je připraven na snadné rozšíření o další moduly, kdy máme na výběr hned dva vzory implementace. Vzor typu „test PING“, který se plně samostatný a vyuţívá jen společných funkcí pro zasílání SMS a zápisu do historie systému a který jsme pouţili při rozšíření funkcionality dohledovacího systému o test DISK a vzor typu „test UPTM“, který vyţaduje implementaci samostatné vyhodnocovací funkce do stejnojmenného modulu na serverové straně dohledovacího systému. Rychlost a spolehlivost celého monitoringu, jak serverové, tak klientské části, je rovněţ nadmíru uspokojivá a myslím si, ţe nic nebrání nasazení produktu do celého oddělení správy aplikačních serverů. Navíc je celý systém velmi univerzální, coţ znamená, ţe by se dal vyuţít nejen ve zmiňovaném bankovním prostředí, ale i kdekoliv jinde. Fakt, ţe Powershell 2.0 je nainstalován jako součást systému na všech nových operačních systémech rodinz MS Windows, dohledovací systém svým návrhem nevyţaduje ţádné další instalace a dohled můţe být spuštěn, po úpravě proměnné $global:workPath a konfiguraci SMS skriptu, resp. SMTP serveru, víceméně kdekoliv a kdykoliv. Jako závěrečný bonus bych pak zmínil fakt, ţe díky snaze o zajištění přehlednosti celého kódu, dodrţení pravidla čistého řídícího cyklu, zapouzdřenosti všech funkcí a dostatečné míře komentářů, je celý kód připraven i jako inspirace pro začínající či pokročilé programátory v tomto výtečném skriptovacím prostředí administrátorů systémů rodiny Microsoft Windows.

79

Závěr V teoretické části této diplomové práci jsem chtěl seznámit odbornou veřenost s novými funkcemi a příkazy skriptovacího prostředí Windows Powershell 2.0. Myslím, ţe tato teoretická část přinesla celou řadu zajímavých momentů. Ukázal jsem, ţe ne všechny informace, prezentované výrobcem, jsou pravdivé a ţe pouţití některých nových příkazů je přinejměnším diskutabilní. Na druhou stranu, většina cmdletů, funkcí a metod pracuje dle očekávání rychle a efektivně, a díky ohromné flexibilitě a provázanosti celého prostředí, se na kaţdý případný problém, najde náhradní technické řešení. V praktické části, jsem představil reálné síťové prostředí nadnárodní banky i problémy, se kterými se oddělení správy aplikačních serverů při dohledování potýká. Společně s liniovým vedoucím jsme na závěr zadali rámcové poţadavky na vývoj nového dohledovacího produktu pro toto oddělení. Při výběru metodiky, jsem volil mezi úkolocentrickým a hodnotocentrickým přístupem k vývoji. Zvaţoval jsem nejrůznější aspekty budoucího vývoje, jako vyuţití navrhování modelů v rámci skriptovacího prostředí, zaţitý způsob tvorby skriptů a neméně důleţitým argumentem pro výběr metodiky byl i fakt, ţe jsem na vývoji produktu pracoval sám. Zvolená metodika Unifikovaného Procesu vývoje aplikací splnila má očekávání. Metodiku jsem sice musel přizpůsobit poţadavkům konkrétního projektu i stereotypům navyklého chování při tvorbě kódu, přesto však vzniklý metodický rámec dovedl celý vývoj ke zdárnému konci. Výsledný produkt, tedy dohledovací nástroj fungující v běhovém prostředí Windows Powershell 2.0, bych vyhodnotil jako zdařilý a tímto potvrzuji naplnění cíle této práce. Podařilo se mi vytvořit velmi stabilní monitorovací systém, který za svou jednoduchostí, spolehlivostí a flexibilitou schovává desítky hodin čistého času návrhů, testování a samotného programování. Výsledný produkt je však velmi univerzální a jeho pouţití je vhodné pro všechny podporované operační systémy rodiny MS Windows. Myslím, ţe se mi zároveň podařilo dokázat, ţe prostředí Windows Powershell 2.0, i přes některé své chyby, je skutečně dobrým a univerzálním prostředím pro dohledování serverů a jeho široké moţnosti vyuţití se dají nejen snadno aplikovat pro přímou správu systémů, ale i jednoduše implementovat do mnou navrţeného dohledovacího systému.

80

Ačkoliv k nasazení vyvinutého nástroje do ostrého provozu bankovní organizace zatím nedošlo, testování na vybraném vzorku serverů dokázala výše zmiňovaná tvrzení. Přesto doufám, ţe tímto produktem alespoň trochu pozvednu úrověň poskytovaných sluţeb našeho oddělení a tím i jeho prestiţ v rámci centrální podpory sluţeb IT v celé naší bankovní organizaci.

81

Seznam použité literatury Tištěná dokumentace [1]

ARLOW, Jim a Ila NEUSTAD. UML 2 a unifikovaný proces vývoje aplikací: Objektově orientovaná analýza a návrh prakticky. Druhé aktualizované a doplněné vydání. Brno: Computer Press, 2008. ISBN 978-80-251-1503-9.

[2]

GUCKENHEIMER, Sam a Juan J. PEREZ. Efektivní softwarové projekty. 1. vydání. Brno: Zoner Press, 2007. ISBN 978-80-86815-62-6.

[3]

HYPŠ, Tomáš. Skriptovací jazyky - PowerShell v praxi. Praha, duben, 2010. Bakalářská práce. BIVŠ, Praha. Vedoucí práce Ing. Vladimír Beneš.

[4]

KADLEC, Václav. Agilní programování: Metodiky efektivního vývoje softwaru. První vydání. Brno: Computer Press, 2004. ISBN 80-251-0342-0.

[5]

MALINA, Patrik. Jak vyzrát na Windows PowerShell 2.0. První vydání. Brno: Computer Press, a.s., 2010. ISBN 978-80-251-2732-2.

[6]

MALINA, Patrik. Microsoft Windows PowerShell : Podrobný průvodce skriptováním. Brno : Computer Press, a.s. 2007. 340 s. ISBN 978-80-251-1816-0.

Internetové odkazy [7]

BECHNÝ, Ondřej. Návr metodiky vývoje softwaru z pohledu samostatného vývojáře. Brno, 2010. Diplomová práce. Masarykova univerzita Fakulta informatiky. Vedoucí práce RNDr. Jan Pavlovič, Ph.D.

[8]

BERRY. MCB SYSTEMS. PowerShell: Get-WinEvent vs. Get-EventLog | MCB Systems [online]. [cit. 2012-02-08]. Dostupné z: http://www.mcbsys.com/techblog/2011/04/powershell-get-winevent-vs-geteventlog/

[9]

Fáze metodiky UP. [online]. [cit. 2012-04-15]. Dostupné z: http://pss.tym.cz/prednasky/P04/foil25.html

[10]

JONES, Don. Windows PoweShell Getting Transactional TechNet Magazine. [online]. [cit. 2012-02-10]. Dostupné z: http://technet.microsoft.com/enus/magazine/ff808320.aspx

[11]

MICROSOFT. About_Windows_PowerShell_2.0 [Interní nápověda prostředí]. [cit. 5.1.2012].

[12]

MICROSOFT. How to convert text to numbers in Excel 2002 and in Excel 2003 [online]. [cit. 2012-02-08]. Dostupné z: http://support.microsoft.com/kb/291047 82

[13]

MICROSOFT. Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0) [online]. [cit. 2012-02-05]. Dostupné z: http://support.microsoft.com/kb/968929/en-us

[14]

PowerGUI.org - Free Windows Powershell Community. [online]. [cit. 2012-02-11]. Dostupné z: http://powergui.org/index.jspa

[15]

POWERSHELL.COM. Administrator's Guide to Powershell Remoting Powershell.com – Powershell Scripts, Tips and Resources [online]. [cit. 2012-0206]. Dostupné z: http://powershell.com/cs/media/p/7257.aspx

[16]

RUSSINOVICH, Mark. TCPView and TCPVCon: Get past Netstat’s limitations. [online]. 2005-03-29 [cit. 2012-04-04]. Dostupné z: http://www.windowsitpro.com/article/monitoring-and-analysis/tcpview-andtcpvcon

[17]

ScrumMaster.com.au. [online]. [cit. 2012-02-27]. Dostupné z: http://scrummaster.com.au/Content/images/ScrumCycle.png

[18]

SIDDAWAY, Richadr. Setting the drive letter - Richard Siddaway's Blog [online]. [cit. 2012-02-07]. Dostupné z: http://msmvps.com/blogs/richardsiddaway/archive/2011/08/05/setting-the-driveletter.aspx

[19]

SUBRAMANIAM, Vankat a Andy HUNT. Practices of an Agile Developer: Working in the Real World. První vydání. Raleigh, North Carolina Dallas, Texas: The Pragmatic Bookshelf, 2006. 2006-3-20. ISBN 0-9745140-8-X.

[20]

ÜÇÜNCÜ, Bayram. Developing Factorial Application Using Test Driven Development - CodeProject®. [online]. [cit. 2012-03-26]. Dostupné z: http://www.codeproject.com/Articles/320791/Developing-Factorial-ApplicationUsing-Test-Driven

[21]

WILSON, Ed. Use the Set-WmiInstance PowerShell Cmdlet to Ease Configuration - Hey, Scripting Guy! Blog - Site Home - TechNet Blogs [online]. [cit. 2012-02-07]. Dostupné z: http://blogs.technet.com/b/heyscriptingguy/archive/2011/10/20/usethe-set-wmiinstance-powershell-cmdlet-to-ease-configuration.aspx

83

Seznam použitých obrázků Obrázek 1.

Výpis instalovaných verzí .NET Framework a určení aktuální pouţívané ............ 11

Obrázek 2.

Cesta k souborům Windows Powershell 2.0 .......................................................... 12

Obrázek 3.

Výpis procesů Powershell.exe ze vzáleného počítače pomocí rozhraní WMI ....... 13

Obrázek 4.

Aplikace metody Terminate() na vzdáleném serveru ............................................ 14

Obrázek 5.

Výpis konkrétního procesu ze vzdáleného systému pomocí Get-Process ............. 15

Obrázek 6.

Svolení ke vzdálené správě .................................................................................... 16

Obrázek 7.

Jednorázové interaktivní připojení pomocí WinRM .............................................. 17

Obrázek 8.

Přetrvávající interaktivní připojení pomocí WinRM ............................................. 17

Obrázek 9.

Ukázka pouţití automatizovaného spouštění na vzdálených systémech ................ 18

Obrázek 10.

Ukázka spuštění úlohy na pozadí systému ............................................................. 19

Obrázek 11.

Pouţití příkazu Set-WmiInstance ........................................................................... 21

Obrázek 12.

Příklad pouţití příkazu Invoke-WmiMethod ......................................................... 22

Obrázek 13.

Tabulka č. 1 experimentálního meření výpisu událostí systému ............................ 23

Obrázek 14.

Tabulka č. 2 experimentálního meření výpisu událostí systému ............................ 24

Obrázek 15.

Aplikace různých filtrů v tabulce GridView .......................................................... 26

Obrázek 16.

Ukázka řazení zobrazených dat a) s desetinnou čárkou, b) bez čárky ................... 26

Obrázek 17.

Příklad zpracování události přes .NET Framework ............................................... 28

Obrázek 18.

zpracování události přes WMI pouţitím globální proměnné ................................. 29

Obrázek 19.

Zpracování události přes WMI pouţitím fronty událostí ....................................... 30

Obrázek 20.

Ukázka pouţití transakcí v Powershellu ................................................................ 31

Obrázek 21.

Pokuţití modulů v Powershellu 2.0 ....................................................................... 33

Obrázek 22.

Ukázka pouţití Powershell_ISE ............................................................................. 34

Obrázek 23.

Úkolocentrický a hodnocentrický přístup .............................................................. 43

Obrázek 24.

Fáze podle metodiky UP ........................................................................................ 48

Obrázek 25.

Případy uţití – klientská strana .............................................................................. 54

Obrázek 26.

Případy uţití – serverová strana ............................................................................. 55

Obrázek 27.

Scénář poţadavku „SpustitTesty:UPTM“ .............................................................. 56

Obrázek 28.

Scénář vyhodnocení testu UPTM na serverové straně ........................................... 56

Obrázek 29.

Návrh diagramu nasazení ....................................................................................... 57

Obrázek 30.

Výpis posledního restartu vzdáleného serveru ....................................................... 59

Obrázek 31.

Demonstrace chyby Powershellu na Windows XP ................................................ 60

Obrázek 32.

Prototyp klientské konzoly dohledovacího systému .............................................. 62

Obrázek 33.

Diagram aktivit řídícího cyklu ............................................................................... 64

Obrázek 34.

Modul Spouštěč testů (funkce fTest-Launcher) ..................................................... 65

Obrázek 35.

Vytvoření transakčního souboru ............................................................................ 67

84

Obrázek 36.

Stavový diagram testu PING .................................................................................. 68

Obrázek 37.

Optimalizované zobrazení funkce fCheck-FolderStructure ................................... 70

Obrázek 38.

Ukázka konečné podoby klientské konzoly ........................................................... 72

Obrázek 39.

Výřez z konzole uţivatele ...................................................................................... 74

Obrázek 40.

Zatíţení CPU a RAM při spuštění 10 úloh na jednou. ........................................... 76

Obrázek 41.

Zatíţení CPU a RAM při spuštění 10 úloh se vteřinovou pausou.......................... 77

Obrázek 42.

Ukázka konzoly serveru ......................................................................................... 77

85

Příloha č. 1

86

PowerShell 2.0 Dohledování serverů

Recommend Documents