Zdieľanie zdrojov touto cestou vedie k zvýšenému využitiu zdrojov, zmenšuje náklady na riadenie a ceny celkového systému tým, že redukuje počet požadovaných systémov. Pre efektívnu konsolidáciu aplikácií do menšieho počtu fyzických systémov musí zostať možnosť nezávislého riadenia jednotlivých aplikácií. To si vyžaduje možnosti kontroly využitia zdrojov, izolácie porúch a správy bezpečnosti medzi viacerými aplikáciami na jednom serveri. Inak povedané, vyžaduje si to vytvorenie virtuálnych serverových hraníc vnútri fyzického serveru.
Prvým krokom v tomto smere bolo predstavenie dynamických systémových domén (Dynamic System Domains) na veľkých serveroch SUN. S dynamickými systémovými doménami môže byť server rozdelený do niekoľkých domén, pričom na každej beží vlastná kópia operačného systému Solaris. Domény zabezpečujú hardvérovú izoláciu aplikácií, takže poškodenie v jednej doméne sa neprenesie do iných domén. Doménové hranice môžu byť dynamicky rozdelené, aby bola možná ich adaptácia na zmeny systémových zdrojov. Zdroje sa môžu presúvať z jednej domény do inej bez nutnosti reštartovania systému.
Správa úloh
Štandardne, operačný systém Solaris spracúva každú požiadavku na zdroje s rovnakou prioritou. Ak je k dispozícii dostatok zdrojov, žiadosť je akceptovaná a zdroje sú pridelené. Ak požiadavka na zdroj prekračuje mieru celkovej dosiahnuteľnej kapacity, operačný systém Solaris sa prispôsobí obmedzením prístupu k zdroju. Akcia použitá na obmedzenie prístupu, závisí od typu zdroja. Napríklad ak by mala požiadavka na čas CPU presiahnuť dosiahnuteľný čas CPU, plánovač procesov zareaguje nastavením priority procesov za účelom zmeny rozdelenia času CPU. Rozvrhovací program operuje s vláknami, pričom nemá žiadny koncept aplikácií. Neuvažuje teda ich vzájomnú previazanosť a dôležitosť z hľadiska obchodnej perspektívy. Nedôležitá aplikácia nadmerne vyťažujúca procesor môže diskriminovať iné, oveľa dôležitejšie aplikácie.
Kontajnery Solaris zabezpečujú prostredie, ktoré podporuje bezpečné usporiadanie aplikácií do jediného fyzického servera.
Iné zdroje, tak ako celkový počet procesov v systéme, majú pevnú hornú hranicu. Len čo je limit dosiahnutý, tento zdroj nemôže byť viac použitý. Prebiehajúci proces, ktorý pokračuje v tvorbe nových procesov, môže zabrániť štartu nových užitočných procesov. Inak, ako špecifikovať hornú hranicu na úrovni systému, nie je iná možnosť,ako obmedziť počet procesov, ktoré môžu byť vytvorené aplikáciou alebo sadou aplikácií.
Je teda potrebný spôsob kontroly využívania zdrojov založený na akejsi pracovnej náplni (workload – ďalej úloha). Úloha je zoskupenie viacerých procesov prislúchajúcich aplikácii alebo skupine aplikácií, ktoré spolu súvisia najmä z hľadiska obchodnej perspektívy. Namiesto riadenia využitia zdrojov na úrovni procesov je teda možné riadiť využitie zdrojov na úrovni akýchsi pracovných úloh. Toto umožní aplikáciu pravidiel typu „Obchodná aplikácia má garantovaných minimálne 30 percent výpočtových zdrojov“, čo môže smerovať k dohodám typu SLA (service level agreement) na úrovni operačného systému. Vlastnosti riadenia zdrojov operačného systému Solaris umožňujú pracovať s úlohami spôsobom:
- obmedzenie prístupov k špecifickým systémovým zdrojom
- poskytnútie zdrojov jednotlivým úlohám na základe preferencií
- vzájomná izolácia úloh
Prvým krokom pri riadení využívania zdrojov úlohami je identifikovanie a klasifikácia komponentov, ako sú procesy, z ktorých daná úloha pozostáva. Ďalším krokom je meranie spotreby zdrojov týmito úlohami. Nakoniec môže byť úloha kontrolovaná aplikovaním obmedzení na využívanie pre ňu určených zdrojov. Aplikované obmedzenia vychádzajú z metód definovaných pre pracovnú náplň, založených na obchodných požiadavkách. Vhodným postupom by mohlo byť aplikovanie pravidla garantujúceho dôležitej úlohe určené minimálne množstvo systémových zdrojov, dokonca aj v stave preťaženom systému. Opačnou metódou by mohol byť prístup, kedy úloha dostane prístup k CPU, ak aktuálne žiadne iné úlohy prístup k tomuto zdroju nepožadujú.
Projekty
Prvým krokom v správe systémových zdrojov je určenie úloh (workloads) bežiacich v systéme. Vhodné prístupy zahŕňajú určenie úloh pomocou užívateľského mena alebo názvu procesu. Tieto prístupy sú jednoduché, ale predstavujú problém v prípade, keď viacero inštancií tej istej aplikácie beží v systéme v rámci rôznych úloh, ako napríklad databáza pre obchodnú aplikáciu a databáza pre marketingovú aplikáciu. Pokiaľ databázová aplikácia nepodporuje spúšťanie vlákien pod rôznymi užívateľmi v závislosti od úlohy, nie je použiteľný ani jeden zo spomenutých prístupov. Navyše to neumožňuje zhromaždenie viacerých súvisiacich aplikácií, ako databázové servery, aplikačné servery a webové servery pre obchodné aplikácie v jednom systéme.
Operačný systém Solaris poskytuje možnosť zvanú projekty na určenie úloh (workloads). Projekt slúži ako administratívna značka používaná na zoskupenie súvisiacej práce, do určitej miery vhodne stanovenej správcom systému. Správcovia systému môžu napríklad vytvoriť jeden projekt pre obchodné aplikácie a iný projekt pre marketingové aplikácie. Umiestnením všetkých procesov súvisiacich s predajnými aplikáciami do predajného projektu a procesov pre marketingové aplikácie do marketingového projektu môže administrátor rozdeľovať a hlavne riadiť úlohy určitým spôsobom vzhľadom na ich postavenie v obchodnej činnosti. Používateľ, ktorý je členom viac než jedného projektu, môže spúšťať procesy súčasne vo viacerých projektoch, čo umožňuje používateľovi súčasne participovať na viacerých úlohách. Všetky detské procesy spustené istým rodičovským procesom po ňom dedia aj príslušnosť k projektu. Čiže nastavenie príslušnosti štartovacieho skriptu k istému projektu spôsobí spustenie všetkých aplikácií z daného skriptu ako častí daného projektu.
Databáza projektov
Projekty sú definované v databáze projektov. Tá sa môže nachádzať v lokálnom súbore, alebo v adresárovej službe typu NIS či LDAP. Umiestnením databázy projektov do NIS alebo LDAP môžu byť definície projektov zdieľané medzi viacerými systémami. Každá položka (entita) databázy projektov pozostáva z nasledovných polí:
- name – meno projektu
- ID – unikátny numerický identifikátor projektu
- comment – popis projektu
- user list – zoznam užívateľov zahrnutých do projektu
- group list – zoznam skupín zahrnutých do projektu
- attributes – zoznam atribútov projektu (napr. ovládače zdrojov)
Novo nainštalovaný systém vždy obsahuje lokálnu databázu projektov v súbore /etc/project. Táto obsahuje päť štandardných projektov:
- system – systémové procesy a deemony
- user.root – všetky procesy bežiace pod užívateľom root
- noproject – procesy špecifické pre IP quality of service (IPQoS)
- default – procesy užívateľov ktorí nepríslušia k žiadnemu projektu (zahŕňa všetky projekty)
- group.staff – procesy všetkých užívateľov v skupine staff
Užívateľ alebo skupina môže byť členom jedného alebo viacerých projektov. Zoznam užívateľov a skupín v databáze projektov určuje, v ktorých projektoch môže užívateľ, alebo skupina užívateľov spúšťať procesy. Tieto zoznamy môžu obsahovať tzv. wildcards, ktoré umožňujú flexibilne definovať rozsahy užívateľov. Užívatelia sa (resp. ich procesy) môžu prepnúť do akéhokoľvek projektu, ktorého sú členmi. Pokiaľ sa užívateľ neprepne do iného projektu. Jeho procesy sú spúšťané v jeho prednastavenom projekte (default project). Zoznam užívateľov a skupín definuje len projekty, v ktorých je užívateľovi dovolené spúšťať procesy, nedefinuje však predvolený projekt pre daného používateľa alebo skupiny. Tento je určený systémom počas prihlasovania užívateľa do systému.
Fair Share Scheduler
Beh viacerých úloh v rovnakom systéme môže viesť k situácii, kedy jedna úloha obsadí výpočtové zdroje, čím postihne aj ostatné úlohy. Toto môže mať dopad na dôležité úlohy, pretože im nebude poskytnutá dostatočná výpočtová kapacita ku korektnému behu. Je vhodné mať mechanizmus, pomocou ktorého systémoví administrátori môžu uprednostniť prístup k výpočtovým prostriedkom v závislosti od dôležitosti (priority) danej úlohy.
Štandardný plánovač procesov v OS Solaris poskytuje každému vláknu relatívne rovnaké výpočtové zdroje. Ak nemá žiadne informácie o úlohách, štandardný plánovač nemôže uprednostniť pridelenie výpočtových zdrojov v závislosti od dôležitosti úlohy. Solaris ponúka alternatívny plánovač, ktorý dokáže vziať do úvahy priority plánovaných úloh a podľa nich rozdeľovať výpočtové zdroje.
Podiely CPU (SPU Shares)
Fair Share Scheduler (FSS) ovláda prideľovanie výpočtových zdrojov použitím tzv. CPU Shares (ďalej podiely CPU). Dôležitosť úlohy je vyjadrená počtom podielov, ktoré systémový administrátor pridelí projektom reprezentujúcim úlohu. FSS zabezpečuje, že výpočtové zdroje sú rozložené medzi aktívne projekty, ktoré sú založené na počte podielov pridelených každému projektu. (viz Obrázok 3). Podiel CPU definuje relatívny nárok výpočtových zdrojov, ktoré sú v systéme k dispozícii pre daný projekt. Je potrebné poznamenať, že podiely CPU nie sú to isté ako percentuálna hodnota z využitia procesora. Podiely CPU definujú relatívnu dôležitosť projektov s ohľadom na iné projekty.
Ak projekt A je napr. dvakrát taký dôležitý ako projekt B, projektu A by malo byť pridelených dvakrát toľko podielov CPU ako projektu B. Informácia o aktuálnom počte pridelených podielov je dosť irelevantná – 2 podiely pre projekt A versus 1 podiel pre projekt B pripúšťa rovnaký výsledok ako 18 podielov pre projekt A versus 9 podielov pre projekt B. V oboch prípadoch má projekt A k dispozícii dvakrát väčšie množstvo výpočtových zdrojov ako projekt B. Dôležitosť projektu A vzhľadom na projekt B môže byť zvýšená pridelením viacerých podielov projektu A, pričom počet podielov projektu B zostane nezmenený.
Fair Share Scheduler zabezpečuje, aby aplikáciam boli pridelené výpočtové zdroje podľa preferencií nastavených administrátorom.
Fair Share Scheduler vypočítava pomer výpočtových zdrojov pridelených projektu deliac počet podielov pre projekt celkovým počtom podielov v aktívnom projekte. Aktívny projekt je projekt s aspoň 1 procesom používajúcim výpočtové zdroje. Podiely pre nečinný projekt, ako sú projekty bez aktívnych procesov, nie sú používané vo výpočtoch. Napríklad, vezmime do úvahy projekty A, B a C s počtom podielov 2, 1 a 4. Ak projekty A, B a C sú aktívne, projekt A je oprávnený využívať 2\7, projekt B na 1\7 a projekt C 4\7 výpočtových zdrojov. Ak projekt A je nečinný, projekt B môže využívať 1/5 výpočtových zdrojov a projekt C 4/5 (viz. Obrázok 3). Teda aj keď aktuálne množstvo výpočtového výkonu prideleného projektom B a C vzrastá, pomer medzi projektami B a C zostáva nezmenený (1:4).
FSS však limituje použitie výpočtových zdrojov len ak dochádza k súpereniu o ne. Ak je v systéme iba jeden aktívny projekt, môže používať 100 % výpočtových zdrojov bez ohľadu na počet podielov CPU, ktoré mu sú pridelené. Nikdy teda nedochádza k neúplnému využitiu výpočtových prostriedkov na úkor spomalenia behu programu. Ak projekt z nejakého dôvodu naplno nevyužíva všetky pridelené výpočtové zdroje, tieto sú prerozdelené medzi ostatné aktívne projekty.
Fair Share Scheduler distribuuje výpočtové zdroje medzi aktívne projekty podľa počtu im pridelených podielov CPU.
Konfigurácia podielov CPU
Podiely CPU sú nastavované pomocou project.cpu-shares ovládača zdrojov (resource control) v databáze projektov. Každému projektu môže byť pridelená hodnota project.cpu-shares ovládača zdrojov. Projektom bez ovládača zdrojov býva systémom pridelený jeden podiel CPU. Systémový projekt je používaný pre všetky systémové procesy a démonov a je špeciálny v tom, že má neobmedzený počet podielov CPU. Projekty s prideleným nulovým počtom podielov môžu pracovať iba vtedy, ak iné projekty s nenulovými podielmi nie sú aktívne.
Užívatelia môžu byť členmi viacerých projektov a použitie CPU je kontrolované počtom podielov projektu, v ktorom užívateľ pracuje. Dôsledkom tohto, užívateľ môže byť oprávnený použiť rozličné množstvá výpočtových zdrojov v rovnakom čase. Jeden proces ale môže byť súčasne priradený iba jednému projektu, teda mať rozličné množstvá výpočtových zdrojov v rovnakom čase znamená, že procesy, ktoré užívateľ vlastní, prislúchajú rozličným projektom.
Na aplikáciu limitovania výpočtového výkonu na jediného užívateľa je potrebné vytvoriť projekt s vhodným počtom podielov CPU, ktorý obsahuje iba daného užívateľa. Tento projekt by mal byť predvolený pre daného užívateľa a užívateľ by nemal byť členom iných projektov.
CPU shares môžu byť nastavené dynamicky pomocou príkazu prctl. Tieto zmeny sú platné až do reštartu systému. Aby sa zmeny stali a zachovali aj po reštarte systému, je potrebné im priradiť pevnú hodnotu v project.cpu-shares databáze projektov.
Ovládače zdrojov
Množstvo zdrojov priradených úlohám môže byť kontrolované aplikovaním obmedzenia na použitie zdrojov. Tieto hranice môžu byť použité na ochranu úlohy pred pohltením určitého zdroja a následným obmedzovaním iných úloh. Solaris poskytuje možnosť kontroly zdrojov na implementáciu možnosti prevencie pohltenie zdrojov. Táto vlastnosť je rozšírením tradičných vlastností OS UNIX obmedzenie zdroja (rlimit).
Funkcionalita rlimit môže byť použitá na nastavenie obmedzení a limitov využívania výpočtových zdrojov, ako napríklad maximálny procesorový čas, maximálna veľkosť súborov a pod. Avšak, keďže rlimit je založený na procesoch, jeho použitie na obmedzenie workloads je limitované. Možnosť kontroly zdrojov v OS Solaris rozširuje limity založené na procesoch pridaním kontroly zdrojov na úrovni úloh a projektov. Počet obmedzení systémových zdrojov, ktoré môžu byť nastavené, je rozšírený, aby poskytol administrátorom viac kontroly nad využívaním zdrojov procesmi, úlohami a projektmi v systéme.
Správa ovládačov zdrojov
Ovládače zdrojov sú konfigurované pomocou databázy projektov. Posledné pole entity projektu je použitá na nastavenie ovládača zdrojov. Ovládač zdrojov je v entite projektu reprezentovaná dvojicou meno – hodnota. Meno znamená typ limitu, kým hodnota je zoznam atribútov pre ovládač. Projekt môže mať nastavených viac ovládačov zdrojov, ktoré sú navzájom oddelené bodkočiarkami. Zoznam atribútov pre ovládač zdrojov pozostáva z privilegovanej úrovne, hranice a akcie.
Privilegovaná úroveň určuje, ktorý užívateľ môže meniť počiatočnú hodnotu. Rozoznávajú sa tri privilegované úrovne:
- základná – vlastník vyvolávajúceho procesu môže meniť medznú hodnotu
- privilegovaná – iba privilegovaní (superuser) užívatelia môže meniť medznú hodnotu
- systémová – medzná hodnota je nemenná počas celého behu OS
Každý ovládač zdrojov má minimálne systémovú hodnotu, ktorá reprezentuje koľko zdrojov je aktuálna implementácia operačného systému schopná poskytnúť. Ovládač zdrojov môže mať najviac jednu základnú hodnotu a ľubovoľné množstvo privilegovaných hodnôt.
Akcia definuje kroky, ktoré majú byť vykonané po prekročení medznej hodnoty. Možné sú 3 akcie:
- deny (odmietnutie) – odmietnuť požiadavku na zdroj pri množstve, ktoré je väčšie ako medzná hodnota
- signal – poslať označený signál procesu prevyšujúcemu medznú hodnotu
- none (žiadna) – nevykonať žiadnu akciu
Dostupné ovládače zdrojov
Nasledujúca tabuľka identifiku ovládače zdrojov dostupné v OS Solaris 10.
| Ovládač zdroja | Popis |
|---|---|
| process.max-port-events | Maximálne dovolené množstvo udalostí na port udalostí (event port). |
| process.max-msg-messages | Maximálne množstvo správ v rade správ (message queue). |
| process.max-msg-qbytes | Maximálne množstvo bajtov správ v rade správ. |
| process.max-sem-ops | Maximálne množstvo semafórových operácií na jedno volanie semfóru. |
| process.max-sem-nsems | Maximálne množstvo semafórov na jednu sadu semafórov (semaphore set). |
| process.max-address-space | Maximálne množstvo adresného priestoru pre jeden proces. |
| process.max-file-descriptor | Maximálny index deskriptora súborov pre daný proces. |
| process.max-core-size | Maximálna veľkosť core súboru, ktorý môže daný proces vytvoriť. |
| process.max-stack-size | Maximálna veľkosť stack segmentu pre daný proces. |
| process.max-data-size | Maximálne množstvo heap pamäte dostupnej pre daný proces. |
| process.max-file-size | Maximálny offset na ktorý môže daný proces zapisovať. |
| process.max-cpu-time | Maximálny procesorový čas pre daný proces. |
| task.max-cpu-time | Maximálny procesorový čas pre procesy danej úlohy. |
| task.max-lwps | Maximálne množstvo LWP súčasne dostupných procesom danej úlohy. |
| project.max-contracts | Maximálne množstvo kontraktov dovolené v rámci projektu. |
| project.max-device-locked-memory | Maximálne celkové množstvo zamknutej pamäte pre daný projekt. |
| project.max-port-ids | Maximálne množstvo portov udalostí (event ports). |
| project.max-shm-memory | Maximálne celkové množstvo zdieľanej pamäte pre daný projekt. |
| project.max-shm-ids | Maximálne množstvo ID zdieľanej pamäte pre daný projekt. |
| project.max-msg-ids | Maximálne množstvo ID radu správ (message queue Ids) pre daný projekt. |
| project.max-sem-ids | Maximálne množstvo ID semafórov pre daný projekt. |
| project.max-crypto-memory | Celkové množstvo pamäte jadra, ktoré môže byť použité hardvérovým akcelerátorom šifrovania pre libpkcs11. |
| project.max-tasks | Maximálne množstvo úloh pre daný projekt. |
| project.max-lwps | Maximálne množstvo LWP súčasne dostupných pre daný projekt. |
| project.cpu-shares | Počet podielov CPU (CPU shares) daného projektu. |
| zone.max-lwps | Maximálne množstvo LWP súčasne dostupných procesom danej zóny. |
| zone.cpu-shares | Množstvo podielov CPU pridelených zóne Fair Share Scheduller-om. |
Ďalšou zaujímavou vlastnosťou je dynamické prideľovanie procesorov alebo Dynamic resource polls. Viac informácií o ňom je možné nájsť v [2] od strany 39. Statické prideľovanie procesorov je vysvetlené na strane 9 (partitioning) toho istého dokumentu.
Zdroje:
[1] Matúš Kováčik, Štúdia pokročilých vlastností operačného systému Solaris – Diplomová práca, Bratislava: FIIT STU, 2007
[2] Menno Lageman, Sun Client Solutions, Sun BluePrints™, 2005, Solaris Containers – What They Are and How to Use Them, Part No. 819–2679–10, Revision 1.0, 5/26/05
