Как стать автором
Обновить

Комментарии 22

На основании Вашего понимания MPLS и маршрутизации Вы сделали не верный вывод. Но в том что физические сервера по-факту дешевле и быстрее Xen вируталок на Амазоне ничего удивительного нет.
А в чем еще может быть причина, на Ваш взгляд? У меня была идея еще в DNS, но я пробовал и по прямому IP-адресу машины с Amazon RDS. Результат был тот же.
Как вариант — стратегия кеширования дисковых и сетевых I/O Xen гипервизором.
У нас были такие мысли — что такой эффект может дать облачный слой, то есть то ПО виртуализации, которое, собственно, облако реализует и поддерживает. Но тогда скорее всего какая-то похожая проблема должна была носить массовый характер для всех клиентов Амазона с одиночными запросами к СУБД. Но я ничего такого на просторах Интернета не нашел. Поэтому и пошел другим путем.
Вообще говоря гугл находит подобные жалобы, и mailing лист xen. Я вкладу закрыл до рефреша коментариев. В любом случае, вируализация это не use case для СУБД. Так что все верно сделали, что смигрировали DB на физ сервер.
а вы обычный пинг пробовали? первый тоже дольше едет?
К сожалению, на амазон RDS ping был закрыт. :( Самого этот вопрос интересовал.
попробуйте «tcp ping»
Да мы уже прибили давно Amazon. Сейчас уже проверить ничего нельзя. :(
Так причем тут MPLS?
Хм. Попробую еще раз покороче. :) На мой взгляд, при первом запросе сервера Amazon работает протокол выстраивания туннеля MPLS, который и вносит задержку. После того, как этот туннель установлен — остальные данные передаются быстро.

Однако, поскольку в моем конкретном случае все запросы в СУБД идут одиночные, получается, что туннель выстраивается под каждый мой запрос к СУБД, что и приводит к фатальной задержке в работе моего приложения.
Спешу вас расстроить это точно не mpls.
Мой вопрос был иронией.
Ваше предпложение неверно, так как в mpls есть LDP, который занимается распространиением меток для построения LSP. Тунель не устанавливается каждый раз, когда отправляется пакет по маршруту в MPLS.
В случае статических маршрутов — да. А для динамики скорее всего OSPF да RSVP работают. Но повторюсь — это только версия. Выше пишут, что проблема была описана в mail-листах тематических, но я или не нашел, или не сопоставил со своей проблемой.
Вам там уже написали много всего в коментариях касательно MPLS, я добавлю небольшую ремарку касательно туннелей. В MPLS для распространения меток (то, что вы назвали строительством туннелей) используются 2 протокола: LDP и RSVP-TE.
LDP строит сразу full-mesh сеть туннелей, после того как поднялись LDP сессии между коробками.
В RSVP-TE туннели простраиваются в виде LSP, и не автоматически, а указывается конкретно откуда куда построить. Как только туннель построился он уже падает только в случае аварии.

Если вы хотите грешить на сеть, но я в первую очередь подозревал бы ARP кеш на граничных устройствах.
Да, кстати. И это может быть запросто. Спасибо.
MPLS бывает L2VPN и L3VPN. последний также основывается на разных протоколах маршрутизации BGP, MBGP, OSPF.
У всех конфигураций различный алгоритм построения туннеля. Где-то он строится при конфигурировании и может измениться только при изменении топологии сети, какие-то делают туннель на маршрут (/24 или /32), какие-то делают метку уже на next-hop, который анонсирует список префиксов.

Просто так утверждать, что дело в MPLS сложно…
Здесь вообще сложно определиться с какой-то конкретной причиной. Поэтому это только одна из версий.
Т.е. вы, не разобравшись абсолютно в сути протокола MPLS делаете какие-то очень странные выводы?
Кстати по пути до амазона найдется еще одна-две транспортных операторских mpls-сети.
В общем — бред какой-то (с)
А кто сказал, что я с ней не разбирался? :) Разбирался в свое время несколько лет и довольно детально. Но дело не в этом. Проблема либо в сети, либо в ПО Амазона. Если честно — во второе не верится, а для первого у меня другого объяснения нет.
Ну значит хреново вы разбирались, и вам выше уже рассказали, почему.
Баг в ПО Амазона — да запоросто, почему нет? Падает он довольно регулярно
AWS используют XEN и скорее всего OVS, рекомендую ознакомиться с концепцией openflow, задержка первого пакета более вероятна из-за задержки создания flow.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации