On Sun, Oct 03, 2010 at 11:52:12PM +0300, Michael Bochkaryov wrote: [dd]

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

hint: У Cisco есть технология vPC (Virtual Port Channel). Думаю у конкуретнов есть аналоги.

Можно ли link aggregation организовать на портах в разных свичах? Или нужно на уровне IP это разруливать (чего не хочется)?

Если подходить к вопросу основательно - почитай про SCTP. В нем есть реализация резервирования на уровне транспортрного протокола.

Заранее спасибо :)

На самом деле вводных даных недостаточно. Если тебе нужна надежность и адекватное время изоляции неисправности - необходим heartbeat на уровне приложения. В любом другом случае слишком велика верхняя оценка для ситуации в которой проблема не обнаружена своевременно. -- ZA-RIPE||ZA1-UANIC

Хм, bonding.txt из линуксведра вполне раскрывает эту тему 2) HA on two or more switches (or a single switch without trunking support) --------------------------------------------------------------------------- This mode is more problematic because it relies on the fact that there are multiple ports and the host's MAC address should be visible on one port only to avoid confusing the switches. If you need to know which interface is the active one, and which ones are backup, use ifconfig. All backup interfaces have the NOARP flag set. To use this mode, pass "mode=1" to the module at load time : # modprobe bonding miimon=100 mode=1 Or, put in your /etc/modules.conf : alias bond0 bonding options bond0 miimon=100 mode=1 Example 1: Using multiple host and multiple switches to build a "no single point of failure" solution. | | |port3 port3| +-----+----+ +-----+----+ | |port7 ISL port7| | | switch A +--------------------------+ switch B | | +--------------------------+ | | |port8 port8| | +----++----+ +-----++---+ port2||port1 port1||port2 || +-------+ || |+-------------+ host1 +---------------+| | eth0 +-------+ eth1 | | | | +-------+ | +--------------+ host2 +----------------+ eth0 +-------+ eth1 In this configuration, there are an ISL - Inter Switch Link (could be a trunk), several servers (host1, host2 ...) attached to both switches each, and one or more ports to the outside world (port3...). One an only one slave on each host is active at a time, while all links are still monitored (the system can detect a failure of active and backup links). Each time a host changes its active interface, it sticks to the new one until it goes down. In this example, the hosts are not too much affected by the expiration time of the switches' forwarding tables. If host1 and host2 have the same functionality and are used in load balancing by another external mechanism, it is good to have host1's active interface connected to one switch and host2's to the other. Such system will survive a failure of a single host, cable, or switch. The worst thing that may happen in the case of a switch failure is that half of the hosts will be temporarily unreachable until the other switch expires its tables. Example 2: Using multiple ethernet cards connected to a switch to configure NIC failover (switch is not required to support trunking). +----------+ +----------+ | |eth0 port1| | | Host A +--------------------------+ switch | | +--------------------------+ | | |eth1 port2| | +----------+ +----------+ On host A : On the switch : # modprobe bonding miimon=100 mode=1 # (optional) minimize the time # ifconfig bond0 addr # for table expiration # ifenslave bond0 eth0 eth1 Each time the host changes its active interface, it sticks to the new one until it goes down. In this example, the host is strongly affected by the expiration time of the switch forwarding table. 3 октября 2010 г. 23:52 пользователь Michael Bochkaryov написал:

Мое почтение всем!

Не подскажет ли кто направление копания в такой задаче?

Имеется: 1) 2 сервера на linux c 2 x ethernet 2) 2 управляемых свича с поддержкой link aggregation 802.3ad

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

Можно ли link aggregation организовать на портах в разных свичах? Или нужно на уровне IP это разруливать (чего не хочется)?

Заранее спасибо :)

-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

-- Yours, Max

Макисм, спасибо - bonding.txt я читал, как и LARTC. А вот с современными свичами я знаком куда хуже Как реализовать failover only - вроде бы достаточно понятно. А вот что нужно, чтобы в нормальной ситуации были и HA, и load balancing - пока не уверен, что знаю. 2010/10/4 Max Speransky

Хм, bonding.txt из линуксведра вполне раскрывает эту тему

2) HA on two or more switches (or a single switch without trunking support) --------------------------------------------------------------------------- This mode is more problematic because it relies on the fact that there are multiple ports and the host's MAC address should be visible on one port only to avoid confusing the switches.

If you need to know which interface is the active one, and which ones are backup, use ifconfig. All backup interfaces have the NOARP flag set.

To use this mode, pass "mode=1" to the module at load time :

# modprobe bonding miimon=100 mode=1

Or, put in your /etc/modules.conf :

alias bond0 bonding options bond0 miimon=100 mode=1

Example 1: Using multiple host and multiple switches to build a "no single point of failure" solution.

| | |port3 port3| +-----+----+ +-----+----+ | |port7 ISL port7| | | switch A +--------------------------+ switch B | | +--------------------------+ | | |port8 port8| | +----++----+ +-----++---+ port2||port1 port1||port2 || +-------+ || |+-------------+ host1 +---------------+| | eth0 +-------+ eth1 | | | | +-------+ | +--------------+ host2 +----------------+ eth0 +-------+ eth1

In this configuration, there are an ISL - Inter Switch Link (could be a trunk), several servers (host1, host2 ...) attached to both switches each, and one or more ports to the outside world (port3...). One an only one slave on each host is active at a time, while all links are still monitored (the system can detect a failure of active and backup links).

Each time a host changes its active interface, it sticks to the new one until it goes down. In this example, the hosts are not too much affected by the expiration time of the switches' forwarding tables.

If host1 and host2 have the same functionality and are used in load balancing by another external mechanism, it is good to have host1's active interface connected to one switch and host2's to the other. Such system will survive a failure of a single host, cable, or switch. The worst thing that may happen in the case of a switch failure is that half of the hosts will be temporarily unreachable until the other switch expires its tables.

Example 2: Using multiple ethernet cards connected to a switch to configure NIC failover (switch is not required to support trunking).

+----------+ +----------+ | |eth0 port1| | | Host A +--------------------------+ switch | | +--------------------------+ | | |eth1 port2| | +----------+ +----------+

On host A : On the switch : # modprobe bonding miimon=100 mode=1 # (optional) minimize the time # ifconfig bond0 addr # for table expiration # ifenslave bond0 eth0 eth1

Each time the host changes its active interface, it sticks to the new one until it goes down. In this example, the host is strongly affected by the expiration time of the switch forwarding table.

3 октября 2010 г. 23:52 пользователь Michael Bochkaryov написал:

...

Мое почтение всем!

Не подскажет ли кто направление копания в такой задаче?

Имеется: 1) 2 сервера на linux c 2 x ethernet 2) 2 управляемых свича с поддержкой link aggregation 802.3ad

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

Можно ли link aggregation организовать на портах в разных свичах? Или нужно на уровне IP это разруливать (чего не хочется)?

Заранее спасибо :)

-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

-- Yours, Max

-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

On Mon, Oct 04, 2010 at 11:30:03AM +0300, Michael Bochkaryov wrote:

Макисм, спасибо - bonding.txt я читал, как и LARTC. А вот с современными свичами я знаком куда хуже

Как реализовать failover only - вроде бы достаточно понятно. А вот что нужно, чтобы в нормальной ситуации были и HA, и load balancing - пока не уверен, что знаю.

Одновременно и HA и load-balancing на разных свитчах не бывает (разве что свитчи шибко умные, понимающие всякий кластеринг и так далее, но это не твой случай). Так что сделай failover only и не мучайся :)

2010/10/4 Max Speransky

Хм, bonding.txt из линуксведра вполне раскрывает эту тему

2) HA on two or more switches (or a single switch without trunking support) --------------------------------------------------------------------------- This mode is more problematic because it relies on the fact that there are multiple ports and the host's MAC address should be visible on one port only to avoid confusing the switches.

If you need to know which interface is the active one, and which ones are backup, use ifconfig. All backup interfaces have the NOARP flag set.

To use this mode, pass "mode=1" to the module at load time :

   # modprobe bonding miimon=100 mode=1

Or, put in your /etc/modules.conf :

   alias bond0 bonding    options bond0 miimon=100 mode=1

Example 1: Using multiple host and multiple switches to build a "no single point of failure" solution.

               |                                     |                |port3                           port3|          +-----+----+                          +-----+----+          |          |port7       ISL      port7|          |          | switch A +--------------------------+ switch B |          |          +--------------------------+          |          |          |port8                port8|          |          +----++----+                          +-----++---+          port2||port1                           port1||port2               ||             +-------+               ||               |+-------------+ host1 +---------------+|               |         eth0 +-------+ eth1           |               |                                       |               |              +-------+                |               +--------------+ host2 +----------------+                         eth0 +-------+ eth1

In this configuration, there are an ISL - Inter Switch Link (could be a trunk), several servers (host1, host2 ...) attached to both switches each, and one or more ports to the outside world (port3...). One an only one slave on each host is active at a time, while all links are still monitored (the system can detect a failure of active and backup links).

Each time a host changes its active interface, it sticks to the new one until it goes down. In this example, the hosts are not too much affected by the expiration time of the switches' forwarding tables.

If host1 and host2 have the same functionality and are used in load balancing by another external mechanism, it is good to have host1's active interface connected to one switch and host2's to the other. Such system will survive a failure of a single host, cable, or switch. The worst thing that may happen in the case of a switch failure is that half of the hosts will be temporarily unreachable until the other switch expires its tables.

Example 2: Using multiple ethernet cards connected to a switch to configure           NIC failover (switch is not required to support trunking).

         +----------+                          +----------+          |          |eth0                 port1|          |          | Host A   +--------------------------+  switch  |          |          +--------------------------+          |          |          |eth1                 port2|          |          +----------+                          +----------+

 On host A :                                 On the switch :     # modprobe bonding miimon=100 mode=1     # (optional) minimize the time     # ifconfig bond0 addr                    # for table expiration     # ifenslave bond0 eth0 eth1

Each time the host changes its active interface, it sticks to the new one until it goes down. In this example, the host is strongly affected by the expiration time of the switch forwarding table.

3 октября 2010 г. 23:52 пользователь Michael Bochkaryov написал: > Мое почтение всем! > > Не подскажет ли кто направление копания в такой задаче? > > Имеется: > 1) 2 сервера на linux c 2 x ethernet > 2) 2 управляемых свича с поддержкой link aggregation 802.3ad > > Нужно организовать "шибко надежный" ethernet для парочки серверов. > Чтобы как при вылете порта, так и при вылете одного из свичей сетка > продолжала работать, пускай и с меньшей скоростью. > > Можно ли link aggregation организовать на портах в разных свичах? > Или нужно на уровне IP это разруливать (чего не хочется)? > > Заранее спасибо :) > > -- > Regards, > Michael Bochkaryov > Net.Style - VoIP and VAS development > www.netstyle.com.ua > >

-- Yours, Max

-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

-- In theory, there is no difference between theory and practice. But, in practice, there is.

2010/10/4 Alexandre Snarskii

On Mon, Oct 04, 2010 at 11:30:03AM +0300, Michael Bochkaryov wrote:

...

Макисм, спасибо - bonding.txt я читал, как и LARTC. А вот с современными свичами я знаком куда хуже

Как реализовать failover only - вроде бы достаточно понятно. А вот что нужно, чтобы в нормальной ситуации были и HA, и load balancing - пока не уверен, что знаю.

Одновременно и HA и load-balancing на разных свитчах не бывает (разве что свитчи шибко умные, понимающие всякий кластеринг и так далее, но это не твой случай).

А не подскажешь на будущее, куда посмотреть стоит? Слишком уж чайником себя с этой задачкой почувствовал :)

Так что сделай failover only и не мучайся :)

Убедил :)

...

2010/10/4 Max Speransky

Хм, bonding.txt из линуксведра вполне раскрывает эту тему

2) HA on two or more switches (or a single switch without trunking support)

---------------------------------------------------------------------------

...

This mode is more problematic because it relies on the fact that

there

...

are multiple ports and the host's MAC address should be visible on

one

...

port only to avoid confusing the switches.

If you need to know which interface is the active one, and which ones

are

...

backup, use ifconfig. All backup interfaces have the NOARP flag set.

To use this mode, pass "mode=1" to the module at load time :

# modprobe bonding miimon=100 mode=1

Or, put in your /etc/modules.conf :

alias bond0 bonding options bond0 miimon=100 mode=1

Example 1: Using multiple host and multiple switches to build a "no

single

...

point of failure" solution.

| | |port3 port3| +-----+----+ +-----+----+ | |port7 ISL port7| | | switch A +--------------------------+ switch B | | +--------------------------+ | | |port8 port8| | +----++----+ +-----++---+ port2||port1 port1||port2 || +-------+ || |+-------------+ host1 +---------------+| | eth0 +-------+ eth1 | | | | +-------+ | +--------------+ host2 +----------------+ eth0 +-------+ eth1

In this configuration, there are an ISL - Inter Switch Link (could be

a

...

trunk), several servers (host1, host2 ...) attached to both switches each,

and one

...

or more ports to the outside world (port3...). One an only one slave on

each

...

host is active at a time, while all links are still monitored (the system

can

...

detect a failure of active and backup links).

Each time a host changes its active interface, it sticks to the new

one

...

until it goes down. In this example, the hosts are not too much affected by

the

...

expiration time of the switches' forwarding tables.

If host1 and host2 have the same functionality and are used in load balancing by another external mechanism, it is good to have host1's active

interface

...

connected to one switch and host2's to the other. Such system will

survive

...

a failure of a single host, cable, or switch. The worst thing that

may

...

happen in the case of a switch failure is that half of the hosts will be temporarily unreachable until the other switch expires its tables.

Example 2: Using multiple ethernet cards connected to a switch to

configure

...

NIC failover (switch is not required to support trunking).

+----------+ +----------+ | |eth0 port1| | | Host A +--------------------------+ switch | | +--------------------------+ | | |eth1 port2| | +----------+ +----------+

On host A : On the switch : # modprobe bonding miimon=100 mode=1 # (optional) minimize

the time

...

# ifconfig bond0 addr # for table expiration # ifenslave bond0 eth0 eth1

Each time the host changes its active interface, it sticks to the new

one

...

until it goes down. In this example, the host is strongly affected by the expiration time of the switch forwarding table.

3 октября 2010 г. 23:52 пользователь Michael Bochkaryov написал: > Мое почтение всем! > > Не подскажет ли кто направление копания в такой задаче? > > Имеется: > 1) 2 сервера на linux c 2 x ethernet > 2) 2 управляемых свича с поддержкой link aggregation 802.3ad > > Нужно организовать "шибко надежный" ethernet для парочки серверов. > Чтобы как при вылете порта, так и при вылете одного из свичей сетка > продолжала работать, пускай и с меньшей скоростью. > > Можно ли link aggregation организовать на портах в разных свичах? > Или нужно на уровне IP это разруливать (чего не хочется)? > > Заранее спасибо :) > > -- > Regards, > Michael Bochkaryov > Net.Style - VoIP and VAS development > www.netstyle.com.ua > >

-- Yours, Max

-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

-- In theory, there is no difference between theory and practice. But, in practice, there is.

-- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

On Mon, Oct 04, 2010 at 02:11:56PM +0300, Michael Bochkaryov wrote:

On Mon, Oct 04, 2010 at 11:30:03AM +0300, Michael Bochkaryov wrote: > Макисм, спасибо - bonding.txt я читал, как и LARTC. > А вот с современными свичами я знаком куда хуже > > Как реализовать failover only - вроде бы достаточно понятно. > А вот что нужно, чтобы в нормальной ситуации были и HA, > и load balancing - пока не уверен, что знаю.

Одновременно и HA и load-balancing на разных свитчах не бывает (разве что свитчи шибко умные, понимающие всякий кластеринг и так далее, но это не твой случай).

А не подскажешь на будущее, куда посмотреть стоит? Слишком уж чайником себя с этой задачкой почувствовал :)

Миш, тут нужно не столько читать, сколько помнить одну простую вещь - свитч, принявший пакет с некоего порта, "запоминает", что "этот src-mac живет здесь", и использует эту память для свитчинга следующих пакетов (в случае агрегата со стороны свитча запоминается, разумеется, не физический порт, а агрегат, которому он принадлежит)... В результате, если с одной стороны у тебя агрегат, а с другой - нет - получается веселая чехарда класса: linux посылает пакеты с одним и тем же src-mac'ом (ибо с его стороны это агрегат) то в один линк то в другой. И свитчи никак не могут понять - так куда же нужно пакеты для твоего linux'а отправлять - "напрямую" или "через соседа". Некоторые (которые поумнее) такой mac через какое-то время просто зануляют в Null0, другие просто начинают терять пакеты... -- In theory, there is no difference between theory and practice. But, in practice, there is.

2010/10/4 Michael Bochkaryov

[image: network-design-hw.png]

Как уже подсказали, для решения с динамической агрегацией линков нужна поддержка стекирования свичей.

В моем случае это не так, посему буду юзать failover bonding и один из портов на каждой физической ноде будет простаивать в ожидании трындеца.

а еще бывает так, что порт светит, но пакеты не свитчит. Шо тогда будешь делать? Вообще говоря, самое лучшее решение, которое можно применить - сделать IP-based failover. Поднять OSPF, можно даже закрутить таймеры и раутить/раутиться по состоянию сессии. Все остальное - костыли и обязательно найдется ситуация, при которой они не сработают. -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

2010/10/4 Vladimir Litovka

2010/10/4 Michael Bochkaryov

...

[image: network-design-hw.png]

Как уже подсказали, для решения с динамической агрегацией линков нужна поддержка стекирования свичей.

В моем случае это не так, посему буду юзать failover bonding и один из портов на каждой физической ноде будет простаивать в ожидании трындеца.

а еще бывает так, что порт светит, но пакеты не свитчит. Шо тогда будешь делать?

Свич менять :-) Но, насколько я помню, при failover bonding не только состояние линка проверяется.

Вообще говоря, самое лучшее решение, которое можно применить - сделать IP-based failover. Поднять OSPF, можно даже закрутить таймеры и раутить/раутиться по состоянию сессии. Все остальное - костыли и обязательно найдется ситуация, при которой они не сработают.

А это не слишком ли сложно для одного сегмента IP-сети в одном VLAN? -- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

2010/10/5 Vladimir Litovka

2010/10/5 Michael Bochkaryov

а еще бывает так, что порт светит, но пакеты не свитчит. Шо тогда будешь

...

...

делать?

Свич менять :-)

А, то есть полчасика на замену свича - это допустимое время простоя? :)

Нет, но тем временем будет работать другой свич. А если они оба такие - тогда бить морду поставщику :-)

...

Но, насколько я помню, при failover bonding не только состояние линка проверяется.

А что еще?

Например, ARP - если свич не свитчит, то это будет заметно.

...

Вообще говоря, самое лучшее решение, которое можно применить - сделать IP-based failover. Поднять OSPF, можно даже закрутить таймеры и раутить/раутиться по состоянию сессии. Все остальное - костыли и обязательно найдется ситуация, при которой они не сработают.

А это не слишком ли сложно для одного сегмента IP-сети в одном VLAN?

А что в этом сложного? поставить кваггу и поднять раутинг? делов на 20 минут - мы уже дольше дискутируем вопрос :-) зато гарантированно будет работать. IMHO проверка целостности на уровне IP всегда надежнее и качественнее любой хоботни на эзернете.

Ну, пока жду появления второго свича, хотя бы возможные варианты выясню :-) -- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

2010/10/5 Michael Bochkaryov А если они оба такие - тогда бить морду поставщику :-)

Если своя к тому моменту уцелеет ;-)

Но, насколько я помню, при failover bonding не только состояние линка

...

проверяется.

...

А что еще?

Например, ARP - если свич не свитчит, то это будет заметно.

если свитчит, если не свитчит... а если у него лег порт в сторону шлюза? мы тут, конечно, мальчики умные и что-нибудь и придумаем в любом случае - можем VRRP поднять, можем сделать кластер свичей, можем ARP'ы посылать... :) потом - вылезет еще что-нибудь и опять что-нибудь придумаем :) только вот - а зачем? моё имхо остается прежним - нельзя на ethernet'е сделать end-to-end надежное решение. Сервис у тебя работает на каком уровне? IP? ну так и механизмы failover ему делай на этом же уровне -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

Но про возможность использования OSPF в моей схеме (2 хоста + 2 свича) я таки посмотрю...

Это проще всего и однозначно работать будет. Главное, как я уже говорил - биндить приложение к lo0 aliases на обеих коробках

2010/10/5 Vladimir Litovka

Ну, усложнение схемы в общем случае надежность только понижает.

...

Потому что появляются новые сущности, которые тоже могут сбоить :-)

Тут такой момент - включая OSPF, ты можешь отказаться от сложных схем на L2. Так что непонятно, что окажется проще в конце-концов.

/* Зато я добавляю сложную схему на L3 в очень простой сетке. Причем, ограничиваюсь строго IP и какой-нибудь AoE мне не светит. */ Если в моей схеме оставить только два свича и два сервера, где сплит брейны возможны и опасны, то получается такое: +------+ +------+ | |- eth0 ----- [Sw1] ----- eth0 -| | | HN-1 | | HN-2 | | |- eth1 ----- [Sw2] ----- eth1 -| | +------+ +------+ Я правильно понимаю, что нужно на обоих нодах ставить по квагге? Причем, инт-сы eth0 и eth1 посадить в разные подсетки (A и B), через которые раздавать маршруты к адресам (C и D), на которых собственно сервисы висят? -- Regards, Michael Bochkaryov Net.Style - VoIP and VAS development www.netstyle.com.ua

Я правильно понимаю, что нужно на обоих нодах ставить по квагге?

или какой-либо другой routing agent почему непременно квагга

Причем, инт-сы eth0 и eth1 посадить в разные подсетки (A и B), через

да

которые раздавать маршруты к адресам (C и D), на которых собственно сервисы висят?

да

2010/10/5 Michael Bochkaryov :

Ну, усложнение схемы в общем случае надежность только понижает. Потому что появляются новые сущности, которые тоже могут сбоить :-)

Но про возможность использования OSPF в моей схеме (2 хоста + 2 свича) я таки посмотрю...

OSPF в квагге глючной. :-( -- VEL-[RIPE|UANIC]

2010/10/5 Vladimir Velychko :

2010/10/5 Michael Bochkaryov :

...

Ну, усложнение схемы в общем случае надежность только понижает. Потому что появляются новые сущности, которые тоже могут сбоить :-)

Но про возможность использования OSPF в моей схеме (2 хоста + 2 свича) я таки посмотрю...

OSPF в квагге глючной. :-(

На каждой машине BIRD или OpenBGPd с [e|i]BGP в сторону gateway L3 свитчей с поддержкой multipath. Получаеш per-flow load-balancing + state-less switchover. Схема легко масштабируется с 2-х серверов до N, где N - количество path, поддерживаемых ECMP и [i|e]BGP реализациями на gateway L3 свитчах. -- Regards, Volodymyr.

Володя, коллеги, ну какой BGP? BGP мееееедленный, он пока заметит, что линк упал, пока отреагирует... Тут именно OSPF оптимален by design да еще и с "поджатыми" таймерами (чтобы *быстро* реагировал на глюки сети). Да хоть и раз в 2 секунды поставь hello и пусть арбайтен себе, чай не 486-е процессоры нонче в тазиках, так и те справлялись ;) Глючный в квагге? да мало ли вменяемых реализаций. Помню на древних gated-ах OSPF превосходно работал. К слову гойворя, OSPF прекрасно справится и в варианте с предложенной выше "подпоркой" в виде PPP по RS-232 нуль-модему между компортами двух коробок. И ему сугубо все равно, что за свичи и что у них в мозгах и есть ли что-то вообще.

На каждой машине BIRD или OpenBGPd с [e|i]BGP в сторону gateway L3 свитчей с поддержкой multipath.

Получаеш per-flow load-balancing + state-less switchover.

Схема легко масштабируется с 2-х серверов до N, где N - количество path, поддерживаемых ECMP и [i|e]BGP реализациями на gateway L3 свитчах.

Вот это да, это красиво, но имхо для ситуации с N серверами в соседних стойках на 2 сегментах эзернета - это явный overkill aka из пушки по птичкам. С наилучшими, я

2010/10/5 Andrew Stesin :

Володя, коллеги,

ну какой BGP? BGP мееееедленный, он пока заметит, что линк упал, пока отреагирует... Тут именно OSPF оптимален by design да еще и с "поджатыми" таймерами (чтобы *быстро* реагировал на глюки сети). Да хоть и раз в 2 секунды поставь hello и пусть арбайтен себе, чай не 486-е процессоры нонче в тазиках, так и те справлялись ;)

А что мешает в BGP подкрутить таймеры окромя религии? :-)

Глючный в квагге? да мало ли вменяемых реализаций. Помню на древних gated-ах OSPF превосходно работал.

Вменяемых - мало. Как это ни странно с вменяемыми бесплатными реализациями BGP сейчас проще чем с IGP. Ну и еще вопрос есть ли в наличии OSPF multipath или BGP multipath.

К слову гойворя, OSPF прекрасно справится и в варианте с предложенной выше "подпоркой" в виде PPP по RS-232 нуль-модему между компортами двух коробок. И ему сугубо все равно, что за свичи и что у них в мозгах и есть ли что-то вообще.

:-)

...

На каждой машине BIRD или OpenBGPd с [e|i]BGP в сторону gateway L3 свитчей с поддержкой multipath.

Получаеш per-flow load-balancing + state-less switchover.

Схема легко масштабируется с 2-х серверов до N, где N - количество path, поддерживаемых ECMP и [i|e]BGP реализациями на gateway L3 свитчах.

Вот это да, это красиво, но имхо для ситуации с N серверами в соседних стойках на 2 сегментах эзернета - это явный overkill aka из пушки по птичкам.

Ты знаеш, судя по тенденциям в индустрии BGP как метод анонсирования доступности shared IP сейчас любят поболее IGP. -- Regards, Volodymyr.

2010/10/6 Vladimir Litovka :

2010/10/6 Volodymyr Yakovenko

...

А что мешает в BGP подкрутить таймеры окромя религии? :-) В BGP они, имхо, так не подкручиваются, до сабсеконд.

Поправьте меня, если я ошибаюсь, но раз уж BGP работает поверх TCP/IP то в результате этого таймеры BGP не получится "закрутить" больше, чем позволяют настройки таймеров TCP/IP стека, а их трогать ээээ нежелательно.

On Wed, Oct 06, 2010 at 09:49:19AM +0300, Andrew Stesin wrote:

К слову гойворя, OSPF прекрасно справится и в варианте с предложенной выше "подпоркой" в виде PPP по RS-232 нуль-модему между компортами двух коробок. И ему сугубо все равно, что за свичи и что у них в мозгах и есть ли что-то вообще.

just comment: nullmodem предлагался вовсе не для ppp и даже не для ip-траффика. По нему умеет работать heartbeat с heartbeat'ом, в результате даже в случае проблем с ethernet-сетью split-brain не наступает. -- In theory, there is no difference between theory and practice. But, in practice, there is.

RFCs и для BGP, и для OSPF задают значения таймеров в _секундах_ и переопределить их на миллисекунды без изменений/дополнений к существующих протоколам нельзя. Если нужно определение падения линка "как в SDH", то я бы смотрел на BFD - на него пару месяцев назад RFC вышел; правда авторы RFC из компании J и, скорее всего, компания C умеет более "правильную" версию BFD ;) Best wishes, Maxim 2010/10/6 Vladimir Litovka

2010/10/6 Volodymyr Yakovenko

А что мешает в BGP подкрутить таймеры окромя религии? :-)

...

В BGP они, имхо, так не подкручиваются, до сабсеконд.

-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

On Wed, Oct 06, 2010 at 05:08:20PM +0300, Vladimir Litovka wrote: [dd]

Та же проблема - можно на *nix гарантировать, что определенный процесс или thread будет получать управление с частотой, достаточной для посылки hello каждые 50ms?

Вендор J как раз и реализовал одним процессом: 1322 ?? S 55:51.90 /usr/sbin/ppmd -N -- ZA-RIPE||ZA1-UANIC

On Wed, Oct 06, 2010 at 05:33:30PM +0300, Andrey Zarechansky wrote:

On Wed, Oct 06, 2010 at 05:08:20PM +0300, Vladimir Litovka wrote: [dd]

...

Та же проблема - можно на *nix гарантировать, что определенный процесс или thread будет получать управление с частотой, достаточной для посылки hello каждые 50ms?

Вендор J как раз и реализовал одним процессом:

1322 ?? S 55:51.90 /usr/sbin/ppmd -N

Реализовать и гарантировать - всё же разные вещи. Банальный read retry SATA HDD/DVD, например, поставит раком половину ОС (Solaris с raidz2, в котором диск с 1400 ремапов порой конкретно тупит - похоже, диск в PIO mode слетает, хотя zpool status ничего плохого не показывает). Т.е. гарантировать "почти можно" на определённом наборе железа и софта - реализуемо в очень ограниченных масштабах. -- Best regards, Paul Arakelyan.

2010/10/7 Paul Arakelyan

Вендор J как раз и реализовал одним процессом:

...

1322 ?? S 55:51.90 /usr/sbin/ppmd -N

...

JunOS суть по своей FreeBSD :-)

Реализовать и гарантировать - всё же разные вещи. Банальный read retry

SATA HDD/DVD, например, поставит раком половину ОС (Solaris с raidz2, в котором диск с 1400 ремапов порой конкретно тупит - похоже, диск в PIO mode слетает, хотя zpool status ничего плохого не показывает).

Т.е. гарантировать "почти можно" на определённом наборе железа и софта - реализуемо в очень ограниченных масштабах.

Паша, спасибо, исчерпывающий ответ. То есть можно сказать, что если сервер не укомплектован периферией (вплоть до netboot в RAM), то шансы успешно реализовать на нем OSPF fast convergence существенно возрастают - это так? -- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/

On Thu, Oct 07, 2010 at 09:33:04AM +0300, Vladimir Litovka wrote:

2010/10/7 Paul Arakelyan Реализовать и гарантировать - всё же разные вещи. Банальный read retry

...

SATA HDD/DVD, например, поставит раком половину ОС (Solaris с raidz2, в котором диск с 1400 ремапов порой конкретно тупит - похоже, диск в PIO mode слетает, хотя zpool status ничего плохого не показывает).

Т.е. гарантировать "почти можно" на определённом наборе железа и софта - реализуемо в очень ограниченных масштабах.

Паша, спасибо, исчерпывающий ответ.

То есть можно сказать, что если сервер не укомплектован периферией (вплоть до netboot в RAM), то шансы успешно реализовать на нем OSPF fast convergence существенно возрастают - это так?

Да, если на нём ещё и не исполняется "хз что" впридачу. (Можно надеяться на шедулер, но в том же солярисе - чтение-запись с gzip'ed ZFS вгоняет в ступор 2 ядра запросто, с пингами как на луну, 4 - не помню, но тоже вполне загружаемо кажется. Мультимедиа при этом ваще лесом идёт). У меня есть "ХЗ что" - графики mrtg/rrdtool ;). Ещё "втуляние маршрутов в таблицы маршрутизации" - тоже процесс... И VPN там же, с компрессией :).Короче, нужен "controlled environment". Или костыли всякие, типа "проверим не пришло ли чего посреди пересчёта таблицы" (потоки наверно не совсем хорошо - ими шедулер рулит же). -- Best regards, Paul Arakelyan.