Počítačové systémy 2. Stavba OS Obsah: funkce OS, součásti OS typy jader OS (monolitické, mikrojádro, hybridní) RTOS jednoúlohové a víceúlohové OS jednouživatelské a víceuživatelské OS multiprocesory, ASMP, SMP multipočítače (clustery) © Milan Keršláger http://www.pslib.cz/ke/slajdy 11. 10. 2012 http://creativecommons.org/licenses/by-nc-nd/3.0/

Funkce operačního systému ovládání počítače umožňuje uživateli spouštět programy zajišťuje předání vstupů a získání výstupů programu abstrakce hardware programátor používá API → volání funkcí (čti, zapiš...) nestaráme se o detaily ovládání HW → ovladače správa prostředků přiděluje a odebírá procesům systémové prostředky tj. je nejvyšším arbitrem, neztrácí kontrolu nad počítačem spravuje též hardware ovládaný počítačem: grafická karta, USB porty, paměť, procesor, …

Součásti operačního systému jádro operačního systému (kernel) zavádí se do paměti při startu počítače zůstává v činnosti po celou dobu provozu počítače obstarává všechny dříve zmíněné činnosti 3 typy jader + specifický případ RTOS monolitické jádro, mikrojádro, hybridní jádro pomocné nástroje utility – nástroje na přidělování práv, formátování... démoni (v MS Windows označováno jako „služby“)

Typy jader OS monolitické jádro – monolithic kernel jeden celek řeší celý problém (průběžný vývoj) varianta: modulární jádro mikrojádro – microkernel idea jako u strukturovaného programování ještě menší: exokernel, nanokernel, picokernel hybridní jádro – hybrid kernel něco mezi monolitickým a mikrojádrem snaha o využití „toho lepšího“ z obou RTOS – speciální případ

Monolitické jádro jádro je jeden celek původní model do konce 80. let (např. Unix) v souvislém úseku paměti (kernel-space) vše na stejné (absolutní) úrovni oprávnění chyba (např. v ovladači) ohrožuje celé jádro umožňuje efektivní programátorské triky do téže paměti zasahují různé subsystémy pozitivní vliv na výkon (nízká režie jádra) vývoj náročný na znalost funkce celého jádra dnes Linux, FreeBSD a další

Modulární jádro varianta monolitického jádra základ je monolit ovladače (či jiné části) jsou v modulech ovladač síťové karty, grafické karty, síťový subsystém modul je součástí jádra → absolutní oprávnění moduly lze zavádět do jádra za běhu někdy lze moduly za běhu i odstranit (např. Linux) není nutné při změně HW vytvořit nové jádro využívají toho např. distribuce Linuxu dodáváno je univerzální jádro + mnoho modulů moduly se zavádějí automaticky (připojení USB flash...)

Mikrojádro jádro minimalizováno (jen nejnutnější části) důsledek strukturovaného programování činnost jádra je rozdělena do logických celků (částí) v jádře ponecháme jen nejdůležitější části přepínání kontextu (viz víceúlohový systém) správa paměti důsledkem je zjednodušení co nejvíce částí je vyvedeno mimo jádro → do běžných procesů (tzv. „servery“) jádro se snadněji programuje

Výhody mikrojádra rozvržení kódu do (malých) částí přehledný kód vše „vlastní píseček“ je snadné pochopit kód např. souborový subsystém, síťový subsystém a další vzájemná komunikace přes API (zasílání zpráv) proces (server) lze po pádu restartovat (ale fuj) chyba v serveru neohrožuje stabilitu systému ale minimálně se ztratí informace o stavu zaniknou například vytvořená síťová spojení jen mikrojádra mohou být super-bezpečná, RTOS lze provést audit kódu, dát záruky co se nemůže stát

Nevýhody mikrojádra výkonnostní problémy (někdy nemusí vadit) vyvolání služby jádra může znamenat řetězové přepínání kontextu (zejména při vzájemné komunikaci) řeší se pečlivým návrhem snaha o minimalizaci kopírování dat (API) samostatné procesy nemohou manipulovat se společnými daty (např. cache) zástupci: GNU Hurd + mikrojádro GNU Mach – stále není finální Symbian – funkční, navíc RTOS Minix + Tanenbaum

Hybridní jádro kombinuje výhody monolitu a mikrojádra základní jádro je větší včetně částí citlivých na výkonnost grafický subsystém, správa cache kompromis mezi monolitem a mikrojádrem blíží se z druhé strany modulárnímu monolitu Microsoft Windows NT NT 3.1, 3.5, 3.51, 2000, XP, 2003, Vista, 2008, 7, ... Microsoft Windows CE Windows Mobile, Pocket PC, Windows Phone, ...

RTOS Real Time Operating System tzv. operační systém reálného času jsou definována časová ultimáta úloha má garantovaný běh v jednotce času programátor ví, že za daný čas dostane alespoň garantovaný strojový čas procesoru může si rozmyslet, co je nebytně nutné spočítat a co může počkat RTOS nedovolí spustit další proces, nemůže-li ultimáta splnit krátká doba reakce na událost tzv. latence (doba od vzniku události po její obsloužení) garance maximální doby pro programy, ale i ovladače rychlé přepínání úloh minimalizace režie změny kontextu

Typy RTOS hard RTOS časová ultimáta je nutné splnit vždy systém musí být od začátku navržen jako RTOS v podstatě možné jen pro mikrojádra soft RTOS časová ultimáta jsou plněna přibližně doplňky pro jádro Windows NT RTLinux mnoho RT záplat i v klasickém jádře Linuxu

Využití RTOS průmyslové nasazení řízení výrobních procesů, motorů, … zpracování dat z čidel mobilní telefony nepřipraví-li data, je výpadek přenosu snížení kvality hlasu RT systémy nebo RT-like systémy: Symbian, Windows CE RTLinux, doplňky pro Windows NT

OS podle schopností víceuživatelský jednoúlohový CP/M DOS víceúlohový jednouživatelský víceuživatelský jednoúlohový CP/M DOS víceúlohový Windows NT (desktopová verze) Mac OS 9 (s Terminal Services) Unix/Linux Mac OS X

Jednoúlohový systém v paměti jen jádro OS a jedna běžící úloha starší počítače → pomalé CPU, jednoduchý OS v PC byl CPU bez podpory ochrany paměti (i8086) úloha může ohrozit operační systém (→ reboot) CP/M (Gary Kindall, 1973) 8bitový, pro procesory 8080, Z80 (Commodore 128...) přímý předchůdce pro DOS DOS (Tim Patterson, 1980, původně QDOS) 16bitový, pro procesory 8086, 8088 (IBM PC) žádný OS se nejmenoval DOS → je to celá rodina OS jádro nebylo reentrantní → spuštěn max. 1 program

Víceúlohový systém původně snaha o lepší využití počítače když procesor čeká na dokončení I/O operace → může být vykonávána jiná úloha úloha by mohla být „odložena“ na disk (mg. pásku) to je však velmi pomalé → nepraktické takže střídající se úlohy musí být v RAM je však potřeba od sebe oddělit jádro i všechny úlohy → zavedení tzv. „ochrany paměti“ (viz později) ochrana paměti vyžaduje HW podporu v CPU CPU musí umět i „privilegovaný režim“ (též později) zavádíme tzv. multitasking (též probereme později)

Vývoj víceúlohových systémů 1966 – IBM OS/360 + MFT Multitasking With Fixed Number of Tasks ještě jen konfigurace kontrolního programu 1967 – IBM OS/360 + MVT Multitasking With Variable Number of Tasks subsystémy: správa a ochrana paměti, scheduler Multics (neúspěšný projekt) – AT&T 60. léta měl umět „všechno“ (až futuristicky) Unix (Ken Thompson) – 1969 jednoduchý – „programátoři sobě“, něco z Multicsu

Víceuživatelský systém podpora více uživatelů zároveň můžeme je označit za skutečné operační systémy nutné zavedení oprávnění, správce (administrátor) vícenásobné uživatelské rozhraní textové rozhraní (v Unixu zajišťuje tzv. shell) terminály sériovým kabelem, počítačovou sítí (PuTTY) grafické rozhraní → problém jedna grafická karta → jak více klávesnic, monitorů? původní návrh HW a SW s tím obvykle nepočítá řešení: obraz jen v paměti + síťový přístup MS Windows: vzdálená plocha (vyžaduje Terminal services) Unix: modulární X Window systém (již od počátku)

Zvýšení výkonu počítače zrychlení hodin CPU zaostávání pomalejších částí počítače – cache fyzikální limity (rychlost světla vs. velikost čipu) širší sběrnice, větší registry více dat zpracovaných najednou zvýšení průchodnosti systému paralelizace zpracování úloh pro specifické úlohy, jiný styl programování multiprocesory a multipočítače

Multiprocesory a multipočítače více procesorů na základní desce dříve více fyzických CPU, dnes více jader jen jedna společná operační paměť (RAM) NUMA (AMD) → každý CPU „vlastní“ paměť půjčování paměti Intel → stále jedna společná paměť multipočítače tzv. clustery více samostatných počítačů procesory NEmají společnou operační paměť

Multiprocesory I. více procesorů sdílí jednu operační paměť současný přístupu ke stejné paměti → souběh řízení konfliktního přístupu do paměti je limitující systém nelze škálovat lineárně přidání dalšího procesoru zvýší celkový výkon jen o část problémy se škálováním má i software odlišně řeší NUMA (procesory od AMD) každý CPU má „svoji paměť“ vyjednávají mezi sebou jen při přístupu k „cizí“ paměti současné klasické systémy s NUMA moc nepočítají např. tabulka procesů, otevřených souborů atd. na jednom místě procesy musí zůstávat na stejném jádru (tzv. „pinning“) co se však stane, když je vyvolána služba jádra?

Multiprocesory II. paralelní vykonávání kódu více procesory problém souběhu při zápisu do stejného místa v paměti více procesy je nutné přizpůsobit jádro systému asymetrické řešení → ASMP kód jádra je prováděn jen na CPU#0 Novell Netware server 4 (1993) snadné přizpůsobení UP jádra pro SMP prostředí úloha z jiného procesoru volající jádro musí čekat na uvolnění #0 symetrické řešení → SMP vyžaduje zamykání datových struktur jádra Linux, Windows NT a další

Multiprocesory III. více fyzických CPU, dnes vícejádrové CPU problém: zvýšení výkonu není lineární čekání na uvolnění zámku zámky řeší problém souběhu (vysvětlení později) často jeden BLK (Big Kernel Lock) → blokuje celé jádro speciální architektury pro masivní MP problém: každý CPU komunikuje s každým → exponenciální složitost nutno naprogramovat specifické aplikace dnes většina aplikací jednovláknová

Multipočítače (clustery) snaha o zvýšení výkonu pomocí více počítačů poznají se podle toho, že nemají společnou paměť obvykle z „laciných“ PC → levný superpočítač propojení pomocí rychlé LAN (uzly) různá zaměření clusterů (typicky kombinace): výpočetní – HPC, paralelní výpočty load-ballancing – rozkládání zátěže fail-over – odolnost proti výpadku uzlu storage – rozložení a paralelizace I/O operací gridové clustery nededikované počítače, aplikační využití (Boinc)

Výpočetní cluster znásobení výpočetní síly výpočet je nutné rozdělit mezi více počítačů síť slouží ke komunikaci, předávání dat paralelní systémy více spuštěných programů každý počítač v clusteru vlastní program distribuované výpočty upravený program umí rozdělit data stejný výpočet nad různými daty na různých uzlech

Distribuované výpočty na úrovni jádra OS z vnějšku jako mohoprocesorový stroj běžící úlohy migrují mezi uzly clusteru na úrovni aplikace programátor napíše program distribuovaně každý uzel počítá jinou část úlohy každý uzel má typicky spuštěn stejný program využívání vzájemné komunikace uzlů využívání hotových knihoven např. MPI

Load-ballancing cluster rozložení zátěže mezi více uzlů v clusteru více počítačů se stejným obsahem je jedno, který z nich vyřídí požadavek mohou mít společnou databázi nebo diskový prostor např. zatížené WWW servery o rozložení zátěže rozhoduje arbitr např. předřazený počítač softwarově obdoba reverzní proxy cache nginx (např. www.seznam.cz) arbitr je „single point of failure“

Single point of failure místo, které při selhání vyřadí celý systém data nemohou jít jinou cestou například řadič pro diskové pole RAID používá se tzv. multipath, tj. alespoň dva řadiče jeden není aktivní a přebírá komunikaci po výpadku nebo se používají oba, ale stačí i jen jeden vyžaduje speciální ovladače v jádře OS switch s počítačové síti lze snadno vyměnit kus za kus napájecí zdroj používají se dva zdroje + logika pro přepínání

Failover cluster zajištění odolnosti vůči výpadku v případě výpadku převezme úlohu záložní typicky předřazen arbitr směřující dotazy arbitr sleduje odpovědi serveru tj. sleduje čas odezvy v případě selhání směřuje dotazy na záložní server arbitr může nevyřízený dotaz zopakovat záložnímu arbitr je single point of failure lze řešit dvěma arbitry s různými IP adresami v DNS jsou pro 1 DNS jméno dvě IP adresy je otázka, zda klient (prohlížeč) použije druhou IP adresu

Úložný cluster pro ukládání dat datová propustnost počítače je omezená do clusteru data ukládána paralelně tím se zvětší propustnost i kapacita je nutné tok dat rozdělit do jednotlivých uzlů clusteru používá se pro hromadný sběr dat např. nahrávání videa z mnoha kamer zvyšuje se pravděpodobnost výpadku uzlu je nutné zajistit odolnost → je potřeba i failover

Gridový cluster počítače v clusteru nejsou vyhrazené snaha o využití běžných počítačů desktopový počítač často nedělá nic speciální aplikace nabídne přes síť jeho výkon není-li počítač používán, začne počítat např. SETI@Home jako šetřič obrazovky využití i iddle time CPU (tj. kdy by CPU nic nedělal) typicky snížením priority dotyčného procesu problémem je bezpečnost (BOINC) počítáme opravdu to, co je deklarováno? na svém počítači spouštíme cizí kód → cesta pro trojské koně