Как и для чего Яндекс отключает собственные дата-центры
- вторник, 18 ноября 2014 г. в 02:11:25
habrahabr
http://habrahabr.ru/company/yandex/blog/243033/
Раз в неделю Яндекс отключает один из своих дата-центров. Мы называем это учениями. Что это такое? Как возникло? Зачем мы это делаем? А не диверсия ли это? Насколько это опасно? На эти вопросы мне регулярно приходится отвечать как внутри так и снаружи компании. Сегодня я решила прояснить все эти вопросы разом.
Сейчас у нас несколько собственных дата-центров, в которых располагается несколько десятков тысяч серверов и сетевое оборудование. Учения — это моделирование реальной жизненной ситуации, при которой мы теряем или весь дата-центр или его часть.
Для начала предлагаю обратиться к истории и попытаться понять, как мы пришли к такому решению. Все привыкли к тому, что наши сервисы работают всегда, без перерывов на обед и профилактику. Серьезные сбои происходят настолько редко, что каждый из них становится заметным событием.
В 2000 году Яндекс арендовал четыре стойки в «МТУ-Интеле», где размещалось около 40 собственных серверов Яндекса. Эти несколько десятков серверов и стали основой первого самостоятельного дата-центра Яндекса, который располагался в первом офисе компании — в Москве, на улице Вавилова, в вычислительном центре Российской академии наук. В те годы все сервера и вся сетевая инфраструктура были в одном дата-центре. Несколько лет нам везло и никаких ЧП не случалось. Все изменилось в 19 часов 12 ноября 2004 года. В тот момент за пару минут до начала второго тура игры «Кубок Яндекса» в здании Вычислительного центра Российской Академии наук (ВЦ РАН) в Москве на улице Вавилова, где располагается компания, внезапно отключилось электричество.
Это произошло из-за неполадок в оборудовании поставщика электроснабжения. На тот момент у нас уже было 2 дата-центра, но все сетевое оборудование, обеспечивающее связность наших серверов с внешним миром, было в отключённом дата-центре. В тот вечер сервисы Яндекса не работали несколько часов.
Это была первая большая авария, потом были еще и другие:
Очевидно, что в таких условиях мы быстро поняли, что можно рассчитывать только на свои силы и уметь жить в условиях N-1 дата-центр. Мы начали над этим работать в 2004 году, и тогда многие решения, которые кажутся очевидными и простыми сейчас, были для нас в новинку.
Начали с инфраструктуры. После событий 12 ноября наш первый дата-центр был оборудован дизель-генераторной установкой, а второй получил внешнюю связность не только с первым дата-центром, но и связь с внешним миром. Таким образом, в теории стало возможным как-то обслуживать пользователей в условиях, когда один из двух дата-центров не работал. Было понятно, что до того, чтобы это можно было сделать на практике, надо еще вложиться в избыточность, чтобы не умирать под нагрузкой, много чего исправлять в архитектуре проектов и продолжать развивать инфраструктуру.
Интересный факт: c той поры все наши дата-центры оборудованы ДГУ, которые нас не один раз выручали. Как известно, наши основные операционные системы — Linux и FreeBSD, а когда дата-центр работает на ДГУ, то мы шутим, что работаем на Солярке.
Также было решено, что магистральная сеть, объединяющая ДЦ, должна не иметь единых точек отказа. В частности, никакие каналы связи между дата-центрами не должны проходить одними путями. Поэтому первая топология сети, обеспечивающая резервирование, представляла собой кольцо. Тогда каналы соединяли между собой уже три наших дата-центра плюс две точки обмена трафиком с подключением к MSK-IX — в ИКИ и на M9. Со временем магистральная сеть превратилась в двойное кольцо, а теперь все дата-центы московского региона по сути связаны в full mesh. Таким образом, обрыв одного кабеля не влияет на доступность сервисов.
Много усилий ушло на переработку кода наших приложений для работы в новых условиях. Например, мы учили программы складывать пользовательские данные на два сервера и думали, что делать, если один из них становится недоступным: предлагать пользователю загрузить свои данные позже или все же загрузить их на работающий сервер, а потом синхронизировать; патчили модуль ядра IPVS для балансировки нагрузки. Было много раздумий над тем, что делать с базами данных. Например, в MySQL всегда есть один master-сервер, если он не работает может быть два варианта развития событий: переводить сервис в режим «только для чтения», либо писать скрипты, позволяющие быстро сделать master из другого сервера в другом дата-центре. Вспомнить сейчас все, что было сделано тогда, уже не получится, но работы было много.
Подготовительный этап занял около трех лет, за это время мы вложились в дублирование компонент там, где это необходимо и оправдано; для каких-то сервиcов поняли, что переписывать все с нуля — очень дорогая задача и научились деградировать, отрезать менее важную функциональность на время аварий.
К осени 2007 года было понятно, что пора тестировать результаты работы. Как? Конечно, отключать дата-центр по-настоящему в четко обозначенное время, когда все, кому могут быть интересны результаты, были на месте. Сейчас это достаточно распространенная практика: подобные учения проводит большинство крупных игроков со своими дата-центрами, в том числе и многие хостинг-провайдеры. А тогда это был не самый очевидный и достаточно рискованный шаг.
Впервые отключение прошло 25 октября 2007 года, мы прожили без одного из наших дата-центров 40 минут. Первое время у нас не все шло гладко, команды проектов смотрели внимательно на свои сервисы: придумывали, что делать с архитектурой сервисов дальше, писали новые мониторинги, правили баги. С тех пор на вопросы: «Насколько это опасно? А не диверсия ли это?» — я отвечаю, — «Конечно, опасно, нет не диверсия».
Обычно они проходят раз в неделю по вечерам. Почему именно вечером? Мы сами регулярно про это спорим. Тут много факторов, но можно выделить два. Во-первых, мы во время учений можем что-то сломать, днем это затронет большее количество пользователей и будет заметно снаружи, что плохо, а ночью не все на местах, можем что-то упустить и не заметить, что тоже плохо. Во-вторых, вечером у нас не пик трафика, но и не минимум, можно под нагрузкой посмотреть на поведение сервисов. Иногда время начала работ и продолжительность может меняться. Бывает, что мы совмещаем учения с сервисными работами на сети, которые проводят сотрудники NOC. Поскольку сеть должна работать всегда, регламентные работы в сети дата-центра можно производить только тогда, когда он не обслуживает пользовательский трафик. В этом случае отключение дата-центра может растянуться на несколько часов. Это бывает довольно редко, потому что многие регламентные работы, например, обновление программного обеспечения ToR-коммутаторов (Top of Rack), практически полностью автоматизированы и один сетевой инженер может обновить несколько сотен устройств, запустив пару скриптов. В частности, для этого мы используем RackTables — open source продукт, к созданию которого приложили руку мы сами.
Про время, продолжительность и дату определились, что дальше? Важная часть подготовки — координация выключения дата-центра. C 5 октября 2007 у нас на внутренней вики и с недавних пор во внутреннем календаре всегда есть актуальное расписание учений на ближайшее время. График учений стараемся составлять на несколько месяцев вперед. За день до часа X организаторы рассылают последнее предупреждение на несколько списков рассылки и публикуют анонс во внутреннем блоге. В письме можно найти ссылку на список того, что будет не работать/деградировать, и за чем стоит внимательно посмотреть.
Как происходит отключение? Во время учений мы не выключаем питание серверов в тестируемом дата-центре, а моделируем его отключение с помощью сети. Фактически, на сетевом оборудовании, находящемся на периметре дата-центра, мы выключаем виртуальные сетевые интерфейсы, разрывая сетевую связность. Проще делать это таким образом, так как отключать все сервера по питанию сложнее и в итоге дороже. Если отключать по питанию, то необходимо, чтобы на объекте был персонал, который сможет после окончания Учений все включить, и практика показывает, что оборудование частично не включится, что-то обязательно придется менять. По нашей статистике, до 5% дисков может перестать распознаваться операционной системой после выключения. Ну и, конечно же, самый важный фактор — если что-то пойдет не так, то надо иметь возможность быстро вернуть дата-центр в работу. В нашем случае мы можем сделать это достаточно быстро. Поэтому даже если учения идут не по плану, отваливается какой-нибудь сервис или часть функций, для пользователей в подавляющем большинстве случаев все проходит незаметно.
По окончании учений у нас появляется информация о том, что происходило – разбор полетов. Если какие-то сервисы работали незапланированным образом, команды этих сервисов вместе пытаются выяснить, что послужило причиной этому и ставят сами себе задачки.
С каждым разом ошибок всплывает все меньше. Вот, например, недавно мы с небольшим промежутком отключали сначала наш самый старый, а потом самый большой ДЦ. На страничках с итогами отключений нет ни одного тикета с багами. Приятно! Но, конечно, не всегда все проходит так гладко, так как наши сервисы постоянно развиваются и не за всем удается уследить, к сожалению. Но для этого мы и проводим наши тестовые отключения дата-центров.
Нам все еще есть еще над чем работать. Сейчас у нас есть несколько важных задачек. Одна из них — обеспечить непрерывную работу не только наших сервисов для пользователей, но и обеспечить непрерывную работу нашей разработки. Сейчас тестовые и девелоперские среды по большей части не задублированы, и во время учений разработчики вынуждены пить чай и кофе. Сейчас мы ставим эксперименты с OpenStack по миграции – непросто, так как виртуалок и данных много, а междатацентровые линки у нас широкие, но не бесконечные. С другой стороны, быстрое разверытывание вируальной машинки в iaas с необходимым окружением и данными с помощью скриптов.
Почему мы проводим работы регулярно? Нагрузка постоянно растет, сейчас у нас происходит около 1000 изменений программ в день, архитектура меняется, количество серверов, обслуживающих сервис, меняется, с годами меняются условия жизни — старые дата-центры закрываются, появляются новые. В таком постоянно меняющемся окружении надо продолжать решать задачу — работать в условиях N-1 дата-центр.
Раз в неделю Яндекс отключает один из своих дата-центров. Мы называем это учениями. Что это такое? Как возникло? Зачем мы это делаем? А не диверсия ли это? Насколько это опасно? На эти вопросы мне регулярно приходится отвечать как внутри так и снаружи компании. Сегодня я решила прояснить все эти вопросы разом.
Сейчас у нас несколько собственных дата-центров, в которых располагается несколько десятков тысяч серверов и сетевое оборудование. Учения — это моделирование реальной жизненной ситуации, при которой мы теряем или весь дата-центр или его часть.
Для начала предлагаю обратиться к истории и попытаться понять, как мы пришли к такому решению. Все привыкли к тому, что наши сервисы работают всегда, без перерывов на обед и профилактику. Серьезные сбои происходят настолько редко, что каждый из них становится заметным событием.
Когда сервера были большими, а дата-центры маленькими...
В 2000 году Яндекс арендовал четыре стойки в «МТУ-Интеле», где размещалось около 40 собственных серверов Яндекса. Эти несколько десятков серверов и стали основой первого самостоятельного дата-центра Яндекса, который располагался в первом офисе компании — в Москве, на улице Вавилова, в вычислительном центре Российской академии наук. В те годы все сервера и вся сетевая инфраструктура были в одном дата-центре. Несколько лет нам везло и никаких ЧП не случалось. Все изменилось в 19 часов 12 ноября 2004 года. В тот момент за пару минут до начала второго тура игры «Кубок Яндекса» в здании Вычислительного центра Российской Академии наук (ВЦ РАН) в Москве на улице Вавилова, где располагается компания, внезапно отключилось электричество.
Это произошло из-за неполадок в оборудовании поставщика электроснабжения. На тот момент у нас уже было 2 дата-центра, но все сетевое оборудование, обеспечивающее связность наших серверов с внешним миром, было в отключённом дата-центре. В тот вечер сервисы Яндекса не работали несколько часов.
Это была первая большая авария, потом были еще и другие:
- пух забивался в кондиционеры, и они начинали греть, а не охлаждать дата-центры, сервера приходилось отключать;
- отключение дата-центров по питанию по разным и совершенно невероятным причинам, начиная от того, что арендодатель забыл вовремя оплатить счет за электроэнергию, кончая тем, что кошка забралась в трансформаторную будку и устроила короткое замыкание;
- были потопы в дата-центрах;
- конечно, не обошлось и без нашего любимого персонажа — экскаваторщика, ловко и метко копающего в местах, где лежит наш оптоволоконный кабель.
Очевидно, что в таких условиях мы быстро поняли, что можно рассчитывать только на свои силы и уметь жить в условиях N-1 дата-центр. Мы начали над этим работать в 2004 году, и тогда многие решения, которые кажутся очевидными и простыми сейчас, были для нас в новинку.
Развитие инфраструктуры
Начали с инфраструктуры. После событий 12 ноября наш первый дата-центр был оборудован дизель-генераторной установкой, а второй получил внешнюю связность не только с первым дата-центром, но и связь с внешним миром. Таким образом, в теории стало возможным как-то обслуживать пользователей в условиях, когда один из двух дата-центров не работал. Было понятно, что до того, чтобы это можно было сделать на практике, надо еще вложиться в избыточность, чтобы не умирать под нагрузкой, много чего исправлять в архитектуре проектов и продолжать развивать инфраструктуру.
Интересный факт: c той поры все наши дата-центры оборудованы ДГУ, которые нас не один раз выручали. Как известно, наши основные операционные системы — Linux и FreeBSD, а когда дата-центр работает на ДГУ, то мы шутим, что работаем на Солярке.
Также было решено, что магистральная сеть, объединяющая ДЦ, должна не иметь единых точек отказа. В частности, никакие каналы связи между дата-центрами не должны проходить одними путями. Поэтому первая топология сети, обеспечивающая резервирование, представляла собой кольцо. Тогда каналы соединяли между собой уже три наших дата-центра плюс две точки обмена трафиком с подключением к MSK-IX — в ИКИ и на M9. Со временем магистральная сеть превратилась в двойное кольцо, а теперь все дата-центы московского региона по сути связаны в full mesh. Таким образом, обрыв одного кабеля не влияет на доступность сервисов.
Много усилий ушло на переработку кода наших приложений для работы в новых условиях. Например, мы учили программы складывать пользовательские данные на два сервера и думали, что делать, если один из них становится недоступным: предлагать пользователю загрузить свои данные позже или все же загрузить их на работающий сервер, а потом синхронизировать; патчили модуль ядра IPVS для балансировки нагрузки. Было много раздумий над тем, что делать с базами данных. Например, в MySQL всегда есть один master-сервер, если он не работает может быть два варианта развития событий: переводить сервис в режим «только для чтения», либо писать скрипты, позволяющие быстро сделать master из другого сервера в другом дата-центре. Вспомнить сейчас все, что было сделано тогда, уже не получится, но работы было много.
Подготовительный этап занял около трех лет, за это время мы вложились в дублирование компонент там, где это необходимо и оправдано; для каких-то сервиcов поняли, что переписывать все с нуля — очень дорогая задача и научились деградировать, отрезать менее важную функциональность на время аварий.
К осени 2007 года было понятно, что пора тестировать результаты работы. Как? Конечно, отключать дата-центр по-настоящему в четко обозначенное время, когда все, кому могут быть интересны результаты, были на месте. Сейчас это достаточно распространенная практика: подобные учения проводит большинство крупных игроков со своими дата-центрами, в том числе и многие хостинг-провайдеры. А тогда это был не самый очевидный и достаточно рискованный шаг.
Впервые отключение прошло 25 октября 2007 года, мы прожили без одного из наших дата-центров 40 минут. Первое время у нас не все шло гладко, команды проектов смотрели внимательно на свои сервисы: придумывали, что делать с архитектурой сервисов дальше, писали новые мониторинги, правили баги. С тех пор на вопросы: «Насколько это опасно? А не диверсия ли это?» — я отвечаю, — «Конечно, опасно, нет не диверсия».
Как проходят учения?
Обычно они проходят раз в неделю по вечерам. Почему именно вечером? Мы сами регулярно про это спорим. Тут много факторов, но можно выделить два. Во-первых, мы во время учений можем что-то сломать, днем это затронет большее количество пользователей и будет заметно снаружи, что плохо, а ночью не все на местах, можем что-то упустить и не заметить, что тоже плохо. Во-вторых, вечером у нас не пик трафика, но и не минимум, можно под нагрузкой посмотреть на поведение сервисов. Иногда время начала работ и продолжительность может меняться. Бывает, что мы совмещаем учения с сервисными работами на сети, которые проводят сотрудники NOC. Поскольку сеть должна работать всегда, регламентные работы в сети дата-центра можно производить только тогда, когда он не обслуживает пользовательский трафик. В этом случае отключение дата-центра может растянуться на несколько часов. Это бывает довольно редко, потому что многие регламентные работы, например, обновление программного обеспечения ToR-коммутаторов (Top of Rack), практически полностью автоматизированы и один сетевой инженер может обновить несколько сотен устройств, запустив пару скриптов. В частности, для этого мы используем RackTables — open source продукт, к созданию которого приложили руку мы сами.
Про время, продолжительность и дату определились, что дальше? Важная часть подготовки — координация выключения дата-центра. C 5 октября 2007 у нас на внутренней вики и с недавних пор во внутреннем календаре всегда есть актуальное расписание учений на ближайшее время. График учений стараемся составлять на несколько месяцев вперед. За день до часа X организаторы рассылают последнее предупреждение на несколько списков рассылки и публикуют анонс во внутреннем блоге. В письме можно найти ссылку на список того, что будет не работать/деградировать, и за чем стоит внимательно посмотреть.
Как происходит отключение? Во время учений мы не выключаем питание серверов в тестируемом дата-центре, а моделируем его отключение с помощью сети. Фактически, на сетевом оборудовании, находящемся на периметре дата-центра, мы выключаем виртуальные сетевые интерфейсы, разрывая сетевую связность. Проще делать это таким образом, так как отключать все сервера по питанию сложнее и в итоге дороже. Если отключать по питанию, то необходимо, чтобы на объекте был персонал, который сможет после окончания Учений все включить, и практика показывает, что оборудование частично не включится, что-то обязательно придется менять. По нашей статистике, до 5% дисков может перестать распознаваться операционной системой после выключения. Ну и, конечно же, самый важный фактор — если что-то пойдет не так, то надо иметь возможность быстро вернуть дата-центр в работу. В нашем случае мы можем сделать это достаточно быстро. Поэтому даже если учения идут не по плану, отваливается какой-нибудь сервис или часть функций, для пользователей в подавляющем большинстве случаев все проходит незаметно.
Разбор полетов
По окончании учений у нас появляется информация о том, что происходило – разбор полетов. Если какие-то сервисы работали незапланированным образом, команды этих сервисов вместе пытаются выяснить, что послужило причиной этому и ставят сами себе задачки.
С каждым разом ошибок всплывает все меньше. Вот, например, недавно мы с небольшим промежутком отключали сначала наш самый старый, а потом самый большой ДЦ. На страничках с итогами отключений нет ни одного тикета с багами. Приятно! Но, конечно, не всегда все проходит так гладко, так как наши сервисы постоянно развиваются и не за всем удается уследить, к сожалению. Но для этого мы и проводим наши тестовые отключения дата-центров.
Нам все еще есть еще над чем работать. Сейчас у нас есть несколько важных задачек. Одна из них — обеспечить непрерывную работу не только наших сервисов для пользователей, но и обеспечить непрерывную работу нашей разработки. Сейчас тестовые и девелоперские среды по большей части не задублированы, и во время учений разработчики вынуждены пить чай и кофе. Сейчас мы ставим эксперименты с OpenStack по миграции – непросто, так как виртуалок и данных много, а междатацентровые линки у нас широкие, но не бесконечные. С другой стороны, быстрое разверытывание вируальной машинки в iaas с необходимым окружением и данными с помощью скриптов.
Почему мы проводим работы регулярно? Нагрузка постоянно растет, сейчас у нас происходит около 1000 изменений программ в день, архитектура меняется, количество серверов, обслуживающих сервис, меняется, с годами меняются условия жизни — старые дата-центры закрываются, появляются новые. В таком постоянно меняющемся окружении надо продолжать решать задачу — работать в условиях N-1 дата-центр.