Comments 69
Всё хорошо, что хорошо кончается.
+6
А еще в таких ситуациях инженер(ы), который проводит переключение, получает отличный опыт. Даже если проблема оказывается простой и путь решения тривиальный — такой опыт въедается в память и там остается. Решение задач под давлением ответственности, возможно финансовой, действует почти как адреналин, только в данном случае соображаешь быстрее. Такой опыт считаю крайне полезным, и для многих это редкость, искренне рад за тех, у кого это наоборот.
Про вашу компанию ничего не знаю, но удачи!
Про вашу компанию ничего не знаю, но удачи!
+5
Почти ничего не понял, только к концу поста понял, что речь о сети дата-центров (или таки неправильно понял?), но радует, что российские ИТ-компании не стыдятся сообщать в паблике о проблемах.
+7
Не примите за критику или приговор. Просто хотел поделится внутренним голосом при чтении статьи.
Проводили ли вы лабораторные тесты по интеграции опорного маршрутизатора и коммутаторов доступа до запланированных работ? Вообще тесты на интеграцию были вне продакшина?
Был ли у вас MOP (Method Of Procedure) (он помогает продумать каждый шаг и сценарий до того как хоть что-то начать делать)?
Был ли у вас Roll Back план? Задавались ли вы вопросом: «что мы будем делать если что-то пойдёт не так?» «как оборудование себя поведёт днем когда трафик возрастёт в разы и как всё вернуть на место если новое железо не справится с наплывом»
Когда мы работали в T-mobile USA у опреционщиков были телефоны с sim картами AT&T. Логика проста если во время работ накрыли свою сеть чтобы можно было созвониться и решить непредвиденный сценарий. В вашем случае полагаю что можно было купить несколько sim карт, номера «Антикризисного центра» скинуть в [twitter,facebook,g+,blogspot,habr] и посадить людей которые сообщили бы об серьёзной аварии и невозможности отвечать по обычному телефону. Costumer frustration создался от того что людей игнорируют (даже если по техническим причинам), а не от того что там что-то сломалось.
Простите но петля это ошибка дизайна. Когда всё и так «горит» нужно всё «поставить на место как было», и переосмыслить дизайн а не заниматься troubleshooting-ом во время outage-a.
Хочу сказать что я восхищаюсь вашей смелостью и открытостью в освящении событий. В России к сожалению такое не часто увидешь.
В 02:00 по плану мы начали работы с переноса роутинга клиентов на другой роутер и переключения access-свитчей.
Во время подключения access-свитчей также выяснилось, что Cisco Catalyst не очень хотят дружить с оборудованием Juniper и пришлось прыгать с бубном консолью около каждого свитча.
Разные мировоззрения производителей Juniper Networks, Extreme Networks и Cisco Systems на, казалось бы, полностью стандартизованные протоколы STP и MPLS оставили без связи часть клиентов.
Проводили ли вы лабораторные тесты по интеграции опорного маршрутизатора и коммутаторов доступа до запланированных работ? Вообще тесты на интеграцию были вне продакшина?
Однако уже после переноса подключений и начала демонтажа роутера Cisco Catalyst начались странные проблемы с резервным свитчём: ему стало мало памяти и CPU периодически был сильно загружен.
Был ли у вас MOP (Method Of Procedure) (он помогает продумать каждый шаг и сценарий до того как хоть что-то начать делать)?
Был ли у вас Roll Back план? Задавались ли вы вопросом: «что мы будем делать если что-то пойдёт не так?» «как оборудование себя поведёт днем когда трафик возрастёт в разы и как всё вернуть на место если новое железо не справится с наплывом»
Из-за проблем с access-свитчами наш сайт, а также телефония временно были выведены из работоспособности. Этим-то и вызваны жалобы клиентов, что они не могли до нас дозвониться. Но довольно скоро проблема решилась и всё заработало.
Когда мы работали в T-mobile USA у опреционщиков были телефоны с sim картами AT&T. Логика проста если во время работ накрыли свою сеть чтобы можно было созвониться и решить непредвиденный сценарий. В вашем случае полагаю что можно было купить несколько sim карт, номера «Антикризисного центра» скинуть в [twitter,facebook,g+,blogspot,habr] и посадить людей которые сообщили бы об серьёзной аварии и невозможности отвечать по обычному телефону. Costumer frustration создался от того что людей игнорируют (даже если по техническим причинам), а не от того что там что-то сломалось.
Например, образовалась «петля», поймать которую удалось не сразу. Ловля петли отняла дополнительное время. Петля зацепила часть клиентов и в других наших дата-центрах.
Простите но петля это ошибка дизайна. Когда всё и так «горит» нужно всё «поставить на место как было», и переосмыслить дизайн а не заниматься troubleshooting-ом во время outage-a.
Хочу сказать что я восхищаюсь вашей смелостью и открытостью в освящении событий. В России к сожалению такое не часто увидешь.
+27
UFO just landed and posted this here
Да ладно, что люди приходят на хабр рассказать как все плохо, это далеко не всегда так.
Например, меня лично, все эти саксесс стори как все у всех хорошо — малость задолбали, хочется МЯСА :)
Когда все рушится и как это исправляют.
Вот например, тут недавно Альфабанк пытался обновить все свои интернет сервисы, ночью начали, утром сообщили что нужно откатыватся, и потом еще почти день возвращали все назад.
Что вам было бы интереснее узнать — как быстро они обновились, или почему все запоролось, почему не получилось быстро решить проблему и как они откатывались обратно?
Второе на мой взгляд интереснее.
Например, меня лично, все эти саксесс стори как все у всех хорошо — малость задолбали, хочется МЯСА :)
Когда все рушится и как это исправляют.
Вот например, тут недавно Альфабанк пытался обновить все свои интернет сервисы, ночью начали, утром сообщили что нужно откатыватся, и потом еще почти день возвращали все назад.
Что вам было бы интереснее узнать — как быстро они обновились, или почему все запоролось, почему не получилось быстро решить проблему и как они откатывались обратно?
Второе на мой взгляд интереснее.
+2
Costumer frustration создался от того что людей игнорируют (даже если по техническим причинам), а не от того что там что-то сломалось.
Золотые слова.
Золотые слова.
+4
У меня «многобайт» ассоциируется с «постоянно лежит». Год назад с него уехали и больше никаких проблем с сетью. А до этого каждый месяц то пинги теряются, то связность нарушается, то вообще лежит. Единственный плюс — дешевле. Но надежность никакая.
Не в обиду вам будет сказано, конечно, но что то проблемы у вас постоянно.
Не в обиду вам будет сказано, конечно, но что то проблемы у вас постоянно.
+1
UFO just landed and posted this here
Jumbo Frames заставили меня несколько часов перегружать то одну железку, то другую;) SSH работал, но некоторые другие протоколы не хотели, т.к. пытались выплюнуть большие пакеты в сеть, и че-то не сразу такое развитие событий пришло на ум…
0
начались странные проблемы с резервным свитчём: ему стало мало памяти и CPU периодически был сильно загружен.
Из-за чего — выяснили?
Разные мировоззрения производителей Juniper Networks, Extreme Networks и Cisco Systems на, казалось бы, полностью стандартизованные протоколы STP и MPLS
Вы что, не тестировали заранее? :) И у вас не было сервисного контракта? Я слышал, у Juniper хорошая поддержка. Прямо-таки бесценная, если одним махом внедряется целая гора непривычных сетевикам железок…
Некоторые свитчи клиентов, подключенных к нашим access-свитчам, также были некорректно настроены и влияли на нашу сеть.
Как? Имели меньший STP приоритет, чем ваши свитчи? Что-то ничего другого, с чем нельзя одним пальцем разобраться в режиме конфигурации порта со стороны провайдера, не могу придумать.
В общем, побольше технических подробностей. Я не ваш клиент, но интересно же :)
+1
UFO just landed and posted this here
Для того чтобы проблем с клиентскими свичами не было нужно настраивать RootGuard на доступе.
Беда в том, что он глушит порт, т.е. все равно требуется пинать клиента, чтобы тот поправил косяк.
0
UFO just landed and posted this here
Почему другие клиенты должны из-за него страдать?
Переизбрание рута STP вызывает маленький дрючок. И если в договоре не было сказано «STP priority не может составлять менее 16384», то как-то некрасиво глушить порт клиента.
Вообще в принципе можно обойтись без STP на границе с клиентом при правильном дизайне и пользоваться даже BPDU Guard
Отключать STP, тем более в ЦОДе, нельзя категорически. BPDU filter (как и portfast) крайне опасен.
blog.ioshints.info/2012/04/stp-loops-strike-again.html
И я однажды с таким столкнулся.
Вдруг клиент каким-то образом объединит бочкой два порта в нагруженном VLANе на том самом жунипере? Все-таки полный процесс STP при link up дает дополнительную безопасность. Без гарантии, конечно, но большинство сценариев покроет. На остальные есть storm control, CoPP и так далее.
0
UFO just landed and posted this here
почему другие клиенты ЦОД должны страдать из-за того что у какого то конкретного клиента что-то не так с оборудованием.
Не должны. Но если в договоре не было сказано про минимальный приоритет, то глушить порт клиента нельзя.
Однако — раньше-то все работало нормально, рут был у хостера. Неужели сетевики не осилили понизить до минимума приоритет жуниперов? :)
По по поду bpdu guard все заивист от того что за устройство с другой стороны, свич или конечный сервер.
BPDU guard всегда должен быть включен, если на порт не должны прилетать BPDU. Однако, он может не успеть сработать. Секунда или две между отправкой BPDU — целая вечность с точки зрения 10G сети.
Про portfast и filter я вам не писал.
Писали. «Обойтись без STP» = «сделать на порту BPDU filter или на VLANe no spanning-tree» (говорю в цискиной терминологии). Тогда свитчу хостера будет плевать, какой приоритет шлет клиент в своих BPDU. В остальных случаях свитчи клиента будут учитываться в топологии, если они шлют BPDU.
0
UFO just landed and posted this here
Обойтись без STP – не собирать схемы при которых он нужен.
Это да. Но это не всегда удается. Как сохранить избыточность? Варианты:
1) mLAG до каждого вышестоящего уровня. Но оно может не поддерживаться. Или поддерживаться только до стеков (один control plane на несколько железок), которые я недолюбливаю. Например, я столкнулся с немалым числом проблем с VSS из пары 6500-х, связанных именно с самим VSS. На нексусах с vPC можно сделать mLAG без объединения мозгов, но это есть только на нексусах.
2) TRILL-образные протоколы. Поддерживается мало где, экзотика.
Есть и что-то вроде fabricpath у жуниперов, но снова — не всегда и не везде, с весьма серьезным ценником.
Я тоже терпеть не могу STP, тоже предпочитаю собирать топологии, где он в штатном режиме ничего не блокирует, но я могу понять людей, у которых нет возможности добиться такого.
0
UFO just landed and posted this here
Я как раз имел ввиду стэкирование на доступе, 3750 либо EX4200 на мой взгляд лучше бы смотрелось.
У меня как-то снесло крышу правильно собранному стеку из 3750-х при вылетании одного из них (подробностей уже не помню). После этого стек решили разобрать. Да, там работает MST в паре зон, блокируя половину аплинков для каждой. Некрасиво? Конечно. Однако, оно ни разу не ломалось.
В общем, технологии класса «один control plane на N девайсов» — это стрёмно. Нексусы собираются в vPC кластер, сохраняя мозги на каждой из железок. Причем есть автоматическая синхронизация конфигов портов, и трафик, прилетевший на один из свитчей и предназначенный int vlan, будет маршрутизироваться именно этим свитчем, не улетая на соседа, который HSRP active. Красиво.
0
Вообще-то в приведённой ссылке как раз более чем убедительно показывается, почему на STP полагаться не стоит. У нас нет дата-центра (городская сеть), но тем не менее STP не используем — проблем от него больше, чем решений.
0
В приведенной ссылке убедительно показывается, что в ЦОДе без колец и с включенным STP подключение нового устройства или банальное объединение двух портов патч-кордом способно вызвать армагеддон.
И опять же, возвращаемся к вопросу о том, что если требуется обеспечить резервирование на L2, то не всегда можно обойтись без блокируемых STP линков. Стеки снижают резервирование, вводя единую точку отказа в виде активного управляющего процессора. Ведь он запросто может заглючить так, что сеть ляжет, но фейловера не произойдет — у меня такое бывало.
И опять же, возвращаемся к вопросу о том, что если требуется обеспечить резервирование на L2, то не всегда можно обойтись без блокируемых STP линков. Стеки снижают резервирование, вводя единую точку отказа в виде активного управляющего процессора. Ведь он запросто может заглючить так, что сеть ляжет, но фейловера не произойдет — у меня такое бывало.
0
Ну и по поводу поддержки:
1) Парни сказали, что долго устраняли петлю. Да, неприятное явление, но обычно 15-и минут на ее разгребание должно хватить. Не знаю, как жуниперы, но те же cat6500 прекрасно отзываются по консоле при лупе — ищется порт, который на 100% загружен на input и либо глушится, либо нужно перейти к устройству за этим портом и повторить операцию. Но у каталистов есть storm control, который позволит сети почти нормально функционировать при петле и будет сразу писать в логи, на какой порт приходит слишком много броадкастов/мультикастов/unknown unicast'ов. Наверняка у жуниперов есть аналогичная технология. Ну не может не быть, иначе я в них разочаруюсь.
Если устранение петли (с личным присутствием в ЦОДе) заняло часы, то тут явно и косяк в дизайне, и недостаточные навыки работы с железом.
2) Еще несколько часов ребята осознавали, что у жуниперов и цисок немного разное понимание слова «MTU» и того, какие заголовки учитываются в нем. Опять же, это не может не быть упомянуто в любой базе знаний саппорта вендора.
Ну а вообще, переходили бы на нексусы 7000 — не столкнулись бы с этими проблемами :) Все-таки 6-тонник действительно устарел и не годится для серьезных ЦОДов (хотя там уже не «2х20Гбит/сек на слот», а поболее, но все равно мало). Нексусы 7k дают 550гб/с на слот.
1) Парни сказали, что долго устраняли петлю. Да, неприятное явление, но обычно 15-и минут на ее разгребание должно хватить. Не знаю, как жуниперы, но те же cat6500 прекрасно отзываются по консоле при лупе — ищется порт, который на 100% загружен на input и либо глушится, либо нужно перейти к устройству за этим портом и повторить операцию. Но у каталистов есть storm control, который позволит сети почти нормально функционировать при петле и будет сразу писать в логи, на какой порт приходит слишком много броадкастов/мультикастов/unknown unicast'ов. Наверняка у жуниперов есть аналогичная технология. Ну не может не быть, иначе я в них разочаруюсь.
Если устранение петли (с личным присутствием в ЦОДе) заняло часы, то тут явно и косяк в дизайне, и недостаточные навыки работы с железом.
2) Еще несколько часов ребята осознавали, что у жуниперов и цисок немного разное понимание слова «MTU» и того, какие заголовки учитываются в нем. Опять же, это не может не быть упомянуто в любой базе знаний саппорта вендора.
Ну а вообще, переходили бы на нексусы 7000 — не столкнулись бы с этими проблемами :) Все-таки 6-тонник действительно устарел и не годится для серьезных ЦОДов (хотя там уже не «2х20Гбит/сек на слот», а поболее, но все равно мало). Нексусы 7k дают 550гб/с на слот.
0
UFO just landed and posted this here
Написано об этом на каждом углу.
Могу предположить, что они просто не ожидали грабель в этом направлении. То есть — недостаток опыта для настолько серьезной миграции.
TAC Cisco, отвечает оперативнее JTAC Juniper
Справедливости ради: у меня при телефонном звонке не удавалось попасть на инженера быстрее чем за 15 минут…
По поводу оборудования, нужно плясать от конкретной задачи
Я исхожу из написанного: «шеститонники всем устраивали, но в какой-то момент стало не хватать емкости на слот». Нексусы — специализированные коммутаторы для ЦОДов, они во многом похожи на IOS устройства вроде каталистов, совместимость на уровне протоколов полная, переучивание недолгое.
0
UFO just landed and posted this here
Я всегда открываю case через сайт.
Только severity 3-4, в переводе «что-то нехорошо, надо как-нибудь неспеша починить». А когда сеть умерла — это severity 1-2, заводятся только по телефону, и оператор сразу переводит звонок на инженера. Теоретически. На практике — пока продиктуешь серийники, пока инженеры разберутся между собой, в чьей зоне ответственности лежит проблема — часики тикают.
0
Из-за чего — выяснили?
Пока разбираемся. Сейчас через него идёт около 8Гбит/сек (половина от той нагрузки, которую он лопатил до этого) и проблем нет.
Вы что, не тестировали заранее? :) И у вас не было сервисного контракта? Я слышал, у Juniper хорошая поддержка. Прямо-таки бесценная, если одним махом внедряется целая гора непривычных сетевикам железок…
У нас есть и сервисная поддержка и next day замена неисправного оборудования. Мы тестировали всё оборудование до ввода в строй. Мало того, оно уже работало включенным в наше кольцо и проблем с ним не было. Даже гоняло через себя пару гигабит трафика с тестовых серверов.
В общем, побольше технических подробностей. Я не ваш клиент, но интересно же :)
Подробности будут в течение рабочей недели. Когда всё окончательно выясним. :-) Разумеется тут о них надо написать, чтобы другие не натыкались на те же грабли.
+3
Однако уже после переноса подключений и начала демонтажа роутера Cisco Catalyst
То есть старое оборудование начали демонтировать в ту же ночь?
0
То есть старое оборудование начали демонтировать в ту же ночь?
Старое оборудование было демонтировано
0
[irony]
Очень нравятся фото панелек оборудования! Чем больше размер бренда, тем лучше. Чем больше лампочек в кадре, тем лучше!
Кстати, почему каждая железка в одном экземпляре, когда можно по 2 в шасси? Подключать клиентов с помощью AE в разные устройства. Проводить апгреды без перерыва сервиса. Экономите?
[/irony]
Выделить из бюджета деньги на MX960 3D и EX8200 и поставить их по технологии plug-and-plug все же мало. Нужно узнать, как они работают, и научиться ими управлять. Жаль мне ваших клиентов, им с вашим администрированием еще жить.
Очень нравятся фото панелек оборудования! Чем больше размер бренда, тем лучше. Чем больше лампочек в кадре, тем лучше!
Кстати, почему каждая железка в одном экземпляре, когда можно по 2 в шасси? Подключать клиентов с помощью AE в разные устройства. Проводить апгреды без перерыва сервиса. Экономите?
[/irony]
Выделить из бюджета деньги на MX960 3D и EX8200 и поставить их по технологии plug-and-plug все же мало. Нужно узнать, как они работают, и научиться ими управлять. Жаль мне ваших клиентов, им с вашим администрированием еще жить.
+1
UFO just landed and posted this here
Софта, но не железа. Многобайт же менял железо недавно как раз. LINX, например, двумя RE не ограничился.
0
UFO just landed and posted this here
Согласен. Учтя эту мысль, но все же решив, что помпезный текст и намек на крутые фото крутого оборудования излишни, комментарий про резервирование разместил в блоке с намеком на иронию.
IMHO, у них есть деньги на это. Их же конкуренты могут позволить себе по 2 MX и EX. Тот же vk.com ставит Нексусы и ЕХы пачками.
IMHO, у них есть деньги на это. Их же конкуренты могут позволить себе по 2 MX и EX. Тот же vk.com ставит Нексусы и ЕХы пачками.
0
То что у конторы есть деньги на такое оборудование, не значит что есть деньги на резервирование.
У нас внутри оборудования всё отрезервировано. То есть в шасси стоят по 3 SCB-E и по 2 RE (для MX) и по 8 SF и 2 RE (для EX). Резервировать сами шасси в некоторых ситуациях невозможно, например, поставить на М9 два MX960 для резервирования друг друга.
0
Я правильно понял, что на шасси там по одной управляющей карте? Ш-ш-шикарно :)
0
Спасибо за то что рассказали что случилось и как решали проблемы а не «Она утонула». Интересно почитать с чем сталкиваются работники ЦОДов.
0
> Все пострадавшие клиенты получат компенсации и приятные бонусы – в этом можно не сомневаться.
М-да? Приятно, конечно, но у нас суточные потери из-за простоя больше чем мы вам в квартал платим…
М-да? Приятно, конечно, но у нас суточные потери из-за простоя больше чем мы вам в квартал платим…
-1
> Из-за проблем с access-свитчами наш сайт, а также телефония временно были выведены из работоспособности. Этим-то и вызваны жалобы клиентов, что они не могли до нас дозвониться.
Именно поэтому в телекому принятно не держать у себя свой сайт и телефоны — чтобы в случае проблем/перенастроек и прочего не потерять связь.
Именно поэтому в телекому принятно не держать у себя свой сайт и телефоны — чтобы в случае проблем/перенастроек и прочего не потерять связь.
0
Можно пример хостингового телекома, который хостит сайт не у себя? :)
А про телефонию, согласен. Можно хотя бы в письме с оповещением давать номера мобильных телефонов саппорта. Или взять какой-нибудь Е1, или IP-телефонию пустить не через свою сеть. Или иметь резервный номер. Вариантов много. И их применяют некоторые хостинговые фирмы в России.
А про телефонию, согласен. Можно хотя бы в письме с оповещением давать номера мобильных телефонов саппорта. Или взять какой-нибудь Е1, или IP-телефонию пустить не через свою сеть. Или иметь резервный номер. Вариантов много. И их применяют некоторые хостинговые фирмы в России.
0
Молодцы, наняли хорошего пиарщика, который серьезный сбой представил в позитиве, заодно прорекламировал как вы растете.
0
Мы не нанимали пиаршика. Статью написал я сразу по горячим следам. Чтобы и пострадавшим клиентам и сообществу IT было понятно что у нас случилось. А то обычно после аварий у телекомов на форумах появляются сообщения типа «я в саппорт своего хостера звонил… ну они в этом же дата-центре стоят… хостер сказал, что на дата-центр упал метеорит» или «я не клиент дата-центра, но слышал, что там гендиректор сошёл с ума и расстрелял из автомата сервера». :-)
0
Хорошо, что по горячим следам осветили информацию. а не замалчивали или пытались пустить в глаза. ок
0
traceroute to mnogobyte.ru (77.220.184.171), 30 hops max, 60 byte packets
XXX CONTENT
6 msk-r0.w-ix.net (193.232.245.79) 5.619 ms 5.682 ms 5.736 ms
7 vl-722.r2-m9.mnogobyte.net (77.220.168.205) 7.105 ms 7.168 ms 7.086 ms
8 vl-998.r1-dc1.mnogobyte.net (77.220.168.30) 7.582 ms 7.649 ms 7.700 ms
9 77.220.184.171 (77.220.184.171) 7.415 ms 2.526 ms 2.342 ms
% telnet 77.220.168.30
Trying 77.220.168.30…
Connected to 77.220.168.30.
Escape character is '^]'.
s1-dc4-RE0 (ttyp1)
login:
Password:
% telnet 77.220.168.30 21
Trying 77.220.168.30…
Connected to 77.220.168.30.
Escape character is '^]'.
220 s1-dc4-RE0 FTP server (Version 6.00LS) ready.
Golden Telecom style. В 2012 году это, IMHO, некрасиво.
s1-dc4. Видимо, тот самый ЕХ (r — router, s — switch) и его RE0 в том самом DC4. Смею предположить, что он и маршрутизирует весь DC4.
MnogoByte, вы на оборудование из вне по telnet ходите, передавая пароли cleartext? Скопируйте filter с MX на ММТС9 на ЕХ.
0
14ть часов не смертельный простой. Молодцы, что смогли быстро решить проблему! Главное теперь не повторить подобного:)
0
Ох ИРОНИЯ.
0
Ребята! Почему Ваш «качественный взлёт» сегодня снова рухнул?
0
Потому что качество продукта либо услуги это не цель которую можно достигнуть. Это процесс, который стоит дорого а видимой отдачи в короткие сроки не видно.
0
Sign up to leave a comment.
Качественный взлет после «падения». Или почему «лежал» МногоБайт