Мне просто нужно понять идею, как оно будет работать в случае если отваливается 1 хост. Для себя я нарыл либо хай авиалейбл, от вмваре, но там получется что нужен сторадж, и это узкое место. А фаулт толеранс  я уже писал почему не подходит. Все точто предлагают тут в топике не всисывается в ту концепцию как я это вижу. Тут предлагают дулибование резервирование, тоесть создание копий сервера и переключение между ними. Я же вижу это как ОДИН сервер, который хоститься одновременно на нескольких машинах и вс луче выхода из строя железа, нагрузка просто перекладывается на оставшиеся.

Я же вам написал, если не хотите, чтобы надо был сторейдж - смотрите в сторону vmware VSA, и VSAN - но тут куча своих граблей.

Ваша задача решается двумя сторейджами в актив-актив кластере, на разных техплощадках + 2 фермы вычислительных нод на разных техплощадках, тоже в нем же - кластере, средствами чего душа пожелает - хоть вмваре, хоть ксенсервер, хоть проксмокс.

Необязательно-же делать именно кластер? Для целей биллинга достаточно синхронизировать базу данных основного и резервного биллинговых серваков.

А дальше схема примерно такая:
Сателлиты обращаются к биллингу не по адресу, а по доменному имени, которое завязано на динамик ДНС.
Резервный сервак пингует это-же имя, и если не получит ответа - запускает у себя клиентский скрипт динамик ДНСа, чтобы "перетянуть на себя" запросы сателлитов.

Конечно, это не кластер, моментального "подхвата" не будет. Но переключение произойдёт всего за несколько минут. Реальному живому админу нужно примерно столько-же, чтобы в случае аварии добежать до серверной и начать разбираться, что там произошло. А тут за такое-же время оно уже работать будет.

Я думал речь идет о всем железном парке. А то что Вы описали решается намного более гуманным и не костыльным методом. Смотрите HAproxy, например :
http://mysql.wingtiplabs.com/documentation/hap225xe/fail-over-mysql-with-haproxy

1) vmware vsa - максимум 3 хоста
2) vmware vsan - от 3-х хостов по схеме 2n+1 - на данный момент в бете и непонятно

Это из все в одном.

Классический вариант это отдельно сторейдж от вычислительных нод.

Например надо сделать две географически разнесенных площадки в кластере

1) Для этого нужно active-active кластер сторейджей :
   а) Железные решение NetApp, HP LeftHand и тд
   б) Платные решения  - Starwind, Open-e и тд
   в) Попробовать завести что-то opensource и халявное(оно или не работает, или работает так, что лучше бы не работало) : drbd, glusterfs со всякими костылями и тд
2) Собственно кластер вычислительных нод - на том же vmware(с костылями типа hearbreat для vcenter), proxmox и тд и тп

Разносим половину железа на один сайт, половину а другой. Соединяем все по iSCSI и получаем отказоустойчивый кластер.

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


P.S. Сами так ничего пока и не построили, активно изучаем тему. И потому да, согласен, пиздеть -  не мешки ворочать Но все таки разного рода тестирование привели меня к таким умозаключениям.
  

а как же accel-ppp ? вроде бы нормально работает на PPPoE серверах на линуксе

А еще IPoE : инициализация сессии по dhcp discover, или по unknown source ip packet. С радиус авторизацией, аккаунтингом, CoA.

Все довольно грамотно сделано, как у больших

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

2 efendy : я думаю интеграция с accel-ppp из коробки много времени не займет, но даст огромный плюс в распространении nodeny. На линукс-тазике получаешь сабскрайбер менеджмент фукнционал как на больших железных решениях. Причем несколько типов авторизации живут превосходно на одном сервере. Да и с такого на что-то железное перейти намного проще.

П.С. А будет у nodeny+ что-то типа realese, когда можно быть уверенным, что все устаканилось и подумать о возможностях апргейда ?

Или это все надо было в фичреквест?

Кстати, а не планируется ли версия noserver под linux ? по некоторым данным, шейпер на линуксе более производительный

ну так логика  такая же как в  n49/50, почему бы тому, кто сделал это под них, не сделать под  N+?

А как насчет интеграции с http://forum.nag.ru/forum/index.php?showtopic=53156
https://bitbucket.org/sysoleg/lisg/wiki/Home ?

Из проблем:
не понятно как использовать одновременно и динамические сервисы и не полисить украину на вход для абонента.
SCU работает, но в динамическом профиле нельзя матчить по сорус/дестинейшин классу, только по префикс листу.

Совместными усилиями с коллегой - завели. Осталось проверить работает ли на 10Г, ибо поступала утка, что cos только на 1Г.
И пока не получается разделить по разным динамическим сервисам, хотя в одном отлично

А не затруднит написать кратко по настройке, было бы очень полезно, только начну осваивать ведь. Или посоветовать что почитать?

Отослать вывод  show chassis hardware на juniper@nag.ru и попасть в закрытый раздел. Там есть очень занимательные диалоги меня со мной

А вообще : http://www.juniper.net/techpubs/en_US/junos11.4/information-products/pathway-pages/subscriber-access/index.html

Насчет софта : 11.4 ветку лучше использовать. 11.4X27.38 - максимум всего для брас функционала, что есть.  11.4R6.5 - последняя с пофиксеными багами во всем.

Всем спасибо за дельные советы, взяли МХ80-5G польстились на ограничения портов «right to use»

Из проблем:
не понятно как использовать одновременно и динамические сервисы и не полисить украину на вход для абонента.
SCU работает, но в динамическом профиле нельзя матчить по сорус/дестинейшин классу, только по префикс листу.
Можно передавать только имя руками наконфигуреных полисеров через радиус, в которых делать SCU.

Все остальное замечательно работает :
динамическое создание интерфейсов для абонента, включая qinq
динамический профиль для авторизации абонента
демультиплексирование абонентов по ip в случае с shared vlan
Динамические сервисы на каждого абонента и динамический аккаунтингом. CoA/PoD все работает.

И все это чудо работает и на агрегированных интерфейсах, в отличии от Ericsson SE, где :

Нельзя на агрегированых линках в сторону бордера красить трафик с интерфейсов(тот самый SCU). То бишь разделить украину/мир даже на вход к абоненту на LAG интерфейсах не возможно(ограничение дизайна железки)
В сторону абонентов очень хитрый LAG c балансировкой per subscriber, на котором не работает посервисный аккаунтинг и CoA, только PoD(не понять чего ограничение)
для ipoe инициализация сессии только по DHCP. на данный момент nondhcp-clips только в тестовых версиях софта.
На одну clips можно выдать только один адрес.

Обвязка такого рода, как у LanBilling например. Когда просто грубо говоря указываются вендор специфик атрибуты для конкрентной железки. И дальше, как конструктор собирается сервис для абонента.

а чтобы я не искал можешь и у них в доке/форуме в это ткнуть носом?

http://www.lanbilling.ru/radiusagent.html

http://shop.nag.ru/article/bazovaya-nastrojka-i-integratsiya-ericsson-smartedge--lanbilling-19-static-clips-chast-i - начало как раз про биллинг.

Не стоит задачи сделать для всех брасов все возможные механизмы взаимодействия.

Нужна какая-то прослойка, что был какой-то унифицированный механизм обращения к данным.

А не так : почитак доку, получил от браса атрибуты, распарсил что надо, передал в радчек, в радчеке и радрепли селекты с 100500 джойнов чтобы выбрать и отдать в ассепте нужную инфу. И это еще не говоря про CoA/PoD.

Еще раз реквестирую обвязку для радиуса.

ткни носом где это просишь

Единственное, что нашел почти в тему : http://forum.nodeny.com.ua/index.php?topic=1174.msg17584#msg17584

Видно только подумал

Обвязка такого рода, как у LanBilling например. Когда просто грубо говоря указываются вендор специфик атрибуты для конкрентной железки. И дальше, как конструктор собирается сервис для абонента.
Мы то понятное дело пишим свои процедуры под конкретные нужды.

У конкурентов в этом плане больше преимущество для тех, кто захотел купить MX/SE/ASR, натыкать мышкой и взлететь.

зато у них мега производительная коммутационная матрица.
высокая плотность портов.
достаточно высокая стабильность при использовании L2

О чем я и писал выше

у меня не парсилка.

Тогда подробней пожалуйста.

Еще раз реквестирую обвязку для радиуса.

Уже который  пост намекает, что в нодени+ надо сделать таки API. Чтобы мило и уютненько все могли писать свои приложения под *имя_платформы*, а не просто парсилку веб интерфейса.

Работал с экстримом Х650 - вещь просто лютая... больше сказать нечего.

Лютая в каком смысле?

На нем приотлично просто форвардить уймы трафика. И желательно, чтобы л3 трафика. И маков было не сильно много. Ежели что-то надо делать - например терминировать много абонентов, или еще чего - отвратительный глюкадром. Хуже софта, чем в экстриме и придумать сложно.
Есть большой опыт : как и терминациия многих тысяч абонентов, так и использование даже в качестве бордера с двумя VRF.

Остались экстримы только в качестве молотилки трафика, из функционала - vlan