Думаю, используя виртуальный ввод-вывод в продуктивных lpar'ах, никто даже не задумывается, что VIOs может быть один. Плюсы двух VIO серверов очевидны. Если обойтись без лишних деталей, то их два:
Хочу рассмотреть здесь лишь один момент в этой связке - сеть.
Для начала попробуем изобразить, что нам нужно:
У нас есть 2 VIOS'а, много LPAR'ов и желание сделать красиво.
Итак, задача выпустить LPAR'ы наружу и понадежнее. Для этих целей можно использовать 2 метода:
1. SEA failover - родной IBM'овский способ научить VIOS'ы решать кто из них сейчас главный. При этом оба SEA бриджа находятся в одном VLAN'е виртуального коммутатора ETHERNET0. Чтобы избежать ARP-шторма, который обязательно случится, если оба SEA будут в активном состоянии, нужно подружить VIOS'ы. Для этого у каждого SEA появляется новый виртуальный адаптер в отдельном VLAN'е - ctl_chan. Дальше в подробности углубляться не будем, лишь посмотрим на картинку.
Безусловно, это смахивает на HighAvailability кластер (VIOS'ы - узлы, а ctl_chan - hartbeat). Вобщем, так оно и есть, только высокодоступный ресурс здесь один - выход наружу коммутатора ETHERNET0. А значит мы имеем сказочно-автоматический переезд линка между VIOS'ами при невозможности работы одного из них. В этом подходе сплошные плюсы:
....
Намекал на схему приведенную ниже - Network Interface Backup. Такая картинка позволяет впускать часть хостов через один VIOS и вторую часть через другой.
При таком подходе есть одна но очень большая проблема: при смерти VIOS1 сетка в LPAR1 может не переключиться с ent0 на ent1 сама! И вот почему:
NIB перебрасывает трафик с активного интерфейса на пассивный только в случае, если первый говорит LINK DOWN. А в нашем случае проблема не с ent0 в LPAR1, а с ent0 в VIOS1, то есть в SEA. Надо пинговать ...
to be continued...
- Возрастающая надежность виртуальных девайсов
- Воможность делать maintenance и апдейт одного VIOs не выключая второй - то есть возрастающая доступность LPAR'ов
Хочу рассмотреть здесь лишь один момент в этой связке - сеть.
Для начала попробуем изобразить, что нам нужно:
Итак, задача выпустить LPAR'ы наружу и понадежнее. Для этих целей можно использовать 2 метода:
1. SEA failover - родной IBM'овский способ научить VIOS'ы решать кто из них сейчас главный. При этом оба SEA бриджа находятся в одном VLAN'е виртуального коммутатора ETHERNET0. Чтобы избежать ARP-шторма, который обязательно случится, если оба SEA будут в активном состоянии, нужно подружить VIOS'ы. Для этого у каждого SEA появляется новый виртуальный адаптер в отдельном VLAN'е - ctl_chan. Дальше в подробности углубляться не будем, лишь посмотрим на картинку.
Безусловно, это смахивает на HighAvailability кластер (VIOS'ы - узлы, а ctl_chan - hartbeat). Вобщем, так оно и есть, только высокодоступный ресурс здесь один - выход наружу коммутатора ETHERNET0. А значит мы имеем сказочно-автоматический переезд линка между VIOS'ами при невозможности работы одного из них. В этом подходе сплошные плюсы:
- Полная автоматика с возможностью ручного управления (за подробностями в комменты)
- Поддержка тегированного трафика в обе стороны
- Прозрачность для LPAR'ов
- Относительно простое конфигурирование
- Возможность динамического изменения параметров схемы
- и т.д.
....
Намекал на схему приведенную ниже - Network Interface Backup. Такая картинка позволяет впускать часть хостов через один VIOS и вторую часть через другой.
При таком подходе есть одна но очень большая проблема: при смерти VIOS1 сетка в LPAR1 может не переключиться с ent0 на ent1 сама! И вот почему:
NIB перебрасывает трафик с активного интерфейса на пассивный только в случае, если первый говорит LINK DOWN. А в нашем случае проблема не с ent0 в LPAR1, а с ent0 в VIOS1, то есть в SEA. Надо пинговать ...
to be continued...



А ежели так?
ОтветитьУдалитьhttp://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/p7hb1/iphb1_vios_scenario_sea_load_sharing.htm