Платформа або ПО
|
Підтримувані
технології
|
Примітка
|
Kernel-based
Virtual Machine (KVM)
|
Intel VT, AMD-V
|
Віртуалізація рівня
екземплярів операційних систем під Linux.
|
Microsoft Virtual
PC
|
Intel VT, AMD-V
|
Настільна платформа
віртуалізації для хостових Windows-платформ.
|
Microsoft Virtual
Server
|
Intel VT, AMD-V
|
Серверна платформа
віртуалізації для Windows. Версія з підтримкою апаратної віртуалізації,
Microsoft Virtual Server 2005 R2 SP1
|
Parallels
Workstation
|
Intel VT, AMD-V
|
Платформа
віртуалізації для Windows і Linux хостів.
|
VirtualBox
|
Intel VT, AMD-V
|
Настільна платформа
віртуалізації з відкритим вихідним кодом для Windows, Linux і Mac OS.
|
Virtual Iron
|
Intel VT, AMD-V
|
Virtual Iron 3.5 є
першою платформою віртуалізації, що використовує апаратні техніки, яка
дозволяє запускати 32-бітові та 64-бітові незмінені гостьові системи
практично без втрати продуктивності.
|
VMware Workstation
и VMware Server
|
Intel VT, AMD-V
|
Для запуску 64-х
бітних гостьових систем потрібна підтримка Intel VT (так само як і для VMware
ESX Server), для 32-бітних ж гостьових ОС за замовчуванням підтримка IntelVT
відключена з тих же причин , що і у VirtualBox.
|
Xen
|
Intel VT, AMD-V
|
Платформа
віртуалізації Xen з відкритим вихідним кодом.
|
1.2.3
Віртуалізація на рівні операційної системи
Віртуалізація на рівні операційної системи - віртуалізує
фізичний сервер на рівні ОС, дозволяючи запускати ізольовані і безпечні
віртуальні сервери на одному фізичному сервері. Ця технологія не дозволяє
запускати ОС з ядрами, відмінними від типу ядра базової ОС. При віртуалізації
на рівні операційної системи не існує окремого шару гіпервізора. Замість цього
сама хостова операційна система відповідає за розподіл апаратних ресурсів між
декількома віртуальними серверами і підтримку їх незалежності один від одного.
Ядро операційної системи підтримує декілька ізольованих
екземплярів простору користувача, замість одного. Ці примірники (часто звані
контейнерами або зонами) з точки зору користувача повністю ідентичні реальному
серверу. Для систем на базі UNIX, ця технологія може розглядатися як поліпшена
реалізація механізму chroot. Ядро забезпечує повну ізольованість контейнерів,
тому програми з різних контейнерів не можуть впливати одина на одну.
Також потрібно відмітити ще два типи віртуалізаії, досить
специфічних, та все ж таки займаючих своє вагоме місце серед технологій
віртуалізації:
Віртуалізація програмного продукту
Віртуалізація додатків увазі використання моделі ізоляції
прикладних програм та їх взаємодії з ОС, коли виртуализует кожен екземпляр
додатку, всі його основні компоненти: файли (у тому числі системні), реєстр,
шрифти, INI-файли, COM-об'єкти, служби. У якомусь сенсі цей вид віртуалізації
можна вважати спрощеним варіантом віртуальних контейнерів для окремого додатка.
На відміну від віртуалізації ОС цей підхід не вирішує питань роботи з
успадкованими додатками, а тільки проблему надійної роботи додатків в
багатозадачному середовищі.
Програма в цьому випадку виконується без інсталяції в
традиційному її розумінні і може запускатися з зовнішніх носіїв (наприклад, з
флеш-карт або з мережевих папок). З точки зору ІТ-відділу такий підхід має
переваги: прискорюється розгортання настільних систем і з'являється можливість
управління ними, зводяться до мінімуму конфлікти між додатками і потреби в
тестуванні сумісності додатків. Фактично саме такий варіант віртуалізації
використовується в Microsoft Appication Virtualization (раніше Softgrid),
VMware Thinstall, Symantec / Altiris Virtualization, Novell ZENworks
Application Virtualization.
Найбільш поширеними продуктами, що дозволяють використовувати
такий тип віртуалізації є ThinApp від VMware та App-V від Microsoft.ThinApp
(раніше відома як Thinstall) - засіб для віртуалізації та створення переносимих
додатків від компанії VMware, призначене для перенесення існуючих програм на
інші платформи без перекомпіляції і тестування.здатна виконувати будь-який
додаток без установки в традиційному розумінні за допомогою віртуалізації
(емуляції) ресурсів (змінних середовища, файлів і реєстру Windows). Всі ресурси
зберігаються на диску в папці програми. Коли додаток запитує який-небудь
ресурс, шар віртуалізації ThinApp перехоплює запит і повертає запитувана
значення з файлу на диску. Додаток вважає себе повністю встановленим. ThinApp
не вимагає установки ні програм, ні драйверів. Це дозволяє запускати
віртуалізовані застосування з USB-накопичувачів або мережевих дисків без прав
адмінінстратора. ThinApp перетворює звичайні файли встановлення (наприклад,
файли *. Msi) в автономні EXE файли, що містять все необхідне для запуску
програми. ThinApp також може створити переносний додаток на основі даних про
зміни в системних файлах і реєстрі, але для цього потрібно просканувати систему
до і після установки програми. На відміну від архівів, ThinApp не виносить
файли на диск. ThinApp підтримує збірки ОС Windows починаючи від Windows NT
4.0.Application Virtualization (APP-V) - це рішення віртуалізації додатків не
вимагає установки самого додатка на комп'ютер користувача. Додаток безпечно
доставляються користувачеві на вимогу. Це значно підвищує ефективність ІТ і дає
велику гнучкість бізнесу і кінцевим користувачам. Використання віртуалізації
додатків переводить додатки з розряду звичайних, що вимагають установки, в
сервіси доступні по мережі. APP-V представляє нові можливості користувацького
інтерфейсу та процесу керування чергою доступу.
Гнучка віртуалізація, реалізована у останній версії App-V,
дозволяє ізольовані додатки пов'язати між собою, щоб вони взаємодіяли один з
одним і з встановлюваними додатками. Це забезпечує компанії переваги обох
середовищ: незважаючи на ізоляцію, яка зменшує число конфліктів і кількість
часу, що витрачається на регресивне тестування, додатки при необхідності можуть
взаємодіяти і обмінюватися даними один з одним.
Віртуалізація візуалізації
Цей термін ввела пару років тому компанія Microsoft для
позначення технологій термінального доступу, які почали активно застосовуватися
для x86-сумісних комп'ютерів з кінця 90-х рр.. Основна ідея тут - поділ
процесів виконання програми та візуалізації інтерфейсу користувача, що
забезпечує перенесення основного обчислювального навантаження на сервер і
дозволяє застосовувати тонкий клієнт.
Поява засобів термінального доступу спочатку була пов'язана в
основному із використанням застарілих ПК і успадкованого ПЗ: настільні додатки
виконувалися на серверах, а робочі станції застосовувалися лише як термінали
для забезпечення користувацького інтерфейсу Але потім стало видно і інші,
навіть більш важливі переваги централізованої обробки даних, зокрема щодо
забезпечення безпеки та зниження витрат на адміністрування систем.
Створення та розвиток технологій термінального доступу
пов'язано з компаніями Cirtix і Microsoft, які мають багаторічну історію
стратегічного співробітництва в цій сфері, де Citrix займає лідируючі позиції
на рівні high-end-рішень зі своїм комплексом XenApp (раніше називався
Presentation Server), а Microsoft домінує на low -сегменті з Windows Terminal
Services.
Однак в останні роки в цій сфері починають активно діяти і
інші компанії, в тому числі виробники апаратних засобів (HP, Sun, Wyse).
З'являються також гравці з якісно новими рішеннями. І тут потрібно в першу
чергу згадати про швидко набираючі популярність рішення компанії NComputing.
У дещо спрощеному вигляді термінальна технологія дозволяє
перетворити програмний продукт на клієнт-серверний варіант завдяки перехопленню
користувацького інтерфейсу, який потім передається на ПК, де виповнюється
спеціалізованим клієнтським ПЗ під управлінням стандартної операційної системи.
Рішення NComputing - це спеціалізований програмно-апаратний комплекс, що з
програмного середовища віртуалізації vSpace і термінальних пристроїв (до 30),
до яких підключаються монітор, клавіатура і миша, т.д.
В порівнянні з традиційним варіантом на клієнтському місці замість
системного блоку, ОС і клієнтського ПЗ використовується спеціалізований
пристрій (тонкий клієнт). Ключову роль у цьому комплексі грає ПО vSpace, про
архітектуру якого поки майже нічого невідомо. Швидше за все, це ПЗ реалізує
якийсь змішаний варіант технології віртуальних контейнерів і термінального
сервера стосовно до настільних систем. При цьому обмін даними між сервером і
терміналом виконується за допомогою патентованого протоколу UXP, оптимізованого
для обміну мультимедійною інформацією. Загалом очевидно, що NComputing
поступається в універсальності (обмежене число терміналів, що підключаються
тільки в локальних мережах) традиційному варіанту терміналів на базі ПК, але в
той же час може ефективно застосовуватися в багатьох реальних ситуаціях.
На даному етапі найбільш популярним варіантом термінального
доступу для Unix систем є FreeNX server - сервер (безкоштовна версія серверу NX
NoMachine), не обмежений за кільістю одночасно підключених клієнтів, та
безкоштовний для комерційного використання.- технологія реалізації системи
"віддаленого терміналу". Забезпечує реакцію запускаються програм,
порівнянну з часом їх виконання на локальній системі. FreeNX зберігає високу
інтерактивність додатків при великій завантаженості та низької швидкості каналу.
Базові бібліотеки надані nomachine під вільною ліцензією GPL.
Також існує так званий Linux Terminal Server Project (LTSP) -
це вільно поширюваний додатковий пакет для Linux з відкритим вихідним кодом,
який дозволяє декільком людям з малопотужними комп'ютерами (терміналами)
використовувати обчислювальні потужності одного, більш продуктивного комп'ютера
(сервера). При цьому, всі програми запускаються на сервері, а термінали, так
само звані тонкими клієнтами (або X-терміналами), просто приймають відеоряд, що
посилається сервером, і крім нього нічого не обробляють. Як правило, термінал
являє собою малопотужний комп'ютер, в ньому навіть може бути відсутнім жорсткий
диск, внаслідок чого він може працювати тихіше, ніж звичайний настільний
комп'ютер.
Технологія тонких клієнтів знайшла широке застосування в
таких установах як школи, так як дозволяє забезпечити учням доступ до
комп'ютерів без покупки або модернізації наявних настільних комп'ютерів. При
нестачі в школі комп'ютерів, організація нових тонких клієнтських машин є менш
дорогою, ніж покупка повноцінних комп'ютерів. А якщо перед школою стоїть
питання оновлення комп'ютерної техніки, то можна відкласти це питання шляхом
переконфігурації комп'ютерів в тонкі клієнти, так як навіть відносно повільний
процесор має достатню продуктивність для ролі тонкого клієнта. І тоді достатньо
придбати один потужний комп'ютер, який буде виконувати роль сервера для інших.
Крім економії коштів, освітній заклад також отримує більше
контролю над використанням обчислювальних ресурсів учнями. Прикладами
використання LTSP можуть послужити AbulЙdu, Edubuntu, K12LTSP і Skolelinux.
LTSP підтримується компаніями Cutter project і Deworks.
1.2.4
Віртуалізація мережевого обладнання
При проектуванні сучасних комп'ютрених мереж, розрахунку
навантаження на мережу, що у майбутньому буде обслуговувати потреби робітників
підприємства, важко урахувати усі можливі фактори, що можуть у тій чи іншій
мірі негативно вплинути на подальшу роботу мережевого обладнання да усієї
локальної мережі підприємства вцілому.
Студенту технічного вузу важко буде зрозуміти принцип роботи
з мережевим обладнанням, якщо він не буде в змозі самостійно познайомитися з
його командним інтерфейсом, на практиці закріпити отримані знання, та отримати
досвід у справжніх "бойових" ситуаціях.
На думку відразу спадає всім відомий Cisco Packet Tracer, та
він надає можливість оперувати приблизно 80% команд консолі, і, якщо вам
недостатньо цого, на допомогу приходить GNS3 - графічний симулятор мережевого
обладнання, такого як CISCO, котрий дозволяє будувати мережеві топології та
взаємодіяти з гіпервізорами другого рівня на зразок VirtualBox.
Можливості програми:
) Симуляція ATM, Frame Relay і Ethernet комутаторів
) Проектування найскладніших топологій
) Зв'язок віртуальної мережі з реальною
) Побудова великих мереж на основі роутерів
(відпрацювання різних протоколів динамічної маршрутизації).
) Використання сторонніх гіпервізорів
Слід зауважити, що GNS3 складається одразу з декількох
програм (Dynamips, Dynagen, Qemu / Pemu, Putty, VPCS, WinPCAP і Wireshark).
Ця своєрідна "солянка" дозволить вам на максимум
наблизиться до "бойових" умов. Пакет абсолютно безкоштовний та
доступний для установки на операційні системи сімейства Windows, Linux-based
дистрибутиви та MacOS. На даному етапі, на думку багатьох спеціалістів та
викладачів, не існує кращого інструменту як для підготовки до здачі екзаменів
CCNA, так і для перевірки работоздатності компьютерної мережі перед непосредньо
монтажем ії у будівлі.
1.2.5 Постановка задачі
) Опрацювати літературу по заданій дипломній роботі.
) Дослідити особливості рішень з віртуалізації за
різних технологій та розробників, описати принцип роботи основних методів, їх
особливості, достоїнства і недоліки.
) На основі отриманих знань розробити макет
комп’ютерної мережі для будівлі середнього офісу, використовуючи технології
віртуалізації та вільне програмне забезпечення.
2. Теоретична
частина
.1 Віртуалізація як інструмент навчання, проектування мереж
та системного адміністрування
2.1.1
Віртуалізація в адмініструванні комп’ютерних мереж
У контексті системного адміністрування найбільш істотні дві
властивості будь-якої технології віртуалізації. Перше полягає в тому, що
віртуалізація вводить проміжний рівень між обладнанням (апаратним
забезпеченням) і програмним забезпеченням. Використання цього рівня дає
адміністратору можливість гнучко управляти розподілом апаратних ресурсів між
паралельно виконуються програмами. Друге - приміщення програм у віртуальне
оточення досить надійно ізолює їх від всіх інших програм, що виконуються на
цьому ж фізичному обладнанні поза даного оточення. Тим самим радикально
знижується ймовірність побічного впливу роботи одних програм на роботу інших, в
тому числі знижується ймовірність атак, побудованих на подібних побічних
взаємодіях.
.1.2
Сервери та сервіси
Під сервером зазвичай розуміється окремий (зазвичай потужний)
комп'ютер, спеціалізований під виконання завдань з обслуговування абонентів
(надання сервісів). Кількість таких сервісів, одночасно виконуються в рамках
одного сервера, обмежена зверху обчислювальними можливостями обладнання,
пропускною здатністю каналу для запитів клієнтів тощо На практиці кількість
сервісів на одному сервері зазвичай більше одного, як з економічних міркувань
(невигідно дозволяти простоювати дорогому серверного обладнання ), так і з
технологічних (найчастіше сервіси буває зручно агрегованих на одному вузлі, т.
к. вони можуть працювати взаємопов'язано, наприклад, з одними і тими ж даними).
З розвитком технологій постійно наростаючі потужності
комп'ютерного обладнання набагато випереджають зростання запитів до ресурсів з
боку програм. У результаті все вище піднімається верхня межа за кількістю
можливих сервісів на одному сервері, і все більш невигідно стає тримати сервер
тільки для одного сервісу - ресурси простоюють.
2.1.3
Віртуалізація сервісів
Традиційний підхід до розміщення сервісів полягає в тому, що
на одному фізичному сервері працює одна операційна система, в рамках якої
виконуються декілька системних служб, що надають ті чи інші сервіси.
У кількох завдань, що виконуються в рамках однієї ОС (інакше
кажучи, в розділенову середовищі), завжди є можливості для взаємодії, оскільки
ОС саме для організації такої взаємодії і призначена. Крім того, в розділеному
середовищі завдання спільно користуються загальними інтерфейсами (файлова
система, структури ядра ...) і в кінцевому підсумку загальними апаратними
ресурсами, що відкриває дорогу побічним взаємодіям. У разі незалежних сервісів
подібна взаємодія рівнозначно перешкод і порушення роботи.
У UNIX-системах, при розробці яких багатозадачність була
одним з найважливіших пріоритетів, вже присутній комплекс засобів для вирішення
завдань ізоляції та контролю. До подібних засобів відносяться, наприклад,
системний виклик chroot (), що забезпечує ізоляцію на рівні файлової системи, у
FreeBSD існує також технологія jail, додатково до цього обмежує доступ до
структур ядра. В останніх версіях ядра Linux реалізована підтримка апаратної
паравіртуалізації (kvm, застосовне в тому випадку, якщо її підтримує процесор).
Однак стандартні засоби UNIX-систем не вирішують всіх проблем спільного
розміщення сервісів.
Простіше кажучи, в розділяється середовищі працює логіка:
"хто встиг, той і з'їв". Тому в ситуації, коли критично важлива
робота декількох сервісів, особливо вимогливих до апаратних ресурсів, робота в
рамках однієї розділяється середовища (ОС) може бути небажана.
Шлях вирішення означених проблем - використовувати засоби
віртуалізації, щоб виключити можливості побічного взаємодії та отримати
додаткову до засобів ОС точку контролю за споживанням апаратних ресурсів. Так,
останнім часом нормою поступово стає розміщення декількох сервісів в рамках
одного сервера не в одній і тій же ОС, а в окремих віртуальних оточеннях. Далі
ми будемо називати таке віртуальне оточення з працюючою в ньому системної
службою віртуальним контейнером.
З точки зору завдання віртуалізації сервісів не принципово,
яка конкретно технологія віртуалізації обрана для створення контейнера. При
великому обчислювальному навантаженні це навряд чи може бути віртуальна машина,
що емулює все обладнання комп'ютера, але цілком може використовуватися одна з
систем з гіпервізором. Для UNIX-систем може бути досить зручно застосовувати
одну з технологій віртуалізації на рівні ОС, доводять кошти ізоляції та
контролю UNIX до рівня, достатнього для організації повноцінних віртуальних
оточень. До таких технологій відносяться OpenVZ (широко застосовуваний в ALT
Linux) і VServer.
Висока надійність і гарантоване обслуговування
У багатьох областях обслуговування абонентів критично важливо
забезпечувати постійну роботу сервісу, мінімізувати простої через неполадки або
управлятися з великим потоком запитів, щоб вони не приводили до порушення
роботи сервісу. Системи, що володіють технічними характеристиками для виконання
цих умов, називають системами високої надійності (high availability systems).
Приміщення сервісу у віртуальний контейнер можна використовувати для підвищення
надійності його роботи.
Обмеження ресурсів
Апаратні ресурси, доступні віртуальним контейнерів, повинні
бути завжди менше апаратних ресурсів всієї системи.
Бувають ситуації, особливо при роботі під великим
навантаженням, коли витребувані сервісом ресурси настільки великі, що можуть
призвести до неработопособності самої операційної системи. Засобами
віртуального оточення можна обмежити верхню межу ресурсів системи, що
виділяються сервісу в рамках віртуального контейнера. Технологія віртуалізації
застосовується в даному випадку як засіб контролю ресурсів, споживаних окремим
завданням, і забезпечує неперевищення цих ресурсів (оскільки задача не має
прямого доступу до обладнання). Це завдання більшість засобів віртуалізації
вирішує досить надійно. Такий підхід підвищує надійність системи, оскільки
гарантує операційну систему від непрацездатності з причини перевищення ресурсів
з боку сервісу. Однак цей метод, природно, не може гарантувати від збоїв самого
сервісу, викликаних, наприклад, великим потоком запитів. Поміщення сервісу у
віртуальний контейнер дозволяє мінімізувати час простою навіть у ситуації збою
віртуального контейнера через перевищення ресурсів, оскільки буде потрібно
тільки відновити віртуальний контекст, що в середньому швидше, ніж
перезавантаження всього сервера. Таким чином, навіть у разі розміщення на
сервері тільки одного сервісу, виправдано його приміщення у віртуальний контейнер.
Гарантовані ресурси
Апаратні ресурси, доступні віртуальному контейнеру, повинні
бути гарантовано більше деякого мінімального значення. У ряді випадків
необхідно надати клієнтам сервісу деякі гарантії якості обслужіваніяш (QoS,
quality of service). Прикладом такої ситуації може служити телефонна розмова:
після з'єднання клієнт отримує гарантію, що під час розмови не закінчаться
ресурси каналу зв'язку і розмова не перерветься. Інший приклад, вже з області
системного адміністрування: дуже бажано гарантувати, що навіть при
максимальному навантаженні на сервері (у тому числі в ситуації DoS-атак), у
сервісу SSH буде достатньо ресурсів, щоб забезпечити віддалений вхід на сервер
системного адміністратора, який міг би вжити термінових заходів. Щоб забезпечити
якість обслуговування для сервісу, адміністраторові необхідно гарантувати
достатній обсяг апаратних ресурсів для цього сервісу, тобто виключити ситуації
збою сервісу через фізичний брак ресурсів у системі. І тут можна
використовувати віртуалізацію сервісів. Якщо сервіс працює у віртуальному
контейнері, то гарантія мінімального рівня ресурсів зводиться до того, що
процеси, що їх поза даного контейнера, в сумі не зажадають більше ресурсів, ніж
різниця між обсягом ресурсів системи і ресурсами даного контейнера. Так, якщо
в системі паралельно виконується кілька сервісів, кожен з яких поміщений в
окремому віртуальному контейнері, то завдання адміністратора - обмежити ресурси
кожного контейнера таким чином, щоб сума виділених їм ресурсів не перевищувала
всіх ресурсів системи, і при цьому виділені кожному сервісу ресурси були
достатні для його нормальної роботи.
У разі, якщо програми не поміщені у віртуальні контейнери,
домогтися гарантованої нижньої межі доступних ресурсів можна тільки в тому
випадку, якщо на одному фізичному сервері виконується тільки один сервіс. В
іншому випадку працює правило "хто перший встав, того і тапки", тобто
будь-який з сервісів може в якийсь момент зайняти великий обсяг вільних
ресурсів, так що залишився не вистачить іншому сервісу для нормальної роботи.
Інакше кажучи, в розділяється середовищі неможливо гарантувати окремому сервісу
нижню межу доступних ресурсів, і, отже, неможливо дати гарантії клієнтам щодо
якості обслуговування.
Ізоляція ergo захищеність
Default deny - найважливіший принцип інформаційної безпеки: всяка
взаємодія, яке не є завідомо необхідною, має бути за замовчуванням заборонена.
Сервіс, що приймає запити від зовнішніх клієнтів, є одним з
класичних джерел для різного роду вразливостей в безпеці системи. Найчастіше несанкціонований
доступ до ОС здійснюється саме через експлуатацію вразливостей деякого сервісу.
Якщо піддався атаці сервіс поміщений у віртуальний контейнер, наслідки злому
можуть бути значно менш руйнівними, ніж у випадку, коли сервіс виконується
безпосередньо в операційній системі сервера. В останньому випадку ОС сервера
може бути зламана через один з сервісів, а під удар підставляються все
виконуються сервіси.
У разі віртуалізованого сервісу, зломщик може отримати доступ
тільки в рамках віртуального контейнера, так що навіть якщо на сервері
паралельно виконуються інші сервіси (в інших віртуальних контейнерах), то їх
роботі даний інцидент загрожувати не буде. Спроби зломщика вичерпати всі
фізичні ресурси призведуть тільки до вичерпання ресурсів даного контейнера.
Таким чином, зломщик не зможе утруднити віддалений доступ адміністратора на
сервер, вичерпавши всі доступні ресурси. Крім того, зсередини контейнера у
зломщика немає можливості перезаписати завантажувач сервера і отримати
який-небудь прямий контроль над обладнанням. При подібному інциденті
адміністратор може просто цілком знищити скомпрометований віртуальний контекст
і відновити його і дані з резервної копії, без перезавантаження сервер і не
зупиняючи роботу інших виконуються на ньому сервісів.
Програмні та апаратні засоби обмеження ресурсів
З попередніх розділів стає зрозуміло, що при використанні
віртуальних контейнерів на сервері працездатність як віртуалізованних сервісів,
так і основної ОС сервера досить істотно залежить від надійності роботи механізмів
обмеження та ізоляції, закладених в технології віртуалізації. Такі механізми
обмеження можуть бути двох родів: апаратні і програмні.
Якщо використовується платформа, що підтримує віртуалізацію
на апаратному рівні, то алгоритми ізоляції контекстів реалізовані безпосередньо
в обладнанні, підвести тут може тільки помилка в мікросхемі. У всіх інших
технологіях віртуалізації механізми обмеження реалізовані так чи інакше
програмно, і, як показує практика, у програмних реалізаціях помилки
зустрічаються. Виробники програмного забезпечення, що виконує ті чи інші
серверні функції (тобто мають деякий сервіс), можуть вбудовувати в свої
продукти власні засоби контролю ресурсів, що мають приблизно ту ж
функціональність, що і обмеження засобами віртуального контейнера. Однак як у
будь програмної реалізації в цих механізмах можливі помилки, що дають
можливість за певних умов обходити встановлені обмеження.
Однак, імовірність помилок у механізмах обмеження тим вище,
чим більше різних механізмів використано в системі. Тому в разі розміщення на
сервері декількох віртуальних контейнерів з сервісами правильніше
використовувати один загальний механізм контролю, що надається засобом
віртуалізації. Крім того, якщо використовується стандартне для дистрибутива
засіб віртуалізації (OpenVZ у разі ALT Linux), то можливі помилки, критичні для
безпеки, будуть швидше виявлені і виправлені.
Захист інтерфейсу управління
При організації сервера з використанням віртуалізованних
сервісів критично важливою точкою для безпеки системи стає інтерфейс управління
самими віртуальними контейнерами. Доступ до цього інтерфейсу повинен бути
найбільш докладно захищений.
Можливі варіанти захисту доступу до інтерфейсу управління:
) заборонити віддалений доступ по мережі, дозволити
тільки доступ з локальної консолі (віртуальна консоль, послідовний порт);
) фізично ізолювати мережеве підключення для
інтерфейсу управління (окремий мережевий адаптер);
) логічно ізолювати мережеве підключення для
інтерфейсу управління (окремий VLAN-інтерфейс);
) використовувати захищені мережеві з'єднання для
віддаленого доступу до інтерфейсу управління (захищений тунель ipsec, openvpn,
pptp або ssh-тунелі).
Консолідація серверів
Консолідація сервісів на одному сервері веде до економії на
витратах на обслуговування обладнання. Вище вже говорилося про те, що сучасне
обладнання дозволяє одночасно виконувати значно більше одного сервісу на одному
сервері. При використанні деяких технологій віртуалізації обчислювальних
ресурсів сьогодні вистачає на організацію безлічі віртуальних контекстів на
сервері, навіть з урахуванням додаткових обчислювальних витрат на
віртуалізацію. Технології віртуалізації на рівні операційної системи (для
UNIX-систем) дозволяють одночасно експлуатувати сотні віртуальних контекстів на
одному досить потужному сервері.
Типова сфера застосування подібних рішень -
хостинг-провайдери: при використанні віртуальних контекстів кожного клієнта
можна видати незалежне оточення з правами суперкористувача, надавши
адміністрування всередині контексту на його повне розсуд. Вигоди від малої і до
масової консолідації сервісів на одному сервері в першу чергу лежать у сфері
зниження витрат на придбання, розміщення та обслуговування обладнання.
Традиційно подібна консолідація стримувалася міркуваннями безпеки та якості
обслуговування, які також забезпечуються засобами віртуальних контейнерів.
Динамічний перерозподіл ресурсів
Віртуалізація сервісів дає можливість простого і безущербно
впровадження, переміщення і виведення з ладу будь-якого з сервісів без шкоди
загальній інфраструктурі і без простою. Ще одна неочевидна, але важлива вигода,
яка надається приміщенням сервісів у віртуальні контейнери походить від того,
що віртуальні контексти, з одного боку, самодостатні, а з іншого - отчуждаеми
від устаткування. Завдяки цьому, адміністратор має можливість маніпулювати
віртуальними контейнерами як цілісними об'єктами, у тому числі переносити з
одного сервера на інший. Так, для більшості технологій віртуалізації є кошти
для "заморозки" контейнера в поточному стані, з можливістю подальшої розморожування,
в тому числі на іншому сервері, при тому що виконуються всередині контейнера
процеси навіть не помітять сталася зміни. Такі можливості дозволяють навіть в
процесі роботи мігрувати віртуалізовані сервіси, наприклад, за різними вузлам
мережі, гнучко перерозподіляючи обчислювальну навантаження, у тому числі серед
вузлів кластера. Крім того, можна знищити ставший непотрібним віртуальний
контейнер, при цьому не виникне необхідності продавати вивільнившийся сервер:
просто інші контейнери зможуть розділити отриману потужність.
2.2 Мережі та віртуалізація
З впровадженням технологій віртуалізації і появою віртуальних
машин виникла очевидна потреба в комутації трафіку між ними. З цією метою були
розроблені віртуальні комутатори, такі як VMware vSwitch або Cisco Nexus 1000V
- в англомовній літературі їх зазвичай називають Virtual Embedded (або
Ethernet) Bridge (VEB). За своїм функціоналом вони відповідають звичайним
комутаторів Ethernet, тільки виконані програмно на рівні гіпервізора. Трафік
між віртуальними машинами в рамках "свого" сервера комутується
локально, не виходячи за його межі (див. Рис. 2.1). А прочий трафік (із
зовнішніми МАС-адресами) - направляється у зовнішню мережу.
Рис. 2.1 Комутація трафіку віртуальних машин всередині
сервера (VEB) і винесення цього процесу в зовнішній комутатор (VEPA).
Віртуальні комутатори можуть бути модульними, як, наприклад,
вже згаданий Cisco Nexus 1000V. Він складається з двох основних компонентів:
модуль Virtual Ethernet Module (VEM) функціонує на базі гіпервізора і
відповідає за комутацію трафіку віртуальних машин, а модуль управління Virtual
Supervisor Module (VSM) може бути встановлений на зовнішньому сервері. Один
комутатор Nexus 1000V здатний підтримувати безліч модулів VEM на фізичних
серверах. А для управління всім цим господарством (вирішення завдань
конфігурування, моніторингу, діагностики та ін) досить одного модуля VSM. По
суті, все як у звичайному модульному пристрої: VEM - це аналог лінійної карти,
а VSM - плати управління.
У віртуальних комутаторів VEB є свої переваги: локальна
комутація трафіку всередині сервера не приводить до будь-якої додаткової
навантаженні на мережу, до того ж для реалізації такої комутації не потрібно
зовнішнє обладнання. Дане рішення відрізняється невисокою вартістю і забезпечує
мале значення затримки. Але у нього є і серйозні мінуси: до віртуальних
комутаторів далеко не завжди застосовні традиційні прийоми конфігурування та
управління, а курсує через них трафік неможливо відстежити звичайними засобами
моніторингу. Такі комутатори часто перебувають у віданні фахівців, що
відповідають за сервери, тоді як за всі інші (апаратні) комутатори відповідають
мережеві адміністратори, що створює проблеми для цілісного управління всією
мережею. Крім того, підтримка роботи віртуальних комутаторів означає додаткове
завантаження процесорів сервера.
Інший підхід до комутації трафіку віртуальних машин
складається у винесенні цього процесу в зовнішні комутатори. Для його
реалізації були розроблені кілька технологій, дві основні описані в документах
IEEE 802.1Qbg (Edge Virtual Bridging) і 802.1BR (Bridge Port Extension), які на
даний момент знаходяться у фінальній стадії затвердження. Розробка першої із
зазначених технологій, в основу якої покладено механізм Virtual Ethernet Port
Aggregator (VEPA), була ініційована компанією HP. Технологія 802.1BR народилася
в Cisco Systems. Спочатку її стандартизацією займалася група 802.1Qbh, але
потім було вирішено виділити цю технологію в окремий стандарт 802.1BR, щоб
дистанціювати її від стандартів серії 802.1Q, "відповідальних" за
тегування трафіку Ethernet.
Як приклад реалізації технології VN-Tag розглянемо так звані
віртуальні інтерфейсні карти (Virtual Interface Card, VIC) компанії Cisco.
Рис. 2.2. Приклад реалізації технології VN-Tag з
використанням віртуальних інтерфейсних карт (Virtual Interface Card, VIC)
компанії Cisco.
Насправді, це цілком реальний мережевий адаптер з портами 10
GbE і підтримкою технології FCoE, але спеціально підготовлений до роботи в
віртуалізованих середовищах. На його базі можуть бути сформовані до 256
віртуальних інтерфейсів vNIC, які, відповідно до концепції виносів, стають
логічним продовженням зовнішнього комутатора Ethernet. У результаті кожної
віртуальній машині виділяється віртуальний порт на фізичному комутаторі (див.
Рис. 2.2), який бере на себе турботу не лише про комутації трафіку, а й про
дотримання встановлених правил безпеки, якості обслуговування і пр.
Підтримка продуктами VIC технології VMware VMDirectPath
дозволяє істотно підвищити продуктивність і знизити затримку мережевої
взаємодії віртуальних машин. Вона робить можливим пряму взаємодію між
віртуальними інтерфейсами vNIC і віртуальними машинами в обхід гіпервізора (див.
Рис. 2.3).
Рис. 2.3 Різні режими взаємодії між віртуальними інтерфейсами
vNIC і віртуальними машинами при використанні віртуальних інтерфейсних карт
(Virtual Interface Card, VIC) компанії Cisco.
При необхідності можна використовувати механізм VMware
VMotion, наприклад, для динамічного розподілу навантаження.
Мережеві адаптери нового покоління, оптимізовані для роботи в
віртуалізованих середовищах, можуть не тільки направляти трафік віртуальних
машин у зовнішню мережу, але й самостійно його комутувати. Прикладом такого
продукту служить адаптер Brocade Fabric Adapter (FA) 1860, який містить один
або два фізичних порти: 10 Гбіт / с (Ethernet, FCoE) або 16 Гбіт / с (Fibre
Channel). При використанні цього адаптера можливі три варіанти комутації
трафіку віртуальних машин (див. Рис. 2.4).
Рис. 2.4 Різні варіанти комутації трафіку віртуальних машин
при використанні адаптера Brocade Fabric Adapter (FA) 1860.
Перші два - це вже розглянуті нами локальна комутація силами
віртуального комутатора (адаптер FA 1860 в даному випадку взагалі не
задіюється) і винесення комутації в зовнішню мережу із застосуванням технології
VEPA. Третій варіант в Brocade називають апаратним віртуальним комутатором (Hardware
Based VEB).
При використанні цього варіанта весь трафік від віртуальних
машин направляється на локальний мережевий адаптер для комутації: якщо трафік
призначено віртуальної машини, що перебуває на тому ж сервері, він прямує назад
гіпервізорами, якщо ні - йде в мережу. Даний варіант комутації використовує
стандартний формат кадру Ethernet. До переваг технології Hardware Based VEB
фахівці Brocade відносять низьку завантаження процесора сервера, а також
можливість (правда, лише часткову) для настроювання політик безпеки і
використання механізму якості обслуговування (QoS), до недоліків - обмеження з
управління трафіком.
Другий і третій варіанти у вирішенні Brocade засновані на
використанні технології віртуалізації PCI-пристроїв Single-Root I / O Virtualization
(SR-IOV), розробленої групою фахівців PCI Special Interest Group. Ця технологія
вводить поняття "віртуальної функції" - Virtual Function (VF) і
дозволяє розділяти мережевий пристрій PCI на кілька віртуальних екземплярів,
які працюватимуть безпосередньо з віртуальними машинами
Например, при использовании метода разделения ресурсов SR-IOV
в рамках одного физического адаптера FA 1860 может быть создано 255 виртуальных
экземпляров. К сожалению, как отмечают специалисты Brocade, технология SR-IOV
имеет свои ограничения: в текущей спецификации предусматривается только
передача входящего/ исходящего трафика виртуальных машин, а локальная
коммутация осуществляется программным коммутатором гипервизора. Кроме того,
виртуальный экземпляр адаптера VF не может вести себя как полноценный
физический PCI-адаптер и поэтому требуется дополнительная инсталляция драйверов
для гипервизора операционной системы VMware ESX и Microsoft HyperV, а также для
BIOS серверов. Такая поддержка только планируется производителями этих операционных
систем, что затрудняет применение методов Hardware Based VEB и VEPA.
Багато експертів вважають найбільш перспективними технології
на зразок VEPA, коли мережеве взаємодія між віртуальними машинами виводиться у
фізичну мережу. Однак ряд причин, в тому числі вже згадана затримка з виходом
необхідних для механізму SR-IOV драйверів для популярних гіпервізорів,
ускладнюють реалізацію цих технологій. Власне, з точки зору розробників
середовищ віртуалізації цілком логічно виглядає відсутність у них великого
ентузіазму щодо створення інструментів, які дозволять вивести з-під їх контролю
такий важливий процес, як взаємодія віртуальних машин.
У цьому зв'язку показовою є позиція Cisco. Просуваючи
технологію 802.1BR з метою забезпечити "проникнення" мережі вглиб
сервера, вона не менш активно розвиває і свій віртуальний комутатор Nexus
1000V, який виконує локальну комутацію трафіку віртуальних машин всередині
сервера. Правда, при цьому функції управління цим процесом - модуль Virtual
Supervisor Module (VSM) - виносяться назовні.
2.3
Віртуалізація у навчанні
.3.1
Сфери використання
Не для кого не є секретом, що для повноцінного навчання
потрібно кожний пройдений матеріал закріплювати практичними навичками. І процес
навчання професії системного інженера чи програміста не є виключенням.
Завдяки віртуалізації мережевого обладнання студенти
технічних факульетеів ВУЗів отримують практичне знання у плануванні
комп'ютерних мереж, віртуалізація допомогає отримувати нові додаткові градації
поза межами навчального заладу, такі як CCNA.
Дякуючи віртуалізації студенти мають змогу працювати у
віртуальних лабораторіях кафедри, отримуючи практику роботи з реальним
серверним ПЗ, працюють з UNIX-подібними системами, тощо.
У багатьох випадках для таких цілей використовують вже згаданий
вище GNS3 (на віртуальному хості з встановленною Ubuntu/Debian/Linux Mint
тощо), а самі віртуальні хости розміщуються на сервері VMware vSphere ESXi 5.1,
або для кожного студента організовується його персональний логін і пароль на
сервері терміналів. Для використання ж віртаульних хостів на персональних
комп'ютерах як правило встановлюються гіпервізори другого рівня, такі як
VirtualBox, Qemu, KVM, VMware Player.
2.3.2
Вибір платформи для навчання
Мережеві маршрутизатори працюють під управлінням операційних
систем. У ряді випадків ці операційні системи можна запустити всередині
віртуальних машин. Мережеві пристрої в мережі з'єднані каналами зв'язку, а для
організації віртуальної мережевої лабораторії треба з'єднати між собою
віртуальні машини, в яких запущені операційні системи мережевих пристроїв.
Під час проведення лабораторного практикуму група студентів
отримує індивідуальне завдання, у якому кожен розробляє власну топологію
мережі. Одночасно працюють десятки віртуальних машин. Виникає завдання такого
вибору операційної системи мережевого пристрою і віртуальної машини, щоб
забезпечити студентам комфортну одночасну роботу за умови обмеженості ресурсів
хост-комп'ютера.
Ідея віртуальних мережевих лабораторій не нова, і для їх
реалізації існують спеціалізовані рішення. Для моделювання пристроїв фірми
Cisco, що працюють під управлінням операційної системи IOS, використовуються
програми Cisco Packet Tracer і Boson NetSim, мають зручний графічний інтерфейс,
що дозволяє швидко створювати досить складні мережеві топології. Однак
вбудована в них урізана версія IOS дозволяє вивчати лише мережеві технології
початкового рівня.
Більший інтерес представляє використання операційних систем
реальних мережевих пристроїв. Виникають наступні питання, що стосуються вибору операційної
системи пристрою і віртуальної машини для запуску цієї операційної системи:
скільки ресурсів хост-машини споживає віртуальна
машина;
який час запуску операційної системи всередині
віртуальної машини;
які засоби надають віртуальні машини для з'єднання
між собою запущених всередині них операційних систем і як швидко можна створити
складну мережеву топологію з десятків пристроїв.
Далі мова піде про контейнер віртуальних машин GNS3, що
широко використовується для моделювання мережевих топологій. Для створення
мережевих топологій в GNS3 використовується технологія Drug-and-Drop: зачепив
пристрій мишею і перетягнув його на робоче поле. GNS3 підтримує три віртуальні
машини: Dynamips, VirtualBox і Qemu. Вибір саме цих машин для включення до GNS3
зумовлений наявністю в їх складі розвинутих засобів для з'єднання між собою
операційних систем (в VirtualBox - за допомогою API).
Віртуальна машина Dynamips дозволяє запустити всередині себе
реальну IOS для дуже широкого класу пристроїв Cisco. Однак при роботі з
Dynamips слід підбирати параметри для зменшення навантаження на центральний
процесор. Без належних налаштувань Dynamips використовує всі ресурси комп'ютера
вже для топології з трьох маршрутизаторів.
Під Qemu працює вельми широкий клас мережевих, вбудованих і
мобільних операційних систем: Juniper JunOS, Vyatta, Openwrt, Google Android,
Mikrotik RouterOs, фаєрволи Cisco IDS, та ін Наш вибір був зроблений на користь
Qemu у складі GNN3. Під Qemu працює вельми широкий клас мережевих, вбудованих і
мобільних операційних систем (ОС): Juniper JunOS, Vyatta, Openwrt, Google
Android, Mikrotik RouterOs, фаєрволи Cisco, та ін VirtualBox також підтримує
безліч ОС, але в складі GNN3 вимагає настройки окремої віртуальної машини для
кожного пристрою мережевої топології. Qemu для всіх пристроїв з однаковою ОС
використовує єдині налаштування.
З перелічених вище особливостей кожного гіпервізору вибір
вочевидь падає на зв’язку Qemu та GNS3. Також слід відмітити віртуальну машину
IOU для Cisco IOS. У ній можна запустити пару операційних систем Cisco IOS з
вельми потужною функціональністю, і вона не вимагає такого налаштування, як
Dynamips. На жаль, IOU не володіє графічним інтерфейсом.
Слід визначитися, в чому працювати: в Windows або в Linux.
GNS3 і Qemu задумані, зроблені і розвиваються в Linux. Qemu під Linux підтримує
апаратну віртуалізацію KVM. Qemu під Windows не підтримує KVM і при запуску
декількох екземплярів Qemu використовується тільки одне ядро центрального процесора, що
істотно уповільнює роботу з великими мережевими топологіями. Виникає питання
вибору дистрибутива Linux. GNS3 написаний на Python і вимагає бібліотеки Qt4.
Після ряду експериментів з різними дистрибутивами Linux з установки GNS3 з
вихідних кодів вибір припав на настільну версію Ubuntu.
Визначимо операційну систему мережевого пристрою для запуску
під Qemu. Якщо зажадати, щоб пристрій підтримувало мережеву технологію MPLS, то
вибір відразу скоротиться: це або операційна система JunOS фірми Juniper, або
RouterOS фірми Mikrotik.
За обсягом споживаних ресурсів JunOS істотно перевершує
RouterOS. Наприклад, на комп'ютері з двоядерним процесором Intel Core2 6600 з
частотою 2.4 ГГц час завантаження RouterOS версії 5.20 в Qemu під Ubuntu
становить кілька секунд (див. нижче), а JunOS версії Olive12.1R1.9 вантажиться
75 секyнд. RouterOS вимагає мінімум 64 Мб пам'яті, JunOS - 512 Мб. Образ диска
RouterOS - 60 Мб, JunOS - 600 Мб.
У Linux є програмне рішення KVM (Kernel-based Virtual
Machine), що підтримує апаратну віртуалізацію на базі процесорів Intel VT або
AMD SVM. Сам по собі KVM не виконує емуляції і використовується спільно з
віртуальними машинами. Отже, доцільно буде використовувати KVM без оптимізатора
пам'яті ksmd.
Число одночасно працюючих екземплярів RouterOs під Qemu
визначається вільною пам'яттю хост-машини Ubuntu. Кожен екземпляр RouterOS з
пам'яттю 64 Мб, запущений в Qemu з KVM, вимагає у Ubuntu 32 Мб пам'яті, а кожен
екземпляр RouterOS з пам'яттю 128 Мб запущений в Qemu з KVM, вимагає у Ubuntu
54 Мб пам'яті.
Операційну систему Ubuntu можна запускати також під
управлінням віртуальної машини, наприклад HYPER-V фірми Microsoft. Qemu в
Ubuntu під управлінням HYPER-V працює дещо повільніше, ніж Qemu в Ubuntu на
реальному комп'ютері. Це обумовлено, крім іншого, і тим, що KVM не працює на
віртуальній апаратурі HYPER-V.
Багатоядерність процесорів распараллелівать завантаження
декількох екземплярів RouterOs. Так час завантаження одного примірників
RouterOS на побутовому 2-х ядерному комп'ютері без підтримки KVM приблизно в
два рази більше, ніж на віртуальному 4-х ядерному процесорі HYPER-V. Тобто
реальні ядра побутового комп'ютера мають приблизно однакову потужність в
порівнянні з ядром віртуального процесора HYPER-V.під віртуальною машиною Qemu
у складі GNS3 під управлінням Ubuntu виявилася кращим вибором для організації
віртуальної лабораторії.
Операційна система RouterOs підтримує практично всі сучасні
мережеві технології. Це дозволило розробити лабораторний практикум для вивчення
наступних мережевих технологій: Ethernet-мости, DHCP, балансування
навантаження, EoIP, NAT, маршрутизація RIP, OSPF і BGP, перерозподіл маршрутів,
PPP, PPTP, SSTP, L2TP, OpenVPN, віртуальні приватні мережі 2-го і 3-го рівня,
IPSec, MPLS, VPLS, VRF.
Закупка, установка на налаштування реального обладнання, що
дозволило б на практиці вивчати усе перелічені вище технології, потребує
виділення великої суми коштів, що не є доцільним для використання у
лабораторному практикумі чи то університету, чи на базі курсів з підготовки
системних інженерів.
.4 Віртуалізація як засіб підвищення відмовостійкості
передбачає широкий спектр служб і програм для підвищення
відмовостійкості. Є як служби, що працюють автономно, так і служби, керовані
адміністраторами. У даному розділі детальніше зупинимося на п'яти з них:
2.4.1
VMware High Availability (HA)
VMware High Availability (HA) - функція високої доступності.
Можливості VMware HA дозволяють підвищити відмовостійкість віртуальної
інфраструктури і зробити безперервним бізнес компанії. Суть можливостей VMware
HA полягає в перезапуску віртуальної машини відмовившого сервера VMware ESX з
загального сховища (власне, сам VMware HA), а також рестарт віртуальної машини
на сервері при втраті сигналу від VMware Tools (VM Monitoring).
Рис. 2.5 Принцип VMware HA
Дана функція, безсумнівно, підвищує відмовостійкість, однак
для неї існує ряд обмежень, а саме:
) Хостів в кластері VMware HA - максимально 32 хоста;
) Віртуальних машин на хост з числом хостів VMware ESX 8 і
менше - максимально 100;
) Віртуальних машин на хост з числом хостів VMware ESX 8 і
менше для vSphere 4.0 Update 1 - максимально 160;
) Віртуальних машин на хост з числом хостів VMware ESX 9 і
більше - максимально 40;
Для великих компаній такі числа можуть бути недостатніми, так
що ця функція корисна для малого та середнього бізнесу, однак, варто помітити,
що компанія VMware оголосила про свої наміри в найближчому майбутньому ці
показники підвищити. Зараз у кластері HA може бути тільки 5 primary хостів ESX,
чого явно недостатньо для створення катастрофостійкі рішення на рівні possible
failure domain. Крім того, на даний момент немає прозорого механізму
призначення хостів як primary або secondary, що теж викликає іноді проблеми. У
цьому плані компанія VMware вже докладає зусиль, щоб зробити такі кластери
VMware HA, які будуть переживати необмежене число відмов хостів VMware ESX.
Іншими словами High Availability - засіб відмовостійкості віртуальних машин, що
дозволяє в разі відмови фізичного хост-сервера автоматично перезапустити його
віртуальні машини з загального сховища
.4.2
VM Monitoring
VM Monitoring, як вже говорилося вище, - служба миттєвої
перезавантаження віртуальної машини при втрати тактових імпульсів від утиліти
VMTools, встановленої на цю ВМ. VM Monitoring досить довго були в статусі
experimental, але сьогодні вони вже доступні для промислового використання.
Однак VMware поки не поспішає їх ставити за замовчуванням -
не дивно, адже користувачі не раз стикалися з ситуацією, коли VM Monitoring на
ранніх етапах свого розвитку давав збій і даремно перезавантажував віртуальні
машини. Тут завдання VMware полягає в технічному удосконаленні можливостей VM
Monitoring, а також поступове завоювання довіри користувачів.
2.4.3 VMware Fault Tolerance (FT)
VMware Fault Tolerance (FT) - засіб безперервної доступності
віртуальних машин, що дозволяє підтримувати резервну працюючу копію віртуальної
машини на іншому сервері, яка миттєво перемикає на себе навантаження в разі
відмови основної машини. Вона дозволяє захистити віртуальні машини за допомогою
кластерів безперервної доступності, що дозволяють у разі відмови хоста з
основною віртуальною машиною миттєво перемкнутися на її "тіньову"
працюючу копію на іншому сервері ESX. Іншими словами, дана функція створює таку
ж ВМ, але призначену параметром Backup VM, яка миттєво стає Primary VM після
припинення прийому пакета тактових імпульсів, відсилає пакетом VMTools
віртуальної машини, сервером.
Рис. 2.6 VMware FT
Тіньові ВМ повинні знаходитися на різних машинах ESX з
основною ВМ:
Рис. 2.7 VMware FT
У такої технології є як свої позитивні сторони, так і
негативні. Дана технологія дозволяє максимізувати відмовостійкість окремих ВМ,
що, звичайно ж, обрадує замовника. Але уявіть, якщо створити кожній ВМ таку
тіньову машину. Тіньова ВМ це така ж ВМ з такими ж характеристиками, що й
основна, тільки готова в будь-який момент часу встати на її місце. При
збільшенні в два рази ВМ, також збільшаться і споживані ресурси При включенні
даної технології будуть накладені істотні обмеження на відносини ВМ і хостів,
систему зберігання і мережеві параметри даної ВМ. У ВМ як Primary, так і
Secondary є кілька обмежень:
) Не повинні мати знімків віртуальних машин (снапшотов);
) Не можуть перебувати на хостах в режимах maintenance mode
або standby mode;
) Не можуть мати пристроїв VMDirectPath I / O;
Експерти виділяють кілька правил, за яких технологія FT буде
застосовуватися з найбільшим коефіцієнтом корисної дії:
) Не заводьте більше 4-8 FT-машин на одному хості ESX
(з урахуванням primary і secondary);
) Помістіть ISO-образи, які використовують FT-машини
на загальне сховище, щоб primary і secondary ВМ могли мати доступ до цих даних;
) Вимкніть power management в BIOS хостів ESX / ESXi.
Якщо вони увійдуть до power-saving mode, то може не вистачити ресурсів CPU на
Secondary VM на виконання завдань синхронно з первинної ВМ;
) Рівномірно розподіляйте саме Primary VMs - так як
саме вони генерують трафік;
На саму ВМ з включеним FT також будуть накладені обмеження.
Основні з них:
) Не працює Hot-plug для віртуальних пристроїв, CPU і
RAM;
) Не можна використовувати Storage VMotion;
) Не можуть бути використані VMDirectPath I / O для
networking I / O devices;
) Не можуть бути використані віртуальні USB пристрої;
) Не можуть бути використані Virtual floppy,
примонтировать до фізичних пристроїв;
) Не можна використовувати снапшоти;FT рекомендований
до використання до наступних ВМ:
) ВМ з додатком з вимогою постійної доступності;
) ВМ з високим коефіцієнтом використання;
) Пріоритетно важливі ВМ;
Слід зазначити, що дана служба (FT) недоступна користувачам,
що купили пакет Essentials і Essentials Plus.
.4.4
Distributed Resource Scheduler (DRS)
Distributed Resource Scheduler (DRS) - технологія, що
вирівнює навантаження серверів ESX. Дана функція необхідна, якщо в системі
утворюється сервер з максимальними навантаженнями на ньому. DRS перекидає
ресурси на більш низько використовувані сервери, таким чином, усереднюючи
коефіцієнт використання всіх серверів. У наступній версії VSphere Client'а 5.0
буде доступна також технологія DRS for Storage.
Рис. 2.8 Принцип дії VMware Distributed Resource Scheduler
Дана функція може бути інтегрована в систему разом з функцією
FT, що дозволить домогтися більш високої відмовостійкості, проте всі обмеження
для FT будуть підсумовуватися з обмеженнями для DRS. Число машин на хості
повинно бути не більше 4-х з метою оптимального швидкодії. Якщо ви спробуєте
мігрувати п'яту віртуальну машину з включеною технологією FT на хост, ви
отримаєте ось таке повідомлення: "Host already has the recommended number
of 4 Fault Tolerance VMs running on it". Дане перенесення здійснюється
службою VMotion. Дана служба (DRS) також недоступна користувачам, що купили
пакет Essentials і Essentials Plus.
.4.5
VMware Site Recovery Manager (SRM)
VMware Site Recovery Manager (SRM) - продукт автоматизує
процеси аварійного відновлення, створення та тестування планів відновлення
після катастроф. Даний продукт пропонує передові можливості управління аварійним
відновленням, тестування без переривання роботи та автоматизованого аварійного
перемикання.vCenter Site Recovery Manager підтримує управління аварійним
перемиканням на резервні інфраструктури, а також між двома інфраструктурами з
активними робочими навантаженнями.
Більше того, можливе відновлення кількох інфраструктур з
однієї спільної резервної системи. Site Recovery Manager також допомагає
забезпечити планове аварійне перемикання ЦОД, наприклад при їх перенесенні.
Керування аварійним відновленням:
) Створення та адміністрування планів відновлення
безпосередньо з VMware vCenter Server;
) Виявлення і візуалізація віртуальних машин,
захищених реплікацією сховища, за допомогою засобів інтеграції, сертифікованих
постачальниками систем зберігання;
) Розширення планів відновлення за допомогою
користувацьких сценаріїв;
) Моніторинг доступності віддалених середовищ і
повідомлення користувачів про їх можливі відмови;
) Зберігання, перегляд та експорт результатів
тестування, а також запуск аварійного перемикання з VMware vCenter Server;
) Управління доступом до планів відновлення за
допомогою деталізованих елементів управління доступом на основі ролей;
) Підтримка рішень по реплікації на основі iSCSI,
FibreChannel або NFS;
) Відновлення декількох середовищ з однієї спільної
резервної інфраструктури;
) Доступ до новітніх можливостям і технологіям VMware
vSphere;
Тестування без переривання роботи:
) Засоби створення знімків забезпечують тестування
відновлення без втрати реплікованих даних;
) Підключення віртуальних машин до існуючих
ізольованим мереж для тестування;
) Автоматизація тестування плану відновлення;
) Налаштування виконання планів відновлення Уолла
тестування;
) Автоматизація очищення тестових середовищ після
тестування;
Автоматизоване аварійне перемикання:
) Запуск виконання планів відновлення з VMware vCenter
Server одним натисканням кнопки;
) Автоматизація призначення реплікованих сховищ даних
для відновлення за допомогою адаптерів, створених провідними постачальниками
систем зберігання для своїх платформ реплікації;
) Виконання користувача сценаріїв і призупинення
процесів при відновленні.
) Зміна IP-адрес віртуальних машин відповідно до
конфігурації мережі резервної інфраструктури;
) Адміністрування і моніторинг виконання планів
відновлення з VMware vCenter Server.
2.4.6
Переваги переходу на віртуальне середовище
При віртуалізації є кілька серйозних переваг, порівняно з
фізичним аналогом побудови інфраструктури:
) Експлуатаційна гнучкість;
) Збільшення віддачі від існуючих ресурсів;
) Софтверна підтримка;
) Планування;
) Скорочення витрат;
) Відмовостійкість;
Експлуатаційна гнучкість
За допомогою віртуалізації ми доб'ємося оперативного
реагування на зміни ринку завдяки динамічному управлінню ресурсами, прискореної
ініціалізації серверів та поліпшеного розгортання настільних комп'ютерів і
додатків. Збільшення віддачі від існуючих ресурсів.
Можливість об'єднання загальних ресурсів інфраструктури в
пули і відхід від застарілої моделі "один сервер - один додаток" за
допомогою консолідації серверів. Софтверна підтримка. У разі віртуалізації ВМ
використовують ресурси серверів, на яких вони знаходяться. Але сама ідея
віртуалізації в тому, що на ВМ, наприклад не варті ЦПУ від компанії Intel або
AMD, віртуалізація підтримує сервери з різними конфігураціями, а, отже, на ВМ
на даний момент йде більшість ОС і майже весь підтримуваний софт цими ОС. Отже,
на одних і тих же за характеристиками серверах, можливо, розгортати абсолютно
незалежні один від одного, і різні за характеристиками ВМ, також і навпаки,
сервери з різними характеристиками будуть підтримувати один кластер, в якому
будуть знаходитися декілька ВМ.
Планування
За допомогою зручного клієнта управління всією структурою
VSphere адміністратор зможе повністю відстежувати процеси, що відбуваються з
серверами, а також при впровадженні подальшого устаткування, це допоможе
набагато спростити і зробити більш прозорою всю структуру віртуальних систем.
Скорочення витрат. Віртуалізація дозволяє зменшувати кількість фізичних
серверів у порівнянні з числом зростаючих віртуальних машин, що дозволить
скоротити витрати на обладнання, енергоспоживання, а також персонал, який буде
все це обслуговувати.
Відмовостійкість
При впровадженні віртуалізації, завдяки технологіям VMware, а
саме: HA FT DRS і т.д., можливо не тільки зберегти свій рівень відмовостійкості
до консолідування ВМ, але і підвищити його. Нижче описані технології
забезпечення надійності віртуальної системи, а також шляхи їх впровадження. На
ранніх етапах консолідування віртуальних технологій, буде збережений той же рівень
надійності, але в подальшим за досить великої інфраструктурі серверного
обладнання, дана інфраструктура, заснована на фізичному рішенні, буде поступово
втрачати надійність з збільшенням обладнання, в той час як віртуальна буде його
завжди утримувати на певному рівні.
Отже, ми розглянули 5 параметрів, що підвищують
відмовостійкість системи до максимуму. Такі параметри, як HA, FT і DRS є
можливостями платформи, наявність яких залежатиме від комплектації купленого
пакету VMware. VM Monitoring присутній у всіх версіях платформ, а SRM є окремим
повноцінним продуктом компанії VMWare, який поставляється також з VCenter
Server.
3. Практична
частина
.1 Планування складу мережі
У практичній частині дипломної роботи за допомогою засобів
віртуалізації був розроблений макет мережі для середнього офісу, який би
задовольняв наступним вимогам:
) Використовувати ВПЗ там, де це можливо
) Досягти максимально можливої відмовостійкості (для
обраної конфігурації ПЗ та технічних характеристик)
) Мінімалізувати матеріально-технічні витрати на
побудову мережі
) Забезпечити єдину конфігурацію усіх користувацьких
робочих місць та можливість повноцінної роботи у мережі підприємства для
віддалених співробітників.
Варто зазначити, що будівля офісу підприємства нараховує 32
постійних робочих місця, обладнаних ПК. Також нараховується близько 10
співробітників по території України, котрим потрібен доступ до мережі
підприємства з дому.
.1.1 Вибір платформи віртуалізації
На роль гіпервізора нульового рівня, що буде забезпечувати
роботу мережі, були висунуті два кандидати:
) VMware vSphere ESXi 5.1
) Proxmox VE 3.0vSphere ESXi 5.1 - останній реліз
флагманської платформи віртуалізації від VMware. Це яскравий представник
гіпервізорів першого типу, так званий "bare-metal".
Як гіпервізор першого рівня, vSphere встановлюється
безпосередньо на сервер, і поділяє його ресурси між окремими віртуальними
машинами, котрі завдяки цьому можуть працювати одночасно. На відміну від усіх
інших гіпервізорів, управління vSphere можно повністю здійснювати віддалено за
допомогою спеціально розроблених клієнтських програм. Завдяки відсутності
будь-якої основної операційної системи установка гіпервізору займає на диску
близько 150 мегабайт, і може бути виконана на з’ємний USB-диск. vSphere -
найбільш розвинений у плані фунціоналу гіпервізор на ринку, і володіє
наступними особливостями:
) Мінімальна інсталяція для зменшення ймовірності
виходу зі строю та якомога довшої роботи без патчів
) Незалежність від операційної системи та драйвери,
прив’язані до апаратної частини серверу
) Розширене керування пам’яттю з можливістю
де-дублікації та стискання
) Розширена система управління дисковим простором з
інтегрованою кластерною файловою системою
) Висока масштабованість операцій вводу-виводу для
усунення "вузьких місць" цих самих операцій
З огляду на вимогу до коштів, витрачених на побудову мережі,
слід привести витримку з ліцензійного договору на vSphere:
"Ліцензія на безкоштовний vSphere Hypervisor дозволяє
вам мати необмежену кількість процесорів на сервері, при цьому загальний обсяг
сконфігурованої оперативної пам'яті віртуальних машин (VRAM) не може
перевищувати 32 ГБ на одному сервері.", що, звісно, є великим плюсом на
рахунок vSphere, адже 32 ГБ оперативної пам’яті на сервері під нужди невеликого
офісу буде більше, ніж достатньо.VE 3.0 - це система віртуалізації з відкритим
вихідним кодом, заснована на Debian GNU / Linux. Розробляється австрійською
фірмою Proxmox Server Solutions GmbH, що спонсорується Internet Foundation
Austria.
В якості гіпервізорів використовує KVM і OpenVZ. Відповідно,
здатна виконувати будь-які підтримувані KVM ОС (Linux, * BSD, Windows та інші)
з мінімальними втратами продуктивності і Linux без втрат. Управління
віртуальними машинами і адміністрування самого сервера виконується через
веб-інтерфейс або через стандартний інтерфейс терміналу Linux.
Для створюваних віртуальних машин доступно безліч опцій:
використовуваний гіпервізор, тип сховища (файл образу або LVM), тип емульованої
дискової підсистеми (IDE, SCSI або VirtIO), тип емульованого мережевого
адаптеру, кількість доступних процесорів та інші. Ключові можливості:
1) Просте управління через веб-інтерфейс;
2) Моніторинг навантаження в реальному часі;
) Бібліотека настановних образів (у
локальному/віддаленому сховищі);
) Підключення до "фізичної" консолі
гостьових систем безпосередньо з браузера (по VNC);
) Об'єднання серверів в кластер з можливістю живої
міграції віртуальних машин (без зупинки гостьової системи);
) Швидке розгортання гостьових систем з шаблонів
(доступно лише для OpenVZ);
) Автоматичне резервне копіювання віртуальних машин.
Має наступні, критичні для нас, недоліки:
) Оснований на дистрибутиві Debian 7,
пакети котрого часто на версію, а то й більше, відстають від останньої
стабільної.
) Не має функції автоматичного відкату
віртуальної машини до початкого стану (non-persistant disk або
snapshot-rollback).
) Більш підходить для розгортання пулу
серверних віртуальних машин.
З огляду на це, можемо зробити висновок, що для
наших нужд більш підходить продукт компанії VMware, а саме VMware vSphere ESXi
5.1.
3.1.2 Вибір платформи на роль контролеру домену та серверу Active
Directory
На роль котролеру домену розглядалось два
кандидати:
) Red Hat Enterprise Linux (RHEL 6)
) Debian 7 Wheezy
Вибір проводився по наступним критеріям:
) Безкоштовність рішення
) Простота реалізації та адміністрування
) Наявність достатньої кількості
документації
) Стабільні версії пакетів та можливість
оновлення
За цими критеріями на роль контролеру домену був
обраний Debian 7 (Wheezy), що нещодавно перейшов до лінійки stable. Він
дозволяє получити безкоштовне своєчасне оновлення пакетів з мімімумом недоліків
програмного коду (розробники Debian дуже прискіпливо стежать за оновленнями
пакетів, що входять до дистрибутиву), а також має достатню кількість
документації з установки.6 - навпаки, не має можливості безкоштовного
оновлення, технічна підтримка також платна. Так як явяється меньше
розповсюдженною, ніж Debian, то і документація представлена в меньшій
кількості.
З огляду на це можна зробити висновок, що за
основну платформу для налаштування контролеру домену є більш доцільним узяти
Debian 7 (Wheezy).
Сам контролер домену буде налаштований на Sabma,
а пакет OpenLDAP повністю впорається з роллю сервера Active Directory (далі -
AD).
.1.3 Вибір варіанту рішення для 1С:Підприємство
З появою мультиплатформенності у рішенні 1С 8.1
з'явилась можливість повноцінного використання серверу для роботи з базою даних, об'єктними
даними, виконанням запитів. Це дозволяє використовувати тонкий клієнт для
роботи клієнтських машин та оптимізований web-клієнт для доступу з планшетів та
мобільних пристроїв. Це дозволить знизити навантаження на клієнтські ПК та
підвищить надійність збереження даних, а також суттєво зберігає кошти, що були
б витрачені на покупку рішення від Microsoft.
Рис. 3.1 Клієнт-серверна схема роботи 1с: Підприємство на
основі Linux
У нашому випадку ми будемо використоувати клієнт-серверний
варіант встановлення 1С: Підприємство. У якості СУБД для сервера 1С:
Підприємство буде використано PostgreSQL
(рекомендовано розробниками 1С)
3.1.4 Вибір рішення для організації доменної пошти,
внутрішньомережевого чату та засобу встановлення ОС через PXE
Базовою системою для налаштування пакетів раніше
було обрано Debian Wheezy. На роль почтового серверу, безсумнівно, обрано
Postfix, як найбільш розвинене рішення з великою кількістю документації.
На роль внутрішньомережевого чату був обраний
кросплатформенний XMPP-сервер Openfire, що має кросплатформенний клієнт Spark.
Використання цієї зв'язки дозволить віддалено підключатися до корпоративного
чату, отримувати новини та завдання, і при цбому не важливо, яким пристроєм ви
для цього користуєтесь.
Встановлення операційної системи через мережу має
дві найвідоміші реалізації:
) WDS служба на базі Microsoft Windows
Server 2008 R2 Enterprise.
) LTSP - безкоштовний сервер терміналів на
базі Linux
Вочевидь, доцільніше використовувати LTSP у
зв'язці з Debian Wheezy, адже LTSP володіє достатньою кількістю документації і
є безкоштовним рішенням.
Також слід зауважити, що для організації
інкреметного резервного копіювання даних використовується набір shell-скриптів,
об'єднаних у пакет backup-manager.
3.1.5 Вибір операційної системи для користувацьких ПК
На роль операційної системи для роботи кінцевого
користувача були розглянуті три варіанти linux-based дистрибутивів:
) Ubunut 12.04 LTS
) Debian 7 (Wheezy)
) CentOS 6 (thin-client package)
При виборі дистрибутиву враховувались наступні
критерії:
) Дружність користувачу
) Достатня кількість документації
) Гарантована підтримка оновлень
дистрибутиву
Так як з виходом 1С для linux дистрибутивів
необхідність встановлення 1С на сервер терминалів (NX NoMachine, FreeNX, тощо),
або використання продукту компанії EterSoft (wine@etersoft) відпала, то
клієнтські машини будуть мати повноцінну установку операційної системи, а отже
CentOS з встановленним мінімальним пакетом тонкого клієнту вже не є
доцільним.Wheezy буде підтримуватись розробниками ще як мінімум 3 роки, він
добре забезпечений документацією, але не дуже зрозумілий рядовому
користувачу.12.04 LTS є ідеальнім рішенням по усім критеріям, знаходиться у
лінійці версій з "довгою підтримкою", має увесь необхідний набір
програм у стандартній установці, завдяки дивізу команди розробників "Make
it simple" є найбільш дружньою до рядового користувача і не потребує
великої кількості доналаштувань після установки, також найбільш документована.
3.2 Розгортання мережі на віртуальному стенді на базі VMware
Workstation
3.2.1 Створення віртуальної машини з VMware vSphere ESXi 5.1
Cтворимо віртуальну машину в середовищі VMware
workstation 8, для установки VMware vSphere ESXi 5.1:
) Створюємо віртуальну машину
Рис. 3.2 Створення віртуальної машини
) Вибираємо пункт "custom" для
більш тонкої настройки. У наступному вікні вибираємо Workstation 8, яка
сумістна з ESXi 5.1
Рис. 3.3 Створення віртуальної машини
3) У наступному вікні вказуємо шлях до iso-образу,
заздалегідь викачаного з сайту вендора:
Рис. 3.4 Створення віртуальної машини
Рис. 3.5 Вказання шляху до iso-файлу
Далі вказуємо ім'я нової машини і шлях до місця майбутнього
розташування її файлів:
Рис. 3.6 Вказання імені ВМ та розташування файлів
4) І в наступному вікні вказуємо кол-во процесорів і
ядер:
Рис. 3.7 Вказання кількості сокетів та ядер
5) Кількість оперативної пам'яті (чим більше - тим
краще):
Рис. 3.8 Задання кількості оперативної памяті
6) Вказуємо за замовчуванням використовувати з'єднання
міст:
Рис. 3.9 Задання типу мережевого інтерфейсу
Тип контролеру - SCSI + LSI Logic:
Рис. 3.10 Задання типу SCSI-контролеру
) Вибираємо створення нового віртуального
диска:
Рис. 3.11 Створення нового віртуального диску
8) Вказуємо обсяг майбутнього datastorage,
куди ми будемо завантажувати образи створюваних віртуальних машин і iso-файли
для їх установки, та багато що інше. Так само вибираємо пункт "зберігати
диск як один файл"
Рис. 3.12 Створення нового віртуального диску
9) Далі бачимо фінальне вікно, що сумує всю
інформацію про характеристики майбутнього сервера. Нам потрібно трохи змінити
налаштування та додати пару мережевих адаптерів, тому натискаємо
"customize hardware":
Рис. 3.13 Вікно підтвердження конфігурації
10) Додамо новий мережевий адаптер "host-only"
для управління сервером і видалимо непотрібний "floppy-drive":
Рис. 3.14 Вікно редагування конфігурації
11) Натискаємо "close" і в попередньому вікні
тепер натискаємо "finish". На цьому, мабуть, все, прийшов час
установки ESXi 5.1.
3.2.2 Встановлення та налаштування гіпервізора VMware vSphere
ESXi 5.1
Меню просте і досить інтуїтивне. Якщо дисків багато, скажімо,
6 або 8, то можна зробити RAID-50 (це дзеркало з двох RAID-5). Працюватиме
істотно швидше, і підвищується надійність - допускається вихід з ладу до двох
дисків, якщо вони в різних групах дзеркала. Вантажимося з ISO образу і
встановлюємо VMWare ESXi. Процес установки досить тривіальний, але довгий. Не
забуваємо ввести адміністративний пароль для користувача root.
Рис. 3.15 Вікно встановленого гіпервізору ESXi 5.1
Перезавантажуємося, дивимося адресу, отриману з DHCP. Для
порядку, звичайно, краще налаштувати постійну IP-адресу, якщо сервер відразу
встановлений на своє постійне місце. Конфігурування VMWare ESXi відбувається
дуже просто (на відміну від Hyper-V від Microsoft). Треба включити всі мережеві
адаптери.
Натискаємо "<F2> Customze Systero / Vieu
Logs". Вводимо пароль. Стрілка вниз, вибираємо "Confiqure Management
network", Enter. Там "Network Adapters", натискаємо Enter.
Рис. 3.16 Вікно конфігурування інтерфесів менеджмент-трафіку
Рис. 3.17 Вікно конфігурування інтерфесів менеджмент-трафіку
За допомогою пробілу ставимо хрестики навпроти всіх доступних
адаптерів, Enter, ESC, Y (підтверджуємо збереження конфігурації), ESC (Log
Out).
.2.3 Первинна настройка VMWare
ESXi
Клієнт vSphere Client вже встановлений раніше. Якщо ні, то
підключаємося по щойно отриманій адресі до свіжовстановленого гіпервізору за допомогою
браузера і викачуємо його по посиланню "Download vSphere Client".
Рис. 3.18 Стартова сторінка ESXi
Встановлюємо, запускаємо, вводимо все той же адресу, ім'я
користувача root і свій пароль.
Рис. 3.19 Вікно клієнту vSphere
Після першого підключення до встановленого VMWare ESXi
вводимо ліцензійний ключ, без якого система буде працювати тільки 60 днів. Цей
ключ був поруч з посиланням на скачування iso-образу VMware-VMvisor-Installer.
Для введення ключа в консолі vSphere Client переходимо на закладку
Configuration, зліва в групі Software пункт Licensed Featuresсправа клацаємо на
ссилку Edit.
Рис. 3.20 Розділ уведення ліцензіонного ключа.
Там натискаємо кнопку "Enter Key" і копіюємо ключ з
буфера. Безкоштовний ключ дає можливість використовувати на VMWare ESXi тільки
32 Гб оперативної пам'яті і до 8 віртуальних процесорів (це, наприклад, два
чотириядерних процесора), що цілком достатньо для багатьох випадків.
Перевіряємо поточний час гіпервізора. У групі Software пунктTime Configuration
справа вгорі ссилка "Properties ...", задаємо час з точністю до
хвилин. ОК. Знову відкриваємо це вікно і внизу кнопка "Options ...".
Переводимо перемикач в положення "Start and stop with host". У цьому
вікні зліва вибираємо розділ "NTP Settings", кнопка "Add
..", вводимо адресу свого контролера, ОК, натискаємо кнопку
"Start", ОК, включаємо галочкою "NTP Client Enabled",
тиснемо ОК.
Створюємо сховище даних. На цій же закладці Configuration,
зліва в групі Hardware пункт Storage, поки сховища НЕ сконфігуровані, на цій
сторінці зверху жовтий транспарант: "The ESXi host does not have
persistent storage." І трохи нижче посилання на створення сховища даних:
"click hereto create a datastore ... ".
Рис. 3.21 Меню створення сховища даних
Клацаємо по ній. Т.я. для віртуальних машин планується
використовувати локальні диски, залишаємо перемикач в положенні "Disk /
LUN"; кнопка Next. Вибираємо у списку довгу назву масиву, Next. Версію
файлової системи залишаємо VMFS-5, тому що немає причин працювати зі старою
версією, Next. Тут майстер попереджає, що все доступне йому дисковий простір
буде знищено і переконфігурувати у формат VMWare без можливості подальшого
відкоту і відновлення даних, жмемNext. Вводимо ім'я сховища, наприклад,
"Stor1", Next. Задаємо розмір для нього. Можна створити кілька сховищ
для різних цілей. У даному випадку це не потрібно, тиснемо Next, потім Finish.
Сховище готово. Конфігуріруем мережеві інтерфейси. На закладці Configuration,
зліва в групі Hardware пункт Networking. Тут фізичні мережеві адаптери
зіставлені з віртуальними свіча. У нас зараз 2 адаптера: vmnic0 і vmnic1. Якщо
не потрібно мати роздільні мережі як, наприклад, для мережевого екрану типу ISA
сервера на цьому віртуальному сервері, то можна об'єднати всі адаптери в групу
для резервування каналу. Над переліком адаптерів у рядку "Standard Switch:
vSwitch0" натискаємо посилання "Properties ...". Виділяємо свіч
"vSwitch", кнопкаEdit, закладка NIC Teaming. По черзі виділяючи
адаптери в списку, переміщаємо їх у групу "Active Adapters" кнопкою
Move Up. Для установки віртуального мережевого екрану, скажімо, ISA 2006, має
сенс розділити адаптери по різних мереж. Тоді для автоматично створеного свіча
vSwitch один з адаптерів vmnic0 залишаємо в групі "Active Adapters",
а інший vmnic1 в групі "Unused Adapters". Закриваємо вікно
властивостей свіча, виділяємо під ним "VM Network", кнопка Edit,
змінюємо на "VM Network 0", щоб нумерація відповідала імені фізичної
адаптера. КнопкаClose. Трохи вище попередньої посилання, в рядку
"Networking" натискаємо посилання "Add Networking ...",
Next, залишаємо перемикач в положенні "Create a vSphere standard
switch", бачимо автоматично сгенерированное ім'я "VM Network",
змінюємо його на "VM Network 1", щоб нумерація відповідала імені
фізичної адаптера, тиснемо Finish.
Відкриваємо властивості новоствореного "vSwitch1",
закладка "Network Adapters", Add, оптічіваем "vmnic1",
кнопка Next. На питання про те, що цей адаптер вже приєднаний до іншого свічу і
його доведеться перенести від нього, відповідаємо "Так". Кнопка Next,
кнопка Finish, кнопка Close. Тепер, якщо ми хочемо, щоб віртуальний адаптер
віртуальної машини був підключений до фізичного адаптера "vmnic0", то
у властивостях цього віртуального адаптера потрібно буде вказувати "VM
Network 0". Для підключення до "vmnic1" - "VM Network
1".
На цьому можна вважати нашу віртуальну платформу готовою для
створення на ній віртуальних машин.
.3 Встановлення Debian Wheezy для налаштування контролеру
домену
) Для початку натискаємо правою кнопкою миші по назві
серверу (у даному випадку - це IP-адреса), і з контекстного меню обираємо пункт
"New virtual machine…"
Рис. 3.22 Створення нової ВМ
) У наступному вікні обираємо пункт "Custom…"
та натискаемо "Next…"
Рис. 3.23 Обрання методу створення
) У наступному вікні уводимо ім’я для нової ВМ:
Рис. 3.24 Уведення назви нової ВМ
) Далі обираємо сховище даних, на котре буде проходити
встановлення. У нашому випадку воно одне:
Рис. 3.25 Вибір місця розташування
5) Далі обираємо "Virtual Machine Version: 8",
а на наступному екрані обираємо потрібний дистрибутив з випадаючого списку:
Рис. 3.26 Вибір архітектури
Задаємо кількість сокетів та ядер на одному сокеті:
Рис. 3.27 Задання кількості процесорів та ядер
) Обираємо кількість доступної vRAM:
Рис. 3.28 Задання кількості vRAM
7) Обираємо бажану кількість мережевих адаптерів:
Рис. 3.29 Задання кількості мережевих адаптерів
) Задаємо тип SCSI-контролеру:
Рис. 3.30 Вибір типу SCSI-контролеру (за замовчуванням)
) Створюємо новий віртуальний диск:
Рис. 3.31 Створення нового образу диску
) Задаємо розмір образу (для наших цілей достатньо
буде 10 Гб), а також задаємо тип диску. Далі для спрощення установки та
розгортання цю віртуальну машину буде клоновано. Thin Provision краще вибирати
у випадку економії місця на сховищі, у іншому випадку краще буде обрати Thick
Provision. Також є можливість указати свій шлях до розміщення файлів
віртуальної машини, а також образу її жорсткого диску. Ми обираємо за
замовчуванням зберігати образ диску разом з файлами налаштувань у папці
віртуальної машини.
Рис. 3.32 Створення нового образу диску
) Вибір типу роботи системи з диском. Потрібно обрати
канал з диском, а далі потрібно вказати, який режим диска вам потрібен
(persistent або nonpersistent):
Рис. 3.33 Вибір режиму роботи
) Далі виводиться вікно підтвердження конфігурації.
Якщо потрібно, можна поставити галочку на "Edit the virtual machine
settings…", щоб по закінченні потрапити у діалогове вікно, котре дозволяє
вже більш детально розглянути конфігурацію сервера:
Рис. 3.34 Підтвердження конфігурації
) Нажимаємо "Continue". Все, початкове
налаштування віртуальної машини завершене. Можна приступати до встановлення
операційної системи та компонентів серверу.
) У розділі "Configuration" обираємо
"Storage" і "Browse datastore"
Рис. 3.35 Режим перегляду вмісту сховища
) У відкрившомуся вікні створюємо папку ISO, яка буде
зберігати образи установочних дисків систем. Обираємо цю папку, та на верхній
панелі нажимаємо "Upload file to datastore" та обираємо у
відкрившомуся вікні заздалегідь підготовлений образ
debian-7.0.0-amd64-netinst.iso.
Рис. 3.36 Вибір завантажуємого файлу
І отримуємо наступне: у нашій папці тепер лежить файл, з
якого ми можемо встановити віртуальну машину майбутнього серверу.
Рис. 3.37 Поміщення файлу до сховища
) Приєднуємо образ до тільки що створеної
віртуальної машини, запускаємо її, відриваємо консоль до неї. У процесі запуску
натискаємо клавішу Esc та обираємо завантаження з диску:
Рис. 3.38 Вибір варіанту інсталяції Debian
) Далі нам потрібно обрати мінімальний пакет
графічного оточення (мій вибір пав на LXDE) та встановити мінімальний набір
пакетів для роботи:
Рис. 3.39 Вибір варіанту інсталяції LXDE
) Обираємо російський варіант інсталяційного меню:
Рис. 3.40 Вибір російського варіанту меню
) Далі обираємо варіант розкладки клавіатури та методу
їх переключення.
) Для правильного відображення часу у системі
необхідно обрати локацію згідно місця проживання:
Рис. 3.41 Вибір Українського часового поясу
) Уводимо netbios name. Так як ця віртуальна машина
виконуватиме функцію контролеру домену, назвемо її PDC:
Рис. 3.42 Задання імені комп’ютера
) Потрібно увести FQDN (повне ім’я домену), у моному
випадку це:
Рис. 3.43 Задання імені домену
) Потрібно увести пароль користувача root:
Рис. 3.44 Уведення паролю root’a
) Далі буде запропоновано створити нового користувача,
задати його ім’я та пароль.
) Прийшов час розмітити віртуальний диск для
встановлення системи. Обираємо режим "вручну":
Рис. 3.45 Варіант способу розбиття диску
) Та розбиваємо диск з розрахунку: 5 Гб - під корінний
розділ / (ext4), 2 Гб - linux-swap, вільний простір - під директорії
користувачів /home (ext4).
Рис. 3.46 Розбивка диску на розділи для установки системи
) Для дзеркала пакетів обираємо Російську Федерацію,
так як дзеркало ftp.ru.debian.org є найшвидшим для нашої території:
Рис. 3.47 Вибір Російської Федерації для обрання дзеркала
завантаження пакетів
) Далі потрібно обрати пакети, що будуть встановлені.
Так як ця інсталяція буде типовою для усіх наступних віртуальних машин, то
оберемо стандартний набір пакетів:
Рис. 3.48 Набір пакетів для серверу
) По завершенню інсталяції пакетів буде запропоновано
встановити системний загружчик GRUB до головного загрузочного запису /dev/sda.
Погоджуємося, размонтуємо диск з установкою, перезагружаємо систему.
Рис. 3.49 Установка GRUB
) Після перезапуску системи потрібно встановити
компілятор С gcc, make та linux-headers-all-3.2.0.4-all-amd64 для встановлення
vmware-tools та компіляції модулів ядра. Після проведених маніпуляцій отримуємо
повністю "готову до бою" систему.
Рис. 3.50 Встановлена система Debian Wheezy AMD64 з LXDE
) Інсталяція серверу завершена. Тепер потрібно
"клонувати" щойно створений сервер для установки на копіях СУБД PostgreSQL,
серверу 1С: Підприємство, почтового серверу Postfix, тощо, та рознести цей
функціонал на три різні віртуальні машини для підвищення відмово стійкості
мережі. Отже, нам потрібні три копії цієї установки.
) У безплатній версії гіпервізору не можна клонувати
віртуальні машини, але це робиться дуже легко наступним чином:
Спочатку вимкнути ВМ, котру збираємося "клонувати"
- Через режим перегляду файлового сховища скопіювати
файл віртуального диску ***.vdmk цієї машини у інше місце.
Створити нову віртуальну машину з потрібними нам
характеристиками
При створенні вказати путь до скопійованого файлу
***.vdmk
Запущена таким чином ВМ буде абсолютно ідентична до
"клонованої".
3.3.1 Встановлення Samba PDC та OpenLDAP
Подальше налаштування будемо проводити з-під аканту root.
1) Перевіримо правильність вмісту файлів
/etc/hostname та /etc/hosts
Рис. 3.51 Вивід команд
2) Домен має назву ace.dp.ua, контролеру домену -
PDC.ace.pd.ua
3) Установимо усі необхідні пакети
sudo aptitude install libpam-ldapd libnss-ldapd samba
smbclient smbfs smbldap-tools slapd mcrypt ldap-utils libgd-tools samba-doc
У процессі встановлення sladp запросить пароль
адміністратора, а конфігурація пакету libnss-ldapd виведе наступне вікно, де
потрібно відмітити усі галочки.
Рис. 3.52 Конфігурація libnss-ldapd
) Налаштування OpenLDAP
Налаштування проводимо у файлі / і т.д. / LDAP / slapd.conf.
Попередньо переміщаємо куди-небудь директорію slap.d:
# service slapd stop
# mv /etc/ldap/slap.d /root/
Потім створюємо файл конфігурації / і т.д. / LDAP /
slapd.conf приблизно ось такого змісту:
# Global Directives:
# Features to permit
#allow
bind_v2/etc/ldap/schema/core.schema/etc/ldap/schema/collective.schema/etc/ldap/schema/corba.schema/etc/ldap/schema/cosine.schema/etc/ldap/schema/duaconf.schema/etc/ldap/schema/dyngroup.schema/etc/ldap/schema/inetorgperson.schema/etc/ldap/schema/java.schema/etc/ldap/schema/misc.schema/etc/ldap/schema/nis.schema/etc/ldap/schema/openldap.schema/etc/ldap/schema/ppolicy.schema/etc/ldap/schema/samba.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change
this./var/run/slapd/slapd.pid
# List of arguments that were passed to the
server/var/run/slapd/slapd.args
# Read slapd.conf(5) for possible valuesnone
# Where the dynamically loaded modules are
stored/usr/lib/ldapback_hdb
# The maximum number of entries that is returned for a search
operation500
# The tool-threads parameter sets the actual amount of cpu's
that is used
# for indexing.threads 1
##################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until
another
# 'backend' directive occurshdb
##################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until
another
# 'backend' directive occurs
#backend <other>
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until
another
# 'database' directive occurshdb
# The base of your directory in database
#1"dc=ldap"
# rootdn directive for specifying a superuser on the
database. This is needed
# for
syncrepl."cn=admin,dc=ldap"{MD5}X03MO1qnZdYdgyfeuILPmQ==
# Where the database file are physically stored for database
#1"/var/lib/ldap"
# The dbconfig settings are used to generate a DB_CONFIG file
the first
# time slapd starts. They do NOT override existing an
existing DB_CONFIG
# file. You should therefore change these settings in
DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take
effect.
# For the Debian package we use 2MB as default but be sure to
update this
# value if you have plenty of RAMset_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value
incredibly high
Рис. 3.53 Початкова установка
На наступному екрані вибираємо редакцію операційної системи,
яку хочемо встановити:
Рис. 3.54 Вибір редакції операційної системи
Погоджуємося з ліцензійною угодою:
Рис. 3.55 Ліцензійна узгода
Далі нам пропонують налаштувати жорсткі диски. Вибираємо
пункт Повна установка (додаткові):
Рис. 3.56 Вибір варіанту установки
Бачимо єдиний диск який у нас встановлений у віртуальній
машині. Вибираємо його, тиснемо ОК.:
Рис. 3.57 Вибір диску для установки
Рис. 3.58 Процес встановлення
Установка завершена, продовжуємо. Змінюємо пароль:
Рис. 3.59 Зміна паролю адмінстратора
Після завантаження потрапляємо на сторінку початкового
налаштування (Завдання початкової настройки). Взагалі Microsoft зробили дуже
зручно тим, що винесли багато налаштування сюди, тоді як у попередніх версіях
ці налаштування доводилося робити під час установки.
Рис. 3.60 Вікно керування сервером
Налаштовуємо мережеві підключення:
Рис. 3.61 Встановлення статичної IP-адреси для налаштування
КД
Міняємо ім'я комп'ютера, перезавантажуємося.
Рис. 3.62 Змінюємо ім’я серверу на DC
Далі нам необхідно зробити сервер контролером домену. Для
цього нам необхідно спочатку встановити роль контролера домену Active
Directory, потім запустити Dcpromo з командного рядка. Відкриваємо Диспетчер
сервера (Server Manager) в лівій панелі вибираємо Ролі, в правій вибираємо
Додати ролі (Add Roles). З'являється вікно, "Before You Begin",
тиснемо далі. У наступному вікні вибираємо роль контролера домену (Active
Directory Domain Service), як тільки ми виберемо відповідну опцію, майстер нам
запропонує встановити необхідні функції, тиснемо Додати необхідні компоненти
"Add Required Features":
Рис. 3.63 Встановлення ролі контролеру AD
На наступному кроці майстра ми бачимо повідомлення про цю
роль сервера. Ось деякі моменти про які нам повідомляють: Необхідно мати два
контролери домену в одній мережі для забезпечення відмовостійкості. Я
проігнорую цей момент, тому що я встановлюю сервер для забезпечення роботи
лабораторного стенду. Для роботи домену обов'язково потрібно DNS, цю роль також
включаемо до, або вона ключена підчас установки ролі контролеру домену. Після
установки ролі потрібно запустити Dcpromo.
Під час установки будуть встановлені служби простору імен DFS
реплікація DFS реплікації іFile, ці служби необхідні для нормального
функціонування домену Windows, тому вони встановлюються автоматично.
Рис. 3.64, 5.65. Установка необхідного додаткового
функціоналу
Все. Установка ролі завершена, тиснемо Close. Отже ми
встановили Windows Server 2008R2 та надали йому роль контролера домену.
.4.2 Налаштування NTP-серверу
Отже, як же активувати SNTP сервер в Windows Sever 2008 R2:
) Відкриємо редактор реєстру regedit
) Знайдемо і розгорнемо наступну гілку реєстру:
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \
W32Time \ Config \
) У правій панелі знаходимо ключ AnnounceFlags, і
змінимо його. Тип цього параметра DWORD, вказуємо його значення рівне 5
) Включаємо сервер NTPServer.
) Знайдемо і розкриємо гілку реєстру:
_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services
\W32Time \ TimeProviders \ NtpServer \
6) У правій панелі знайдемо параметр Enabled, змінимо
його. Як значення даного ключа вкажемо 1.
) Робота з реєстром завершена. Відкриємо cmd
натисканням клавіш Win + R
) Наступна команда перезапустить службу Windows Time з
новими параметрами:
net stop w32time && net start w32time
Все, NTP сервер готовий обслуговувати клієнтів.
.4.3 Уведення VMware vSphere ESXi в домен
Зпочатку треба підключитися до хосту безпосередньо з VSphere
клієнта. Клацаємо на вкладці конфігурації. Потім виберем "Authentication
Services" з меню в лівому нижньому кутку. Потім тиснемо на кнопку
"Властивості". Виберемо "Service Type", потім "Active
Directory". У полі Домен потрібно ввести ім'я домену, до якого ми будемо
підключатися. Слід переконатися, що час в гіпервізора синхронізовано з часом в
контролері домену. Наступний крок -це натиснути кнопку "Реєстрація
домену" і буде представлено вікно аутентифікації.
Рис. 3.66 Вікно аутентифікації гіпервізора в домені
Введемо ім'я користувача домену, що має адміністративні
права. Після успішного введення hostname гіпервізора буде додано до домену. Тепер,
коли хост VMware був доданий в домен, можна додати користувачів або групи на
вкладку Дозволи. Клацнути правою кнопкою миші на пункт "Permissions"
і вибрати "Add permission…".
Рис. 3.67 Вікно управління дозволами
Рис. 3.68 Визначення властивостей правила
Тиснемо кнопку "Add ...", з'являється вікно, в
якому вибираємо домен, а не локальних користувачів, і додаємо дозволу потрібної
групі.
Рис. 3.69 Вікно управління правилами
В результаті отримуємо дозволи користувачів домену як
"readonly", а адміністраторів домену, як "administrators".
Рис. 3.70 Перелік діючих дозволів на доступ
На цьому налаштування закінчене.
.5 Встановлення та налаштування PostgreSQL 9.1
Оптимальним рішенням для установки є установка Postgresql
9.1.2 от 1С postgresql_9_1_2-1.1C_deb_x86_64.
Перелік файлів, котрі необхідно завантажити з офіційного
сайту 1С та встановити:_9.1.2-1.1C_amd64.deb libpgtypes3_9.1.2-1.1C_amd64.deb
libpq5_9.1.2-1.1C_amd64.deb postgresql-9.1_9.1.2-1.1C_amd64.deb
postgresql-client-9.1_9.1.2-1.1C_amd64.deb
postgresql-contrib-9.1_9.1.2-1.1C_amd64.deb
Спочатку треба встановити більш ранню версію пакету
libssl0.9.8
# wget
http://ftp.ru.debian.org/debian/pool/main/o/openssl/libssl0.9.8_0.9.8o-4squeeze13_amd64.deb
# sudo dpkg -i libssl0.9.8_0.9.8o-4squeeze13_amd64.deb
# sudo apt-get install libxslt1.1
Буде потрібно змінити деякі параметри ядра, у файл / etc /
sysctl.conf
додати наступні строки:
.shmmax = 671088640 kernel.shmall = 671088640
Виконати команду:
# sysctl-p
Після установки кожного пакета postgresql необхідно
заборонити оновлення пакету, оскільки в репозиторіях версія postgresql
9.1.7.оздамо невеликий скрипт pgsq-linstall.sh який допоможе встановити
postgresql від 1С:
# nano pgsq-linstall.sh
#!/bin/sh dpkg -i libssl0.9.8_0.9.8o-4squeeze13_amd64.deb
dpkg -i libpq5_9.1.2-1.1C_amd64.deb echo "libpq5 hold" | sudo dpkg
--set-selections dpkg -i libpgtypes3_9.1.2-1.1C_amd64.deb echo
"libpgtypes3 hold" | sudo dpkg --set-selections dpkg -i
libecpg6_9.1.2-1.1C_amd64.deb echo "libecpg6 hold" | sudo dpkg
--set-selections apt-get install postgresql-common libossp-uuid16 dpkg -i
postgresql-client-9.1_9.1.2-1.1C_amd64.deb echo "postgresql-client-9.1
hold" | sudo dpkg --set-selections dpkg -i
postgresql-9.1_9.1.2-1.1C_amd64.deb echo "postgresql-9.1 hold" | sudo
dpkg --set-selections dpkg -i postgresql-contrib-9.1_9.1.2-1.1C_amd64.deb echo
"postgresql-contrib-9.1 hold" | sudo dpkg --set-selections
Перевіримо які пакети від 1С встановлені:
# dpkg --list | grep 1C1c-enterprise82-common 8.2.17-157 i386
1C:Enterprise 8.2 common components ii 1c-enterprise82-server 8.2.17-157 i386
1C:Enterprise 8.2 server for Linux hi libecpg6 9.1.2-1.1C amd64 run-time
library for ECPG programs hi libpgtypes3 9.1.2-1.1C amd64 shared library
libpgtypes for PostgreSQL 9.1 hi libpq5 9.1.2-1.1C amd64 PostgreSQL C client
library hi postgresql-9.1 9.1.2-1.1C amd64 object-relational SQL database,
version 9.1 hi postgresql-client-9.1 9.1.2-1.1C amd64 front-end programs for
PostgreSQL 9.1 hi postgresql-contrib-9.1 9.1.2-1.1C amd64 additional facilities
for PostgreSQL
Сервер 1С підприємство 32bit, а СУБД Postgresql 9.1.2 -
64bit.
Перевіримо список пакетів заблокованих для оновлення:
# dpkg - get-selections | grep holdhold libpgtypes3 hold
libpq5 hold postgresql-9.1 hold postgresql-client-9.1 hold
postgresql-contrib-9.1 hold
Маємо встановлений Postgresql 9.1.2, оптимізований для роботи
з сервером 1С підприємства 8.2, наданий 1С.
.6 Встановлення FreeNX термінального серверу
Як варіант організації доступу до роботи з сервером 1С:
Підприємство був розглянений FreeNS server - сервер терміналів, оснований на
сирцевому коді термінального серверу компанії NoMachine NX. Нижче буде подана
інструкція по його встановленню на Debian.
Створимо скрипт install.sh, який буде містити наступний
текст:
** echo *FreeNX Setup Script* echo ** sudo apt-get install
python-software-properties sudo add-apt-repository ppa:freenx-team sudo apt-get
update sudo apt-get install freenx -y sleep 5 echo ** echo *The End* echo **
Робимо його виконуваним:
# sudo chmod +x install.sh
Скрипт додасть репозиторій sources.list і завантажить і
установить усе необхідне, а саме: мінімальний (зовсім) gnome2 (якщо необхідно)
і сам, власне, freenx-server.
# sudo bash ./install.sh
По закінченню процесу установки міняємо файл node.conf по
шляху / etc / nxserver:
# sudo nano /etc/nxserve/node.conf
Знаходимо строку:
#ENABLE_PASSDB_AUTHENTICATION="0"
Та змінюємо на:
_PASSDB_AUTHENTICATION="1"
Далі потрібно встановити права користувачам на доступ до
NX-сервера по ssh. Для цього потрібно у файлі:
# sudo nano / etc / ssh / sshd_config після рядків:
RSAAuthentication yes PubkeyAuthentication yes # AuthorizedKeysFile%
h/.ssh/authorized_keys2
Додати:
nx your * user * name
Де nx - системний юзверя (на скільки я розумію), без якого
взагалі нічого працювати віддалено не буде, а your * user * name - імена
користувачів, облікові записи яких будуть на сервері, і яким ви хочете дати
доступ до NX-серверу.
Далі створюємо так званий client id dsa - ключ, який буде
використовуватися для перевірки доступу подключаюегося серверу користувача. Для
цього:
/ usr / lib / nx / nxkeygen
Якщо все добре, то вивід буде наступним:
key generated; your users must install / Var / lib / nxserver
/ home / .ssh / client.id_dsa.key on their computers.
Що означає, що потрібно скопіювати сгенеренний ключ на
клієнтські машини з вказаної папки. Далі створюємо файл users.id_dsa в папці /
etc / nxserver, і копіюємо в нього вміст файлик / var / lib / nxserver / home /
.ssh / client.id_dsa.key.
Далі додаємо юзверя в юзер-лист NX-сервера. Користувач,
відповідно, повинен був бути зареєстрований у самій системі sudo nxserver -
adduser chris Якщо вивід команди подібний: NX> 100 NXSERVER - Version
3.2.0-74-SVN OS (GPL, using backend: 3.4.0) egrep: / etc / nxserver /
passwords: No such file or directory cp: cannot stat `/ etc / nxserver /
passwords ': No such file or directory NX> 1000 NXNODE - Version
3.2.0-74-SVN OS (GPL, using backend: 3.4.0) cat: / etc / nxserver /
users.id_dsa.pub: No such file or directory cat: / etc / nxserver /
users.id_dsa.pub: No such file or directory NX> 716 Public key added to: /
home/chris/.ssh/authorized_keys2 NX> 1001 Bye. NX> 999 Bye то все ОК,
якщо ні - шукаємо помилку. Далі встановлюємо користувачеві пароль для входу.
Рекомендую не морочити голову ні собі ні людям і ставити пароль такий же, як
від входу в систему. sudo nxserver - passwd chris Якщо вивід такий: NX>
100 NXSERVER - Version 3.2.0-74-SVN OS (GPL, using backend: 3.4.0) New
password: Password changed. NX> 999 Bye то все ОК, якщо ні - шукаємо
помилку.
Далі видаємо дозволи системного користувачеві на користування
татком і всім її вмістом:
chown nx: root / var / lib / nxserver / db / *
Перезавантажуємо ssh-сервер і freenx-сервер: sudo / etc / init.d / ssh restart
sudo nxserver - restart
З’єднання з сервером проходить за допомогою
кроссплатформеного клієнту NX-Client від NoMachine.
4. Охорона
праці та безпека в надзвичайних ситуаціях
Завдання: "Розробити інструкцію з охорони праці на
робочому місці системного адміністратора ТОВ "Фірма Ейс ЛТД".
4.1 Загальні положення
Інструкція з охорони праці - це нормативний акт, що містить
обов'язкові для дотримання працівниками вимоги з охорони праці при виконанні
ними робіт певного виду або за певною професією на робочих місцях, у виробничих
приміщеннях, на території підприємства або в інших місцях, де за дорученням
роботодавця виконуються ці роботи, трудові чи службові обов'язки;
Інструкції з охорони праці поділяються на:
інструкції, що належать до нормативно-правових актів з
охорони праці;
примірні інструкції;
інструкції, що діють на підприємстві.
Адміністрація підприємства, у відповідності до
наказу Комітету по нагляду з охорони праці України Міністерства праці та
соціальної політики України від 1 №9 від 29.01.98 №9, зареєстрованого в
Міністерстві юстиції України 7 квітня 1998 р. за №226/2666, повинна розробити
план інструкцію з охорони праці на робочому місці працівника. Організація
вивчення інструкцій працівниками забезпечується роботодавцем згідно з ДНАОП
0.00-4.12-94 "Типове положення про навчання, інструктаж і перевірку знань
працівників з питань охорони праці" метою розробки інструкції з охорони
праці працівника на робочому місці є планування дій працівника на робочому
місці з моменту початку робочого часу до моменту завершення робіт, та
передбачення ситуацій недбалої поведінки працівника на робочому місці з метою
запобігання утворення НC на підприємстві, а також доведення до відомості
працівника положень про техніку безпеки на робочому місці.
Під час експлуатації ЕОМ на працівників можуть діяти такі
небезпечні і шкідливі виробничі фактори:
Фізичні:
. Електромагнітне випромінювання, при наближенні до
екрану чи задньої частини відеотерміналу ближче 0,6-0,7 м.;
. М’яке рентгенівське випромінювання, при наближенні
до ВДТ ближче 0,05 м.;
. Ультрафіолетове й інфрачервоне випромінювання;
. Електростатичне поле між екраном і працівником;
. Можлива наявність шуму та вібрації при роботі
принтерів застарілої модифікації;
. Нерівномірність розподілу яскравості в полі зору;
. Підвищена яскравість світлового зображення;
. Ураження електричним струмом при порушенні вимог
електробезпеки.
Психофізіологічні:
. Напруження зору;
. Напруження уваги;
. Інтелектуальні навантаження;
. Емоційні навантаження;
. Тривалі статичні навантаження;
. Монотонність праці;
. Необхідність обробки великого обсягу інформації в
одиницю часу;
. Нераціональна організація робочого місця.
4.2 Вимоги безпеки перед початком роботи
1. Привести в порядок робоче місце
впевнитися: що на ньому відсутні сторонні предмети
всі пристрої і блоки ПК під'єднані до системного блоку.
. Перевірити:
наявність та надійність захисного заземлення устаткування
справність вимикачів та інших органів управління ПК
справність роз'ємів кабелів електроживлення;
відсутність пошкоджень ізоляції проводів живлення;
відсутність відкритих струмопровідних частин у пристроях ПК.
. Відрегулювати сидіння робочого стільця (крісла);
кут нахилу спинки стільця в межах 90-220° до площини сидіння;
кут зору на екрані монітора - складав 25°
відстань до екрана - 600-800 мм;
. Вжити заходів, щоб пряме світло не потрапляло на екрани
пристроїв.
. Протерти трохи зволоженою серветкою клавіатуру (для
зниження рівня статичної електрики), зовнішню поверхню екрана монітора.
. Освітленість у приміщеннях з ПК - регулювати сонцезахисними
пристроями.
. Перед вмиканням штепсельної вилки - упевнитися в тому, що
вимикачі мережі на всіх пристроях ПК знаходяться в положенні
"вимкнено"
. При виявленні несправностей ПК не вмикати і негайно
повідомити керівника.
4.3 Вимоги безпеки під час роботи
. Виконувати тільки ту роботу, яка входить в обов’язки
працівника.
. Вмикати і вимикати ПЕОМ тільки вимикачами, забороняється
проводити вимкнення вийманням вилки з розетки.
. Забороняється оператору знімати захисні кожухи з обладнання
і працювати без них. Не допускати до ПЕОМ сторонніх осіб, які не беруть участі
у роботі.
. Забороняється переміщати і переносити блоки, обладнання,
які знаходяться під напругою.
. Забороняється поправляти і заправляти фарбуючу стрічку на
принтері під час роботи.
. Не палити на робочому місці.
. Суворо виконувати загальні вимоги по електробезпеці та
пожежній безпеці.
. Категорично забороняється самостійно розбирати та проводити
ремонт електронної та електронно-механічної частини ПЕОМ. Ці роботи можуть
виконувати лише фахівці з технічного обслуговування ПЕОМ.
. ПЕОМ необхідно використовувати у суворій відповідності з
експлуатаційною документацією на неї.
. Під час виконання роботи слід бути уважним, не звертати
уваги на сторонні речі.
. Про всі виявлені несправності та збої в роботі апаратури
необхідно повідомити безпосереднього керівника.
З метою зниження зорового і кістково-м'язового стомлення
програмісту слід дотримувати встановлений режим праці та відпочинку. Режими
праці та відпочинку при роботі з персональним комп'ютером повинні
організовуватися в залежності від виду та категорії трудової діяльності. При
виконанні протягом робочої зміни робіт, що відносяться до різних видів трудової
діяльності, за основну роботу з персональним комп'ютером слід приймати таку,
яка займає не менше 50% часу протягом робочої зміни або робочого дня.
Для видів трудової діяльності встановлені 3 категорії
тяжкості і напруженості роботи з персональним комп'ютером, які визначаються: -
Для групи А - по сумарному числу прочитуються знаків за робочу зміну, але не
більше 60000 знаків за зміну;
Для групи Б - по сумарному числу зчитуються або вводяться
знаків за робочу зміну, але не більше 40000 знаків за зміну;
Для групи В - по сумарному часу безпосередньої роботи з
персональним комп'ютером за робочу зміну, але не більше 6 годин за зміну.
Тривалість безперервної роботи з відеомонітором без
регламентованого перерви не повинна перевищувати 2 годин. Для забезпечення
оптимальної працездатності і збереження здоров'я програміста протягом робочої
зміни повинні бути встановлені регламентовані перерви. Час регламентованих
перерв протягом робочої зміни слід встановлювати в залежності від її
тривалості, виду і категорії трудової діяльності.
При роботі з персональним комп'ютером в нічну зміну (з 22 до
6 годин), незалежно від категорії і виду трудової діяльності, тривалість
регламентованих перерв повинна бути збільшена на 60 хвилин.
При 8 годинній робочій зміні і роботі на персональному
комп'ютері регламентовані перерви слід встановлювати:
Для I категорії робіт через 2 години від початку робочої
зміни і через 2 години після обідньої перерви тривалістю 15 хвилин кожен;
Для II категорії робіт через 2 години від початку робочої
зміни і через 1,5-2,0 години після обідньої перерви тривалістю 15 хвилин кожен
або тривалістю 10 хвилин через кожну годину роботи;
Для III категорії робіт через 1,5-2,0 години від початку
робочої зміни і через 1,5-2,0 години після обідньої перерви тривалістю 20
хвилин кожен або тривалістю 15 хвилин через кожну годину роботи. При 12
годинний робочій зміні регламентовані перерви повинні встановлюватися в перші 8
годин роботи аналогічно перервам при 8 годинний робочій зміні, а протягом
останніх 4 годин роботи, незалежно від категорії і виду робіт, кожну годину
тривалістю 15 хвилин. Програмісту, що працює з високим рівнем напруженості під
час регламентованих перерв і в кінці робочого дня, рекомендується психологічне
розвантаження у спеціально обладнаних приміщеннях (кімната психологічного
розвантаження).
Неприпустимо:
·
обслуговування,
ремонт і налагодження ЕОМ безпосередньо на робочому місці користувача ЕОМ;
·
збереження
біля відеотерміналів і ЕОМ папера, дискет, інших носіїв інформації, запасних
блоків, деталей і т.п., якщо вони не використовуються для поточної роботи;
·
відключення
захисних пристроїв, самовільна зміна конструкції і складу ЕОМ, устаткування, а
також їхнє технічне налагодження;
·
робота з
відеотерміналами, у яких при роботі виникають нехарактерні сигнали, нестабільне
зображення на екрані і т.п.;
·
робота на
матричному принтері зі знятою верхньою кришкою.
·
працювати
без належного освітлення;
·
вживати
їжу та напої, працюючи на комп'ютерному обладнанні;
·
працювати
з монітором, у якого під час роботи з'являються нехарактерні сигнали,
нестабільне зображення на екрані тощо;
·
залишати
без нагляду включене обладнання;
·
працювати
на комп'ютерному обладнанні без дозволу майстра виробничого навчання.
З метою профілактики негативного впливу на здоров'я
виробничих факторів необхідно дотримуватись режимів праці та відпочинку: після
кожної години роботи за комп'ютерним обладнанням необхідно робити перерву для
відпочинку, указану у регламенті відповідно до категорії виконуваної праці.
Під час регламентованих перерв з метою зниження
нервово-емоційного напруження, втоми очей, кистей рук, усунення негативного
впливу рекомендується виконувати спеціальні вправи та самомасаж кистей рук та
очей.
.4 Вимоги безпеки після закінчення роботи
. Відключити ПЕОМ від електромережі, для чого
необхідно вимкнути тумблери, а потім витягнути штепсельну вилку із розетки.
. Якщо зала, в якій знаходиться ЕОМ, обладнана
додатковими вимикачами, то потрібно спочатку знеструмити ЕОМ, далі потрібно перевести
вимикачі у положення "вимкнено".
. Якщо зала обладнана кондиціонуючим обладнанням,
системою очистки повітря (вентиляцією), додатковим периферійним обладнанням,
котре не використовується після закінчення робочої зміни, то його також
потрібно вимкнути.
. Протерти зовнішню поверхню ПЕОМ чистою вологою
тканиною. При цьому не допускається використання розчинників, одеколону,
очищуючих препаратів в аерозольній упаковці.
. Прибрати робоче місце. Скласти робочі документи,
диски у відповідні місця зберігання.
. При виявленні недоліків у роботі обладнання, або
будь-якого відхилення стану робочого місця від норми слід відразу повідомити
про це керівника підрозділу, до якого відноситься працівник, або
відповідального за безпеку на підприємстві.
. Протягом робочого часу та по завершенню роботи
повідомляти не посереднього керівника про виявлені недоліки: збої в роботі
операційної системи та периферійного обладнання; наявність та справність
захисної ізоляції - шнурів та роз'ємів, захисних пристроїв, що забезпечують
роботу оператора комп'ютерного набору.
8. Порядок здавання робочого місця:
·
Закінчити
роботу та зберегти потрібну інформацію. Вийти з усіх працюючих програм і
вимкнути комп'ютер.
·
Вимкнути
принтер (якщо він увімкнений), вимкнути монітор і системний блок.
·
Вимкнути
стабілізатор, якщо комп'ютер підключений до мережі через нього. Штепсельні
вилки витягнути з розеток.
4.5 Вимоги безпеки в аварійних ситуаціях
Згідно наказу Міністерства праці та соціальної політики
України N 112 від 17.06.99 Про затвердження Положення щодо розробки планів
локалізації та ліквідації аварійних ситуацій і аварій (ПЛАС) на підприємстві
повинні бути документи на інструкції, що передбачають дії робітників у разі
виникнення аварійної ситуації. П’ятий розділ інструкції з охорони праці на
робочому місці системного адміністратора (програміста) повинен включати вимоги
безпеки в аварійних ситуаціях.
Заходи працівника з безпеки праці в аварійних ситуаціях:
1. При появі незвичного звуку, запаху паленого,
самовільного вимкнення машини негайно припиніть роботу і повідомте про це
безпосереднього керівника.
. ПЕОМ необхідно використовувати у суворій
відповідності з експлуатаційною документацією на неї.
. Під час виконання роботи слід бути уважним, не
звертати уваги на сторонні речі.
. Про всі виявлені несправності та збої в роботі
апаратури необхідно повідомити безпосереднього керівника.
. При виявленні будь-яких неполадок в роботі
персонального комп'ютера програміст повинен припинити роботу, вимкнути
комп'ютер і повідомити про це безпосереднього керівника для організації
ремонту.
. Програмісту не слід самому усувати технічні
неполадки персонального комп'ютера.
. Програміст не повинен виробляти роботу при знятому
корпусі комп'ютера.
. При нещасному випадку, отруєнні, раптовому
захворюванні необхідно негайно надати першу допомогу потерпілому, викликати
лікаря або допомогти доставити потерпілого до лікаря, а потім повідомити
керівника про те, що трапилося.
Кожен працівник повинен знати основні правила поведінки під
час аварії, вміти діяти в обставинах, що склалися. Кожен має знати, як
викликати пожежну команду та швидку допомогу, а також план евакуації з
небезпечної території та евакуаційні шляхи і виходи. Діяти рішуче, спокійно і
виважено, не панікувати.
Відомості про ознаки аварійних ситуацій, характерні причини
аварій
Найпоширенішими наслідками аварії є пожежі. Пожежа може
виникнути від розрядів статичної електрики, необережного поводження при
використанні відкритого вогню, короткого замикання електропроводів, що
використовуються як в середині обладнання, так і при під'єднанні його до
джерела живлення. Короткі замикання виникають в результаті порушення ізоляції в
електричних проводах. Небезпека полягає в тому, що струм при короткому
замиканні досягає десятків і сотень ампер. При цьому виділяється велика
кількість тепла і відбувається загоряння ізоляції, плавиться метал з викиданням
в навколишнє середовище іскор, які спроможні викликати пожежу, що в свою чергу
супроводжується із виділенням токсичних продуктів горіння. Найбільш небезпечним
є продукт повного згоряння (оксид вуглецю), концентрація якого в розмірі 0,5%
викликає отруєння через 20 хв., а при концентрації 1,3% раптове отруєння людини
внаслідок 2-3 вдихів. Вуглекислий газ є менш небезпечним, тому реальна
небезпека для життя настає тільки при значних концентраціях (8-10%).
Відомості про порядок застосування засобів проти аварійного
захисту та сигналізації
Для гасіння пожежі використовують первинні засоби
пожежегасіння, що є на підприємстві. В приміщенні, де використовуються ЕОМ,
згідно норм пожежної безпеки має бути три вуглекислотних вогнегасники.
Приведення вогнегасників до дії необхідно здійснювати
безпосередньо у разі виникнення пожежі. Правила користування вогнегасником
вказані на його корпусі. Гасіння необхідно починати з відстані, що дорівнює
максимальній довжині струменя, направляючи його в основу полум'я. Після
закінчення гасіння за наявності вогнегасної речовини продовжити її подавання з
метою охолодження нагрітих поверхонь.
Порядок дій щодо подання першої медичної допомоги потерпілим
під час аварії
1. Вивести потерпілого з оточення, де стався нещасний
випадок.
2. Надати потерпілому найбільш зручне положення, що
забезпечує спокій.
. Визначити вид травми (перелом, поранення, опік
тощо).
. Визначити загальний стан потерпілого, встановити, чи
не порушені функції життєво важливих органів.
. Розпочати проведення необхідних заходів:
·
зупинити
кровотечу;
·
зафіксувати
місце перелому
·
надати
реанімаційних заходів (оживлення), штучне дихання, зовнішній масаж серця;
·
обробити
ушкоджені частини тіла.
6. Одночасно з наданням долікарської допомоги викликати
швидку допомогу.
Ураження електричним струмом
Ознаки: загальні - втрата свідомості, судорожне скорочення
м'язів (потерпілого або відкидає в бік, або він не може розтиснути руку, що
захопила провід), зупинка дихання та серцевої діяльності (клінічна смерть);
місцеві - термічні опіки III-IV ступеня, "знаки струму "біля місць
входу (місце дотику до джерела струму) і виходу (місце зіткнення із землею) у
вигляді жовтувато-бурих ділянок або деревовидних червоних смуг на шкірі.
Перша допомога: ізоляція потерпілого від дії електричного
струму; необхідно попередити або убезпечити можливе падіння потерпілого при
відключенні установки; надання долікарської допомоги; підтримку життєдіяльності
організму потерпілого до приїзду швидкої медичної допомоги. Ізоляція
потерпілого від дії електричного струму досягається такими способами: -
Вимиканням рубильника, вимикачів, а також шляхом зняття або викручування
запобіжників (пробок), роз'єму штепсельного з'єднання. Якщо потерпілий
знаходиться на висоті, то необхідно вжити заходів, що попереджають падіння
потерпілого або забезпечують його безпеку;
Для відриву потерпілого від землі або від струмоведучих
частин слід користуватися сухим канатом, сухою палицею, дошкою чи будь-яким
сухим предметом, що не проводить електричний струм. Можна також відтягнути його
за одяг (якщо він сухий і відстає від тіла), уникаючи при цьому дотику до
оточуючих металевих предметів і частин тіла потерпілого, не прикритого одягом.
Відтягучи потерпілого за ноги, надаючий допомогу не повинен торкатися його
взуття або одягу без хорошої ізоляції своїх рук, тому що взуття та одяг можуть
бути сирими і бути провідниками електричного струму.
Для ізоляції той, хто надає допомогу, особливо якщо йому
необхідно торкнутися тіла потерпілого, не прикритого одягом, повинен одягнути
діелектричні рукавички або обмотати руку шарфом, надягти на неї суконний
кашкет, натягнути на руку рукав піджака або пальто, накинути на постраждалого
гумовий килимок, прогумовану матерію або просто суху матерію. Можна також
ізолювати себе, ставши на гумовий килимок, суху дошку або яку-небудь, що не
проводить електричний струм, підстилку і т.п. При відділенні потерпілого від
струмопровідних частин рекомендується діяти однією рукою, тримаючи другу в
кишені або за спиною. Можна також перерубати дроти сокирою з сухою дерев'яною
рукояткою або перекусити їх інструментом з ізольованими рукоятками (кусачками,
пасатижами тощо). Перерубувати або перекушувати проводи необхідно пофазно,
тобто кожен провід окремо, при цьому рекомендується по можливості стояти на
сухих дерев'яних дошках, діелектричних предметах. Заходи першої допомоги
залежать від того стану, в якому знаходиться постраждалий після звільнення його
від струму.
Опіки та теплові удари
При наданні першої допомоги при опіках, теплових ударах слід
швидко припинити дію високої температури. Це має особливо велике значення при
займанні одягу і при опіках рідиною через одяг. У першому випадку необхідно
загасити полум¢я, негайно накинути на людину, що горить, будь-яку цупку
тканину, щільно притиснути її до тіла. Знімають тліючий одяг або обливають його
водою.
При промоканні одягу гарячою водою, його також необхідно
облити холодною водою або зірвати. Швидке занурення обпеченого лиця у холодну
воду зменшує біль і тяжкість опіку.
Місце опіків кислотами ретельно промивають струменем води
протягом 10-15 хв. Обпечене місце промити 5%-ним розчином перманганату калію,
або 10%- ним розчином питної соди (одна чайна ложка на склянку води). На місце
опіку накладають бинт. Місце опіків їдкими лугами (каустичною содою, негашеним
вапном) промивають проточною водою протягом 10-15 хв., потім слабким розчином
оцтової кислоти. Місце опіку накривають марлею.
Опіки бувають трьох ступенів. При опіках першого ступеня з¢являються почервоніння,
припухлість шкіри. Уражені місця обробляють спиртом, прикладають примочки з
розчину перманганату калію і забинтовують. При більш тяжких опіках (2 і 3
ступенів) обпечені місця спочатку звільняють від одягу, накривають стерильним
матеріалом, зверху накладають шар вати і забинтовують. Після перев¢язування потерпілого
відправляють у лікувальний заклад. При опіках не слід розрізати пухирів,
видаляти смолистих речовин, що прилипли до обпеченого місця, віддирати шматків
одягу, які прилипли до рани.
При опіках очей електричною дугою роблять холодні примочки з
розчину борної кислоти, потім потерпілого направляють у медичний заклад. При
появі різних ознак теплового або сонячного удару потерпілого негайно виводять
на свіже повітря або в тінь, потім його кладуть, розстібають одяг, що стискує,
на голову і на серце кладуть холодні компреси, дають пити у великій кількості
холодну воду, у тяжких випадках потерпілого обливають холодною водою. При
припиненні дихання або при його утрудненні до прибуття лікаря потерпілому
роблять штучне дихання.
Висновки
В процессі виконання дипломної роботи мною були розглянуті та
вивчені на практиці сучасні технології віртуалізації та їх роль та користь у
проектуванні комп’ютерних мереж, адмініструванні, навчанні та підвищенні
професійного рівня спеціалістів. Завдяки отриманим навичкам та знанням мною був
розроблений макет мережі для середнього офісу, реалізація якого у реальному
житті не потягне за собою жодних витрат на програмне забезпечення завдяки
використанню вільного програмного забезпечення, а використання віртуалізації
покликане суттєво знизити витрати на покупку обладнання.
Ціль, поставлена передо мною у дипломній роботі, була
повністю досягнена, а я в процесі виконання розглянув тонкощі технологій
віртуалізації, о існуванні яких раніше й не здогадувався.
Дипломна робота має велику цінність і актуальність, адже
віртуалізація - один з найважливіших напрямків розвитку сучасних мережевих
технологій, а рішення, розглянуті у дипломній роботі, є найсвіжішими розробками
у даній області. Завдяки ж стилю виконання практичної частини, дана дипломна
робота може бути використана, як методичний матеріал на практичних заняттях з
віртуалізації, або інструкція для проектування, налаштування та адміністрування
комп’ютерної мережі офісу підприємства.
Сам же макет мережі буде викоритсаний на базі підприємства
ООО "Фірма Ейс ЛДТ", де дипломник займає пост штатного системного
адміністратора.
Список використаної літератури
віртуалізація комп’ютерний мережа операційний
1. http://ru.wikipedia.org/wiki/Виртуализация
2. https://ru.wikipedia.org/wiki/Аппаратная_виртуализация
. http://www.sitronics.ua/solutions/it-infrastructure/sxod/virt.php
. http://citforum.ru/operating_systems/virtualization/index.shtml
. http://www.ixbt.com/cm/virtualization-h.shtml
. http://www.ixbt.com/cm/virtualization.shtml
. http://www.pcmag.ru/solutions/detail.php?ID=34643
. http://ru.wikipedia.org/wiki/VMware_ThinApp
. http://blog.vadmin.ru/2013/01/software-defined-datacenter.html
. http://www.osp.ru/lan/2013/02/13034060/
. http://www.vsphere5.ru/doku.php?id=using-vmware:disaster-recovery-infrastructure
. http://forum.proxmox.com/threads/13898-Proxmox-VE-3-0-released!
. Михеев
М. - "Администрирование VMware vSphere 5" (2012, ДМК Пресс)
. Михеев
М. - "Администрирование VMware vSphere 4.1" (2011, ДМК Пресс)
. Azad
T.Securing Citrix XenApp Server in the Enterprise.Syngress 2008
. VMware
ESX Server.Syngress. 2008
. Запечников
С. Основы построения виртуальных частных сетей. Телеком 2004
18. http://zakon4.rada.gov.ua/laws/show/z0424-99
19. http://zakon4.rada.gov.ua/laws/show/z0226-98
. ДержСанПіН 3.3.2.007 1998 "Правила охорони праці
при експлуатації ЕОМ"
. Основи охорони праці. За редакцією К.Н. Ткачука і М.О.
Халімовського
22. Безопасность жизнедеятельности. / Под ред. Н.А. Белова -
М.: Знание, 2000
23. Зинченко В.П. Основы эргономики. - М.: МГУ, 1979