Как стать автором
Обновить

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

Яндекс когда-нибудь начнет нормально работать в US и Южной Амеркие? Пинг в 150 мс — это тотальный ужас. Неужели так обязательно гнать трафик через половину земного шара в Москву?
Когда-нибудь — начнет.
Тогда когда-нибудь начну пользоваться Яндексом :)
Потому что даже из Питера Яндекс откликается медленнее «заокеанского» 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 поставил свое железо не так далеко от моего дома, а родной Яндекс не соизволил.
А каким таким сервисом вы пользуетесь, что вам для него настолько критичен пинг?
Я Почтой :( Он не критичен, он причина — половина страниц сваливалась в «Превышено время ожидания ответа сервера».
Это, безусловно, ненормально. Если проблема повторяется и вы готовы поучаствовать в диагностике, напишите мне на ivlad@yandex-team.ru, я попрошу коллег разобраться.
НЛО прилетело и опубликовало эту надпись здесь
Просто у вашего провайдера стоит такая коробка: peering.google.com/about/ggc.html

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

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

GGC это не коробка, это полстойки серверов.
НЛО прилетело и опубликовало эту надпись здесь
У нас стоят кеши в SPB-IX.
У меня противоположная ситуация:
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
> Пинг в 150 мс — это тотальный ужас.

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

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
Очень подозрительный трейс. У вас до собственного роутера уже 100 мс. А дальше значения сильно скачут. Похоже, что-то сильно нагружало вашу сеть или роутер во время измерений.
НЛО прилетело и опубликовало эту надпись здесь
К тому же свет в оптоволокне распространяется не прямолинейно, соотв. времени нужно даже больше…
НЛО прилетело и опубликовало эту надпись здесь
Оу…
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 мсек


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

Кстати, у Yandex есть свой публичный Looking Glass? Для отладки проблемы надо бы оба трейса, как от клиента до Я, так и от Я до клиента.
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]
Ваш провайдер заворачивает трафик через спутник:

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 уже выглядит не столь пугающей.
Ваш провайдер заворачивает трафик через спутник
Правда что ли??? А название других узлов вас не смутило??
Например bgw1-gi0-0-21.tech.kamchatka.ru
Ваш провайдер заворачивает трафик через спутник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

crontab:

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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