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

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык украинский
Дата добавления 24.04.2014
Размер файла 5,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

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

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

Висока надійність і гарантоване обслуговування

У багатьох областях обслуговування абонентів критично важливо забезпечувати постійну роботу сервісу, мінімізувати простої через неполадки або управлятися з великим потоком запитів, щоб вони не приводили до порушення роботи сервісу. Системи, що володіють технічними характеристиками для виконання цих умов, називають системами високої надійності (high availability systems). Приміщення сервісу у віртуальний контейнер можна використовувати для підвищення надійності його роботи.

Обмеження ресурсів

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

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

Гарантовані ресурси

Апаратні ресурси, доступні віртуальному контейнеру, повинні бути гарантовано більше деякого мінімального значення. У ряді випадків необхідно надати клієнтам сервісу деякі гарантії якості обслужіваніяш (QoS, quality of service). Прикладом такої ситуації може служити телефонна розмова: після з'єднання клієнт отримує гарантію, що під час розмови не закінчаться ресурси каналу зв'язку і розмова не перерветься. Інший приклад, вже з області системного адміністрування: дуже бажано гарантувати, що навіть при максимальному навантаженні на сервері (у тому числі в ситуації DoS-атак), у сервісу SSH буде достатньо ресурсів, щоб забезпечити віддалений вхід на сервер системного адміністратора, який міг би вжити термінових заходів. Щоб забезпечити якість обслуговування для сервісу, адміністраторові необхідно гарантувати достатній обсяг апаратних ресурсів для цього сервісу, тобто виключити ситуації збою сервісу через фізичний брак ресурсів у системі. І тут можна використовувати віртуалізацію сервісів. Якщо сервіс працює у віртуальному контейнері, то гарантія мінімального рівня ресурсів зводиться до того, що процеси, що їх поза даного контейнера, в сумі не зажадають більше ресурсів, ніж різниця між обсягом ресурсів системи і ресурсами даного контейнера. Так, якщо в системі паралельно виконується кілька сервісів, кожен з яких поміщений в окремому віртуальному контейнері, то завдання адміністратора - обмежити ресурси кожного контейнера таким чином, щоб сума виділених їм ресурсів не перевищувала всіх ресурсів системи, і при цьому виділені кожному сервісу ресурси були достатні для його нормальної роботи.

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

Ізоляція ergo захищеність

Default deny - найважливіший принцип інформаційної безпеки: всяка взаємодія, яке не є завідомо необхідною, має бути за замовчуванням заборонена.

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

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

Програмні та апаратні засоби обмеження ресурсів

З попередніх розділів стає зрозуміло, що при використанні віртуальних контейнерів на сервері працездатність як віртуалізованних сервісів, так і основної ОС сервера досить істотно залежить від надійності роботи механізмів обмеження та ізоляції, закладених в технології віртуалізації. Такі механізми обмеження можуть бути двох родів: апаратні і програмні.

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

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

Захист інтерфейсу управління

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

Можливі варіанти захисту доступу до інтерфейсу управління:

1) заборонити віддалений доступ по мережі, дозволити тільки доступ з локальної консолі (віртуальна консоль, послідовний порт);

2) фізично ізолювати мережеве підключення для інтерфейсу управління (окремий мережевий адаптер);

3) логічно ізолювати мережеве підключення для інтерфейсу управління (окремий VLAN-інтерфейс);

4) використовувати захищені мережеві з'єднання для віддаленого доступу до інтерфейсу управління (захищений тунель 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 Віртуалізація у навчанні

2.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.

RouterOS під віртуальною машиною Qemu у складі GNS3 під управлінням Ubuntu виявилася кращим вибором для організації віртуальної лабораторії.

Операційна система RouterOs підтримує практично всі сучасні мережеві технології. Це дозволило розробити лабораторний практикум для вивчення наступних мережевих технологій: Ethernet-мости, DHCP, балансування навантаження, EoIP, NAT, маршрутизація RIP, OSPF і BGP, перерозподіл маршрутів, PPP, PPTP, SSTP, L2TP, OpenVPN, віртуальні приватні мережі 2-го і 3-го рівня, IPSec, MPLS, VPLS, VRF.

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

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

VMware передбачає широкий спектр служб і програм для підвищення відмовостійкості. Є як служби, що працюють автономно, так і служби, керовані адміністраторами. У даному розділі детальніше зупинимося на п'яти з них:

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

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

1) Хостів в кластері VMware HA - максимально 32 хоста;

2) Віртуальних машин на хост з числом хостів VMware ESX 8 і менше - максимально 100;

3) Віртуальних машин на хост з числом хостів VMware ESX 8 і менше для vSphere 4.0 Update 1 - максимально 160;

4) Віртуальних машин на хост з числом хостів VMware ESX 9 і більше - максимально 40;

Для великих компаній такі числа можуть бути недостатніми, так що ця функція корисна для малого та середнього бізнесу, однак, варто помітити, що компанія VMware оголосила про свої наміри в найближчому майбутньому ці показники підвищити. Зараз у кластері HA може бути тільки 5 primary хостів ESX, чого явно недостатньо для створення катастрофостійкі рішення на рівні possible failure domain. Крім того, на даний момент немає прозорого механізму призначення хостів як primary або secondary, що теж викликає іноді проблеми. У цьому плані компанія VMware вже докладає зусиль, щоб зробити такі кластери VMware HA, які будуть переживати необмежене число відмов хостів VMware ESX. Іншими словами High Availability - засіб відмовостійкості віртуальних машин, що дозволяє в разі відмови фізичного хост-сервера автоматично перезапустити його віртуальні машини з загального сховища

2.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 є кілька обмежень:

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

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

3) Не можуть перебувати на хостах в режимах maintenance mode або standby mode;

4) Не можуть мати пристроїв VMDirectPath I / O;

Експерти виділяють кілька правил, за яких технологія FT буде застосовуватися з найбільшим коефіцієнтом корисної дії:

1) Не заводьте більше 4-8 FT-машин на одному хості ESX (з урахуванням primary і secondary);

2) Помістіть ISO-образи, які використовують FT-машини на загальне сховище, щоб primary і secondary ВМ могли мати доступ до цих даних;

3) Вимкніть power management в BIOS хостів ESX / ESXi. Якщо вони увійдуть до power-saving mode, то може не вистачити ресурсів CPU на Secondary VM на виконання завдань синхронно з первинної ВМ;

4) Рівномірно розподіляйте саме Primary VMs - так як саме вони генерують трафік;

На саму ВМ з включеним FT також будуть накладені обмеження. Основні з них:

1) Не працює Hot-plug для віртуальних пристроїв, CPU і RAM;

2) Не можна використовувати Storage VMotion;

3) Не можуть бути використані VMDirectPath I / O для networking I / O devices;

4) Не можуть бути використані віртуальні USB пристрої;

5) Не можуть бути використані Virtual floppy, примонтировать до фізичних пристроїв;

6) Не можна використовувати снапшоти;

VMware FT рекомендований до використання до наступних ВМ:

1) ВМ з додатком з вимогою постійної доступності;

2) ВМ з високим коефіцієнтом використання;

3) Пріоритетно важливі ВМ;

Слід зазначити, що дана служба (FT) недоступна користувачам, що купили пакет Essentials і Essentials Plus.

2.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.

2.4.5 VMware Site Recovery Manager (SRM)

VMware Site Recovery Manager (SRM) - продукт автоматизує процеси аварійного відновлення, створення та тестування планів відновлення після катастроф. Даний продукт пропонує передові можливості управління аварійним відновленням, тестування без переривання роботи та автоматизованого аварійного перемикання.

VMware vCenter Site Recovery Manager підтримує управління аварійним перемиканням на резервні інфраструктури, а також між двома інфраструктурами з активними робочими навантаженнями.

Більше того, можливе відновлення кількох інфраструктур з однієї спільної резервної системи. Site Recovery Manager також допомагає забезпечити планове аварійне перемикання ЦОД, наприклад при їх перенесенні.

Керування аварійним відновленням:

1) Створення та адміністрування планів відновлення безпосередньо з VMware vCenter Server;

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

3) Розширення планів відновлення за допомогою користувацьких сценаріїв;

4) Моніторинг доступності віддалених середовищ і повідомлення користувачів про їх можливі відмови;

5) Зберігання, перегляд та експорт результатів тестування, а також запуск аварійного перемикання з VMware vCenter Server;

6) Управління доступом до планів відновлення за допомогою деталізованих елементів управління доступом на основі ролей;

7) Підтримка рішень по реплікації на основі iSCSI, FibreChannel або NFS;

8) Відновлення декількох середовищ з однієї спільної резервної інфраструктури;

9) Доступ до новітніх можливостям і технологіям VMware vSphere;

Тестування без переривання роботи:

1) Засоби створення знімків забезпечують тестування відновлення без втрати реплікованих даних;

2) Підключення віртуальних машин до існуючих ізольованим мереж для тестування;

3) Автоматизація тестування плану відновлення;

4) Налаштування виконання планів відновлення Уолла тестування;

5) Автоматизація очищення тестових середовищ після тестування;

Автоматизоване аварійне перемикання:

1) Запуск виконання планів відновлення з VMware vCenter Server одним натисканням кнопки;

2) Автоматизація призначення реплікованих сховищ даних для відновлення за допомогою адаптерів, створених провідними постачальниками систем зберігання для своїх платформ реплікації;

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

4) Зміна IP-адрес віртуальних машин відповідно до конфігурації мережі резервної інфраструктури;

5) Адміністрування і моніторинг виконання планів відновлення з VMware vCenter Server.

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

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

1) Експлуатаційна гнучкість;

2) Збільшення віддачі від існуючих ресурсів;

3) Софтверна підтримка;

4) Планування;

5) Скорочення витрат;

6) Відмовостійкість;

Експлуатаційна гнучкість

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

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

Планування

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

Відмовостійкість

При впровадженні віртуалізації, завдяки технологіям VMware, а саме: HA FT DRS і т.д., можливо не тільки зберегти свій рівень відмовостійкості до консолідування ВМ, але і підвищити його. Нижче описані технології забезпечення надійності віртуальної системи, а також шляхи їх впровадження. На ранніх етапах консолідування віртуальних технологій, буде збережений той же рівень надійності, але в подальшим за досить великої інфраструктурі серверного обладнання, дана інфраструктура, заснована на фізичному рішенні, буде поступово втрачати надійність з збільшенням обладнання, в той час як віртуальна буде його завжди утримувати на певному рівні.

Отже, ми розглянули 5 параметрів, що підвищують відмовостійкість системи до максимуму. Такі параметри, як HA, FT і DRS є можливостями платформи, наявність яких залежатиме від комплектації купленого пакету VMware. VM Monitoring присутній у всіх версіях платформ, а SRM є окремим повноцінним продуктом компанії VMWare, який поставляється також з VCenter Server.

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

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

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

1) Використовувати ВПЗ там, де це можливо

2) Досягти максимально можливої відмовостійкості (для обраної конфігурації ПЗ та технічних характеристик)

3) Мінімалізувати матеріально-технічні витрати на побудову мережі

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

Варто зазначити, що будівля офісу підприємства нараховує 32 постійних робочих місця, обладнаних ПК. Також нараховується близько 10 співробітників по території України, котрим потрібен доступ до мережі підприємства з дому.

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

На роль гіпервізора нульового рівня, що буде забезпечувати роботу мережі, були висунуті два кандидати:

1) VMware vSphere ESXi 5.1

2) Proxmox VE 3.0

VMware vSphere ESXi 5.1 - останній реліз флагманської платформи віртуалізації від VMware. Це яскравий представник гіпервізорів першого типу, так званий "bare-metal".

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

1) Мінімальна інсталяція для зменшення ймовірності виходу зі строю та якомога довшої роботи без патчів

2) Незалежність від операційної системи та драйвери, прив'язані до апаратної частини серверу

3) Розширене керування пам'яттю з можливістю де-дублікації та стискання

4) Розширена система управління дисковим простором з інтегрованою кластерною файловою системою

5) Висока масштабованість операцій вводу-виводу для усунення "вузьких місць" цих самих операцій

З огляду на вимогу до коштів, витрачених на побудову мережі, слід привести витримку з ліцензійного договору на vSphere:

"Ліцензія на безкоштовний vSphere Hypervisor дозволяє вам мати необмежену кількість процесорів на сервері, при цьому загальний обсяг сконфігурованої оперативної пам'яті віртуальних машин (VRAM) не може перевищувати 32 ГБ на одному сервері.", що, звісно, є великим плюсом на рахунок vSphere, адже 32 ГБ оперативної пам'яті на сервері під нужди невеликого офісу буде більше, ніж достатньо.

Proxmox 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) Моніторинг навантаження в реальному часі;

3) Бібліотека настановних образів (у локальному/віддаленому сховищі);

4) Підключення до "фізичної" консолі гостьових систем безпосередньо з браузера (по VNC);

5) Об'єднання серверів в кластер з можливістю живої міграції віртуальних машин (без зупинки гостьової системи);

6) Швидке розгортання гостьових систем з шаблонів (доступно лише для OpenVZ);

7) Автоматичне резервне копіювання віртуальних машин.

Має наступні, критичні для нас, недоліки:

1) Оснований на дистрибутиві Debian 7, пакети котрого часто на версію, а то й більше, відстають від останньої стабільної.

2) Не має функції автоматичного відкату віртуальної машини до початкого стану (non-persistant disk або snapshot-rollback).

3) Більш підходить для розгортання пулу серверних віртуальних машин.

З огляду на це, можемо зробити висновок, що для наших нужд більш підходить продукт компанії VMware, а саме VMware vSphere ESXi 5.1.

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

На роль котролеру домену розглядалось два кандидати:

1) Red Hat Enterprise Linux (RHEL 6)

2) Debian 7 Wheezy

Вибір проводився по наступним критеріям:

1) Безкоштовність рішення

2) Простота реалізації та адміністрування

3) Наявність достатньої кількості документації

4) Стабільні версії пакетів та можливість оновлення

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

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

З огляду на це можна зробити висновок, що за основну платформу для налаштування контролеру домену є більш доцільним узяти Debian 7 (Wheezy).

Сам контролер домену буде налаштований на Sabma, а пакет OpenLDAP повністю впорається з роллю сервера Active Directory (далі -- AD).

3.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. Використання цієї зв'язки дозволить віддалено підключатися до корпоративного чату, отримувати новини та завдання, і при цбому не важливо, яким пристроєм ви для цього користуєтесь.

Встановлення операційної системи через мережу має дві найвідоміші реалізації:

1) WDS служба на базі Microsoft Windows Server 2008 R2 Enterprise.

2) LTSP -- безкоштовний сервер терміналів на базі Linux

Вочевидь, доцільніше використовувати LTSP у зв'язці з Debian Wheezy, адже LTSP володіє достатньою кількістю документації і є безкоштовним рішенням.

Також слід зауважити, що для організації інкреметного резервного копіювання даних використовується набір shell-скриптів, об'єднаних у пакет backup-manager.

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

На роль операційної системи для роботи кінцевого користувача були розглянуті три варіанти linux-based дистрибутивів:

1) Ubunut 12.04 LTS

2) Debian 7 (Wheezy)

3) CentOS 6 (thin-client package)

При виборі дистрибутиву враховувались наступні критерії:

1) Дружність користувачу

2) Достатня кількість документації

3) Гарантована підтримка оновлень дистрибутиву

Так як з виходом 1С для linux дистрибутивів необхідність встановлення 1С на сервер терминалів (NX NoMachine, FreeNX, тощо), або використання продукту компанії EterSoft (wine@etersoft) відпала, то клієнтські машини будуть мати повноцінну установку операційної системи, а отже CentOS з встановленним мінімальним пакетом тонкого клієнту вже не є доцільним.

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

Ubuntu 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:

1) Створюємо віртуальну машину

Рис. 3.2 Створення віртуальної машини

2) Вибираємо пункт "custom" для більш тонкої настройки. У наступному вікні вибираємо Workstation 8, яка сумістна з ESXi 5.1

Рис. 3.3 Створення віртуальної машини

3) У наступному вікні вказуємо шлях до iso-образу, заздалегідь викачаного з сайту вендора:


Подобные документы

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

    дипломная работа [6,2 M], добавлен 15.06.2014

  • Фізичне та логічне представлення топології мереж, кабельна система. Вибір мережевого устаткування. Імітаційне моделювання корпоративної комп’ютерної мережі в NetCracker 4.0. Представлення локальної мережі в Microsoft Visio 2013, економічне обґрунтування.

    курсовая работа [993,5 K], добавлен 17.05.2015

  • Обгрунтування фізичної топології комп’ютерної мережі. Розробка схеми фізичного розташування кабелів та вузлів. Типи кабельних з’єднань та їх прокладка. Вибір сервера та інсталяція його програмного забезпечення, налаштування ОС Windows 2008 Server.

    курсовая работа [1,4 M], добавлен 07.02.2016

  • Використання мережі із топологією "розподілена зірка", витої пари та концентраторів (для сполучення), мережевої карти із роз'ємами типу RG-45, встановлення операційної системи та монтаж мережі комп'ютерної лабораторії із підключенням до Інтернету.

    контрольная работа [1,0 M], добавлен 12.06.2010

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

    курсовая работа [5,1 M], добавлен 04.10.2014

  • Побудова апаратної структури для серверу, встановлення операційної системи і програмного забезпечення, розробка веб-сайту. Розрахунок річної суми економічного ефекту від впровадження комп’ютерної мережі. Проектування освітлення, засобів пожежогасіння.

    дипломная работа [5,6 M], добавлен 02.07.2015

  • Створення програмного модуля імітаційного дослідження архітектури комп'ютерних мереж системи "Емулятор мережі" в середовищі Microsoft Visual C # 8.0 Express Edition з використанням технології dotNet. Розробка комплексних лабораторних робіт на її основі.

    дипломная работа [2,2 M], добавлен 26.10.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.