Організація бездискового завантаження Windows-систем з використанням протоколу АоЕ

Размещено на http://www.allbest.ru/

Міністерство інфраструктури України

Державна служба зв'язку України

Кафедра Мереж зв'язку

Випускна робота бакалавра

на тему:

Організація бездискового завантаження Windows-систем з використанням протоколу АоЕ

Одеса 2012

Зміст

Вступ

1. Технологія бездискового завантаження і протокол АоЕ

1.1 Опис впроваджуваної технології

1.2 Вимоги замовника до проекту

2. Розробка стратегії впровадження та реалізації проекту

3. Установка і налаштування сервера з використанням протокола АоЕ

3.1 Установка і налаштування сервера

3.2 Налаштування клієнтів Windows

Висновки та пропозиції

Додаток А

Вступ

Розвиток обчислювальної техніки відбувається все більш стрімкими темпами. Якщо ще років 10 тому ПК з пів-гігабайтом оперативної пам'яті здавався мало не межею мрій, то сьогодні 512Мб в домашньому комп'ютері вже якось замало. Частоти процесорів, оперативної пам'яті і обсяги жорстких дисків також продовжують збільшуватися. Два-три роки, що минули з початку експлуатації комп'ютера, автоматично переводять його в категорію морально застарілої техніки. Однак моральне старіння зовсім не означає фізичне. Для цього досить зробити їх «тонкими клієнтами» служби терміналів. Перевага такої технології в тому, що на «апаратні плечі» клієнта при цьому не лягає майже ніякого навантаження, адже весь обчислювальний процес відбувається на стороні сервера. Таким чином, маючи в розпорядженні досить потужний сервер, можна використовувати вже існуючі низькопродуктивні комп'ютери для виконання завдань, з якими вони в інших конфігураціях впорається вже не в змозі. Найбільший ефект від застосування терміналів досягається в умовах забезпечення роботи великої кількості користувачів, які виконують однотипні завдання, наприклад, навчальні класи або робочі офісні місця. Продуктивність такої системи буде залежати тільки від потужності ресурсів сервера терміналу. Клієнт може працювати навіть без жорсткого диска і знімних носіїв, здійснюючи завантаження ОС по мережі. Така конфігурація дозволяє підвищити надійність роботи в цілому, адже всі дані будуть зберігатися на сервері, де ймовірність втрати або пошкодження даних на порядки нижче, ніж на локальних комп'ютерах. Зберігання даних на сервері значно спрощує їх резервування. Можна навіть заощадити на джерелах безперебійного живлення, адже відключення терміналу або його повний вихід з ладу не призведе до незворотних втрат інформації. Значно спрощуються завдання адміністрування. Програми необхідно встановлювати і виконувати їх оновлення лише на сервері - зміни термінального сервера позначаються одночасно на всіх робочих місцях. Відсутність на терміналі знімних носіїв, підвищує безпеку і дозволить економити на антивірусному забезпеченні, зніме необхідність контролю установки користувачами несанкціонованого ПЗ і можливість витоку конфіденційної інформації. Налаштування програмного забезпечення терміналу вимагає значно менше часу і зусиль, ніж розгортання локальних копій ОС.

1. Технологія бездискового завантаження і протокол АоЕ

бездисковий windows адміністрування сервер

1.1 Опис впроваджуваної технології

Поява Інтернету послужило появі бездискового завантаження. Централізована модель досить зручна (наприклад клієнт-серверна). Бездискове завантаження з'явилося на початку 90-х років.

2 етапи розвитку бездискового завантаження:

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

- Другий етап розвитку з'явився в 2002 році і продовжується до сьогодні.

Основні переваги при роботі без жорстких дисків:

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

Існують спеціалізовані робочі станції:

- JavaStation

2) Простота обслуговування. Отримуємо централізацію всіх операцій управління і створення резервних копій

3) Сукупна вартість володіння системою. Сюди входить вартість апаратних комплектуючих, години витрати часу адміністрування, програмістів, інженерів.

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

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

Реалізація бездискового завантаження.

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

2 групи вузлів:

- Один або кілька серверів бездискового завантаження;

- Сукупність бездискових клієнтів.

Під бездисковим клієнтом будемо мати на увазі комп'ютер, чия початкова загрузка виконується з деякого файлу, доступного по мережі і яке використовує файлові системи, що надаються через мережевий доступ по одному з відповідних протоколів: NFS всіх версій і протокол SMI, АоЕ.

ATA overEthernet (AoE) - це мережевий протокол, зареєстрований IEEE як Ethernet-протокол номер 0x88a2. AoE це низькорівневий протокол, набагато більш простий ніж TCP / IP або навіть просто IP.

AoE є відкритим стандартом на основі протоколу, який забезпечує прямий доступ до мережі для дисків, клієнтів хостів, таких як веб-сервери, поштові сервери, або кластер серверів. Ці системи можуть використовувати протокол AoE для доступу до як завгодно великих масивів AoE серверів за рахунок використання комутаторів. AoE сервери можуть бути невеликі процесори і диски на невеликій монтажній платі підключеної до невеликої стійки встановленої на шасі. Ці плати, називаються «blades».

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

Протокол складається із запиту повідомлень, відправлених на сервер AoE і відповідних повідомлень які повертаються до хоста. Деякі повідомлення містять ATA команди, і будь-які дані, пов'язані з транзакцією. Інші повідомлення відносяться до Config / Query особливість протоколу, щоб встановити і запросити невелику кількість outofband даних. Формати цих повідомлень є простими і мають дві форми: ATA повідомлення і Config / повідомлення запиту. Обидві мають загальний формат заголовка, який полегшує доставку по мережі. Структура роботи відображає структуру протоколу.

Загальний заголовок. У той час як два класи повідомлень, ATA і Config / Query, у кожного є свої поля, вони обидва мають загальний формат протягом перших 24 байт повідомлення. Цей загальний заголовок дає достатньо інформації для передачі повідомлень між хостами і AoE серверами. Загальний заголовок складається з чотирьох функцій. По-перше, це дає можливість співвіднести відповіді з запитами. По-друге, це дає можливість відкрити для себе Ethernet. По-третє, загальний заголовок визначає запити з відповідями. Нарешті, заголовок містить інформацію про помилки.

AoE повідомлення можуть бути поставлені в чергу в AoE серверів. Це дозволяє дискам залишатися зайнятими. AoE використовує всі зусилля Ethernet-доставки, а також програмне забезпечення клієнтського хоста відповідає за повторну відправку повідомлень запитів, які не відповіли в задану кількість часу. Для пошуку відповідей з проханнями і перевірку відповіді, яку ніколи не було отримано, клієнтський хост може використовувати тег області.

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

Наступна функція дає можливість знайти конкретні сервери AoE. Вони вставляються в слоти в невеликій полиці. Загальний заголовок має поле, щоб допомогти відстежувати blades на місцях. Кожна полиця має DIP-перемикачі надаючи йому неповторну індивідуальність. Кожний blade може прочитати ці DIP-перемикачі, а також його номер слота. Ці два числа представлені в загальній заголовка полиці. (У специфікації AoE вони називаються старший і молодший номера). Ці поля можуть бути використані, щоб знайти Ethernet-адресу конкретного blade. Це робиться з повідомленнями Ethernet мовлення. Ethernet має зарезервовану адресу, що складається з усіх тих, для широкомовних повідомлень для всіх пристроїв в сегменті локальної мережі. AoE протокол вимагає, що бтільки ті повідомлення, які мають свої унікальні шельф та номер слота бути оброблені, скинувши всі інші. Якщо ми хочемо знайти Ethernet-адресу blade, скажімо, полку 6 слотів 4, ми будемо транслювати повідомлення з шельфу і слот полів на 6 і 4 відповідно.

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

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

Нарешті, Class або Cmd як це називається в специфікації AoE, містить нуль повідомлень ATA і один для Config / Query повідомлень.

ATA класи повідомлень. Додаткові дані технології стандарту, який розвинувся з інтерфейсу ST506 і Western Digital 1010 дискового контролеру чіпа початку 1980-х. Ці чіпи були впроваджені в хост-адаптери (HBA), які використовується в IBM Personal Computer сумісних систем.

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

Наприклад, у випадку команди читання, дані будуть передаватися з диска в буфер від HBA, і HBA буде повідомляти приймаючій стороні ці дані, які були доступні для читання. Хост буде тоді переміщати дані в своїй локальної пам'яті.

З появою в диск Electronics (IDE), контролер функція була перенесена з HBA на сам диск. Специфікації швидкість передачі даних між внутрішнім буфером і пам'яті хоста була збільшена в декілька разів. Все це було, нарешті, кодифіковано в Advanced Technology. Додаток або ATA стандарт. ATA стандарт включає в себе як фізичні з'єднання з приводом логічний інтерфейс.

Оригінальний параметр реєструє використанням тривимірних координат у вигляді циліндра, були замінені на 24-розрядну адресу логічного блоку (LBA). З диска розглядаються як 512 байт сектори, 24 біт LBAs обмеження дисків 137GB. Коли диски перевищили цю межу була прийнята 48-бітна адресація. Це було досягнуто за рахунок додавання нових 48-бітових команд і дозволяє старим параметрам реєструвати в подвійному завантажені. Тобто, можна зберігати два значення в тому ж регістрі, і обидва значення будуть використовуватися в якості частини адреси. AoE також дозволяє використовувати 48-бітний LBA команди, що дозволяє дискам 144, 115 ГБ, чого повинно бути достатньо на деякий час.

ATA повідомлення містять запити і відповіді для виконання операції АТА. В ATA є три можливості: дані не будуть передані дані будуть записані на диск, або дані зчитуються з диска. Нульовий параметр в регістрах вказує, яка із цих операцій буде відбуватися. Коли прапор W в повідомленні ATA встановлюється в 1 це означає, що буде передача на диск.

Рисунок 1.1 Заголовок ATA

Повідомлення ATA містить значення яке знаходиться в регістрі і прапорі поля управління, які використовують значення. Якщо біт E Aflags дорівнює нулю, 24-бітна адресація використовується. LBA значення копіюється на адресу регістрів, функції і значення сектора кількості копіюються у відповідні реєстри. Остання команда копіюється в регістр команд. Сервер AoE стежить за станом регістра, і після завершення команди, копіює всі параметри з регістра в заголовок відповіді. Помилка регістра переходить в ERR функції поля та стану регістра копіюються в Cmd статус області. Відповідь ATA повідомлення буде містити значення стану і помилок регістрів, разом з будь-яким залишком параметра регістрів. Оскільки ATA команди переносяться Ethernet, а так як є обмеження на розмір кадру в мережі Ethernet, ми не можемо послати більше двох секторів по 512 байт в одному повідомленні. Це означає, що кількість секторів буде менше або дорівнюватиме двом. Навіть з 1GE і 10GE Jumbo Frames, ми не можемо рухатися більше, ніж 8192 байт, або 16 секторів. Так, в 48-бітному режимі, ми не переходимо з верхнього байт сектора. Це може здатися надмірно обмежувальними, але NFS-клієнт чутливий до кількості нульових бітів які кодуються в протоколі.

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

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

На кожному сервері AoE є невелика кількість енергонезалежної пам'яті, яка може бути використана клієнтом сервером для збереження даних конфігурації. Ця конфігурація даних може бути довільним двійковим значенням, і має довжину до 1024 байт. Ця інформація не має ніякого значення на сервер AoE, це просто місце для хостів, щоб заховати інформацію. Ці дані не зберігаються на диску, щоб уникнути будь-якої взаємодії з будь-яким сервером програмного забезпечення. Диски з хостів, наприклад, можуть бути переміщені на сервер AoE і як і раніше доступні, без того, щоб реформувати інформацію. Config / Query повідомлення використовують ці дані в двох напрямках. По-перше, конфігураційні дані можуть бути умовно або безумовно встановлені. По-друге, існують різні способи для запиту даних.



Рисунок 1.2 Заголовок Config / Query

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

Останній запит вимагає точної відповідності збереженої інформації. Дані в заяві та дані на сервері повинні співпадати як за змістом, так і по довжині. Це корисно для трансляції запитів для конкретного сервера AoE.

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

AoE - «ATA overEthernet» - протокол інкапсуляції звичайних ATA-команд в Ethernet-фрейми. Інкапсуляція ведеться саме в Ethernet-фрейми, а не в IP-пакети, тобто протокол працює на мережевому рівні. Даний протокол працює поверх Ethernet, і в загальному випадку не вимагає протоколів TCP / IP. Замість того щоб покладатися на TCP / IP, він покладається на можливості сучасних комутаторів, у яких не буває колізій, є можливість управління потоком і постійно зростає продуктивність. У локальній мережі зберігається послідовність пакетів і для кожного пакета мережевим обладнанням обчислюється контрольна сума. Хоча це має і недолік - AoE не пустиш через Інтернет (без додаткової інкапсуляції). У кожному AoE пакеті знаходиться команда для ATA-диска або відповідь від ATA-диска. Драйвер AoE в ядрі Linux виконується AoE і робить диск доступним як звичайний блоковий пристрій, так, наприклад, як / dev/etherd/e0.0 - точно також як IDE-драйвер робить диск, підключений до кінця IDE-кабеля, доступним як / dev / hda. Драйвер, якщо потрібно, ретранслює пакети, так що AoE-пристрій виглядає для решти ядра як звичайний диск.

Протокол Аое забезпечує непогану швидкодію і низьку вартість. З інших плюсів протоколу - працює з будь-яким UNIX пристроєм, фактично з будь-яким файлом, дуже невимогливий до ресурсів, підтримується на багатьох ОС - в Linux, OpenBSD і Plan9 вбудований, а щонайменше для Windows і FreeBSD є драйвери. Є у нього і недоліки. Це в першу чергу відсутність механізмів забезпечення безпеки, так як ATA протокол інкапсулюється в Ethernet кадри. З цієї ж причини неможлива маршрутизація (тобто AoE може працювати тільки в межах однієї локальної мережі). Немає в AoE ніякої перевірки на помилки (і тим більше відновлення), крім тієї що є в самому протоколі Ethernet. Ну і через особливості реалізації не можна розбивати Ethernet кадри (що для локальної мережі практично завжди виконується) .

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

З особливостей протоколу, випливає як краще його використовувати. Для сервера (або групи серверів) краще мати виділену мережу Ethernet з окремою мережевою картою, зі швидкістю не менше 1 Гбіт. Сервер буде грати роль клієнта протоколу AoE і дуже зручно використовувати під віртуальною машиною. В дану ж мережу буде включатися пристрій, що зображує сервер AoE, на якому буде знаходитися дисковий масив. У загальному випадку цей масив виду RAID5 або RAID10. З цього дискового масиву «віртуальні» «жорсткі диски» будуть монтуватися на сервері.

AТAoE базується на двох точках:

1. ATAoE Target (vblade). Демон, який експортує локальні блочні пристрої, або навіть, файли, прямо в Ethernet. Цей демон ставиться на кожен сервер, який буде виступати в ролі Storage і надавати свої блокові пристрої для всього кластера. Доступний як vbladepackage проекту AOE Tools.

2. ATAoE ініціатор. Модуль ядра «aoe» і супутні утиліти - AOE Tools. Ставиться на боці кожної ноди кластера та імпортує блокові пристрої з Ethernet як локальні блочні пристрої. На додаток до ATA командам, у AoE є проста можливість ідентифікації доступних пристроїв за допомогою конфігураційних опитувальних пакетів (queryconfigpackets). Це все: ATA команди і конфігураційних опитувальні пакети.

1.2 Вимоги замовника до проекту

Компанія замовник, яка має мережу на 120 комп'ютерів вирішила заощадити на комплектуючих,обмежити кількість з'єднань, роз'ємів, шин,отримати централізацію всіх процесів управлінь. Також замовник хоче щоб ми зменшили витрати на постійну модернізацію комп'ютерів під зростаючі вимоги нових операційних систем, один раз поставили систему, відповідно налаштували, сформували з цієї системи образ і розмістили його на мережному ресурсі. Ці вимоги є основними. Також компанія хоче щоб система була розгорнута швидко. Так як фірма має обмежений бюджет і не може собі витрачувати великі суми грошей на програмне забезпечення і його установку, яка проводиться спеціалістами в галузі адміністрування комп'ютерних систем. Для цього ми організуємо бездискове завантаження Windows-систем з використанням протоколу АоЕ. Протокол АоЕ забезпечує непогану швидкодію і низьку вартість. З інших плюсів протоколу - працює з будь-яким UNIX пристроєм, фактично з будь-яким файлом, дуже невимогливий до ресурсів, підтримується на багатьох ОС - в Linux, OpenBSD і Plan9 вбудований, а щонайменше для Windows і FreeBSD є драйвери. Організовуючи бездискове завантаження ми отримаємо здешевлення вартості робочої станції, збільшення терміну служби, підвищення інформаційної безпеки, зниження часу простою робочої станції внаслідок відмови, легкість і централізованість адміністрування

Потрібно: налаштувати сервер на базі операційної системи FreeBSD 9.0,

клієнтських машин на базі операційної системи MS Windows 2003. Установити ОС сервера, яка виконується звичайним способом за винятком невеликої деталі: в нашому випадку, для розміщення файлових систем клієнта, відводяться дві окремі партіції, одна призначається "тільки для читання", інша для "читання-запису». Також потрібно установити і налаштувати DHCP-сервер, TFTP-сервер, АоЕ-сервер.

2. Розробка стратегії впровадження та реалізації проекту

Поява Інтернету послужило появі бездискового завантаження. Централізована модель досить зручна (наприклад клієнт-серверна). Бездискове завантаження з'явилося на початку 90-х років.

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

Сервер бездискового завантаження виконує кілька функцій:

- Перш за все, видача бездисковому клієнту ip-адреси та деяких інших параметрів протоколу мережевого стека по протоколу DHCP.

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

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

Етапи завантаження бездискового клієнта:

1) Широкомовна розсилка бездисковим клієнтам DHCP запиту DHCP DISCOVER.

BIOS перевіряє працездатність всіх пристроїв в системі. У загальному випадку визначається завантажувальний пристрій, в нашому випадку завантажувальний пристрій це не жорсткий диск, а мережевий адаптер з підтримкою функцій бездискового завантаження. Ці функції описані в специфікації PXE_Preboot Exemtion Envitonment. В ньому є запам'ятовуючий пристрій, в якому зашиті функції, що дозволяють сформувати запит на отримання ip-адреси, вказує параметри і відправляє запит до сервера (DHCP DISCOVER).

2) DHCP OFFER. У загальному випадку такий запит звичайно надсилається не більше 4-х разів. Інтервали між запитами складають 4,8,16,32 с.

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

Завантажувачів є декілька:

- Pxeboot (onlyFreeBSD);

- Grub (Linux) завантажує систему жорсткого диска і систему віддаленого диска;

- Syslinux.

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

Необхідно поставити один з завантажувачів на клієнтську робочу станцію. Для цього використовується TFTP протокол.

4) Запит цільового завантажувального файлу на TFTP сервер. Ми взяли файл, розпакували його і завантажуємо в оперативну пам'ять. Будемо завантажувати образ за протоколом АоЕ. Завантажувач визначає де знаходиться кореневий файл системи, монтує її на клієнтську частину. Ядро завантажується в ОС, визначає всі пристрої, завантажує драйвера. У разі завантаження Windows використовуються протоколи доступу до мережевих ресурсів ISCSI, AoE. А завантажувач Etherboot.

5) Монтування кореневої файлової системи.

ATA overEthernet (AoE) - це мережевий протокол, зареєстрований IEEE як Ethernet-протокол номер 0x88a2. AoE це низькорівневий протокол, набагато більш простий ніж TCP / IP або навіть просто IP.

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

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

На даний момент доступні GPL-драйвера для Linux 2.4, 2.6. У пакет ПО входять як модулі (aoe-2.4.XX/aoe2.6.YY), так і утиліти (aoetools) з віртуальним наносервером (vblade). З січня 2005 року AoE-драйвери включені в поставку Linux-ядер версії 2.6. Також на сьогоднішній день готові порти для BSD-систем. В Linux 2.6 драйвера AoE, спеціальні файли знаходяться в каталозі / Dev / etherd. Імена цих файлів пов'язують їх з конкретними фізичними місцями blades AoE. Ім'я, наприклад, для blade полиця 3, слот 6 буде / dev/etherd/e3.6, а другий розділ на тому, що blade буде/ Dev/etherd/e3.6p2. Це дозволяє дуже простим способом управляти blades в мережі.

Крім того, є кілька символів спеціальних файлів в каталозі. Поточний стан AoE blade може бути перерахований на читання файлу / Dev / etherd / статусу.

Суть завантаження бездискових системи по мережі в тому, щоб на етапі завантаження машини передати їй по мережі ядро ??FreeBSD. Handbook у зв'язку з цим згадує два способи:

Preboot eXecution Environment (PXE) реалізований в Intel-та деяких інших мережевих картах.

Etherboot - формує програми, які можуть бути виконані в середовищі MS-DOS або записані в ПЗУ мережевих карт. В якості альтернативи, не згаданої в handbook, при бажанні можливо використовувати проект netboot - брат etherboot з боку Linux. Детальніше cм. систему портів net / etherboot, net / netboot і сайти розробників.

Обидва варіанти: PXE і etherboot користуються BOOTP або DHCP, за допомогою яких отримують необхідну інформацію про мережеві адреси. Різниця між цими способами полягає в тому, що etherboot, використовуючи TFTP або AoE, цілком викачує з сервера і завантажує ядро ??FreeBSD, а PXE спочатку по протоколу TFTP отримує незрівнянно меншу за розмірами програму pxeboot, яка потім вже сама по AoE або TFTP забезпечує завантаження ядра системи.

Еtherboot набагато легше, ніж netboot налаштувати для завантаження ядра FreeBSD, а PXE, в свою чергу, ще простіше, оскільки взагалі не потрібно встановлювати додаткового програмного забезпечення.

Далі ядро ОС бездискового клієнта монтує корінь своєї файлової системи на AoE-ресурсі сервера і викликає / sbin / init (або те, що його може замінити init.bak, oinit, sysinstall), монтує devfs в каталог / dev, виконує скрипт / etc / rc і для відповідних термінальних пристроїв з файлу / etc / ttys породжує процеси getty.

Скрипт / etc / rc, який завершує цикл завантаження і запускає основні демони системи, варто відзначити окремо. Для даного способу завантаження бездискових клієнтів, скрипт / etc / rc важливий ще й тим, що вході його виконання буде проведена "підміна" однією з файлових систем. Справа в тому, що заради економії місця на диску сервера, кореневу файлову систему ми зробимо загальної для всіх бездискових клієнтів, тому логічніше всього монтувати її в режимі "тільки для читання". Відповідно, каталог / etc для всіх бездискових станцій виявиться, на жаль, одним і тим же і до того ж буде доступний тільки для читання. Тому, щоб забезпечити гнучкість створення індивідуальних для кожного клієнта директорій / etc, закладемо в rc-скрипт операцію з монтування кожної бездискової станції свого / etc, доступного для читання і запису. Аналогічних цілей можна досягти, застосувавши стандартні rc-скрипти FreeBSD. Проте, в цьому випадку / etc буде розміщуватися у віртуальній пам'яті комп'ютера, що на мій погляд не дуже добре, оскільки для бездискових станцій основним, і часто дефіцитним ресурсом є саме оперативна пам'ять. Докладніше можна дізнатися, вивчивши скрипти завантаження FreeBSD 5.2.1 / etc / rc.d / initdiskless та / etc / rc.d / diskless.

Настройка самої бездисковой станції вимагає мінімальних зусиль і полягає лише в установці в її корпус мережевої карти з підтримкою специфікації PXE. Далі, в залежності від конкретних особливостей обладнання станції, залишається вказати тільки правильний порядок завантаження, тобто вибрати завантаження з LAN. Це звичайно робиться або в BIOS комп'ютера, або в меню самої мережевої карти. На тестовій станції, BIOS якої, не підтримував завантаження через мережу, мені довелося проводити настройку через меню мережевої карти. Для того щоб потрапити в меню мережевої карти потрібно на етапі завантаження комп'ютера натиснути Crtl + S.

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

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

Установка самої ОС сервера виконується звичайним способом за винятком невеликої деталі: в нашому випадку, для розміщення файлових систем клієнта, відводяться дві окремі директорії, одна призначається "тільки для читання", інша для "читання-запису». У нашому випадку ми будемо монтувати ці директорії в наступні каталоги кореневої файлової системи сервера: / Diskless_ro або / Diskless_rw

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

Установка і налаштування DHCP-сервера.

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

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

Для настройки сервера DHCP під FreeBSD скористаємося продуктом ISC DHCP (isc-dhcp3), який також підтримує і протокол BOOTP. ISC DHCP не входить в дистрибутив FreeBSD, тому його доведеться інсталювати з пакетів, портів або вихідних текстів.Оскільки при описі AoE-сервера ми домовилися, що кожному бездискового клієнту будемо надавати AoE-ресурс для запису, то час від часу міняти IP-адреси бездискових станцій стає просто не коректно, тому в конфігурації DHCP-сервера нам доведеться відмовитися від динамічного розподілу адрес, і використовувати ISC DHCP для клієнтів BOOTP. На цьому етапі в BIOS вашого комп'ютера першим пунктом повинна стояти завантаження з диска - для мережевої завантаження ще не настав час.

TFTP-сервер під FreeBSD входить в дистрибутив і ніякого додаткового програмного забезпечення встановлювати не потрібно. Демон називається tftpd і зазвичай запускається з inetd.

Запускається vblade дуже просто # Vblade {SHELF} {SLOT} {NETIF} {FILE}

{SHELF} - логічний «номер» сервера, на якому встановлений vblade (1 і більше), наприклад, 1

{SLOT} - логічний «номер» блочного пристрою для експорту (від 0 до 15 кшталт), наприклад, 0

{NETIF} - інтерфейс для експорту, наприклад, eth0

{FILE} - звичайний файл або блочне пристрій, який буде експортуватися в Ethernet. Наприклад, / dev / sdb. Можна так само експортувати розділ диска (/ dev/sdb1) або навіть звичайний файл (/ home / usr / file.dat)

Загрузочний образ ОС - фактично це вміст вашого завантажувального розділу, але перенесений на віртуальний диск. Отже, для початку на серверній машині створіть за допомогою BXP Administrator віртуальний диск.

Робиться це так: Спочатку домонтують новий диск (найпростіший спосіб зробити це - вибрати диск і натиснути). Тепер цей віртуальний диск «примонтувати» у віртуальний те, який з'явився у вас на сервері (крім диска з ліцензіями). Врахуйте, що "меппінг" працює тільки при запущеному BXP Administrator. Тепер відформатуйте цей диск самим звичайним для Windows способом і отмонтіруйте його назад. Тепер диск готовий для запису образа.

Наступний крок вимагатиме уважності: Ми створюємо еталонний образ системи для безхардових машин. Створіть нового клієнта на сервері - можете вказати для нього фіксований MAC-адресу (якщо не знаєте - ставте знаки питання), якщо хочете обмежити завантаження тільки певними робочими станціями. Вкажіть у налаштуваннях тип завантаження З жорсткого диска. Перезавантажте клієнтську машину, увійдіть в BIOS і першим номером поставте завантаження по мережі. Тепер з перезавантаження ви повинні побачити опитування DHCP та отримання "п'яти точок". Насправді кожна точка відповідає за отримання певної опції настройки - як з'ясувалося з вихідного коду PXE BIOS.

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

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

3. Установка і налаштування сервера з використанням протоколу АоЕ

3.1 Установка і налаштування сервера

Основні налаштування DHCP-сервера зберігаються у файлі / usr / local / etc / dhcpd.conf. Редагуємо його щоб скласти просту конфігурацію. Оскільки в нашому прикладі всього одна підмережа і один сервер бездискових клієнтів, можна сміливо виносити майже всю інформацію в розділ глобальних параметрів.

Установку з портів можна зробити так:

server # cd / usr/ports/net/isc-dhcp3 &&makeinstallclean

Редагуємо файл dhcpd.conf:

Лістинг

authoritative;

# Сервер авторитетний для своєї підмережі

ddns-update-style none;

# Відмовляємося від динамічного оновлення DNS

use-host-decl-names on;

# Видавати клієнтам "hostname", яке зазначено в поле host

optionrouters 192.168.1.1;

# Зазначимо маршрутизатор за замовчуванням

next-server 192.168.1.2;

# Тут вказується сервер, з якого береться boot-файл

filename "pxeboot";

# Власне boot-файл, який читається з next-server

option root-path "192.168.1.2 :/ diskless_ro";

# Тут буде корінь файлової системи клієнта

subnet 192.168.1.0 netmask 255.255.255.0 {}

# Описуємо підмережу. Динамічного розподілу адрес

# Не буде, і тут теж не буде ніяких опцій. Однак, прибрати

# Опис підмережі не можна, інакше DHCP-сервер не завантажиться

# Опис бездискових станцій: для кожного клієнта

# Вказуємо ім'я хоста, його IP і MAC адреси

host diskless-1 {

# Ім'я хоста, яке через "use-host-decl-names on" буде

# Передано клієнтові в якості його hostname

hardwareethernet 00:0 D: 9D: 8B: BB: 48;

# MAC-адресу мережевої карти бездискового клієнта.

fixed-address 192.168.1.11;

# IP-адресу, який призначається клієнту.

}

...

host diskless-80 {

hardwareethernet 00:0 C: 29:74:2 B: 35;

fixed-address 192.168.1.90;

}

...

host diskless-120 {

hardwareethernet 00:02: B3: 8A: D6: BF;

fixed-address 192.168.1.130;

}

Тепер можна стартувати DHCP-сервер:

server # / usr / local / sbin / dhcpd start

І якщо завантаження пройшло вдало, отримаємо подібну відповідь:

Лістинг

Internet SoftwareConsortium DHCP Server V3.0.1rc12

Copyright 1995-2003 Internet SoftwareConsortium.

Allrightsreserved.

Forinfo, pleasevisit http://www.isc.org/products/DHCP

Wrote 0 deletedhostdeclstoleasesfile.

Wrote 0 newdynamichostdeclstoleasesfile.

Wrote 0 leasestoleasesfile.

Listeningon BPF/fxp0/00: 0c: 29: f8: 78: fc/192.168.1.0/24

Sendingon BPF/fxp0/00: 0c: 29: f8: 78: fc/192.168.1.0/24

SendingonSocket / fallback / fallback-net

Залишається тільки додати виклик DHCP в автоматичне завантаження сервера:

Server cd / usr / local / etc / rc.d

Server mv isc-dhcpd.sh.sample isc-dhcpd.sh

Server chmod 755 isc-dhcpd.sh

Установка і настройка TFTP-сервера

Бездисковий клієнт разом зі своїм IP-адресою отримує від DHCP-сервера ще 3 важливих для завантаження параметри:

option root-path - місце розташування своєї кореневої файлової системи на віддаленому AoE сервері.

next-server - адреса сервера, з якого по протоколу TFTP слід отримати файл, необхідний для продовження завантаження.

filename - файл який необхідно завантажити з next-server.

Параметр root-path потрібно трохи пізніше при завантаженні ядра і монтуванні кореневої файлової системи. А поки, PXE мережевої карти бездисковой станції, саме два останніх, з перерахованих вище параметрів, автоматично спробує використовувати для продовження завантаження. Файл pxeboot (8) є зміненою версією завантажувача loader (8), що працює на 3-му етапі завантаження FreeBSD. Оскільки бездисковий клієнт очікує отримати цю програму по протоколу TFTP, то його слід налаштувати на сервері 192.168.1.2.

Тому для того, щоб запустити TFTP-сервер, ми просто створимо спеціальний каталог / tftpboot і запишемо туди pxeboot.

Створимо спеціальний каталог / tftpboot і запишемо туди pxeboot:

server # mkdir / tftpboot

server # cp / boot / pxeboot / tftpboot

задамо відповідний рядок в / etc / inetd.conf:

tftpdgramudpwaitroot / usr / libexec / tftpd tftpd-l-s / tftpboot

Тут опція-l включає логування операцій,-s встановлює каталог, який є кореневим для tftpd після виконання ним виклику chroot ().

Сервер настроєний, залишається тільки перезапустити демон inetd: server # killall-HUP inetd

Якщо все пройшло успішно, команда: server # sockstat-4l | grep 69

Поверне схожий результат: rootinetd 556 5 udp4 *: 69 *: *

Установка і настройка AoE-серверу.

Для роботи необхідно поставити AoE драйвери на FreeBSD 9.0 по замовчуванню вони не інстальовані.

Встановимо драйвер AoE на FreeBSD.

# cd /usr/ports/net

# fetch http://www.son.org/download/aoe-kmod.tgz

# tarxvzf aoe-kmod.tgz

# cdaoe

# makeinstall

Після того, як завантажувач pxeboot буде успішно викачаний по TFTP, він, керуючись опцією "root-path" спробує по протоколу AoE звернутися до каталогу / diskless_ro сервера 192.168.1.2, так, як вважатиме що, там міститься коренева файлова система з ядром операційної системи бездисковой станції.

Тут необхідно зробити наступне зауваження: що pxeboot може бути також налаштований для завантаження ядра по протоколу TFTP, що дозволить завантажувати різним бездискових станцій різні версії ядер. Правда щоб це здійснити, необхідно перекомпілювати pxeboot з опцією LOADER_TFTP_SUPPORT = YES, зазначеної у файлі / etc / make.conf сервера. Докладніше про це див в handbook і у файлі / usr / share / examples / etc / make.conf.

Зробимо загальну для всіх директорію / diskless_ro доступною режимі "тільки для читання", а в / diskless_rw розташуємо каталоги, індивідуальні для кожного IP-адреси станції, так щоб кожен бездисковий клієнт зміг виробляти туди запис. У таких каталогах для кожної робочої станції, в свою чергу, необхідно створити піддиректорії etc і var. Наприклад, станція буде мати власний каталог: / diskless_rw/192.168.1.11 і два підкаталогу / diskless_rw/192.168.1.11/etc та / diskless_rw/192.168.1.11/var. Таким чином, каталог / diskless_ro буде поки порожній а / diskless_rw на цьому етапі буде мати наступну структуру:

/ Diskless_rw/192.168.1.11

/ Diskless_rw/192.168.1.11/etc

/ Diskless_rw/192.168.1.11/var

...

/ Diskless_rw/192.168.1.90

/ Diskless_rw/192.168.1.90/etc

/ Diskless_rw/192.168.1.90/var

...

/ Diskless_rw/192.168.1.130

/ Diskless_rw/192.168.1.130/etc

/ Diskless_rw/192.168.1.130/var

Крім того, бездискові станції, в режимі "тільки для читання" будуть користуватися серверної файлової системою / usr.

Для того, щоб дозволити бездискових станцій безперешкодно користуватися всіма цими каталогами, необхідно відповідним чином налаштувати AoE -сервер.

Розміщувати diskless_rw і diskless_ro на одному фізичному файлової системи не рекомендується, оскільки AoE експортує клієнтові не каталог, а файлову систему цілком. В / etc / exports кожен рядок являє собою опис експорту однієї файлової системи сервера одному або кільком клієнтам. Причому для кожної експортованої файлової системи, один і той же клієнт може бути зазначений тільки один раз.

Наприклад, якщо / diskless_rw та / diskless_ro різні файлові системи, то такий / etc / exports буде правильним:

/ diskless_rw 192.168.1.11

/ diskless_ro-ro 192.168.1.11

Для цього в файл / etc / exports необхідно помістити наступні рядки:

Лістинг

# Файлові системи доступні для читання:

/ usr-ro-maproot = 0-network 192.168.1.0-mask 255.255.255.0

/ diskless_ro-ro-maproot = 0-network 192.168.1.0-mask 255.255.255.0

# Файлові системи доступні для запису

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

# Diskless-1

/ diskless_rw/192.168.1.11/etc / diskless_rw/192.168.1.11/var-mapall = root 192.168.1.11

...

# Diskless-80

/ diskless_rw/192.168.1.90/etc / diskless_rw/192.168.1.90/var-mapall = root 192.168.1.90

...

# Diskless-120

/ diskless_rw/192.168.1.130/etc / diskless_rw/192.168.1.130/var-mapall = root 192.168.1.130

Зробимо Vblade автозапуск при старті системи за допомогою RC скрипта /etc/init.d/vblade.vblade0

Позначимо, що будемо експортувати (EXPORTS).

У файлі / etc / exports визначають, які файлові системи на вашому сервері будуть експортуватися. Кожен рядок у файлі задає файлову систему, яка буде експортуватися і які машини будуть мати до неї доступ.

Вийшли 2 виконуваних файла - vblade і vbladed. Останній є звичайним скриптом, який запускає vblade. Його конструкція нагадує нижче наведений варіант:

Vblade 9 0 eth0 / dev / hda1

mount /dev/etherd/e9.0 /mnt/tmp

де «9» - номер шасі, «0» - номер слота (диска), «eth0» - назва інтерфейсу, за яким буде відбуватися обмін даними та «/ dev / hda1» - власне пристрій, який в форматі «AoE» робиться доступним поethernet.

Зробимо Vblade автозапуск при старті системи за допомогою RC скрипта /etc/init.d/vblade.vblade0

# /etc/init.d/vblade.vblade0 start

# rc-updateadd vblade.vblade0 default

Тепер позначимо, що будемо експортувати (EXPORTS).

У файлі / etc / exports визначають, які файлові системи на вашому сервері будуть експортуватися. Кожен рядок у файлі задає файлову систему, яка буде експортуватися і які машини будуть мати до неї доступ. Нам потрібно розшарити директорію / home / share.

Для цього в / etc / exports додамо.

/ home / share-ro-alldirs-maproot = root 192.168.1.11 host. diskless-1.local

…

/ home / share-ro-alldirs-maproot = root 192.168.1.90 host. diskless-80.local

...

/ home / share-ro-alldirs-maproot = root 192.168.1.130 host. diskless-120.local

/ home / share - Директорія для доступу.

-alldirs - Дозволяє монтувати будь підкаталог; за замовчуванням дозвіл видається

тільки для зазначеного каталогу.

-maproot = юзер - Закріплює ідентифікатор облікового запису root за вказаним користувачем

(це може бути значення UID або ім'я). За замовчуванням вибирається користувач nobody

(UID -2). Щоб дозволити привілейований доступ, задайте-maproot = root.

-mapall = юзер - Закріплює все значень UID за певним користувачем; це зручно

при роботі з персональними комп'ютерами і ненадійними однокористувацький станціями.

При зміна exports потрібно перезапустити mountd.

kill-HUP `cat / var / run / mountd.pid`

або:

# / Etc / rc.d / mountdreload

Після того, як АоЕ-сервер завантажився без помилок, перевіримо, наскільки успішно експортувалися файлові системи:

server # showmount-e

Exportslistonlocalhost:

Лістинг

/ usr 192.168.1.0

/ diskless_rw/192.168.1.11/var 192.168.1.11

/ diskless_rw/192.168.1.11/etc 192.168.1.11

...

/ diskless_rw/192.168.1.90/var 192.168.1.90

/ diskless_rw/192.168.1.90/var 192.168.1.90

...

/ diskless_rw/192.168.1.130/etc 192.168.1.130

/ diskless_rw/192.168.1.130/etc 192.168.1.130

/ diskless_ro 192.168.1.0

Автоматично монтувати віддалену файлову систему при кожному завантаженні комп'ютера, додайте файлову систему в / etc / fstab:

Server_IP :/ home / share / mntаоеrw,-b 0 0

-b - Змушує при завантаженні системи виконати швидку спробу з'єднається з сервером якщо спроба не вдалася система буде завантажуватися далі. Але породжується дочірній процес, який продовжує спроби.

3.2 Налаштування клієнтів Windows систем.

На встановленій системі, встановити драйвера AoE через "Додати нове устаткування -> вибрати -> SCSI"

Після установки, заходимо в редактор реєстру для HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services

Там, шукаємо ключ для завантаження мережевої карти і змінимо "Пуск" для 0 (завантаження). Драйвер AoE буде автоматично завантажуватися до atapi.sys, але це буде тільки завантажуватися з диска.Це означає, що можна, наприклад, установити на реальний жорсткий диск, поставив диск в сервер або Coraid корпус, мережевий від неї, і коли ви хочете завантажити її в звичайному порядку, ви можете поклав його назад і нехай він завантажиться в нормальному режимі.

Монтування директорій клієнтів:

Після установки і перезавантаження з'являється можливість примонтувати АоЕ до diskless-1.

Windows mount info

Щоб зіставити мережевий диск за допомогою засобів командного рядка введіть:

mount [-o Параметри] [-u: Користувач] [-p: {Пароль | *}]

Ім'я_комп'ютера :/ Ім'я_загального_ресурсу {ім'я_пристрою | *}

або

mount [-o Параметри] [-u: Користувач] [-p: {Пароль | *}]

\ \ Ім'я_комп'ютера \ Ім'я_загального_ресурсу{ім'я_пристрою | *}

Mount

З цього вищесказаного ясно що примонтувати можна так:

Ім'я_сервера :/ Ім'я_загального_ресурсу

або так:

\ \ Ім'я_сервера \ Ім'я_загального_ресурсу

Для автоматичного монтування можна в консолі виконати.

umount-a

mount 192.168.1.12 :/ home / share Z:

Висновки та пропозиції

Настройка серверу в корпоративній мережі будь-якого підприємства чи закладу - це багатоступенева задача, розв'язання якої потребує знання новітніх комп'ютерних технологій. У цій випускній роботі показано на прикладі настроювання серверу на на базі операційної системи FreeBSD 9.0. Результати роботи такі.

1) Встановили сервер з підтримкою протоколу АоЕ.

2) Примонтували директорії робочих станцій на сервері.

3) Налаштували робочі станції на використання сервера.

Додаток А

Структурна схема мережі

Размещено на Allbest.ru

...