Перейти к контенту

Поиск в системе

Результаты поиска по тегам 'failover'.

  • Поиск по тегам

    Введите теги через запятую.
  • Поиск по автору

Тип контента


Форумы

  • Продуктовый ряд ViPNet
    • Общие вопросы по продуктовому ряду ViPNet для корпоративных пользователей
    • Общие вопросы по программным решениям ViPNet для индивидуальных пользователей
    • Общие вопросы по продуктовой линейке ViPNet PKI
    • Пожелания к разработчикам ПО ViPNet
    • Пользовательские интерфейсы продуктов ViPNet
  • Бета-тестирование продуктов ViPNet
    • ViPNet Client/Coordinator x64
    • ViPNet Custom Windows
    • ViPNet Office Firewall Windows
    • ViPNet Office Firewall Linux
    • ViPNet Safe Disk
    • ViPNet Personal Firewall
    • ViPNet CSP 4.х
    • ViPNet Java Crypto SDK

Искать результаты в...

Искать результаты, которые...


Дата создания

  • Начать

    Конец


Последнее обновление

  • Начать

    Конец


Фильтр по количеству...

Зарегистрирован

  • Начать

    Конец


Группа


AIM


MSN


Сайт


ICQ


Yahoo


Jabber


Skype


Город


Интересы

Найдено 7 результатов

  1. Добрый день, коллеги! С прошедшими и с наступающими. Итак, к вопросу. Вводные. 1. Есть кластер на hw1000. 2. Цимус в чём. Все прелести жизни. - Четыре года назад поднят и настроен кластер, настроен коммутатор стоящий перед ним. - Что имеем. Скачки электропитания, в результате которых несохраненная конфига коммутатора слетела. Пофикшена. - Сервисный порт, где исходя из sendconfig заливалась конфига на пассивную ноду. И закрытый icmp на пассивной ноде (а заливалась ли). 3. Активная нода тянет работу, с ней всё ок. - Пассивная нода не доступен. Все интерфейсы включены, но пинги с нее и на нее не идут, arp таблица на 2960-24 стоящем за ней не строится. - Сервисный порт с активной ноды так же не пингуется. С пассивной не пингуется сервисный порт активной. - Сервисный порт подключали и прямым и кроссом. - На пассивной ноде в правилах firewall не разрешен пинг сервисного порта, которым соединены координаторы кластера. Видимо исторически так собрали. 4. На коммутаторе: - Порт локальной сети, порт випнет и порт провайдера, после слета конфиги, какое-то время были в ауте, по ним никакого обмена данных с пассивным узлом не было. - На активном узле порты встали после скачков напряжения нормально, тк конфига по ним была сохранена. - На текущий момент порты пассивной ноды на коммутаторе настроены. Но интерфейсы пассивной ноды не доступны, хотя на ней самой мониторятся как up, connected. 5. И естественно на время скачек электричества пришелся плановый период смены админского пароля. Который пассивная нода не получила. Пока разобрались, старый админ протух, enable не доступен. Поправить конфиги на ней теперь нельзя, старые пароли не принимаются. Биос заблочен, и единственный варик - откат назад во времени по ntp, подкинуть старого админа, поправить настройки, вернуть в кластер. 6. Демоны. - При остановленных на пассиве failover, iplir, mftp ситуация не меняется. С пассива я не пингую сеть вокруг себя, даже коммутатор и шлюз. - При останове failover, iplir, mftp на активном и пассивном ситуация не меняется. 7. ЦУС - Создать новый узел, отключив iplir и failover пробовал. Просто failover пробовал. - Создать новый узел, положив активную ноду и тормознув демонов на пассивной пробовал. По сети ничего он получать не хочет. Сам вопрос. У меня два варианта решения в голове на текущий момент. 1. Создать отдельную подсеть, чтоб попробовать подцепить пассивную ноду к ntp, положив iplir и failover. И зайдя под старым админом менять конфиги файрвола на сервисном порту, а потом пытаться вернуть в кластер. Смущает то, что интерфейсы сейчас не доступны. и отключение failover ничего не меняет. 2. Переустанавливать пассивную ноду. Если я не прав, подскажите, что я не так понимаю. Если у кого-нибудь есть схожий печальный опыт, буду признателен. Сдается мне я уже очень сильно туплю, и не вкуриваю нюансы технологии. Спасибо!
  2. Добрый день! Возникла следующая ситуация: Понадобилось настроить для тестирования кластер горячего резервирования на двух координаторах hw1000 версии 4.2.0-1958. Схема следующая: Coordinator1 - 89.175.27.5 (eth0 - внешний), 192.168.120.3 (eth1 - внутренний) и 172.16.1.1 (eth2 - канал для связи со вторым координатором) Coordinator2 - 89.175.27.6 (eth0 - внешний), 192.168.120.4 (eth1 - внутренний) и 172.16.1.2 (eth2 -канал для связи с первым координатором) Active IP - 89.175.27.2 (внешний) и 192.168.120.2 (внутренний) В качестве testip на внешнем и внутреннем интерфейсах обоих координаторов указал адрес 127.0.0.1. Остальные параметры оставлены по умолчанию. Собственно сама проблема: запускаю первый координатор в активном режиме, второй координатор - в пассивном, при этом второй координатор спустя примерно минуту переводится в активный режим, а первый - в пассивный. Далее спустя несколько секунд второй координатор уходит в перезагрузку, после перезагрузки начинается опять то же самое: переход этого координатора в активный режим и опять перезагрузка. Адреса каналов связи координаторов пингуются без проблем. В чем может быть причина бесконечной перезагрузки одного из координаторов?
  3. Доброе. два координатора соединены в failover как на рисунке eth2 eth3 eth1 eth0 [о] [о] [о] [] | соединение [о] [x] [о] [] как узнать IP адреса портов [o]?
  4. Доброго времени суток. Перезагружается координатор HW 1000, который становится активным в отказоустойчивом кластере. То есть, стоит координатору стать активным, как через 20~25 секунд он перезагружается. Тоже самое со вторым, который работает в паре. В сингл режиме такого нет. Из-за чего могут быть перезагрузки координатора в режиме кластера?
  5. Решили испытать Linux Coordinator: https://www.infotecs.ru/downloads/cdownload_demo.php?i_id_file=5802 Собрали кластер и обнаружили, что он работает только при: firewall.conf [local] . . . rule= num proto any from anyip to anyip pass даже с icmp: rule= num proto icmp from anyip to anyip pass не работает! Пассивная нода "не обнаруживает" активные адреса и пытается стать главной. Это баг или фича?
  6. Приветствую! Ребят, подскажите пожалуйста, кто нибудь настраивал систему защиты от сбоев для кластера в условиях ограничений по выделению IP-адресов. По документации одно из требований необходимо прописать запуск скрипта change_route.sh. Не понятно, его можно использовать в состоянии в котором он сейчас есть или его надо редактировать под мои требования? Если есть возможность поясните мне этот момент пожалуйста. Перед тем как начать настраивать, хочу разобраться. Вдруг есть какие подводные камни или что то упущено в документации. Спасибо! С уважением, Юрий!
  7. Здравствуйте! Возникла следующая неприятная ситуация: Пару недель назад «сбойнул» один из координаторов failover-ной связки. По данной проблеме было зарегистрировано обращение в техподдержку, отправлены все необходимые данные, но… все рекомендации не привели к положительному результату. Было принято решение о установке координатора заново: установлен дистрибутив SUSE (такой же, как и на второй, работоспособной ноде); установлено ПО ViPNet Coordinator Linux; расшит актуальный dst; скорректирован файл failover.ini… Казалось бы, всё делаю, как обычно… НО(!) … На первом сервере (S1) failover запущен в активном режиме. Соединяем файловерные интерфейсы, запускаем второй координатор (S2)… он стартует в пассивном режиме (при проверке на S1 командой failover info выводится верная информация о том, что S1 – активный, а S2 – пассивный). Примерно через 40 секунд S2 (по непонятным мне причинам) занимает ip-адрес кластера (который УЖЕ принадлежит S1). После этого S2 «понимает», что такой ip в сети уже есть и уходит в перезагрузку. И так – циклично. При этом, S1 остаётся работоспособным (как и ЧАСТЬ клиентов, находящихся в сети; оставшиеся клиенты перестают работать до момента перезагрузки S1 (при условии, что S2 либо выключен полностью, либо на нём отключен режим failover-а)). Вопрос: не сталкивались ли вы с чем-то подобным? Возможно, натолкнёте на решение… p.s. S1 и S2 имеют по 2 интерфейса (eth0 – СПД, eth1 – failover); друг друга пингуют, видны по arp; testip доступен для каждого координатора; файловерные интерфейсы в 4-м режиме, остальные во 2-м. Версия координатора: 3.7.4-4464. Если необходимы ещё какие-то данные, спрашивайте, постараюсь прояснить ситуацию.
×
×
  • Создать...

Важная информация

Продолжая пользоваться сайтом вы принимаете Условия использования.