Cool Solutions: розгортання балансування навантаження для NBM за допомогою відключення сеансів і перемикача L4

1. Зміст Вступ Цільова аудиторія Передумови / припущення Фон Novell BorderManager Proxy Відмова...
2. Фон
3. Запропоноване рішення
4. Кроки налаштування
5. Висновок
6. Довідка

Зміст

Вступ
Цільова аудиторія
Передумови / припущення
Фон
Novell BorderManager Proxy
Відмова від сесії за допомогою BorderManager 3.8.4
Як працює сеанс відмови
Балансування завантаження проксі-сервера BorderManager
Запропоноване рішення
Інформація про мережу
Кроки налаштування
Налаштування служби HTTP на проксі BorderManager
Налаштування агента Auth
Запуск агента Auth
Налаштування проксі-сервера для відмови від сеансу
Запуск агента проксі
Налаштування комутатора L4
Перевірка налаштувань
Висновок
Довідка

Вступ

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

Ця програма використовує цю концепцію і надає рекомендації для розгортання Novell BorderManager Proxy з можливостями балансування навантаження для обслуговування ряду користувачів. Це рішення спирається на використання декількох серверів ферми BorderManager 3.8.4, підключених через комутатор Layer-4. Він також використовує функцію відмови сеансу від Novell BorderManager 3.8.4.

Цільова аудиторія

Ця AppNote призначена для тих, хто бажає:

• Ефективне використання проксі-серверів BorderManager у розгортанні декількох проксі-серверів.
• Можливості балансування навантаження комутатора L4 для проксі BorderManager для високої доступності.
• Можливість відмови від сеансу в розгортанні декількох проксі-серверів BorderManager (тобто, надайте послугу 24 x 7, навіть якщо втрачено підключення до будь-якого проксі-сервера).

Передумови / припущення

Користувачі / Адміністратори знайомі з користувачами Novell BorderManager Proxy / Адміністратори знають, як налаштувати проксі-сервіси, наприклад, використання NWADMIN. Адміністратори працювали над комутатором L4, який вони мають намір використовувати з цим рішенням. У цьому AppNote ми на високому рівні розглядаємо те, що потрібно налаштувати для роботи комутатора з Novell BorderManager.

Фон

Novell BorderManager Proxy

Існує три основні програми проксі Novell BorderManager: Forward, Reverse і Transparent. HTTP forward проксі-сервер Novell BorderManager використовується більшістю організацій для забезпечення доступу до Інтернету своїм співробітникам. Прямий проксі-сервер є однією з широко використовуваних функцій через кешування, аутентифікації та можливостей однократного входу.

Проксі Novell BorderManager не має вбудованих можливостей балансування навантаження, за винятком випадків, коли розгортається як кластер. Однак балансування навантаження в сценарії кластера все ще вимагає від користувачів повторної автентифікації під час перемикання проксі-серверів. Проте Novell BorderManager надає перевагу в середовищі кластера - кешована інформація буде доступна з іншими вузлами кластера. Після завершення повторної автентифікації новий вузол проксі-сервера може обслуговувати веб-запити з кешу. Незважаючи на те, що інформація кешування спільна з усіма вузлами кластера, інформація автентифікації не використовується спільно. Тепер з випуском BoderManager 3.8.4, проксі може обмінюватися інформацією аутентифікації, використовуючи функцію переходу на сеанс.

Відмова від сесії за допомогою BorderManager 3.8.4

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

Як працює сеанс відмови

Це рішення має дві складові: Auth Agent і Proxy Agent. Як правило, в системі встановлено один агент агента і проксі-агент, налаштований на кожен проксі-сервер BorderManager. Усі об'єкти поділяють подібний файл конфігурації, який визначає агента Auth і всі агенти-проксі в системі.

Агент агента - це центральна сутність, яка збирає інформацію від декількох проксі-агентів і розподіляє її всім іншим проксі-агентам. Це забезпечує обмін інформацією про аутентифікацію між усіма проксі, налаштованими на використання агента Auth. Навіть якщо користувач аутентифікований лише одним проксі-сервером, ця інформація буде спільною з усіма іншими налаштованими проксі-серверами. Auth Agent - це java-додаток, який може бути розгорнутий на сервері NetWare або Linux.

Проксі-агент - це новий authchk.nlm, який виконується в кожному з проксі-серверів, налаштованих для переходу на сеанс. Агенти-проксі працюють на кожному проксі-сервері BorderManager і несуть відповідальність за інформування агента Auth про кожен вхід, вихід або час очікування. Всякий раз, коли подібна подія відбувається в будь-якому іншому проксі, агент auth пересилає інформацію до кожного проксі-сервера, на якому налаштовано проксі-агент. Проксі-агент оновлює таблицю локального аутентифікованого користувача при отриманні інформації від агента Auth.

Балансування завантаження проксі-сервера BorderManager

До Novell BorderManager 3.8.4 (тобто з можливістю відмови від сесії) не вдалося забезпечити прозоре балансування навантаження для проксі-серверів. Як згадувалося раніше, розгорнутий на кластерах проксі-сервер може забезпечити перехід на відмову, але він не є прозорим, і користувач повинен повторно перевірити автентичність до нового проксі-сервера. З введенням функції відмови від сеансу, тепер усі проксі-сервери в розгорнутій мережі можуть бути налаштовані на обмін інформацією про аутентифікацію. Це дозволило використовувати балансування навантаження для проксі-серверів BorderManager.

Запропоноване рішення

Щоб забезпечити можливості балансування навантаження, комутатор L4 налаштований для розподілу навантаження між різними проксі-серверами. Проксі-сервери Novell Border Manager налаштовані за комутатором L4. Проксі-сервер налаштовується з функцією переходу на сеанс для обміну інформацією про аутентифікацію.

На малюнку 1 показана установка зразка, яка використовується для цілей цього AppNote. Докладна інформація про налаштування описана в розділі 5.2. У пропонованому рішенні балансування навантаження типова послідовність взаємодії між користувачами, комутатором L4, Novell BorderManager Proxy (Проксі-агент) і агентом Auth описана нижче.

Ось процес:

1 . Користувач аутентифікується через комутатор L4 до будь-якого з проксі-серверів (обраних за допомогою перемикача L4).

2 . Як тільки аутентифікація пройшла успішно, проксі-сервер посилає інформацію аутентифікації агенту Auth, який, у свою чергу, передає його іншим проксі-серверам в установці.

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

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

5 . У разі виходу користувача або таймауту аутентифікації користувача інформація передається всім проксі через агента Auth (як у кроці 2).

Рисунок 1 - Схема мережі для налаштування балансування навантаження

Інформація про мережу

Нижче наведено деталі налаштування мережі, як показано на малюнку 1. \ t

Проксі (сервер BorderManager)

Всі сервери NBM налаштовані з проксі-сервером HTTP, а аутентифікація включена. Ці сервери мають приватний інтерфейс у мережі 10.xxx і публічний інтерфейс у мережі 192.168.10.x.

Бренд: Dell Power Edge 2650 series
Процесор: Intel xeon 1.8 Ghz
ОЗУ: 2 ГБ

L4 Перемикач

Перемикач L4 налаштований для балансування навантаження між трьома проксі-серверами. Він знаходиться в тій же мережі, що й клієнти, і приватний інтерфейс серверів BorderManager. Для цієї установки він також забезпечує зв'язок між проксі-сервером і агентом Auth.

Бренд: Alteon 184 series
Версія ОС: 10.0.32.1

Клієнти

Бренд: Connoi
Процесор: Intel Pentium 4
ОЗУ: 1 ГБ

Кроки налаштування

Налаштування служби HTTP на проксі BorderManager

Щоб налаштувати сервер Border Manager для Forward Proxy, скористайтеся наведеним нижче посиланням, де наведено детальну інформацію:

Налаштування агента Auth

Auth Agent може бути налаштований на Netware або Linux серверах; це AppNote має справу з Linux. Щоб налаштувати агента Auth,

1 . Створіть auth.cfg у каталозі / etc / proxy (SYS: / ETC / PROXY / для NetWare).

2 . Скопіюйте bmauth.jar в систему, де налаштовується агент Auth.

3 . Створіть auth.cfg у каталозі / etc / proxy (SYS: / ETC / PROXY / для NetWare). Ви можете скопіювати зразок файлу auth.cfg в папку / etc / proxy з папки SYS: / ETC сервера BorderManager.

4 . Змініть файл відповідно до налаштувань.

Агент агента та проксі-агент повинні мати можливість зв'язуватися один з одним. Виберіть інтерфейс проксі-сервера в тій самій мережі, що і агент Auth.

Наприклад, файл auth.cfg для налаштування на малюнку 1 буде виглядати так:

Рисунок 2 - файл auth.cfg для агента Auth

У наведених вище зразках конфігурації 1, 2 і 3 є унікальними проксі-ідентифікаторами для агента-проксі-1 (10.10.1.1), проксі-агента-2 (10.10.1.2) і проксі-агента-3 (10.10.1.3). 10.10.1.5 - це IP-адреса сервера, на якому запущений агент Auth.

Запуск агента Auth

Java повинна бути встановлена ​​на вашому сервері, де налаштований агент Auth. Для запуску агента Auth використовуйте таку команду:

java -classpath <full_path_of_bmauth.jar> com.novell.bordermanager.proxy.auth.AuthDB

Налаштування проксі-сервера для відмови від сесії

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

1 . Перш ніж запускати проксі-агент, переконайтеся, що налаштований і запущений агент Auth.

2 . Скопіюйте зразок файлу auth.cfg до папки SYS: / etc / proxy з папки SYS: / ETC сервера BorderManager. Наприклад, файл auth.cfg для першого проксі-сервера в налаштуванні буде виглядати так:

Рисунок 3 - файл auth.cfg для проксі-сервера

Знову ж таки, у вищезазначеному файлі зауважте, що 1, 2 і 3 є унікальними ідентифікаторами проксі для агента проксі-1 (10.10.1.1), проксі-агента-2 (10.10.1.2) і проксі-агента 3 (10.10.1.3). 10.10.1.5 - це IP-адреса сервера, на якому налаштований агент Auth.

Примітка : У обох файлах auth.cfg кожен окремий проксі-агент для локального агента повинен додати значення "localhost".

Запуск агента проксі

На консолі Netware вашого проксі-сервера BorderManager запустіть stopbrd і startbrd після налаштування файлу auth.cfg. Після перезапуску служб BorderManager служба проксі-сервера починається з проксі-агента. Екран реєстратора вказує, що перехід на сеанс включений.

Налаштування комутатора L4

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

1 . Додайте всі проксі-сервери BorderManager як "справжні сервери" (проксі).

2 . Налаштуйте IP-адресу та додайте порт для послуги, що надається кожним сервером. Для розгортання порти 8080 і 443.

3 . Налаштуйте групу з трьома реальними серверами, налаштованими на наведеному вище етапі. Ця група діє як пул для балансування навантаження.

4 . Налаштуйте Virtual Server з послугами, наданими для портів 8080 і 443.

5 . Приєднайте групу, створену на кроці 3, до цієї віртуальної служби, яка дозволяє комутатору L4 виконувати балансування навантаження між реальними серверами.

6 . Налаштуйте алгоритм балансування навантаження, який буде використовуватися для розподілу навантаження між усіма проксі-серверами. Для цього AppNote використовувався алгоритм балансування навантаження HASH (який пов'язує клієнтів з певним сервером на основі IP-адреси клієнта).

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

Перевірка налаштувань

1 . Налаштуйте налаштування проксі-сервера для браузера на клієнті, використовуючи IP-адресу комутатора L4 як адресу проксі-сервера, а порт - 8080.

2 . Запустіть HTTP-сесію від клієнта.

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

Висновок

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

Довідка

Онлайнова документація для BorderManager Session Failover:
http://www.novell.com/documentation/nbm38/index.html?page=/documentation/nbm38/inst_admin/data/bxizbb7.html#bxizbb7

Novell Cool Solutions (корпоративні веб-спільноти) виробляються WebWise Solutions. www.webwiseone.com