|
|
kaumov@ketz.ru
Цитировать выделенное
|
День добрый!
Есть пожелание следующего вида:
У хоста в настройках ID интернет соединения добавить возможность указания нескольких пользовательских серверов. (настроек)
Можно сделать какой нибудь приоритет по доступности . Просто бывают разные ситуации. Эта опция добавит универсальности продукту. Зачастую у клиентов есть ноутбуки. Те. когда клиент на удаленке один IP ID сервера (если rms mini id server в конфигурации пере адресации), когда у себя в сети клиент уже внутренний IP сервера указан. |
| Профиль |
Сообщений:
44 |
Дата создания:
01.10.2021 06:39:18 |
|
Re: Дополнителный ID server
|
|
|
alex
Модератор
Цитировать выделенное
|
kaumov@ketz.ru,
это просят давно и это не будет реализовано, т.к. если копнуть немного вглубь, станет ясно, что подобные опции приоритета будут постоянно приводить к потере связанности. речь идет, конечно, не про Клиент, где можно просто перебирать несколько серверов на доступность, а речь про Хост. Если данную опцию приоритета Серверов делать, то на нее должен же ведь быть настроен и Хост, это будет постоянно приводить к потере связанности. В случае малейших проблем Хост будет цепляться на разные Сервера.
рекомендую делать резервирование через DNS. Либо создать несколько соединений. |
| Профиль |
Сообщений:
3449 |
Дата создания:
09.10.2021 13:30:40 |
|
Re: Дополнителный ID server
|
|
|
kaumov@ketz.ru
Цитировать выделенное
|
Да жаль.
Про ДНС понятно.
А создание нескольких соединений уточните что имеется ввиду? |
| Профиль |
Сообщений:
44 |
Дата создания:
15.10.2021 08:01:19 |
|
Re: Дополнителный ID server
|
|
|
A_Creature
Цитировать выделенное
|
Тоже давно хотел присоединиться к вопросу failover servers list/priority или cluster servers.
То есть, повышение отказоустойчивости работы хостов через Internet-ID сервера посредством списка серверов по приоритету подключения в ожидании соединения с клиентом или вариант кластеризации (организации группы серверов с постоянно-периодическим обменом информации о хостах).
Сторонний разработчик в лучшем случае сможет организовать одновременный тоннелинг подключений на группу серверов, т.е. некий гейтвэй роутинг, где точка входа одна, но одновременно имеет активные подключения ко всем доступным серверам, при этом подключаясь к любому и серверов, каждый из них будет абсолютным зеркалом и при больших нагрузках (более сотни одновременных подключений через тоннели, из-за разности подключений клиентов и хостов к разным серверам) с неширокими каналами интернета, должно доставить явный дискомфорт всему частникам клиентской связи. Но, пока никто ещё ничего подобного не реализовал.
В идеале, хотелось бы иметь в распоряжении организацию работы отказоустойчивости серверов (серверных подключений для работы через Internet-ID соединения) кластерного типа с активной постоянной репликацией по необходимости (при изменении состояний и по расписанию, например раз в час). Т.е., подключаясь клиентом к любому активному серверу в кластере, у нас всегда свежая информация об активности нужного/искомого хоста. В итоге происходит соединение клиента и хоста через целевой доступный сервер обоим, либо в случае невозможности организации подключения к целевому серверу по разным причинам хоста или клиента, при этом сервер1 видит сервер2, организуется дополнительно мост/тоннель соединяющий клиента и хоста подключённых ко двум разным серверам.
Основные причины недоступности сервера: выключен/перезагружается, провайдерN "отвалился", два провайдера не видят друг-друга, "плохой канал" (авария, сетевая атака, перебои в работе сетевого оборудования).
На текущий момент, было бы здорово, хотя-бы указать список 3-5 серверов отказоустойчивости по приоритету их указания, а также опрос серверов, например каждые 5 минут, если сервера по приоритету "отвалились", начиная с высшего (первого по списку).
Имеем 5 серверов по приоритету. Высший Сервер1 первый в списке и соответственно Сервер5 самый нижний с списке.
Логика работы Хоста: Хост подключается к .Сервер1. Через час Сервер1 "пропал", в течении 5 Сервер1 недоступен. Хост подключается к Сервер2, Сервер2 недоступен. Хост подключается к Сервер3, успешное соединение. Через 5 минут, Хост проверяет доступность Сервер1, Сервер1 недоступен. Хост проверяет Сервер2. Сервер2 стал доступен. Подключение к Сервер2, успешно. Через 5 минут, Хост проверяет доступность Сервер1, Сервер1 доступен. Хост подключается к Сервер1, успешное подключение. Хост не переключается между серверами приоритета (имея активное подключение с любым сервером по приоритету), если установлена связь с Клиентом. Хост не переключается между серверами приоритета имея текущее подключение к серверу из списка приоритетов, если было активное подключение Клиента в течении 30-60 минут (например произошёл сбой в работе сеанса подключения или по любой причине, когда необходимо повторное соединение Клиента и Хоста).
Логика работы Клиента: Клиент подключается к первому по приоритету Сервер1, успешное подключение. Клиент опрашивает Сервер1 на наличие активного подключения Целевого Хоста к Сервер1. На Сервер1 не обнаружен целевой активный Хост. Клиент подключается к Сервер2, Сервер2 недоступен. Клиент подключается к Сервер3, успешное подключение, целевой активный Хост не обнаружен. Клиент подключается к Сервер4, Сервер4 недоступен. Клиент подключается к Сервер5, Сервер5 недоступен. Достигнуто окончание списка серверов приоритета, Клиент запускает повторный опрос-подключение с начала списка, с Сервер1, Сервер 1 недоступен. Клиент подключается к Сервер2, Сервер2 недоступен. Клиент подключается к Сервер3, успешное подключение. Целевой Хост обнаружен активным, Клиент соединяется с Хостом успешно.
П.С.: Я уже запутался, что написал, но надеюсь логику донёс. Спасибо! |
| Профиль |
Сообщений:
24 |
Дата создания:
31.12.2021 20:50:46 |
|
Re: Дополнителный ID server
|
|
|
alex
Модератор
Цитировать выделенное
|
A_Creature,
сложная распределенная система имеется и хорошо отработана, наши глобальные сервера на ней построены.
по Mini-ID серверу пока таких запросов не было в реальности. Даже очень крупные организации один Сервер вытягивает. В целом, планы есть, разрешить кластеризацию для ID Серверов, но пока только планы, т.к. реального запроса нет. Только теоретические выкладки, вроде ваших. Но, когда начинаются обсуждения по существу, оказывается, что и один сервер перекрывает все потребности в разы.
Что касается отказоустойчивости и репликации, это уже другой вопрос, только косвенно связанный с кластеризацией. Если сделать возможность указывать несколько Серверов, это, при малейших проблемах, будет приводить к потере связанности. Хосты и Клиенты будут делать запросы на разные Сервера, не связанные в единой пространство. Попытка установить соединение будет приводить к массе лишних запросов и растягиваться на пол минуты.
Репликацию нужно делать при помощи специально созданных для этого инструментов, резервирование - через DNS.
Та схему, которую вы описали, - это костыль на костыле, не будет оно на практике нормально работать, в целом, падения Сервера - это инцидент, который не должен происходить.
В случае ЧП, нужно чтобы сотрудник или автоматика меняла DNS на резервный Сервер. Резервный Сервер может реплицироваться постоянно.
Также, нужно учитывать тот факт, что Сервер выполняет не только роль ID транспорта, по этому так просто взять и сделать несколько резервных Серверов, которые могут работать случайным образом, нельзя. Будет нарушение синхронизации адресных книг, к примеру, не говоря уж о сертификатах. |
| Профиль |
Сообщений:
3449 |
Дата создания:
01.01.2022 23:13:49 |
|
Re: Дополнителный ID server
|
|
|
A_Creature
Цитировать выделенное
|
К сожалению, ваши сервера тоже бывают недоступны и по более 5 минут. Но при всём, ваши сервера в итоге надёжней всего. Однако, никто не гарантирует, что Ваши сервера будут всегда доступны или вы не решите ввести какую-нибудь подписку на время. Но, я восхищаюсь вашими решениями по лицензиям, не требующих доплат на мажорные обновления.
Что касаемо темы. Mini Server Internet-ID, безусловно работает и это факт! Но в моём случае(небольшой компании, которое располагается в некой ПГТ, с отвратительно нестабильными провайдерами несмотря на оптику), происходит периодический отвал канала/каналов и/или высокий процент потери пакетов, что делает невозможным работу MSIID в данном случае.
По поводу резервирования отказоустойчивости, то по сути потеря в полминуты и куча запросов, вполне допустимо, чем недоступность хостов десятками минут или даже часами, потому-что эти запросы не выполняются ни постоянно, ни бесконечно.
Тогда следующий вопрос. Можно ли будет добавить/расширить функционал, с возможностью выбора роли MSIID, например Master и Node.
Роль Master - Гарантированное аккумулирование и упорядочивание данных, обработка, приём и ответ на запросы, только принимает подключения от серверов роли Master.
Роль Node - принимает подключения Хостов и Клиентов, связывает их, подключается к серверу с Master, передаёт и получает данные с текущими статусами (Master ID, Хост I-ID, статус подключения (ожидает, соединён, отключён), время подключения. Если соединён, то Клиент ID (имя ПК, или логин, или через точки логин_в_ОС.имя_ПК.локальный_IP.внешний_IP), время начала сеанса, время конец сеанса. И т.п..
Или уже хотя-бы какой-нибудь REST API с каким-нибудь токеном авторизации (возможно даже 2FA), позволяющий читать и/или управлять данными MSIID. |
| Профиль |
Сообщений:
24 |
Дата создания:
07.01.2022 01:04:45 |