Comments 35
Здорово, что так все получилось. И отдельно круто, что это все уложилось в пару человекодней — например, для тех команд, с которыми я взаимодействую, я бы выставлял первоначальную оценку «на покопаться» без гарантий результата в пару-тройку человеконедель. Тут, конечно, повезло, что в changelog'ах что-то получилось найти, но в целом скорость работы — прокопать такое за пару дней — впечатляющая. И инфраструктура должна быть весьма отточенная для такого.
Ну, я изложил сильно прилизанную историю. В процессе там был ещё случайно поставленный в нашем роутере (для тестового тенанта) mtu 1400, который мне изрядно попил крови, ибо я совсем офигевал от цифры 1400 в MTU, некоторое количество глупостей и ложных следов (я в какой-то момент заподозрил, что это KVM tap'ы портит и полез не туда читать).
Но основное, это, конечно, доступные сырцы. Для проприетарного оно бы так и осталось загадкой.
Но основное, это, конечно, доступные сырцы. Для проприетарного оно бы так и осталось загадкой.
Т.е. «два человекодня» — это не оценка «сколько получилось», а «сколько должно было бы получиться, если бы все разбирательство шло сразу по оптимальному маршруту»?
Для проприетарного — все превращается в пинание мячика с очередными китайцами / индусами / кем-нибудь подобным из IBM / HP / EMC / Dell / Cisco / кем-нибудь таким… Решить можно, но да, обычно на порядок-два дольше и в итоге, как правило, совсем нерентабельно, если только ты не какой-нибудь гугл или фейсбук, чтобы у вендора был стимул довести решение до рабочего состояния, а не пройти очередной раз по маршруту вида «мы с вашей железкой уже полгода копаемся, у нас вон вообще новая вышла — покупайте, что ли, ее, мигрируйте, а там видно будет — и баг этот ваш скорее всего пройдет».
Для проприетарного — все превращается в пинание мячика с очередными китайцами / индусами / кем-нибудь подобным из IBM / HP / EMC / Dell / Cisco / кем-нибудь таким… Решить можно, но да, обычно на порядок-два дольше и в итоге, как правило, совсем нерентабельно, если только ты не какой-нибудь гугл или фейсбук, чтобы у вендора был стимул довести решение до рабочего состояния, а не пройти очередной раз по маршруту вида «мы с вашей железкой уже полгода копаемся, у нас вон вообще новая вышла — покупайте, что ли, ее, мигрируйте, а там видно будет — и баг этот ваш скорее всего пройдет».
Я занимался не только этой штукой, реально история заняла по wallclock примерно три дня, первый день я сильно затупил на mtu 4000, поставленным внутри виртуального роутера у нашего тестового тенанта.
Да, я наблюдал это перепинывание с Juniper'ом, когда их SRX намертво подвисал при маленьком флуде PUP-пакетами на входящих интерфейсах. Индусы честно собрали стенд, воспроизвели проблему. За те пол-года, как я наблюдал за историей, никаких подвижек не было.
Да, я наблюдал это перепинывание с Juniper'ом, когда их SRX намертво подвисал при маленьком флуде PUP-пакетами на входящих интерфейсах. Индусы честно собрали стенд, воспроизвели проблему. За те пол-года, как я наблюдал за историей, никаких подвижек не было.
Ну, в итоге-то все как бы грустно и утыкается в то, что, например, насколько я понимаю, внутреннее устройство ядра какого-нибудь IOS'а или хотя бы какого-нибудь MegaRAID — представляют что-нибудь типа десяток человек на этой планете. Эти люди загружены работой на ближайшие лет 10-20, и индусы из внедрения, очевидно, в их число не входят.
Ну, IOS это фатально, да. А MegaRAID в случае затруднений локализуется (по появляющейся проблеме) и заменяется на HBA.
Другое дело, что SAS HBA — это тот ещё лес со своим интеллектом и глюками. На удивление, наиболее беспроблемными были обычные интеловские южные мосты с AHCI.
Другое дело, что SAS HBA — это тот ещё лес со своим интеллектом и глюками. На удивление, наиболее беспроблемными были обычные интеловские южные мосты с AHCI.
Эх, умели бы еще эти чудесные южные мосты больше 5-6 дисков — цены б им не было.
А так — да, у меня на самом деле особенно к производителям storage за последние пару недель какая-то объективная ненависть нарастает. Ну, блин, как можно было до такого ада в индустрии дойти — «ах, у нас есть SMART, но мы вам не скажем, что он показывает, это наша Большая Военная Тайна»…
А так — да, у меня на самом деле особенно к производителям storage за последние пару недель какая-то объективная ненависть нарастает. Ну, блин, как можно было до такого ада в индустрии дойти — «ах, у нас есть SMART, но мы вам не скажем, что он показывает, это наша Большая Военная Тайна»…
Есть ещё smartctl -x, там иногда лог ошибок можно почитать. Это в контексте дисков, конечно.
Да я как бы в курсе… На самом деле — сколько смотрю уже из опыта за последние лет 5 — у меня чем дальше, тем больше зреет ненулевое желание отказаться от SMART нафиг.
Меня по сути не очень интересует окончательная смерть конкретного диска — ее распознают вполне штатными средствами и диск поменяют. Меня не интересует предварительная сигнализация о скорой смерти диска (по первоначальной задумке полезная для унылых «домашних» пользователей десктопа-с-одним-жестким-диском-без-бэкапов) — мне не нужно в этом случае внезапно начинать рвать волосы и пытаться спасти с диска хоть что-нибудь. Сдохнет — и фиг с ним, на новый данные накатятся из реплики и будет все ок.
Гораздо неприятнее когда диск стабильно начинает ощутимо тормозить (в 2-3-5-10-100 раз) или внезапно впадать в ступоры по 3-5 секунд (что внезапно будет означать падение iops до эдак ~0.2..0.3) — при этом в SMART все кристально чисто, якобы формальных поводов для тревоги нет. Разумеется, будучи элементом какого-либо массива или распределенной файловой системы, внезапно, от такого «слабого звена» начинает страдать весь массив или ФС.
Универсального рецепта я для себя так пока и не выработал. По идее хорошо бы проводить время от времени эталонные тесты и замеры скоростей всех шпинделей, но для этого надо вводить в систему некие интервалы на обслуживание — скажем, объявлять каждую ночь пятиминутку тестирования, когда приостанавливается вся дисковая активность и мы прогоняем тесты. К сожалению, на практике так делать можно далеко не всегда — для того же вычислительного кластера, скажем, тупо остановка может занимать минут 30-40, а потом еще минут 15 на запуск — терять час времени в сутки печально. Если на диски все время идет некая более-менее равномерная активность — то можно обойтись без тестов и мерять среднее значение этой активности. Но это тоже не универсальный рецепт — далеко не везде есть равномерная активность…
Меня по сути не очень интересует окончательная смерть конкретного диска — ее распознают вполне штатными средствами и диск поменяют. Меня не интересует предварительная сигнализация о скорой смерти диска (по первоначальной задумке полезная для унылых «домашних» пользователей десктопа-с-одним-жестким-диском-без-бэкапов) — мне не нужно в этом случае внезапно начинать рвать волосы и пытаться спасти с диска хоть что-нибудь. Сдохнет — и фиг с ним, на новый данные накатятся из реплики и будет все ок.
Гораздо неприятнее когда диск стабильно начинает ощутимо тормозить (в 2-3-5-10-100 раз) или внезапно впадать в ступоры по 3-5 секунд (что внезапно будет означать падение iops до эдак ~0.2..0.3) — при этом в SMART все кристально чисто, якобы формальных поводов для тревоги нет. Разумеется, будучи элементом какого-либо массива или распределенной файловой системы, внезапно, от такого «слабого звена» начинает страдать весь массив или ФС.
Универсального рецепта я для себя так пока и не выработал. По идее хорошо бы проводить время от времени эталонные тесты и замеры скоростей всех шпинделей, но для этого надо вводить в систему некие интервалы на обслуживание — скажем, объявлять каждую ночь пятиминутку тестирования, когда приостанавливается вся дисковая активность и мы прогоняем тесты. К сожалению, на практике так делать можно далеко не всегда — для того же вычислительного кластера, скажем, тупо остановка может занимать минут 30-40, а потом еще минут 15 на запуск — терять час времени в сутки печально. Если на диски все время идет некая более-менее равномерная активность — то можно обойтись без тестов и мерять среднее значение этой активности. Но это тоже не универсальный рецепт — далеко не везде есть равномерная активность…
Я про SCT ERC давно уже писал: geektimes.ru/post/92701/
Про ERC я тоже в курсе. До ERC в этих случаях не доходит — здесь нет такого, чтобы запрошенный сектор или чанк читался больше ERC-времени (или соответствующих count'ов в SAS) — конкретный сектор-то прочитается, а вот средняя скорость будет очень печальной (ну или не очень, а просто печальной — внезапные 15-20 МБпс вместо положенных 80-100, скажем — уже печально).
Выставлять таймауты ERC в какие-то сильно маленькие значения желания тоже нет — в конце концов, совершенно не хочется иметь перспективу умирающего на пустом месте сервера / деградирующего и всех соответствующих перестроений из-за одной случайной мелочи.
В идеале хотелось бы видеть именно то, для чего изначально был придуман SMART — четко видеть остаток ресурса HDD и его деградацию со временем. SMART же в текущем его состоянии годится в лучшем случае различать 3 состояния «вроде бы жив, почти мертв, мертв». Если не повезет — то даже 2 крайних.
Выставлять таймауты ERC в какие-то сильно маленькие значения желания тоже нет — в конце концов, совершенно не хочется иметь перспективу умирающего на пустом месте сервера / деградирующего и всех соответствующих перестроений из-за одной случайной мелочи.
В идеале хотелось бы видеть именно то, для чего изначально был придуман SMART — четко видеть остаток ресурса HDD и его деградацию со временем. SMART же в текущем его состоянии годится в лучшем случае различать 3 состояния «вроде бы жив, почти мертв, мертв». Если не повезет — то даже 2 крайних.
… копирует флаг do not fragment из исходного IP-пакета. Большие пакеты, которые не «влазили» в MTU после дописывания к ним заголовка, больше не фрагментировались, а дропались.
Это объясняет, почему перестали проходить пинги с явно выставленным DF, но почему обычный трафик отваливался?
Можно ли такое обнаружить мониторингом упреждающе? Сказать честно, разумных вариантов я не вижу — слишком тонкая и сложная диагностика, требующая крайней кооперации со стороны клиентских инстансов
А фрагментацию пакетов мониторить не получится?
Честно, не разбирался, но, подозреваю, что это связано с реализацией PMTUD в TCP на IPv4, которая ожидает получения ICMP о превышении размера. Оно должно было отработать, если бы пакет не пролезал в роутер, но вместо этого не пролезал в интерфейс уже GRE-пакет. Хост слал ICMP отправителю GRE, а до отправителя TCP оно не доходило, так что TCP тупило до упора. В сравнении с этим TCP IPv6 обрабатывает эту ситуацию не ожидая ICMP.
Мониторить фрагментацию… Идея интересная, но я метрик пока не видел. Найду, сделаем.
Мониторить фрагментацию… Идея интересная, но я метрик пока не видел. Найду, сделаем.
А фрагментацию пакетов мониторить не получится?
А она разве сама по себе что-то говорит? Даже если выделить пакеты одного клиента и найти среди них фрагментированные — то надо вводить тучу каких-то неочевидных, вычислительно сложных и, самое главное, сильно зависящих от типового трафика клиента правил типа «два больших пакета = хорошо, а один большой и один обкусок на 12 байт = плохо». Не говоря уже о том, что это все надо делать на потоке из скольких-то там миллионов пакетов в секунду…
Тут проблема в другом — у нас были фрагменты на контролируемых нами интерфейсов, то есть у нас были кривые MTU.
А, т.е., грубо говоря, в этом конкретном роутере правильное количество фрагментаций должно быть 0?
Не роутере. Схема openstack'а: инстансы работают на compute, их трафик попадает в overlay network, откуда отсылается на сетевые ноды, откуда уже уходит в интернеты (и обратно аналогично). В этой схеме пользовательский трафик ходит только в туннелях, то есть «голыми» на интерфейсах есть только служебные (контролируемые нами) пакеты. Если с нашей стороны всё настроено правильно, то фрагменты не должны возникать.
Внезапно, netstat -s показывает количество фрагментов. С учётом, что у нас интерфейсы на compute контролируются только нами, их быть не должно. Спасибо большое, будем мониторить.
В tshark (ключик -R) можно пофильтровать все, хоть черта лысого, так же как и в wireshark. очень полезный навык при дебаге всяких сетевых непоняток.
От wireshark'а меня интересуют не фильтры, а «потыкать мышкой по пакету». Для остального tcpdump и pcap-filter справляются.
Сам же в статье написал что не справилось.
Эм… Тут всё сложнее. И wireshark, и tcpdump не фильтруют сами, а используют механизм pcap-filter, который фильтрует пакеты в ядре, и интересные присылает по netsocket'у. То есть если pcap в нормальном режиме не отработает, то он одинаково не отработает у всех. То есть правило для tshark'а будет выглядеть так же, как для wireshark'а — с указанием диапазона байтов и hex-кодов.
У wireshark/tshark есть еще и свои фильтры. Которые позволяют сделать например так:
tgz@dhcp1 ~ % sudo tshark -i eth0 -R «bootp.type == 1»
Running as user «root» and group «root». This could be dangerous.
Capturing on eth0
34.743298 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
34.743687 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
34.743854 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
34.743934 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
Как видим, никаких диапазонов и прочей hex'овни. Причем фильтр сработает даже если этот DHCP пакет был внутри GRE, который внутри IP, который внутри PPP, который внутри MPLS и так далее.
tgz@dhcp1 ~ % sudo tshark -i eth0 -R «bootp.type == 1»
Running as user «root» and group «root». This could be dangerous.
Capturing on eth0
34.743298 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
34.743687 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
34.743854 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
34.743934 10.11.64.64 -> 172.33.193.81 DHCP 333 DHCP Request — Transaction ID 0x30cd1ee4
Как видим, никаких диапазонов и прочей hex'овни. Причем фильтр сработает даже если этот DHCP пакет был внутри GRE, который внутри IP, который внутри PPP, который внутри MPLS и так далее.
О, а вот это уже очень интересно. Я исходил из предположения, что там у всех pcaps без вариантов. Сейчас поиграюсь, спасибо.
… wow. Он ловит грешный трафик. Спасибо!
… wow. Он ловит грешный трафик. Спасибо!
Там очень серьёзные фильтры.
Была задача собирать логи звонков с H.323, проходящего транзитом через микротик.
Оказалось, что всё декодирование можно сделать консольным tshark'ом — он легко достаёт всю необходимую информацию из туннеля TZSP (в нём микротик отдаёт зеркалированный трафик), в котором лежат пакеты с Q.931.
Была задача собирать логи звонков с H.323, проходящего транзитом через микротик.
Оказалось, что всё декодирование можно сделать консольным tshark'ом — он легко достаёт всю необходимую информацию из туннеля TZSP (в нём микротик отдаёт зеркалированный трафик), в котором лежат пакеты с Q.931.
Великолепно. Напомнило старую историю об электронной почте, которая «не ходит дальше 300 миль» =) Тоже регрессия после обновления, ага.
Кажется, что наследование DF протоколом GRE из IP, это баг.
Сложный вопрос. Я нашёл место, где его добавили (почти) текущий код:
commit c19e654ddbe3831252f61e76a74d661e1a755530
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Oct 9 11:59:55 2008 -0700
gre: Add netlink interface
This patch adds a netlink interface that will eventually displace
the existing ioctl interface. It utilises the elegant rtnl_link_ops
mechanism.
This also means that user-space no longer needs to rely on the
tunnel interface being of type GRE to identify GRE tunnels. The
identification can now occur using rtnl_link_ops.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
…
+ NLA_PUT_U8(skb, IFLA_GRE_PMTUDISC, !!(p->iph.frag_off & htons(IP_DF)));
Но при этом убрали функцию ipgre_tunnel_init, а к ней есть такой потрясающий комментарий в модуле:
То есть раньше GRE всегда шёл с DNF, потом требования смягчили. А у собственной реализации OVS это поведение настраивается опциями, то есть в процессе переключения неявно поменяли дефолты в OVS'е и отключили один из вариантов поведения. Линукс винить нельзя, OVS винить нельзя, нас винить нельзя, никто не виноват, а на выходе оно работает «не так».
Потрясающая история даже вне контекста беготни за MTU.
commit c19e654ddbe3831252f61e76a74d661e1a755530
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Oct 9 11:59:55 2008 -0700
gre: Add netlink interface
This patch adds a netlink interface that will eventually displace
the existing ioctl interface. It utilises the elegant rtnl_link_ops
mechanism.
This also means that user-space no longer needs to rely on the
tunnel interface being of type GRE to identify GRE tunnels. The
identification can now occur using rtnl_link_ops.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
…
+ NLA_PUT_U8(skb, IFLA_GRE_PMTUDISC, !!(p->iph.frag_off & htons(IP_DF)));
Но при этом убрали функцию ipgre_tunnel_init, а к ней есть такой потрясающий комментарий в модуле:
2. Networking dead loops would not kill routers, but would really
kill network. IP hop limit plays role of «t->recursion» in this case,
if we copy it from packet being encapsulated to upper header.
It is very good solution, but it introduces two problems:
— Routing protocols, using packets with ttl=1 (OSPF, RIP2),
do not work over tunnels.
— traceroute does not work. I planned to relay ICMP from tunnel,
so that this problem would be solved and traceroute output
would even more informative. This idea appeared to be wrong:
only Linux complies to rfc1812 now (yes, guys, Linux is the only
true router now :-)), all routers (at least, in neighbourhood of mine)
return only 8 bytes of payload. It is the end.
Hence, if we want that OSPF worked or traceroute said something reasonable,
we should search for another solution.
One of them is to parse packet trying to detect inner encapsulation
made by our node. It is difficult or even impossible, especially,
taking into account fragmentation. TO be short, tt is not solution at all.
Current solution: The solution was UNEXPECTEDLY SIMPLE.
We force DF flag on tunnels with preconfigured hop limit,
that is ALL. :-) Well, it does not remove the problem completely,
but exponential growth of network traffic is changed to linear
(branches, that exceed pmtu are pruned) and tunnel mtu
fastly degrades to value <68, where looping stops.
Yes, it is not good if there exists a router in the loop,
which does not force DF, even when encapsulating packets have DF set.
But it is not our problem! Nobody could accuse us, we made
all that we could make. Even if it is your gated who injected
fatal route to network, even if it were you who configured
fatal static route: you are innocent. :-)
То есть раньше GRE всегда шёл с DNF, потом требования смягчили. А у собственной реализации OVS это поведение настраивается опциями, то есть в процессе переключения неявно поменяли дефолты в OVS'е и отключили один из вариантов поведения. Линукс винить нельзя, OVS винить нельзя, нас винить нельзя, никто не виноват, а на выходе оно работает «не так».
Потрясающая история даже вне контекста беготни за MTU.
История несомненно увлекательная! Но у меня возник вопрос про MTU на виртуалках. Зачем там MTU меньше чем 1500?
Мне, как конечному пользователю, привычнее видеть MTU = 1500 байт. Опять же чем меньше MTU тем больше overhead стека TCP/IP.
Разве не лучше увеличить MTU на сетевом оборудовании датацентра и спрятать туда весь транспортный overhead оверлейных сетей?
Мне, как конечному пользователю, привычнее видеть MTU = 1500 байт. Опять же чем меньше MTU тем больше overhead стека TCP/IP.
Разве не лучше увеличить MTU на сетевом оборудовании датацентра и спрятать туда весь транспортный overhead оверлейных сетей?
Sign up to leave a comment.
Админские байки: в погоне за фрагментацией туннелей в оверлейной сети