Розробка макету комп’ютерної мережі з використанням засобів віртуалізації

 

Реферат

Дипломна робота містить 146 сторінок машинописного тексту, 83 рисунки, 1 таблицю та 23 літературних джерела.

Обєкт дослідження: технології віртуалізації у проектуванні компютерних мереж.

Мета роботи: розробка макету компютерної мережі з використанням засобів віртуалізації.

Методи роботи: у процесі виконання дипломної роботи були розглянуті методи проектування мереж, що використовують не посередньо, або містять у собі засоби віртуалізації чи то програмної, чи то апаратної. Також був обраний кращий гіпервізор з погляду "безкоштовна ліцензія-кількість можливостей-якість реалізації". Була детально розглянута продукція VMware та розглянуті кандидатури на заміну їх флагмана ESXi 5.1.

Результати роботи: готовий макет компютерної мережі, основаної на технологіях віртуалізації та вільного програмного забезпечення.

Ключові слова: системи віртуалізації, адміністрування, проектування, відмовостійкість, віртуальна машина, гіпервізор, VMware, Debian, Linux.

Abstract

graduate thesis includes 146 pages of typed text, 83 images, 1 table and 23 literary sources.subject of this research is "Virtualisation technologies in computer network design".methods: methods examined during the execution of this graduate project either directly use or contain software or hardware virtualisation tools. In addition, the best hypervisor was chosen based on "free license - functionality - quality of implementation" considerations. VMware products and possible alternatives for their flagship product EXSi 5.1 were examined in detail.results: a complete computer network layout based on virtualisation technologies and free software.: virtualisation systems, administration, design, reliability, virtual machine, hypervisor, VMware, Debian, Linux.

Зміст

Вступ

Літературний огляд

. Види та технології віртуалізації

.1 Види віртуалізації

.1.1 Віртуалізація платформ

.1.2 Віртуалізація ресурсів

.1.3 Де застосовується віртуалізація

.2 Технології віртуалізації

.2.1 Програмна віртуалізація

.2.2 Апаратна віртуалізація

.2.3 Віртуалізація на рівні операційної системи

.2.4 Віртуалізація мережевого обладнання

1.2.5 Постановка задачі

. Теоретична частина

.1 Віртуалізація як інструмент навчання, проектування мереж та системного адміністрування

.1.1 Віртуалізація в адмініструванні компютерних мереж

.1.2 Сервери та сервіси

.1.3 Віртуалізація сервісів

.2 Мережі та віртуалізація

.3 Віртуалізація у навчанні

.3.1 Сфери використання

.3.2 Вибір платформи для навчання

.4 Віртуалізація як засіб підвищення відмовостійкості

.4.1 VMware High Availability (HA)

.4.2 VM Monitoring

.4.3 VMware Fault Tolerance (FT)

.4.4 Distributed Resource Scheduler (DRS)

.4.5 VMware Site Recovery Manager (SRM)

.4.6 Переваги переходу на віртуальне середовище

. Практична частина

.1 Планування складу мережі

.1.1 Вибір платформи віртуалізації

.1.2 Вибір платформи на роль контролеру домену та серверу Active Directory

.1.3 Вибір варіанту рішення для 1С:Підприємство

.1.4 Вибір рішення для організації доменної пошти, внутрішньомережевого чату та засобу встановлення ОС через PXE

.1.5 Вибір операційної системи для користувацьких ПК

.2 Розгортання мережі на віртуальному стенді на базі VMware Workstation

.2.1 Створення віртуальної машини з VMware vSphere ESXi 5.1

.2.2 Встановлення та налаштування гіпервізора VMware vSphere ESXi 5.1

.2.3 Первинна настройка VMWare ESXi

.3 Встановлення Debian Wheezy для налаштування контролеру домену

.3.1 Встановлення Samba PDC та OpenLDAP

.4 Встановлення Windows Server 2008 R2 Enterprise

.4.1 Установка Windows Server 2008 R2 SP1

.4.2 Налаштування NTP-серверу

.4.3 Уведення VMware vSphere ESXi в домен

.5 Установка і налаштування PostgreSQL 9.1

.6 Установка FreeNX термінального серверу

. Охорона праці та безпека в надзвичайних ситуаціях

.1 Загальні положення

.2 Вимоги безпеки перед початком роботи

.3 Вимоги безпеки під час роботи

.4 Вимоги безпеки після закінчення роботи

.5 Вимоги безпеки в аварійних ситуаціях

Висновки

Список використаної літератури

Вступ

Сучасний світ IT-технологій та темпи його розвитку потребують постійного ведення розробки нового програмного забезпечення для мобільних пристроїв, персональних комп'ютерів, робочих станцій та серверного обладнання, тощо. Важливим етапом розробки якісного програмного продукту є тестування ПО для виявлення недоліків у програмному коді. Для проектування комп'ютерних мереж використовується моделювання роботи реальної мережі за допомогою імітації роботи реального мережевого обладнання. Для підвищення завадостійкості локальних мереж та збільшення ефективності роботи обслуговуючого персоналу використовують віртуальне програмне забезпечення та віртуальні операційні системи. І технології віртуалізації, як жодна річ, виконують вимоги користувачів. Вони заощаджують кошти керівництва підприємств, дозволяють уникнути помилок при проектуванні компютерних мереж та дають можливість розробникам програмного забезпечення виконати тестовий запуск нового продукту і провести його випробування, перш ніж випустити продукт на ринок. Сервери, що обслуговують компанії, починаючи від малого та середнього бізнесу, і завершуючи банками, промисловими гігантами та дата-центрами, у більшості - віртуальні.

Перелік достоїнств віртуалізації дійсно вражає, та вона виконує функції, без котрих не представляється можливим розвиток технологічної сфери людського життя. Тож, почнемо їх розгляд!

Літературний огляд

. Види та технології віртуалізації

1.1 Види віртуалізації

Поняття віртуалізації умовно можна розділити на дві фундаментально розрізняються категорії:

) Віртуалізація платформ

Продуктом цього виду віртуалізації є віртуальні машини - деякі програмні абстракції, що запускаються на платформі реальних апаратно-програмних систем.

2) Віртуалізація ресурсів

Даний вид віртуалізації переслідує своєю метою комбінування або спрощення подання апаратних ресурсів для користувача і здобуття якихось користувальницьких абстракцій обладнання, просторів імен, мереж і т.п.

.1.1 Віртуалізація платформ

Під віртуалізацією платформ розуміють створення програмних систем на основі існуючих апаратно-програмних комплексів, що залежать або незалежних від них. Система, що надає апаратні ресурси і програмне забезпечення, називається хостової (host), а симуляція їй системи - гостьовими (guest). Щоб гостьові системи могли стабільно функціонувати на платформі хостової системи, необхідно, щоб програмне і апаратне забезпечення хоста було досить надійним і надавало необхідний набір інтерфейсів для доступу до його ресурсів.

Є кілька видів віртуалізації платформ, в кожному з яких здійснюється свій підхід до поняття "віртуалізація". Види віртуалізації платформ залежать від того, наскільки повно здійснюється симуляція апаратного забезпечення. До цих пір немає єдиної угоди про термінах у сфері віртуалізації, тому деякі з наведених далі видів віртуалізації можуть відрізнятися від тих, що нададуть інші джерела.

Види віртуалізації платформ:

) Повна емуляція (симуляція)

При такому вигляді віртуалізації віртуальна машина повністю виртуализует всі апаратне забезпечення при збереженні гостьової операційної системи в незмінному вигляді. Такий підхід дозволяє емулювати різні апаратні архітектури. Наприклад, можна запускати віртуальні машини з гостьовими системами для x86-процесорів на платформах з іншою архітектурою (наприклад, на RISC-серверах компанії Sun). Довгий час такий вид віртуалізації використовувався, щоб розробляти програмне забезпечення для нових процесорів ще до того, як вони були фізично доступними. Такі емулятори також застосовують для низькорівневої налагодження операційних систем. Основний мінус даного підходу полягає в тому, що емульованого апаратне забезпечення вельми і вельми істотно уповільнює швидкодію гостьової системи, що робить роботу з нею дуже незручною, тому, крім як для розробки системного програмного забезпечення, а також освітніх цілей, такий підхід мало де використовується. Приклади продуктів для створення емуляторів: Bochs, PearPC, QEMU (без прискорення), Hercules Emulator.

) Часткова емуляція (нативна віртуалізація)

У цьому випадку віртуальна машина виртуализует лише необхідну кількість апаратного забезпечення, щоб вона могла бути запущена ізольовано. Такий підхід дозволяє запускати гостьові операційні системи, розроблені тільки для тієї ж архітектури, що і у хоста. Таким чином, кілька примірників гостьових систем можуть бути запущені одночасно. Цей вид віртуалізації дозволяє істотно збільшити швидкодію гостьових систем в порівнянні з повною емуляцією і широко використовується в даний час. Також, з метою підвищення швидкодії, в платформах віртуалізації, що використовують даний підхід, застосовується спеціальна "прошарок" між гостьовою операційною системою і устаткуванням (гіпервізор), що дозволяє гостьовий системі безпосередньо звертатися до ресурсів апаратного забезпечення. Гипервизор, званий також "Монітор віртуальних машин" (Virtual Machine Monitor) - одне з ключових понять у світі віртуалізації. Застосування гіпервізора, що є сполучною ланкою між гостьовими системами та апаратурою, істотно збільшує швидкодію платформи, наближаючи його до швидкодії фізичної платформи. До мінусів даного виду віртуалізації можна віднести залежність віртуальних машин від архітектури апаратної платформи.

Приклади продуктів для нативної віртуалізації: VMware Workstation, VMware Server, VMware ESX Server, Virtual Iron, Virtual PC, VirtualBox, Parallels Desktop та інші.

) Часткова віртуалізація, а також "віртуалізація адресного простору" ("address space virtualization")

При такому підході, віртуальна машина симулює кілька примірників апаратного оточення (але не всього), зокрема, простору адрес. Такий вид віртуалізації дозволяє спільно використовувати ресурси і ізолювати процеси, але не дозволяє розділяти примірники гостьових операційних систем. Строго кажучи, при такому вигляді віртуалізації користувачем не створюються віртуальні машини, а відбувається ізоляція будь-яких процесів на рівні операційної системи. В даний момент багато хто з відомих операційних систем використовують такий підхід. Прикладом може послужити використання UML (User-mode Linux), в якому "гостьове" ядро запускається у просторі користувача базового ядра (у його контексті).

) Паравіртуалізація

При застосуванні паравіртуалізації немає необхідності симулювати апаратне забезпечення, однак, замість цього (або на додаток до цього), використовується спеціальний програмний інтерфейс (API) для взаємодії з гостьовою операційною системою. Такий підхід вимагає модифікації коду гостьової системи, що, з точки зору спільноти, Open Source не так і критично. Системи для паравіртуалізації також мають свій гіпервізор, а API-виклики до гостьової системі, називаються "hypercalls" (гіпервизови). Багато хто сумнівається в перспективах цього підходу віртуалізації, оскільки в даний момент всі рішення виробників апаратного забезпечення стосовно віртуалізації спрямовані на системи з нативної віртуалізацією, а підтримку паравіртуалізації доводиться шукати у виробників операційних систем, які слабо вірять в можливості пропонованого їм кошти. В даний час провайдерами паравіртуалізації є компанії XenSource і Virtual Iron, які стверджують, що швидкодія паравіртуалізації вище.

) Віртуалізація рівня операційної системи

Суттю даного виду віртуалізації є віртуалізація фізичного сервера на рівні операційної системи з метою створення декількох захищених віртуалізованних серверів на одному фізичному. Гостьова система, в даному випадку, розділяє використання одного ядра хостової операційної системи з іншими гостьовими системами. Віртуальна машина являє собою оточення для додатків, що запускаються ізольовано. Даний тип віртуалізації застосовується при організації систем хостингу, коли в рамках одного примірника ядра потрібно підтримувати декілька віртуальних серверів клієнтів.

Приклади віртуалізації рівня ОС: Linux-VServer, Virtuozzo, OpenVZ,Solaris Containers і FreeBSD Jails.

) Віртуалізація програмного рівня

Цей вид віртуалізації не схожий на всі інші: якщо в попередніх випадках створюються віртуальні середовища або віртуальні машини, що використовуються для ізоляції додатків, то в даному випадку сам додаток поміщається в контейнер з необхідними елементами для своєї роботи: файлами реєстру, файлами налаштувань, користувача і системними об'єктами. У результаті виходить додаток, що не вимагає установки на аналогічній платформі. При перенесенні такого додатку на іншу машину і його запуску, віртуальне оточення, створене для програми, вирішує конфлікти між нею і операційною системою, а також іншими додатками. Такий спосіб віртуалізації схожий на поведінку інтерпретаторів різних мов програмування (недарма інтерпретатор, Віртуальна Машина Java (JVM), теж потрапляє в цю категорію). Прикладом такого підходу служать: Thinstall, Altiris, Trigence, Softricity.

1.1.2 Віртуалізація ресурсів

При описі віртуалізаційних платформ ми розглядали поняття віртуалізації у вузькому сенсі, переважно застосовуючи його до процесу створення віртуальних машин. Однак якщо розглядати віртуалізацію в широкому сенсі, можна прийти до поняття віртуалізації ресурсів, узагальнюючим в собі підходи до створення віртуальних систем. Віртуалізація ресурсів дозволяє концентрувати, абстрагувати і спрощувати управління групами ресурсів, таких як мережі, сховища даних і простору імен.

Види віртуалізації ресурсів:

) Об'єднання, агрегація і концентрація компонентів

Під таким видом віртуалізації ресурсів розуміється організація декількох фізичних або логічних об'єктів в пули ресурсів (групи), що представляють зручні інтерфейси користувачеві. Приклади такого виду віртуалізації:

)багатопроцесорні системи, що представляються нам як одна потужна система,

)RAID-масиви та засоби керування томами, що комбінують декілька фізичних дисків в один логічний,

)віртуалізація систем зберігання, використовувана при побудові мереж зберігання даних SAN (Storage Area Network),

)віртуальні приватні мережі (VPN) і трансляція мережевих адрес (NAT), що дозволяють створювати віртуальні простори мережевих адрес та імен.

) Кластеризація комп'ютерів та розподілені обчислення (grid computing)

Цей вид віртуалізації включає в себе техніки, застосовувані при об'єднанні безлічі окремих комп'ютерів у глобальні системи (метакомпьютери), спільно вирішальні загальну задачу.

) Поділ ресурсів (partitioning)

При поділі ресурсів у процесі віртуалізації відбувається поділ якого-небудь одного великого ресурсу на кілька однотипних об'єктів, зручних для використання. У мережах зберігання даних це називається зонуванням ресурсів ("zoning").

) Інкапсуляція

Багатьом це слово відомо як приховування об'єктом всередині себе своєї реалізації. Стосовно до віртуалізації, можна сказати, що це процес створення системи, що надає користувачеві зручний інтерфейс для роботи з нею і приховує подробиці складності своєї реалізації. Наприклад, використання центральним процесором кеша для прискорення обчислень не відбивається на його зовнішніх інтерфейсах.

Віртуалізація ресурсів, на відміну від віртуалізації платформ, має більш широкий і розпливчастий сенс і являє собою масу різних підходів, спрямованих на підвищення зручності звернення користувачів з системами в цілому. Тому, далі ми будемо спиратися в основному на поняття віртуалізації платформ, оскільки технології, пов'язані саме з цим поняттям, є в даний момент найбільш динамічно розвиваються і ефективними.

1.1.3 Де застосовується віртуалізація

Віртуалізація операційних систем за останні три-чотири роки дуже добре просунулася вперед, як в технологічному, так і в маркетинговому сенсі. З одного боку, користуватися продуктами віртуалізації стало набагато простіше, вони стали більш надійними і функціональними, а з іншого - знайшлося чимало нових цікавих застосувань віртуальним машинам.

Сферу застосування віртуалізації можна визначити, як "місце, де є комп'ютери", проте на даний момент можна позначити наступні варіанти використання продуктів віртуалізації:

) Консолідація серверів

У даний момент програми, що працюють на серверах в IT-інфраструктурі компаній, створюють невелике навантаження на апаратні ресурси серверів (в середньому 5-15 відсотків). Віртуалізація дозволяє мігрувати з цих фізичних серверів на віртуальні та розмістити їх все на одному фізичному сервері, збільшивши його завантаження до 60-80 відсотків і, підвищивши тим самим коефіцієнт використання апаратури, що дозволяє істотно заощадити на апаратурі, обслуговуванні та електроенергії.

) Розробка і тестування програм

Безліч продуктів віртуалізації дозволяють запускати кілька різних операційних систем одночасно, дозволяючи тим самим розробникам і тестерам програмного забезпечення тестувати їх додатки на різних платформах і конфігураціях. Також зручні засоби по створенню "знімків" поточного стану системи одним кліком миші і такого ж простого відновлення з цього стану, дозволяють створювати тестові оточення для різних конфігурацій, що істотно підвищує швидкість і якість розробки.

) Використання в бізнесі

Цей варіант використання віртуальних машин є найбільш великим і творчим. До нього відноситься все, що може знадобитися при повсякденному поводженні з IT-ресурсами в бізнесі. Наприклад, на основі віртуальних машин можна легко створювати резервні копії робочих станцій і серверів (просто скопіювавши папку), будувати системи, що забезпечують мінімальний час відновлення після збоїв, і т.п. До даної групи варіантів використання відносяться всі ті бізнес-рішення, які використовують основні переваги віртуальних машин.

) Використання віртуальних робочих станцій

З приходом ери віртуальних машин буде безглуздо робити собі робочу станцію з її прив'язкою до апаратури. Тепер створивши одного разу віртуальну машину зі своєї робочого або домашнього середовища, можна буде використовувати її на будь-якому іншому комп'ютері. Також можна використовувати готові шаблони віртуальних машин (Virtual Appliances), які вирішують певне завдання (наприклад, сервер додатків). Концепція такого використання віртуальних робочих станцій може бути реалізована на основі хост-серверів для запуску на них переміщуються десктопів користувачів (щось подібне мейнфреймів). Надалі ці десктопи користувач може забрати з собою, не синхронізуючи дані з ноутбуком. Цей варіант використання також надає можливість створення захищених користувача робочих станцій, які можуть бути використані, наприклад, для демонстрації можливостей програми замовнику. Можна обмежити час використання віртуальної машини - і після цього часу віртуальна машина перестане запускатися. У цьому варіанті використання закладені великі можливості.

.2 Технології віртуалізації

Віртуалізація в обчисленнях - процес подання набору обчислювальних ресурсів, або їх логічного об'єднання, який дає певні переваги перед оригінальною конфігурацією. Це новий віртуальний погляд на ресурси складових частин, не обмежених реалізацією, фізичної конфігурацією або географічним положенням. Зазвичай віртуалізовані ресурси включають в себе обчислювальні потужності і сховище даних, інакше кажучи, віртуалізація - це ізоляція обчислювальних процесів і ресурсів один від одного.

Прикладом віртуалізації є симетричні мультипроцесорні комп'ютерні архітектури, які використовують більше одного процесора. Операційні системи зазвичай конфігуруються таким чином, щоб кілька процесорів представлялися як єдиний процесорний модуль. Ось чому програмні додатки можуть бути написані для одного логічного (віртуального) обчислювального модуля, що значно простіше, ніж працювати з великою кількістю різних процесорних конфігурацій.

Виділяють три основних типи віртуалізації: програмна, апаратна та віртуалізація на рівні операційної системи, основні їх характеристики подані нижче.

1.2.1 Програмна віртуалізація

Програмна віртуалізація припускає функціонування віртуальних середовищ поверх програмної прошарку, що забезпечує доступ ізольованих ВМ до загального пулу апаратних ресурсів. Програмна віртуалізація отримала саме широке поширення на серверах стандартної архітектури x86.

Використання програмної віртуалізації дозволяє реалізувати такі переваги:

)Підвищення норми утилізації ресурсів з 5-15% до 60-80% приводить до скорочення числа необхідних серверів і розмірів ЦОД. Результатом стане економія на оренді площ, зниженні енергоспоживання серверів і систем кондиціонування, зниження потреби в обслуговуючому персоналі;

)Розгортання віртуальних серверів і додатків та їх перенесення на інше обладнання займає набагато менше часу;

)Відкривається можливість динамічно виділяти ресурси кожної ВМ відповідно до реальних потреб бізнес-додатків;

)Консолідація виконуваних додатків, забезпечувана повною ізоляцією кожної з ВМ. Крах будь-якої ВМ не впливає на працездатність інших машин, що функціонують на тій же апаратурі;

)Міграція успадкованих додатків і версій ОС на віртуальні розділи без модифікації;

)Централізований засіб управління всіма віртуальними серверами підприємства через єдиний інтерфейс;

)Висока оперативність відновлення доступності додатків після збоїв.

Програмна паравіртуалізація

Паравіртуалізація є рішенням по обходу команд процесора (операційної системи хоста), які не піддаються віртуалізації. Для цього ядро гостьової системи перед початком роботи модифікується таким чином, щоб замінити "погані" команди на запити до гіпервізора, який транслює запити до процесора. За аналогією з мережевими технологіями, в даному випадку гіпервізор можна порівняти з проксі-сервером. Однак застосування даної технології довгий час було обмежене закритістю вихідного коду пропрієтарних операційних систем. Однак з введенням процесорів з підтримкою технологій апаратної віртуалізації, стало можливо запускати немодифіковані ОС на системах паравіртуалізації.

Програмна повна віртуалізація

У 1998 році компанія VMWare випустила програмний комплекс повної віртуалізації, який був заснований на бінарній трансляції коду. Код гостьової операційної системи приймався гіпервізором і перевірявся на наявність проблемних команд. Логіка гіпервізора при цьому або перекладала команди на виконання від імені гіпервізора, або заміняла певним чином команди. Технологія повної віртуалізації дала можливість реалізувати віртуалізацію пропрієтарних операційних систем, як Windows, MacOS, де немає можливості модифікувати ядро системи. Однак слід зазначити, що повна трансляція і модифікація бінарного коду - вельми ресурсномістка операція, тому така повна віртуалізація не відрізняється високою продуктивністю.

.2.2 Апаратна віртуалізація

Апаратна віртуалізація - віртуалізація з підтримкою спеціальної процесорної архітектури. На відміну від програмної віртуалізації, за допомогою даної техніки можливе використання ізольованих гостьових систем, керованих гіпервізором безпосередньо. Гостьова система не залежить від архітектури хостової платформи та реалізації платформи віртуалізації. Наприклад, за допомогою технологій апаратної віртуалізації можливий запуск 64-бітних гостьових систем на 32-бітних хостових системах.

Апаратна віртуалізація забезпечує продуктивність, порівнянну з продуктивністю невіртуалізованной машини, що дає віртуалізації можливість практичного використання і тягне її широке поширення. Найбільш поширені технології віртуалізації Intel-VT і AMD-V:

У Intel VT (Intel Virtualization Technology) реалізована віртуалізація режиму реальної адресації (режим сумісності з 8086). Відповідна апаратна віртуалізація введення-виведення - VT-d. Часто позначається абревіатурою VMX (Virtual Machine eXtension). Кодова назва - Vanderpool.V часто позначається абревіатурою SVM (Secure Virtual Machines). Кодова назва - Pacifica. Відповідна технологія віртуалізації введення-виведення - IOMMU. AMD-V простіше і ефективніше, ніж Intel VT. Підтримка AMD-V з'явилася в Xen 3.3.

За кожним віртуальним сервером, як правило, закріплюється власний набір апаратних ресурсів. Апаратна віртуалізація дозволяє виділити віртуальній машині (ВМ) потрібні апаратні ресурси і забезпечити розподіл апаратних потужностей на рівні пристроїв.

Розвиток апаратних технік віртуалізації

Ідея апаратної віртуалізації не нова: вперше вона була втілена в 386-х процесорах і носила назву V86 mode. Цей режим роботи 8086-го процесора дозволяв запускати паралельно кілька DOS-додатків. Тепер апаратна віртуалізація дозволяє запускати кілька незалежних віртуальних машин у відповідних розділах апаратного простору комп'ютера. Апаратна віртуалізація є логічним продовженням еволюції рівнів абстрагування програмних платформ - від багатозадачності до рівня віртуалізації:

Багатозадачність

Рис. 1.1 Багатозадачність

Багатозадачність є першим рівнем абстракції додатків. Кожна програма поділяє ресурси фізичного процесора в режимі поділу виконання коду за часом.

HyperThreading

Рис. 1.2 HyperThreading

Технологія HyperThreading в широкому сенсі також представляє собою апаратну технологію віртуалізації, оскільки при її використанні в рамках одного фізичного процесора відбувається симуляція двох віртуальних процесорів в рамках одного фізичного з допомогою техніки Symmetric Multi Processing (SMP).

Віртуалізація

Рис. 1.3 Віртуалізація

Віртуалізація являє собою емуляцію декількох віртуальних процесорів для кожної з гостьових операційних систем. При цьому технологія віртуального SMP дозволяє представляти кілька віртуальних процесорів в гостьовій ОС за наявності технології HyperThreading або декількох ядер у фізичному процесорі.

Переваги апаратної віртуалізації над програмною

Програмна віртуалізація в даний момент преважає над апаратною на ринку технологій віртуалізації з огляду на те, що довгий час виробники процесорів не могли належним чином реалізувати підтримку віртуалізації. Процес впровадження нової технології в процесори вимагав серйозної зміни їх архітектури, введення додаткових інструкцій і режимів роботи процесорів. Це породжувало проблеми забезпечення сумісності і стабільності роботи, які були повністю вирішені в 2005-2006 роках в нових моделях процесорів. Незважаючи на те, що програмні платформи вельми просунулися щодо швидкодії та надання засобів управління віртуальними машинами, технологія апаратної віртуалізації має деякі незаперечні переваги перед програмної:

)Спрощення розробки платформ віртуалізації за рахунок надання апаратних інтерфейсів управління та підтримки віртуальних гостьових систем. Це сприяє появі та розвитку нових платформ віртуалізації і засобів управління, у зв'язку із зменшенням трудомісткості і часу їх розробки.

)Можливість збільшення швидкодії платформ віртуалізації. Оскільки управління віртуальними гостьовими системами проводиться за допомогою невеликого проміжного шару програмного забезпечення (гіпервізора) безпосередньо, в перспективі очікується збільшення швидкодії платформ віртуалізації на основі апаратних технік.

)Можливість незалежного запуску декількох віртуальних платформ з можливістю перемикання між ними на апаратному рівні. Кілька віртуальних машин можуть працювати незалежно, кожна в своєму просторі апаратних ресурсів, що дозволить усунути втрати швидкодії на підтримку хостової платформи, а також збільшити захищеність віртуальних машин за рахунок їх повної ізоляції.

)Відлучення гостьової системи від архітектури хостової платформи та реалізації платформи віртуалізації. За допомогою технологій апаратної віртуалізації можливий запуск 64-бітних гостьових систем з 32-бітових хостових системах, з запущеними у них 32-бітними середовищами віртуалізації.

Як працює апаратна віртуалізація

Необхідність підтримки апаратної віртуалізації змусила виробників процесорів дещо змінити їх архітектуру за рахунок введення додаткових інструкцій для надання прямого доступу до ресурсів процесора з гостьових систем. Цей набір додаткових інструкцій носить назву Virtual Machine Extensions (VMX). VMX надає наступні інструкції: VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXON і VMXOFF.

Процесор з підтримкою віртуалізації може працювати в двох режимах root operation і non-root operation. У режимі root operation працює спеціальне програмне забезпечення, що є "легковагою" прошарком між гостьовими операційними системами і обладнанням - монітор віртуальних машин (Virtual Machine Monitor, VMM), що носить також назву гіпервізор (hypervisor). Слово "гіпервізор" з'явилося цікавим чином: колись дуже давно, операційна система носила назву "supervisor", а програмне забезпечення, що знаходиться "під супервізором", отримало назву "гіпервізор".

Щоб перевести процесор в режим віртуалізації, платформа віртуалізації повинна викликати інструкцію VMXON і передати управління гіпервізорами, який запускає віртуальну гостьову систему інструкцією VMLAUNCH і VMRESUME (точки входу у віртуальну машину). Virtual Machine Monitor може вийти з режиму віртуалізації процесора, викликавши інструкцію VMXOFF.

Рис. 1.4 Процедура запуску віртуальних машин

Кожна з гостьових операційних систем запускається і працює незалежно від інших і є ізольованою з точки зору апаратних ресурсів і безпеки.

Відмінність апаратної віртуалізації від програмної

Класична архітектура програмної віртуалізації увазі наявність хостової операційної системи, поверх якої запускається платформа віртуалізації, емулююча роботу апаратних компонентів і керуюча апаратними ресурсами щодо гостьової операційної системи. Реалізація такої платформи досить складна і трудомістка, присутні втрати продуктивності, у зв'язку з тим, що віртуалізація проводиться поверх хостової системи. Безпека віртуальних машин також знаходиться під загрозою, оскільки отримання контролю на хостової операційною системою автоматично означає отримання контролю над усіма гостьовими системами.

На відміну від програмної техніки, за допомогою апаратної віртуалізації можливе отримання ізольованих гостьових систем, керованих гіпервізором безпосередньо. Такий підхід може забезпечити простоту реалізації платформи віртуалізації і збільшити надійність платформи з декількома одночасно запущеними гостьовими системами, при цьому немає втрат продуктивності на обслуговування хостової системи. Така модель дозволить наблизити продуктивність гостьових систем до реальних і скоротити витрати продуктивності на підтримку хостової платформи.

Недоліки апаратної віртуалізації

Варто також відзначити, що апаратна віртуалізація потенційно несе в собі не тільки позитивні моменти. Можливість управління гостьовими системами за допомогою гіпервізора і простота написання платформи віртуалізації з використанням апаратних технік дають можливість розробляти шкідливе програмне забезпечення, яке після отримання контролю на хостової операційною системою, виртуализует її та здійснює всі дії за її межами.

На початку 2006 року в лабораторіях Microsoft Research був створений руткіт під кодовою назвою SubVirt, що вражає хостової системи Windows і Linux та чинить свою присутність практично не виявляється. Принцип дії цього руткита полягав у наступному:

)Через одну з вразливостей в операційній системі комп'ютера шкідливе програмне забезпечення отримує адміністративний доступ.

)Після цього, руткіт починає процедуру міграції фізичної платформи на віртуальну, по закінченні якої відбувається запуск віртуалізованому платформи допомогою гіпервізора. При цьому для користувача нічого не змінюється, все продовжує працювати, як і раніше, а всі засоби і служби, необхідні для доступу до гіпервізорами ззовні (наприклад, термінального доступу), знаходяться за межами віртуалізованому системи.

)Антивірусне програмне забезпечення після здійснення процедури міграції не може виявити шкідливий код, оскільки він перебуває за межами віртуалізованому системи.

Наочно ця процедура виглядає так:

Рис. 1.5 Система роботи руткіту SubVirt

Однак, не варто перебільшувати небезпеку. Розробити шкідливу програму, що використовує технології віртуалізації все одно набагато складніше, ніж, користуючись "традиційними" засобами, експлуатуючими різні уразливості в операційних системах. При цьому головне допущення, яке робиться тими, хто стверджує, що таке зловмисне складніше у виявленні і більше того, може не використовувати "дірки" в ОС, діючи виключно "в рамках правил", полягає в тому, що нібито віртуалізована операційна система не в змозі виявити, що вона запущена на віртуальній машині, що є початково невірна посилка. Відповідно, антивірусне забезпечення має всі можливості виявити факт зараження. А, отже, пропадає і сенс розробляти настільки ресурсномісткий і складний троян, враховуючи наявність куди більш простих способів вторгнення.

Програмне забезпечення, що підтримує апаратну віртуалізацію

На даний момент, абсолютна більшість вендорів програмних платформ віртуалізації заявило про підтримку технологій апаратної віртуалізації Intel і AMD. Віртуальні машини на цих платформах можуть бути запущені за підтримки апаратної віртуалізації. Крім того, у багатьох операційних системах, в дистрибутив яких включені програмні платформи паравіртуалізації, такі як Xen або Virtual Iron, апаратна віртуалізація дозволить запускати незмінені гостьові операційні системи. Так як паравіртуалізації є одним з видів віртуалізації, що вимагають модифікації гостьової операційної системи, реалізація в платформах паравіртуалізації підтримки апаратної віртуалізації є для цих платформ вельми прийнятним рішенням, з точки зору можливості запуску не модифікованих версій гостьових систем. У наведеній далі таблиці перераховані основні популярні платформи віртуалізації та програмне забезпечення, що підтримують технології апаратної віртуалізації:

Табл. 1.1 ПО з пітримкою апаратної віртуалізації

Платформа або ПОПідтримувані технологіїПриміткаKernel-based Virtual Machine (KVM)Intel VT, AMD-VВіртуалізація рівня екземплярів операційних систем під Linux.Microsoft Virtual PCIntel VT, AMD-VНастільна платформа віртуалізації для хостових Windows-платформ.Microsoft Virtual ServerIntel VT, AMD-VСерверна платформа віртуалізації для Windows. Версія з підтримкою апаратної віртуалізації, Microsoft Virtual Server 2005 R2 SP1Parallels WorkstationIntel VT, AMD-VПлатформа віртуалізації для Windows і Linux хостів.VirtualBoxIntel VT, AMD-VНастільна платформа віртуалізації з відкритим вихідним кодом для Windows, Linux і Mac OS.Virtual IronIntel VT, AMD-VVirtual Iron 3.5 є першою платформою віртуалізації, що використовує апаратні техніки, яка дозволяє запускати 32-бітові та 64-бітові незмінені гостьові системи практично без втрати продуктивності.VMware Workstation и VMware ServerIntel VT, AMD-VДля запуску 64-х бітних гостьових систем потрібна підтримка Intel VT (так само як і для VMware ESX Server), для 32-бітних ж гостьових ОС за замовчуванням підтримка IntelVT відключена з тих же причин , що і у VirtualBox.XenIntel 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 є кілька обмежень:

) Тільки один vCPU;

) Не повинні мати знімків віртуальних машин (снапшотов);

) Не можуть перебувати на хостах в режимах 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 Уведення паролю roota

)Далі буде запропоновано створити нового користувача, задати його імя та пароль.

)Прийшов час розмітити віртуальний диск для встановлення системи. Обираємо режим "вручну":

Рис. 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

# to get slapd running at all. See #"justify"># information.

# Number of objects that can be locked at the same time.set_lk_max_objects 1500

# Number of locks (both requested and granted)set_lk_max_locks 1500

# Number of lockersset_lk_max_lockers 1500

# Indices to maintain for this databaseobjectClass eq,presou,cn,sn,mail,givenname eq,pres,subuidNumber,gidNumber,memberUid eq,presloginShell eq,pres

## required to support pdb_getsampwnamuid pres,sub,eq

## required to support pdb_getsambapwrid()displayName pres,sub,eqnisMapName,nisMapEntry eq,pres,subsambaSID eqsambaPrimaryGroupSID eqsambaDomainName eqdefault subuniqueMember eqsambaGroupType eqsambaSIDList eq

# Save the time that the entry gets modified, for database #1on

# Checkpoint the BerkeleyDB database periodically in case of system

# failure and to speed slapd shutdown.512 30

# Where to store the replica logs for database #1

# replogfile /var/lib/ldap/replog

# users can authenticate and change their passwordto attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdMustChange,sambaPwdLastSetself writeanonymous auth* none

# those 2 parameters must be world readable for password aging to work correctly

# (or use a priviledge account in /etc/ldap.conf to bind to the directory)to attrs=shadowLastChange,shadowMaxself write* read

# all others attributes are readable to everybodyto ** read

# For Netscape Roaming support, each user gets a roaming

# profile for which they have write access to

#access to dn=".*,ou=Roaming,o=morsnet"

# by dn="cn=admin,dc=example,dc=com" write

# by dnattr=owner write

#######################################################################

# Specific Directives for database #2, of type 'other' (can be hdb too):

# Database specific directives apply to this databasse until another

# 'database' directive occurs

#database <other>

# The base of your directory for database #2

#suffix "dc=debian,dc=org"

Самої схеми самби за замовчуванням немає, треба взяти із прикладів.

# zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz > /etc/ldap/schema/samba.schema

Для вставки хешу пароля використовуємо команду

# slappasswd -h {MD5}

Підклали конфіг, можна пробувати стартувати Slapd:

# slapindex

# chown -R openldap:openldap /var/lib/ldap

# service slapd start

5)Налаштування Samba

Налаштування проводимо у /etc/samba/smb.conf:

dos charset = CP1251charset = UTF8charset = UTF8= LDAP= OpenLDAPstring = %h server

#interfaces = eth0:1 ## Необходимо поправить на свой интерфейс, или вообще убрать

#bind interfaces only = Yes ## Убрать, если нет определенного интерфейса на самбуto guest = Bad Userbackend = ldapsam:ldap://127.0.0.1/password change = Yesprogram = /usr/sbin/smbldap-passwd -u %uchat = *New*password* %n\n *Retype*new*password* %n\n *all*authentication*tokens*updated*= 0server = Yesfile = /var/log/samba/log.%mlog size = 1000options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192user script = /usr/sbin/smbldap-useradd -m %u -d /domain/home/%u %uuser script = /usr/sbin/smbldap-userdel %u -r %ugroup script = /usr/sbin/smbldap-groupadd -p %ggroup script = /usr/sbin/smbldap-groupdel %guser to group script = /usr/sbin/smbldap-groupmod -m %u %guser from group script = /usr/sbin/smbldap-groupmod -x %u %gprimary group script = /usr/sbin/smbldap-usermod -g %g %umachine script = /usr/sbin/smbldap-useradd -w %u

#logon script = logon.bat

##logon path = \\%N\profiles\%U ## Раскомментировать, если нужны переносимые профилиlogons = Yeslevel = 10master = Yesmaster = Yesproxy = Nosupport = Yesadmin dn = cn=admin,dc=ldapdelete dn = Yesgroup suffix = ou=groupidmap suffix = ou=idmapmachine suffix = ou=computersuffix = dc=ldapssl = nouser suffix = ou=peopleaction = /usr/share/samba/panic-action %dacl inherit = Yessensitive = Nounreadable = Yeshidden = Yessystem = Yespasswd sync = yes

[homes]= Home Directories= /domain/home/%uusers = %Sonly = Nomask = 0600mask = 0700= No

[netlogon]= /domain/netlogon= No

#[profiles] ## Раскомментировать, если нужны переносимые профили

#path = /domain/profiles

#force user = %U

#read only = No

#create mask = 0600

#directory mask = 0700

#guest ok = Yes

#profile acls = Yes

#browseable = No

#csc policy = disable

Треба працювати через OpenLDAP і створювати для Windows-машин домен з ім'ям LDAP. Задаємо пароль у LDAP для Samba:

# smbpasswd -w password

Створюємо потрібні директорії:

# mkdir -p /domain/netlogon /domain/profiles

# chown -Rf root:root /domain/netlogon /domain/profiles /domain/home

# chmod 1777 /domain/profiles

Перезапускаємо Samba:

# service samba restart

6)Налаштування libnss і SMB-LDAP-Utils

Налаштування мінімальні.

Дивимося в /etc/ldap/ldap.conf (це настройка клієнта LDAP):

host 127.0.0.1dc=ldapcn=admin,dc=ldappassword_policy soft_password exop15_base_passwd dc=ldap?sub_base_shadow dc=ldap?sub_base_group ou=group,dc=ldap?one

Ну і найважливіше - скрипти інтеграції Samba і LDAP:

# nano /etc/smbldap-tools/smbldap.conf:

##############################################################################

#

# General Configuration

#

##############################################################################

# Put your own SID. To obtain this number do: "net getlocalsid".

# If not defined, parameter is taking from "net getlocalsid" return="S-1-5-21-3384730673-3036888877-1999087345"

# Domain name the Samba server is in charged.

# If not defined, parameter is taking from smb.conf configuration file

# Ex: sambaDomain="IDEALX-NT"="LDAP"

##############################################################################

#

# LDAP Configuration

#

##############################################################################

# Notes: to use to dual ldap servers backend for Samba, you must patch

# Samba with the dual-head patch from IDEALX. If not using this patch

# just use the same server for slaveLDAP and masterLDAP.

# Those two servers declarations can also be used when you have

# . one master LDAP server where all writing operations must be done

# . one slave LDAP server where all reading operations must be done

# (typically a replication directory)

# Slave LDAP server

# Ex: slaveLDAP=127.0.0.1

# If not defined, parameter is set to "127.0.0.1"="127.0.0.1"

# Slave LDAP port

# If not defined, parameter is set to "389"="389"

# Master LDAP server: needed for write operations

# Ex: masterLDAP=127.0.0.1

# If not defined, parameter is set to "127.0.0.1"="127.0.0.1"

# Master LDAP port

# If not defined, parameter is set to "389"

#masterPort="389"="389"

# Use TLS for LDAP

# If set to 1, this option will use start_tls for connection

# (you should also used the port 389)

# If not defined, parameter is set to "0"="0"

# Use SSL for LDAP

# If set to 1, this option will use SSL for connection

# (standard port for ldaps is 636)

# If not defined, parameter is set to "0"="0"

# How to verify the server's certificate (none, optional or require)

# see "man Net::LDAP" in start_tls section for more details="require"

# CA certificate

# see "man Net::LDAP" in start_tls section for more details="/etc/smbldap-tools/ca.pem"

# certificate to use to connect to the ldap server

# see "man Net::LDAP" in start_tls section for more details="/etc/smbldap-tools/smbldap-tools.pem"

# key certificate to use to connect to the ldap server

# see "man Net::LDAP" in start_tls section for more details="/etc/smbldap-tools/smbldap-tools.key"

# LDAP Suffix

# Ex: suffix=dc=IDEALX,dc=ORG="dc=ldap"

# Where are stored Users

# Ex: usersdn="ou=Users,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for usersdn="ou=people,${suffix}"

# Where are stored Computers

# Ex: computersdn="ou=Computers,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for computersdn="ou=computer,${suffix}"

# Where are stored Groups

# Ex: groupsdn="ou=Groups,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for groupsdn="ou=group,${suffix}"

# Where are stored Idmap entries (used if samba is a domain member server)

# Ex: groupsdn="ou=Idmap,dc=IDEALX,dc=ORG"

# Warning: if 'suffix' is not set here, you must set the full dn for idmapdn="ou=idmap,${suffix}"

# Where to store next uidNumber and gidNumber available for new users and groups

# If not defined, entries are stored in sambaDomainName object.

# Ex: sambaUnixIdPooldn="sambaDomainName=${sambaDomain},${suffix}"

# Ex: sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"="sambaDomainName=${sambaDomain},${suffix}"

# Default scope Used="sub"

# Unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT)_encrypt="MD5"

# if hash_encrypt is set to CRYPT, you may set a salt format.

# default is "%s", but many systems will generate MD5 hashed

# passwords if you use "$1$%.8s". This parameter is optional!_salt_format="%s"

##############################################################################

#

# Unix Accounts Configuration

#

##############################################################################

# Login defs

# Default Login Shell

# Ex: userLoginShell="/bin/bash"="/bin/bash"

# Home directory

# Ex: userHome="/home/%U"="/domain/home/%U"

# Default mode used for user homeDirectory="700"

# Gecos="System User"

# Default User (POSIX and Samba) GID="513"

# Default Computer (Samba) GID="515"

# Skel dir="/etc/skel"

# Default password validation time (time in days) Comment the next line if

# you don't want password to be enable for defaultMaxPasswordAge days (be

# careful to the sambaPwdMustChange attribute's value)="365"

##############################################################################

#

# SAMBA Configuration

#

##############################################################################

# The UNC path to home drives location (%U username substitution)

# Just set it to a null string if you want to use the smb.conf 'logon home'

# directive and/or disable roaming profiles

# Ex: userSmbHome="\\PDC-SMB3\%U"="\\%L\%U"

# The UNC path to profiles locations (%U username substitution)

# Just set it to a null string if you want to use the smb.conf 'logon path'

# directive and/or disable roaming profiles

# Ex: userProfile="\\PDC-SMB3\profiles\%U"

#userProfile="\\%L\profiles\%U"=""

# The default Home Drive Letter mapping

# (will be automatically mapped at logon time if home directory exist)

# Ex: userHomeDrive="H:"="U:"

# The default user netlogon script name (%U username substitution)

# if not used, will be automatically username.cmd

# make sure script file is edited under dos

# Ex: userScript="startup.cmd" # make sure script file is edited under dos

#userScript="logon.bat"=""

# Domain appended to the users "mail"-attribute

# when smbldap-useradd -M is used

# Ex: mailDomain="idealx.com"="ldap"

##############################################################################

#

# SMBLDAP-TOOLS Configuration (default are ok for a RedHat) И для Debian Squeeze, хе-хе

#

##############################################################################

# Allows not to use smbpasswd (if with_smbpasswd == 0 in smbldap_conf.pm) but

# prefer Crypt::SmbHash library_smbpasswd="0"="/usr/bin/smbpasswd"

# Allows not to use slappasswd (if with_slappasswd == 0 in smbldap_conf.pm)

# but prefer Crypt:: libraries_slappasswd="0"="/usr/sbin/slappasswd"

# comment out the following line to get rid of the default banner

# no_banner="1"

Дізнатися SID домену можна командою:

# net getlocalsid

# nano /etc/smbldap-tools/smbldap_bind.conf:

############################

# Credential Configuration #

############################

# Notes: you can specify two differents configuration if you use a

# master ldap for writing access and a slave ldap server for reading access

# By default, we will use the same DN (so it will work for standard Samba

# release)="cn=admin,dc=ldap"="password"="cn=admin,dc=ldap"="password"

Налаштовуємо конфігурацію за замовчанням:

# cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf /etc/smbldap-tools/smbldap_bind.conf

# zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > /etc/smbldap-tools/smbldap.conf

Змінюємо права:

# chmod 0644 /etc/smbldap-tools/smbldap.conf

# chmod 0600 /etc/smbldap-tools/smbldap_bind.conf

Запуск smbldap:

# smbldap-populate

3.4 Встановлення Windows Server 2008 R2 Enterprise

Як аналог контролеру домену на linux також розглядався варіант підняття КД на базі Windows Server 2008 R2 Etnetprise. Після запуску віртуальної машини налаштовуємо на сервері NTP-сервер для синхронізації часу в домені. У нашому випадку сервер буде брати час з зовнішнього сервера ntp.time.in.ua. Піднімаємо домен, налаштовуємо служби AD, ролі і політики. Вводимо в домен всі створені віртуальні машини і сам гіпервізор для авторизації користувачів в клієнті vClient за логіном і паролем доменного аккаунта. Далі приведу порядок встановлення та налаштування:

.4.1 Установка Windows Server 2008 R2 SP1

Завантажуємося з ISO образу, на першому екрані вибираємо - мову США, регіональні стандарти - Россія; мова введення - США.

Рис. 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

#"justify"># 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.#"justify">2.http://ru.wikipedia.org/wiki/Аппаратная_виртуализация

.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.Михеев М. - "Администрирование 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.#"justify">19.#"justify">.ДержСанПіН 3.3.2.007 1998 "Правила охорони праці при експлуатації ЕОМ"

.Основи охорони праці. За редакцією К.Н. Ткачука і М.О. Халімовського

22.Безопасность жизнедеятельности. / Под ред. Н.А. Белова - М.: Знание, 2000

23.Зинченко В.П. Основы эргономики. - М.: МГУ, 1979

Реферат Дипломна робота містить 146 сторінок машинописного тексту, 83 рисунки, 1 таблицю та 23 літературних джерела. Обєкт дослідження: технології вір

Больше работ по теме: