Кратко

  • В раннем Firehose 1.0 отказ двух определённых восходящих соединений мог лишить две группы машин связи между собой, хотя связь с другими машинами сохранялась. Этот проект не передавал рабочий трафик.
  • Независимые блоки позднее уменьшили масштаб отдельных работ, но физическое разделение не устранило общие риски управляющего ПО и конфигурационных процедур.
  • Документированная ответственность Urs Hölzle за инфраструктуру и его соавторство позволяют связать его с коллективной инженерной работой, не приписывая ему каждое техническое решение.

Фраза «машина доступна» не всегда описывает то, что требуется приложению. Одна группа машин может общаться с другими, вторая тоже, но между этими двумя группами связь отсутствует. Это не аккуратно отрезанный остров, границу которого легко учесть в работе распределённой системы.

В оригинальной статье SIGCOMM 2015 года команда Google разбирает такой случай для Firehose 1.0. Если на двух коммутаторах верхнего уровня стойки в одном окне ремонта отказывали восходящие линии с противоположных сторон, подключённые машины могли сохранять связь с другими машинами, но не друг с другом. Авторы отмечают, что приложениям было трудно работать с такой нетранзитивной связностью.

Это описание нельзя выдавать за нынешний сбой Google. Firehose 1.0, согласно статье, вообще не нёс рабочего трафика. Перед нами урок раннего проектирования и реализации, который объясняет последующие изменения, а не сообщение об аварии действующего сервиса.

Где в этой истории Hölzle

Urs Hölzle — один из многих соавторов ретроспективы. Биография Google Research называет его Google Fellow в Google Cloud и указывает, что до 2023 года он был Senior Vice President for Technical Infrastructure. В этой должности он отвечал за надзор над проектированием, установкой и эксплуатацией серверов, сетей и центров обработки данных для сервисов Google.

Такой круг обязанностей связывает схему сети со строительством и повседневной эксплуатацией. Нужно не только проложить пути, но и разместить работу, смонтировать оборудование, затем менять его без потери управляемости. Поэтому роль Hölzle важна для этой истории. Однако ни должность, ни общая подпись не показывают, кто придумал каждый механизм. Рассказ об одном изобретателе скрыл бы обучение команды на стыке оборудования, программ и полевых работ.

Публикация Google в мае 2013 года и текст Hölzle о сети в марте 2020 года фиксируют эту инфраструктурную роль в конкретные даты. Второй текст отдельно рассматривает сеть Google и последнюю милю провайдеров доступа. Нельзя распространять одну операционную ответственность на все зависимости пользовательского соединения.

Защита от локальной аварии расширяет обмен

Техническая статья объясняет связь между устойчивостью приложений и требованиями к сети. Распределение задач и хранения между разными областями питания и отказа уменьшает концентрацию риска при локальной проблеме. Но одновременно ресурсы оказываются дальше друг от друга, и обмен уже нельзя удержать внутри небольших групп машин.

Многоступенчатая топология Clos создаёт многочисленные пути из большого числа коммутирующих элементов. Она позволяет строить крупную сеть не только вокруг одного огромного шасси. Однако количество линий на схеме не доказывает, что при нужной комбинации отказов сохранится именно та связь, на которую рассчитывает приложение. Firehose 1.0 дал конкретный пример этого различия.

В Firehose 1.1 изменились и физическая компоновка, и соединения. Вместо обычных серверов для размещения коммутирующих чипов использовали специальные корпуса, отдельную внеполосную сеть управления, пары стоечных коммутаторов и переработанную структуру агрегации. Авторы сообщают о большей устойчивости к отказам линий. При этом прокладка кабелей и размещение компонентов оставались трудоёмкими. Реальная архитектура должна выдерживать монтаж, повторное подключение и замену деталей.

Что означает вывести четверть

Позднейшая архитектура Freedom делает единицу обслуживания явной. Типовой уровень связности состоял из четырёх независимых блоков. Один блок можно было освободить от трафика и обновить, потеряв 25% суммарной пропускной способности. Работы больше не обязательно требовали вывода всего уровня.

Это свойство конкретной схемы, а не обещание неизменной производительности каждого приложения. Нагрузка должна помещаться в оставшиеся ресурсы; суммарная ёмкость сама по себе не описывает нагрузку на отдельные пути.

Другая иллюстрация той же статьи делит шасси сети Clos на четыре группы для поэтапного обновления. Отключение одной оставляет 56,25% ёмкости: потери взаимодействуют между ступенями. Восемь групп делают процедуру мягче, но длиннее. Это не пример четырёх независимых блоков Freedom, и их расчёты нельзя подменять друг другом.

Следовательно, масштаб вмешательства определяется не числом вынутых устройств, а связностью, которая остаётся, и распределением работы по ней. В этой точке план обслуживания становится частью архитектуры.

Общие зависимости отдельных частей

Для Firehose, Watchtower и Saturn авторы описывают Firepath. Он распространяет общую картину топологии и состояния линий, а коммутаторы рассчитывают таблицы пересылки локально. Логическая централизация относится к согласованию состояния, не к выбору пути каждого пакета в одном центре. Этому служили резервные управляющие экземпляры и отдельная сеть. Подробная архитектура управления Jupiter прямо оставлена за рамками работы.

До Jupiter ограниченный набор параметров кластера также порождал списки материалов, планы стоек и кабелей, данные управляющей сети, сведения для наблюдения и общие конфигурации коммутаторов. Сужение выбора упрощало повторяемое строительство. Вместе с тем правильность общей спецификации приобретала значение сразу для множества устройств.

Эксплуатационные случаи показывают, как это разделение может не сработать. При одновременном перезапуске всей сети проверки активности и расчёт маршрутов конкурировали за ограниченный процессор коммутатора. Старение внутренних и управляющих соединений выявило состояния, которые недостаточно наблюдались. Во время изменения BGP в Freedom одновременное чтение конфигурации без блокировки взаимодействовало с записью и породило неполную конфигурацию. Команда описывает откат и усиление инструментов.

Эти фрагменты объясняют исторические механизмы. Они не дают общей частоты аварий, их длительности или оценки ущерба клиентам. Но они показывают, почему независимые корпуса ещё не означают независимость обнаружения, программных переходов и операций настройки.

Не размер сети, а возможность вмешаться

Конференционная публикация 2015 года и версия CACM 2016 года относятся к одной работе. Это не две независимые проверки. Подробная ретроспектива оператора помогает понять обучение, но не подтверждает нынешнюю реализацию всех его центров обработки данных.

Значение Hölzle здесь — документированная связь между руководством инфраструктурой и коллективным созданием сети, допускающей ограниченные изменения. Устойчивый вопрос возникает при следующем выводе блока: что действительно останется независимым, а что продолжит зависеть от одного общего изменения или отказа?

Источники