Топологія мережі – зірка або кільце.

Оптоволоконний джгут може містити довільне число світловодів (зазвичай кратну 6). Стандарт не обумовлює їх кількість, тому проектувальник повинен сам визначити скільки йому необхідно багатомодових і одномодових пар.

Кабель, в якому частина світловодів – одномодова (~ 25%), а інша – багатомодова (~ 75%), називається гібридним.

При виборі оптоволоконного кабелю необхідно враховувати:

1. Довжину (не можна помилятися в меншу сторону, так як оптоволоконний кабель дорогий, що не надійно і трудомістко з’єднувати)

2. Діаметр світловодів (зазвичай 62.5 мікрона для багатомодового і 8 мікрон для одномодового)

3. Оптичне вікно – довжина хвилі лазерного обладнання (850 1300, 1310, 1550 нм)

4. Згасання (аналог опору для мідного кабелю)

5. Пропускну здатність приймаючої / передавального обладнання

6. Якість оптоволокна (стандартне, високоякісне, преміум)

Розширення при топології "зірка" проводиться через спеціальний порт маршрутизаторів:

З’єднання шинних сегментів:

Можлива також змішана топологія. При цьому комутаційне обладнання повинно підтримувати режим dual speed.

Засоби управління ЛВС

Управління мережею розділяється на

• управління пристроями

• управління трафіком

Засоби:

• Агенти SNMP (Simple Network Multiply Protocol)

• Агенти середовища аналізу трафіку

• внутрішньо порожнинне спостереження

• поза смугове спостереження

• розподілене спостереження

Програмно-апаратна підтримка:

• Термінальна консоль (пряме підключення, режим VT100, управління через консольні порти)

• Консоль управління ланцюжком (ПЕОМ, ОС, спеціальне програмне забезпечення, з’єднання з концентратором 0-модемним або коаксіальним кабелем)

• Консоль мережевого трафіку (ПЕОМ, ОС, розвинене програмне забезпечення, з’єднання з концентратором через стандартний порт RJ45)

Оцінюючий коефіцієнт насиченості колізійної області мережі:

LAN =

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

Збільшення пропускної здатності ЛВС може здійснюватися:

• пасивно – за рахунок заміни обладнання і збільшення швидкості мережевого обміну з 10 до 100 або 1000 Мбіт / сек

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

Розглянемо точковий сегмент Ethernet.

1. Мережа працює повільно при слабкому насиченні колізійної області (LAN << 40%)

Критичне місце – сервер, потрібно розділити його функції і частина перенести на нове обладнання.

2. Мережа працює повільно при LAN ~ 40%, тоді можна розділити сегмент на два під сегментні, з’єднавши їх мостом або маршрутизатором. При цьому в кожній колізійної області є свій сервер.

3. Якщо всім клієнтам мережі при LAN >> 40% необхідний online доступ до різними серверами, то за умови збалансованого трафіку, рекомендованим рішенням збільшення пропускної здатності мережі є установка комутатора

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

Захист інформації та підвищення безпеки роботи в ЛВС

Захист може бути:

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

• логічний – на програмно апаратному рівні комутаторів, маршрутизаторів і мостів.

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

Захист мережевого обладнання здійснюється за допомогою вирішення наступних завдань:

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

• обмеження доступу до обладнання та забезпечення надійності його електроживлення та охолодження.

• контроль прямого доступу до всього мережевого обладнання

• забезпечення захисту ліній зв’язку. Всі комунікаційні лінії і мережеві дроти повинні бути захищені від прослуховування.

• розробка плану відновлення системи в разі злому

На рівні захисту адміністративного інтерфейсу мережевих пристроїв застосовуються такі заходи:

• захист доступу до консолі

• використання шифрування паролів

• ретельна настройка параметрів ліній зв’язку

• використання багаторівневої системи привілеїв доступу

• використання інформаційних банерів пристроїв

• управління доступом Telnet

• управління доступом SNMP (Simple Network Management Protocol – простий протокол мережевого управління)

Безпека мережі на програмному рівні забезпечується наступними заходами.

1. Доступ до мережевих ресурсів надається тільки зареєстрованим користувачам

2. Ведення грамотної політики паролів для облікових записів:

o завдання мінімальної довжини пароля

o завдання терміну дії пароля

o блокування облікового запису при деякому числі невдалих спроб введення

3. Використання брандмауерів (апаратні або програмні засоби обмеження і фільтрації трафіку на стику двох мережевих сегментів)

4. Використання фільтрування пакетів маршрутизаторами (фільтрування проводиться на основі заголовків протоколів)

5. Використання NAT (Network Addres Translation) – дозволяє комп’ютерам мережі не передавати свої IP-адреси, а користуватися одним IP-адресом шлюзового комп’ютера для виходу в другий сегмент мережі.

6. Використання проксі-серверів. Проксі-сервер діє на прикладному рівні моделі OSI на відміну від NAT (мережевий рівень) і виконує функцію ретрансляції даних, приховуючи IP-адрес клієнта.

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

o Ipsec (складається з двох протоколів AH (Authentication Header) і ESP (Encapsulating Security Payload) виконуючих транспортну функцію і шифрування відповідно)

o L2TP (Layer 2 Tunneling Protocol) створює тунелі в віртуальних приватних мережах і для шифрування використовує інструменти Ipsec

o SSL (Secure Sockets Layer) Складається з двох частин-SSLHP і SSLRP перша відповідає за перевірку справжності друга зашифрованості. (система сертифікатів)

o Kerberos використовується службами каталогу, щоб надати користувачеві єдину точку входу в мережу тобто користувач отримує доступ до всіх ресурсів мережі (Active Directory) (якщо доступ дозволено!) (система передачі квитків TGT, ST).

Лекція 4: Логічна модель РБД. Бізнес-логіка файл-серверної, клієнт-серверної і N-рівневої архітектури.

Логічна модель РБД.

Логічна модель РБД будується на 3–х рівнях (шарах) абстракції даних: подання інформації, обробки (бізнес-логіки) і зберігання. Шари утворюють сувору ієрархію: шар бізнес-логіка взаємодіє з шарами зберігання та подання. Фізично, шари можуть входити до складу одного програмного модуля, або ж розподілятися на декількох паралельних процесах в одному або декількох вузлах мережі.

• Шар подання інформації

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

• Шар бізнес-логіки

Сполучний, саме він визначає функціональність і працездатність системи в цілому. Блоки програмного коду розподілені по мережі і можуть використовуватися багаторазово (CORBA, DCOM) для створення складних розподілених додатків.

• Шар зберігання даних

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

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

Шар \ Тип архітектури	Файл–сервер	Клієнт–сервер (Бізнес–логіка на клієнті)	Клієнт–сервер (бізнес–логіка на сервері)	N–рівнева архітектура
Уявлення	Клієнт	Клієнт	Клієнт	Клієнт
Бізнес-логіки	Клієнт	Клієнт	Сервер БД	Сервер додатків (комп. кластер)
Зберігання	Файл-сервер (або клієнт) Всі три шари утворюють єдиний програмний модуль	Сервер БД. Користувач. Інтерфейс і бізнес-логіка утворюють єдиний модуль. Дані зберігаються на сервері БД	Сервер БД. Вся бізнес логіка реалізована у вигляді збережених процедур, що виконуються на сервері БД	Сервер БД. Всі шари виконуються на різних машинах.

Файл-сервер

У системах, побудованих за архітектурою файл-сервера всі гілки системи представляють єдине і неподільне ціле. БД зберігається у вигляді файлу або набору файлів на файл-сервері. Вся логіка вибірки, зберігання і забезпечення несуперечності даних покладається на клієнтську частину. Файл-серверні системи орієнтовані на роботу з окремими записами в таблиці.

Переваги:

1. Простота логіки.

2. Низькі вимоги до апаратного забезпечення і малий обсяг необхідної пам’яті.

3. Не вимагають надійних багатозадачних і багатокористувацьких ОС.

4. Невисока ціна СУБД.

Недоліки:

1. Обмеженість мови і негнучкість середовища розробки додатків

2. Слабка масштабованість

3. Не забезпечують багато користувачів режим роботи

4. Важко підтримувати цілісність і несуперечність даних

5. Необхідність ручного блокування записів або таблиць цілком.

6. Низький рівень захищеності як зовнішньої (від злому), так і внутрішньої (від помилок додатків) Наприклад індекси окремо від таблиць.

7. Не мають коштів шифрування мережевого трафіку

8. Створюють високе навантаження на мережу

Висновки:

Файл-серверна архітектура є досить привабливою альтернативою для створення одного користувача ІС зі слабкими вимогами до захисту даних.

Клієнт-сервер з бізнес-логікою на клієнті

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

Клієнтська частина обмінюється даними з сервером за допомогою SQL запитів. Обробка інформації в клієнт-серверних системах ведеться на рівні безлічі кортежів.

Процес розробки розділяється на створення БД і написання клієнтської частини з бізнес-логікою.

Переваги:

1. Висока продуктивність, стабільність і надійність при багато користувачів роботі.

2. Легко організовується захист даних (шифрування мережевого трафіку SSH, SSL)

3. Універсальність мови визначення і маніпулювання даними

Недоліки:

1. Більш висока ціна СУБД. (Сервер БД продається окремо).

2. Досить високі вимоги до кваліфікації розробників

3. Навички адміністрування сервера БД

4. Підвищені вимоги до пропускної здатності мережі

5. Підвищені вимоги до клієнтських місцях (на них виконується шар бізнес- логіки)

Висновки:

При кількості користувачів від 2 до ~ 50 вона є хорошим варіантом. З ростом числа користувачів починає позначатися недостатня пропускна здатність мережі.

Клієнт-сервер з бізнес-логікою на сервері

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

Переваги:

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

2. Простіший процес створення бізнес-логіки.

Недоліки:

1. Підвищені вимоги до сервера БД. (Кожен сеанс "з’їдає" пам’ять з розрахунку граничного завантаження)

2. Невисока мобільність системи на інші сервери БД.

Висновки:

У порівнянні з попередніми класами, дозволяє тримати велике навантаження.

N-рівнева архітектура

Основними елементами є сервера БД, сервер (кластер) додатків і клієнтська частина. Головна ідея n-рівневої архітектури полягає в максимальному спрощенні клієнта (тонкий клієнт), винесення всієї бізнес-логіки з клієнта і сервера БД.

Тонкий клієнт являє собою певний термінал типу HTML-browser або емулятори X-терміналу

Вся бізнес-логіка оформляється у вигляді набору додатків, що запускаються на сервері додатків під управлінням ОС типу UNIX.

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

Сервер додатків з’єднаний з сервером БД за допомогою окремого високошвидкісного сегмента мережі.

Переваги:

1. Підвищена захищеність.

2. Висока продуктивність.

3. Легкість розвитку і модифікації.

4. Легкість адміністрування.

5. Можливість створення системи з масовим паралелізмом (серверів БД може бути кілька, а сервером додатків можуть служити кілька з’єднаних в кластер комп’ютерів).

Недоліки:

1. Висока складність.

2. Висока ціна рішення.

3. У деяких випадках поступається по продуктивності клієнт-серверних систем з бізнес-логікою на сервері.

Висновки:

Єдина альтернатива для створення ІС для дуже великої кількості користувачів.

Лекція 5:

Базові об’єктні архітектури розподілених систем. Технології .NET, (D) COM +, CORBA, EJB.

Базові технології. Порівняння на понятійному рівні.

Функції CORBA і COM – це функції проміжного middleware програмного забезпечення об’єктної середовища. Функціональність об’єкта надається клієнтові за допомогою звернення до абстрактних інтерфейсів. Інтерфейс визначає набір методів, властиві даному класу об’єктів. Клієнт отримує доступ до об’єкту тільки шляхом виклику методу, визначеного в інтерфейсі об’єкта, але деталі реалізації приховані від клієнта. Реальні дії виконуються в адресному просторі об’єкта, можливо, такого далекого по відношенню до процесу клієнта. Приховування деталей реалізації і визначає незалежність від платформи і мови програмування.

В обох технологіях взаємодія між клієнтським процесом і сервером об’єкта, тобто процесом, який породжує і обслуговує екземпляри об’єкта, здійснюється за рахунок віддаленого виклику процедур (RPC, remote procedure call). Механізм RPC реалізує схему передачі повідомлень, відповідно до якої в розподіленому клієнт-серверному застосуванні процедура – клієнт передає спеціальне повідомлення з параметрами виклику по мережі в віддалену серверну процедуру, а результати її виконання повертаються в іншому повідомленні клієнтського процесу.

Для цього на стороні клієнта і на стороні сервера підтримуються спеціальні компоненти, що носять назву клієнтський і серверний сурогати (client stub і server stub). Для виклику методу об’єкта клієнт звертається до клієнтського сурогату, який упаковує аргументи на повідомлення-запит і передає їх на транспортний рівень з’єднання. Серверний сурогат розпаковує отримане повідомлення і відповідно до переданих аргументами викликає потрібний метод об’єкта. У СОМ клієнтський сурогат називається proxy, а серверний – stub. У CORBA клієнтський сурогат не має спеціальної назви, а серверний позначається терміном skeleton.

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

Поняття про технологію (D) COM (+)

(D) COM (+): COM, DCOM, COM +. COM (Component Object Model) – Об’єктно-Компонентна Модель (1993). D – distributed (1996). + – 1998.

У СОМ об’єкт характеризується своїм класом. Клас – це реалізація певної кількості інтерфейсів. Множинне спадкування інтерфейсів не підтримується, замість цього об’єкт може мати кілька інтерфейсів одночасно. У СОМ інтерфейс може визначатися шляхом успадкування іншого інтерфейсу. Для всіх інтерфейсів існує базовий інтерфейс – IUnknown. Для того щоб перейти від інтерфейсу базового типу до успадкованого інтерфейсу або від одного з інтерфейсів об’єкта до іншого, клієнт повинен викликати метод QueryInterface, визначений у базовому інтерфейсі IUnknown.

Для ідентифікації класів і інтерфейсів СОМ використовуються ті ж універсальні унікальні ідентифікатори (UUID), які прийняті для ідентифікації інтерфейсів в специфікації DCE RPC. Можна застосовувати і символьні позначення інтерфейсу, але потім вони повинні бути трансльовані в належний ідентифікатор UUID. Об’єкт в СОМ – це екземпляр класу. Клієнт получає доступ до об’єкту за допомогою покажчика на один з його інтерфейсів (interface pointer). Ідентифікатор класу посилається на конкретну реалізацію, і фактичний набір інтерфейсів для даної реалізації стає остаточно відомий тільки на стадії виконання. СОМ реалізує інтеграцію об’єктів на рівні двійкових кодів.

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

COM підтримує інтерфейс динамічного виклику (коли інтерфейс об’єкта не відомий клієнту на етапі компіляції).

В COM для ідентифікації об’єктів використовується механізм moniker, який забезпечує перетворення символьного імені об’єкта в покажчик інтерфейсу. Цей механізм діє для тих об’єктів, які зберігаються в довгостроковій пам’яті. Два ж активних об’єкта вважаються ідентичними, якщо для них збігаються покажчики на інтерфейс IUnknown. Для довготривалого зберігання в СОМ підтримуються дві моделі. Перша і початкова модель надає клієнту можливість управляти зберіганням об’єкту. За другою моделі Microsoft Transaction Server (MTS) забезпечує управління зберіганням з боку сервера.

У СОМ передбачені такі загальні служби, як захист (security), управління життєвим циклом (lifecycle managemеnt), інформація про типи (type information), іменування (naming), доступ до баз даних (database access), передача даних (data transfer), реєстрація (registry) і асинхронне взаємодія.