- Служба Network Load Balancing (NLB) .В основному, призначена для балансування вхідного трафіку TCP / IP. NLB зазвичай використовується для веб-серверів.
- Кластери серверів .Реалізуются для забезпечення переходів щодо відмови (failover) серед кластеризованих комп'ютерів. Служба Cluster зазвичай використовується для додатків, що працюють з базами даних.
Ви не можете застосувати обидві технології до одного сервера, але можете використовувати ці два кластерних рішення спільно для реалізації доповнюють один одного функцій, наприклад, зробити базу даних доступною для відвідувачів веб-сайту.
Кластери Network Load Balancing
Network Load Balancing (NLB) - це програмна розробка, яка використовується в кластеризації Microsoft Windows для масштабування роботи IP-програм шляхом розподілу клієнтських запитів серед кількох серверів в кластері. NLB використовується найчастіше для підвищення продуктивності і рівня готовності веб-додатків, але може також використовуватися для підвищення продуктивності безлічі IP-додатків всередині вашого підприємства.
Примітка. Служба Network Load Balancing в її поточній формі з'явилася як перероблена заміна служби Windows Load Balancing Service (WLBS), використовуваної в Windows NT 4. Однак ви побачите, що до сих пір є компоненти вихідної WLBS, наприклад, що запускається з командного рядка програма управління, wlbs .exe, все ще використовується для забезпечення сумісності.
- Standard Edition;
- Enterprise Edition;
- Datacenter Edition;
- Web Edition.
Переваги Network Load Balancing
готовність
Одне з головних переваг служби NLB - це висока готовність, яка забезпечується цією службою для додатків підприємства. Кластерний ПО може автоматично змінювати розподіл клієнтських запитів в разі відмови сервера. Для цього кластер і окремі сервери стежать за станом один одного. Між серверами, а також між кожним сервером і кластером відбувається обмін груповими або широкомовними повідомленнями.
Якщо стан сервера (або декількох серверів) всередині кластера змінюється, то активні сервери запускають процес, який називається "злиттям" (convergence), щоб визначити, які сервери залишилися активними і як перерозподілити навантаження між ними. За замовчуванням NLB визначає втрату члена кластера протягом п'яти секунд і виконує процес злиття протягом наступних п'яти секунд. Поки відбувається злиття, кожен вузол кластера продовжує обробляти пакети додатків згідно з правилами, які існували до початку процесу злиття.
Якщо злиття ініціюється в результаті втрати одного з серверів, то запити додатки, які повинні були оброблятися відмовив сервером, повертаються невиконаними, поки не буде виконано перепризначення запитів (після закінчення злиття). Цей стан помилки повинно враховуватися в перехідному стані користувачем або додатком, але не самої службою NLB.
Якщо до кластеру додається ще один хост-сервер, той же самий процес злиття дозволяє новому хосту отримувати його частку трафіку. В результаті розширення кластера відбувається абсолютно прозоро як для клієнтів, так і для додатків.
масштабованість
NLB забезпечує два рівня масштабованості.
- Масштабованість дій .Повишеніе числа користувачів і збільшення трафіку відбувається безперешкодно за рахунок постійного розподілу запитів, що дозволяє надавати рівний доступ всім клієнтам до додатка або службі.
- Масштабованість системи .У кластер можна включати додаткові компоненти (сервери або процесори).
керованість
Адміністрування Network Load Balancing відбувається ефективно, оскільки кластер управляється як єдине ціле з однієї точки управління (яка може бути віддаленою). Адміністратори керують кластером, використовуючи команди оболонки і скрипти для запуску, припинення роботи і управління кластером. Крім того, можливість перекладу окремих серверів в автономний режим без зниження продуктивності кластера спрощує обслуговування і модернізацію операційних систем.
архітектура NLB
Алгоритм, певний під час процесу злиття кластера, дозволяє кожному вузлу кластера вирішувати, потрібно або не потрібно обробляти черговий клієнтський запит. Оброблювальний вузол відправляє пакет в стек протоколів IP, а всі інші вузли відкидають цей пакет. Для кожного хоста можна задати його відсоток навантаження або розподіляти навантаження рівномірно серед всіх хостів.
NLB перехоплює тільки пакети TCP і UDP. Пакети інших протоколів IP передаються в стек протоколів і обробляються всіма вузлами NLB-кластера.
Устаткування і протоколи
Вступники клієнтські запити відображаються в хости кластера за допомогою розподіляє алгоритму. При надходженні пакета всі хости виконують відображення одночасно. Це дозволяє швидко визначити, який хост повинен обробляти даний пакет. Цей алгоритм одночасної фільтрації є більш ефективним для обробки пакетів, ніж програми, що використовують централізовані алгоритми балансування навантаження. Централізована фільтрація передбачає модифікацію і повторну передачу пакетів, що може збільшувати час затримки. З іншого боку, одночасна фільтрація забезпечує високу загальну пропускну здатність.
NLB управляє розподілом по з'єднаннях для TCP і по дейтаграмою для UDP, застосовуючи фільтрацію вхідного трафіку, перш ніж відбувається звернення до програм протоколу TCP / IP. В TCP / IP обробляються тільки протоколи TCP і UDP, і все управління застосовується на рівні портів.
NLB можна конфігурувати для обробки трафіку кластера більш детально шляхом використання таких коштів, як правила для портів або спорідненість (affinity). Більш детальну інформацію див. Нижче в розділі "Установка і конфігурація Network Load Balancing".
Віртуальні кластери
Віртуальні сервери мають такі властивості.
конфігурація додатків
Є кілька способів конфігурації додатків в NLB-кластері. Кластер можна конфігурувати таким чином, щоб копія серверної програми виконувалася на кожному хості; або додаток може виконуватися на одному хості, коли всі запити відправляються на цей хост замість рівномірного розподілу навантаження по всьому кластеру. Прийняте рішення залежить від типу програми. Наприклад, додатки, яким потрібна централізація, такі як Microsoft Exchange Server, належать якогось одного хосту. Крім того, запити записи в базу даних можуть відправлятися на виділений сервер бази даних в системі. Якщо навантаження по базі даних збалансована в кластері, то кожен вузол кластера може мати свою власну копію цих даних. Оновлення у вмісті таблиці бази даних повинні синхронізуватися шляхом регулярного злиття в режимі offline. Однак в більшості випадків критично важливі бази даних розгортаються в середовищі кластера серверів, що дозволяє виконувати переходи по відмовах (failover), а не в середовищі NLB (див. Нижче розділ "Кластери серверів").
NLB в чистому вигляді найбільш підходить для нецентралізованого зберігання даних або для додатків, які не приймають даних від клієнтів, що виконують доступ до сервера (тобто для доступних тільки з читання додатків на основі протоколу TCP або UDP). Веб-сайти є ідеальними "кандидатами" для використання з NLB, оскільки це дозволяє легко постачати кожен хост поточної копією сторінок (які зазвичай є статичними), забезпечуючи простоту і швидкість обробки великих обсягів трафіку. Для веб-клієнтів, яким потрібен доступ до бази даних, веб-сервери можуть направляти запити на сервер бази даних. Є також такі кандидати, для яких підходить NLB:
- HTTP, HTTPS, FTP, TFTP і SMTP поверх TCP / IP
- HTTP через SSL - порт 443
- FTP - порт 21, порт 20, порти 1024.65 і порт 535
- SMTP - порт 25
- Terminal Services - порт 3389
- Веб-сервери (такі як Microsoft Internet Information Services) - порт 80
- Веб-сервери, що використовують кругову DNS
- Сервери віртуальних приватних мереж (VPN)
- Сервери потокового медіа.
Додаток можна розгортати в NLB-кластері, якщо кілька примірників цієї програми можна виконувати одночасно без помилок або якого-небудь збитку.
Сервери додатків і з'єднання із змінним станом
Є два види з'єднань між клієнтами і хостами для серверів додатків, і вони зазвичай описуються терміном stateful-з'єднання (з'єднання із змінним станом).
- Interclient-стан (стан з урахуванням всіх клієнтів). Оновлення синхронізуються з транзакціями, виконуваними для інших клієнтів. Прикладом є оновлення бази даних запасів на сайті e-commerce після продажу товарів за допомогою бездротової технології з клієнтом.
- Intraclient-стан (стан на рівні одного клієнта). Стан, підтримуване для конкретного клієнта протягом одного сеансу, що включає, наприклад, продаж продуктів (зазвичай за допомогою процесу обробки "торгової візки") на сайті e-commerce. Насправді для більшості сайтів e-commerce процес обробки "торгової візки" може охоплювати кілька окремих з'єднань з одним клієнтом.
Служба NLB діє найкраще, якщо вона використовується, щоб забезпечувати масштабованість для інтерфейсних служб, що не змінюють свого стану (наприклад, для стандартного веб-додатки HTTP), навіть якщо ці служби виконують доступ до поділюваного прикладного сервера баз даних.
NLB ніколи не слід використовувати з interclient-з'єднаннями. Додатки, які використовують цей тип stateful-з'єднання, не дозволяють кілька примірників з'єднань, за допомогою яких виконується доступ до поділюваного базі даних і відбувається одночасна синхронізація оновлень.
NLB можна використовувати для масштабованості додатків з intraclient-станами, навіть в рамках сеансу, що охоплює кілька з'єднань. При включенні однієї з опцій спорідненості (affinity) для клієнтів NLB направляє всі TCP-з'єднання на один і той же хост кластера, що дозволяє підтримувати стан сеансу в пам'яті цього хоста. (Для клієнт / серверних додатків, які вбудовують стан в cookie-файли або відправляють його в прикладну базу даних, не потрібно спорідненість для клієнтів.)