Спасибо, про Proxmox я знаю :) Запускал под ним бухгалтерскую Венду с терминал сервером, Астериски, контроллер Unifi и много другого интересного. В данном случае он плохо подходит под требования задачи — смотрите первое предложение статьи:
Задача: запустить FreeBSD из-под Linux, желательно с минимумом изменений в Linux-системе при начальной настройке и обновлениях, возможностью запуска на рабочей станции и на сервере
Proxmox: требует продуманной инсталляции на отдельный компьютер; вряд ли пригоден для экспериментов на десктопном компе; засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами, которым по хорошему место в отдельном контейнере; ради поддержки OpenVZ построен на сильно неновом и редко обновляемом кастомизированном ядре; имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.
То есть у Proxmox есть своя ниша в Enterprise, где он imho лучший, но мне требовалось такое решение, которое можно было бы запустить на существующих серверах без кардинальных переделок, и иметь возможность до задействования серверов по максимуму тестировать его локально.
Я выше написал, чем лично меня не устроила libvirt.
Вряд ли virt-manager настолько умный, что умеет обходить её ограничения.
Формально из того, что перечислено на странице www.linux-kvm.org/page/Management_Tools,
для начального знакомства к KVM лучше всего подходит AQemu:
лёгкая GUI-оболочка без собственных представлений о том, что правильно, а что нет.
Увы, но на практике оказалось, что он пока слишком сырой: в первый раз кое-как запустился,
но когда создал в ~/.aqemu описание первой виртуалки, стал стабильно падать с ошибкой сегментирования прямо при запуске.
> Если не секрет, а чем libvirtd + virt-manager не устроили?
Тяжеловесностью, глючностью и заточенностью под представления авторов. Возможно, за год с момента последней проверки ситуация изменилась к лучшему, но тогда было так.
Например, «virsh shutdown» менял статус контейнера на «shutdowning...», но kvm-контейнер продолжал работать до «killall kvm» на ферме либо «poweroff» в гостевой системе.
Конфиги контейнеров (доменов в терминологии либвирта) требовалось менять при миграции с одной фермы на другую (например, между Дебианом и Центосом), потому что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров.
Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, которых при прямом использовании КВМ не было и в помине:
1) Сначала либвирт не давал КВМу создавать TAP-интерфейсы из-за зарезанных привилегий.
2) Когда это победили и обновились с libvirt с 0.6 из Центоса до 0.7 из Епеля, появились новые ограничения привилегий, из-за которых настроенные конфиги снова нерабочими.
3) Если в конфигах либвирта включались DHCP и/или TFTP, либвирт автоматически запускал dnsmasq, но с такими параметрами, что на TAP-интерфейсах использовать его было нельзя: с ключом «bind-interfaces» он их просто не видел, потому что запускался либвиртом ДО создания интерфейса.
Получилось, что своими проблемами либвирт зря отнял время, а в плане облегчения работы с КВМ никак не помог. Скорее наоборот, разобраться непосредственно с КВМ оказалось бы быстрее. Но это только мой личный опыт, коллективный разум вроде бы считает иначе.
40 клиентов. Каналов больше. Нагрузка на сетевой интерфейс и процессор невысокая, менее 20%.
udpxy начинал спотыкаться не из-за нагрузки, а из-за однопользовательской по сути архитектуры.
Решение лучшее из худших. Отказаться внедрять IP-телевидение нельзя. Ждать, пока закончится модернизация транспортной сети, тоже нельзя. Расчитывать при её нынешнем состоянии только на мультикаст тоже нельзя. Если хотя бы сто клиентов смотрят телевидение там, куда мультикаст не прокинуть — в этих случаях нужно использовать udpxy и обходить его ограничения.
Без up/down-сценариев обойтись почти нереально.
Например, если провайдер выдал сеть /30 и после получения IP надо добавить статический маршрут по умолчанию.
Или если он выдал одну bgp-сессию, то надо скомандовать Квагге "(no) neighbor 1.2.3.1 shutdown".
Во-первых, vrrpd не понимает up/down-сценарии.
Во-вторых, лицензионно-патентные рогатки в протоколе.
В-третьих, у vrrpd в README.Debian прямо написано, что он заброшен и лучше пользоваться ucarp'ом.
Т.к. они оба одинаково компактны, я выбрал ucarp.
Целью заметки было именно описать практическое решение небольшой задачи.
Общая информация приведена только как отправная точка для самостоятельных поисков.
Как показывает опыт, имея то и другое, восполнить пробелы труда не представляет.
Но если у Вас появились конкретные вопросы, то я попробую на них ответить :)
Redhat как платформа imho слишком тяжеловесен. Приходится одновременно иметь дело с Centos и Debian — по субъективным ощущениям Дебиан более проворен, менее запутан и тщательнее допилен.
Возможно, это объясняется тем, что Дебиан смотрит на завтрашний день, а Редхат нацелен на послезавтрашний :)
Соединения важны для сервера. Маршрутизатору без NAT они в 99,9999% случаев безразличны.
Но для сервера соединение — это не столько флаги пакетов, сколько содержимое.
Если трафик не зеркалируется целиком на резервные серверы, то при аварии основного всё равно запрос придётся отправлять на резервный заново. Поэтому толку от conntrackd в случае с серверами тоже не видно.
Обеспечение отказоустойчивости протоколами маршрутизации — это уже более высокий уровень. Не layer3, а layer7 :) Применим широко, но не везде. Например, шлюз, который обслуживает конечных пользователей, никакими RIP и OSPF не зарезервируешь.
И если верхний провайдер выдал вам сеть /30 и одну BGP-сессию,
то единственный способ зарезервировать свой основной бордер — это отдавать резервному его IP-адрес.
Судя по их сайте, это решение на основе Hearthbeat.
Возможно, неплохая весчь, но для относительно несложной задачи «отказоустойчивый роутер» imho несколько тяжеловата.
Proxmox: требует продуманной инсталляции на отдельный компьютер; вряд ли пригоден для экспериментов на десктопном компе; засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами, которым по хорошему место в отдельном контейнере; ради поддержки OpenVZ построен на сильно неновом и редко обновляемом кастомизированном ядре; имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.
То есть у Proxmox есть своя ниша в Enterprise, где он imho лучший, но мне требовалось такое решение, которое можно было бы запустить на существующих серверах без кардинальных переделок, и иметь возможность до задействования серверов по максимуму тестировать его локально.
Вряд ли virt-manager настолько умный, что умеет обходить её ограничения.
Формально из того, что перечислено на странице www.linux-kvm.org/page/Management_Tools,
для начального знакомства к KVM лучше всего подходит AQemu:
лёгкая GUI-оболочка без собственных представлений о том, что правильно, а что нет.
Увы, но на практике оказалось, что он пока слишком сырой: в первый раз кое-как запустился,
но когда создал в ~/.aqemu описание первой виртуалки, стал стабильно падать с ошибкой сегментирования прямо при запуске.
Тяжеловесностью, глючностью и заточенностью под представления авторов. Возможно, за год с момента последней проверки ситуация изменилась к лучшему, но тогда было так.
Например, «virsh shutdown» менял статус контейнера на «shutdowning...», но kvm-контейнер продолжал работать до «killall kvm» на ферме либо «poweroff» в гостевой системе.
Конфиги контейнеров (доменов в терминологии либвирта) требовалось менять при миграции с одной фермы на другую (например, между Дебианом и Центосом), потому что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров.
Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, которых при прямом использовании КВМ не было и в помине:
1) Сначала либвирт не давал КВМу создавать TAP-интерфейсы из-за зарезанных привилегий.
2) Когда это победили и обновились с libvirt с 0.6 из Центоса до 0.7 из Епеля, появились новые ограничения привилегий, из-за которых настроенные конфиги снова нерабочими.
3) Если в конфигах либвирта включались DHCP и/или TFTP, либвирт автоматически запускал dnsmasq, но с такими параметрами, что на TAP-интерфейсах использовать его было нельзя: с ключом «bind-interfaces» он их просто не видел, потому что запускался либвиртом ДО создания интерфейса.
Получилось, что своими проблемами либвирт зря отнял время, а в плане облегчения работы с КВМ никак не помог. Скорее наоборот, разобраться непосредственно с КВМ оказалось бы быстрее. Но это только мой личный опыт, коллективный разум вроде бы считает иначе.
udpxy начинал спотыкаться не из-за нагрузки, а из-за однопользовательской по сути архитектуры.
Имелся в виду встроенный синтаксис, а seq и jot — это внешние команды.
Кроме того, последним значением должен быть не $SUBPORTS, а $SUBPORTS-1,
т.е. придётся либо добавлять вызов expr, либо заводить отдельную переменную.
> пользователем Wilmer с форума Cacti и мной
В чём заключались поправки?
Шаблон Эрика импортируется с ошибками:
forums.cacti.net/viewtopic.php?f=12&t=19250&p=226881#p226881
Например, если провайдер выдал сеть /30 и после получения IP надо добавить статический маршрут по умолчанию.
Или если он выдал одну bgp-сессию, то надо скомандовать Квагге "(no) neighbor 1.2.3.1 shutdown".
Во-вторых, лицензионно-патентные рогатки в протоколе.
В-третьих, у vrrpd в README.Debian прямо написано, что он заброшен и лучше пользоваться ucarp'ом.
Т.к. они оба одинаково компактны, я выбрал ucarp.
Целью заметки было именно описать практическое решение небольшой задачи.
Общая информация приведена только как отправная точка для самостоятельных поисков.
Как показывает опыт, имея то и другое, восполнить пробелы труда не представляет.
Но если у Вас появились конкретные вопросы, то я попробую на них ответить :)
Возможно, это объясняется тем, что Дебиан смотрит на завтрашний день, а Редхат нацелен на послезавтрашний :)
Но для сервера соединение — это не столько флаги пакетов, сколько содержимое.
Если трафик не зеркалируется целиком на резервные серверы, то при аварии основного всё равно запрос придётся отправлять на резервный заново. Поэтому толку от conntrackd в случае с серверами тоже не видно.
Если для NAT-клиентов некритичен перерыв на 3-4 секунды в маловероятном случае переключения, то и на NAT-шлюзе без conntrackd imho можно обойтись.
www.loadbalancing.org/#Free_BSD_stuff_CARP_PF_and_hoststated_
К сожалению, в данном случае мне требовалось компактное решение именно на Линукс.
Про трекер поподробнее рассказать не хотите? С интересом почитаем :)
статьюхабратопик! :)И если верхний провайдер выдал вам сеть /30 и одну BGP-сессию,
то единственный способ зарезервировать свой основной бордер — это отдавать резервному его IP-адрес.
Возможно, неплохая весчь, но для относительно несложной задачи «отказоустойчивый роутер» imho несколько тяжеловата.