Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

Как реализовать управляемую нагрузку на возможность подключения к системе OMNITRACKER

Не для кого не секрет, что после, того как служба OTserver запущена, пользователи в систему будут допущены после того, как в лог файле будет подтверждение готовности Welcome.

Есть такое наблюдение, когда в системе работает свыше 400 человек, любые изменения проходят с задержкой. Это связанно со многими причинами, а когда свыше 1000 тут и говорить нечего.

Предположим себе такую ситуацию, есть кластерная система в которую входит три сервера приложения. Известно, что для штатной работы системы достаточно два сервера приложения. Третий сервер приложения, является резервной нодой, для повышения отказоустойчивости системы.

Для входа в мульти кластерную схему работы сервера, нужно время, и это время нужно для согласования информации между серверами (это внутренняя логика системы). Если падение произойдет в пиковую нагрузку, то сервер в кластер будет собирается довольно долго, как эту проблему решить?

Причина кроется в количестве пользователей, которые пытаются подключится к системе, и системе приходится отвечать на каждое такое подключение, тратя на это ресурсы.


Как же можно обойти данную проблему, без больших затрат?
Нам потребуется:

Балансировки класса F5
Доменное имя, которое будет включить в себя IP включенный в данную схему балансировки.
Скрипт подключения через OtAut
IIS на каждом APP сервере.

Общая логика работы:
Скрипт подключается к конкретной ноде, и проверяет возможность авторизации на сервере.
Если авторизация успешная, то на IIS на некой страничке пишется код ответа, скажем код 200. Все хорошо, система может принимать подключения. Если авторизация будет не успешной, то код ошибки может быть 300 или 500, это уже ваша фантазия.
Далее на F5 пишем проверки для проброса пользователей при условии, что на сервере N по пути http://имя сервера/наша страница проверки/ возвращаемый код равен 200, тогда проброс разрешен.
Для IIS приложения пишем проверку, подключения к системе один раз в минуту, этого будет достаточно.
Перенастраиваем IIS сервера WEB приложения на наш F5 балансировщик, в том числе все подключения пользователей через него. На выходе мы получили управляемую нагрузку на сервера для всех внешних подключений.

Теперь, при возникновении сбоя с одним из серверов, F5 не будет пробрасывать пользователей к неработающему серверу, тем самым сократит количество запросов к системе. Что позволит ей, быстрее входить в кластерную работу, также можно дополнить нашу логику управления данным балансировщиком. Скажем нам нужно не пускать никого в систему, при этом без применения штатных механизмов блокировки.

Код для подключения, для IIS проверки.

Код
OtSession session = _app.CreateSession(); session.HostName = string.IsNullOrEmpty(server) ? Dns.GetHostName() : server; // Host берётся от текущей машины, либо заданный вручную, если это необходимо.
session.PortNumber = 5085;
session.LangCode = "ru";
session.ForceClusterNode = true; // Чтобы подключиться к конкретной node

session.UserName = "Login";
session.Password = "Password";

HttpStatusCode result = HttpStatusCode.OK; try {
   session.Connect();
   session.Logoff();
}
catch (Exception e)
{
   if (e.Message.Contains("WSAECONNREFUSED: No connection could be made because the target machine actively refused it.\r\n (10061)") ||
      e.Message.Contains("WSAECONNREFUSED: Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.\r\n (10061)"))
      result = HttpStatusCode.GatewayTimeout;
   else if (e.Message == "Сервер в данный момент занят, так как находится на стадии запуска.")
      result = HttpStatusCode.Redirect;
   else if (e.Message == "Неверное имя пользователя или пароль")
      result = HttpStatusCode.OK;
   else
      result = HttpStatusCode.BadRequest;
}

_availableFact = result;


Таким способом можно управлять подключения пользователей к системе.