company_banner

Как и для чего Яндекс отключает собственные дата-центры

    Раз в неделю Яндекс отключает один из своих дата-центров. Мы называем это учениями. Что это такое? Как возникло? Зачем мы это делаем? А не диверсия ли это? Насколько это опасно? На эти вопросы мне регулярно приходится отвечать как внутри, так и снаружи компании. Сегодня я решила прояснить все эти вопросы разом.



    Сейчас у нас несколько собственных дата-центров, в которых располагается несколько десятков тысяч серверов и сетевое оборудование. Учения — это моделирование реальной жизненной ситуации, при которой мы теряем или весь дата-центр или его часть.

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

    Когда сервера были большими, а дата-центры маленькими...


    В 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 дата-центр.
    Яндекс
    577,00
    Как мы делаем Яндекс
    Поделиться публикацией

    Комментарии 115

      –13
      Яндекс когда-нибудь начнет нормально работать в US и Южной Амеркие? Пинг в 150 мс — это тотальный ужас. Неужели так обязательно гнать трафик через половину земного шара в Москву?
        +26
        Когда-нибудь — начнет.
          –7
          Тогда когда-нибудь начну пользоваться Яндексом :)
            +6
            Потому что даже из Питера Яндекс откликается медленнее «заокеанского» Google:
            ping google.com
            PING google.com (80.70.231.29): 56 data bytes
            64 bytes from 80.70.231.29: icmp_seq=0 ttl=61 time=3.726 ms
            


            ping ya.ru
            PING ya.ru (93.158.134.3): 56 data bytes
            64 bytes from 93.158.134.3: icmp_seq=0 ttl=54 time=16.678 ms
            


            Google поставил свое железо не так далеко от моего дома, а родной Яндекс не соизволил.
              +2
              А каким таким сервисом вы пользуетесь, что вам для него настолько критичен пинг?
                +3
                Я Почтой :( Он не критичен, он причина — половина страниц сваливалась в «Превышено время ожидания ответа сервера».
                  +8
                  Это, безусловно, ненормально. Если проблема повторяется и вы готовы поучаствовать в диагностике, напишите мне на ivlad@yandex-team.ru, я попрошу коллег разобраться.
                  • НЛО прилетело и опубликовало эту надпись здесь
                  +5
                  Просто у вашего провайдера стоит такая коробка: peering.google.com/about/ggc.html

                  Она и пингуется. Увы, в этой коробке есть не весь интернет, поэтому когда вы задаете гуглу запрос, она всё равно ходит в настоящую сеть гугла, с уже заметно большим пингом.
                    0
                    Не совсем у провайдера, оно стоит в точке обмена трафиком (Pirix) и дает отличное латенси, например, до Google DNS :)

                    Да и GGC — это несколько иное, это чисто провайдерская коробка, которую Google ставит начиная с XX гигабит трафика на Youtube с определенного провайдера и позволяет дать суперскую скорость, да!

                      +2
                      GGC это не коробка, это полстойки серверов.
                        +2
                        Немного не так. GGC представляет собой комплекс из N серверов, которые кешируют горячие данные для сервисов из списка FAQ. Google Public DNS там нет. Количество серверов в ноде прямо пропорционально максимально возможному трафику на ноду.
                          +1
                          У нас стоят кеши в SPB-IX.
                        +3
                        У меня противоположная ситуация:
                        ping yandex.ru
                        PING yandex.ru (93.158.134.11) 56(84) bytes of data.
                        64 bytes from yandex.ru (93.158.134.11): icmp_seq=1 ttl=56 time=11.9 ms
                        64 bytes from yandex.ru (93.158.134.11): icmp_seq=2 ttl=56 time=11.8 ms
                        
                        ping6 ipv6.yandex.ru
                        PING ipv6.yandex.ru(www.yandex.ru) 56 data bytes
                        64 bytes from www.yandex.ru: icmp_seq=1 ttl=56 time=12.8 ms
                        64 bytes from www.yandex.ru: icmp_seq=2 ttl=56 time=12.6 ms
                        


                        ping google.com
                        PING google.com (64.233.162.138) 56(84) bytes of data.
                        64 bytes from 64.233.162.138: icmp_seq=1 ttl=48 time=25.8 ms
                        64 bytes from 64.233.162.138: icmp_seq=2 ttl=48 time=26.9 ms
                        
                        ping6 ipv6.google.com
                        PING ipv6.google.com(lb-in-x8b.1e100.net) 56 data bytes
                        64 bytes from lb-in-x8b.1e100.net: icmp_seq=1 ttl=56 time=61.7 ms
                        64 bytes from lb-in-x8b.1e100.net: icmp_seq=2 ttl=56 time=61.0 ms
                        
                    +6
                    > Пинг в 150 мс — это тотальный ужас.

                    Да вы, батенька, зажрались, мягко говоря.
                      –1
                      На самом деле было хуже, но сохранилась лишь часть трейса :)

                      1 10.156.0.2 (10.156.0.2) 79.867 ms 100.977 ms 91.591 ms
                      2 10.20.253.2 (10.20.253.2) 103.734 ms 183.075 ms 11.776 ms
                      3 10.20.100.18 (10.20.100.18) 36.451 ms 33.319 ms 37.083 ms
                      4 201-157-2-1.internetmax.maxcom.net.mx (201.157.2.1) 15.168 ms 43.386 ms 30.280 ms
                      5 201-157-100-54.internetmax.maxcom.net.mx (201.157.100.54) 25.187 ms 59.009 ms 63.127 ms
                      6 * * xe-11-1-1.bar2.houston1.level3.net (4.59.126.73) 88.111 ms
                      7 * * *
                      8 ae-2-2.ebr1.washington1.level3.net (4.69.132.86) 310.144 ms 244.329 ms 181.692 ms
                      9 ae-91-91.csw4.washington1.level3.net (4.69.134.142) 177.498 ms
                      ae-61-61.csw1.washington1.level3.net (4.69.134.130) 251.652 ms
                      ae-81-81.csw3.washington1.level3.net (4.69.134.138) 178.365 ms
                      10 ae-62-62.ebr2.washington1.level3.net (4.69.134.145) 236.085 ms *
                      ae-82-82.ebr2.washington1.level3.net (4.69.134.153) 195.498 ms
                      11 ae-44-44.ebr2.paris1.level3.net (4.69.137.61) 820.918 ms 181.402 ms 190.887 ms
                      12 ae-46-46.ebr1.frankfurt1.level3.net (4.69.143.137) 177.647 ms
                      ae-47-47.ebr1.frankfurt1.level3.net (4.69.143.141) 202.515 ms
                      ae-48-48.ebr1.frankfurt1.level3.net (4.69.143.145) 288.213 ms
                      13 ae-71-71.csw2.frankfurt1.level3.net (4.69.140.6) 326.613 ms *
                      ae-91-91.csw4.frankfurt1.level3.net (4.69.140.14) 201.955 ms
                      14 ae-63-63.ebr3.frankfurt1.level3.net (4.69.163.1) 210.309 ms
                      ae-73-73.ebr3.frankfurt1.level3.net (4.69.163.5) 276.961 ms
                      ae-83-83.ebr3.frankfurt1.level3.net (4.69.163.9) 302.146 ms
                      15 ae-45-45.ebr1.dusseldorf1.level3.net (4.69.143.165) 179.881 ms
                      ae-48-48.ebr1.dusseldorf1.level3.net (4.69.143.177) 226.336 ms 219.083 ms
                      16 ae-114-3504.bar1.stockholm1.level3.net (4.69.158.253) 205.535 ms
                      ae-111-3501.bar1.stockholm1.level3.net (4.69.158.241) 293.399 ms
                      ae-114-3504.bar1.stockholm1.level3.net (4.69.158.253) 192.366 ms
                      
                        +15
                        Очень подозрительный трейс. У вас до собственного роутера уже 100 мс. А дальше значения сильно скачут. Похоже, что-то сильно нагружало вашу сеть или роутер во время измерений.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        К тому же свет в оптоволокне распространяется не прямолинейно, соотв. времени нужно даже больше…
                          +1
                          Добавьте ещё замедление скорости света на треть в оптоволокне, и меньше чем 200 мс вы на полземного шара не получите.
                          +1
                          Оу…
                          C:\Users\User>ping mail.yandex.ru

                          Обмен пакетами с mail.yandex.ru [87.250.251.25] с 32 байтами данных:
                          Ответ от 87.250.251.25: число байт=32 время=753мс TTL=47
                          Ответ от 87.250.251.25: число байт=32 время=688мс TTL=47
                          Ответ от 87.250.251.25: число байт=32 время=696мс TTL=47
                          Ответ от 87.250.251.25: число байт=32 время=688мс TTL=47

                          Статистика Ping для 87.250.251.25:
                          Пакетов: отправлено = 4, получено = 4, потеряно = 0
                          (0% потерь)
                          Приблизительное время приема-передачи в мс:
                          Минимальное = 688мсек, Максимальное = 753 мсек, Среднее = 706 мсек


                          Заметьте, и ведь мой пинг из России…
                            0
                            Сделайте tracepath, будет понятнее, где затык.

                            Кстати, у Yandex есть свой публичный Looking Glass? Для отладки проблемы надо бы оба трейса, как от клиента до Я, так и от Я до клиента.
                              0
                              C:\Users\User>tracert mail.yandex.ru

                              Трассировка маршрута к mail.yandex.ru [93.158.134.25]
                              с максимальным числом прыжков 30:

                              1 2 ms 7 ms 2 ms 192.168.1.1
                              2 43 ms 40 ms 40 ms 85.28.192.68
                              3 143 ms 41 ms 42 ms 85.28.192.33
                              4 42 ms 40 ms 40 ms bgw1-gi0-0-21.tech.kamchatka.ru [85.28.192.174]

                              5 39 ms 47 ms 40 ms kmch-car2-ge0-1-104.rt-comm.ru [213.59.5.17]
                              6 574 ms 575 ms 588 ms main.kriljon.ru [213.59.5.6]
                              7 579 ms 599 ms 583 ms skhl-car1-ge0-1-16.rt-comm.ru [213.59.5.5]
                              8 689 ms 769 ms 714 ms 95.167.91.62
                              9 686 ms 761 ms 714 ms 79.133.94.214
                              10 * * * Превышен интервал ожидания для запроса.
                              11 807 ms 712 ms 681 ms ugr-p3-be6.yndx.net [87.250.239.91]
                              12 733 ms 713 ms 688 ms ugr-b-c1-ae4.yndx.net [87.250.239.75]
                              13 761 ms 710 ms 713 ms mail.yandex.ru [93.158.134.25]
                                0
                                Ваш провайдер заворачивает трафик через спутник:

                                5 39 ms 47 ms 40 ms kmch-car2-ge0-1-104.rt-comm.ru [213.59.5.17]
                                6 574 ms 575 ms 588 ms main.kriljon.ru [213.59.5.6]
                                7 579 ms 599 ms 583 ms skhl-car1-ge0-1-16.rt-comm.ru [213.59.5.5]

                                РТКОММ — провайдер, обладающий спутниковыми каналами.

                                Сайт kriljon.ru/ немногословен, но имеет нужную информацию: Спутниковая компания ООО «Крильон-САТ»

                                Разница между пингом до седьмого хопа на Сахалине и до mail.yandex.ru уже выглядит не столь пугающей.
                                  0
                                  Ваш провайдер заворачивает трафик через спутник
                                  Правда что ли??? А название других узлов вас не смутило??
                                  Например bgw1-gi0-0-21.tech.kamchatka.ru
                                    +1
                                    Ваш провайдер заворачивает трафик через спутник

                                    Правда что ли???

                                    Простите, был неточен в формулировке. Апстрим (магистральный провайдер) вашего провайдера заворачивает трафик через спутник. Как вы еще объясните шестой хоп с таким RTT?

                                    А название других узлов вас не смутило??
                                    Например bgw1-gi0-0-21.tech.kamchatka.ru

                                    Не вижу причин, по которым наличие пограничного маршрутизатора с гигабитным интерфейсом у вашего провайдера должно было меня смутить. Его наличие никак не влияет на наличие спутникового моста от Камчатки до Сахалина у рткомм.
                                      0
                                      Не вижу причин, по которым наличие пограничного маршрутизатора с гигабитным интерфейсом у вашего провайдера должно было меня смутить.

                                      Камчатка. Полуостров. Проводных каналов интернет нет. Совсем.
                          0
                          -
                            +5
                            Удивила цифра про 5% с дисками. С чем это связано?
                              –1
                              Возможно с резким изменением силы магнитного поля, когда сеть обесточивается и поле просто пропадает.
                                +4
                                Когда они непрерывно работают, разогреваются и расширяются. При выключении и быстром остывании, видимо, нарушается качество поверхности. Если бы дорожки просто смещались, скорее всего, проблемы бы не было. Но у нас, увы, нет электронного микроскопа, что б поисследовать это получше. :(

                                Еще какая-то доля мрет по электронике, но, если я правильно помню статистику, небольшая.
                                  0
                                  Когда неожиданно пропадает питание, диску не всегда хватает энергии, чтобы запарковать головки. Если головки не паркуются, то могут испортить поверхность диска. Например, это одна из причин
                                    0
                                    если я правильно понимаю, то сейчас у всех дисков парковка идет чисто потоком набегающего воздуха.
                                    а так, имхо тут в первую очередь вопрос о контактах будет и плюс электроника. мне рассказывали как-то про SCSI полку, оттарабанившую лет 6 без единого косяка, но в которой ни один диск не стартовал после отключения питания — при включении у всех дисков сдохли мозги.
                                      +1
                                      Кто-то из производителей дисков хвастался, что использует кинетическую энергию диска для генерации электроэнергии, которая используется, чтобы сбросить кэш на диск и запарковать головки.
                                        +2
                                        Погодите-погодите. Какое еще «неожиданно пропадает питание»? Это на десктопике у меня возможно, а у вас вон целый цех с ДГ!
                                        Так что сказали А, говорите и Б — откуда 5% отказов? :)
                                          +1
                                          ХЗ, но суровая правда. Если сотня дисков непрерывно крутится пол года-год, а потом её вырубить и врубить назад, то действительно несколько штук умрут либо сразу, либо в течении очень короткого времени. Не знаю, как насчёт 5% отказов, но процент-два будет. Лично проверял. Возможно дело как раз в механике задействованной при парковке/разгоне, которая тоже подвержена износу при движении головки, но может неиспользоваться чуть ли не годами — до моменты остановки диска.
                                          Более того, ещё вертояность отказов в обычной электронике повышается, что уж совсем удивительно.
                                            +1
                                            Вырубить нормально, т.е без выдергивания питания в момент сброса кэша?
                                            А это к вас на каком примерно кол-ве дисков воспроизводится, ну порядок?
                                            Интересно.
                                              0
                                              Вырубить нромально можно как раз дескоп, это просто. А вот вырубить быстро несколько тысяч серверов сложнее. Хотя бы потому, что не у всех есть ipmi (legacy). C ipmi проще, конечно же, но и то бывают исключения, что сервер по каким-то причинам не потушился.
                                                –1
                                                Опять вы уводите тему! =) Вас я спрашивал как раз о ваших же словах -«Когда неожиданно пропадает питание, диску не всегда хватает энергии...» — поскольку не понятно каким образом в яндексе может неожиданно пропасть питание, если всё резервируется бескрайним цехом с дизелями.
                                                  0
                                                  Не поверите, но не всегда все резервирование отрабатывает правильно. И думаю что ЦОД-ы Яндекса — не исключение. Именно для этого резервируются еще и сами площадки.
                                                0
                                                Вырубить выключением питания. Все критические задачи конечно завершаются, но ОС проболжает работать. На количестве примерно сотня. Эффект наблюдается если система длительное время проработала — т.к. несколько месяцев гоняем не выключая. А потом выключаем. И тогда несколько дисков могут запросто не включиться. Система промышленная — там довольно жарко и вибрации всякие (при том, что компьютеры конечно же с активным охлаждением, на аамортизаторах и т.п.).
                                                При этом, я даже не могу вспомнить ни одного «горячего» (т.е. во время работы) отказа — или не включается, или мрёт буквально после включения (там диагностика всякая крутилась до начал аработы системы).
                                                  –2
                                                  Ну, несколько месяцев это не много. Хотя бы год — уже можно о чем-то говорить. Но раз у вас какая-то специфика (вибрации, жара), то «не интересно». Просто потому, что у вас необычные условия. Речь всё-таки про обычную среднестатистическую серверную.
                                                    0
                                                    Специфика спецификой, но все параметры мониторились и были в допустимых предалах.
                                                    0
                                                    При этом, я даже не могу вспомнить ни одного «горячего» (т.е. во время работы) отказа

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

                                                    Но HDD изнашивается и по механике, и по магнитному слою на блинах, так что для них нормально помирать просто так в процессе работы.
                                                0
                                                Ну вот пример из жизни: сертифицированный коммерческий ЦОД. Два луча питания, SLA, все дела. И тут однажды — бац! — один из источников питания от уважаемой фирмы ловит программную ошибку и считает своим долгом выключиться. Ну, допустим, имеет право, пока есть второй луч.
                                                Но источник на втором луче смонтирован/настроен с ошибкой и воспринимает увеличившуюся нагрузку как ток короткого замыкания и предупредительно выключает второй луч.
                                                Кстати, софтовая бага повторилась и в другом ЦОДе, другого владельца и полностью независимого от первого. Но там второй луч уже не падал.
                                                Так что внезапно электропитание пропасть вполне, увы, может. До дизелей в этом случае не доходит, т.к. дизели реагируют на пропадание входящего напряжения, а отключение произошло уже непосредственно перед стойками.
                                                  0
                                                  Уважаемая фирма это APC, видимо.
                                              +3
                                              Очень просто — сдыхает все, что «планировало» сдохнуть в недалеком будущем.

                                              Старт-стоп — это всегда наиболее «отказоемкая» фаза для любого оборудования. Причин этому несколько:

                                              — Остановка и последующий запуск движущихся частей. К примеру, кулер с умирающим мотором может долго крутиться на постоянных оборотах, а вот набрать их после отключения — уже нет.

                                              — Температурный перепад (охлаждение после остановки, потом нагрев при выходе на режим). Микротрещины пайки, вздутия конденсаторов, плохой контакт разъемов — все идет сюда.

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

                                              — Повышенная электрическая нагрузка. Массовый стартап может просадить даже сеть во всем ДЦ, а в условиях конкретных систем это может вылиться, к примеру, в неспособность «поношенного» блока питания дисковой полки раскрутить пару десятков дисков одновременно (а стартовые токи могут в разы превышать рабочие). При этом в нормальном режиме его вполне хватало.

                                              В норме железка проработала бы еще несколько дней-недель-месяцев, но один из этих факторов может легко «добить» ее именно в момент массового отключения-включения. А если железок тысячи, то и число умерших будет приличным.
                                            +1
                                            Интересно, а планируются ли учения N-2? Ведь чем больше датацентров, тем больше (теоретически) вероятность отказа двух одновременно.
                                              +2
                                              Пока не планируются, это удорожает стоимость проектов. На моей практике было всего два случая, когда одновременно были аварии в двух датацентрах. Кстати, мы выживали и продолжали работать :-)
                                                0
                                                «Извините, сервис временно недоступен

                                                Ваше последнее действие не выполнено.
                                                Попробуйте повторить его позднее».
                                                Это тоже часть учений? Причем, по какому-то злому року, этот сервис недоступен гораздо чаще, чем хотелось бы :(
                                                Если что — я об Яндекс.Закладках
                                                  0
                                                  Нет, это не часть учений.
                                                    0
                                                    kukutz tvt, а предупредить заранее об этой части «не учений» возможно было? В интернете нигде информации нет, на вики информации нет, на почту (Яндекс) уведомлений тоже не было, ticket 14120122401039313 — пока что молчат, вот сижу и думаю, когда мне начинать паниковать? В пятницу вечером можно будет напиваться?
                                                      0
                                                      Я не уловил.

                                                      Я вам говорю: это не учения, это сервис упал. А вы мне говорите: «а почему заранее не предупредили?».

                                                      Так?
                                              +5
                                              Это же скучно, может так:

                                              crontab:
                                              
                                              0 * * * * /home/admin_at_yandex/make_random_issue_in_random_data_center.sh
                                              


                                              А то у вас все распланировано, и всё такое, жить надо веселее :)
                                                +1
                                                Это следующий уровень, ну или аварийное отключение :-)
                                                  +4
                                                  Мы знаем про существование Chaos Monkey и идея мне нравится. Дойдем и до этого.
                                                  +4
                                                  А каким образом вы боретесь с неконсистентностью данных? Скажем, поднимается датацентр, включается в работу, а данные уже рассинхронизированы. Как перенаправляете запросы, каким образом реагируете на непредсказуемую задержку в этом случае? Особенно интересно, каким образом все восстанавливается в случае географически удаленных датацентров.
                                                    +2
                                                    Происходит примерно следующим образом: после включения датацентра смотрим на консистентность данных тоже. Конечно делается это не вручную, а с помощью специальных программ. Пока данные в отключенном датацентре не станут консистентыми в работу он не включается. Например, сервера прикрыты firewall пока данные на slave server mysql не будут синхронизированы с slave серверами в других ДЦ.
                                                    Датацентровые линки, конечно, помогают.
                                                      0
                                                      Стараемся хранить данные в тех СУБД, которые умеют переживать отключение master'а и автоматически синхронизоваться. Какие именно — зависит от конкретного сервиса. Часто можно обойтись key value хранилищем. В некоторых сервисах реализованы избыточные вычисления: одни и те же данные обрабатываются на нескольких машинах, забирать можно с любой. А какие-то задачи можно вообще условно считать stateless: при запуске сервис подгрузит свежие данные из низлежащих сервисов и начнет работать.
                                                      +15
                                                      киску жалко
                                                        0
                                                        Ой, 5 хабов у топика, оказывается, уже может быть. А при создании всё ещё пишут «Чтобы увеличить аудиторию публикации, выберите два дополнительных тематических хаба».
                                                          0
                                                          А не планировали тестровать обесточивание с бОльшей редкостью? эдак раз в пол года для каждого ДЦ?
                                                            +4
                                                            А можно спустя 5 лет, я все-таки увижу фотку того самого сервака с временем аптайм в… уже 15 лет?

                                                            я хорошо себя вел в этом году, могу я получить подарок?

                                                            спасибо
                                                              0
                                                              Обесточивание ДЦ именно в формате выключения по питанию происходит достаточно редко, так как операция дорогая, как я и писала. Оно необходимо только в случае, когда происходят работы на энергетическом оборудовании.
                                                              Если под обесточиванием подразумеваются учения, то так как датацентров несколько, то получается, что в среднем для каждого датацентра учения происходят с бОльшей редкостью.
                                                              Ну и надо учитывать, что мы, например, не учим их на праздниках, до них, сразу после них.
                                                              Регулярность необходима — это залог того, что в нужный момент, во время аварии, когда контролировать ситуацию в разы сложнее, у нас все сработает.
                                                                +6
                                                                Во, а такой наглый вопрос можно закинуть:
                                                                Как в яндексе ведется контроль живости хардов? Только по тому, как они мрут? По тому, как винт отдает по смарту, что ему скоро будет TEC? По постоянному анализу смарта? По тому, что говорят рейды, в настройках которых вписан переодический verify массивов? Отдано на попечение чей-либо СХД?
                                                                  0
                                                                  В условиях выживания N-1 ДЦ крайне редко имеет смысл контролировать живость отдельно взятого HDD.
                                                                    0
                                                                    Если положить с пробором на хоть какой-то контроль, то можно налететь на прикол, когда в течении 1-2 недель сильно помрут кучи хардов в двух ДЦ, что не есть вери гуд. Плюс в случае с брендовыми решениями можно налететь на партию слегка некошерных дисков, а если при этом положить болт ещё дальше, то можно её распределить между двумя ДЦ причем так, что партия целиком окажется на двух дублирующих друг-друга серверах.
                                                                    0
                                                                    Есть фоновые проверки по SMART. Я, к сожалению, не могу говорить про детали организации RAID, политики про СХД и проч.
                                                                    0
                                                                    на последнем фото коммутаторы Extreme? :)
                                                                      0
                                                                      Судя по плотности портов, типичным заглушкам и более блеклому цвету — что-то из Huawei. Возможно, серия S6300 :)
                                                                      –1
                                                                      серверА
                                                                      ну зачем вы так?
                                                                        +1
                                                                        Действительно, литературная норма «серверы», но на той же «Грамоте» за «сервера» не убивают, потому что такое употребление допускается в профессиональной речи. А это текст, написанный специалистом.
                                                                        0
                                                                        А имитировать пропадания питания на всех ввода не пробовали? Был свидетелем, когда в Даталайне система запуска ДГУ (ни одного из трех) не сработала, и когда аккумуляторы разрядились, то все выключилось. В другом ДЦ (KIAE-House) переключатель вводов не сработал или сработал неверно, после того как один отключился.

                                                                        Откуда взялась цифра про 5% дисков? Это на глаз или расчеты?

                                                                        Сервера не включатся по массе причин — RAID не определится, POST-тест не пройдет, память не проверится. И все это произойти может разово — после ребута все встанет. А блоки питания — порой им надо состоять с выключенным шнуром минут 20-30 и они заработают. Я так понимаю, конденсаторы разряжаются и снова готов к работе.

                                                                        Что касаемо персонала для включения. Есть же Wake-on-LAN. Есть управляемые розетки. KVM, spare-диски иметь в массивах. Думаю, можно сделать ДЦ где не будет нужны remote hands. Вернее, я даже видел что-то подобное у продвинутых айтишников.

                                                                          0
                                                                          А имитировать пропадания питания на всех ввода не пробовали?
                                                                          У нас есть процесс тестирования ДГУ и резерва электропитания. Но это не тоже самое, что пропадание датацентра, другой уровень. Поэтому тут про это не рассказываем.
                                                                          Откуда взялась цифра про 5% дисков?
                                                                          Трудно называть расчетами одну операцию деления, но, да, «расчеты».
                                                                            0
                                                                            Понятно.

                                                                            Но предположу, что это синтетические тесты, к боевой ситуации не совсем имеющие отношения.
                                                                              0
                                                                              Если всетаки почитать статью, то там упоминаются случаи когда датацентры целиком отключали по питанию. Это разве не «боевая ситуация» или думаете кошка в трансформаторе была засланная?
                                                                                0
                                                                                Кошка в трансформаторе была не засланная. Она была синтетическая :)
                                                                                  0
                                                                                  Отнюдь. 100-процентная натуральная шерсть. :)
                                                                                  0
                                                                                  Я это воспринял как историю о стандартном дизастере, который постигает многие (или все ДЦ). Но мы вроде про тесты говорим.

                                                                                  Да и не было сказано, что тогда произошло — все попадало или штатно переключилось на другой ввод и перестало работать.
                                                                                    0
                                                                                    Кстати, я и заголовок воспринял, как отключение по питанию. Связность это конечно важно, но это не так страшно, как падение по питанию всего зала.Мне приходилось переживать подобное в пору работы в датацентрах.

                                                                                    Ощущение тишины в датацентре поражает.

                                                                                    А еще напрягает ситуация, когда идет перегрев тотальный и обстановка напоминает, рассказ Житкова про контрабандную перевозку бертолетовой соли. Там был боцман Салерно, который знал, какую «соль» везет корабль.

                                                                              0
                                                                              Во-во-во, мне про диски и 5% тоже сразу стало интересно! От гугла есть очень добротная статья как они изучали отказы дисков, хотя в основном с перекосом в SMART мониторинг, что для железных рейдов не актуально. Не думаю, что у яши хватит сил на подобный труд, но хотя бы комментарий к цифре очень интересен.
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  +1
                                                                                  Согласно статистике гугла, по smart теоретически предсказывается до 30% отказов. Остальные мрут мгновенно или смарт ничего не предсказывал. Про то, когда рейд выкидывает диск, кстати, есть интересная заметка от amarao geektimes.ru/post/92701/. Но вцелом на масштабах яндекса врядли будут гадать на смарте. Рейд подразумевает избыточность и диски, как расходный материал. Чуть сбойнул — пошел вон, никто не будет ждать до последнего. Поэтому, наверное, смарта за реидом и не видно обычно.
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    0
                                                                                    LSI — умеет, Adaptec — тоже умел (по крайней мере в до SAS 6Gbps эпохи), прочие не мучал (про софтовые поделки — хз, я этим мусором не занимался)
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    0
                                                                                    Для железных рейдов смарт какраз ещё более актуален, в случае софтовой помойки или вообще отдельного диска на осыпание можно отреагировать фразой «нублин, опять пара гигов убилась», а когда raid60 решит между делом выплюнуть три-четыре диска и планомерно скатиться из degraded в dead.
                                                                                      0
                                                                                      Не совсем понял, что вы хотели этим сказать. RAID подразумевает избыточность дисков, но если у вас одновременно умирает 3-4 диска, то, простите, вам просто очень не повезло. Но это крайне маловероятный случай (про смерть в процессе ребилда мы сейчас не говорим, это отдельная тема).
                                                                                      Честно скажу, что взаимоотношения R-контроллеров со SMART-ами дисков — смотрят они туда или нет, и если да, то на что именно — для меня тайна. Если у вас есть пруфлинки, буду признателен. А теоретизировать я и сам горазд =)
                                                                                  +1
                                                                                  А как у вас сервера в смысле отказоустойчивости оборудованы? Интересует: есть ли в машинах зеркалирование дисков (или еще какие-то RAID; если да, то RAID аппаратный или программный), есть ли вторый БП, вторые сетевушки?

                                                                                  Я к тому, что при большом числе серверов вроде как вылет одного сервера не критичен (другие нагрузку подхватят, наверное?), так вот насколько вы сразу тратитесь на резервирование вылетающих компонентов каждого сервера, либо просто считаете, что вылет сервера не смертелен, и брать лишний винты, БП, другое железо бессмысленно, и только удорожает конкретную машину.
                                                                                    0
                                                                                    Сильно зависит от проекта и функционала, но в общем случае потеря одного сервера и даже стойки с серверами не должна является чем-то критичным для проекта. Однако, есть исключения.
                                                                                    0
                                                                                    Фактически, на сетевом оборудовании, находящемся на периметре дата-центра, мы выключаем виртуальные сетевые интерфейсы, разрывая сетевую связность.

                                                                                    Гасите жестко (ACL с deny any во входящем направлении), или все-таки стараетесь избегать любого рода таймаутов и мягко отзываете анонсы?

                                                                                    Точно ли нет смысла нарушать связность и внутри площадки, чтобы системы перестали друг друга видеть?
                                                                                      0
                                                                                      shut.
                                                                                        0
                                                                                        Notification при этом уходит?
                                                                                          0
                                                                                          LSA. да.

                                                                                          Точно ли нет смысла нарушать связность и внутри площадки, чтобы системы перестали друг друга видеть?
                                                                                          Она частично нарушается. Но машинки внутри одного свича в любом случае будут друг друга видеть.
                                                                                            0
                                                                                            Я больше про BGP. Ну наверняка уходит notification, и вы экономите сколько-то секунд на обнаружение сбоя (если поднят BFD, то сколько-то миллисекунд, но… не все так делают).

                                                                                            А на предмет частичных сбоев тестируете? К примеру, на площадке отъехал ряд стоек (погасили аплинки до ToR свитчей). Или перестал работать L2 сегмент. Опять же, ЦОДы мрут полностью очень редко, я бы сказал что большинство даунтаймов вызываются вовсе не попаданием метеорита в площадку или ее обесточиванием.

                                                                                            Кстати, тоже повод для статьи. Опишите причины нескольких последних серьезных (минута и более простоя сервиса) сбоев :)
                                                                                              0
                                                                                              Ну, конечно, там, где доходит до BGP, случается notification.

                                                                                              Мы подумаем на счет еще одной статьи про стабильность Яндекса.
                                                                                      –14
                                                                                      Yandex опять пиарится на Хабре?

                                                                                      А будет ответ на вопрос почему Yandex летом 2014 года по запросу «Вторжение в Украину» не индексировал и не выдавал ничего? В выдаче были только ссылки 2013 и пред. годов
                                                                                        0
                                                                                        Очень интересная и немного познавательная статья.

                                                                                        По поводу индексации тоже есть вполне логичное объяснение: провокационные запросы, нарушающие статью УК «разжигание межнациональной розни» могли резать специально. Точно так же как резались запросы «массовые убийства женщин и детей в Донецке», «фашисты из АТО подвергают мирных жителей средневековым пыткам», «вторжение украинских войск в Россию» (когда украинские военные с оружием в руках сотнями переходили нашу границу).
                                                                                          –6
                                                                                          могли резать специально

                                                                                          У меня и мысли не было что случайно. А что можно получить официальный ответ что это произошло из-за сбоя в работе оборудования?

                                                                                          Точно так же как резались запросы

                                                                                          На какой странице Яндекса можно увидеть список запросов которые запрещены к выдаче?
                                                                                            –3
                                                                                            Такую техническую информацию никто никогда не разгласит, это информация ограниченного доступа для служебного пользования. Я свечку не держал, доступа к такому списку нет, но уверен, что режется часть инфы по созданию взрывчатки и прочих пособиях террористов, сервера тика «кавказ», педофилия, ядерное вооружение, нацистские сайты.
                                                                                          +2
                                                                                          Сейчас такого ответа, вероятно, не будет, т.к. вы его задаёте сейчас, а не летом. Если вы сейчас знаете какие-то запросы, по которым не находится то, что по вашему мнению должно — напишите.
                                                                                            –4
                                                                                            Летом я не видел что на Хабре пишет Яндекс.
                                                                                            Куда мне надо было вопрос отправить? На support@yandex.ru или putin@kreml.ru?
                                                                                              –1
                                                                                              Зачем писать вопросы, не требующие ответа? Есть законы РФ, конкретно УК. Яндекс ведет свою деятельность на территории России и обязан подчиняться ее законодательству. Как гугл и рамблер подчиняются американскому законодательству. Есть закон, яндекс старается работать в его рамках, что в этом удивительного?
                                                                                                0
                                                                                                Показать ответ на любой запрос пользователя не нарушает никаких законов.

                                                                                                Если их кто-то и может нарушать — то это сайты, которые находятся.
                                                                                                0
                                                                                                На support@yandex.ru.
                                                                                            0
                                                                                            Я вам предлагаю назвать такие вечера «Грандиозные Дебаг». По сути вы ведь именно дебажите свои сервисы, таким образом. Процесс невероятный… В отличии от обычного дебага знакомого каждому программисту, у вас уровень адреналина на «вечеринках» просто зашкаливает.
                                                                                              +1
                                                                                              Подозреваю, что уровень адреналина остается в пределах нормы. Есть согласованный план работ, ответственные. Процедура обкатанная, оборудование зарезервировано с запасом. В случае форс-мажоров, есть план восстановительных работ. Каждый форс-мажор изучается экспертами для исключения их в будущем. Как с авиацией, каждая авария делает полеты еще более безопасными за счет внедрения новых мер. У инженеров процедура уже отработанная, месяцами проходит без сбоев, чего бы им волноваться?
                                                                                                0
                                                                                                Учитывая, что сервисы постоянно развиваются, и уследить за всем нереально, всегда есть шанс, что случится «вдруг нежданчик». Учитывая меры безопасности, в обморок никто не падает, но нервишки все таки поигрывают.

                                                                                                А пускай опрос проведут, кто сколько нервничает во время таких тренировок.
                                                                                                  +2
                                                                                                  Вообще, если говорить, про нервы, то первое время было волнительно, ну и для людей у которох это в первый раз, наверное тоже. Когда это налаженный и управляемый процесс, то нервничать нечего, надо думать головой :-)
                                                                                                    0
                                                                                                    То есть когда что-то начинает идти «не по плану», вы совсем не нервничаете!?
                                                                                                      0
                                                                                                      Бывает 2 вида «не по плану»:
                                                                                                      1. Вполне предсказуемый отказ какой-либо системы, ради которого и проводится тест. Умерла какая то железка, софт, сервис. Обычно такие тесты проходят без проблем, а тут вдруг shit happens. Есть аварийный план, согласно которого производится диагностика, исправление ситуации, работы по недопущению подобного в будущем, повторные тесты.
                                                                                                      2. Абсолютный форс-мажор. Сгорел (к примеру) самый главный распределительный щит питания серверной, который от зарезервированных вводов, подстрахованных ДГУ обеспечивает работу всей системы. В этом случае уже быстро ничего не сделаешь, т.к. авария выходит за рамки прогнозируемых рисков. В этом случае оповещается начальство, ответственность переходит на уровень выше, поднимаются аварийные службы, начинаются работы по восстановлению. Особенно волноваться некогда, стараешься тщательнее расчитать каждый следующий шаг, чтобы не усугубить последствия. Мозг в таких случаях активизируется, адреналина в крови добавляется, но на уровне велогонки или спортивной игры. Сделать быстро, сделать качественно, сделать правильно. Чтобы коленки тряслись или сильно волновался не было ни разу. Все понятно, работай и не парься. Если не понятно, диагностика до понимания проблемы, а дальше опять работа по планомерному поднятию системы. Форс-мажор, чего сильно переживать?
                                                                                              0
                                                                                              Вот кстати похожая статья о том как разработчики тестируют свои системы в продакшене — queue.acm.org/detail.cfm?id=2353017
                                                                                                +2
                                                                                                Спасибо за статью, очень интересно читать :)
                                                                                                Не планируете написать серию статей (или одну, но большую!) с экскурсом в свое прошлое по поводу становления такой системы отказоустойсти? Со всякими своими best practices и white papers?
                                                                                                  +1
                                                                                                  Спасибо за статью!
                                                                                                  Было бы очень интересно почитать, какие инструменты типа Service Manager для управления IT-инфраструктурой используются в Яндексе.
                                                                                                    0
                                                                                                    true Outage Driven Infrastructure
                                                                                                    tweettunnel.com/DEVOPS_BORAT

                                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                    Самое читаемое