Використання виділених служб нагляду за мережею

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

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

Прийнято вважати, що на сьогодні від 40% до 70% Інтернет трафіку в публічних мережах займає трафік однорангових мереж.

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

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

Автори розробки iPlane використали розосереджену науково-дослідну систему PlanetLab як базу для зовнішньої інфраструктури керування та розвідки мережної топології. За допомогою модифікованих клієнтів однорангової мережі BitTorrent, система iPlane збирає та аналізує широкий спектр показників, які впливають і визначають ефективність та швидкість обміну даними. Зокрема, авторами розроблено так званий «алгоритм фронтіру» для визначення суттєвих в контексті певної однорангової мережі топологічних зв’язків та показників завантаження каналу. Основою алгоритму є функція, вбудована в кожен клієнтський вузол однорангової мережі, яка регулярно звітує до системи iPlane щодо маршруту, часу затримки відповіді вузлів при трасуванні з усіма вузлами, з якими даний вузол вступає в контакт та оціночного значення рівня втрати пакетів. iPlane згодом агрегує зібрану інформацію та обчислює узагальнену топологію актуальної частини мережі а також оцінює ступінь завантаженості каналів в ній в цілому.

Крім того, система iPlane для спрощення обчислень топології виконує самостійну (без участі даних від поточних клієнтів мережі) сегментацію мережі Інтернет на так звані «атоми», в ролі яких виступають в даному випадку префікси BGP, тобто стандартні одиниці множини правил маршрутизації. Дані отримуються за допомогою публічної служби RouteViews, CoralReef, служб типу «Looking Glass» та інших.

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

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

В роботі [6] на основі даних тривалого аналізу трафіку BitTorrent (як запитів до трекера так і міжклієнтських зв’язків) та користуючись тим фактом, що протокол BitTorrent є відкритою специфікацією, пропонується використання проміжних автоматичних серверів кешування. Такі сервери повинні відслідковувати ідентифікатори всіх активних в мережі оператора клієнтів BitTorrent та всі заявлені ними ідентифікатори контенту (тобто участь вузлів у рої), разом із бітовою картою доступності. У випадку, якщо якийсь вузол A запитує частину контенту у іншого вузла B з того ж рою, вузол B знаходиться за межами мережі оператора і в межах мережі оператора є вузол C, що приймає участь в тому самому рої і має вже завантажену частину контенту, то такий сервер кешування здійснює прозору модифікацію трафіку таким чином, щоб замість вузла B вузол A встановив з’єднання з вузлом C.

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

Рисунок 4.7. Порівняльні результати при використанні методу врахування локальності в BitTorrent karagiannis.

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

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

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

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

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

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

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

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

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

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

Всі перераховані вище недоліки є так званою «єдиною точкою відмови» (single point of failure), порушення нормальної роботи якої приводить до краху всієї системи. Порушення може мати як технічний характер (відключення або збій сервера, який надає послуги користувачам публічного доступу), так і адміністративний — зміна корпоративної політики консорціуму, яка приводить до припинення надання послуги або припинення функціонування мережі, або втрата цікавості чи фінансової підтримки колективу дослідників з боку наукових фондів. Прийнятою практикою розробки ІТ є небажаність ставити публічну систему, яка розроблена для одночасного розгортання на сотнях тисяч вузлів по всьому світу, в залежність від такої єдиної точки відмови.

Поиск по сайту: