Комментарии 15
А куда этот Солярис подключен (коммутатор, наверное?), и как оно воспримет IPMP? Кстати, ведь протоколу IEEE 802.3ad уже больше десяти лет — Сану сложно было сделать стандартную агрегацию каналов?
ipmp со стороны маршрутизатора видится только как all-host multicast, на который он ( маршрутизатор) не должен отвечать, так как это не all-router multicast, а даже если ответит, то просто будет потом получать icmp ping и отвечать на них
и ipmp это скорее next-hop redundancy protocol, а не link aggregation, хотя и поддерживает агрегацию.
и ipmp это скорее next-hop redundancy protocol, а не link aggregation, хотя и поддерживает агрегацию.
Для Сана это и есть стандартная агрегация каналов. И пока лучше IPMP для Oracle Sun (к сожалению теперь их так величают), лучше ничего не придумали. И зачем создавать новый велосипед, ipmp легок в настройке и вполне оправдывает свое применение на продакшен уровне.
Правильно ли я понял, что использоваться будет только одна сетевая карта, а вторая подхватит в случае выхода из строя первой?
Тогда действительно получается какой-то next-hop redundancy protocol.
Тогда действительно получается какой-то next-hop redundancy protocol.
IPMP выполнят две задачи, это избыточность сетевых карт (в следствии достигается отказоустойчивость) и балансировка нагрузки исходящего трафика, т.е. в моем примере получается что, ввод трафика будет происходит одной сетевой картой, а вывод двумя.
Но также (прошу прощения, забыл указать это в статье) существует реализация протокола LACP под solaris, он в свою очередь работает на уровне mac адресации, в отличии от ipmp работающего на 3-ем уровне, со всеми выходящими от сюда плюсами и минусами. Более подробно о преимуществах вам скажут тут
Но также (прошу прощения, забыл указать это в статье) существует реализация протокола LACP под solaris, он в свою очередь работает на уровне mac адресации, в отличии от ipmp работающего на 3-ем уровне, со всеми выходящими от сюда плюсами и минусами. Более подробно о преимуществах вам скажут тут
А как же агрегация LACP с помощью dladm? ( sk1f3r.ru/lacp )
спасибо большое, как раз с этим мучаюсь уже пару дней
У вас несколько неточностей:
1. multicast адрес не пингуется, а используется для определения хостов в подести, которые потом в свою очередь пингуются.
2. link-based mode настроен всегда, когда настроен ipmp. то есть точнее два режима это link-based & link-based+probe-based.
3. последний `+` в строке с addif — лишний.
1. multicast адрес не пингуется, а используется для определения хостов в подести, которые потом в свою очередь пингуются.
2. link-based mode настроен всегда, когда настроен ipmp. то есть точнее два режима это link-based & link-based+probe-based.
3. последний `+` в строке с addif — лишний.
Хмм… не хочу показаться грубым, но кажется это у вас кое-какие не точности.
1. В solaris-е multicast пингуется, это можно проверить выводами команд netstat -rn, ping 224.0.0.1. Другой вопрос для чего он там нужен. Но думаю это сюжет для отдельной статьи. Если есть интерес, то могу в ближайшем будущем раскрыть данную тему.
2. Суть Вашего второго замечания для меня не вполне понятна. Где это Вы увидели в статье о настройке link-based mode? Я сразу написал, что рассматриваю только probe-based.
3. Знак + возможно лишний, но это мой рабочий конф. файл. В принципе сам файл /etc/hostname.* можно заполнить как угодно, в зависимости от конкретной ситуации, достаточно внимательно прочитать man ifconfig и не забыть добавить ipmp группу.
1. В solaris-е multicast пингуется, это можно проверить выводами команд netstat -rn, ping 224.0.0.1. Другой вопрос для чего он там нужен. Но думаю это сюжет для отдельной статьи. Если есть интерес, то могу в ближайшем будущем раскрыть данную тему.
2. Суть Вашего второго замечания для меня не вполне понятна. Где это Вы увидели в статье о настройке link-based mode? Я сразу написал, что рассматриваю только probe-based.
3. Знак + возможно лишний, но это мой рабочий конф. файл. В принципе сам файл /etc/hostname.* можно заполнить как угодно, в зависимости от конкретной ситуации, достаточно внимательно прочитать man ifconfig и не забыть добавить ipmp группу.
1. не спорю что мультикаст пингуется. в случае ipmp сервер шлет пакет на 224.0.0.1, фиксирует первые пять, по-моему, хостов, кто ответил на него, заносит в список target host и потом каждого отдельно с помощью unicast ping проверяет.
2. вы написали что ipmp может работать в двух режимах. я написал, что это не совсем точно и что два режима, в которых ipmp может работать это link-based и llink+probe mode
2. вы написали что ipmp может работать в двух режимах. я написал, что это не совсем точно и что два режима, в которых ipmp может работать это link-based и llink+probe mode
1.С первым утверждением согласен.
2. В пору, когда я готовился к сертификации по Oracle Solaris 10 Network Administrator, в книжке было написано следующее:
Probe-based IPMP Configurations Compared With Link-based IPMP Configurations:
There are two methods for configuring IPMP: probe-based and link-based. Probe-based IPMP utilizes test addresses to monitor the health of interfaces. Link-based IPMP does not utilize test addresses. Instead, the interface kernel driver performs this function.
Так что даже не знаю кому верить. Скорее всего, правильно было бы указать именно про два метода работы ipmp, а не режима, хотя на мой взгляд суть от этого не изменилась бы.
2. В пору, когда я готовился к сертификации по Oracle Solaris 10 Network Administrator, в книжке было написано следующее:
Probe-based IPMP Configurations Compared With Link-based IPMP Configurations:
There are two methods for configuring IPMP: probe-based and link-based. Probe-based IPMP utilizes test addresses to monitor the health of interfaces. Link-based IPMP does not utilize test addresses. Instead, the interface kernel driver performs this function.
Так что даже не знаю кому верить. Скорее всего, правильно было бы указать именно про два метода работы ipmp, а не режима, хотя на мой взгляд суть от этого не изменилась бы.
с 10-той Солярой ещё не ковырялся, но в 9-той вникал в этот вопрос глубоко.
Во первых на счёт того, кому верить.
Курил много инфы по сабжу, и форумы и книжки для подготовки на SCNA, но самым информативным и близким к истине оказался «man mpath.d».
(Истину проверял снятием снифов посредством Wireshark и snoop)
А ещё очень полезной оказалась эта статья
Во вторых на счёт двух режимов я с вами не очень-то согласен. Вы указываете на обоих интерфейсах группу, а дальше есть варианты и их далеко не два!
Вы задаёте параметр -failover и соответственно интерфейсы работают в режиме ACTIVE-STANDBY. Но если этот параметр не задавать, то все интерфейсы группы будут работать в режиме ACTIVE-ACTIVE, о чём вы вообще не упоминаете (а оно работает — проверено!).
Вы задаёте параметр DEPRICATED — на самом деле этот параметр означает, что IP адрес данного интерфейса будет использоваться для сбора проб в данной группе. Это даёт много вариантов настройки для всевозможных ситуаций. Например для выявления отказа коммутатора можно использовать один интерфейс, а для передачи трафика другой. Или например можно включить интерфейс в группу, но не задавать ему DEPRICATED адрес, тогда он будет участвовать в группе, но пробы с него делаться не будут, ну и т.д.
В файле /etc/default/mpathd тоже есть чего поправить, а вы его даже не упомянули.
Например там можно указать время FAILURE_DETECTION. Там же можно указать FAILBACK — т.е. делать ли его вообще. Время FAILBACK'a равно двойному значению FAILURE_DETECTION.
А ещё там можно включить сбор проб для ВСЕХ интерфейсов, а не только для тех, которые участвуют в группах, а трафиком управлять уже за счёт таблицы маршрутизации.
Вообщем, назвался груздем — полезай в кузов. Взялись писать «статью на хабр», можно было бы уж уделить внимание теории и написать человеческий обзор IPMP, а не пионэрский очерк в две строчки «самого интересного» (и нихрена непонятного).
Во первых на счёт того, кому верить.
Курил много инфы по сабжу, и форумы и книжки для подготовки на SCNA, но самым информативным и близким к истине оказался «man mpath.d».
(Истину проверял снятием снифов посредством Wireshark и snoop)
А ещё очень полезной оказалась эта статья
Во вторых на счёт двух режимов я с вами не очень-то согласен. Вы указываете на обоих интерфейсах группу, а дальше есть варианты и их далеко не два!
Вы задаёте параметр -failover и соответственно интерфейсы работают в режиме ACTIVE-STANDBY. Но если этот параметр не задавать, то все интерфейсы группы будут работать в режиме ACTIVE-ACTIVE, о чём вы вообще не упоминаете (а оно работает — проверено!).
Вы задаёте параметр DEPRICATED — на самом деле этот параметр означает, что IP адрес данного интерфейса будет использоваться для сбора проб в данной группе. Это даёт много вариантов настройки для всевозможных ситуаций. Например для выявления отказа коммутатора можно использовать один интерфейс, а для передачи трафика другой. Или например можно включить интерфейс в группу, но не задавать ему DEPRICATED адрес, тогда он будет участвовать в группе, но пробы с него делаться не будут, ну и т.д.
В файле /etc/default/mpathd тоже есть чего поправить, а вы его даже не упомянули.
Например там можно указать время FAILURE_DETECTION. Там же можно указать FAILBACK — т.е. делать ли его вообще. Время FAILBACK'a равно двойному значению FAILURE_DETECTION.
А ещё там можно включить сбор проб для ВСЕХ интерфейсов, а не только для тех, которые участвуют в группах, а трафиком управлять уже за счёт таблицы маршрутизации.
Вообщем, назвался груздем — полезай в кузов. Взялись писать «статью на хабр», можно было бы уж уделить внимание теории и написать человеческий обзор IPMP, а не пионэрский очерк в две строчки «самого интересного» (и нихрена непонятного).
Во первых, то что вы все изучили и проверили, достойно уважения. Как было уже отмечено выше, все что нужно при настройке ipmp — это внимательно прочитать ман ifconfig.
Во вторых, как уже я отписался в комментарии выше, да, действительно, правильнее было бы написать, что существует по сути только два метода (а не режима) работы IPMP, а вот режимов куда поболее будут.
Согласен, я не очень то подробно расписал про все переменные которые использовались при настройке интерфейсов, но я упомянул в статье о том что, все взято из man ifconfig. Дело в том что у меня на все это ушло около 30 минут, что бы разобраться, какие именно параметры добавлять в /etc/hostname.* и я не увидел в этом ничего сложно, чтоб расписывать и растравлять, как говориться все «по полочкам».
ИМХО: ipmp не та тема, которая требует детальный обзор для хабра, а вот готовый шаблон настроек для повседневной жизни админа, самое оно.
А не счет последнего утверждения, опять таки же, ничего супер сложного нет в настройке ipmp, все уже давно расписано в ман ifconfig, поэтому:
Прошу прощения, если вам, как вы написали, «нихрена непонятно». Но судя по одному из коментариев, кому та она не много помогла.
Но в любом случае, спасибо за конструктивную критику. Была бы карма, плюсанул бы, честно)
Во вторых, как уже я отписался в комментарии выше, да, действительно, правильнее было бы написать, что существует по сути только два метода (а не режима) работы IPMP, а вот режимов куда поболее будут.
Согласен, я не очень то подробно расписал про все переменные которые использовались при настройке интерфейсов, но я упомянул в статье о том что, все взято из man ifconfig. Дело в том что у меня на все это ушло около 30 минут, что бы разобраться, какие именно параметры добавлять в /etc/hostname.* и я не увидел в этом ничего сложно, чтоб расписывать и растравлять, как говориться все «по полочкам».
ИМХО: ipmp не та тема, которая требует детальный обзор для хабра, а вот готовый шаблон настроек для повседневной жизни админа, самое оно.
А не счет последнего утверждения, опять таки же, ничего супер сложного нет в настройке ipmp, все уже давно расписано в ман ifconfig, поэтому:
… хочу сразу предупредить, что статья несет в основном практическую нагрузку, поэтому заранее извиняюсь если где то не в полном объеме раскрыл теоретическую составляющую данной темы...
Прошу прощения, если вам, как вы написали, «нихрена непонятно». Но судя по одному из коментариев, кому та она не много помогла.
Но в любом случае, спасибо за конструктивную критику. Была бы карма, плюсанул бы, честно)
link-based работает как само-собой разумеется… казалось бы, да.
Но я имел опыт с Solaris x86, который НЕ реагировал на физическое падение линка и фактически работал только в probe-mode.
Т.е. Соляра в упор не видела, что у неё упал интерфейс, при этом если ей было кого пинговать, то методом PROBE она могла обнаружить падения интерфейса.
Так что режим probe-mode (без link) в природе тоже встречается!
Хотя это скорее глюк, чем фича.
=)
Но я имел опыт с Solaris x86, который НЕ реагировал на физическое падение линка и фактически работал только в probe-mode.
Т.е. Соляра в упор не видела, что у неё упал интерфейс, при этом если ей было кого пинговать, то методом PROBE она могла обнаружить падения интерфейса.
Так что режим probe-mode (без link) в природе тоже встречается!
Хотя это скорее глюк, чем фича.
=)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IP Multipathing в Solaris 10