Как решить проблему round-robin dns при общении с HTTP API?

Question

[Александр]

Товарищи, доброго утра. =) Есть проблема на уровне дизайна скрипта, никак не могу сообразить,
подскажите кто чем может, пожалуйста.
Есть скрипт, который опрашивает по HTTP устройство в сети. Перед отправкой основного запроса требуется
аутентификация - отправляется хэш от "имя_пароль" (так же по HTTP), в ответ получаем токен, который
потом прикрепляем к заголовкам основного запроса.
У девайса может быть два контроллера, у каждого свой IP к которому мы можем обратиться. Так вот, если
мы настроим оба IP на одну DNS запись (round-robin), то при обращении к DNS, без использования кэширования
DNS, будем с посылать запросы то к одному контроллеру, то к другому. Т.е. мы можем получить токен аутентификации
от контроллера А, а уже следующим запросом попытаться получить данные с этим токеном от контроллера B.
Если использовать IP адрес для подключения, такой проблемы нет, но я пытаюсь реализовать подключение по
HTTPS с проверкой сертификата, где, как я понимаю, обязательно использовать FQDN, который приходится
разрешать в IP. Может быть requests имеет какие-то хитрые механизмы для этого?
Если нужно, вот код на GitHub:
https://github.com/asand3r/zbx-hpmsa/blob/master/z...

Comments

[Алексей Уколов]

Это не в клиенте, а на сервере, который использует round-robin, должно реализовываться - его область ответственности. Называется sticky session.

[Александр]

Алексей Уколов, тут Windows DNS, не слышал чтобы он мог sticky session. Умной балансировкий нет. Хотелось бы решить со стороны скрипта, т.к. решение планируется более или менее универсальным.

[Алексей Уколов]

Поставить перед всей этой системой nginx нельзя? Он бы и сертификат отдавал и балансировал запросы между ip и сессии приклеивал. Тогда вообще round-robin не нужен.

[Александр]

Алексей Уколов, нет. =) Опрашивается дисковая полка от HP. У нее есть HTTP API, вот с ним и общаемся.

[Алексей Уколов]

Ну так nginx и будет проксировать туда запросы, ничего измениться не должно - вместо ip вы используете доменное имя, это имя резолвится на какой-то третий ip, где стоит nginx, а он уже перенаправляет все запросы по нужным адресам.

[Александр]

Алексей Уколов, будет слишком сложное решение, как мне видится.

[Алексей Уколов]

Да, если опыт настройки nginx нулевой, это может занять какое-то время (хотя, запросов "nginx load balance" и "nginx sticky session" должно хватить с головой).
Но с архитектурной точки зрения это было бы правильнее - если сервер устраивает карусели с round-robin (или любой другой балансировкой нагрузки), ему и обеспечивать незаметность всей этой системы для клиентов.

[Александр]

Алексей Уколов, хм, я может быть описал ситуацию как-то некорректно но не совсем понимаю какой сервер имеется в виду. Чуть дополню - скрипт пишется для системы мониторинга Zabbix. Он вызывается серверным процессом с аргументами и просто завершается. По сути, не считая дополнительных действий в виде парсинга и работы с кэшем, он делает два GET запроса к API дисковой полки. Т.к. контроллера два, то и IP два; а вот DNS имя у них одно на двоих из-за чего я и схватил проблему с RR. Мне просто не понятно как к такой системе пристроить балансировщик, будь то nginx или haproxy. Т.е. да, прикрутить можно (опыт с haproxy есть), но в этой ситуации оно будет вот прям лишним, на мой взгляд. Хочется решить это дело на уровне скрипта... Я думал, что может быть можно протащить всю работу через одно HTTP соединение, устанавливая его в начале работы и закрывая в конце, но т.к. HTTP ссылка меняется, скорее всего так не получится.

[Сергей Тихонов]

Александр, а почему у вас на два контроллера один DNS? Мониторить-то оба контроллера надо отдельно.

• можно сделать два DNS и больше ничего не менять
  
• можно ходить напрямую к IP, передавая его из zabbix (для этого надо будет добавить в запрос заголовок Host с нужным DNS-именем)
  
• если использовать requests.Session, то один раз установленное соединение будет переиспользовано для всех последовательных запросов до закрытия этой сессии