Как Google справляется с перебоями в работе

Раздел: Компьютерная жизнь @ 10.04.2009 | Ключевые слова: google как работает

Автор: mchost
Источник: habrahabr

Перевод интервью Урса Хельцле (Urs Hoelzle), опубликованного на ресурсе Data Center Knowledge. Урс Хельцле – вице-президент Google по операциям и почетный сотрудник (Google Fellow). В его текущие обязанности входит проектирование и отслеживание работы серверов, сетей и центров обработки данных в Google (цитата с сайта компании).

По мнению Урса, вносить изменения в поисковую инфраструктуру Google примерно так же легко, как и менять колеса в автомобиле на скорости под сотню километров в час. Компания планомерно обновляет софт и аппаратные системы, и обычно это происходит без инцидентов. Но не всегда. К примеру, 24 февраля ошибка в программном обеспечении, контролирующем расположение данных Google, вызывала перебой в работе Gmail, широко известного сервиса веб-почты, входящего набор веб-приложений Google Apps.

Несколькими днями ранее серверы Google все же остались в строю во время перебоя в электроснабжении дата-центра, принадлежащего сторонней компании. Он расположен под Атлантой и Google размещает там некоторую часть из своего гигантского серверного парка.

Обычно комания не обсуждает работу конкретных дата-центров. Но Хельцле, будучи старшим вице-президентом компании по операциям и почетным сотрудником Google, согласился пролить свет на систему, используемую в Google для борьбы с аппаратными отказами и программными сбоями в режиме вопрос-ответ.

Data Center Knowledge (DCK). У Google много дата-центров и распределенных операций. Как система опознает проблемы в конкретном дата-центре или сегменте сети?

Урс Хельцле (УХ). У нас есть несколько типовых решених для команд по отслеживанию отказов. Один из типичных способов – перекрестный мониторинг различными средствами. Работая по методу черного ящика, можно понять, доступен ли конкретный сервер, а структурный мониторинг помогает отследить мелкие проблемы (простой 2-4% времени в течение нескольких часов). Конечно, мы не забываем учиться на собственных ошибках, и после любого отказа запускаем полную «посметрную» проверку, чтобы понять, могла ли зарегистрировать сбой существующая система мониторинга, и, если нет, что можно сделать для того, чтобы засечь его в следующий раз.

DCK. Есть ли в компании центр управления сетью (NOC), отслеживающий все происходящие события и координирующий реакцию на них?

УХ. Нет, мы используем распределенную модель управления, когда несколько команд инженеров работают в разных временных зонах. Наши инфраструктурные команды выступают в роли координаторов проблем в случае сбоев, но тут есть некоторое отличие от обычных NOC. Точка контакта зависит от типа проблемы. Инженеры, занятые решением проблемы по своему усмотрению привлекают нужные дополнительные ресурсы. У нас также есть немало автоматических систем мониторинга, созданных разработчиками под их собственные продукты. Они напрямую сообщают дежурному инженеру о зарегистрированных аномалиях.

DCK. Насколько автоматизированы процедуры «обходной» маршрутизации, и каковы границы возможной автоматизации?

УХ. Есть несколько сценариев для различных проблем, где понадобится «обходная» маршрутизация. Если откажет сервер Google File System, эта проблема будет решена клиентом GFS автоматически. А вот с потерей питания в дата-центре, возможно, придется повозиться вручную. В общем и целом, мы стараемся применять масштабируемые решения и встраиваеть возможности «обходной» маршрутизации в наши программные продукты для того, чтобы все известные проблемы разрешались просто и ясно. Когда же проблема требует сложного взаимодействия, пошаговых процедур или постоянной обратной связи, мы предпочитаем, чтобы процессом управлял человек.

DCK. Насколько проблемы с питанием целого дата-центра отличаются от более локальных сбоев? Как справляется с этим архитектура Google?

УХ. Внутренняя инфраструктура дата-центра Google (GFS, планирование загрузки серверов) в общем и целом спроектирована так, чтобы легко разбираться с отказами отдельных серверов с групповыми отказами серверов/стоек. К примеру, GFS хранит дублированные данные на серверах в разных стойках, так что потеря стойки может привести к снижению производительности, но не к потере данных.

Отказы уровня дата-центра или региональные отключения электропитания довольно редки и поэтому мы разбираемся с ними вручную. Для новых классов проблем, когда они возникают, мы подбираем новые инструменты. Кроме того, команды инженеров регулярно отрабатывают сценарии перенаправления трафика в обход того или иного дата-центра в качестве тренировки.

DCK. Вопрос в стиле «законов Мёрфи». С учетом того, что Google предприняла все меры для того, чтобы избежать простоя своих сервисов, что же все-таки их вызвало?

УХ. В большинстве простоев сервисов Google свою роль сыграл наш темп роста и проблемы с конфигурацией (судя по всему, постоянно растущего серверного парка, прим. перев.). Мы постоянно строим новые и перестраиваем старые системы, поэтому какое-нибудь банальное решение по конфигурации, принятое полгода или год назад, в сочетании с двумя-тремя новыми функциями, может внезапно сильно нагрузить надежно работавший ранее компонент системы.

Рост, конечно, тоже является серьезным моментом. Кто-то однажды сравнил процесс апгрейда нашей поисковой инфраструктуры со сменой колес на машине, движущейся со скоростью под сотню км/ч по шоссе. Очень редко системы, создаваемые для того, чтобы бороться с простоями, сами вызывают проблемы. К счастью, это произошло лишь однажды, когда в феврале на некоторое время оказалась недоступна почта Gmail (здесь можно ознакомиться с результатами проверки на английском: www.google.com/appsstatus/ir/1nsexcr2jnrj1d6.pdf).

DCK. Как в конечном итоге Google реагирует на проблемы с доступом к сервисам и интегрирует вынесенные уроки в свою деятельность?

УХ. В общем и целом, после простоя команда анализирует результаты проверки и выдает сценарии реакции в будущем, вроде «необходимо мониторить время реакции Х», или «задокументировать процедуру восстановления после отказа и ознакомить с ней инженеров». Инженеры из команд, затронутых происшествием, и сами при этом рады попросить поддержки и получить подобный документ.

Человеку свойственно ошибаться, так что, когда только это возможно, мы стараемся составить подробные инструции или выработать правило для автоматизированного мониторинга. Это относится как к проблемам с конфигурацией/софтом, так и к проблемам аппаратного обеспечения и дата-центров.

Вернуться в раздел: Компьютерная жизнь