случай потенциальной катастрофы на выставке

[Joseph W. Doherty]

Примечание: это не актуальная проблема, хотя она действительно существовала. Ее причины и способы устранения могут встречаться и сегодня. Я привожу этот пример для практического обучения посредством обсуждения. Несколько десятилетий назад, работая в довольно крупной международной компании-разработчике программного обеспечения, меня спросили, есть ли у меня какие-либо идеи или предложения по поводу «серьезной сетевой проблемы», с которой они только что столкнулись. Проблема заключалась в том, что через полтора дня должна была открыться крупная выставка, а их флагманский продукт работал ужасно медленно. Немного предыстории: Эта компания участвовала в нескольких выставках по всему миру, как правило, ежегодно, в разных регионах мира. Для сравнения, это было похоже на Cisco с ее выставками
Cisco Live
. Каждый крупный регион отвечал за «проведение» выставки в своем регионе, и за кулисами велась большая подготовительная работа, как внутри компании, за несколько месяцев до открытия выставки, так и на месте проведения выставки, за одну-две недели до ее открытия. В региональном штабе в Америке, на восточном побережье США, локальная сетевая среда (на тот момент) имела скорость 100 Мбит/с для хостов конечных пользователей и гигабитную скорость везде ailleurs. В штабе флагманское приложение работало нормально, получая доступ к своим серверам поддержки в том же месте. На месте проведения выставки, в Лас-Вегасе, США, который находился примерно в 2000 милях от штаб-квартиры, считалось, что две арендованные линии T3 (по 45 Мбит/с каждая) обеспечат достаточную пропускную способность для связи со штаб-квартирой. (Я не помню, был ли выбор T3 лучшим на тот момент из того, что мог предоставить выставочный центр, или он был обусловлен бюджетными соображениями). Примерно через неделю после настройки нашей сетевой среды в конференц-центре и за два дня до открытия выставки было замечено, что флагманский продукт работал правильно, подключаясь к серверным ресурсам в штаб-квартире, но работал очень, очень медленно! Первый вопрос: почему приложение работало так медленно? Следует отметить, что никаких видимых физических проблем с сетевыми соединениями не было, и на момент тестирования только это приложение использовало пропускную способность, которая была едва измеримой, поскольку приложение было, более или менее, транзакционным. (Я предполагаю, что большинство легко определит основную проблему, но, пожалуйста, назовите ее явно). Следующий вопрос: что можно сделать для решения этой проблемы, если на ее решение осталось менее двух дней? (Это действительно очень важный вопрос, время уходит! В качестве дополнительного бонуса, что можно сделать, особенно в наши дни, в качестве альтернативы, чтобы изначально исключить эту проблему?)

[Ramblin Tech]

Если бы приложение HQ работало на сервере типа ПК, то было бы относительно «просто» (ха!) установить новый сервер на месте для демонстрации... просто по сравнению с приложением на базе мини- или мэйнфрейм-сервера, что было бы логистически невозможно. Переход с спутниковых на наземные линии связи (если T3 был спутниковым) или установка новой линии связи в более близком центре обработки данных также были бы логистически невозможны, поскольку установка новой линии связи заняла бы несколько недель. Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя вина, так как они не генерируются ИИ.

[Joseph W. Doherty]

Возможно, еще слишком рано давать дополнительные подсказки, но я немного удивлен, что никто не ответил на первый вопрос, то есть не указал первопричину. Однако на второй вопрос, похоже, невозможно дать ответ, особенно за полтора дня. Что ж, в данном случае правильное понимание первопричины привело меня к очень важному вопросу, который привел к решению. Я скажу, что решение, возможно, требует проverbial «нестандартного мышления», и когда оно будет раскрыто, вероятно, вызовет реакцию «ну да, конечно». Не стесняйтесь задавать дополнительные вопросы, так как один из них был ключом к решению этого случая.

[Ramblin Tech]

Привет, Джо: за эти годы я видел несколько приложений, которые работают нормально, когда клиентские и серверные компоненты находятся в одном месте, но работают очень плохо (если вообще работают), когда они разделены физическим расстоянием из-за задержек в распространении сигнала. Это было особенно верно, когда сеансовый уровень был построен на парадигме
«остановись и подожди
». Я помню, как в середине 90-х годов я потратил немало времени, объясняя некоторым системным администраторам и администраторам баз данных, что транспортная сеть не была повреждена и что основной причиной была архитектура их приложения, которая выполняла миллионы транзакций базы данных по одной записи за раз, ожидая времени прохождения сигнала между каждой транзакцией с клиентскими и серверными компонентами, разделенными расстоянием более 2 тысяч миль (Джорджия и Вашингтон). Решением в этом случае стала новая версия программного обеспечения базы данных, которая более эффективно обрабатывала задержки распространения. Более современным решением для высокой задержки (это конкретное приложение базы данных работало через DECnet) может быть TCP-спуфинг с оптимизаторами WAN для локального завершения сеансов TCP с целью улучшения производительности окон... или, возможно, полный отказ от TCP в пользу
QUIC
. Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя вина, так как они не генерируются ИИ.

[Joseph W. Doherty]

Джим, вы совершенно верно определили основную причину, а именно: это было связано с задержкой, обусловленной расстоянием, и большим количеством обращений приложения. Существует большая разница между «обменом данными» между двумя хостами, расположенными в одном здании, и двумя хостами, расположенными на расстоянии двух тысяч миль друг от друга. Вы также правы в том, что с тех пор возможной альтернативой могло бы быть использование какого-либо оптимизатора WAN. Однако это может быть очень рискованным. Что касается преимуществ QUIC, то да и нет. Преимущества одновременных потоков могут быть значительными в LFN, особенно при решении классических проблем LFN TCP, но в идеале вам нужно приложение, которое избегает многократных обратных запросов, и ваш пример с базой данных является «ярким примером». Причина проблемы была выявлена, но как она была решена, особенно за полтора дня?

[Joseph W. Doherty]

@Ramblin Tech
написал:
Если бы приложение HQ работало на сервере типа ПК, то было бы относительно «легко» (ха!) установить новый сервер на месте для демонстрации... Именно! Я спросил, может ли сервер приложения быть сервером типа ПК, и ответ был положительным. Таким образом, сервер был отправлен ночной доставкой, и они смогли подключить его к сети к открытию выставки. С точки зрения «сетевого» решения, возможно, это было «нестандартное» решение. Однако вопрос о том, что является поддерживающим сервером, позволил найти «очевидное» решение. Что касается того, почему вообще была задействована «сеть», то это потому, что они более или менее гарантировали, что все будет работать так же хорошо в 2000 милях от них, на паре T3, как и в головном офисе в том же здании. Конечно, никто не потрудился попробовать это, что было бы несколько тривиально, поскольку у этой компании было несколько офисов даже в пределах США. (Кроме того, примерно через год они направили ко мне одного VIP-клиента, чтобы я ответил на вопрос, почему их приложения работают все медленнее и медленнее по мере удаления от серверов. У него были очень впечатляющие графики производительности, которые показывали задержку, связанную с сетью. По какой-то «странной» причине самая большая сетевая задержка была между хостами, которые находились буквально на противоположных концах света. Одна аналогия, которая, казалось, хорошо работала, заключалась в объяснении того, что все сети имеют фиксированное «ограничение скорости», поэтому чем дальше вам нужно путешествовать, тем дольше это занимает. Пропускная способность обеспечивает более крупные транспортные средства, которые перевозят больше груза. То есть они не прибывают быстрее, но больше материала транспортируется за меньшее время. Кроме того, как и в системе автомагистралей, между двумя конечными точками, скорее всего, нет прямой дороги, поэтому часто требуется еще более длительное путешествие по дороге. Пользователи, как правило, всегда приравнивают пропускную способность сети к «скорости», часто упуская из виду потенциальное влияние задержки. К моему удивлению, я встречал многих сетевых инженеров, которые часто упускают из виду влияние задержки, пока она не становится серьезной проблемой. Возможно, в то время мог бы сработать другой подход, который заключался бы в использовании программного обеспечения удаленного рабочего стола на выставке, доступе к клиенту в головном офисе и работе с сервером, также находящимся в головном офисе. Вероятно, это все равно было бы несколько медленнее по сравнению с клиентом и сервером, находящимися рядом друг с другом, и вызвало бы вопрос, зачем вы используете приложение удаленного рабочего стола. (Кстати, я достаточно стар, в начале своей карьеры я участвовал в международных телефонных разговорах с использованием высокоорбитальных «стационарных» спутников связи, и задержка была очень заметной).