Міністерство освіти і науки, молоді та спорту України
Тернопільський національний економічний університет
Факультет комп’ютерних інформаційних технологій
Кафедра міжнародної інформації
Комплексне практичне індивідуальне завдання
з дисципліни:
"Системне програмне забезпечення"
на тему:
“Windows server 2008”
Зміст
Вступ 3
1 Управління процесами 4
1.1 Процес і його ресурси 4
1.2 Планування потоків 4
1.3 Рівні пріоритету 5
1.4 Стани процесів 6
1.5 Перемикання контексту 7
2 Управління пам’яттю 8
2.1 Віртуальна пам’ять 8
2.2 Структура адресних просторів 8
2.3 Диспетчер пам’яті 9
2.4 Компоненти диспетчера пам’яті 9
3 Підсистема вводу-виводу 11
4 Файлова система 13
4.1 Типи файлових систем 13
4.2 Драйвер файлової системи 13
4.3 Служба VSS 14
4.4 Служба DFSR 14
5 Переваги та недоліки системи Windows Server 15
Висновки 17
Використані джерела 18
Додаток А Код програми Device manager class implementation 19
Вступ
Microsoft Windows Server 2008 (кодове ім'я «Longhorn Server») — версія серверної операційної системи від Microsoft. Випущена 27 лютого 2008 року. Ця версія замінює Windows Server 2003 як представник операційних систем покоління Vista (NT 6.x). Ця ОС допомагає ІТ-фахівцям повністю контролювати інфраструктуру, забезпечуючи безпрецедентну доступність і керованість, що дозволяє досягти більш високого, ніж коли-небудь, рівня безпеки, надійності і стійкості серверного середовища. ОС Windows Server 2008 відкриває перед організаціями нові можливості, надаючи всім користувачам, незалежно від їх місцезнаходження, доступ до повного набору мережевих послуг. Крім того, у Windows Server 2008 є засоби для аналізу стану та діагностики операційної системи, що допомагає адміністраторам приділяти більше часу розвитку бізнесу. Дана серверна операційна система пропонує цілий ряд нових технічних можливостей у галузі безпеки, управління та адміністрування, розроблених для підвищення надійності і гнучкості роботи сервера. Особливу увагу привертає нова функція безпеки AD DS - Read-Only Domain Controller (RODC, контролер домену тільки для читання), який дозволяє використовувати копію бази даних домену тільки для читання в умовах зниженої фізичної або адміністративного захисту, наприклад, в офісах філій.
1 Управління процесами
1.1 Процес і його ресурси
Процес - це контейнер для набору ресурсів, що використовуються при виконанні примірника програми. Процес складається з закритого адресного простору, одного або декількох потоків, ідентифікації захисту і списку відкритих описувачів таких об'єктів, як файли і розділи загальної пам'яті, або синхронізуючих об'єктів на кшталт мьютексів, подій і семафорів. На рисунку 1 представлена схема процесу і його ресурсів.
Кожен процес володіє контекстом захисту, який зберігається в об'єкті - маркері доступу. Маркер доступу містить ідентифікацію захисту та визначає повноваження даного процесу.
Дескриптори віртуальних адрес (virtual address descriptors, VAD) - це структури даних, що використовуються диспетчером пам'яті для обліку віртуальних адрес, задіяних процесом.
Рисунок 1 Процес і його ресурси
1.2 Планування потоків
Планування потоків може виконуватись по таким критеріям:
Витісняюче планування на основі рівнів пріоритету
Вибір потоку може бути обмежений прив'язкою до процесора
Обраний потік працює протягом кванта часу. Квант залежить від:
Конфігураційних параметрів
Статусу процесу
Використання об'єкта завдання
Код відповідає за планування розсіяний по ядрі
Сукупність процедур, які виконують ці обов'язки називається диспетчером ядра
Код Windows, що відповідає за планування, реалізований в ядрі. Оскільки цей код розсіяний по ядрі, єдиного модуля або процедур з назвою «планувальник» немає. Сукупність процедур, які виконують ці обов'язки, називається диспетчерами ядра (kernel's dispatcher). Диспетчеризація потоків може бути викликана будь-яким з наступних подій:
Потік готовий до виконання - наприклад, він щойно створений або вийшов зі стану очікування.
Потік виходить зі стану Running (виконується), так як його квант минув або потік завершується або переходить в стан очікування.
Пріоритет потоку змінюється в результаті виклику системного сервісу або самої Windows.
Змінюється прив'язка до процесорів, через що потік більше не може працювати на процесорі, на якому він виконувався.
Планування в Windows здійснюється на рівні потоків. Оскільки рішення, що приймаються в ході планування, стосуються виключно потоків, система не звертає уваги на те, якому процесу належить той чи інший потік. Так, якщо у процесу А є 10, у процесу В - 2 готових до виконання потоків, і всі 12 мають однаковий пріоритет, кожен з потоків теоретично отримає 1 / 12 процесорного часу, тому що Windows не стане порівну ділити процесорний час між двома процесами.
1.3 Рівні пріоритету
Рівні пріоритету призначаються з урахуванням двох різних точок зору - Windows API та ядра Windows.
Windows API спочатку впорядковує процеси по класах пріоритету, призначеним при їх створенні [Real-time (реального часу), High (високий), Above Normal (вище звичайного), Normal (звичайний), Below Normal (нижче звичайного) і Idle (простоює) ], а потім - за відносним пріоритетом індивідуальних потоків у рамках цих процесів [Time-critical (критичний за часом), Highest (найвищий), Above-normal (вище звичайного), Normal (звичайний), Below-normal (нижче звичайного), Lowest (найменший) і Idle (простоює)].
Базовий пріоритет кожного потоку в Windows API встановлюється, виходячи з класу пріоритету його процесу і відносного пріоритету самого потоку. Якщо у процесу тільки одне значення пріоритету (базове), то у кожного потоку їх два: поточне і базове. Рішення, пов'язані з плануванням, приймаються на основі поточного пріоритету. У певних обставинах система може на короткий час підвищувати пріоритети потоків в динамічному діапазоні (1-15). Windows ніколи не змінює пріоритети потоків в діапазоні реального часу (16-31), тому у таких потоків базовий пріоритет ідентичний поточному.
Зазвичай базовий пріоритет процесу (а значить, і базовий пріоритет первинного потоку) за замовчуванням дорівнює значенню з середини діапазонів пріоритетів процесів (24, 13, 10, 8, 6 або 4). Однак базовий пріоритет деяких системних процесів (наприклад, диспетчера сеансів, контролера сервісів та сервера локальної автентифікації) дещо перевищує значення за замовчуванням для класу Normal (8).
1.4 Стани процесів
Розглянемо стани в яких може перебувати процес:
Ready ( готовий ) Потік в стані готовності очікує виконання. Вибираючи наступний потік для виконання, диспетчер приймає до уваги лише пул потоків, готових до виконання.
Standby ( простоює ) Потік в цьому стані вже вибраний наступним для виконання на конкретному процесорі. У відповідний момент диспетчер перемикає контекст на цей потік. У стані Standby може перебувати тільки один потік для кожного процесора в системі. Потік може бути витіснений навіть у цьому стані (якщо, наприклад, до початку виконання потоку, який поки знаходиться в стані Standby, до виконання буде готовий потік з вищим пріоритетом).
Running ( виконується ) Потік переходить у цей стан і починає виконуватися відразу після того, як диспетчер перемикає на нього контекст. Виконання потоку припиняється, як тільки він завершується, витісняється потоком з більш високим пріоритетом, перемикає контекст на інший потік, самостійно переходить в стан очікування або закінчується виділений йому квант процесорного часу (і інший потік з тим же пріоритетом готовий до виконання).
Waiting ( очікує ) Потік входить в стан Waiting кількома способами. Він може самостійно почати очікування на синхронізуючому об'єкті або його змушує до цього підсистема оточення. Після закінчення очікування потік - в залежності від пріоритету - або негайно починає виконуватися, або переходить в стан Ready.
Transition ( перехідний стан ) Потік переходить в цей стан, якщо він готовий до виконання, але його стек ядра вивантажений з пам'яті. Як тільки цей стек завантажується в пам'ять, потік переходить в стан Ready.
Terminated ( завершено ) Закінчуючи виконання, потік переходить в стан Terminated. Після цього блок потоку виконавчої системи (структура даних у пулі непідкачуваної пам'яті, що описує даний потік) може бути вилучений, а може бути і не знищено - це вже визначається диспетчером об'єктів.
Initialized ( ініціалізований ) У цей стан потік входить в процесі свого створення.
Deferred Ready (готовий, відкладено). Це стан використовується для потоків, вибраних для виконання на конкретному процесорі, але поки не запланованих до виконання. Це новий стан призначено для того, щоб ядро могло звести до мінімуму термін застосування загальносистемного блокування до бази даних планування (scheduling database).
Рисунок 2 Стани процесів в Windows Server 2008
1.5 Перемикання контексту
Залежить від архітектури процесора. Типовий випадок збереження та відновлення покажчика команд, покажчиків стека ядра і користувальницький стек, покажчика на адресний простір, в якому виконується потік. Ядро зберігає цю інформацію, запихаючи її в поточний стек ядра, оновлюючи покажчик стека і зберігаючи його в блоці KTHREAD потоку. Далі покажчик стека ядра встановлюється на стек ядра нового потоку і завантажується контекст цього потоку. Якщо новий потік належить іншому процесу, в спеціальний регістр процесора завантажується адреса його каталогу таблиць сторінок, в результаті чого адресний простір цього процесу стає доступним.
При наявності відкладеної АРС ядра запитується переривання IRQL рівня 1. В іншому випадку управління передається завантаженому для нового потоку вказівником команд, і виконання цього потоку поновлюється.
2 Управління пам’яттю
2.1 Віртуальна пам'ять
У Windows реалізована система віртуальної пам'яті, заснована на плоскому (лінійному) адресному просторі. Вона створює кожному процесу ілюзію того, що у нього є власний великий і закритий адресний простір. Віртуальна пам'ять дає логічне уявлення, яке не обов'язково відповідає структурі фізичної пам'яті. У період виконання диспетчер пам'яті, використовуючи апаратну підтримку, транслює, чи проектує (maps), віртуальні адреси на фізичні, за якими реально зберігаються дані. Керуючи проектуванням і захистом сторінок пам'яті, операційна система гарантує, що жоден процес не завадить іншому і не зможе пошкодити дані самої операційної системи.
Оскільки у більшості комп'ютерів обсяг фізичної пам'яті набагато менший загального обсягу віртуальної пам'яті, задіяної виконуваними процесами, диспетчер пам'яті переміщує, або підкачує (pages), частина вмісту пам'яті на диск. Підкачка даних на диск звільняє фізичну пам'ять для інших процесів або самої операційної системи. Коли потік звертається до сторінки віртуальної пам'яті, скинутої на диск, диспетчер віртуальної пам'яті завантажує цю інформацію з диска назад в пам'ять. Для використання переваг підкачки в додатках ніякого додаткового коду не потрібно, тому що диспетчер пам'яті спирається на апаратну підтримку цього механізму.
Розмір віртуального адресного простору залежить від конкретної апаратної платформи. На 32-розрядних х8б-системах теоретичний максимум для загального віртуального адресного простору складає 4 Гб.
2.2 Структура адресних просторів
Рисунок 3 Структура адресних просторів
Windows Server 2008 підтримує завантажувальні параметри / 3GB та / USERVA, які вказуються у файлі Boot.ini, що дозволяє процесам, які виконують програми зі спеціальним прапором в заголовку виконуваного образу, використовувати до 3 Гб закритого адресного простору і залишає операційній системі тільки 1 Гб. Цей варіант дає можливість додаткам наприклад сервера бази даних зберігати в адресному просторі свого процесу великі порції бази даних і тим самим зменшити частоту проектування окремих уявлень цієї бази.
2.3 Диспетчер пам'яті
Завдання диспетчера управління пам'яттю:
Трансляція віртуального адресного простору процесу на фізичну пам'ять
Підкачка частини вмісту пам'яті на диск
Надання базового набору сервісів:
Підтримка файлів проектуються в пам'ять
Підтримка програм використовують великі розріджені адресні простори
Використання більше пам'яті, ніж можна спроектувати на віртуальний адресний простір процесу (AWE).
За замовчуванням віртуальний розмір процесу в 32-розрядної Windows - 2 Гб. Якщо образ позначений як підтримуючий великий адресний простір і система завантажується зі спеціальним ключем, 32-розрядний процес може займати до 3 Гб в 32-розрядної Window's і до 4 Гб в 64-розрядної.
Диспетчер управління пам'яттю вирішує два головні завдання:
Трансляція, або проектування (mapping), віртуального адресного простору процесу на фізичну пам'ять. Це дозволяє посилатися на коректні адреси фізичної пам'яті, коли потоки, що виконуються в контексті процесу, читають і записують у його віртуальному адресному просторі. Фізично резидентна підмножина віртуального адресного простору процесу називається робочим набором (working set).
Підкачка частини вмісту пам'яті на диск, коли потоки або системний код намагаються задіяти більший обсяг фізичної пам'яті, ніж той, який є в наявності, і завантаження сторінок назад у фізичну пам'ять по мірі необхідності.
2.4 Компоненти диспетчера пам'яті
Компоненти міститься у файлі Ntoskrnl.exe
Набір сервісів виконавчої системи для виділення, звільнення та управління віртуальною пам'яттю.
Обробники пасток трансляції недійсних адрес і порушень доступу для апаратно виявляються винятків.
Кілька ключових компонентів, які працюють в контексті шести різних системних потоків режиму ядра.
Диспетчер робочих наборів (working set manager) з пріоритетом 16. Диспетчер настройки балансу (системний потік, створюваний ядром) викликає його раз в секунду або при зменшенні обсягу вільної пам'яті нижче певного порогового значення. Він реалізує загальні правила управління пам'яттю, наприклад усічення робочого набору, старіння і запис модифікованих сторінок.
Потік завантаження і вивантаження стеків (process / stack swapper) з пріоритетом 23 - вивантажує (outswapping) і завантажує (inswapping) стеки процесу та потоку. При необхідності операцій зі сторінковим файлом цей потік пробуджується диспетчером робочих наборів та кодом ядра, що відповідає за планування.
Підсистема запису модифікованих сторінок (modified page writer) з пріоритетом 17. Записує змінені сторінки, зареєстровані в списку модифікованих сторінок, назад до відповідних сторінкові файли. Цей потік пробуджується, коли виникає потреба у зменшенні розміру списку модифікованих сторінок.
Підсистема запису спроектованих сторінок (mapped page «writer») з пріоритетом 17. Записує змінені сторінки спроектованих файлів на диск. Пробуджується, коли потрібно зменшити розмір списку модифікованих сторінок або коли сторінки модифікованих файлів у цьому списку більше 5 хвилин. Цей другий потік запису модифікованих сторінок потрібно тому, що він може генерувати помилки сторінок, в результаті яких видаються запити на вільні сторінки. Якби в системі був лише один потік запису модифікованих сторінок, вона могла б перейти в нескінченне очікування вільних сторінок.
Потік сегмента розіменування (dereference segment thread) з пріоритетом 18. Відповідає за зменшення розмірів системного кеша і зміна розмірів сторінкового файлу.
Потік обнулення сторінок (zero page thread) з пріоритетом 0. Заповнює нулями сторінки, зареєстровані в списку вільних сторінок.
3 Підсистема вводу-виводу
Система вводу-виводу виконавчої системи - це частина коду ОС, яка отримує запити вводу-виводу від процесів режиму користувача і передає їх, у перетвореному вигляді, пристроям введення-виведення. Між сервісами користувацького режиму та апаратурою введення-виведення розташовується кілька окремих компонентів системи, включаючи закінчені файлові системи, численні драйвери пристроїв і драйвери мережевих транспортів.
Система вводу-виводу управляється пакетами запиту вводу-виводу (I / O Request Packet, IRP). Кожен запит вводу-виводу представляється у вигляді пакета IRP під час його переходу від однієї компоненти системи вводу-виводу до іншої. IRP - це структура даних, що управляє обробкою операції вводу-виводу на кожній стадії її виконання.
У систему вводу-виводу входять наступні компоненти:
Диспетчер вводу-виводу (I / O manager) . Реалізує засоби вводу-виводу, що не залежать від типу пристрою, і встановлює модель для вводу-виводу виконавчої системи. Диспетчер вводу-виводу здійснює створення, читання, запис, установку і отримання інформації, та інші операції над файловими об'єктами. Диспетчер вводу-виводу реалізує асинхронну підсистему вводу-виводу, засновану на передачі пакетів запиту вводу-виводу (I / O Request Packet, IRP). Диспетчер вводу-виводу також відповідає за підтримку та забезпечення операційного середовища для драйверів.
Файлові системи. Драйвери, що приймають запити файлового вводу-виводу і транслюють їх в запити, прив'язані до конкретного пристрою. Сюди ж входять мережеві файлові системи, що складаються з двох компонентів: мережевого редиректора (network redirector), що реалізується як драйвер файлової системи, який передає віддалені запити вводу-виводу на машини в мережі, і мережевого сервера (network server), що є звичайним драйвером, які приймають і обробляють такі запити.
Мережеві драйвери, які можуть завантажуватися в ОС і розглядатися як частина системи вводу-виводу.
Драйвери пристроїв. низькорівневі драйвери, безпосередньо працюють з обладнанням.
Диспетчер вводу-виводу (I / O manager) визначає порядок, за яким запити вводу-виводу доставляються драйверам. До обов'язків диспетчера входить:
Отримання запиту на ввід-вивід і створення пакету IRP.
Передача IRP відповідному драйверу. Драйвер, отримавши IRP, виконує зазначену в ньому операцію вводу-виводу, і, або повертає його диспетчеру вводу-виводу для завершення обробки, або передає іншому драйверу для продовження операції вводу-виводу.
Супровід IRP по стеку драйверів.
Завершення IRP після закінчення операції вводу-виводу і повернення результатів обробки ініціатору запиту вводу-виводу.
Також диспетчер вводу-виводу реалізує загальні процедури, до яких звертаються драйвери під час обробки вводу-виводу, і надає системні сервіси, що дозволяють захищеним підсистемам реалізувати свої API вводу-виводу.
Більшість операцій вводу-виводу не вимагає участі всіх компонентів підсистеми введення-виводу. Як правило, запит на ввід-вивід видається застосунком, який виконує відповідну операцію (наприклад, читання даних з пристрою); такі операції обробляються диспетчером вводу-виводу, одним або декількома драйверами пристроїв і HAL.
У Windows, потоки виконують операції вводу-виводу над віртуальними файлами. Операційна система абстрагує всі запити на введення-виведення, приховуючи той факт, що кінцевий пристрій вводу-виводу може і не бути пристроєм з файловою структурою. Це дозволяє узагальнити інтерфейс між програмами та пристроями. Таким чином, віртуальний файл відноситься до будь-якого джерела або вводу-виводу (файлу, каталогу, іменовані канали і поштовою скринькою), який розглядається як файл. Всі зчитувані або записувані дані подаються простими потоками байтів, які направляються у віртуальні файли. Програми для користувацького режиму (хоч би до якої підсистемі вони не відносилися - Windows або POSIX) викликають документовані функції, які в свою чергу звертаються до внутрішніх функцій підсистеми вводу-виводу для читання / запису файлу і для виконання інших операцій. Запити, адресовані віртуальним файлам, диспетчер вводу-виводу динамічно направляє відповідним драйверам пристроїв. Базова схема обробки запиту на ввід-вивід показана на рисунку 4.
Рисунок 4 Базова схема обробки запитів на ввід-вивід4 Файлова система
4.1 Типи файлових систем
Windows підтримує такі файлові системи:
CDFS;
UDF;
FAT12, FAT16 и FAT32;
NTFS.
NTFS - вбудовані («рідна») файлова система Windows. NTFS використовує 64 розрядні номера кластерів. Це дозволяє NTFS адресувати томи розміром до 16 екзабайт (16000000000 Гб). Однак Windows, обмежує розміри томів NTFS до значень, при яких можлива адресація 32 розрядними кластерами, тобто до 128 Тб (з
використанням кластерів по 64 Кб). NTFS підтримує ряд додаткових можливостей - захист файлів і каталогів, дискові квоти, стиснення файлів, символьні посилання на основі каталогів і шифрування. Одне з найважливіших властивостей NTFS - відновлюваність. При несподіваній зупинці системи цілісність метаданих тома FAT може бути втрачена, що викличе пошкодження структури каталогів і значного обсягу даних. NTFS веде журнал змін метаданих шляхом протоколювання транзакцій, тому цілісність структур файлової системи може бути відновлена без втрати інформації про структуру файлів або каталогів. (Проте дані файлів можуть бути втрачені). Якщо в попередніх версіях Windows операційна система виявляла помилки у файловій системі томи NTFS, вона відзначала том як «брудний»; виправлення помилок на томі не могло бути виконане негайно. У самовідновлювальній NTFS замість блокування всього тому блокуються лише пошкоджені файл чи папки, що залишаються недоступними на час виправлення. Завдяки цьому більше немає необхідності перезавантаження сервера для виправлення помилок файлової системи.
Також операційна система тепер відображає інформацію SMART жорстких дисків щоб допомогти визначити можливі збої жорсткого диска.
4.2 Драйвер файлової системи
Драйвер файлової системи (file system driver, FSD) управляє форматом файлової системи. Хоча FSD виконуються в режимі ядра, у нього є цілий ряд особливостей у порівнянні зі стандартними драйверами режиму ядра. Можливо, найважливішою особливістю є те, що він повинен реєструватися у диспетчера вводу-виводу і більш інтенсивно взаємодіяти з ним. Крім того, для більшої продуктивності FSD зазвичай покладається на сервіси диспетчера кеша. Таким чином, FSD використовує більш широкий набір функцій, що експортуються Ntoskrnl, ніж стандартні драйвери. Якщо для створення стандартних драйверів режиму ядра вимагається Windows DDK, то для створення драйверів файлових систем знадобиться Windows Installable File System (IFS) Kit.
У Windows два типи драйверів файлових систем:
локальні FSD, керуючі дисковими томами, підключеними безпосередньо до комп'ютера;
мережеві FSD, що дозволяють звертатися до дискових томів, підключених до віддалених комп'ютерів.
4.3 Служба Volume Shadow Copy Service (VSS)
Служба Volume Shadow Copy Service (VSS) (Служба тіньового копіювання томів), або скорочено, VSS, дозволяє адміністраторам і сторонні постачальникам програмного забезпечення робити знімки файлової системи для подання більш швидкого виконання резервного копіювання і в деяких випадках миттєвого відновлення даних без необхідності отримання доступу до носія резервних копій. Також VSS-копії тома можуть монтуватися і бути доступними подібно любому іншому томові Windows, якщо виникне така необхідність.
4.4 Служба Distributed File System Replication (DFSR)
Служба Distributed File System Replication (Реплікація розподіленої файлової системи) – це протокол забезпечує високу степінь стабільності при реплікації, надаючи можливість точного адміністративного контролю і додаткові опції під час реплікацій і доступу. Для реплікації даних використовується протокол RDC (Remote Differential Compression – віддалене диференційне стиснення). RDC покращує процес реплікації за рахунок того, що припускає виконання реплікації тільки тих частин файлів, які змінилися, а не всіх файлів повністю і реплікація може бути захищеною при передачі.
5 Переваги та недоліки системи
Хоча в Windows Server 2008 було додано багато нових можливостей і функцій, спочатку слід звернути увагу на нововведення, які залишаються невидимими для очей, але відповідають за надання деяких самих базових можливостей цієї нової операційної системи. Вони являють собою технології, які роблять операційну систему швидшою, надійнішою і т.д., а не функціональні компоненти, які повинні встановлюватися або конфігуруватися.
Технологія Server Message Block 2.0
Ця технологія з'явилася в Windows Vista і Windows Server 2008, Server Message Block 2.0 (Блок повідомлень сервера), часто звана просто SMB2, являє собою протокол, який відповідає за передачу файлів між системами. По суті, SMB2 стискає файлові запити і за допомогою що маючи більший розмір буфера таких запитів скорочує кількість циклічних проходів, необхідних при передачі даних між системами.
Технологія Hyper-V
Hyper-V являє собою технологію, яка була вбудована в ядро в Windows Server 2008 і розширена в Windows Server 2008 R2 і яка дозволяє значно покращити продуктивність і можливості віртуалізації сервера в середовищі Windows. Раніше програмне забезпечення віртуального сервера розміщувалося поверх мережевої операційної системи, і кожен гостьовий сеанс залежав від багатьох, спільно використовуваних компонентів цієї операційної системи.
Технологія Hyper-V створює між абстрактним рівнем обладнання системи і рівнем операційної системи ще один дуже тонкий рівень, який дозволяє гостьовим сеансам у віртуальному середовищі взаємодіяти з рівнем обладнання системи напряму. Завдяки відсутності на шляху обслуговуючої (хост) операційної системи, гостьові сеанси можуть функціонувати набагато швидше, ніж раніше, і набагато стабільніше, оскільки, працюючи незалежно від операційної системи, їм не доводиться мати справу з наявними в ній вузькими місцями.
У Windows Server 2008 R2 також була покращена технологія управління енергоспоживанням під назвою "парковка ядер" (core parking). Зазвичай при застосуванні сервера з безліччю процесорів, всі ядра у всіх цих процесорів працюють на максимально можливій високій швидкості незалежно від того, чи використовується сервер. В організаціях, потребують високої робочої здібності тільки у робочі дні, коли їх співробітники трудяться, це означає, що їх системи, по суті, простоюють вечорами і на вихідних, тобто більше двох третин часу, при цьому як і раніше споживаючи енергію і нагріваючи повітря. У разі застосування технології паркування ядер сервери з новітніми процесорами, розпізнають протоколи паркування ядер, відключатимуть ядра в системі при відсутності необхідності в їх використанні. Тобто на сервері з 16 ядрами при наявності необхідності у використанні тільки 2 ядер, решта 14 будуть автоматично вимикатися. Це значно покращує управління енергоспоживанням і скорочує вартість операцій серверних систем.
Однією з нових вбудованих в Windows Server 2008 і Windows Server 2008 R2 технологій є самовідновлюється (self-healing) файлова система NTFS. По суті, у операційній системі є робочий потік, який виконується у фоновому режимі і в разі виявлення пошкодженого файлу або каталогу вносить у файлову систему NTFS відповідні виправлення. Раніше при появі проблеми у файловій системі звичай потрібно перезавантажувати сервер і тим самим дозволяти утиліті chkdsk запускатися і усувати помилки, які виникли через пошкодження файлів або каталогів. Побачити функцію самовідновлення в дії неможливо, але вона є однією з тих доданих можливостей всередині Windows Server 2008 R2, які дозволяють операційній системі працювати більш надійним чином і з меншою кількістю збоїв.
Висновки
Під час виконання даного комплексно-практичного індивідуального завдання було досліджено операційну систему Windows Server 2008, яка розширює базові можливості операційної системи Windows і надає нові потужні засоби, допомагаючи організаціям всіх розмірів підвищувати керованість, доступність і гнучкість відповідно до мінливих вимог бізнесу. Нові веб-засоби, технології віртуалізації, засоби управління і розширені можливості масштабування економлять час, знижують витрати і надають надійну платформу для створення ІТ-інфраструктури організації. Також в рамках виконання КПІЗ були детально досліджені принципи управління процесами та пам’яттю, ознайомлені з особливостями підсистеми вводу-виводу та файловою системою, висвітлені її переваг та недоліків перед іншими ОС. В додатку А наведений код який дозволяє взаємодіяти з Audio CD, а саме зчитувати інформацію про треки та програвати композиції.
Використані джерела
Моримото, Рэнд, Ноэл, Майкл, Драуби, Омар, Мистри, Росс, Амарис, Крис. М79 Microsoft Windows Server 2008 R2. Полное руководство. : Пер. с англ. — М. : ООО "И.Д. Вильяме", 2011. — 1456 с. : ил. — Парал. тит. англ. Эндрю С.
Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. Мастер-класс. / Пер. с англ. — 4-е изд. — М.: Издательство «Русская Редакция»; СПб.: Питер, 2008. — 992 стр.: ил.
Шеховцов В. Л. Операційні системи. К.: Видавнича група B1IV, 2005. 575 с.: іл. ISBN 966-552-157-8
http://www.microsoft.com/en-us/server-cloud/windows-server/default.aspx
http://www.ibm.com/developerworks/ru/edu/os_architecture_course2/
Додаток А
Код програми Device manager class implementation
// ccdinfo.cpp : device manager class implementation
#include "stdafx.h"
#include "ccdinfo.h"
CDInfo::CDInfo()
{
// We don't have an open device yet
m_MCIOpen.wDeviceID = 0;
m_nNumberOfTracks = 0;
}
CDInfo::~CDInfo()
{
// If we have an open device then we'll be nice and close it.
// if (m_MCIOpen.wDeviceID != -1)
// {
// mciSendCommand(m_MCIOpen.wDeviceID, MCI_CLOSE, NULL, NULL);
// }
}
short CDInfo::Read()
{
int i;
short nTrackLength;
m_nNumberOfTracks = 0;
m_MCIOpen.lpstrDeviceType = (LPCTSTR)MCI_DEVTYPE_CD_AUDIO;
if (mciSendCommand(NULL, MCI_OPEN, MCI_OPEN_TYPE|MCI_OPEN_TYPE_ID, (DWORD_PTR)&m_MCIOpen))
{
ATLTRACE(_T("Couldn't open CD player"));
}
m_MCIStatus.dwItem = MCI_STATUS_NUMBER_OF_TRACKS;
if (mciSendCommand(m_MCIOpen.wDeviceID, MCI_STATUS, MCI_STATUS_ITEM|MCI_WAIT, (DWORD_PTR)&m_MCIStatus))
{
ATLTRACE(_T("Error getting number of tracks"));
mciSendCommand(m_MCIOpen.wDeviceID, MCI_CLOSE, NULL, NULL);
return 0;
}
m_nNumberOfTracks = (short)m_MCIStatus.dwReturn;
if (m_nNumberOfTracks > MAX_TRACKS)
m_nNumberOfTracks = MAX_TRACKS;
m_MCIStatus.dwItem = MCI_STATUS_LENGTH;
for (i=0; i<m_nNumberOfTracks; i++)
{
m_MCIStatus.dwTrack = i+1;
mciSendCommand(m_MCIOpen.wDeviceID, MCI_STATUS, MCI_TRACK|MCI_STATUS_ITEM|MCI_WAIT, (DWORD_PTR)&m_MCIStatus);
nTrackLength = (short)(MCI_MSF_MINUTE(m_MCIStatus.dwReturn)*60 + MCI_MSF_SECOND(m_MCIStatus.dwReturn));
m_nTrackLength[i] = nTrackLength;
}
mciSendCommand(m_MCIOpen.wDeviceID, MCI_CLOSE, NULL, NULL);
return m_nNumberOfTracks;
}
void CDInfo::Play(short nTrack)
{
MCI_SET_PARMS mciSet;
MCI_PLAY_PARMS mciPlay;
m_MCIOpen.lpstrDeviceType = (LPCTSTR)MCI_DEVTYPE_CD_AUDIO;
if (mciSendCommand(NULL, MCI_OPEN, MCI_OPEN_TYPE|MCI_OPEN_TYPE_ID, (DWORD_PTR)&m_MCIOpen))
{
ATLTRACE(_T("Couldn't open CD player"));
}
// Set the time format to track/minute/second/frame (TMSF).
mciSet.dwTimeFormat = MCI_FORMAT_TMSF;
if (mciSendCommand(m_MCIOpen.wDeviceID, MCI_SET, MCI_SET_TIME_FORMAT, (DWORD_PTR)&mciSet))
{
mciSendCommand(m_MCIOpen.wDeviceID, MCI_CLOSE, 0, NULL);
return;
}
mciPlay.dwCallback = 0;
mciPlay.dwFrom = MCI_MAKE_TMSF(nTrack, 0, 0, 0);
if (mciSendCommand(m_MCIOpen.wDeviceID, MCI_PLAY, MCI_FROM, (DWORD_PTR)&mciPlay))
{
ATLTRACE(_T("Error playing track"));
}
mciSendCommand(m_MCIOpen.wDeviceID, MCI_CLOSE, 0, NULL);
}