47599 (572041), страница 3
Текст из файла (страница 3)
При віддаленому обслуговуванні системного виклику делегат може отримати сигнал від ОС в сервісній ВМ, наприклад, сигнал SIGPIPE про розрив мережевого з'єднання. У цьому випадку делегат сповіщає гіпервізор про здобутий сигналі, і гіпервізор доставляє сигнал довіреній процесу. Для цього він інформує про сигнал модуль ядра ОС, який, у свою чергу, доставляє сигнал процесу засобами API ядра ОС Linux. Доставка процесу сигналу може привести до його аварійного завершення. У цьому випадку монітор повідомить гіпервізор про закінчення виконання процесу, і гіпервізор звільнить пам'ять, відведену під службові структури даних.
2.1 Точка обслуговування системного виклику
У переважній більшості випадків системний виклик може бути асоційований з ресурсами якої-небудь однієї з віртуальних машин або на підставі номера системного виклику, або на підставі його параметрів. Зокрема, системний виклик socket, що створює кінцеву точку для мережевої взаємодії і повертає файловий дескриптор для роботи з нею, повинен обслуговуватися в сервісній ВМ. Системний виклик write вимагає додаткового аналізу файлового дескриптора, що передається в параметрах дзвінка. Якщо дескриптор асоційований з сокетом, то він повинен обслуговуватися в сервісній ВМ, в іншому випадку – в обчислювальній ВМ.
ОС в обох ВМ підтримують набори файлових дескрипторів для довіреної процесу і його делегати незалежно один від одного. Якщо гіпервізор після віддаленого обслуговування системного виклику поверне довіреній процесу ідентифікатор файлового дескриптора, отриманого від делегата, без будь-яких змін, то це може призвести до наявності в пам'яті довіреної процесу двох ідентичних дескрипторів, які насправді відповідають різним ресурсів в тій і іншій ВМ. У подальшому, при виконанні довіреною процесом системного виклику для такого дескриптора гіпервізор не зможе розрізнити, чи відноситься виклик до локального ресурсу в обчислювальній ВМ або віддаленого в сервісній ВМ.
Для вирішення цієї проблеми гіпервізор реалізує додатковий рівень абстракції файлових дескрипторів для довірених процесів. Файлові дескриптори, що зберігаються в пам'яті довіреної процесу (в якихось змінних), являють собою не реальні дескриптори, призначені ядром ОС в обчислювальній або сервісній ВМ, а індекси в таблиці віддалених ресурсів, підтримуваної гіпервізора. Гіпервізор перехоплює і обробляє всі системні виклики довіреної процесу, у яких вхідні або вихідні параметри містити файлові дескриптори. Якщо параметр вхідний, то гіпервізор витягує з таблиці віддалених ресурсів фактичний файловий дескриптор, модифікує параметри системного виклику і передає його на обслуговування тієї ВМ, яка є власником ресурсу з цим дескриптором. Якщо параметр вихідний, то гіпервізор створює новий запис у таблиці віддалених ресурсів, позначаючи, яка з віртуальних машин є власником ресурсу, і модифікує вихідні параметри процесу, підставляючи індекс створеної запису замість фактичного значення дескриптора. Компонента гіпервізора, що відповідає за обробку файлових дескрипторів, враховує особливості виділення вільних дескрипторів ОС Linux, включаючи нюанси роботи системних викликів dup2 і fcntl. Таким чином, за значенням, передається довіреною процесом, завжди можна визначити віртуальну машину – власника ресурсу та номер файлового дескриптора в її контексті.
У ряді випадків виконання системного виклику може задіяти ресурси обох ВМ. Зокрема, параметри системного виклику select і його аналогів, а саме, набори файлових дескрипторів, для яких процес очікує виникнення відповідних подій, можуть одночасно ставитися до ресурсів як обчислювальної, так і сервісної ВМ. Такий виклик повинен обслуговуватися одночасно в обох ВМ, інакше програма може перестати виконуватися коректно. При цьому системний виклик в кожній віртуальній машині повинен обслуговуватися тільки з тими параметрами (файловий дескриптор), які відносяться до ресурсів даної ВМ.
При перехопленні запиту на виконання системного виклику, що вимагає одночасного виконання в обох ВМ, гіпервізор, використовуючи таблицю віддалених ресурсів, розшивають фактичні параметри на два непересічних набору (по одному для кожної з ВМ) і виконує виклик одночасно в обох ВМ з відповідними наборами параметрів. Модифікований набір параметрів записується в пам'ять довіреної процесу поверх оригінального. Перед поверненням управління процесу (після обслуговування системного виклику) гіпервізор відновлює вихідний набір параметрів, можливо, коректуючи його з урахуванням результатів системного виклику, отриманих з сервісної ВМ. Підсумковим результатом виконання системного виклику є результат тієї ВМ, яка хронологічно першою закінчила виконання своєї частини виклику, результати другий ВМ відкидаються.
Після отримання результатів від однієї з ВМ гіпервізор виробляє скасування виконання системного виклику в іншій ВМ. Механізм скасування виконання системного виклику реалізований в обох віртуальних машинах по-різному. У разі обчислювальної ВМ модуль ядра посилає довіреній процесу певний сигнал (не використовується процесом). При цьому модуль системи захисту безпосередньо перед посилкою сигналу реєструє для процесу спеціальний «порожній» обробник сигналу, що представляє собою адресу RET інструкції в коді довіреної програми. Адреса інструкції вказується в паспорті завдання. Реєстрація обробника гарантує, що посилка сигналу не призведе до аварійного останову процесу. У сервісній ВМ всі системні виклики, які можуть виконуватися одночасно в обох ВМ, виконуються в окремому потоці (нитки) делегати. Скасування виконання системного виклику проводиться за допомогою примусового завершення цього потоку.
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 разів. Однак на практиці це не робить істотного впливу на час виконання програми в цілому. По-перше, більшість системних викликів, що вимагають видаленого виконання, включає в себе передачу даних через периферійний пристрій (зокрема, через мережу). По-друге, додаток, як правило, виконує також інші дії, які нівелюють дані накладні витрати, наприклад, воно може часто перебуває у стані очікування відкриття семафора.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
