Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

Ralex. We do the work.
На рынке с 1999го года. Средняя ценовая категория. Ориентация на эффективность решений.
Ознакомтесь с нашим портфолио
Узнайте больше о услугах
Свяжитесь с нами:
E-mail: [email protected]
Tel: (044) 587 - 84 - 78
Custom web design & дизайн и разработка сайта "под ключ"
Креативный, эффективный дизайн. Система управления сайтом (СУС).
Custom flexible разработка систем электронной коммерции
Система e-commerce разрабатывается под индивидуальные потребности. Гибкая функциональность.
Search Engine Optimzation & оптимизация под поисковые системы (SEO)
Постоянная оптимизация и мониторинг сайта в поисковых системах. Достигаем результата быстро и эффективно
Custom logo design & дизайн логотипа и фирменного стиля
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.
профессиональная рекламная фотография
креативно, смело, качественно
Custom logo design & рекламный креатив. дизайн рекламы
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.

Алгоритмічне забезпечення розподілених Web-серверів

  1. Стрімкий розростання Всесвітньої павутини і пов'язане з цим збільшення обсягу трафіку продовжують турбувати...
  2. DNS
  3. Дисципліни з розподільниками навантаження
  4. Дисципліни без розподільника навантаження
  5. Розміщення информации
  6. Висновок
  7. література
Стрімкий розростання Всесвітньої павутини і пов'язане з цим збільшення обсягу трафіку продовжують турбувати фахівців. Web-сервери стали не тільки сховищем текстової та графічної інформації, а й місцем велетенських покладів відео- і аудіоматеріалів, а також засобом проведення масштабних комерційних операцій. На перший план виходить завдання обслуговування запитів за гарантований час, що неминуче вимагає вдосконалених технічних, алгоритмічних і програмних засобів побудови розподілених Web-серверів.

Наша взаимовыгодная связь https://banwar.org/

Згідно з даними компанії Nortel Networks, число користувачів систем електронної комерції зросте з 142 млн. В 1999 році до 500 млн. В 2003-му, а сумарний фінансовий оборот складе в 2003 році понад 1 трлн. дол. При такому зростанні Мережі головною турботою Web-розробників стає необхідність вчасно обслужити запит клієнта. Пошук рішення призводить до ідеї розподіленого Web-сервера.

Web-кластери стали об'єктом пильного вивчення ІТ-менеджерів, інженерів-ставків, математиків. Про це свідчить зростаючий з року в рік потік публікацій, появу експериментальних систем в університетах і наукових центрах, інтенсивно розвивається ринок так званих «розподільників навантаження» (dispatcher, load balancer), формування термінології. Однак російською мовою вийшло украй мало публікацій [1], а деякі перекладні написані, як правило, фахівцями з менеджменту і носять рекламно-публіцистичний характер. Тим часом, організація розподіленого Web-сервера - досить складне завдання, що вимагає детального опрацювання ряду питань:

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

Потоки даних в WWW

Упродовж кількох десятиліть при аналізі моделей, що виникають в теорії обчислювальних систем, дослідники звикли вважати вхідні потоки пуассоновским, а розподілу довжин заявок - експонентними. Такі припущення дозволяють будувати марковский процес і отримувати аналітичні результати, які носять якщо і не Предсказательная, то хоча б пояснювала б характер. Зрозуміло, коли в першій половині 90-х років фахівці зайнялися моделюванням настільки складної структури, як Всесвітня павутина, не міг не виникнути питання, наскільки ці припущення близькі до реальності. Основною з'явилася робота [9], автори якої показали, що потоки в Web описуються пуассоновским, а іншими законами розподілу - «з важким хвостом» (heavy-tailed) або статечними.

Такі розподілу описуються залежністю Pr (X> x) ~ xa, 0x) - ймовірність перевищення випадковою величиною «X» заданого числа «x». Для подібного розподілу характерно нескінченне значення дисперсії, а при a

Типовими прикладами розподілу з «важким хвостом» є розподілу Парето і Вейбулла. Наведемо оцінки параметра a для деяких характеристик, що підкоряються розподілу Парето (менше значення параметра відповідає більшій вираженості властивостей випадкової величини):

  • розміри файлів, що передаються по протоколу HTTP: 1,1
  • розміри файлів, що передаються по протоколу FTP: 0,9

Автори роботи [5] зібрали статистику по безлічі запитуваних файлів (за окремим запитом багаторазово), безлічі переданих з сервера файлів (не виявлення в кеші і повторні файли), безлічі унікальних файлів. На її підставі був зроблений висновок, що розміри файлів в кожному з множин добре описуються розподілом Парето. Більш повна класифікація статистичних даних приведена в [2], де введено поняття інваріантів, тобто характеристик, що відображають особливості деякої цілісної сукупності даних в Web:

  • частка успішних звернень становить 88%, решта - відсутність документа на сервері або прав доступу до нього;
  • HTML-файли та графічні файли складають від 90% до 100%;
  • середній розмір передачі - 21 Кбайт;
  • список даних без попереднього повторів - менше 3% від загального числа переданих файлів;
  • розподіл розміру файлу - Парето, 0,4
  • концентрація посилань - на 10% файлів доводиться до 90% запитів, які складають 90% трафіку;
  • географія - звернення з 10% від загального числа доменів складають понад 75% усіх звернень.

Нерівномірність розподілу показників завантаження можна почерпнути і з власного досвіду. Наприклад, за червень 2002 року з офіційного Web-сервера адміністрації Сургута було здійснено 73740 запитів сторінок; якщо їх упорядкувати по спадаючій числа відвідувань, то вийде список без повторів з 6616 HTML-файлів, причому 36194 запитів припадає на перші 61 файл. Таким чином, в цьому випадку менш ніж на 1% файлів припадає понад 50% запитів.

Так зване «час обмірковування» (thinking time) - проміжок між отриманням відповіді і новим запитом - також розподілено згідно із законом Парето. Це самий розподіл може бути застосовано до кількості гіпертекстових посилань, що ведуть на дану сторінку (inbound) і зі сторінки (outbound).

DNS

Один з найбільш простих способів поділу навантаження між кількома серверами полягає у використанні циклічної дисципліни Round-Robbin DNS (RR-DNS).

Цей спосіб не вимагає наявності виділеного розподільника навантаження, функцію якого виконує DNS-сервер. Сервер, який обслуговує зону, в якій розташований кластер, циклічно виробляє дозвіл одного і того ж доменного імені на різні IP-адреси, відповідні хостам з кластера. Даний підхід досить добре вивчений і поряд з головною перевагою, простотою, має низку очевидних недоліків [4].

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

Боротися з другим недоліком можна шляхом настройки керуючого параметра TTL (Time-to-Live), що задає час «життя» записи в DNS-кеші. Установка TTL рівним нулю виключає ефект кешування, але тоді DNS-сервер може стати вузьким місцем мережевого трафіку. В [10] показано, що без кешування час дозволу доменного імені стає на два порядки вище. Можна підлаштовувати TTL для кожного запису з урахуванням частоти запитів, але далеко не очевидно як це робити з максимальним ефектом. Помічений ще один недолік DNS-підходу - неявне припущення, що клієнт і його локальний name-сервер розташовані поблизу. Однак це не завжди так. Тому тимчасова затримка на name-сервері не завжди правильно відображає затримку клієнта. DNS-подход в умовах великого завантаження і різноманітності типів запитів сам по собі не може гарантувати вирішення проблеми балансування; для цього потрібні більш тонкі дисципліни.

Дисципліни з розподільниками навантаження

Головну роль в Web-кластері, грає розподільник навантаження, що приймає рішення про подальший рух кожного запиту. При цьому весь Web-кластер представлений для зовнішнього спостерігача тільки одним IP-адресою - віртуальним IP (VIP). Коротко згадаємо про механізми маршрутизації пакетів всередині Web-кластера [1, 3, 4]:

  • Односпрямована маршрутизація (one-way routing). Розподільник навантаження підміняє в пакетах власний IP-адреса IP-адресою обраного сервера. Відповідь сервера повертається клієнтові безпосередньо, без участі розподільника навантаження. Web-сервер замінює свій IP-адресу на VIP, щоб відповідь виходив з адреси, на який було надіслано запит. Це дозволяє розвантажити розподільник навантаження (вихідний потік значно перевищує вхідний), але вимагає змін в коді операційної системи сервера, оскільки підміна IP-адреси відбувається на рівні TCP / IP.
  • Двунаправленная маршрутизація (two-way routing). Вихідний потік від сервера йде через розподільник навантаження, який в цьому випадку виконує обидві підстановки адреси. При такому підході розподільник навантаження стає вузьким місцем мережі.
  • Маршрутизація через розподільник навантаження (packet forwarding by the dispatcher). Підхід реалізований в IBM Network Dispatcher [7]. Пересилання пакетів сервера відбувається на рівні MAC-адреси, без зміни заголовка IP-пакета, для якого в даному випадку не потрібно Переобчислювати контрольні суми. Розподільник навантаження і сервери повинні знаходитися в одному мережевому сегменті.

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

Застосовувані алгоритми диспетчеризації якомога розділити на статичні і динамічні. В останньому випадку розподільник навантаження здійснює періодичний моніторинг серверів, що входять в кластер і вибирає для направлення запиту найкращий з них. У статичних алгоритмах стан серверів не відслідковуються. Вибір алгоритмів залежить від багатьох факторів. Підвищена «інтелектуальність» динамічних алгоритмів тягне накладні витрати, пов'язані зі збором інформації з хостів, однак вибір дисципліни обслуговування багато в чому залежить не тільки від характеру трафіку, а й від функціональності розподільника навантаження. Прийнято класифікувати їх на пристрої рівня 4 і рівня 7 (рис. 2).

Розподільник навантаження рівня 4 аналізує пакети тільки на рівні TCP / IP, не доходячи до рівня додатки, не беручи до уваги HTTP-запит при перенаправлення пакета на сервер. Такий механізм називають «сліпим до змісту» (content-blind) або «негайним зв'язуванням» (immediate binding). Розподільник навантаження рівня 7 приймає рішення про маршрутизації запиту тільки при отриманні HTTP-пакета. При цьому, провівши аналіз URL, такі пристрої можуть врахувати тип запиту, оцінити його трудомісткість і визначити, на якому сервері знаходиться потрібний ресурс. Цей механізм називають «чуйним до змісту» (content-aware) або «відкладеним зв'язуванням» (delayed binding) [8]; його підтримують багато комерційні продукти [3]. Зрозуміло, дисципліни другого типу слід віднести до динамічних. З іншого боку, застосування рівня 7 виправдано, якщо його можливості використовуються дисципліною обслуговування, тому цілком природно, що статичні дисципліни реалізують тільки розподільники навантаження рівня 4, а динамічні - як ті, так і інші.

До статичних дисциплін відносяться Random і Round Robbin. У Random сервер вибирається випадковим чином за допомогою рівномірного розподілу. Дисципліна Round Robbin реалізує принцип циклічного перебору, який в чистому вигляді виглядає так: i-ий за рахунком заявка надходить на сервер з номером, рівним залишку від ділення i на N, де N - кількість серверів.

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

  • час перебування заявки на сервері (waiting time);
  • уповільнення (slowdown), тобто відношення часу перебування до довжини заявки (у скільки разів сповільнюється обслуговування запиту через наявність черги).

Найбільш природними динамічними дисциплінами є:

  • Least Loaded (LL) - вибір сервера за критерієм найменшого завантаження його ресурсів (процесор, пам'ять, диск, кількість черг повідомлень);
  • Least Connected (LC) - вибір сервера за критерієм найменшого числа поточних відкритих TCP / IP-з'єднань;
  • Fast Response (FR) - вибрати сервера за критерієм найшвидшого відповіді на тестовий запит від розподільника навантаження;
  • Weighted Round Robbin (WRR) - при циклічному переборі кожного серверу, на відміну від статичної дисципліни RR, передається поспіль не один запит, а кілька, відповідно до ваги сервера, пропорційним, скажімо, його поточне завантаження [7].

Всі ці дисципліни «сліпі до змісту» і не вимагають аналізу HTTP-запиту. У порівняльному дослідженні дисциплін WRR, LC і LL за середнім часу відповіді та завантаженні серверів найкраще показала себе дисципліна LL. При низькій і середньому завантаженні WRR поводиться набагато гірше динамічних дисциплін а час очікування для LC в середньому в 6 разів більше, ніж для LL. З ростом навантаження продуктивності сходяться, причому показники LC прагнуть до показників LL набагато швидше, ніж WRR. Не дивно, що, раз LL виявилася кращою, то легше реалізувати LC, оскільки для LL потрібно більш інтенсивний обмін службовою інформацією між розподільником навантаження і серверами. З цього аналізу випливає, що питання про те, яка з перерахованих динамічних дисциплін найбільш ефективна, має скоріше теоретичне значення. На практиці ж цей вибір не робить будь-якого визначає впливу на продуктивність Web-кластера.

Універсальний підхід до використання динамічних дисциплін типу content-blind реалізовано в IBM Network Dispatcher [7]. Автори ввели поняття «індексу завантаження» Load Metrics Index (LMI) і розділили показники якості роботи системи на три класи.

  • Input - обчислюються локально в РН, наприклад, кількість з'єднань, встановлених з сервером за останні t одиниць часу.
  • Host - обчислюються на кожному сервері, приміром, завантаження сервера.
  • Forward - обчислюються шляхом мережевої взаємодії розподільника навантаження з сервером. Ці характеристики доставляють спеціальні скрипти-агенти, наприклад, подача HTTP-запиту "GET /" і вимір часу відповіді.

Далі, по вектору LMI для кожного сервера обчислюються значення функції WCF (Weight Computation Function), і вибирається сервер з найбільшим значенням. Програмне забезпечення диспетчера складається з трьох компонентів - Advisor, Manager і Executor. Перший компонент опитує сервери і зібрану інформацію передає на другий для обчислення WCF; третій виробляє маршрутизацію пакетів. Відкритими залишаються питання динамічного підстроювання ваг для WCF, а також оптимального значення періодичності оновлення LMI.

Параметр LMI дуже важливий. Справа в тому, що інформація про стан серверів при інтенсивному вхідному потоці може швидко застаріти і виявитися не просто марною, але й шкідливою для розподільника навантаження. Відомий так званий "ефект стада», коли «найкращому» на даний момент сервера поспіль пересилається багато запитів і він швидко стає гіршим - задовго до наступного збору інформації про стан, коли можна буде щось змінити. Методам запобігання такій ситуації присвячено чимало робіт. Деякі з них намагаються врахувати «вік» інформації про завантаження серверів. Якщо інформація свіжа, слід використовувати динамічну дисципліну, інакше - статичну. Припустимо, після опитування стану N серверів впорядковані по зростанню числа активних сполук, і сервер для запитів, що надходять вибирається серед перших k випадковим чином. Очевидно, що k = 1 відповідає динамічної дисципліни LC, k = N - статичній дисципліни Random. Період T між двома послідовними опитуваннями стану ділиться на N інтервалів, і на j-му інтервалі навантаження ділиться між першими j серверами. У міру старіння інформації відбувається поступовий перехід від повністю динамічної дисципліни до повністю статичної.

Для всіх розглянутих дисциплін рішення приймається тільки на підставі інформації від сервера, але і інформація клієнта теж може враховуватися. Це характерно при підтримці властивості client affinity, під яким розуміється послідовне подання запитів від одного клієнта одного й того ж сервера [3]. Такий прийом у багатьох випадках дозволяє підвищити продуктивність і функціональність системи.

Перейдемо тепер до розгляду дисциплін відносяться до класу content-aware. Найбільш простий з них є Cache Affinity [3], відповідно до якої файли розподіляються між серверами за допомогою хеш-функції. Ту ж функцію використовує і розподільник навантаження, забезпечуючи адресність звернень. Однак по-перше, така дисципліну придатна лише для статичного вмісту, по-друге, ігнорує балансування завантаження.

Розглянемо алгоритми, так чи інакше беруть до уваги трудомісткість и ресурсомісткість запиту. При цьом припущені про статистичні Властивості Довжина Запитів, что надходять виробляти до уточнення традіційніх уявлень про балансуванню НАВАНТАЖЕННЯ. Деякі досліднікі відзначають, что Прагнення рівномірно скачать сервери не відповідає структурі потоків в Internet, и можна використовуват дісціпліну SITA-V (Size Interval Tasks Assignment-Variable), согласно З якою «Легкі» завдання надсілаються на хост з меншим завантаження, а «важкі» - з більшою. Так як при статечні розподілі «легких» задач более, а «Важко» - менше, ефективність методу растет зі Зменшення параметра a. Трапляється, что Середнє уповільнення зніжується більш чем в 100 разів у порівнянні з дісціпліною рівномірного завантаження, проти середній годину Очікування при цьом растет. Крім того, обчислення точок розбиття довжин заявок на інтервали, що дозволяють відрізнити «легкі» завдання від «важких», носить оціночний характер.

Наступним кроком стала робота [6], де була розглянута дисципліна SITA-E (тут E - від equal). Її відмінність від SITA-V полягає в тому, що в ній для точок розбиття запропонована точна формула: якщо потрібно розділити вхідний потік заявок між N серверами, N-1 точок знаходяться з інтегрального співвідношення, що виражає умову рівності інтервалів довжин заявок, зважених за ймовірністю в відповідно до щільності розподілу. Заявки, довжини яких лежать в межах i-го інтервалу, направляються на i-ий сервер.

Оцінка ефективності методу грунтувалася на порівнянні дисциплін FCFS ( «першим прийшов - першим обслужений») і PS ( «поділ процесора»). У FCFS обслуговується тільки одна заявка, а решта чекають в черзі; в PS черзі як такої немає, оскільки ресурс процесора ділиться на всі присутні в системі заявки в режимі квантування часу. Математичний аналіз дисципліни PS значно складніше аналізу FCFS, але наскільки ці зусилля виправдані? Автори [6] приходять до цікавого висновку: в разі застосування в розподільнику навантаженні алгоритму SITA-E, здавалося б, досконально вивчена дисципліна FCFS вдвічі перевершує PS за часом відповіді і уповільнення. Системи пакетної обробки завжди були ефективніше з точки зору використання ресурсів, ніж системи поділу часу: на перемикання витрачаються системні ресурси.

У подальших дослідженнях алгоритму SITA-E кожен сервер обробляв запити відповідно до FCFS, довжина заявки передбачається відомої розподільника навантаження. Був проведений порівняльний аналіз трьох дисциплін: Round Robbin, Random і Dynamic Least Work Remaining (в останньому випадку запит передається серверу з мінімальною залишковою роботою, близько до LC) і дійшли висновку: жодна з дисциплін не є найкращою у всіх випадках. Коли дисперсія не дуже велика, динамічна дисципліна краще за інших, але її ефективність падає з наближенням дисперсії до даних реальних вимірів трафіку.

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

Однак побудовані моделі і зроблені висновки виявилися більше цікаві для математиків, ніж для практиків. Причина в тому, що важко заздалегідь точно визначити довжину заявки. Якщо до статичних запитам ці моделі ще можна якось прикласти, то до динамічних SITA-E навряд чи буде доречний. В одній з робіт автори SITA-E запропонували алгоритм TAGS (Task Assignment Based on Guessing Size), добре працює для потоків заявок з великою дисперсією і невідомої заздалегідь довжиною заявки, яка визначається динамічно. Спочатку вона надходить на обслуговування на перший сервер. Якщо s1 одиниць часу виявилося недостатньо для завершення обслуговування, процес переривається, і заявка ставиться в чергу до другого сервера, де її обслуговування починається з початку і т.д. TAGS, таким чином, досягає приблизно тих же цілей, що і SITA-E, але без апріорної інформації про довжину заявки. Для реалізації цієї дисципліни не потрібно аналізу HTTP-заголовка і наявності розподільника навантаження. Однак незрозуміло, скільки необхідно серверів, щоб знизити середню уповільнення до заданого рівня. Неясно і те, як оптимально вибрати послідовності si.

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

В іншому дослідженні запропонована дисципліна MC-RR (Multi Class Round Robbin) для пристроїв рівня 7. Її мета - поліпшити поділ навантаження для Web-кластерів, що виконують статичні і динамічні запити. Всі можливі запити розділені по очікуваному впливу на мережу, процесор і диск: статичні і «легкі» динамічні; з високим навантаженням на диск; з високим навантаженням на процесор; з високим навантаженням на диск і процесор. Заявки першого класу характерні для систем Web-публікацій, решта - для обробки Web-транзакцій і мультимедійних Web-додатків. Усередині кожного класу заявки обслуговуються згідно дисципліни RR. Основна ідея алгоритму полягає в тому, що розподільник навантаження хоча і не може точно обчислити довжину заявки, але може визначити її клас. З невеликими модифікаціями метод MC-RR відомий також як CAP (Client-Aware Policy).

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

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

Дисципліни без розподільника навантаження

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

  • Триангуляція. Працює на рівні TCP / IP. Перший з серверів, який встановив з'єднання, вирішує, обслуговувати цей запит самому або переслати його іншому серверу. В останньому випадку новий сервер розпізнає, що пакет був перенаправлений, і відповідає безпосередньо клієнтові. Наступні пакети цього TCP-з'єднання продовжують надходити на перший сервер і перенаправлятися. Клієнт і два сервера утворюють трикутник, що і пояснює назву методу (рис. 3).
  • HTTP-перенаправлення. Працює на рівні HTTP. Початкові параметри сервер повертає клієнтові новий URL і код відповіді 301, що пропонує запросити шуканий ресурс по новому URL. Переглядач встановлює нове TCP-з'єднання з іншим сервером. Це збільшує "мережеву" частину часу затримки відповіді, але в багатьох випадках може бути компенсовано більш швидкою обробкою запиту на новому сервері, особливо, якщо перший перевантажений. Переглядачі, проте роблять цей механізм видимим для користувача, змінюючи поле введення URL, що може ввести користувача в подив.

Переваги вибору дисципліни обслуговування без розподільника навантаження (децентралізована архітектура) можуть полягати в тому, що усувається потенційно вузьке місце в системі, і вихід з ладу будь-якого сервера не призводить до її зупинки. Разом з тим, за обсягом функціональних можливостей децентралізована система, звичайно, не може зрівнятися з тим, що забезпечує, наприклад, Cisco Director або IBM Network Dispatcher.

Розміщення информации

Ефективність функціонування розподіленого Web-сервера в чому залежить і від того, яким чином всередині нього розміщена інформація. Проблема розміщення даних породжує цікаві завдання дискретної оптимізації, при цьому розрізняють розміщення файлів і видів служб. У першому випадку на полярних позиціях перебувають повне дублювання всієї інформації на кожному сервері і повне розділення, коли все безліч файлів ділиться на N непересічних підмножин. Перше рішення неекономічно, друге ненадійно і не гарантує балансування завантаження - одні файли більш популярні, ніж інші. Найкращим рішенням зазвичай є дублювання одного безлічі файлів і поділ іншого. У зв'язку з цим виникають завдання оптимального розбиття вмісту сервера на підмножини і вибору кількості копій. Нарешті, існують алгоритми, що передбачають динамічну міграцію документів між хостами. Що ж стосується генерації і розподілу динамічного вмісту, то ефективність планування робіт багато в чому визначається бізнес-логікою і технологіями розробки Web-додатків. Загальних тенденцій тут небагато. Дослідження, присвячені плануванню Web-додатків, в основному спрямовані на модифікацію багатоланкових Web-кластерів (рис. 4). Тут сервери додатків реалізують бізнес-логіку і виступають як сполучна ланка між Web-сервером і сервером баз даних.

Висновок

Наукові основи оптимального вибору дисципліни обслуговування ще далеко не склалися, причому це в рівній мірі відноситься і до інших місій, пов'язаних з Web-кластерами. Коли мова йде про моделювання Internet-систем, кожне рішення має досить вузьку область застосування, межі якої швидко можуть стати ще вже, оскільки сьогоднішня Мережа - не те ж саме, що Мережа завтрашня. Різноманітність підходів, методів, оцінок вимагає систематизації, першою спробою якої була робота [3]. Можливо, коли-небудь з'явиться загальна теорія, що зводить розрізнені рішення в єдине ціле. Але поки питань набагато більше, ніж відповідей.

література
  1. Лібман Л. Філософія розподілу навантаження. - Журнал мережевих рішень LAN, № 5, 2000..
  2. Arlitt MF, Williamson CL Web Server Workload Characterization: The Search for Invariants. - In Proceedings of the ACM SIGMETRICS '96 Conference, Philadelphia, PA, 1996. Apr.
  3. Cardellini V., Casalicchio E., Colajanni M., Yu PS The State of the Art in Locally Distributed Web-server Systems. - IBM Research Report, RC22209 (W0110-048), 2001., October.
  4. Cardellini V., Colajanni M., Yu PS High-Performance Web-server Systems. - IEEE, Internet Computing, 1999, May-June.
  5. Crovella ME, Taqqu MS, Bestavros A. Heavy-Tailed Probability Distributions in the World Wide Web. - In A Practical Guide To Heavy Tails, chapter 1, Chapman & Hall, New York.
  6. Harchol-Balter M., Crovella M., Murta C. To queue or not to queue ?: When FCFS is better than PS in a distributed system. - Technical Report, CS Department, Boston University, Number 1997-017, 1997. October 31.
  7. Hunt G., Goldszmidt G., King R., Mukherjee R. Network Dispatcher: a connection router for scalable Internet service. - Computer Networks and ISDN Systems, Vol. 30, 1998..
  8. Hunt G., Nahum E., Tracey J. Enabling content-based load distribution for scalable services. - Technical report, IBM TJ Watson Research Center, May тисяча дев'ятсот дев'яносто сім.
  9. Paxson V., Floyd S. Wide-area Traffic: The Failure of Poisson Modeling. - IEEE / ACM Transactions on Networking, 1995 June.
  10. Shaikh A., Tewari R., Agrawal M. On the Effectiveness of DNS-based Server Selection. - Proceedings of IEEE INFOCOM '01, Anchorage, Alaska, 2001. April.

Ілля Труб ( [email protected] ) - завідувач лабораторією мережевих технологій Сургутского державного університету.

Математичний аналіз дисципліни PS значно складніше аналізу FCFS, але наскільки ці зусилля виправдані?
To queue or not to queue ?
Категории
  • Биология
  • Математика
  • Краеведению
  • Лечебная
  • Наука
  • Физике
  • Природоведение
  • Информатика
  • Новости

  • Новости
    https://banwar.org/
    Наша взаимовыгодная связь https://banwar.org/. Запустив новый сайт, "Пари Матч" обещает своим клиентам незабываемый опыт и возможность выиграть крупные суммы.


    Наши клиенты
    Клиенты

    Быстрая связь

    Тел.: (044) 587-84-78
    E-mail: [email protected]

    Имя:
    E-mail:
    Телефон:
    Вопрос\Комментарий: