Как физически скоммутировать оборудование под CARP ?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Как физически скоммутировать оборудование под CARP ?

Anton Maksimenkov-2
Хай.

Сижу вот думаю такую схему. Есть канал, силёнок одного сервера не
хватает его пережувать (перероутить+pf).
Думаю, а что если поставить 2 машины и сделать CARP чтобы они таки
справились вдвоём?
Но не очень понятно, ка скоммутировать. Изначально видится такое:

      канал в провайдера
                     |
            +---------------+
            | SWITCH1 |
            +---------------+
               |          |
               |          |
+---------------+   +---------------+
|    serv1     |     |    serv2    |
+---------------+   +---------------+
               |          |
               |          |
            +---------------+
            | SWITCH2 |
            +---------------+
                | | | | | | |
            локальная сеть


Думаю дальше. Так, сервера делают CARP, то есть шлют на свичи
МАС-ответы за свой IPшник.
Получается, что оба свича постоянно переписывают свою MAC-таблицу то
на один порт, то на другой (от кого позже пришёл МАС-ответ). Так что
трафик льют то в один порт (серв1), то в другой(серв2).
Что будет с трафиком? Чо-т не могу вкурить, где тут будет равномерное
распределение нагрузки. Кажется, что свич будет лить весь поток
трафика то в один порт, то (после перезаписи МАС-таблицы) в другой. В
результате сервера будут грузиться не равномерно, а как бы
"ударно-прерывисто".

Получается, нужно перед каждой парой интерфейсов ставить ещё HUB,
чтобы из него в свич уже один шнурок, так?

      канал в провайдера
                     |
            +---------------+
            | SWITCH1 |
            +---------------+
                     |
            +---------------+
            |    HUB1    |
            +---------------+
               |          |
+---------------+   +---------------+
|    serv1     |     |    serv2    |
+---------------+   +---------------+
               |          |
            +---------------+
            |    HUB2    |
            +---------------+
                     |
            +---------------+
            | SWITCH2 |
            +---------------+
                | | | | | | |
            локальная сеть


Ну и вообще говоря, поделитесь опытом.

Помогает ли CARP осилить нагрузку (роутинг с pf, большего пока не
надо), которую не тянет один сервак? В каком там состоянии это дело,
кто юзает? Минусы есть?
--
engineer
Reply | Threaded
Open this post in threaded view
|

сборка spark 32bit

Aleksei Bebinov-2
Ребята, подскажите есть ли у кого нибудь скачать готовую сборку образа
CD сабжа под 32 битный sparc ( Netra1 и Ultra 1 ).

Заранее огромное.


Reply | Threaded
Open this post in threaded view
|

Re: Как физически скоммутировать оборудование под CARP ?

Grigoriy Orlov-4
In reply to this post by Anton Maksimenkov-2
On Thu, Dec 04, 2008 at 11:48:54AM +0500, engineer wrote:
> Хай.
>
> Сижу вот думаю такую схему. Есть канал, силёнок одного сервера не
> хватает его пережувать (перероутить+pf).
> Думаю, а что если поставить 2 машины и сделать CARP чтобы они таки
> справились вдвоём?

Есть вероятность огрести множество проблем. Во всяком случае при
использовании pfsync. Может быть нужна хорошая сетевуха и быстрый проц ?
Сколько у тебя пользователей ? Канал 1Gbit ? Если меньше, то точно можно
обойтись одним хостом.

        /gluk


Reply | Threaded
Open this post in threaded view
|

Re: Как физически скоммутировать оборудование под CARP ?

Andrew-45
In reply to this post by Anton Maksimenkov-2
engineer пишет:

> Хай.
>
> Сижу вот думаю такую схему. Есть канал, силёнок одного сервера не
> хватает его пережувать (перероутить+pf).
> Думаю, а что если поставить 2 машины и сделать CARP чтобы они таки
> справились вдвоём?
> Но не очень понятно, ка скоммутировать. Изначально видится такое:
>
>       канал в провайдера
>                      |
>             +---------------+
>             | SWITCH1 |
>             +---------------+
>                |          |
>                |          |
> +---------------+   +---------------+
> |    serv1     |     |    serv2    |
> +---------------+   +---------------+
>                |          |
>                |          |
>             +---------------+
>             | SWITCH2 |
>             +---------------+
>                 | | | | | | |
>             локальная сеть
>
>
> Думаю дальше. Так, сервера делают CARP, то есть шлют на свичи
> МАС-ответы за свой IPшник.
> Получается, что оба свича постоянно переписывают свою MAC-таблицу то
> на один порт, то на другой (от кого позже пришёл МАС-ответ). Так что
> трафик льют то в один порт (серв1), то в другой(серв2).
> Что будет с трафиком? Чо-т не могу вкурить, где тут будет равномерное
> распределение нагрузки. Кажется, что свич будет лить весь поток
> трафика то в один порт, то (после перезаписи МАС-таблицы) в другой. В
> результате сервера будут грузиться не равномерно, а как бы
> "ударно-прерывисто".
>
> Получается, нужно перед каждой парой интерфейсов ставить ещё HUB,
> чтобы из него в свич уже один шнурок, так?
>
>       канал в провайдера
>                      |
>             +---------------+
>             | SWITCH1 |
>             +---------------+
>                      |
>             +---------------+
>             |    HUB1    |
>             +---------------+
>                |          |
> +---------------+   +---------------+
> |    serv1     |     |    serv2    |
> +---------------+   +---------------+
>                |          |
>             +---------------+
>             |    HUB2    |
>             +---------------+
>                      |
>             +---------------+
>             | SWITCH2 |
>             +---------------+
>                 | | | | | | |
>             локальная сеть
>
>
> Ну и вообще говоря, поделитесь опытом.
>
> Помогает ли CARP осилить нагрузку (роутинг с pf, большего пока не
> надо), которую не тянет один сервак? В каком там состоянии это дело,
> кто юзает? Минусы есть?
>  

опыт эксплуатации в режиме failover положительный.
с load-balanced похуже. Дело было на версии 3.9. Нормальной работы
добиться не удалось. Сессии периодически рвались - то ли pfsync плохо их
синхронизировал, то ли еще что, но при переходе от одной ноды к другой
могла порваться сессия. Возможно нужно было переписать правила без
использования keep state. Конфигурация правда немного нестандартная была
- возможно в книжном варианте все будет ОК.


Reply | Threaded
Open this post in threaded view
|

Re: сборка spark 3

Mike Belopuhov
In reply to this post by Aleksei Bebinov-2
On Thu, Dec 04, 2008 at 15:41 +0600, Aleksei Bebinov wrote:
> Ребята, подскажите есть ли у кого нибудь скачать готовую сборку образа
> CD сабжа под 32 битный sparc ( Netra1 и Ultra 1 ).
>

netra1 и ultra1, как подсказывают названия, это ultrasparc'и, то есть
sparc64.  соответственно вот образ ЦД:
ftp://ftp.eu.openbsd.org/pub/OpenBSD/4.4/sparc64/install44.iso

> Заранее огромное.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Как физически скоммутироват

Mike Belopuhov
In reply to this post by Grigoriy Orlov-4
On Thu, Dec 04, 2008 at 13:23 +0300, Grigoriy Orlov wrote:

> On Thu, Dec 04, 2008 at 11:48:54AM +0500, engineer wrote:
> > Хай.
> >
> > Сижу вот думаю такую схему. Есть канал, силёнок одного сервера не
> > хватает его пережувать (перероутить+pf).
> > Думаю, а что если поставить 2 машины и сделать CARP чтобы они таки
> > справились вдвоём?
>
> Есть вероятность огрести множество проблем. Во всяком случае при
> использовании pfsync. Может быть нужна хорошая сетевуха и быстрый проц ?
> Сколько у тебя пользователей ? Канал 1Gbit ? Если меньше, то точно можно
> обойтись одним хостом.
>
> /gluk
>
>

есть мненеи что это самое правильное решение. UP система с одним быстрым
процом с жирным кэшем, гигабитные PCI-X сетевухи и всякие мелочи типа
нормального timecounter сорса в userland.  возможно придется потестить
разное железо. еще бы было замечательно юзать ioapic, которого пока нет
на UP кернелах, но можно попытаться пробить к след. релизу.

+ ко всему золотое правило -- у carp'а должны быть _свои_ _отдельные_
интерфейсы, соединенные кроссом.  конфигурация, представленная на рисунке,
пример неправильной реализации.