Переведено автоматически. Источник engineering.fb.com
By Santosh Janardhan
Теперь, когда наши платформы заработали и работают как обычно после вчерашнего сбоя, я подумал, что было бы полезно поделиться немного более подробной информацией о том, что произошло и почему — и, самое главное, как мы учимся на этом.
Это отключение было вызвано системой, которая управляет пропускной способностью нашей глобальной магистральной сети. Основой является сеть, созданная Facebook для объединения всех наших вычислительных мощностей, состоящая из десятков тысяч миль волоконно-оптических кабелей, пересекающих земной шар и соединяющих все наши центры обработки данных.
Эти центры обработки данных бывают разных форм. Некоторые из них представляют собой массивные здания, в которых размещены миллионы машин, хранящих данные и выполняющих большие вычислительные нагрузки, обеспечивающие работу наших платформ, а другие представляют собой небольшие объекты, которые соединяют нашу магистральную сеть с более широким Интернетом и людьми, использующими наши платформы.
Когда вы открываете одно из наших приложений и загружаете свою ленту или сообщения, запрос приложения на данные передается с вашего устройства в ближайшее учреждение, которое затем напрямую связывается по нашей магистральной сети с более крупным центром обработки данных. Именно здесь информация, необходимая вашему приложению, извлекается, обрабатывается и отправляется обратно по сети на ваш телефон.
Трафик данных между всеми этими вычислительными средствами управляется маршрутизаторами, которые определяют, куда отправлять все входящие и исходящие данные. И в ходе обширной повседневной работы по обслуживанию этой инфраструктуры нашим инженерам часто приходится отключать часть магистрали для технического обслуживания-возможно, ремонтировать оптоволоконную линию, увеличивать пропускную способность или обновлять программное обеспечение на самом маршрутизаторе.
Это было причиной вчерашнего отключения. Во время одного из этих плановых ремонтных работ была выдана команда с намерением оценить доступность глобальной магистральной сети, которая непреднамеренно отключила все соединения в нашей магистральной сети, эффективно отключив центры обработки данных Facebook по всему миру. Наши системы предназначены для аудита подобных команд, чтобы предотвратить подобные ошибки, но ошибка в этом инструменте аудита не позволила ему должным образом остановить команду.
Это изменение привело к полному отключению наших серверных соединений между нашими центрами обработки данных и Интернетом. И эта полная потеря связи вызвала вторую проблему, которая усугубила ситуацию.
Одна из задач, выполняемых нашими небольшими предприятиями, заключается в ответе на DNS-запросы. DNS-это адресная книга Интернета, позволяющая переводить простые веб-имена, которые мы вводим в браузерах, в определенные IP-адреса серверов. На эти запросы о переводе отвечают наши авторитетные серверы имен, которые сами занимают хорошо известные IP-адреса, которые, в свою очередь, передаются остальной части Интернета по другому протоколу, называемому протоколом пограничного шлюза (BGP).
Для обеспечения надежной работы наши DNS-серверы отключают эти рекламные объявления BGP, если они сами не могут связаться с нашими центрами обработки данных, поскольку это указывает на нездоровое сетевое подключение. Во время недавнего отключения вся магистраль была выведена из эксплуатации, в результате чего эти места объявили себя нездоровыми и отозвали рекламу BGP. Конечным результатом стало то, что наши DNS-серверы стали недоступны, хотя они все еще работали. Это сделало невозможным для остальной части Интернета поиск наших серверов.
Все это произошло очень быстро. И пока наши инженеры работали над тем, чтобы выяснить, что происходит и почему, они столкнулись с двумя большими препятствиями: во-первых, не было возможности получить доступ к нашим центрам обработки данных обычными средствами, потому что их сети были отключены, и, во-вторых, полная потеря DNS сломала многие внутренние инструменты, которые мы обычно использовали для расследования и устранения подобных сбоев.
Наш основной и внеполосный доступ к сети был отключен, поэтому мы послали инженеров в центры обработки данных, чтобы они отладили проблему и перезапустили системы. Но на это потребовалось время, поскольку эти объекты спроектированы с учетом высокого уровня физической и системной безопасности. В них трудно проникнуть, и как только вы окажетесь внутри, оборудование и маршрутизаторы будут спроектированы так, чтобы их было трудно модифицировать, даже если у вас есть физический доступ к ним. Поэтому потребовалось дополнительное время, чтобы активировать протоколы безопасного доступа, необходимые для того, чтобы люди могли находиться на месте и работать на серверах. Только тогда мы сможем подтвердить проблему и снова подключить наш костяк к сети.
Как только наше подключение к магистральной сети было восстановлено во всех регионах наших центров обработки данных, все вернулось на свои места. Но проблема не была решена — мы знали, что одновременное включение наших сервисов потенциально может привести к новому витку сбоев из-за резкого увеличения трафика. Отдельные центры обработки данных сообщали о снижении энергопотребления в диапазоне десятков мегаватт, и внезапное изменение такого снижения энергопотребления могло поставить под угрозу все, от электрических систем до тайников.
К счастью, это событие, к которому мы хорошо подготовлены благодаря “штормовым” тренировкам, которые мы проводим уже давно. В упражнении "Шторм" мы имитируем крупный сбой системы, отключая службу, центр обработки данных или весь регион в автономном режиме, проводя стресс-тестирование всей инфраструктуры и программного обеспечения. Опыт, полученный в ходе этих тренировок, дал нам уверенность и опыт, чтобы вернуть все в онлайн-режим и тщательно справляться с возрастающими нагрузками. В конце концов, наши службы восстановились относительно быстро без каких-либо дальнейших системных сбоев. И хотя мы никогда ранее не запускали шторм, который имитировал бы отключение нашей глобальной магистрали, мы, безусловно, будем искать способы моделирования подобных событий в будущем.
Каждая подобная неудача-это возможность учиться и становиться лучше, и нам есть чему поучиться на этом. После каждой проблемы, малой и большой, мы проводим тщательный анализ, чтобы понять, как мы можем сделать наши системы более устойчивыми. Этот процесс уже идет полным ходом.
Мы проделали обширную работу по укреплению наших систем для предотвращения несанкционированного доступа, и было интересно посмотреть, как это укрепление замедлило нас, когда мы пытались восстановиться после сбоя, вызванного не вредоносной деятельностью, а нашей собственной ошибкой. Я считаю, что такой компромисс стоит того — значительно повысить повседневную безопасность по сравнению с более медленным восстановлением после, надеюсь, редкого события, подобного этому. С этого момента наша задача состоит в том, чтобы усилить наши испытания, тренировки и общую устойчивость, чтобы подобные события происходили как можно реже.
By Santosh Janardhan
Теперь, когда наши платформы заработали и работают как обычно после вчерашнего сбоя, я подумал, что было бы полезно поделиться немного более подробной информацией о том, что произошло и почему — и, самое главное, как мы учимся на этом.
Это отключение было вызвано системой, которая управляет пропускной способностью нашей глобальной магистральной сети. Основой является сеть, созданная Facebook для объединения всех наших вычислительных мощностей, состоящая из десятков тысяч миль волоконно-оптических кабелей, пересекающих земной шар и соединяющих все наши центры обработки данных.
Эти центры обработки данных бывают разных форм. Некоторые из них представляют собой массивные здания, в которых размещены миллионы машин, хранящих данные и выполняющих большие вычислительные нагрузки, обеспечивающие работу наших платформ, а другие представляют собой небольшие объекты, которые соединяют нашу магистральную сеть с более широким Интернетом и людьми, использующими наши платформы.
Когда вы открываете одно из наших приложений и загружаете свою ленту или сообщения, запрос приложения на данные передается с вашего устройства в ближайшее учреждение, которое затем напрямую связывается по нашей магистральной сети с более крупным центром обработки данных. Именно здесь информация, необходимая вашему приложению, извлекается, обрабатывается и отправляется обратно по сети на ваш телефон.
Трафик данных между всеми этими вычислительными средствами управляется маршрутизаторами, которые определяют, куда отправлять все входящие и исходящие данные. И в ходе обширной повседневной работы по обслуживанию этой инфраструктуры нашим инженерам часто приходится отключать часть магистрали для технического обслуживания-возможно, ремонтировать оптоволоконную линию, увеличивать пропускную способность или обновлять программное обеспечение на самом маршрутизаторе.
Это было причиной вчерашнего отключения. Во время одного из этих плановых ремонтных работ была выдана команда с намерением оценить доступность глобальной магистральной сети, которая непреднамеренно отключила все соединения в нашей магистральной сети, эффективно отключив центры обработки данных Facebook по всему миру. Наши системы предназначены для аудита подобных команд, чтобы предотвратить подобные ошибки, но ошибка в этом инструменте аудита не позволила ему должным образом остановить команду.
Это изменение привело к полному отключению наших серверных соединений между нашими центрами обработки данных и Интернетом. И эта полная потеря связи вызвала вторую проблему, которая усугубила ситуацию.
Одна из задач, выполняемых нашими небольшими предприятиями, заключается в ответе на DNS-запросы. DNS-это адресная книга Интернета, позволяющая переводить простые веб-имена, которые мы вводим в браузерах, в определенные IP-адреса серверов. На эти запросы о переводе отвечают наши авторитетные серверы имен, которые сами занимают хорошо известные IP-адреса, которые, в свою очередь, передаются остальной части Интернета по другому протоколу, называемому протоколом пограничного шлюза (BGP).
Для обеспечения надежной работы наши DNS-серверы отключают эти рекламные объявления BGP, если они сами не могут связаться с нашими центрами обработки данных, поскольку это указывает на нездоровое сетевое подключение. Во время недавнего отключения вся магистраль была выведена из эксплуатации, в результате чего эти места объявили себя нездоровыми и отозвали рекламу BGP. Конечным результатом стало то, что наши DNS-серверы стали недоступны, хотя они все еще работали. Это сделало невозможным для остальной части Интернета поиск наших серверов.
Все это произошло очень быстро. И пока наши инженеры работали над тем, чтобы выяснить, что происходит и почему, они столкнулись с двумя большими препятствиями: во-первых, не было возможности получить доступ к нашим центрам обработки данных обычными средствами, потому что их сети были отключены, и, во-вторых, полная потеря DNS сломала многие внутренние инструменты, которые мы обычно использовали для расследования и устранения подобных сбоев.
Наш основной и внеполосный доступ к сети был отключен, поэтому мы послали инженеров в центры обработки данных, чтобы они отладили проблему и перезапустили системы. Но на это потребовалось время, поскольку эти объекты спроектированы с учетом высокого уровня физической и системной безопасности. В них трудно проникнуть, и как только вы окажетесь внутри, оборудование и маршрутизаторы будут спроектированы так, чтобы их было трудно модифицировать, даже если у вас есть физический доступ к ним. Поэтому потребовалось дополнительное время, чтобы активировать протоколы безопасного доступа, необходимые для того, чтобы люди могли находиться на месте и работать на серверах. Только тогда мы сможем подтвердить проблему и снова подключить наш костяк к сети.
Как только наше подключение к магистральной сети было восстановлено во всех регионах наших центров обработки данных, все вернулось на свои места. Но проблема не была решена — мы знали, что одновременное включение наших сервисов потенциально может привести к новому витку сбоев из-за резкого увеличения трафика. Отдельные центры обработки данных сообщали о снижении энергопотребления в диапазоне десятков мегаватт, и внезапное изменение такого снижения энергопотребления могло поставить под угрозу все, от электрических систем до тайников.
К счастью, это событие, к которому мы хорошо подготовлены благодаря “штормовым” тренировкам, которые мы проводим уже давно. В упражнении "Шторм" мы имитируем крупный сбой системы, отключая службу, центр обработки данных или весь регион в автономном режиме, проводя стресс-тестирование всей инфраструктуры и программного обеспечения. Опыт, полученный в ходе этих тренировок, дал нам уверенность и опыт, чтобы вернуть все в онлайн-режим и тщательно справляться с возрастающими нагрузками. В конце концов, наши службы восстановились относительно быстро без каких-либо дальнейших системных сбоев. И хотя мы никогда ранее не запускали шторм, который имитировал бы отключение нашей глобальной магистрали, мы, безусловно, будем искать способы моделирования подобных событий в будущем.
Каждая подобная неудача-это возможность учиться и становиться лучше, и нам есть чему поучиться на этом. После каждой проблемы, малой и большой, мы проводим тщательный анализ, чтобы понять, как мы можем сделать наши системы более устойчивыми. Этот процесс уже идет полным ходом.
Мы проделали обширную работу по укреплению наших систем для предотвращения несанкционированного доступа, и было интересно посмотреть, как это укрепление замедлило нас, когда мы пытались восстановиться после сбоя, вызванного не вредоносной деятельностью, а нашей собственной ошибкой. Я считаю, что такой компромисс стоит того — значительно повысить повседневную безопасность по сравнению с более медленным восстановлением после, надеюсь, редкого события, подобного этому. С этого момента наша задача состоит в том, чтобы усилить наши испытания, тренировки и общую устойчивость, чтобы подобные события происходили как можно реже.
Последнее редактирование:
