Comments 115
Яндекс когда-нибудь начнет нормально работать в US и Южной Амеркие? Пинг в 150 мс — это тотальный ужас. Неужели так обязательно гнать трафик через половину земного шара в Москву?
UFO just landed and posted this here
Тогда когда-нибудь начну пользоваться Яндексом :)
Потому что даже из Питера Яндекс откликается медленнее «заокеанского» Google:
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 поставил свое железо не так далеко от моего дома, а родной Яндекс не соизволил.
А каким таким сервисом вы пользуетесь, что вам для него настолько критичен пинг?
Просто у вашего провайдера стоит такая коробка: peering.google.com/about/ggc.html
Она и пингуется. Увы, в этой коробке есть не весь интернет, поэтому когда вы задаете гуглу запрос, она всё равно ходит в настоящую сеть гугла, с уже заметно большим пингом.
Она и пингуется. Увы, в этой коробке есть не весь интернет, поэтому когда вы задаете гуглу запрос, она всё равно ходит в настоящую сеть гугла, с уже заметно большим пингом.
Не совсем у провайдера, оно стоит в точке обмена трафиком (Pirix) и дает отличное латенси, например, до Google DNS :)
Да и GGC — это несколько иное, это чисто провайдерская коробка, которую Google ставит начиная с XX гигабит трафика на Youtube с определенного провайдера и позволяет дать суперскую скорость, да!
Да и GGC — это несколько иное, это чисто провайдерская коробка, которую Google ставит начиная с XX гигабит трафика на Youtube с определенного провайдера и позволяет дать суперскую скорость, да!
У меня противоположная ситуация:
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
UFO just landed and posted this here
Оу…
Заметьте, и ведь мой пинг из России…
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? Для отладки проблемы надо бы оба трейса, как от клиента до Я, так и от Я до клиента.
Кстати, у 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]
Трассировка маршрута к 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]
Ваш провайдер заворачивает трафик через спутник:
РТКОММ — провайдер, обладающий спутниковыми каналами.
Сайт kriljon.ru/ немногословен, но имеет нужную информацию: Спутниковая компания ООО «Крильон-САТ»
Разница между пингом до седьмого хопа на Сахалине и до mail.yandex.ru уже выглядит не столь пугающей.
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
Не вижу причин, по которым наличие пограничного маршрутизатора с гигабитным интерфейсом у вашего провайдера должно было меня смутить. Его наличие никак не влияет на наличие спутникового моста от Камчатки до Сахалина у рткомм.
UFO just landed and posted this here
Удивила цифра про 5% с дисками. С чем это связано?
Возможно с резким изменением силы магнитного поля, когда сеть обесточивается и поле просто пропадает.
UFO just landed and posted this here
Когда неожиданно пропадает питание, диску не всегда хватает энергии, чтобы запарковать головки. Если головки не паркуются, то могут испортить поверхность диска. Например, это одна из причин
если я правильно понимаю, то сейчас у всех дисков парковка идет чисто потоком набегающего воздуха.
а так, имхо тут в первую очередь вопрос о контактах будет и плюс электроника. мне рассказывали как-то про SCSI полку, оттарабанившую лет 6 без единого косяка, но в которой ни один диск не стартовал после отключения питания — при включении у всех дисков сдохли мозги.
а так, имхо тут в первую очередь вопрос о контактах будет и плюс электроника. мне рассказывали как-то про SCSI полку, оттарабанившую лет 6 без единого косяка, но в которой ни один диск не стартовал после отключения питания — при включении у всех дисков сдохли мозги.
Кто-то из производителей дисков хвастался, что использует кинетическую энергию диска для генерации электроэнергии, которая используется, чтобы сбросить кэш на диск и запарковать головки.
Погодите-погодите. Какое еще «неожиданно пропадает питание»? Это на десктопике у меня возможно, а у вас вон целый цех с ДГ!
Так что сказали А, говорите и Б — откуда 5% отказов? :)
Так что сказали А, говорите и Б — откуда 5% отказов? :)
ХЗ, но суровая правда. Если сотня дисков непрерывно крутится пол года-год, а потом её вырубить и врубить назад, то действительно несколько штук умрут либо сразу, либо в течении очень короткого времени. Не знаю, как насчёт 5% отказов, но процент-два будет. Лично проверял. Возможно дело как раз в механике задействованной при парковке/разгоне, которая тоже подвержена износу при движении головки, но может неиспользоваться чуть ли не годами — до моменты остановки диска.
Более того, ещё вертояность отказов в обычной электронике повышается, что уж совсем удивительно.
Более того, ещё вертояность отказов в обычной электронике повышается, что уж совсем удивительно.
Вырубить нормально, т.е без выдергивания питания в момент сброса кэша?
А это к вас на каком примерно кол-ве дисков воспроизводится, ну порядок?
Интересно.
А это к вас на каком примерно кол-ве дисков воспроизводится, ну порядок?
Интересно.
Вырубить нромально можно как раз дескоп, это просто. А вот вырубить быстро несколько тысяч серверов сложнее. Хотя бы потому, что не у всех есть ipmi (legacy). C ipmi проще, конечно же, но и то бывают исключения, что сервер по каким-то причинам не потушился.
Вырубить выключением питания. Все критические задачи конечно завершаются, но ОС проболжает работать. На количестве примерно сотня. Эффект наблюдается если система длительное время проработала — т.к. несколько месяцев гоняем не выключая. А потом выключаем. И тогда несколько дисков могут запросто не включиться. Система промышленная — там довольно жарко и вибрации всякие (при том, что компьютеры конечно же с активным охлаждением, на аамортизаторах и т.п.).
При этом, я даже не могу вспомнить ни одного «горячего» (т.е. во время работы) отказа — или не включается, или мрёт буквально после включения (там диагностика всякая крутилась до начал аработы системы).
При этом, я даже не могу вспомнить ни одного «горячего» (т.е. во время работы) отказа — или не включается, или мрёт буквально после включения (там диагностика всякая крутилась до начал аработы системы).
Ну, несколько месяцев это не много. Хотя бы год — уже можно о чем-то говорить. Но раз у вас какая-то специфика (вибрации, жара), то «не интересно». Просто потому, что у вас необычные условия. Речь всё-таки про обычную среднестатистическую серверную.
При этом, я даже не могу вспомнить ни одного «горячего» (т.е. во время работы) отказа
Обычное дело. Пусковые токи довольно ощутимо бьют по железу. При постоянной работе с нормальным охлаждением и питанием железу намного комфортнее.
Но HDD изнашивается и по механике, и по магнитному слою на блинах, так что для них нормально помирать просто так в процессе работы.
Ну вот пример из жизни: сертифицированный коммерческий ЦОД. Два луча питания, SLA, все дела. И тут однажды — бац! — один из источников питания от уважаемой фирмы ловит программную ошибку и считает своим долгом выключиться. Ну, допустим, имеет право, пока есть второй луч.
Но источник на втором луче смонтирован/настроен с ошибкой и воспринимает увеличившуюся нагрузку как ток короткого замыкания и предупредительно выключает второй луч.
Кстати, софтовая бага повторилась и в другом ЦОДе, другого владельца и полностью независимого от первого. Но там второй луч уже не падал.
Так что внезапно электропитание пропасть вполне, увы, может. До дизелей в этом случае не доходит, т.к. дизели реагируют на пропадание входящего напряжения, а отключение произошло уже непосредственно перед стойками.
Но источник на втором луче смонтирован/настроен с ошибкой и воспринимает увеличившуюся нагрузку как ток короткого замыкания и предупредительно выключает второй луч.
Кстати, софтовая бага повторилась и в другом ЦОДе, другого владельца и полностью независимого от первого. Но там второй луч уже не падал.
Так что внезапно электропитание пропасть вполне, увы, может. До дизелей в этом случае не доходит, т.к. дизели реагируют на пропадание входящего напряжения, а отключение произошло уже непосредственно перед стойками.
Очень просто — сдыхает все, что «планировало» сдохнуть в недалеком будущем.
Старт-стоп — это всегда наиболее «отказоемкая» фаза для любого оборудования. Причин этому несколько:
— Остановка и последующий запуск движущихся частей. К примеру, кулер с умирающим мотором может долго крутиться на постоянных оборотах, а вот набрать их после отключения — уже нет.
— Температурный перепад (охлаждение после остановки, потом нагрев при выходе на режим). Микротрещины пайки, вздутия конденсаторов, плохой контакт разъемов — все идет сюда.
— Повышенная нагрузка после старта. Пока прогреваются кэши или поднимаются виртуалки — те же диски испытывают нагрузку, иногда в разы превышающую рабочую. А если диск в это время вылетает — то оставшиеся принимают и стартовый лоад, и ребилд массива, если он есть. Проблемы с охлаждением, если они есть — тоже могут дать о себе знать в этот момент.
— Повышенная электрическая нагрузка. Массовый стартап может просадить даже сеть во всем ДЦ, а в условиях конкретных систем это может вылиться, к примеру, в неспособность «поношенного» блока питания дисковой полки раскрутить пару десятков дисков одновременно (а стартовые токи могут в разы превышать рабочие). При этом в нормальном режиме его вполне хватало.
В норме железка проработала бы еще несколько дней-недель-месяцев, но один из этих факторов может легко «добить» ее именно в момент массового отключения-включения. А если железок тысячи, то и число умерших будет приличным.
Старт-стоп — это всегда наиболее «отказоемкая» фаза для любого оборудования. Причин этому несколько:
— Остановка и последующий запуск движущихся частей. К примеру, кулер с умирающим мотором может долго крутиться на постоянных оборотах, а вот набрать их после отключения — уже нет.
— Температурный перепад (охлаждение после остановки, потом нагрев при выходе на режим). Микротрещины пайки, вздутия конденсаторов, плохой контакт разъемов — все идет сюда.
— Повышенная нагрузка после старта. Пока прогреваются кэши или поднимаются виртуалки — те же диски испытывают нагрузку, иногда в разы превышающую рабочую. А если диск в это время вылетает — то оставшиеся принимают и стартовый лоад, и ребилд массива, если он есть. Проблемы с охлаждением, если они есть — тоже могут дать о себе знать в этот момент.
— Повышенная электрическая нагрузка. Массовый стартап может просадить даже сеть во всем ДЦ, а в условиях конкретных систем это может вылиться, к примеру, в неспособность «поношенного» блока питания дисковой полки раскрутить пару десятков дисков одновременно (а стартовые токи могут в разы превышать рабочие). При этом в нормальном режиме его вполне хватало.
В норме железка проработала бы еще несколько дней-недель-месяцев, но один из этих факторов может легко «добить» ее именно в момент массового отключения-включения. А если железок тысячи, то и число умерших будет приличным.
Интересно, а планируются ли учения N-2? Ведь чем больше датацентров, тем больше (теоретически) вероятность отказа двух одновременно.
Пока не планируются, это удорожает стоимость проектов. На моей практике было всего два случая, когда одновременно были аварии в двух датацентрах. Кстати, мы выживали и продолжали работать :-)
«Извините, сервис временно недоступен
Ваше последнее действие не выполнено.
Попробуйте повторить его позднее».
Это тоже часть учений? Причем, по какому-то злому року, этот сервис недоступен гораздо чаще, чем хотелось бы :(
Если что — я об Яндекс.Закладках
Ваше последнее действие не выполнено.
Попробуйте повторить его позднее».
Это тоже часть учений? Причем, по какому-то злому року, этот сервис недоступен гораздо чаще, чем хотелось бы :(
Если что — я об Яндекс.Закладках
Нет, это не часть учений.
kukutz tvt, а предупредить заранее об этой части «не учений» возможно было? В интернете нигде информации нет, на вики информации нет, на почту (Яндекс) уведомлений тоже не было, ticket 14120122401039313 — пока что молчат, вот сижу и думаю, когда мне начинать паниковать? В пятницу вечером можно будет напиваться?
Это же скучно, может так:
А то у вас все распланировано, и всё такое, жить надо веселее :)
crontab:
0 * * * * /home/admin_at_yandex/make_random_issue_in_random_data_center.sh
А то у вас все распланировано, и всё такое, жить надо веселее :)
А каким образом вы боретесь с неконсистентностью данных? Скажем, поднимается датацентр, включается в работу, а данные уже рассинхронизированы. Как перенаправляете запросы, каким образом реагируете на непредсказуемую задержку в этом случае? Особенно интересно, каким образом все восстанавливается в случае географически удаленных датацентров.
Происходит примерно следующим образом: после включения датацентра смотрим на консистентность данных тоже. Конечно делается это не вручную, а с помощью специальных программ. Пока данные в отключенном датацентре не станут консистентыми в работу он не включается. Например, сервера прикрыты firewall пока данные на slave server mysql не будут синхронизированы с slave серверами в других ДЦ.
Датацентровые линки, конечно, помогают.
Датацентровые линки, конечно, помогают.
Стараемся хранить данные в тех СУБД, которые умеют переживать отключение master'а и автоматически синхронизоваться. Какие именно — зависит от конкретного сервиса. Часто можно обойтись key value хранилищем. В некоторых сервисах реализованы избыточные вычисления: одни и те же данные обрабатываются на нескольких машинах, забирать можно с любой. А какие-то задачи можно вообще условно считать stateless: при запуске сервис подгрузит свежие данные из низлежащих сервисов и начнет работать.
киску жалко
Ой, 5 хабов у топика, оказывается, уже может быть. А при создании всё ещё пишут «Чтобы увеличить аудиторию публикации, выберите два дополнительных тематических хаба».
А не планировали тестровать обесточивание с бОльшей редкостью? эдак раз в пол года для каждого ДЦ?
А можно спустя 5 лет, я все-таки увижу фотку того самого сервака с временем аптайм в… уже 15 лет?
я хорошо себя вел в этом году, могу я получить подарок?
спасибо
я хорошо себя вел в этом году, могу я получить подарок?
спасибо
Обесточивание ДЦ именно в формате выключения по питанию происходит достаточно редко, так как операция дорогая, как я и писала. Оно необходимо только в случае, когда происходят работы на энергетическом оборудовании.
Если под обесточиванием подразумеваются учения, то так как датацентров несколько, то получается, что в среднем для каждого датацентра учения происходят с бОльшей редкостью.
Ну и надо учитывать, что мы, например, не учим их на праздниках, до них, сразу после них.
Регулярность необходима — это залог того, что в нужный момент, во время аварии, когда контролировать ситуацию в разы сложнее, у нас все сработает.
Если под обесточиванием подразумеваются учения, то так как датацентров несколько, то получается, что в среднем для каждого датацентра учения происходят с бОльшей редкостью.
Ну и надо учитывать, что мы, например, не учим их на праздниках, до них, сразу после них.
Регулярность необходима — это залог того, что в нужный момент, во время аварии, когда контролировать ситуацию в разы сложнее, у нас все сработает.
Во, а такой наглый вопрос можно закинуть:
Как в яндексе ведется контроль живости хардов? Только по тому, как они мрут? По тому, как винт отдает по смарту, что ему скоро будет TEC? По постоянному анализу смарта? По тому, что говорят рейды, в настройках которых вписан переодический verify массивов? Отдано на попечение чей-либо СХД?
Как в яндексе ведется контроль живости хардов? Только по тому, как они мрут? По тому, как винт отдает по смарту, что ему скоро будет TEC? По постоянному анализу смарта? По тому, что говорят рейды, в настройках которых вписан переодический verify массивов? Отдано на попечение чей-либо СХД?
В условиях выживания N-1 ДЦ крайне редко имеет смысл контролировать живость отдельно взятого HDD.
Если положить с пробором на хоть какой-то контроль, то можно налететь на прикол, когда в течении 1-2 недель сильно помрут кучи хардов в двух ДЦ, что не есть вери гуд. Плюс в случае с брендовыми решениями можно налететь на партию слегка некошерных дисков, а если при этом положить болт ещё дальше, то можно её распределить между двумя ДЦ причем так, что партия целиком окажется на двух дублирующих друг-друга серверах.
UFO just landed and posted this here
на последнем фото коммутаторы Extreme? :)
серверА
ну зачем вы так?
ну зачем вы так?
А имитировать пропадания питания на всех ввода не пробовали? Был свидетелем, когда в Даталайне система запуска ДГУ (ни одного из трех) не сработала, и когда аккумуляторы разрядились, то все выключилось. В другом ДЦ (KIAE-House) переключатель вводов не сработал или сработал неверно, после того как один отключился.
Откуда взялась цифра про 5% дисков? Это на глаз или расчеты?
Сервера не включатся по массе причин — RAID не определится, POST-тест не пройдет, память не проверится. И все это произойти может разово — после ребута все встанет. А блоки питания — порой им надо состоять с выключенным шнуром минут 20-30 и они заработают. Я так понимаю, конденсаторы разряжаются и снова готов к работе.
Что касаемо персонала для включения. Есть же Wake-on-LAN. Есть управляемые розетки. KVM, spare-диски иметь в массивах. Думаю, можно сделать ДЦ где не будет нужны remote hands. Вернее, я даже видел что-то подобное у продвинутых айтишников.
Откуда взялась цифра про 5% дисков? Это на глаз или расчеты?
Сервера не включатся по массе причин — RAID не определится, POST-тест не пройдет, память не проверится. И все это произойти может разово — после ребута все встанет. А блоки питания — порой им надо состоять с выключенным шнуром минут 20-30 и они заработают. Я так понимаю, конденсаторы разряжаются и снова готов к работе.
Что касаемо персонала для включения. Есть же Wake-on-LAN. Есть управляемые розетки. KVM, spare-диски иметь в массивах. Думаю, можно сделать ДЦ где не будет нужны remote hands. Вернее, я даже видел что-то подобное у продвинутых айтишников.
UFO just landed and posted this here
Понятно.
Но предположу, что это синтетические тесты, к боевой ситуации не совсем имеющие отношения.
Но предположу, что это синтетические тесты, к боевой ситуации не совсем имеющие отношения.
Если всетаки почитать статью, то там упоминаются случаи когда датацентры целиком отключали по питанию. Это разве не «боевая ситуация» или думаете кошка в трансформаторе была засланная?
Кошка в трансформаторе была не засланная. Она была синтетическая :)
Я это воспринял как историю о стандартном дизастере, который постигает многие (или все ДЦ). Но мы вроде про тесты говорим.
Да и не было сказано, что тогда произошло — все попадало или штатно переключилось на другой ввод и перестало работать.
Да и не было сказано, что тогда произошло — все попадало или штатно переключилось на другой ввод и перестало работать.
Кстати, я и заголовок воспринял, как отключение по питанию. Связность это конечно важно, но это не так страшно, как падение по питанию всего зала.Мне приходилось переживать подобное в пору работы в датацентрах.
Ощущение тишины в датацентре поражает.
А еще напрягает ситуация, когда идет перегрев тотальный и обстановка напоминает, рассказ Житкова про контрабандную перевозку бертолетовой соли. Там был боцман Салерно, который знал, какую «соль» везет корабль.
Ощущение тишины в датацентре поражает.
А еще напрягает ситуация, когда идет перегрев тотальный и обстановка напоминает, рассказ Житкова про контрабандную перевозку бертолетовой соли. Там был боцман Салерно, который знал, какую «соль» везет корабль.
Во-во-во, мне про диски и 5% тоже сразу стало интересно! От гугла есть очень добротная статья как они изучали отказы дисков, хотя в основном с перекосом в SMART мониторинг, что для железных рейдов не актуально. Не думаю, что у яши хватит сил на подобный труд, но хотя бы комментарий к цифре очень интересен.
UFO just landed and posted this here
Согласно статистике гугла, по smart теоретически предсказывается до 30% отказов. Остальные мрут мгновенно или смарт ничего не предсказывал. Про то, когда рейд выкидывает диск, кстати, есть интересная заметка от amarao geektimes.ru/post/92701/. Но вцелом на масштабах яндекса врядли будут гадать на смарте. Рейд подразумевает избыточность и диски, как расходный материал. Чуть сбойнул — пошел вон, никто не будет ждать до последнего. Поэтому, наверное, смарта за реидом и не видно обычно.
LSI — умеет, Adaptec — тоже умел (по крайней мере в до SAS 6Gbps эпохи), прочие не мучал (про софтовые поделки — хз, я этим мусором не занимался)
Для железных рейдов смарт какраз ещё более актуален, в случае софтовой помойки или вообще отдельного диска на осыпание можно отреагировать фразой «нублин, опять пара гигов убилась», а когда raid60 решит между делом выплюнуть три-четыре диска и планомерно скатиться из degraded в dead.
Не совсем понял, что вы хотели этим сказать. RAID подразумевает избыточность дисков, но если у вас одновременно умирает 3-4 диска, то, простите, вам просто очень не повезло. Но это крайне маловероятный случай (про смерть в процессе ребилда мы сейчас не говорим, это отдельная тема).
Честно скажу, что взаимоотношения R-контроллеров со SMART-ами дисков — смотрят они туда или нет, и если да, то на что именно — для меня тайна. Если у вас есть пруфлинки, буду признателен. А теоретизировать я и сам горазд =)
Честно скажу, что взаимоотношения R-контроллеров со SMART-ами дисков — смотрят они туда или нет, и если да, то на что именно — для меня тайна. Если у вас есть пруфлинки, буду признателен. А теоретизировать я и сам горазд =)
А как у вас сервера в смысле отказоустойчивости оборудованы? Интересует: есть ли в машинах зеркалирование дисков (или еще какие-то RAID; если да, то RAID аппаратный или программный), есть ли вторый БП, вторые сетевушки?
Я к тому, что при большом числе серверов вроде как вылет одного сервера не критичен (другие нагрузку подхватят, наверное?), так вот насколько вы сразу тратитесь на резервирование вылетающих компонентов каждого сервера, либо просто считаете, что вылет сервера не смертелен, и брать лишний винты, БП, другое железо бессмысленно, и только удорожает конкретную машину.
Я к тому, что при большом числе серверов вроде как вылет одного сервера не критичен (другие нагрузку подхватят, наверное?), так вот насколько вы сразу тратитесь на резервирование вылетающих компонентов каждого сервера, либо просто считаете, что вылет сервера не смертелен, и брать лишний винты, БП, другое железо бессмысленно, и только удорожает конкретную машину.
Фактически, на сетевом оборудовании, находящемся на периметре дата-центра, мы выключаем виртуальные сетевые интерфейсы, разрывая сетевую связность.
Гасите жестко (ACL с deny any во входящем направлении), или все-таки стараетесь избегать любого рода таймаутов и мягко отзываете анонсы?
Точно ли нет смысла нарушать связность и внутри площадки, чтобы системы перестали друг друга видеть?
UFO just landed and posted this here
Notification при этом уходит?
UFO just landed and posted this here
Я больше про BGP. Ну наверняка уходит notification, и вы экономите сколько-то секунд на обнаружение сбоя (если поднят BFD, то сколько-то миллисекунд, но… не все так делают).
А на предмет частичных сбоев тестируете? К примеру, на площадке отъехал ряд стоек (погасили аплинки до ToR свитчей). Или перестал работать L2 сегмент. Опять же, ЦОДы мрут полностью очень редко, я бы сказал что большинство даунтаймов вызываются вовсе не попаданием метеорита в площадку или ее обесточиванием.
Кстати, тоже повод для статьи. Опишите причины нескольких последних серьезных (минута и более простоя сервиса) сбоев :)
А на предмет частичных сбоев тестируете? К примеру, на площадке отъехал ряд стоек (погасили аплинки до ToR свитчей). Или перестал работать L2 сегмент. Опять же, ЦОДы мрут полностью очень редко, я бы сказал что большинство даунтаймов вызываются вовсе не попаданием метеорита в площадку или ее обесточиванием.
Кстати, тоже повод для статьи. Опишите причины нескольких последних серьезных (минута и более простоя сервиса) сбоев :)
UFO just landed and posted this here
Очень интересная и немного познавательная статья.
По поводу индексации тоже есть вполне логичное объяснение: провокационные запросы, нарушающие статью УК «разжигание межнациональной розни» могли резать специально. Точно так же как резались запросы «массовые убийства женщин и детей в Донецке», «фашисты из АТО подвергают мирных жителей средневековым пыткам», «вторжение украинских войск в Россию» (когда украинские военные с оружием в руках сотнями переходили нашу границу).
По поводу индексации тоже есть вполне логичное объяснение: провокационные запросы, нарушающие статью УК «разжигание межнациональной розни» могли резать специально. Точно так же как резались запросы «массовые убийства женщин и детей в Донецке», «фашисты из АТО подвергают мирных жителей средневековым пыткам», «вторжение украинских войск в Россию» (когда украинские военные с оружием в руках сотнями переходили нашу границу).
UFO just landed and posted this here
Такую техническую информацию никто никогда не разгласит, это информация ограниченного доступа для служебного пользования. Я свечку не держал, доступа к такому списку нет, но уверен, что режется часть инфы по созданию взрывчатки и прочих пособиях террористов, сервера тика «кавказ», педофилия, ядерное вооружение, нацистские сайты.
Сейчас такого ответа, вероятно, не будет, т.к. вы его задаёте сейчас, а не летом. Если вы сейчас знаете какие-то запросы, по которым не находится то, что по вашему мнению должно — напишите.
UFO just landed and posted this here
Зачем писать вопросы, не требующие ответа? Есть законы РФ, конкретно УК. Яндекс ведет свою деятельность на территории России и обязан подчиняться ее законодательству. Как гугл и рамблер подчиняются американскому законодательству. Есть закон, яндекс старается работать в его рамках, что в этом удивительного?
На support@yandex.ru.
Я вам предлагаю назвать такие вечера «Грандиозные Дебаг». По сути вы ведь именно дебажите свои сервисы, таким образом. Процесс невероятный… В отличии от обычного дебага знакомого каждому программисту, у вас уровень адреналина на «вечеринках» просто зашкаливает.
Подозреваю, что уровень адреналина остается в пределах нормы. Есть согласованный план работ, ответственные. Процедура обкатанная, оборудование зарезервировано с запасом. В случае форс-мажоров, есть план восстановительных работ. Каждый форс-мажор изучается экспертами для исключения их в будущем. Как с авиацией, каждая авария делает полеты еще более безопасными за счет внедрения новых мер. У инженеров процедура уже отработанная, месяцами проходит без сбоев, чего бы им волноваться?
Учитывая, что сервисы постоянно развиваются, и уследить за всем нереально, всегда есть шанс, что случится «вдруг нежданчик». Учитывая меры безопасности, в обморок никто не падает, но нервишки все таки поигрывают.
А пускай опрос проведут, кто сколько нервничает во время таких тренировок.
А пускай опрос проведут, кто сколько нервничает во время таких тренировок.
Вообще, если говорить, про нервы, то первое время было волнительно, ну и для людей у которох это в первый раз, наверное тоже. Когда это налаженный и управляемый процесс, то нервничать нечего, надо думать головой :-)
То есть когда что-то начинает идти «не по плану», вы совсем не нервничаете!?
Бывает 2 вида «не по плану»:
1. Вполне предсказуемый отказ какой-либо системы, ради которого и проводится тест. Умерла какая то железка, софт, сервис. Обычно такие тесты проходят без проблем, а тут вдруг shit happens. Есть аварийный план, согласно которого производится диагностика, исправление ситуации, работы по недопущению подобного в будущем, повторные тесты.
2. Абсолютный форс-мажор. Сгорел (к примеру) самый главный распределительный щит питания серверной, который от зарезервированных вводов, подстрахованных ДГУ обеспечивает работу всей системы. В этом случае уже быстро ничего не сделаешь, т.к. авария выходит за рамки прогнозируемых рисков. В этом случае оповещается начальство, ответственность переходит на уровень выше, поднимаются аварийные службы, начинаются работы по восстановлению. Особенно волноваться некогда, стараешься тщательнее расчитать каждый следующий шаг, чтобы не усугубить последствия. Мозг в таких случаях активизируется, адреналина в крови добавляется, но на уровне велогонки или спортивной игры. Сделать быстро, сделать качественно, сделать правильно. Чтобы коленки тряслись или сильно волновался не было ни разу. Все понятно, работай и не парься. Если не понятно, диагностика до понимания проблемы, а дальше опять работа по планомерному поднятию системы. Форс-мажор, чего сильно переживать?
1. Вполне предсказуемый отказ какой-либо системы, ради которого и проводится тест. Умерла какая то железка, софт, сервис. Обычно такие тесты проходят без проблем, а тут вдруг shit happens. Есть аварийный план, согласно которого производится диагностика, исправление ситуации, работы по недопущению подобного в будущем, повторные тесты.
2. Абсолютный форс-мажор. Сгорел (к примеру) самый главный распределительный щит питания серверной, который от зарезервированных вводов, подстрахованных ДГУ обеспечивает работу всей системы. В этом случае уже быстро ничего не сделаешь, т.к. авария выходит за рамки прогнозируемых рисков. В этом случае оповещается начальство, ответственность переходит на уровень выше, поднимаются аварийные службы, начинаются работы по восстановлению. Особенно волноваться некогда, стараешься тщательнее расчитать каждый следующий шаг, чтобы не усугубить последствия. Мозг в таких случаях активизируется, адреналина в крови добавляется, но на уровне велогонки или спортивной игры. Сделать быстро, сделать качественно, сделать правильно. Чтобы коленки тряслись или сильно волновался не было ни разу. Все понятно, работай и не парься. Если не понятно, диагностика до понимания проблемы, а дальше опять работа по планомерному поднятию системы. Форс-мажор, чего сильно переживать?
Вот кстати похожая статья о том как разработчики тестируют свои системы в продакшене — queue.acm.org/detail.cfm?id=2353017
Спасибо за статью, очень интересно читать :)
Не планируете написать серию статей (или одну, но большую!) с экскурсом в свое прошлое по поводу становления такой системы отказоустойсти? Со всякими своими best practices и white papers?
Не планируете написать серию статей (или одну, но большую!) с экскурсом в свое прошлое по поводу становления такой системы отказоустойсти? Со всякими своими best practices и white papers?
Спасибо за статью!
Было бы очень интересно почитать, какие инструменты типа Service Manager для управления IT-инфраструктурой используются в Яндексе.
Было бы очень интересно почитать, какие инструменты типа Service Manager для управления IT-инфраструктурой используются в Яндексе.
true Outage Driven Infrastructure
tweettunnel.com/DEVOPS_BORAT
tweettunnel.com/DEVOPS_BORAT
Sign up to leave a comment.
Как и для чего Яндекс отключает собственные дата-центры