Навигация
3. Продуктивність системи
Описана в цій роботі система реалізована на базі монітора віртуальних машин KVM [9]. KVM включений в основну гілку розробки ядра ОС Linux і являє собою модуль, що динамічно завантажений в ядро базової (хост) операційної системи Linux. Управління виконанням ВМ реалізується спільно ядром хост системи, модулем KVM та користувацький програмою QEMU. QEMU віртуалізується периферійні пристрої та забезпечує спільний доступ віртуальних машин до обладнання, встановленого на комп'ютері і керованого базовою системою.
Реалізація, представлена в цій роботі, побудована на базової операційної системи Linux з ядром версії 2.6.31.6 і моніторі віртуальних машин KVM версії 88. Сумарний обсяг коду компонент системи складає близько 16 тис. рядків. Віртуальні машини виконуються під управлінням ОС Linux з дистрибутива Fedora версії 9 зі штатним ядром версії 2.6.27.12–78.2.8.fc9.i686. На комп'ютері встановлений чотирьохядерних процесор Phenom 9750 компанії AMD з тактовою частотою 2.4 Ггц і 2 Гбайта оперативної пам'яті. Даний процесор підтримує технологію апаратної віртуалізації, включаючи віртуалізацію пам'яті на базі вкладених (NPT) таблиць приписки віртуальної машини. Базова операційна система використовує всі чотири ядра процесора (ядро базової ОС зібрано в SMP-конфігурації). Кожній віртуальній машині виділяється по одному віртуальному процесору і по 512 Мбайт оперативної пам'яті.
Для проведення ряду тестів використовується другий комп'ютер такої ж конфігурації. В обох комп'ютерах встановлені 100 Мбіт-ві мережеві адаптери, пов'язані один з одним через мережевий концентратор (хаб). До концентратора підключені тільки дані дві машини.
Доступ віртуальної машини до мережі здійснюється за допомогою створення в базовій ОС штатними засобами ядра ОС програмного мережевого інтерфейсу (TAP0). Цей інтерфейс є образом мережевого інтерфейсу (ETH0) віртуальної машини в базовій системі. Прив'язка інтерфейсу TAP0 до фізичної середовищі здійснюється через програмний Ethernet-міст (bridge) в ядрі базової ОС, також організовуваний штатними засобами ОС Linux. Така конфігурація (мал. 1) дозволяє відкрити ВМ для інших машин в мережі, на відміну від конфігурації QEMU за замовчуванням, що приховує ВМ від інших машин в мережі за допомогою механізму трансляції мережевих адрес (NAT) і роздільної лише вихідні з'єднання в ВМ.
Для тестування продуктивності ми використовували чотири спеціально розроблених синтетичних тесту, моделюючих «важкі» для системи сценарії використання, і три типових програми: утиліту тестування продуктивності мережі TTCP, програму віддаленого доступу SSH і веб-сервер Apache.
Синтетичні тести засновані на виконанні системного виклику select () з одним або двома файловий дескриптор. Один з дескрипторів (локальний), позначимо його LocalFD, являє собою файл, відкритий в контексті обчислювальної ВМ, другий (віддалений), позначимо його RemoteFD, – сокет, створений в сервісній ВМ. У всіх тестах, крім першого, виконання системного виклику вимагає взаємодії між ВМ. Тести запускаються з контексту обчислювальної ВМ.
Рисунок 5. Конфігурація мережі для тестування продуктивності.
Обрамлення дескриптора квадратними дужками означає, що запитувана операція не може бути виконана для даного ресурсу, і системний виклик заблокує виконання відповідного користувацького процесу в одній з ВМ. Відсутність квадратних дужок означає можливість виконання операції і негайне повернення управління для користувача процесу. Тоді синтетичні тести перевіряють наступні сценарії виконання системного виклику:
· select (LocalFD);
· select (RemoteFD);
· select (LocalFD, [RemoteFD]);
· select ([LocalFD], RemoteFD).
Виконання системного виклику select (LocalFD) не вимагає взаємодії між віртуальними машинами і характеризує «обчислювальні» накладні витрати усередині обчислювальної ВМ на перехоплення системних викликів, аналіз фактичних параметрів та ін Виконання системного виклику select (RemoteFD) показує сумарний час, необхідне на доставку запиту делегату в сервісну ВМ, виконання системного виклику в ній і повернення результатів процесу, яка перебуває весь цей час у стані очікування.
Виконання системного виклику select з двома дескрипторах включає в себе взаємодію між віртуальними машинами і, крім того, вимагає виконання скасування системного виклику в тій ВМ, в якій процес був заблокований, а саме, в тій ВМ, дескриптор ресурсу якої обрамлений квадратними дужками. Слід відзначити принципову відмінність третього і четвертого тесту. У тесті select (LocalFD, [RemoteFD]) скасування системного виклику, виконуваного делегатом в сервісній ВМ, проводиться асинхронно для процесу в обчислювальній ВМ, і він може продовжити своє виконання, не чекаючи підтвердження від мережевої ВМ. Така оптимізація можлива, оскільки для нормального продовження виконання процесу досить результатів, одержуваних локально від ядра обчислювальної ВМ. У свою чергу, в тесті select ([LocalFD], RemoteFD) процес не може продовжити виконання, поки виконання системного виклику не буде перервано, що призводить до додаткових накладних витрат.
У таблиці 1 вказано час виконання тестів (у секундах) у циклі з 100 тисяч ітерацій. Перший рядок таблиці характеризують виконання тесту select (LocalFD) в базовій системі. Другий рядок показує час виконання тесту select (LocalFD) у ВМ із включеним механізмом відстеження виконання процесу. Зростання часу виконання на один порядок обумовлено витратами на перехоплення інструкції INTn, що ініціює системний виклик і, головне, інструкції IRET, що реалізує повернення в призначений для користувача режим як з системного виклику, так з обробників переривань. Ми очікуємо, що за рахунок адаптації пропонованої системи під механізм швидкого виконання системних викликів (SYSCALL / SYSRET), підтримуваний сучасними процесорами сімейства x86, даний показник може бути покращено.
Показник у третьому рядку таблиці говорить про те, що власне обчислювальні витрати системи (за винятком перехоплення двох інструкцій) складають близько 20%. Четвертий рядок характеризує накладних витрати на асинхронну скасування частини системного виклику, виконуваної делегатом в сервісній ВМ. Відзначимо, що кілька послідовних операцій скасування також виконуються асинхронно, і синхронізація здійснюється тільки при наступному виконанні «істотного» (не скасовується) віддаленого системного виклику. Крім того, делегат не буде виконувати системний виклик, якщо виявить, що для нього вже надійшла команда на скасування. Таке можливо в силу асинхронності виконання віртуальних машин.
У тесті select (LocalFD, [RemoteFD]) синхронізація здійснюється тільки після вихід з циклу при закритті «віддаленого» сокета (системний виклик close). При наявності великої кількості послідовно скасованих системних викликів (100 тисяч в даному випадку) така операція синхронізації може займати тривалий час, що й відбито в таблиці. Безпосередньо при виході з основного циклу час виконання тесту складає всього 15 секунд. Подальша операція закриття сокета, що вимагає синхронізації операцій скасування, вимагає додаткових 16 секунд.
Останні два рядки таблиці характеризують повноцінне віддалене обслуговування системного виклику. Шостий рядок таблиці показує накладні витрати на скасування локальної частини системного виклику в обчислювальній ВМ, яка завжди виконується синхронно для процесу.
Таблиця 1. Час виконання синтетичних тестів
| Тест | Час (сек.) |
| Базова система | 1 |
| Віртуальна машина | 9 |
| select(LocalFD) | 11 |
| select (LocalFD, [RemoteFD]) | 15 (31) |
| select(RemoteFD) | 189 |
| select([LocalFD], RemoteFD) | 253 |
Синтетичні тести показують, що при найгіршому сценарії час виконання системного виклику може зростати до 250 разів. Однак на практиці це не робить істотного впливу на час виконання програми в цілому. По-перше, більшість системних викликів, що вимагають видаленого виконання, включає в себе передачу даних через периферійний пристрій (зокрема, через мережу). По-друге, додаток, як правило, виконує також інші дії, які нівелюють дані накладні витрати, наприклад, воно може часто перебуває у стані очікування відкриття семафора.
На малюнку 6 наведено результати тестування системи на утиліті TTCP, що виконує в циклі передачу пакетів між двома машинами в мережі. Перша діаграма відповідає оригінальній TTCP утиліті, друга – модифікованої, в яку ми додали виконання системного виклику select перед кожною посилкою пакета. Системний виклик select в даному випадку виконується віддалено, тобто відповідає синтетичному тесту select (RemoteFD). При виконанні оригінальної утиліти накладні витрати на віддалене обслуговування системних викликів склали всього 2% від сумарного часу виконання програми. Додавання системного виклику select збільшило накладні витрати до 31%, однак навіть у цьому випадку вони значно менше витрат в синтетичному тесті select (RemoteFD), де час виконання збільшилося в 189 разів.
Ми також тестували пропоновану систему на утиліті віддаленого доступу SSH за допомогою копіювання файлу між двома машинами в мережі, а також на веб-сервері Apache, запускаючи для нього пакет тестів навантажувального тестування Flood. В обох випадках час виконання тестів варіювалося в межах 1% від їх виконання на базовій системі. Таким чином, ми вважаємо, що пропонований механізм віддаленого обслуговування системних викликів є досить ефективним для його використання в промислових завданнях.
Рисунок 6. Час виконання утиліти TTCP (сек)
Висновок
У даній роботі представлено підхід до віддаленого виконання системних викликів користувацького процесу, що не вимагає внесення будь-яких змін (у тому числі, перекомпіляції) ні в код процесу, ні в код операційної системи. Особливістю розглянутого підходу є те, що процесу може бути наданий контрольований доступ до таких ресурсів, до яких операційна система, під управлінням якої виконується процес, ні прямої, ні опосередкованої доступу не має. Це дозволяє надавати селективний доступ до ресурсів, що вимагає контролю (наприклад, мережі Інтернет), окремим довіреною користувальницьким процесам, залишаючи в той же час ці ресурси недоступними іншим процесам і навіть ядру операційної системи.
Пропонований підхід заснований на виконанні операційної системи (і керованих нею процесів) всередині апаратної віртуальної машини. Монітор віртуальних машин (гіпервізор) перехоплює системні виклики окремих довірених процесів і при необхідності передає їх на обслуговування сервісної машині. Сервісна машина може бути інший віртуальною машиною, виконується паралельно, або іншої фізичної машиною, з якою у гіпервізора є канал зв'язку.
Розглянутий підхід реалізовано на базі монітора віртуальних машин KVM. В якості сервісної машини використовувалася паралельно виконує віртуальна машина, а в якості контрольованих ресурсів було вибрані мережеві ресурси (у т.ч. ресурси Інтернету). Тестування продуктивності системи показало, що на реальних додатках накладні витрати на віддалене обслуговування системних викликів укладаються в межі 3 відсотків.
Література
1.Tanenbaum, A.S., Herder, J.N., Bos, H. Can We Make Operating Systems Reliable and Secure?. Computer 39, 5 (May 2006), pp. 44–51.
2.Burdonov, I., Kosachev, A., Iakovenko, P. Virtualization-based separation of privilege: working with sensitive data in untrusted environment. In Proceedings of the 1st Eurosys Workshop on Virtualization Technology for Dependable Systems, New York, NY, USA, 2009, ACM, pp. 1–6.
3.Яковенко П.М. Контроль доступу процесів до мережевих ресурсів на базі апаратної віртуалізації. Методи і засоби обробки інформації. Праці Третьої Всеросійської наукової конференції, М, 2009, стор 355–360.
4.Chen, X., Garfinkel, T., Lewis, E.C., Subrahmanyam, P., Waldspurger, C.A., Boneh, D., Dwoskin, J., Ports, D.R. Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems. In Proceedings of the 13th international Conference on Architectural Support For Programming Languages and Operating Systems, ACM, 2008, pp. 2–13.
5.Adams, K., Agesen, O. A comparison of software and hardware techniques for x86 virtualization. In Proceedings of the 12th international Conference on Architectural Support For Programming Languages and Operating Systems, ACM, 2006, pp. 2–13.
6.VirtualSquare: Remote System Call.
7.Sun Microsystems, Inc. RPC: Remote Procedure Call. Protocol Specification. Version 2. Network working group. RFC 1057. 1988.
8.Sun Microsystems, Inc. NFS: Network File System Protocol Specification. Network working group. RFC 1094. 1989.
9.Shah. A. Deep Virtue: Kernel-based virtualization with KVM. Linux Magazine (86), 2008, pp. 37–39.
Похожие работы
... WRR) і його модифікації; - кругове обслуговування з дефіцитом (Deficit Round-Robin, DRR) і його модифікації. Рисунок 1 – Класифікація механізмів обслуговування черг 2. Механізм обслуговування черг FIFO обслуговування алгоритм черга комутатор FIFO (First In – First Out, "першим прийшов – першим пішов") є найпростішим механізмом обслуговування черг, відповідно до якого пакети передаються ...
... допомогою програм пакету ResourseKit фірми Microsoft. Увага! Будь-яке некваліфіковане втручання в структуру системного реєстру може призвести до краху всієї системи. Якщо ви адмініструєте сервер, чи робочу станцію на основі Win9x/nt/2000 , то системний реєстр допоможе вам підвищити рівень безпеки та ефективності вашої системи . Однак, кожен раз запускати редактор реєстру і шукати потрібні ключі , ...
... RTOS складається з ядра, планувальника процесів (process manager) і розширених сервісів на рівні користувача. Як справжня мікроядерного операційна система, QNX Neutrino RTOS реалізує в ядрі ОС тільки найбільш фундаментальні сервіси, такі як передача повідомлень, сигнали, таймери, планування потоків, об'єкти синхронізації. Всі інші сервіси ОС, драйвери та програми виконуються як окремі процеси, які ...
... своєчасне виявлення відхилень від прийнятих стандартів і цілей кредитної політики банку. Кредитний моніторинг є одним із важливих елементів удосконалення механізму здійснення кредитних операцій. Контроль за ходом погашення позички і виплатою відсотків по ній служить важливим етапом усього процесу кредитування. Він полягає в періодичному аналізі кредитного досьє позичальника, перегляді кредитного ...
0 комментариев