Návrh databázového systému pro správu virtuálních serverů

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze

Tomáš Táborský

Návrh databázového systému pro správu virtuálních serverů Bakalářská práce

2011

Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Návrh databázového systému pro správu virtuálních serverů zpracoval samostatně a použil pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 20. května 2011

Podpis

Abstrakt Tato bakalářská práce se zabývá navržením relační databáze pro reálnou agendu správy serverů. Vychází z informací získaných analýzou rozsáhlého souboru dat. Práce je zaměřena na vytvoření struktury databáze, do které budou přesunuta data ze souboru MS Excel. Primárním požadavkem je zpřehlednění a usnadnění přístupu k datům. Celý projekt probíhá za těsné spolupráce s budoucím uživatelem. Teoretická část uvede čtenáře do problematiky relačních databází. V praktické části je čtenář seznámen s prostředím, které bude databáze zachycovat. Následně detailně ukazuje průběh vzniku tabulek databáze a změny jejich struktury s přibývajícím postupem projektu.

Abstract This bachelor work takes an interest in designing a relational database for real agenda in a server administration. It's based on the information obtained from an analysis of a large data file. Work is focused on creating a database structure to store data from large MS Excel file. Main requirement of the database is to be clearly organized and to make an easy access to data. The whole project is made in close cooperation with the future user. A reader can use some basic facts regarding the relational databases from the theoretical part. The practical part starts with an introduction to the company environment, hardware and virtual layers which is what the database is about. Next it gives a detailed view of the database tables' creation and the changes through the project.

Obsah Abstract ......................................................................................................................................... 3 Úvod .............................................................................................................................................. 7 1.

Teoretická část ...................................................................................................................... 8 1.1 Databáze ............................................................................................................................. 8 1.2 Relační databáze, historie a principy .................................................................................. 8 1.3 Normalizace ...................................................................................................................... 10 1.4 Virtualizace ........................................................................................................................ 11

2.

Praktická část - Návrh databáze .......................................................................................... 14 2.1 Shrnutí současného stavu ................................................................................................. 14 2.2.1 Fyzické a virtuální servery .......................................................................................... 14 2.2.2 Rozložení serverů ....................................................................................................... 15 2.2.3 Současné evidence ..................................................................................................... 15 2.2 Specifikace požadavků ...................................................................................................... 16 2.3 Popis jednotlivých částí systému ...................................................................................... 16 2.3.1 Servery ....................................................................................................................... 16 2.3.2 Cluster ........................................................................................................................ 17 2.3.3 Sítě a síťová připojení ................................................................................................. 17 2.3.4 Bezpečnost dat, management serverů a jejich virtualizace ....................................... 18 2.3.5 Evidence serverů ........................................................................................................ 19 2.4 Návrh databáze ................................................................................................................. 20 2.4.1 Volba metody návrhu ................................................................................................. 20 2.4.2 Identifikace základních položek ze zdrojového souboru ........................................... 20 2.4.3 První konzultace ......................................................................................................... 23 2.4.4 Základní tabulky ......................................................................................................... 24 2.4.5 Vztahy tabulek a normalizace .................................................................................... 26 2.4.6 První normální forma ................................................................................................. 27 2.4.7 Druhá normální forma ............................................................................................... 28 2.4.8 Třetí normální forma .................................................................................................. 28 2.4.9 Číselníky...................................................................................................................... 30 2.4.10 Finální konzultace..................................................................................................... 32 2.4.11 Integritní omezení .................................................................................................... 32 2.5 Rozpis tabulek a atributů .................................................................................................. 35 5

2.5.1 Tabulka KOMPONENTA .............................................................................................. 35 2.5.2 Tabulka VIRTUAL ........................................................................................................ 36 2.5.3 Tabulka SESTAVY ........................................................................................................ 38 Závěr............................................................................................................................................ 39 Seznam použitých zdrojů ............................................................................................................ 40

6

Úvod Předmětem bakalářské práce je návrh řešení relační databáze pro reálnou agendu. Práce popisuje vývoj a výběr požadavků pro systém, jejich aplikaci na současnou situaci a tvorbu databáze nutné k řešení daného problému. Téma a náplň práce vychází z reálné situace. Během mého působení v oddělení ICT services jsem se setkal s komplikovanou strukturou jak hardwaru a návazných virtuálních prostředí, tak databází evidujících tyto skutečnosti. Mojí pracovní náplní je udržovat dvě z evidencí hardwaru v aktuálním stavu. Vzhledem k tomu, že průměrně každý den vzniká nový server, méně často některé zanikají či dochází k jiným změnám, jsou nutné každodenní aktualizace. Aktuálně je používán pro osobní potřeby přehled hardwaru v excelovém souboru. Ten je při takovém množství změn nevyhovující vznikal po dobu zhruba čtyř let a shrnuje informace obsažené v jiných evidencích, také další záznamy, které se do těchto evidencí nezaznamenávají a velké množství poznámek a pracovních sloupců. Bakalářské práce má za cíl navrhnout funkční databázi, která splní předem stanovené podmínky. Vysvětluje postupný vznik všech kritérií, jejich výběr v závislosti na reálné potřebě a jejich zařazení do databáze. Práce objasňuje analýzu a všechny procesy během ní probíhající, rozhodovací procesy a následné doplnění vybraných kritérií do základních tabulek. Současně s analýzou probíhá tvorba databáze, prověřování její funkčnosti a konfrontace s požadavky reálného prostředí. Na základě skutečných problémů a potřeb, které se vyskytují v praxi v podmínkách dnešního „počítačového“ světa, je vidět, že lze dobře využít teoretické poznatky tak, aby byly jeho výsledky k užitku v situacích, které to umožňují. Vzhledem k citlivosti dat firmy a situaci na bankovním trhu není v této práci uvedeno, na přání zaměstnavatele, jméno firmy.

7

1. Teoretická část 1.1 Databáze Databáze je velmi zjednodušeně určité místo, kam ukládáme všechna potřebná data – je to zjednodušená definice, ale velmi výstižná. V databázi můžeme mazat a editovat záznamy, ale také vyhledávat a různě třídit. Databáze poskytuje rychlejší přístup k datům než soubory. Databáze umožňuje přímý přístup k datům. Databáze má zabudovaný mechanismus pro paralelní přístup k datům. Databáze umožňuje pomocí dotazů snadno vybírat množiny dat, která vyhovují zadaným kritériím. Databáze se dají rozdělit ještě do několika druhů – relační databáze, objektové databáze a objektově-relační databáze. Relační databázové systémy jsou dobré pro řízení velkého množství dat Objektově orientované programovací jazyky slouží k vyjadřování složitých vztahů mezi objekty [čerpáno z 12]

1.2 Relační databáze, historie a principy Pojem relační databáze zavedl 1969 Dr. Edgar F. Codd ve firmě IBM. V roce 1970 zveřejnil tuto teorii v publikaci „A Relational Model of Data for Large Shared Data Banks“ a poskytl tím alternativu k síťovému, hierarchickému či hvězdicovému modelu databází. Jeho model je založen na predikátové logice a teorii množin a definuje tak operace, které lze na daty provádět, způsob jejich reprezentace a také způsob ochrany. „ Relační databázové systémy vykazují následující charakteristické vlastnosti: Veškerá data se pomyslně dají reprezentovat v pravidelně uspořádaných strukturách s řádky a sloupci, kterým se říká relace. Všechny hodnoty v databázi jsou skalární. To znamená, že v každé konkrétní pozici řádku a sloupce dané relace se nachází jedna (a to přesněji právě jedna) hodnota. Operace v databázi se provádějí vždy nad celou relací a jejich výsledkem je opět jiná relace; tomuto mechanismu se říká uzávěr.“ [1, str. 9]

8

Název „relační“ tedy nevychází z relací mezi daty, ale z entit, které Dr. Codd nazval relacemi a které představují tabulky. Následně mechanismus uzávěr způsobuje, že dotazem do databáze vzniká další relace, nad kterou je opět možno provést dotaz, jako by se jednalo o původní tabulku. V druhém bodě se objevuje požadavek na „jedinou hodnotu“, což je však velmi subjektivní a na zvoleném datovém modelu závislý výraz. O žádném modelu, který vytvoříme, nemůžeme tedy s jistotou tvrdit, že je absolutně správný. „Vhodnost konkrétního datového modelu závisí na datech, která podle něj máme reprezentovat.“ [1, str. 10] Vzhledem k tomu, že tabulka je relací, nemohou se zde vyskytovat identické řádky a relace je, již se svého principu, neuspořádaná. Z těchto důvodu musí existovat v každé tabulce jednoznačná identifikace řádku a tabulka nesmí obsahovat stejné záznamy. Pokud se vyskytuje více možností pro jednoznačnou identifikaci, pak se jedná o kandidátní klíče. Z těchto klíčů se vybere primární klíč, a ostatní zůstanou alternativními. V praxi je však většinou jen jeden primární klíč. Dr. Codd ve své práci o relačních modelech, publikované v roce 1985, specifikuje 12 pravidel, které by měly tyto modely splňovat: 1. „Pravidlo informace: Všechny informace v relační databázi se na logické úrovni reprezentují explicitně hodnotami v tabulkách. 2. Pravidlo zaručeného přístupu: Musí být zajištěno, aby úplně každý údaj v relační databázi byl logicky přístupný použitím názvu tabulky, hodnoty primárního klíče a názvu sloupce. 3. Systematické ošetření prázdných hodnot: Prázdné hodnoty (nikoliv nuly, či prázdné řetězce) jsou systematicky plně podporovány RDBMS pro reprezentaci chybějících informací a neplatných informaci nezávisle na datovém typu.(Typicky řešeno hodnotou NULL). 4. Popis struktury založený na relačním modelu: Popis databáze se na logické úrovni reprezentuje stejně, jako běžná data tzn. v relacích, na které se mohou oprávnění uživatelé dotazovat stejně jako na jakoukoliv jinou relaci. 5. Pravidlo komplexního datového jazyka: Relační systémy mohou podporovat více jazyků a režimů přístupů, ale musí existovat minimálně jeden jazyk, jehož příkazy jsou vyjádřitelné nějakou dobře definovanou syntaxí jako řetězce znaků, který podporuje: o o o o o o

Definici dat Definici pohledu Manipulaci s daty Omezení integrity Autorizaci Vymezení transakce V současnosti používá většina DBMS jazyk SQL 6. Aktualizace pohledu: Všechny aktualizovatelné pohledy je možno aktualizovat systémově. 7. Vysokoúrovňová manipulace s daty: Zpracování základní či odvozené relace se, jako jediný operand, aplikuje jak na vyhledávání, tak vložení a změnu dat. 9

8. Fyzická datová nezávislost: Aplikace a terminály zůstávají logicky nedotčeny změnami v reprezentaci úložiště nebo přístupových metodách. 9. Logická datová nezávislost: Aplikace a terminály jsou logicky nedotčeny, pokud jsou v tabulkách provedeny změny v uchování informací. 10. Nezávislost integrity: Integritní omezení (viz dále) musí být definovatelné v datovém jazyku v databázi, nikoliv v aplikaci. 11. Distribuční nezávislost: Databázový jazyk musí být schopen manipulovat s daty umístěnými na jiném počítačovém systému. 12. Pravidlo nenarušení: Pokud je v systému více jazyků, žádný z nich nesmí mít možnost manipulovat s daty v rozporu s integritními omezeními.“ [Body citovány z 8] Tato pravidla určují, jak by měl vypadat ideální relační systém a většina ze současných databází se snaží tato pravidla dodržovat. [čerpáno z 1, 4, 8]

1.3 Normalizace Relační databáze by měla splňovat normální formy, které omezují, až eliminují duplicity dat, rozkládají složité tabulky na jednodušší a zajišťují efektivitu využití databáze. „Čím větší normální formu schéma splňuje, tím je snadnější ho udržovat v konzistentním stavu a později rozšiřovat.“ [13] Dnes se uvádí až osm normálních forem, které na sebe postupně navazují: 1. Normální forma o „O relaci říkáme, že je v první normální formě, pokud jsou všechny její atributy definovány nad skalárními obory hodnot (doménami).“ [1, str. 32] 2. Normální forma o

„Relace je v druhé normální formě, pokud je v první normální formě a navíc všechny její atributy jsou závislé na celém kandidátním klíči.“ [1, str. 34]

3. Normální forma o „O relaci říkáme, že je ve třetí normální formě, pokud je ve druhé normální formě a navíc všechny její neklíčové atributy jsou vzájemně nezávislé.“ [1, str. 32] Další normální formy nejsou příliš obvyklé. Boyce-Coddova normální forma (BCNF) o Jedná se v podstatě o přísnější variaci na 3. NF o

„Relace se nachází v BCNF, jestliže pro každou netriviální závislost X -> Y platí, že X je nadmnožinou nějakého klíče schématu R.“ [9]

4. Normální forma o „Tabulka je ve čtvrté normální formě, je-li v BCNF a popisuje pouze příčinnou souvislost (jeden fakt).“ [9] 10

5. Normální forma o „Relace je v páté normální formě, pokud je ve čtvrté a není možné do ní přidat další atribut (skupinu atributů) tak, aby se vlivem skrytých závislostí rozpadla na několik dílčích relací.“ [9] 6. Normální forma a doménová/klíčová normální forma se pak využívají jen ve velmi vzácných případech. Vytvořit databázi ve vysoké normální formě je poměrně obtížné. Záleží na posouzení, zda databáze opravdu bude velmi rozsáhlá a opravdu bude vyžadovat všechny tyto podmínky pro bezproblémový provoz a růst. Tak trochu negativním efektem normálních forem je rozbíjení databáze na menší a jednodušší tabulky. Co je pro konzistenci databáze významná pomoc, je pro uživatele, který chce získat data ze dvou vzdálenějších tabulek dlouhá práce navíc. Pokud totiž roztříštíme tabulky na velké množství malých, stane se obyčejný select mimo databázovou aplikaci poměrně obtížnou záležitostí. *čerpáno z 1,4,9,16]

1.4 Virtualizace Virtualizace je přenos roviny operačního systému a aplikací o jednu úroveň výše, kde ztrácí přímou závislost na určitém hardwaru. Tato závislost je posunuta hypervisor* vrstvou, která běží na hardwaru a je schopna zprostředkovat přístup k CPU, RAM, síťovým adaptérům apod. vyšší vrstvě dle nastavení administrátora. Virtualizace v oblasti serverů slouží ke konsolidaci serverů za účelem zvýšení flexibility a snížení nákladů. „Virtualizační vrstva, která se nachází mezi hardwarem a operačním systémem, se nazývá hypervisor.“[7] Dnešní počítače jsou určeny pro provoz jednoho operačního systému na kterém zpravidla běží více aplikací. Virtualizace umožňuje vytvořit na jednom hardwaru několik virtuálních strojů s různými operačními systémy a zpravidla s jednou běžící aplikací pro odstranění interakcí mezi těmito aplikacemi. Virtualizované stroje mohou lépe využít možností hardwaru, protože je virtuálním strojům přiřazeno takové množství CPU jader, RAM a diskového prostoru, jaké vyžadují běžící aplikace. Takto lze rozdělit systémové prostředky hardwaru a zajistit jak optimální funkci aplikací, tak rezervu pro případnou vysokou zátěž. Virtualizace přináší řadu výhod a některé nevýhody. Jsou-li provedeny vhodné analýzy pro přechod do virtuálního prostředí, je možné vyhnout se řadě problémů, které virtualizace přináší, a plně využít její výhody.

*

Technické informace k tématům této práce jsou vyloženy v kapitole 2.3

11

Finanční náročnost virtualizačního procesu je silně závislá na mnoha faktorech. Z hlediska hardwaru je to množství, jeho různorodost a stáří. Z hlediska aplikací také množství, jejich důležitost pro společnost, tedy požadavky na zabezpečení a dostupnost. Vysoká rozmanitost hardwaru a softwaru zvyšuje finanční a časovou náročnost virtualizace z důvodu testování aplikací v novém prostředí. Analyzováním současného stavu lze vyloučit servery s aplikacemi, které nelze virtualizovat, vyloučit hardware, který se blíží konci životnosti nebo je pro virtualizaci nevhodný, navrhnout řešení hardwaru a zvolit vhodnou virtualizační platformu. Samotný přechod z fyzických na virtuální servery zpravidla vyžaduje investice, ale provoz zvirtualizovaného prostředí je levnější a spolehlivější. Velkou výhodou virtuálních serverů běžících na clusterech, např. na ESX clusterech od společnosti VMWare, je vysoká dostupnost. Před virtualizací je zpravidla každá aplikace závislá na běhu určitého serveru. Pokud selže hardware tohoto serveru, není možné spustit aplikaci „ihned“ na jiném serveru (není-li předem připraven jako záložní). Virtuální servery jsou zapouzdřeny do souborů, se kterými lze snadno manipulovat pomocí příslušného softwaru v rámci clusteru, nebo je lze prostým kopírováním klonovat či přenášet do jiných datacenter. Selže li jeden z hostů clusteru, jsou virtuální servery, které aktuálně na hostu běžely, zrestartovány na jiném hostu téhož clusteru a aplikace zaznamenají pouze minimální výpadek. S tím souvisí všeobecná flexibilita clusterů. Tímto způsobem je možné přesouvat virtuální servery mezi hosty clusteru a umožnit tak jejich údržbu či dokonce výměnu hardwaru bez jakýchkoli větších výpadků. Předností virtualizace, která se projeví až u větších organizací s velkým množstvím aplikací je zjednodušení přístupu na servery, jejich zabezpečení a správy jednotlivých serverů. Pokud na fyzickém serveru běží několik aplikací, potřebují na něj přístup všichni, kdo s nimi pracují. Pokud se jedná o citlivé aplikace, je nutné, aby všichni pracovníci byli spolehliví, a je nutné prověřovat všechny, kdo potřebují jednorázový přístup na server k jiné aplikaci. Virtualizace a rozdělení aplikací na jednotlivé servery tuto situaci snadno vyřeší a o přístupy se postarají administrátoři jednotlivých serverů bez nutnosti konzultací mezi týmy. Administrátoři serverů mají také volné ruce v případě restartu, který pak ovlivní pouze jejich aplikaci. Druhou stranou mince je nutnost zakoupit virtualizační software a platit každoročně licenci, zařadit do týmu specialistu na tento software a dále větší závislost na hardware (na jednom serveru mohou běžet desítky až stovky virtuálních serverů. Ceny softwaru a licencí se musí promítnout do úvodní analýzy a ve valné většině případů je toto zvýšení kompenzováno výrazným snížením nákladů na údržbu a provoz hardware

12

serverů. Následkem celého virtualizačního procesu a většiny jeho výhod je právě závislost na hardwaru. Zmenšení serverů zjednoduší většinu úkonů, ale na hosta clusteru se jich tím vejde více. Konsolidace a zakoupení nových serverů odstraní různorodost hardwaru a patrně i zjednoduší servisní požadavky, ale výkonný server může také selhat a ztratí se tak dočasně poměrně velký výkon. Tento problém lze kompenzovat pouze naddimenzováním hardwaru. Pokud se jedná o firmu s více než cca 10 servery, pak cluster musí mít rezervu minimálně jednoho standardního hostu. S tímto limitem je nutno počítat i následně při zvyšování počtu virtuálních serverů a při rozšiřování hardwaru. Pokud se systém někdy dostane do situace, že nemá dost volných prostředků ke kompenzaci pádu jednoho stroje, pak není možné udržet v krizové situaci všechny aplikace v běhu. Vzhledem k tomu, že asi nejlepší servisní smlouva, kterou lze vyjednat je oprava hardwaru do šesti hodin, je jasné, že pro např. pro banku není únosné přijít až na 6 hodin o některé finanční služby. Opomíjení této rezervy sice sníží lehce náklady na provoz, ale může to mít velké důsledky pro celkový provoz firmy. *čerpáno z 6, 7,14,15]

13

2. Praktická část - Návrh databáze 2.1 Shrnutí současného stavu 2.2.1 Fyzické a virtuální servery Databáze se bude zabývat především fyzickými servery. Fyzický server je reprezentován hardwarem, který je zpravidla umístěn z datacentru. Operační systém a aplikace, provozované na daném hardwaru, bude také součástí databáze a to jako „virtuální“ server. Hlavním rozdílem mezi virtuálními servery, kterými se budu dále zabývat, a skutečnými virtuálními servery je vazba k hardwaru. Jako fyzický server je uvažován komplet „virtuálního serveru“ a hardwaru, na kterém je provozován. Skutečný virtuální server přistupuje k hardwaru přes uměle vytvořenou vrstvu, tzv. hypervisor. Slouží k umožnění přístupu virtuálních serverů k systémovým zdrojům typu operační paměť, využití výpočetního času jednotlivých jader procesorů nebo lokální či síťová disková úložiště. Více hypervisorů je následně sdružováno do ESX clusteru.

Obr. 1 – Schematické znázornění prostředí s virtuálními a „virtuálními“ servery.

Nezávislost virtuálních serverů na určitém hardwaru umožňuje, při dostatečných rezervách clusteru, výměnu, opravy, odebrání či přidání strojů za plného provozu veškerých virtuálních serverů a jejich aplikací. Používaný systém VMWare umožňuje snadnou správu a management virtuálních serverů v reálném čase. 14

2.2.2 Rozložení serverů Vzhledem k charakteru projektu je nutné se podrobně seznámit se současným stavem. A to jak se stavem evidence, která se má stát obsahem navrhované databáze, tak s prostředím, které tato evidence popisuje, aby bylo možné v průběhu práce správně rozhodovat o vhodnosti zařazení tabulek, jejich sloupců či vztahů do návrhu. V našem případě je hardware, který tvoří především rack-mountable servery, blade chassis a blade servery, rozmístěn do tří datacenter. V současnosti jsou tato tři datacentra, vzdálená zhruba 15km od sebe. Jsou propojena optickými vlákny a jsou doplněna malým množstvím dalších serverů rozmístěných na pracovištích IT. V datacentrech jsou umístěny servery zajišťující běh celobankovních aplikací, např. databáze klientů, zaměstnanců, evidenční servery, webové servery, klientský přístup k datům a podobně. Tato datacenta jsou pro IT pracovníky relativně dobře přístupná. Druhou, méně početnou skupinou, jsou pobočkové servery. Tyto obstarávají provoz jednotlivých poboček po celé republice a jsou pro správu a údržbu přístupné téměř výlučně přes vzdálené připojení. Většina serverů (odhadem tři čtvrtiny celkového výkonu) v datacentrech jsou blade servery. Tyto servery mají výhodu umístění v blade chassis, která disponují vlastním síťovým připojením, IP adresou pro vzdálenou správu a softwarem umožňujícím správu blade serverů v chassis. Zachování a případně zlepšení evidence vzdáleného přístupu na servery je velmi důležitým aspektem celého projektu.

2.2.3 Současné evidence V současné době jsou ve vztahu k hardwaru používány čtyři evidenční systémy (viz 2.3). Tok informací o nakoupeném HW je z účetní evidence SAP do HP Asset manageru a odtud následně do evidence ACOM. RMA tool stojí mimo tento řetězec jako speciální evidence pro jiné účely. Evidence SAP a HP Asset manager jsou vedeny nadnárodní společností vlastnící banku a jsou tedy zpravidla podkladem pro hlavní evidenci podřízené společnosti, kterou v tomto případě představuje ACOM. Bohužel systém importování dat SAP->HP Asset manager->ACOM není zdaleka dokonalý a nedochází k zaznamenání všech potřebných dat. Už do HP Asset manageru nejsou importovány detailnější informace o hardwaru a tento nedostatek se následně projevuje i v hlavní evidenci. Jedná se především o data týkající se počtu a typu procesorů a velikosti RAM. Tyto informace je následně nutné dodat do ACOMu ručně, když 15

jsou vyžadovány. Do RMA toolu jsou ručně zadávány všechny informace, protože tato evidence není designována pro propojení s evidencemi výše uvedenými.

2.2 Specifikace požadavků Je třeba vytvořit databázi, která by převzala úlohu excelového souboru, který slouží jako seznam fyzických serverů jednomu uživateli. Primárním požadavkem je zvýšení přehlednosti, usnadnění vyhledávání a úprav záznamů dle aktuálních změn. Dále vytvořit komplexní evidenci v jejím specializovaném ohledu. Dalším požadavkem je zvážit zavedení zjednodušeného zadávání hardwaru do databáze při hromadných nákupech. Pokud to bude možné, evidence by také měla být schopna porovnání s evidencemi ACOM a RMA tool. Spolu s postupem tvorby databáze budou stále probíhat konzultace s uživatelem, aby byly zohledněny všechny požadavky uživatele a specifika systému.

2.3 Popis jednotlivých částí systému Vzhledem k odborné terminologii používané v textu je nutné uvést alespoň některé termíny, případně jejich funkci v systému a význam, který mají pro tuto práci.

2.3.1 Servery Blade server - server navržený pro zmenšení velikosti a spotřeby energie. Tyto servery postrádají některé součásti a nejsou schopné běžného fungování mimo blade chassis. Velkou výhodou blade serverů je jejich velikost a následná organizace v chassis. Díky tomu se do místa pro 5 běžných serverů vejde i 16 blade serverů. [čerpáno z 5b] Blade Chassis (blade enclosure) - „rack“ pro blade servery. Chassis zajišťuje důležité funkce blade serverům jako například připojení do počítačové sítě, SAN sítě či chlazení. Blade chassis má až 16 slotů na blade servery a obsahuje zdroje elektrické energie pro vlastní napájení i pro všechny obsažené servery. Disponuje také vlastním síťovým připojením pro správu chassis i obsažených serverů. Tímto systémem je možné spravovat a přistupovat i na neaktivní servery. [čerpáno z 5b] Rack, racková skříň -

jde o standardizovaný systém pro montáž serverů. Racková

skříň má ocelovou konstrukci, šířku zpravidla 19 palců a až 50 pozic (běžně 42 pozic) pro servery po 1,75 palce na výšku. Součástí racků v datacentrech jsou i rozvody

16

elektřiny a nejrůznější držáky a úchyty pro rozvod kabeláže po racku. Servery jsou umístěny na ližinách pro snadnou manipulaci

2.3.2 Cluster Clusterů je několik typů podle jejich využití: High Availability cluster - základní kategorie clusterů, které slouží pro ochranu běhu kriticky důležitých databází a aplikací. Slouží k bezvýpadkovému provozování běžících aplikací a je zajišťován zpravidla dvěma servery, z nichž jeden je aktivní a druhý záložní pro případ výpadku. Load-balancing cluster - slouží k rovnoměrnému rozložení zátěže na všechny stroje clusteru a tak k rovnoměrnému využití výkonu Compute (výpočetní) clustery - sloužící k vytvoření výkonnějšího „superpočítače“ propojením většího množství méně výkonných strojů. ESX (VMware) cluster – software VMware vytváří virtuální prostor nad jednotlivými stroji, kde je nainstalován, a při využití vCenter na samostatném serveru je schopen propojovat tento prostor do clusterů. Tyto clustery slouží především k usnadnění managementu serverů a také jako HA cluster.

2.3.3 Sítě a síťová připojení LAN, WAN (Local Area Network a Wide Area Network) - počítačová síť zajišťovaná v kratších vzdálenostech, jako uvnitř budov, ethernetem či wi-fi a na větší vzdálenosti optickými vlákny. LAN je místní propojení PC, serverů, diskových polí a síťových prvků jako např. switchů, routerů a podobně. LAN používá zpravidla ethernetové propojení. WAN bývá ve většině případů sítí vzniklou propojením několika (či mnoha) sítí LAN. Při propojování velkých vzdáleností je využívané

optické

vlákno,

případně jejich svazek, vzhledem k rychlosti signálu. Pokud jsou aktivní

prvky

s IP

adresami

v různých WAN sítích, mohou mít stejnou IP adresu.

SAN (Storage Area Network) jedná se o typ připojení síťových disků k serverům. Hlavní předností

17

Obr. 2 – Schéma prostředí SAN; [10]

tohoto funkčně velmi složitého systému je vysoká spolehlivost připojení, rychlost a připojování diskového prostoru jako diskové jednotky stroji vlastní. Toto rozhraní je realizováno přes oddělený síťový systém a není tedy jakýmkoli způsobem ovlivněno například při přetížení LAN sítě. Dalšími používanými variantami síťového připojení diskových kapacit jsou NAS (Network-Atached Storage) pracující přes běžné připojení k síti či DAS (Direct Atached Store) pro přímé připojení diskového prostoru k serveru. [čerpáno z 10]

2.3.4 Bezpečnost dat, management serverů a jejich virtualizace Mirroring disků (RAID1) – jedná se o zvýšení bezpečnosti dat na diskové úrovni. Zapojí se dvojnásobek (mirroring může být i vícenásobný) disků s potřebnou kapacitou a následně jsou každé dva disky prezentovány operačnímu systému jako jeden a data jsou ukládána na oba tyto disky. Existuje více možností specifikujících postup při zápisu na takový disk. Samotný mirror je zajištěn v diskovém poli, v případě větších kapacit, nebo speciálním softwarem nainstalován na operační systém. Mirroring také umožňuje rychlejší čtení z disků, pokud je umožněno čtení z obou disků zároveň. [čerpáno z 11]

iLO (Integrated Lights Out) - pokročilý systém vzdáleného managementu HP serverů. Pro toto připojení je nutné samostatné ethernetové připojení s vlastní IP adresou. iLO umožňuje velmi rychlý přístup na servery, jejich plnou kontrolu (jako například VNC software) a obsahuje vlastní management interface pro přehled o fyzickém statutu serveru. RSA (Remote Supervizor Adapter) systém poskytuje velmi podobné možnosti pro IBM servery a DRAC (Dell Remote Acces Card) pro Dell servery. Vzhledem ke značné převaze HP serverů se remote systémy, případně jejich přístupové adresy, budou shrnovat pod název iLO. [čerpáno z 5d]

Hyperthreading - technologie společnosti Intel umožňující, v případě že operační systém i procesor podporuje tuto funkci, zvýšení výkonu procesoru až o třetinu umožněním vícevláknového zpracování dat přímo v procesoru. Z hlediska uživatele či operačního systému se pak procesor jeví jako procesory dva. Nevýhodou, z hlediska evidence hardwaru, je obtížné zjišťování množství procesorů a jader v daném počítači protože aktivita technologie je v operačním systému prakticky neviditelná.

18

Aktivitu hyperthreadingu je možno zjistit některými specializovanými programy, bohužel nezbytnou podmínkou je lokální běh programu. Je tedy velmi obtížné zjistit tuto skutečnost pomocí vzdáleného připojení. Pokud disponujete rozsáhlými vědomostmi o vašem hardwaru, budete pravděpodobně schopni odvodit, zda je hyperthreading aktivní. Nicméně při velkém množství serverů je to velmi obtížné. Hypervisor - jak již bylo řečeno, jedná se o virtualizační vrstvu zajišťující možnost vytváření virtuálních serverů na daném hardwaru. Při propojení těchto hypervisorů z více strojů lze vytvořit cluster, který usnadňuje management a umožňuje migrace virtuálních serverů. Propojení v tomto případě zajišťuje server s nainstalovaným VMware vCenterem. Tento systém je schopen také zajistit spolehlivost provozu automatickým přesunutím virtuálního serveru z nefunkčního hardwaru na jiný. [čerpáno z 5c, 6]

2.3.5 Evidence serverů RTI tool - evidenční aplikace vytvořená speciálně pro potřeby stěhování hardwaru. Tato databáze zohledňuje velké množství i jinak nedůležitých detailů jako je např. váha a rozměry hardwaru. Evidovány jsou zde pouze servery v datacentrech. Přes relativní jednoduchost a komplexnost toolu, není pro běžnou správu serverů tato evidence vhodná, vzhledem k absenci pobočkových a některých dalších typů serverů, u kterých se nepředpokládá možnost přestěhování. Konfigurační databáze (ACOM) -interní evidence, která z hlediska serverů obsahuje informace jak o hardwaru, tak o navazujících virtuálních vrstvách, aplikacích provozovaných na serverech či specifikách SAN prvků. Nevýhodou této evidence je její navázání na HP Asset Manager, ze kterého je pravidelně importována část dat o hardwaru. Pokud jsou data v ACOMu změněna, dojde tímto importem k jejich přepsání. Je tady nutné dělit informace na dvě části a každou z nich zadávat do jiné evidence. HP Asset Manager – standartní nástroj od firmy HP pro správu IT služeb a hardware, umožňující velké množství nastavení, propojení s prodejci či celkové usnadnění managementu IT. Většina informací je do této evidence importována z účetního systému SAP.

19

2.4 Návrh databáze 2.4.1 Volba metody návrhu K relační databázi se lze obecně propracovat dvěma způsoby. Zaprvé je tu možnost využít metodiku Top-down při které se velké, obecné celky rozkládají na stále menší části. Tímto dělením se dostáváme až na elementární, dále nedělitelné, základní prvky. Tyto atributy následně zařadíme do původních celků nebo entit vzniklých jejich rozkladem. Tato metoda je používána při tvorbě nových databází, ke kterým jsou získávány nejdříve zcela obecné informace. Jak postupuje konkretizace požadavků a poznání dané situace, postupuje také dělení na menší tabulky a atributy. Druhou možností je metodika Bottom-up, kde z nejmenších částí systému začneme sestavovat větší celky. Tímto postupem následně vzniká větší množství menších tabulek. Některé se postupně slučují a vytvářejí tak klasickou strukturu databáze. Touto metodou pracuje zpravidla reengineering, kde jsou podrobnosti systému známé z předchozího řešení a postupně se dochází k sestavení nových celků, které lépe vyhovují současné situaci. Ke konstrukci databáze je k dispozici evidenční soubor obsahující velké množství sloupců převoditelných na atributy nejrůznějších typů. Dalším zdrojem informací jsou ostatní evidence. Z těchto evidencí lze snadno určit základní dělení, které je v souvislosti s problematikou ve firmě používáno. Bylo by vhodné podržet se alespoň základů tohoto dělení kvůli následné kompatibilitě informací. Po zhodnocení situace jsem se rozhodl využít kombinace obou postupů. Servery mají značné množství parametrů, které lze v evidenci zachytit, ale jen část je pro tuto evidenci důležitá. Podržím se tedy základního členění fyzických serverů na virtuální server, zahrnující především operační systém, jeho atributy a aplikace, a hardware s příslušnými systémovými parametry. Tyto dvě entity pak naplním atributy, které budou získány analýzou evidenčního souboru. Během celého postupu budou probíhat konzultace s uživatelem. Tím bude zajištěno, že výsledky budou odpovídat realitě a požadavkům uživatele.

2.4.2 Identifikace základních položek ze zdrojového souboru Zdrojový soubor má 180 sloupců a zhruba 1900 řádek, kde řádek reprezentuje jedno sériové číslo hardwaru. V řádcích se objevuje několik nadpisových řádek specifikujících určité skupiny serverů, nicméně toto dělení není příliš respektováno. Mezi sloupci se vyskytuje větší množství pracovních sloupců, které slouží nebo sloužily zpravidla ke zobrazení vypočtených 20

hodnot. Dále se zde vyskytují sloupce, které nenašly své uplatnění, tak jak byly původně plánovány, takže hodnoty v nich obsažené jsou buďto nevyužitelné nebo zaznamenané jen pro zlomek serverů. Dalšími sloupci, které z databáze jistě vypadnou, jsou data z jiných evidencí. V souboru je také několik duplicitních či triplicitních sloupců. Každý z nich obsahuje část dat o dané problematice. Pro správné naplnění databáze bude tedy třeba prověřit aktuálnost sloupců a následně data sloučit. Po prvním důkladném prozkoumání souboru byly nalezeny položky, které po úpravě hodnot, položí základ struktury databáze. Tato analýza zabrala téměř dva týdny. Tento výčet je pouze základem a po konzultaci s uživatelem se seznam hodnot rozšíří.

Sloupec zdrojového souboru

popis zdrojovém souboru

ve

1

B, EM

DatumPorizeni

PORIZENI

sloupce se liší datem záznamu

2

F

SAP InvČ

SAP

ID systému SAP

3

J,K

SN osobně, SN,SN2 Sériové číslo NEW

Sériové číslo. SN2 bude nějakým způsobem změněné SN (např. opravou HW)

4

L

ASSET

ASSET_TAG

ID systému HP Asset manager

5

N, BH

STATUS

STATUS

podobná data, patrně získaná z různých zdrojů

6

P

LOKACE, MISTNOST, PATRO

komplexní zápis lokace, budovy, patra a místnosti

7

BB, BD,BF,DM

8

Q

RACK

RACK_NAME

9

R

RACK_POZ

RACK_POZICE

10 U, CX

Správce

SPRAVCE

11 V

Aplikace

APLIKACE

12 AA,AB,AC

IP adresa, IP2, IP3

IP

Některé servery mohou mít i více IP adres, jen jedna je primární

13 AE

MHZ

MHZ

frekvence procesoru

14 AF, AG

CPU socket, CPU PROC_COUNT NEW

počet procesorů, sloučit sloupce

15 AH

CPU CORES

počet jader na procesor

Položka databázi

pro

Poznámka, popis

doplňkové sloupce ke sloupci P

CORE_COUT

21

potřeba

16 AI

celé názvy procesorů, je třeba CUP model, CUP PROC_NAME, vyhodnotit oba sloupce a typ PROC_VYROBCE rozdělit data

17 AK

MEM

18 AM, AN

internal počet, DISKY Disk model

základ pro výpočet velikosti disků, bohužel sloupce obsahují málo dat

19 AO

Disk int OS

DISKY_OS

velikost disků viděná OS, např. po mirroru

20 AP

Disk SAN

DISKY_SAN

síťové disky připojené přes SAN

připojení

SAN_PORTY, LAN_PORTY, ILO, ILO_IP

propojená skupina buněk obsahující popisy různých propojení, bude nutné doplnit informace z jiných zdrojů

RAM

21 22 23

AQ-AV

24

velikost operační převést z MB na GB

paměti,

25 AX, DP, FM

SAN BOOT, boot YES, Bootable SAN_BOOT From San Implemented

26 AY

kat. supp

SUPPORT

informace o typu podpory serveru

27 AZ

Výrobce

VYROBCE

výrobce serveru

28 BA

ModelNEW

MODEL

model serveru

29 BE

prostředí

PROSTREDI

prostředí serveru, především provoz a testování

30 BG, BK

OWNER, MAJETEK MAJETEK

informace o bootování ze SAN

vlastník hardwaru

31 BM-CI

VYJ_VIRT

množství sloupců s informacemi o výjimkách z virtualizace, bude nutné dohodnout podobu položky

32 CL-CV

ROADMAP

životnost hardvaru, plánovaná výměna za nový

HYPERVISOR

rozlišení hypervisor hostů od klasických serverů

33 DN

HYPER/OS

Tabulka 1 – Souhrn výsledků analýzy vstupního souboru. Položky, které byly vytvořeny ze zdrojového souboru, tvoří zhruba jednu pětinu všech sloupců. Zbývající sloupce nejsou pro databázi zajímavé. Tvoří je především pracovní sloupce s rozloženými či naopak agregovanými hodnotami jiných sloupců, několik prázdných sloupců a velké množství informací které se v tuto chvíli nejeví být pro databázi vhodné nebo důležité. Tento stav se může po konzultaci s uživatelem samozřejmě změnit. Jednu velkou skupinu zde 22

tvoří sloupce věnované evidenci RTI tool. Z celkového množství sto osmdesáti sloupců je jich třicet sedm.

2.4.3 První konzultace Pro další postup při tvorbě databáze je nutné projít uvedené položky a přidat k nim ty, které se ve zdrojovém souboru vůbec nevyskytují, ale uživatel je shledává důležitými. Velmi pravděpodobně se mezi novými položkami objeví identifikátory z ostatních evidencí. Může dojít i k odstranění některých položek z tabulky. Při konzultaci byly schváleny všechny vybrané položky. Také bylo docíleno dohody na dalších položkách a to: 1. RTI_ID – položka nahrazující všechny RTI sloupce z původního dokumentu prostým ID z této evidence. Dojde tak k odstranění duplicity a máme jistotu, že informace z RTI toolu jsou aktuální. 2. ACOM_ID – odkaz na konfigurační databázi v původním dokumentu nebyl, ale vzhledem k tomu, že jde o nejpoužívanější a nejaktuálnější oficiální evidenci je dobré přidat toto propojení do vznikající databáze. 3. OBJ_CISLO – další položka, která v původním dokumentu chybí. Požadavek na evidování tohoto údaje je podložen přístupem uživatele k dodacím listům objednávek a je tedy možné stanovit či opravit hodnoty, které by byly v celém systému chybně zaneseny. 4. DOMENA – zaznamenání domény u serverů je pro uživatele podstatné především z důvodu dostupnosti různými metodami vzdálené správy, pak také kvůli vlastním přístupovým právům a různému zabezpečení domén. 5. ZEME – Již v této době spadá pod českou správu několik slovenských serverů, které je třeba odlišit. 6. HYPERTHREADING – vzhledem k obtížnosti rozlišování aktivního hyperthreadingu bylo dohodnuto, že se tato položka v databázi u virtuálních serverů také objeví. 7. DNS_NAME – z důvodu velkého množství domén a prostředí se jeví jako vhodné zaznamenat k serveru i jeho plné jméno. Přes toto jméno by měly fungovat všechny aplikace, které nejsou zakázané v daném prostředí, zatímco krátké jméno se může často „tvářit“ nedostupné. Přípona ke jménu se dá ve většině případů odvodit z položky DOMENA, ale v některých případech se přípona liší a je tedy nutné ji zde uvádět.

23

Nakonec bude databáze obsahovat více než čtyřicet nejrůznějších položek. Je pravděpodobné, že po vytvoření první podoby návrhu relační databáze ještě několik atributů přibude.

2.4.4 Základní tabulky Nyní je nutné zvolit základní entity. Zde se objeví struktura dat z ostatních evidencí. Základním členěním v tomto případě bude hardware - systémové parametry stroje, a virtuální server- nainstalovaný operační systém, jeho vlastnosti a zdroje, kterými disponuje. Bude nutné pečlivě zvážit, které položky se váží přímo k hardwaru a nemění se se změnou virtuálního serveru. U virtuálního serveru by se měly vyskytovat jen ty položky, kterými skutečně může disponovat. Veškeré atributy se u těchto serverů a u klasických virtuálních serverů shodují. Tedy samozřejmě ve chvíli, kdy budeme považovat vazbu v databázi na sériové číslo hardwaru ekvivalentní k vazbě na virtualizační cluster. Počet položek v entitě KOMPONENTA, tedy hardware, bude vyšší než v entitě VIRTUAL. Vyplývá to zcela jasně již z původního souboru dat. První položkou, a zároveň primárním klíčem, v HW entitě bude SN jako jednoznačná identifikace a současně téměř neměnná položka pro daný stroj. SN2 bude pak sloužit pro stroje, u kterých se při opravě SN změní. Další v pořadí budou identifikátory z jednotlivých evidencí. ASSET_TAG, spolu s SAP_CISLO ke kterému je přiřazován, se týká pouze hardwaru stejně jako OBJ_ID. Ale RTI a ACOM evidují jak HW, tak virtuální servery, takže zde dojde k duplikaci, a obě entity budou položky RTI_ID a ACOM_ID obsahovat. Třetí skupinou položek bude umístění stroje. Začneme od nejmenšího rozlišení položkou RACK_POZICE, zde bude zadán interval dvou čísel značící, které sloty v racku zabírá. Dále RACK_NAZEV, číslo a datacentrum racku (např. rack č.103 na Budějovické by měl označení BUD103), a poté místní určení MISTNOST, např. DMS20/, PATRO, např. druhé podzemní, po složení 2PP/DMS20/, a LOKACE, specifikující budovu např. pro budovu číslo dvě na Budějovické BUD2/2PP/DMS20/. Toto značení bylo přejato z evidence Asset manager vzhledem k již vytvořenému systému a označení všech firemních lokalit. Toto značení navíc umožňuje zaznamenávat polohu serverů precizněji a bez ohledu na datacentra. Před největší skupinou systémových parametrů ještě určíme zbylé jednotlivosti. STATUS udává stav HW, přesněji zda je aktivní (active) - tedy v provozu, nebo různým způsobem mimo provoz (zastaven, ve skladu, určen k likvidaci a podobně).

24

Tak trochu diskutabilní položkou je SPRAVCE. Může se týkat jak toho, kdo má ve správě hardware, tak toho kdo se stará o provoz virtuálního serveru na tomto hardwaru. Vzhledem k tomu, že se o problémy s HW stará správce virtuálního serveru, bude tato položka v entitě VIRTUAL. Dále je tu položka MAJETEK, kterou mohu bez pochybností přiřadit k HW. Patří sem i HYPERVISOR, specifikující zda na HW běží hypervisor nebo operační systém virtuálního serveru. Další dvojicí jsou úzce související PORIZENI a ROADMAP. Zde se rok vyřazení z provozu zřetelně váže na datum pořízení. A nyní k největší skupině, systémovým parametrům. Do této skupiny spadá: VYROBCE MODEL Data týkající se procesorů o

PROC_COUNT

o

CORE_COUNT

o

MHZ

o

PROC_NAME

o

PROC_VYROBCE

Obr. 3 – Základ tabulky KOMPONENTA

RAM DISKY – zde se určuje počet a fyzická velikost disků, tak jak je technik opravdu najde v serveru. ILO – umístění iLO k hardwaru je také diskutabilní, na jedné straně existence iLO rozhraní, na straně druhé skutečné zapojení iLO rozhraní do sítě a tedy jeho funkčnost. Z tohoto důvodu bude tato položka v entitě KOMPONENTA jako výraz existence a ve VIRTUALu jako informace o funkčnosti a ILO_IP jako informace o připojení. Entitu VIRTUAL budou tedy zatím tvořit zbylé položky z výčtu. Pro NAZEV, jako primární klíč, bude použita patrně jmenná konvence z RTI toolu, kde se ke každému serveru mimo produkční prostředí používá přípona pro odlišení stejně pojmenovaných serverů v různých prostředích. RTI_ID a ACOM_ID jako identifikátory pro primární klíče z těchto evidencí. Primární IP adresa serveru (některé servery mohou mít i více IP adres, ale pro připojení stačí primární) bude reprezentována položkou IP. SPRAVCE bude tedy, po předchozím rozhodnutí

25

v hardwarové části, zařazen do této entity. ILO zde bude představovat skutečnou, aktuální funkčnost připojení a ILO_IP jeho IP adresu, která se obvykle váže k primární IP serveru. Položka DISKY_OS se odvíjí od položky DISKY v hardwarové entitě. Jde o velikost disků viděnou operačním systémem a tedy opravdu využitelnou velikost. Tato velikost bývá zpravidla poloviční než u položky DISKY z důvodu mirroringu disků pro zvýšení bezpečnosti dat. DISKY_SAN jsou podstatně důležitějším atributem, protože na síťových discích běží naprostá většina serverových aplikací, zatímco na interních „jen“ operační systém a doplňkové aplikace. Položky PROSTREDI, DOMENA a DNS_NAME jsou provázané a ve své podstatě jsou síťovými parametry virtuálního serveru. Položka APLIKACE obsahuje jméno aplikace běžící na virtuálním serveru. Důležitost aplikace pak určuje hodnotu položky SUPPORT. Položka ZEMĚ je specifikací, pro koho virtuální server běží. Nezáleží zde na vlastníkovi HW, který je specifikován v položce MAJETEK, ale na provozovaných aplikacích. Položka HYPERTHREADING se váže pouze k určitému hardwaru a to ke strojům vybaveným procesory společnosti Intel. Teoreticky by bylo možné zařadit tuto položku do entity KOMPONENTA, ale vzhledem k tomu že softwarově (respektive na úrovni BIOSu) je možné tento parametr ovlivnit a že způsobuje problémy při rozlišování počtu

Obr. 4 – Základ tabulky VIRTUAL

procesorů v především v operačním systému, je řazena k položkám VIRTUALu. LAN_PORTY určují počet aktivních připojení do počítačové sítě, SAN_PORTY počet aktivních připojení

2.4.5 Vztahy tabulek a normalizace Entity byly naplněny atributy a pro dokončení transformace na tabulky je třeba nadefinovat všem atributům datové typy. Při analýze základního souboru již bylo zjištěno, jakých hodnot nabývají jednotlivé položky, takže jde pouze o formální přiřazení datového typu. Většina hodnot bude spadat pod typy varchar, pro řetězce znaků, a integer, pro celá čísla. Jediná položka typu float, tedy desetinné číslo, je MHZ vyjadřující pracovní frekvenci procesoru. Posledním datovým typem, který se zde vyskytne, je bit použitý pro několik položek s prostými hodnotami Ano/Ne případně 1/0. Nyní je třeba provést zásadní rozhodnutí o podobě databáze. Tabulky se ještě rozpadnou na menší, respektive na seskupení tabulek kolem obou původních entit. Celkově může databáze směřovat ke klasické relační nebo k databázi určené k reportování, která však nebude splňovat některé normální formy a bude tedy obsahovat redundantní data. 26

Pokusím se zavést zde alespoň třetí normální formu. Pokud by se však tabulky KOMPONENTA a VIRTUAL rozpadly na velké množství tabulek a nebylo by možné bez porušení těchto norem situaci uživateli zjednodušit, měla by být databáze namodelována podle potřeb a přání uživatele. Vzhledem k tomu, že databáze slouží jednomu uživateli a že je velmi nepravděpodobné výrazné následné rozšiřování, měla by maximálně ušetřit práci a zbytečně nezvyšovat nároky na čas strávený vyhledáváním a sestavováním dotazů. Postupem od první normální formy zhodnotím zásahy do struktury databáze a budu moci postupovat ke struktuře vhodné pro snazší obsluhu vzhledem k povaze a množství dat.

2.4.6 První normální forma Jediné co změní v základním návrhu tabulky KOMPONENTA první normální forma je pole disky. Je nutné zde vytvořit vazební tabulku, protože jeden server může obsahovat více různých disků. Vazební tabulka DISKY_VAZ obsahuje SN, ID_DISKY a MNOZSTVI. Tabulka DISKY obsahuje ID_DISKY a VELIKOST. Dalším atributem, o jehož normalizaci by se mělo uvažovat, je RACK_NAZEV. Vzhledem k zažité konvenci obsahuje jak číslo racku tak název datacentra, např. BUD103. Ale s ohledem na to, že se jedná o „pravá“ jména (racky jsou takto vedené v evidencích) není žádoucí tento atribut tříštit. Ostatní atributy tabulky jsou již v první normální formě. Tabulku VIRTUAL převedení neovlivní vůbec.

Obr. 5 – Tabulky v databázi po zavedení prví normální formy.

27

2.4.7 Druhá normální forma Vzhledem k tomu, že ani jedna tabulka neobsahuje složený primární klíč, přechod na druhou normální formu tabulky neovlivní.

2.4.8 Třetí normální forma Ve třetí normální formě se tabulka VIRTUAL opět nezmění. Tabulka KOMPONENTA se naopak začíná rozpadat. K tabulkám DISKY a DISKY_VAZ přibudou tabulky MISTNOST, LOKACE, PROC a MODEL. V prvních dvou doplněných tabulkách jsou schované všechny atributy vztahující se k umístění, tabulka PROC shrnuje procesory a používá jejich název jako primární klíč, stejně tak tabulka MODEL bude naplněna daty o modelech serverů a jejich výrobcích.

Obr. 6 – Tabulky databáze po zavedení třetí normální formy

28

Třetí normální forma by tedy byla dosažena. Je běžně považována za standardní a pro databázi tohoto rozsahu by nebylo přínosné snažit se dosáhnout maximální normalizace. V této chvíli se objevuje otázka, zda nevytvořit tabulku, která by obsahovala seznam oficiálních sestav, ve kterých se servery dodávají. Díky tomu, že servery se dodávají běžně v maximálně třech sestavách na model, by došlo ke zkrácení vyplňovaných dat na ID sestav namísto množství polí. Tato tabulka by se týkala položek: VYROBCE MODEL RAM PROC_VYROBCE PROC_MODEL MHZ CORE_COUNT PROC_COUNT Touto tabulkou tedy vznikne

číselník

sestav

serverů. Vzhledem k pokusům o normalizaci je třeba i tuto tabulku částečně rozložit na další číselníky. Tyto číselníky budou

vycházet

z tabulek

vzniklých po aplikaci třetí normální formě pro procesory a modely serverů. Vzhledem k tomu že se snažím docílit

Obr. 7 – Číselníková soustava tabulek SESTAVY.

přehlednosti a jednoduchosti i na úkor normalizace, bude do tabulky SESTAVY vložena položka NAZEV obsahující dlouhý název specifikující její obsah např. HPProliant685G7a_4X12core_O6174_2,2GHz_512GB. Tento řádek je sice naprostým popřením první normální formy, ale sestavy se již dále upravovat nebudou. Pokud bude potřeba jiná sestavu, vytvoří se jiná sestava. A tato položka nebude nikde použita jako klíč, takže zde není prostor pro problémy vzniklé porušením normalizace.

29

2.4.9 Číselníky Posledním krokem tvorby podoby databáze bude vytvoření číselníků. To umožní uživateli vkládat a upravovat záznamy v databázi bez neustálého vypisování hodnot do příslušných polí. Tento krok se výrazně projeví až po sestavení databázové aplikace, která umožní zobrazení nabídky pro jednotlivá pole. Další výhodou je snížení šance na nesmyslné záznamy vzniklé omylem přepisem písmene a podobně. Ideální je využít tento systém v případech, kde je cca 3-15 možností. Pokud se jedná o dvě možnosti je většinou lepší využít binární typ. Jde-li o dvě slovní charakteristiky, je patrně vhodnější využít také číselník. Při výběru z množství hodnot větší než deset nebo patnáct se stává číselník méně přehledným a záleží na složitosti hodnoty, zda nezvolit přímý zápis do položky. Číselníky přibudou v obou velkých tabulkách a to namísto těchto položek:

VIRTUAL o

SPRAVCE

o

PROSTREDI

o

DOMENA

o

ZEME – zde se jedná o položku se dvěma možnostmi, ale do budoucna se dá předpokládat zvýšení počtu

o

SUPPORT

KOMPONENTA o

RACK_NAZEV – zde jsem uvažoval o rozšíření číselníku o napojení na tabulky specifikující lokaci pro snazší nalezení prázdného racku. Vzhledem k způsobu jakým je tvořena tato položka to není potřebné.

o

STATUS

o

MAJETEK

o

HYPERVISOR – tato položka je diskutabilní vzhledem k hodnotám, kterých může nabývat. Hodnoty hypervisor/OS se dají nahradit 1/0. Prozatím bude tato položka vedena jako číselník a případná transformace do binárního typu bude vyřešena po konzultaci s uživatelem.

PROC a MODEL o

VYROBCE

30

Obr. 8 – Celkový pohled na tabulky databáze po vytvoření číselníků

31

2.4.10 Finální konzultace Ačkoli je v tomto stavu model databáze téměř hotov rozhodl jsem se pro další konzultaci. Vzhledem k dostatečným vědomostem uživatele o SQL bude možné „předvést“ řešení i ve fázi návrhu a doplnit ještě případné změny. V této konzultaci by bylo vhodné prodiskutovat, zda je u všech položek vyhovující forma pro reportování a především pro zadávání do databáze. Pokud by některé položky nevyhovovaly, bude třeba upravit jejich podobu, pravděpodobně proti normalizaci, a dále prodiskutovat případnou historizaci. Tento problém zatím nebyl probírán vzhledem k tomu, že původní soubor jej v rozumné míře neumožňoval a data nejsou nijak choulostivá, aby byla historizace uvažována od počátku. Pokud bude zavedena historizace, objeví se v tabulkách složený primární klíč, ale nedojde k porušení druhé normální formy. V této chvíli jsou atributy závislé na jednoduchém primárním klíči a po přidání historizace by se jen přidala závislost na časovém faktoru. Poslední konzultace zodpověděla otázku historizace dat a zapříčinila změny v některých tabulkách. Historizace byla odmítnuta z důvodu relativní nedůležitosti dat a malé velikosti databáze poskytující možnosti velmi snadného zálohování v případě potřeby. Další změnou je přesun ILO_IP z tabulky VIRTUAL do tabulky komponenta. Při analýze jsem v tomto bodě vycházel pouze ze zdrojového dokumentu, který neobsahoval dostatek informací. Během konzultace byly tyto informace doplněny. ILO_IP se váže pevně k hardwaru serveru a IP adresa je v datacentrech přidělována z vyčleněného adresního rozsahu pro iLO. Speciální případ, podle kterého byla databáze původně modelována, se týká pouze pobočkových serverů, kterým je pravidelně přidělována IP adresa pro iLO právě o 1 menší než přidělená IP adresa serveru. Po vyjasnění tohoto problému tedy zůstanou pouze dvě hodnoty týkající se iLO a to ILO a ILO_IP v tabulce KOMPONENTA. Další změnou, zasahující tentokrát do struktury tabulek, je přetransformování tabulek zabývající se disky, tedy DISKY a DISKY_VAZ v číselník. Bylo tak rozhodnuto z důvodu malého množství reálných kombinací disků na serverech, které vyplývá z maximálního využívání SAN disků, které jsou bezpečnější a snáze nastavitelné. Vznikla tedy „nová“ tabulka DISKY s atributy ID_DISKY pro číselné označení a NAZEV pro souhrn velikostí disků a jejich počtů.

2.4.11 Integritní omezení Tato databáze je ve své podstatě velmi jednoduchá, nicméně je zde poměrně velké množství propojení tabulek přes cizí klíče. K tomuto stavu vedlo zavedení číselníků pro usnadnění manipulace s databází. Je tedy nutné zabezpečit, aby nemohlo docházet k přiřazení 32

hodnot v číselnících neexistujících. Dalšími běžnými opatřeními jsou zabezpečení sloupců, které nesmí být prázdné (NULL) a zabezpečení proti smazání hodnot v číselnících, na něž se odkazují ostatní tabulky. Veškeré primární klíče budou explicitně definovány jako PRIMARY KEY a pochopitelně NOT NULL. V uvedených tabulkách může většina sloupců obsahovat prázdná pole, až na primární klíče a několik výjimek. V tabulce KOMPONENTA se jedná především o ID_MISTNOST, každý server musí být někde uložen, a ID_STATUS, tato informace má možnost vyjadřovat všechny stavy od dopravy od dodavatele až po čekání na ekologickou likvidaci. Tyto položky musí být tedy při psaní databáze vybaveny příznakem NOT NULL. Všechny ostatní položky mohou být v nějakém časovém rozmezí buďto legálně nevyplněné, či neznámé a to včetně ID_SESTAVY. V tabulce VIRTUAL je nutnou informací SN komponenty. Ačkoli může dojít k situaci, kdy je virtuální server přesouván z jedné komponenty na jinou a nějakou dobu „čeká“ (přes veškerou složitost se stále jedná jen o data) mimo komponentu, z důvodu obsazení obou strojů jinými virtuálními servery, bude tato položka disponovat příznakem NOT NULL, aby nebylo možné v databázi nashromáždit velké množství „zapomenutých“ serverů. V takovém případě bude nutné vytvořit jakousi dočasnou komponentu sloužící jen k navázání virtuálního serveru. Druhou položkou z této tabulky se stejným příznakem bude ID_PROSTREDI. Určité prostředí je částečně součástí identifikace virtuálního serveru a musí tedy být vyplněno. U všech položek z obou hlavních tabulek, které mají datový typ bit, bude nastavena defaultní hodnota. Z toho u položek HYPERTHREADING, SAN_BOOT a HYPERVISOR bude nastaveno No a u položky ILO bude nastaveno Yes. Tyto hodnoty vyjadřují obvyklý stav těchto parametrů a budou jen zřídka měněny. Vzhledem k počtu číselníků je velmi pozitivní, že od standardu SQL92 je u příkazu DELETE implicitně nastavena hodnota NO ACTION. Není třeba se tedy zabývat problémem smazání záznamu z hlavní tabulky s určitým primárním klíčem, pokud v podřízené tabulce existuje záznam s tímto klíčem. V takovém případě systém nedovolí zmazání provést. Bude však nutné zajistit, aby došlo ke změně cizích klíčů, bude-li v hlavní tabulce primární klíč změněn. Není sice příliš pravděpodobné, že by v číselnících docházelo ke změnám číselných primárních klíčů, ale pro zajištění referenční integrity je nutné počítat i s těmito případy. Toto opatření bude realizováno příkazem REFERENCES {hlavní tabulka} ON UPDATE CASCADE. Čili v definici každé závislé tabulky bude pro každý cizí klíč tato specifikace.

33

Obr. 9 – Výsledná podoba návrhu databáze po menších úpravách souvisejících s poslední konzultací projektu

34

2.5 Rozpis tabulek a atributů Zde uvádím podrobný rozpis finálního stavu hlavních tabulek a významu jejich atributů:

2.5.1 Tabulka KOMPONENTA Tabulka popisuje vlastní hardware, jeho identifikaci, umístění a část systémových parametrů stroje. SN – primární klíč tabulky. Udává unikátní sériové číslo hardwaru, které je, až na výjimky, neměnné. Jedná se o kombinaci různých znaků, zpravidla velkých písmen a číslic. SN2 – záložní pozice pro sériové číslo. V případě některých oprav může výjimečně dojít ke změně SN hardwaru. Jakkoli se jedná o malou pravděpodobnost, nelze ztratit původní SN. ACOM_ID – identifikátor z konfigurační databáze. Ačkoli se tato databáze pro správu hardwaru a serverů v rozsahu této práce nehodí, je stále cenným zdrojem dat v množství případů. RTI_ID – identifikátor z evidence RTI. Vzhledem k absenci pobočkových serverů v této evidenci ji nelze využít ve všech případech, ale opět se hodí jako doplňkový zdroj informací. ASSET_TAG – evidenční číslo používané nadřízenou společností. Evidence založená na tomto označení (Asset Manager) sice obsahuje informace o veškerém hardwaru, ale chybí zde informace o virtuálních serverech a nejsou zde kompletní síťové informace. Je navíc zdrojem dat o HW pro evidenci ACOM. SAP_CISLO – identifikační číslo z informačního systému SAP. Zde se jedná především o finanční hledisko. Ze systému SAP jsou stroje automaticky importovány do Asset Manageru. OBJ_CISLO – číslo objednávky ve které byl hardware zahrnut. Slouží ke zpětnému dohledání hardwaru v papírových dokumentech pro případ nejasností v elektronických záznamech ohledně konfigurace, SN či „příbuznosti“ jednotlivých strojů. ID_MISTNOST – cizí klíč číselníku, jež obsahuje místnosti, označení pater a odkaz na malý číselník lokací. ID_RACK – cizí klíč k číselníku racků. Číselník obsahuje název složený z čísla racku a zkratky datacentra pro snadnou identifikaci. RACK_POZICE – interval označující číselnou pozici v racku a velikost souboru v jednotkách U, kde 1 U odpovídá 1,75 palce, tedy 44,5 mm. ID_STATUS – cizí klíč k číselníku určujícímu aktuální stav serveru. Zda je Active, tedy v provozu, Stopped tedy nainstalovaný, ale nikoli v provozu, či například In stock tedy čekající ve skladu .

35

ID_MAJETEK - cizí klíč k číselníku s institucemi, které mají hardware ve vlastnictví. Jedná se o zhruba 10 institucí propojených s firmou různými způsoby. HYPERVISOR – boolean informace reprezentující Yes (1) pro HYPERVISOR a No (0) pro OS. Specifikuje, jestli je na daném hardwaru provozován klasický operační systém nebo jestli je server podporou pro VMware cluster. PORIZENI – datum pořízení hardwaru. Úzce souvisí s položkou ROADMAP. ILO – boolean hodnota značíc připojení, či možnost připojení, serveru ke vzdálenému přístupu přes iLO,RSA či DRAC. ILO_IP – IP adresa remote managementu daného serveru zajišťující vzdálený, a tedy základní, přístup k serveru pro většinu akcí ze strany IT. ROADMAP – předpokládaný rok skončení životnosti serveru ID_DISKY – cizí klíč k číselníku s různými kombinacemi velikostí disků pro jednoduchost zadávání do databáze. Jedná se o fyzické velikosti disků, nikoli velikosti viditelné pro OS. ID_SESTAVY – cizí klíč k pomocné tabulce SESTAVY, která obsahuje většinu informací o systémových parametrech stroje. Z důvodu častého opakování sestav při nákupu hardwaru jsou tato data ve velkém číselníku propojujícím čtyři malé tabulky.

2.5.2 Tabulka VIRTUAL Tato tabulka se zabývá operačním systémem a jeho atributy. Ve valné většině případů bude vazba přes cizí klíč SN ukazovat na hardware, na kterém tento operační systém běží. Takové uspořádání však ponechává příležitost odkazovat se na vytvořené ESX- clustery. Bylo klíčové oddělit tyto „virtuální části serverů“ od hardwaru. V budoucnu se předpokládá jejich virtualizace, tedy převedení provozu na ESX cluster. Pokud by byly tyto informace sloučené s tabulkou komponenta, bylo by nutné při přesunech na jiný hardware nebo na ESX cluster přepisovat celý záznam. NAZEV – primární klíč, jméno serveru. Vzhledem k možnosti shody se jménem serveru v jiném prostředí, bude přidána pomlčka s příponou prostředí. Jedno prostředí nemusí mít nutně jen jeden typ přípony. Není tedy možno vytvořit složený primární klíč přidáním ID_PROSTREDI. SN – cizí klíč, propojuje virtuální server s komponentou, případně i s ESX clusterem. ACOM_ID – identifikátor konfigurační databáze. Vzhledem k tomu, že konfigurační databáze je v oblasti virtuálních serverů nejúplnějším seznamem, bude cenným zdrojem informací pro moou databázi. 36

RTI_ID – identifikátor z evidence RTI. Stejně jako u HW RTI není zcela kompletní ani ve virtuální vrstvě. Tento záznam bude tedy sloužit spíše k občasné vzájemné aktualizaci obou databází. ID_PROSTREDI – specifikuje, zda se server nachází v běžném provozu či některém ze záložních či testovacích prostředí. Servery se mezi těmito prostředími přesouvají, obvykle z testovacích do provozu, přičemž se mění některé jejich parametry. DNS_NAME – tzv. dlouhé jméno, pole skládající se ze jména serveru a adresní přípony která specifikuje prostředí. U některých prostředí je nutné k připojení k serveru, stejně tak u serverů které se vyskytují ve více než jednom prostředí. Stejně jako se v položce NAZEV vyskytuje více přípon od některých prostředí, tak se v této položce vyskytuje více adresních specifikací. ID_APLIKACE – cizí klíč do číselníku na název nebo základní popis aplikace, která na serveru běží. Umožní v případě problémů rychlé zjištění důležitosti serveru i v rámci stejného nastavení supportu. ID_SPRAVCE – cizí klíč k číselníku se jmény správců serverů či provozovatelů aplikací. IP – IP adresa serveru. HYPERTHREADING – booleanská hodnota indikující zapnutí nebo vypnutí služby. Defaultně bude tato položka nastavena na NULL vzhledem k převaze procesorů AMD, které tímto systémem nedisponují. DISKY_OS – číslo indikující velikost disků viditelných a využitelných v operačním systému. Toto číslo je většinou po mirroru disků, takže se ve valné většině případů nerovná hodnotě z číselníku připojené přes ID_DISKY k tabulce KOMPONENTA. LAN_PORTY – udává počet aktuálně aktivních (zapojených) LAN portů. Většina strojů má zapojenou jen polovinu portů a zbytek slouží jako rezerva pro případ poruchy. SAN_PORTY – udává počet portů pro připojení k SAN. Většina disků je k serverům připojena přes systém SAN. DISKY_SAN – velikost diskového prostoru na SAN. Jedná se o klíčový prostor pro data, proto je nutné znát aktuální hodnoty. Na lokálních discích je obvykle pouze operační systém a software nutný k provozu serveru. Prakticky veškeré složitější aplikace běží na SAN discích především z důvodu možné migrace a bezpečnosti. ID_ZEME - číselník s hodnotami CZ a SK. Toto pole je zcela nové a reaguje na nutnost vyčlenit zvětšující se skupinu slovenských serverů. Tento parametr rozhoduje o tom, kdo by měl poskytovat podporu pro tyto servery. 37

ID_DOMENA – cizí klíč k číselníku obsahujícím informace o doménách. Vzhledem k různým bezpečnostním opatřením v různých doménách, různým podmínkám na hesla zaměstnanců, případně právům zaměstnanců a hlavně jiným přihlašovacím údajům se jedná o velmi důležité pole pro vzdálené připojení k serveru. ID_SUPPORT – cizí klíč k číselníku obsahujícím zásadní informace o podpoře, obvykle vyjádřené číslem vyjadřujícím počet hodin/počet dní v týdnu. Důležité servery mají obvykle 24/7 a reakce podpory musí proběhnout do jedné hodiny od vzniku problému. VYJ_VIRT – položka určující případnou výjimku z virtualizace. Prakticky všechny servery sloužící pro celobankovní účely jsou určeny k virtualizaci. Toto směřování je v souvislosti se současným trendem Cloud computingu, kde je snaha o nezávislost aplikací na hardwaru. Pokud dojde k oddělení od HW, je možné poskytovat tato softwarová řešení i po internetu jen jako službu bez nutnosti instalací a podobně. V některých případech je virtualizace odložena, zpravidla do skončení životnosti serveru, většinou z důvodu provázání aplikací s fyzickou strukturou, která by byla jen obtížně přemístitelná na virtuální cluster. SAN_BOOT – booleanská hodnota specifikující schopnost bootování serveru ze SANu. Technicky je to možné téměř u všech serverů, ale běžně se nepoužívá.

2.5.3 Tabulka SESTAVY Tabulka oddělená od tabulky KOMPONENTA z důvodu častého opakování standardních sestav dodávaných výrobci. Obsahuje většinu dat o systémových parametrech stroje, a funguje jako číselník. ID_SESTAVY – primární klíč, pouze číselně označuje sestavu. RAM – velikost operační paměti systému. NAZEV – zkrácený zápis souhrnu parametrů sestavy pro snadné vyhledávání. Například HPProliant685G7a_4X12coreR1753_2,2GHz_512RAM. Jedná se o celkový rozpis systémových parametrů sestavy, aby bylo možné podle jediného pole sestavy vyhodnocovat a nebylo nutné vytvářet selecty vyhledávající potřebné atributy. PROC_COUT – počet procesorů zadaného typu. PROC_NAME – cizí klíč k číselníku obsahujícímu informace o typu procesoru, počtu jader a, přes další číselník, informaci o výrobci procesoru. ID_MODEL – cizí klíč k číselníku modelů serverů opět s propojením na tabulku výrobců. Tabulka VYROBCE je společná jak pro výrobce serverů, tak pro výrobce procesorů. 38

Závěr V této práci jsem se věnoval vytváření relační databáze v těsné spolupráci s budoucím uživatelem. Cílem práce bylo vytvořit návrh, který bude v budoucnu realizován pro danou agendu. Čtenář je v této práci seznámen s daným prostředím, které má databáze popisovat, a je mu postupně předvedena tvorba tabulek z množství atributů získaných analýzou. Pro navržení databáze jsem čerpal informace z poskytnutého zdrojového souboru a postupně se rozhodujícím zdrojem informací stával také uživatel sám. Během projektu proběhly dvě hlavní konzultace. První po analýze zdrojového souboru, kdy došlo k významnému doplnění položek budoucí databáze. A závěrečná, ve které byly upřesněny některé položky a kde byla též prodiskutována možnost historizace databáze. Cíl práce, vytvořit návrh, který bude v budoucnu realizován pro správu serverů, byl splněn. S postupem práce se dařilo plnit požadavky uživatele i přes několik problémů. Hlavním problémem a příčinou nesrovnalostí byla rozsáhlost zdrojového souboru. Ta způsobila počáteční problémy s přesným použitím některých atributů a prodloužení zpracování dat. Vzhledem k časté spolupráci s uživatelem se nedostatky v přesnosti atributů dařilo odstraňovat průběžně s výjimkou informace o iLO. Tato otázka byla vyřešena až při finální konzultaci. Došlo k přehodnocení celkového pohledu na iLO systém a přesunu položek týkajících se iLO do tabulky KOMPONENTA. Byla také odstraněna původní hodnota ILO v této tabulce, značící existenci hardwarového rozhraní pro vzdálené připojení, protože se ukázala nedůležitou. Časté konzultace řešení měly také vliv na vytvoření databáze dle přání uživatele. Došlo tak k propojení zkušeností z praxe a teoretických poznatků. Díky tomu předpokládám, že po realizaci bude databáze pracovat k naprosté spokojenosti uživatele. Požadavky uživatele na systém byly tedy splněny a během následujících tří měsíců by mělo dojít k otestování databáze. Vzhledem k množství číselníků bude vhodné databázi vybavit aplikací pro přístup, patrně napsanou v PHP. Pokud se systém při praktickém fungování osvědčí, může dojít k rozšíření databáze pro clustery a virtuální servery. Hlavním přínosem pro mne je prohloubení znalostí o popisovaném prostředí i relačních databází. Doufám, že se mé řešení v praxi osvědčí.

39

Seznam použitých zdrojů 1. RIORDAN, Rebecca M. Vytváříme relační databázové aplikace. Praha : Computer Press, 2000. 280 s. ISBN 80-7226-360-9. 2. POKORNÝ, Jaroslav. Dotazovací jazyky. Praha : Universita Karlova v Praze, 2007. 255s. ISBN 978-80-246-0497-8 3. POKORNÝ, Jaroslav. Konstrukce databázových systémů Praha : Vydavatelství ČVUT, 1999. 166 s. skripta fakulty elektrotechnické. ISBN 80-01-01935-7 4. HERNANDEZ, Michael J. Návrh databází . Praha : Grada, 2006. 408 s.ISBN 80-247-09007. 5. Hewlett-Packard Development Company , především: a. HP Asset Manager software[online]. 2011, [cit.18. Května 2011+ Dostupný na WWW: b.

HP BladeSystem[online]. 2011, [cit.18. Května 2011+ Dostupný na WWW:

c. HP Virtualization with VMware[online]. 2011, [cit.18. Května 2011] Dostupný na WWW: d. HP Integrated Lights-Out (iLO) Advanced[online]. 2011, [cit.18. Května 2011] Dostupný na WWW: 6. VMware, Inc. Virtualization and Cloud Management [online]. 2011, [cit.18. Května 2011+ Dostupný na WWW: 7. Computerworld. Kouzla virtualizace[online]. 2010, [cit.18. Května 2011+ Dostupný na WWW: 8. www.manualy.net. Teorie relačních databází: Relační model dat [online]. 2006, [cit.18. Května 2011+ Dostupný na WWW: 9. www.manualy.net. Teorie relačních databází: Normalizace [online]. 2007, [cit.18. Května 2011+ Dostupný na WWW:

40

10. Nth Generation Computing, Inc. Storage Area Network Information Center[online]. 2011, [cit.18. Května 2011+ Dostupný na WWW: 11. Wikipedia. Disk mirroring[online]. 2011, [cit.18. Května 2011+ Dostupný na WWW: 12. Programujte.com. Teoretický úvod do relačních databází [online]. 2007, [cit.18. Května 2011+ Dostupný na WWW: 13. Statnice.matfyz.info. Nomální formy[online]. 2008, [cit.18. Května 2011+ Dostupný na WWW: 14. VMware, Inc. Virtualization basics [online]. 2011, [cit.18. Května 2011+ Dostupný na WWW: < http://www.vmware.com/virtualization/what-is-virtualization.html> 15. SCHMIDT, Robert. VMware vSphere 4. Praha : Computer Press, 2011. 344 s. ISBN 98780-251-3483-2 16. BEGG, HOLOWCZAK, CONOLLY. Mistrovství – Databáze. Praha : Computer Press, 2009. 584 s. ISBN 978-80-251-2328-7 17. POUR, GÁLA, ŠEDIVÁ. Podniková informatika – 2.vydání. Praha : Grada Publishing, 2009. 496 s. ISBN 978-80-247-2615-1

41