Задать приоритет ip-адресов.

Главная Форумы POWER Systems AIX/Hardware Задать приоритет ip-адресов.

В этой теме 21 ответ, 7 участников, последнее обновление  Alexandru 9 года/лет, 3 мес. назад.

  • Автор
    Сообщения
  • #2183

    DanGer
    Участник

    И снова, здравствуйте!

    Помогите еще раз с настройкой кластера (если это проблема кластера).

    В общем, вопрос таков:

    Двунодовый кластер. Каждый узел имеет статичные ip-адреса, пусть будут 1.1.1.1 и 1.1.1.2. При помощи HACMP им присваивается еще один адрес – сервис ip 1.1.1.5. Требуется все исходящие пакеты соединения пустить через 1.1.1.5, а все приложения и сама ОС “пихает” пакеты в “статику”.

    Подскажите решение.

    Заранее спасибо!

  • #2186

    _KIRill
    Хранитель

    Для начала вопрос. Сервисный IP вы каким образом хотите на интерфейсы вешать? via Alias или Adapter Swapping? Если первое, то сервисный IP должен находиться в другой подсети. Можно поподробнее об аппаратно-программной конфигурации?

    ---As If, But Not---

  • #2187

    DanGer
    Участник

    Что такое “Adapter Swapping”? Насколько объяснили спецы, что ставили кластер, НЕОБХОДИМО чтобы персистант и сервис адреса были в одной посети.

  • #2189

    _KIRill
    Хранитель

    я говорю о boot и service ip address, а не о persistence. persistence может вообще не быть.
    Adapter Swapping – механизм замены boot ip на service путем выполнения кластером команды ifconfig
    (точнее многократного выполнения). Это механизм использовался в HACMP изначально. Имеет ряд недостатков. На текущий момент, наиболее популярным механизмом является Aliasing.

    ---As If, But Not---

  • #2199

    Дмитрий
    Участник

    Между прочим, елси в AIX есть несколько IP-адресов из одной подсети, то мы не можем указать, через какой конкретно интерфейс послылать пакеты.
    (Именно поэтому есть правило присвоения “boot” адресов на узлах – на каждом узле все интерфейсы должны быть в разных IP-подсетях).
    Таким образом, если Вам необходимо, чтобы пакеты уходили именно с 1.1.1.5, то “статика” (я так понимаю, Вы имеете в виду persistent) должна быть у другой IP-подсети.

    (по телефону это от меня ускользнуло, поэтому всегда и советую – пишите на Форум).

  • #2200

    Ihar
    Участник

    Может я не правильно понял вопрос, но унас на двух машинах в кластере работают по ресурсу, каждый со своим IP, но из одной посети. При переводе обоих ресурсов на одну машину, выход трафика через определённый интерфейс решается просто: route add ip router -i eni. Да один из ресурсов всегда слушает, а второй и сам устанавливает соединения.

  • #2201

    Дмитрий
    Участник

    zubrag, Вы правы, но только если трафик идёт в другую IP-сеть. А если destination в той-же, что и source, то нельзя.

  • #2202

    Ihar
    Участник

    А если через default gateway
    что-то типа:
    route delete 0 …
    route add 0 ip -i eni

  • #2220

    Дмитрий
    Участник

    И что?
    На gateway пойдут пакеты, предназначенные НЕ для “своей” сети.

  • #2243

    Oleg
    Участник

    В tcp/ip есть такой параметр – mpr_policy.

    There is a new no option in AIX 5.3 сalled mpr_policy, which allows the configuration of TCP/IP to ensure that packets for a particular destination will only come from one adapter. To configure TCP/IP to use an adapter based on the destination of the packet, use mpr_policy = 5. We recommend that this is set if any applications are sensitive to the adapter from which the packet comes – e.g., for NFS.

    Сам я не пробовал и не совсем понимаю как это работает. Хорошо, “only one adapter”, но какой именно, если их несколько?

  • #2249

    Ihar
    Участник

    to Dmitry
    На сколько я помню, туда пойдут все пакеты, для которых нет спец маршрутов, плюс для спорных определение маршрута пойдёт тоже тудой.
    Ну и наконец ни кто не отменял весов маршрутов.
    На нужный интерфейс прописываешь маршрут с более (или менее) весом, и всё пойдёт куда хочется, никуда не денется.

  • #2270

    Дмитрий
    Участник

    zubrag, но сначала ищется “implicit route” (если я правильно написал).
    Наиболее точный марширут, на свою сеть, он автоматом добавляется, когда Вы интерфейс настраиваете.
    К тому-же здесь обсуждается кластерная конфигурация, и с правилами, описанными в документации (и при этом реально работающими), я спорить не буду.

  • #2275

    Ihar
    Участник

    Каюсь, был не прав!
    А по поводу данной конфигурации, я бы перебил её.
    Бутовые адреса левые, как в книжках, причём каждый интерфейс в своей подсетке (интерфейс на машине), усли надо для администрирования, то постоянный из отдельной подсети.
    А так, как показывает опыт, даже если сейчас решить эту проблему, по она вылезет боком, если не сразу, по припереходе на следующие версии AIX/HACMP 102%.

  • #2526

    Alexandru
    Участник

    ЗДР! Возникла такая же проблема. Есть 2 узла сконфигурированные с IP Takeover via aliases.
    Каждый узел имеет по 2 сетевых адаптера:
    ——————————
    Node1 – host for APP1

    en0
    192.168.1.1 – base IP node1
    192.168.3.10 – service app1 IP

    en1
    192.168.2.1 – base IP node 1
    192.168.3.1 – persistent IP Node 1
    ——————————
    Node2 – host for APP2

    en0
    192.168.1.2 – base IP node 2
    192.168.3.20 – service app2 IP

    en1
    192.168.2.2 – base IP node 2
    192.168.3.2 – persistent IP Node 2
    ——————————

    APP1 имеет другой шлюз, соотвественно в script-е для старта APP1 прописанно route add -net 10.10./16 192.168.3.11 -if en0.
    Данный шлюз пропускает только пакеты c адресса 192.168.3.10(Service app1 IP).
    Проблема в том что на Node1 всё работает прекрасно.
    Когда отдаю ресурсы второму узлу(Node2) то данный шлюз не пропускает пакеты (script добавляет маршрут для en0 на втором узле.).
    При “захвате” ресурсов с Node1 на Node2 Service IP APP1 прописывается на en0:

    Node2 after Resource Takeover:

    en0
    192.168.1.2 – base IP node 2
    192.168.3.20 – service app2 IP
    192.168.3.10 – service app2 IP

    en1
    192.168.2.2 – base IP node 2
    192.168.3.2 – persistent IP
    ——————————

    Нет возможности посмотреть логи на шлюзе(нет никакого доступа). Не могу сказать как видет пакеты шлюз когда Service app1 IP находится на втором узле (Node2). Но есть такое ощющение что видет как бы пакеты отправляеются с Service app2 IP. Когда кластер не работает то если добавить в ручную 192.168.3.10 – service app1 IP как алиас дла en0 на Node2, то шлюз пропускает пакеты.

    При “захвате” ресурсов с Node2 на Node1, Service IP APP2 прописывается на en0, и всё работает (то есть, шлюз пропускает пакеты дла Service APP1 IP):

    Node1 after Resource Takeover:

    en0
    192.168.1.1 – base IP node1
    192.168.3.10 – service app1 IP
    192.168.3.20 – service app2 IP

    en1
    192.168.2.1 – base IP node 1
    192.168.3.1 – persistent IP
    ——————————

    Default Gateway отсуствует. Возможно проблема в очереди IP адрессов после перехвата ресурсов?
    Помогите PLZ.

  • #2551

    Дмитрий
    Участник

    route add -net 10.10./16 192.168.3.11 -if en0
    Для начала надо убрать -if en0 т.к. мы заранее не можем знать, где будет “висеть” IP. Это можно определить скриптом (т.е., узнать, где он сейчас висит).
    Частично проблему можно решить политикой Anti-Colocation (или другой, это навскидку), чтобы сервисные IP были на разных интерфейсах, но эта политика и так стоит по-умолчанию.

    Мне видится, что для данной конфигурации решения нет.
    Альтернативы:
    1. Сделать сервисные и персистент в разных ip-подсетях; добавить сетевые адаптеры.
    2. На маршрутизаторе разрешить принимать пакеты от App1, App2, Pers1, Pers2. (можно Pers. убрать в другую сеть, тогда на маршрутизаторе про них можно забыть).

  • #2553

    Ihar
    Участник

    route delete …
    netstat -i|grep ip| read aaa bbb
    route add -net … ip_router -if $aaa

    Унас такая … прописана в стартовом скрипте ресурса, в стоповом, сооивеиственно удаляются маршруты.

  • #2554

    Дмитрий
    Участник

    zubrag, спасибо, это поможет определить, на каком интерфейсе висит нужный адрес.
    Но что делать, если на узле 2 сетевых интерфейса, на каждом – свой IP, оба из одной подсети, и для каждого нужно прописать свой маршрут?
    Хм.
    Проблема решаема, если это не маршрут на сеть “0”.
    route add -net DestinationA gateway_A -if interface_A
    route add -net DestinationB gateway_B -if interface_B

  • #2558

    Alexandru
    Участник

    Спасибо за ответы.
    Решил проблему следующим образом:
    В скрипте для старта APP1 добавил команды для удаления алиаса с одной NIC, и добавления на другой NIC:

    ifconfig en1 delete 192.168.3.10
    ifconifg en0 add 192.168.3.10

    соотвественно route определяется с помощью скрипта.

    #START Add route for APP1
    APP1_SERVICE_IP=192.168.3.10
    APP1_GATEWAY_IP=192.168.3.11
    APP1_INTERFACE=`netstat -in|grep $APP1_SERVICE_IP|awk ‘{print $1}’`
    HOST=`hostname`

    if [[ -z APP1_INTERFACE ]]; then
    echo “$APP1_SERVICE_IP not found on any interface.”
    echo “Please check HACMP configuration.”
    exit 1
    else
    echo “System hostname is $HOST, adding route to APP1 using interface $APP1_INTERFACE”
    route add -net 10.10/16 $APP1_GATEWAY_IP -if $APP1_INTERFACE
    fi

    #END Add route for APP1

    Конечно это не решение, при отключения одного интерфейса сервисный IP сного прописшется послендим на другой интерфейс.
    И скрипт тогда можно было бы ограничить в простой командной строке:
    route add -net 10.10/16 192.168.3.11 -if en0

  • #2559

    Pit
    Участник

    не красиво 🙁
    1. все нужно делать по моему B) (шутка)
    2. адреса должны быть из разных сетей
    3. разборки с роутингом надо делать не в старт и стоп скриптах
    а в pre and post events. но то все надо документировать – ведь
    будут проблемы с миграцией

    PS: не подскажите зачем именно с сервис IP надо слать пакеты ? какая разница?

  • #2561

    Ihar
    Участник

    Не знаю не знаю… Мы пробовали на старой системе делать всё в PRE & POST event скриптах, но со временем забывается, где что лежит, и начинается бешеный поиск по всем событиям…
    (документировано всё, запротоколировано, а недавно аудит заставил написать инструкцию “поклавишную” администратора (типа для полного чайника), и не …, что чайника к серверам на выстрел ни кто не подпустит) (прошу прощения, накипело!!!).
    Продолжаем разговор…
    А работа с старт-стоп скриптами ресурсной группы имеет один ОГРОМНЫЙ плюс- всё в одном месте, легко правится, легко отслеживается (всегда на виду)

  • #2568

    Дмитрий
    Участник

    Согласен с zurbag, в старт/стоп скриптах нагляднеею
    Но если надо что-то вставить в другое место – не в момент старта/стопа приложения, тогда деваться некуда.

    А “исправление”, предложенное apstudio, мне _очень_ не нравится. Корявое оно. Я даже толком не вник в его содержимое, но руками перебрасывать ip в кластере – это неправильно…

  • #2577

    Alexandru
    Участник

    ЗДР!
    Я немножко не правильно написал команду
    ifconifg en0 add 192.168.3.10
    правильно так вроде:
    ifconifg en0 alias 192.168.3.10

    Только сервисные IP в одной подсети, остальные из разных(как в книжке).

    В stop script-е route удаляется. То есть в START script-е APP1, route добавляется, это и логично, потому что при аварийном збое APP1 переходит на другой узел (там этой route нету) и соотвественно при старте APP1 добавляется route, так как правильный старт APP1 зависит напрямую от внешнего сервера, если APP1 не видит внешнего сервера, то она не стартует, соотвественно APP1 будет недоступной. Может я не понял что pit имел ввиду 3. разборки с роутингом надо делать не в старт и стоп скриптах

    А надо слать пакеты именно с сервис IP, потому что APP1 подключается к внешнему серверу через данный шлюз на котором прописанно что именно даный IP может принать/отослать пакеты и которого администрирует другая контора, а чтобы они изменили что то на нём, надо им целую эпопею писать и даже платить.

    Согласен с Dmitry по поводу но руками перебрасывать ip в кластере – это неправильно…
    Но другого решения пока что не нашёл кроме этой или использовать Take over via Replacement (но этот вариант более тормознутый).

    Спасибо всем за советы.

Для ответа в этой теме необходимо авторизоваться.