Произвольный тайм-аут таблицы/большого двоичного объекта/очереди Azure в системе Linux (приложение k8s .net core 3)

Это мой сценарий:

Microsoft.Azure.Storage.Blob 11.2.0
Microsoft.Azure.Storage.Queue 11.2.0
Micorosoft.Azure.Cosmos.Table 1.0.7

Я без проблем перенес большую часть своего кода из функции Azure в Google k8s и Google Cloud, запустив приложение Core .Net, в основном с той же библиотекой, встроенной в .net Standard 2.0.

Через несколько дней я заметил другое поведение в системе Linux. Несколько вызовов, взаимодействующих со службой Azure (большие двоичные объекты, таблица, очередь), получают тайм-ауты (похоже, подсистема дает сбой, я пробовал разные политики повторных попыток с тем же результатом). На 10 000 вызовов я получаю от 10 до 50 ошибок (или очень длинные вызовы 180 секунд, до того, как я изменил таймауты). Это происходит во всех службах Azure: таблице, большом двоичном объекте и очереди.

Я пробовал разные решения, чтобы выяснить, почему:

  • Я создаю экземпляр клиента (blobClient, TableClient..etc) при каждом вызове или повторно использую один и тот же клиент, но без разницы
  • Я меняю все тайм-ауты, чтобы справиться с этим поведением. Я работаю над ServerTimeout и MaximumExecutionTime и добавляю слой поверх своего механизма повторных попыток, чтобы свести к минимуму ошибки. Сейчас у меня всего несколько звонков по 20 секунд (вместо 2/3 сек например).
  • Я пробовал все решения с похожими проблемами, найденные на Stackoverflow: D ... но ничего не работает (пока)

Тот же код dll запускается на лазурной функции без каких-либо проблем.

Итак, я пришел к выводу, что в http-клиенте есть что-то, используемое внутри azure sdk, что зависит от операционной системы, в которой вы запускаете свой код. Я думаю, что после нескольких статей это может быть заголовок Keep-Alive, поэтому я примеряю корень своей композиции:

ServicePointManager.SetTcpKeepAlive (true, 120000, 10000);

но ничего не меняется.

Любые идеи или предложения? ... может быть, я на неправильном пути, или я что-то пропустил.


person Gian C.    schedule 25.08.2020    source источник
comment
Поскольку вы перешли в облако Google, проверяли ли вы задержку в сети между регионом GCP, где развернуто ваше приложение, и регионом Azure, где находится ваша учетная запись хранения?   -  person krishg    schedule 26.08.2020
comment
@KrishnenduGhosh-MSFT Спасибо, посмотрю. Может ли задержка между регионами быть настолько важной? Некоторые мои звонки блокируются на несколько минут   -  person Gian C.    schedule 26.08.2020
comment
Это очень важно :)   -  person krishg    schedule 26.08.2020
comment
Удалось ли вам узнать какие-либо сведения о задержке/проблеме в сети?   -  person krishg    schedule 28.08.2020
comment
Я серьезно отношусь к вашему предложению, пытаюсь разобраться (сейчас например читаю эту статью cloud.google.com/solutions/). Но, тем не менее, в моей голове есть тихий голос, который шепчет, как задержка может быть такой разрушительной проблемой? В худшем случае может быть некоторая задержка при звонках... но повесить звонок? Я думаю, многие пользуются сервисами Azure от k8s. Мне кажется странным, что я не могу найти больше проблем, похожих на мою. Может быть, я смотрю в неправильном направлении. Спасибо за помощь :)   -  person Gian C.    schedule 28.08.2020
comment
Кстати, моя сеть Google — europe-west1/europe-west4, и я использую несколько областей в Azure (с резервными копиями в разных регионах Западной Европы, Северной Европы и Центральной Франции).   -  person Gian C.    schedule 28.08.2020
comment
Хорошо, регион мудрый, оба находятся в непосредственной близости. Не могли бы вы поделиться фрагментом кода доступа к хранилищу, чтобы я мог его посмотреть? Также взгляните на эти docs.microsoft.com/ en-us/azure/storage/blobs/ и docs.microsoft.com/en-us/azure/storage/tables/   -  person krishg    schedule 28.08.2020
comment
У нас точно такая же настройка и проблема (вычисления перенесены в Google Cloud, но хранилище осталось в Azure), причем иногда вызовы хранилища занимают очень много времени или завершаются сбоем ровно через 180 секунд. Наша задержка от Google до центра обработки данных Azure измеряется одноразрядными миллисекундами. База данных SQL Azure работает нормально, только с хранилищем Azure возникают проблемы, и по какой-то причине вызовы терпят неудачу через ровно 180 секунд.   -  person Flagbug    schedule 02.10.2020
comment
С риском того, что я тоже прокомментирую, мы видим то же самое в .NET 5 WebAPI, который мы развертываем в экземпляре Linux WebApp в Azure. По какой-то причине любой вызов Table Storage либо напрямую через нашу собственную оболочку репозитория, либо через использование клиента Orleans (то есть с использованием Table Storage для конфигурации кластера) истекает по тайм-ауту или просто просто даже не возвращаясь со звонков   -  person Brendan Green    schedule 23.07.2021


Ответы (1)


ОБНОВЛЕНИЕ

После прочтения последней статьи, на которую ссылается @KrishnenduGhosh-MSFT в последнем комментарии, я попытался изменить этот параметр:

ServicePointManager.DefaultConnectionLimit = 100;

Это был поворотный момент.

Поскольку раньше это происходило случайным образом, я до сих пор не уверен на 100%, решена ли проблема. Но после 50 тысяч звонков я довольно оптимистичен. Очевидно, что в продакшене будет другое поведение, но я его уже ожидаю :)

ОБНОВЛЕНИЕ 2 – ПОСЛЕ ПУБЛИКАЦИИ В PROD

В итоге не работает :( Писал в комментах, но кажется справедливым обновить здесь (более читабельно). У меня еще длинные вызовы (сокращенно с MaximumExecutionTime), но я не вижу света в конец туннеля Теперь я думаю о переносе части хранилища Azure в хранилище Google, но полностью не сдался.

person Gian C.    schedule 31.08.2020
comment
Это действительно решило вашу проблему в производстве? У нас точно такая же настройка и проблема (вычисления перенесены в Google Cloud, но хранилище осталось в Azure), причем иногда вызовы хранилища занимают очень много времени или завершаются сбоем ровно через 180 секунд. Насколько я знаю, свойство ServicePointManager.DefaultConnectionLimit на самом деле ничего не делает в .NET Core и является нулевым, поэтому мне очень любопытно, почему это решило проблему для вас. - person Flagbug; 02.10.2020
comment
Нет, к сожалению, я все еще работаю над этим. Учитывая отсутствие интереса, я подумал, что это только моя проблема из-за какой-то странной конфигурации в моих файлах, поэтому я перестал обновлять информацию. Как только у меня будут новости, я сообщу вам. - person Gian C.; 06.10.2020