пообщаться возможность есть, НО устанавливать nginx не нужно, потому как он есть где-то в вашей сети
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Всем привет. Поднимем мёртвый топик 
Не совсем по вопросу автора , но в тему web-домины.
Собрался переделывать текущую инфраструктуру серверов в более оптимальную, и вдобавок сразу же с направлением на WEB, но не могу понять как правильно сконфигурировать Internet Cluster Manager (ICM). Уже раз 5 перечитал хелпер на сайте hcltehsw по теме ICM, но так и не врубился.
Хотел поэкспериментировать и на текущих тестовых серверах отработать варианты и без помощи видимо совсем никак.
Предполагаемая структура такая:
1) Есть два сервера в кластере "А", на которых поднята авторизация пользователей через NFL. Назовём их авторизационные. А1 и А2
2) Есть кластер из серверов "Б" с базами Б1-Б2-Б3
3) Есть кластер из серверов "В" с другими базами В1-В2-В3
-- Предполагаемая схема работы такая --
1) Пользователь заходит по ссылке а-ля "weblotus/" его балансит на сервер либо А1, либо на А2 в зависимости от нагрузки и доступности.
2) На А1-А2 приветственная страница с ссылками на базы в кластерах вида "Б/база1.nsf" // "Б/база5.nsf" // "В/база2.nsf" // "В/база3.nsf" и т.д.
3) Пользователь уходит по ссылке к примеру на "Б/база1.nsf" и его балансит по кластеру Б , допустим на Б2 по загруженности.
4) Оттуда при отправке на домашнюю страницу или по переходу через линк документа (допустим в БД "Б2/база1.nsf" есть линк на документ в БД "В3/база2.nsf") пользователя опять через балансировщик кидало на менее загруженный сервер.
И вот тут вытекают вопросы:
- обязательно ли к каждому кластеру свой сервер с ICM?
- будет ли схема работать, если поднять ICM на серверах А1 и А2? Или для этого нужен третий сервер в кластер А с ICM, который и будет "входным" под ссылку "weblotus/"?
- Или, к примеру три сервера с ICM, А0 - А1 - А2, А0 будет отвечать за балансировку между А1-А2, а А1 и А2 за балансировку между остальными серверами в других кластерах?
- Другие варианты?
P.s. в последнем блоке варианты типа - угадывание, т.к. не смог до конца понять, как работает ICM.
И главный вопрос - как всё это настраивать? Инструкция на сайте help.hcltehsw, к сожалению мало чем помогает, т.к. там возникают вопросы, на которые нет ответа. К примеру - а будет ли работать по схеме описанной выше, какие параметры и где необходимо для этого указать? обязательно ли создавать настроечный документ интернет-сайта? Какое указывать Имя хоста ICM? Как будет полезна возможность использовать настройку с другого сервера (если тот сервер ляжет, то как считываться она будет)?
Не совсем по вопросу автора , но в тему web-домины.
Собрался переделывать текущую инфраструктуру серверов в более оптимальную, и вдобавок сразу же с направлением на WEB, но не могу понять как правильно сконфигурировать Internet Cluster Manager (ICM). Уже раз 5 перечитал хелпер на сайте hcltehsw по теме ICM, но так и не врубился.
Хотел поэкспериментировать и на текущих тестовых серверах отработать варианты и без помощи видимо совсем никак.
Предполагаемая структура такая:
1) Есть два сервера в кластере "А", на которых поднята авторизация пользователей через NFL. Назовём их авторизационные. А1 и А2
2) Есть кластер из серверов "Б" с базами Б1-Б2-Б3
3) Есть кластер из серверов "В" с другими базами В1-В2-В3
-- Предполагаемая схема работы такая --
1) Пользователь заходит по ссылке а-ля "weblotus/" его балансит на сервер либо А1, либо на А2 в зависимости от нагрузки и доступности.
2) На А1-А2 приветственная страница с ссылками на базы в кластерах вида "Б/база1.nsf" // "Б/база5.nsf" // "В/база2.nsf" // "В/база3.nsf" и т.д.
3) Пользователь уходит по ссылке к примеру на "Б/база1.nsf" и его балансит по кластеру Б , допустим на Б2 по загруженности.
4) Оттуда при отправке на домашнюю страницу или по переходу через линк документа (допустим в БД "Б2/база1.nsf" есть линк на документ в БД "В3/база2.nsf") пользователя опять через балансировщик кидало на менее загруженный сервер.
И вот тут вытекают вопросы:
- обязательно ли к каждому кластеру свой сервер с ICM?
- будет ли схема работать, если поднять ICM на серверах А1 и А2? Или для этого нужен третий сервер в кластер А с ICM, который и будет "входным" под ссылку "weblotus/"?
- Или, к примеру три сервера с ICM, А0 - А1 - А2, А0 будет отвечать за балансировку между А1-А2, а А1 и А2 за балансировку между остальными серверами в других кластерах?
- Другие варианты?
P.s. в последнем блоке варианты типа - угадывание, т.к. не смог до конца понять, как работает ICM.
И главный вопрос - как всё это настраивать? Инструкция на сайте help.hcltehsw, к сожалению мало чем помогает, т.к. там возникают вопросы, на которые нет ответа. К примеру - а будет ли работать по схеме описанной выше, какие параметры и где необходимо для этого указать? обязательно ли создавать настроечный документ интернет-сайта? Какое указывать Имя хоста ICM? Как будет полезна возможность использовать настройку с другого сервера (если тот сервер ляжет, то как считываться она будет)?
Забудь про ICM...Всем привет. Поднимем мёртвый топик
Не совсем по вопросу автора , но в тему web-домины.
Собрался переделывать текущую инфраструктуру серверов в более оптимальную, и вдобавок сразу же с направлением на WEB, но не могу понять как правильно сконфигурировать Internet Cluster Manager (ICM). Уже раз 5 перечитал хелпер на сайте hcltehsw по теме ICM, но так и не врубился.
Хотел поэкспериментировать и на текущих тестовых серверах отработать варианты и без помощи видимо совсем никак.
Предполагаемая структура такая:
1) Есть два сервера в кластере "А", на которых поднята авторизация пользователей через NFL. Назовём их авторизационные. А1 и А2
2) Есть кластер из серверов "Б" с базами Б1-Б2-Б3
3) Есть кластер из серверов "В" с другими базами В1-В2-В3
-- Предполагаемая схема работы такая --
1) Пользователь заходит по ссылке а-ля "weblotus/" его балансит на сервер либо А1, либо на А2 в зависимости от нагрузки и доступности.
2) На А1-А2 приветственная страница с ссылками на базы в кластерах вида "Б/база1.nsf" // "Б/база5.nsf" // "В/база2.nsf" // "В/база3.nsf" и т.д.
3) Пользователь уходит по ссылке к примеру на "Б/база1.nsf" и его балансит по кластеру Б , допустим на Б2 по загруженности.
4) Оттуда при отправке на домашнюю страницу или по переходу через линк документа (допустим в БД "Б2/база1.nsf" есть линк на документ в БД "В3/база2.nsf") пользователя опять через балансировщик кидало на менее загруженный сервер.
И вот тут вытекают вопросы:
- обязательно ли к каждому кластеру свой сервер с ICM?
- будет ли схема работать, если поднять ICM на серверах А1 и А2? Или для этого нужен третий сервер в кластер А с ICM, который и будет "входным" под ссылку "weblotus/"?
- Или, к примеру три сервера с ICM, А0 - А1 - А2, А0 будет отвечать за балансировку между А1-А2, а А1 и А2 за балансировку между остальными серверами в других кластерах?
- Другие варианты?
P.s. в последнем блоке варианты типа - угадывание, т.к. не смог до конца понять, как работает ICM.
И главный вопрос - как всё это настраивать? Инструкция на сайте help.hcltehsw, к сожалению мало чем помогает, т.к. там возникают вопросы, на которые нет ответа. К примеру - а будет ли работать по схеме описанной выше, какие параметры и где необходимо для этого указать? обязательно ли создавать настроечный документ интернет-сайта? Какое указывать Имя хоста ICM? Как будет полезна возможность использовать настройку с другого сервера (если тот сервер ляжет, то как считываться она будет)?
Все что оно хорошо умеет, это разруливать лотусовые ссылки в зависимости от загрузки кластера.
Во всем остальном - покрывается nginx/haproxy.
Да и учет загрузки северов в кластере - можно сделать через bash+curl+agent.
А так - разные кластера лучше обозвать через dns по типу cluster1.domain.net\cluster2.domain.net
Настроить SSO на всех серверах для домена .domain.net.
На nginx разрулить разные кластеры через server конфиг.
Прикрутить липкие сессии по типу:
Будет много гибче и понятно.
а минусы его какие? Ведь в примере как я понял предлагается заменить одну встроенную службу на связку из нескольких ПО? (просто не работал с nginx/haproxy/bash/curl).
Чисто по количеству разве одна служба не лучше нескольких ПО+формирования связки между ними?
P.S. вопрос не для "докопаться", просто пока логики не улавливаю, но не работал ни с чем из вышеперечисленного, в .т.ч. и с ICM
Минус :
1 - этих ICM нужно несколько - по 1 минимум на каждый кластер.
2 - ICM не поддерживает липкие сессии. т е после сохранения документа он может кинуть на другой сервер если хочешь прочитать тут же созданный док.
А док в кластере не мгновенно разлетается
3 - сопровождать этот компот сложнее чем 1 nginx.
4 - ICM не проксирует а *перенаправляет* запрос. т е все 6 серверов должны иметь доступные для пользователя 6 DNS имен.
5 - это решение прибито гвоздями к инфраструктуре - замена, добавление, переконфигурирование принесет дикую головную боль)
6 - если сервер кластера сдохнет - то умирает приложение... ибо для редиректа на живой нужно обратится к ICM еще раз)
Хм, довольно зааргументировано, почти продалМинус :
1 - этих ICM нужно несколько - по 1 минимум на каждый кластер.
2 - ICM не поддерживает липкие сессии. т е после сохранения документа он может кинуть на другой сервер если хочешь прочитать тут же созданный док.
А док в кластере не мгновенно разлетается
3 - сопровождать этот компот сложнее чем 1 nginx.
4 - ICM не проксирует а *перенаправляет* запрос. т е все 6 серверов должны иметь доступные для пользователя 6 DNS имен.
5 - это решение прибито гвоздями к инфраструктуре - замена, добавление, переконфигурирование принесет дикую головную боль)
6 - если сервер кластера сдохнет - то умирает приложение... ибо для редиректа на живой нужно обратится к ICM еще раз)
А можно в таком случае немного подробнее про:
"Во всем остальном - покрывается nginx/haproxy.
Да и учет загрузки северов в кластере - можно сделать через bash+curl+agent."
Если есть опыт настройки на доминоху, естественно
. По моему примеру можешь подсказать более конкретно, на примере изложенном выше несколькими постами?Прочитал общее описание про nginx - довольно интересно, но как уже говорил - не сталкивался с данным вопросом, а планируется настроить web-инфраструктуру на серверах лотуса
Чем дальше в лес, тем крупнее помидоры ?
)наводка - нужно стянуть с сервера кластера availability index каждого его мембера.
скормить башу, что бы он пересчитал коэффициенты и записать веса в файл определения апстрима. ну и nginx -s reload
Короче, ничего сложного - дерзай!
Мда, буквы вижу, слова вижу, а партизаны где-то в кустахЧем дальше в лес, тем крупнее помидоры ?
наводка - нужно стянуть с сервера кластера availability index каждого его мембера.
скормить башу, что бы он пересчитал коэффициенты и записать веса в файл определения апстрима. ну и nginx -s reload
Короче, ничего сложного - дерзай!
)) Попробую разобраться. Думаю в течении месяца вернусь с вопросами ещё.Спасибо!
со скриптом от Нэшеда легко
Bash:
domino cmd "show stat server.expansionfactor" 100 | grep -i server.expansionFactor | tail -1tail - чтобы баден-баден не получился (мало инфы выводит сервер а опрос часто - может быть несколько строк)
учитывая
Ссылка скрыта от гостей
В данном случае expansionfactor не нужен. Его нужно настраивать для "чувствительности" оценки нагрузки )со скриптом от Нэшеда легко100 - это кол-во отображаемых строк (можно увеличивать) т.к. за время работы вызова сервер может "успеть насрать" в консоль многоBash:domino cmd "show stat server.expansionfactor" 100 | grep -i server.expansionFactor | tail -1
tail - чтобы баден-баден не получился (мало инфы выводит сервер а опрос часто - может быть несколько строк)
учитываяСсылка скрыта от гостей
нужен вывод команды sh cl
sh cl
Cluster information:
Cluster name: mh66Cluster, Server name: Server1
Server cluster probe timeout: 1 minute(s)
Server cluster probe count: 45140
Server cluster default port: *
Server cluster auxiliary ports:
Server availability threshold: 0
Server availability index: 65 (state: AVAILABLE)
Server availability default minimum transaction time: 3000
Cluster members (2):
Server: Server1, availability index: 73
Server: Server2, availability index: 65
Вот значения последних строчек нужно привести к диапазону 1-100 например . Алгоритм - можно придумать разный. например у самого большого availability index
значение weight в апстриме будет 1, а у другого как разница между макс значением и мин значением. так же можно обработать значение busy\UNAVAILABLE....
Ссылка скрыта от гостей
т е данные дергать с любого сервера через тот же апстрим. Если сдохнет один сервер кластера - то кто то хоть ответитПо идее - лучший вариант, это дергать через web агента, который через API заберет инфу о кластере. Но как то не добрался до этого вызова API...
Последнее редактирование:
ну значит отгрепать эти две строки из вывода комады
писать агента... я не вижу смысла, не помню - вродить есть модули пистона для нжинкс
Иван Пахомов
Lotus Team
нам энджиникс показался больно сложным. хапрокси у нас летает. всё, что нужно делает
И как прикрутил метрики загруженности кластера?
или просто забили как и я?
Иван Пахомов
Lotus Team
пока эмпирически веса бекам раздали для распределения юзеров. кстати, спасибо за подсказку про липкие сессии! веса подбирали недолго, чтобы примерно одинаково веб откликался юзерам. но мерить время отклика и динамически распределять юзеров, кажется опенсорс версия не может. и энджиникс и хапрокси предлагали подписочку на 2-3куе в год. нам пока это не сильно актуальноИ как прикрутил метрики загруженности кластера?
Обучение наступательной кибербезопасности в игровой форме. Начать игру!