lightalex, да, у вас все так же будет входная точка, но с значительно более высокой надежностью. В задачи haproxy аойдет перекидывание пакетов на сервера и контроль их состояния. От частоты контроля будет зависеть, сколько пакетов уйдет в никуда, прежде чем весь поток будет перенаправлен на работающий сервер. Т.е. абсолютно без потерь не обойтись, но они сведутся к минимуму. Зависит от типа вашей игры. Возможно это приведет лишь к лагу на секунду. Если у вас tcp, то скорее всего пакет даже не потеряется.
Стоит протестировать вам это все. Раз ваши центральные узлы могут работать с общей табличкой пользователей, то такая схема обеспечит большую надежность.
P. S. Если уж очень захочется, то можно и haproxy задублировать с использованием VRRP
lightalex, в таком случае мой вариант все-таки сработает, мне кажется. Вы модете запустить 2 центральных узла и с помощью haproxy или nginx распределять соединения по центральным узлам. Правда, как я понимаю в случае падения одного из них отвалится половина игроков, т.к. второй "центральный" не сможет подхватить уже установленные сессии. Или сможет? Есть какая-то база данных, которую можно объединить на эти 2 узла?
Однако, склоняюсь к вывтду, что сторонними сркдствами делу не поможешь. Необходимо менять логику работы цеетралтных узлов. Они должны быть входной точкой для клиентов, но после выбора улиентом сервера, перкнаправлять его на сервер напрямую, а ек проксировать пакеты. Только в таком случае падение центрального узла не будет приводить к отвалу всех клиентов.
Игорь, выложите конфиг. Возможно, удастся найти то, из-за чего такое поведение у вашего 3com при работе с vlan. Через изоляцию портов, скорее всего, задачу вашу не решить.
Игорь, порты ваш свитч будет изолировать логически, и вероятнее всего, по их PVID. Поэтому у вас получится в свитче должна часть портов быть Untagged VLAN1, а другая часть Untagged VLAN2. Вот так вы получите изоляцию, но VLANы будут только внутри Свитча.
CRS от Микротиков, например, физически способны изолировать.
Wadik_Wadkovich, тогда видимо я поспешил с выводами и в данной версии samba4.0 что-то неладно с функционалом DC. Т.е. Самба в репозитории ГОСЛИНУКСа забагованная. Боюсь, шансов поднять на ней AD нет. Альтернативных инструментов под Linux так же нет
Выложите сюда ваше правило для UDEV (сомнительно что там ошибка, конечно).
Возможно особенность вашего устройства.
Возможно вам придётся в приложении реализовать функционал поиска порта устройства.
Думаю такого не найти, т.к. плохо понятно в каком виде выводить результат. Списком адресов? Нет - их слишком много. В виде 10.X.5.X? Тогда нечетные адреса непонятно как отобразить.
den19948, что-то странный у вас пример. Как это вы по порту RDP копируете что-то с гита? Вариантов, как-бы: 22,80 и 443. Это если говорить, скажем, про Гитхаб, Гитлаб и т.п.
А Jenkins может не иметь доступа по множеству причин - к примеру, у него нет прав на доступ к репозиторию, не указан plaintext пароль или открытый ключ пользователя, из под которого работает jenkins, не указан в настройках вашего гита.
Otrivin, если почти не владеете, то будет не просто. Готового парсера нет.
Есть библиотека для PHP php.net/manual/ru/intro.mailparse.php или https://github.com/php-mime-mail-parser/php-mime-m...
С её помощью можно декодировать сообщение. Далее придётся писать парсер, выдергивающий необходимую вам информацию из тела письма. Если письмо формировалось скриптом, то можно дернуть просто нужные строки, если нет - придётся писать регулярки.
Стоит протестировать вам это все. Раз ваши центральные узлы могут работать с общей табличкой пользователей, то такая схема обеспечит большую надежность.
P. S. Если уж очень захочется, то можно и haproxy задублировать с использованием VRRP