Pull to refresh

Comments 69

Всё хорошо, что хорошо кончается.
А еще в таких ситуациях инженер(ы), который проводит переключение, получает отличный опыт. Даже если проблема оказывается простой и путь решения тривиальный — такой опыт въедается в память и там остается. Решение задач под давлением ответственности, возможно финансовой, действует почти как адреналин, только в данном случае соображаешь быстрее. Такой опыт считаю крайне полезным, и для многих это редкость, искренне рад за тех, у кого это наоборот.

Про вашу компанию ничего не знаю, но удачи!
По личному опыту, о финансовой ответственности меньше всего думаешь в подобных случаях, и даже не о проблемах заказчика/клиентов, больше всего о негативе со стороны посетителей и пользователей ресурсов, которые из-за тебя видят в браузере или других клиентах не то, что ожидали.
Почти ничего не понял, только к концу поста понял, что речь о сети дата-центров (или таки неправильно понял?), но радует, что российские ИТ-компании не стыдятся сообщать в паблике о проблемах.
Не примите за критику или приговор. Просто хотел поделится внутренним голосом при чтении статьи.

В 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.

Хочу сказать что я восхищаюсь вашей смелостью и открытостью в освящении событий. В России к сожалению такое не часто увидешь.
UFO just landed and posted this here
Да ладно, что люди приходят на хабр рассказать как все плохо, это далеко не всегда так.
Например, меня лично, все эти саксесс стори как все у всех хорошо — малость задолбали, хочется МЯСА :)
Когда все рушится и как это исправляют.
Вот например, тут недавно Альфабанк пытался обновить все свои интернет сервисы, ночью начали, утром сообщили что нужно откатыватся, и потом еще почти день возвращали все назад.
Что вам было бы интереснее узнать — как быстро они обновились, или почему все запоролось, почему не получилось быстро решить проблему и как они откатывались обратно?
Второе на мой взгляд интереснее.
UFO just landed and posted this here
Costumer frustration создался от того что людей игнорируют (даже если по техническим причинам), а не от того что там что-то сломалось.

Золотые слова.
У меня «многобайт» ассоциируется с «постоянно лежит». Год назад с него уехали и больше никаких проблем с сетью. А до этого каждый месяц то пинги теряются, то связность нарушается, то вообще лежит. Единственный плюс — дешевле. Но надежность никакая.

Не в обиду вам будет сказано, конечно, но что то проблемы у вас постоянно.
Странно. У нас крайне редко бывают проблемы со связью. Вы стояли непосредственно у нас или у клиента?
UFO just landed and posted this here
Jumbo Frames заставили меня несколько часов перегружать то одну железку, то другую;) SSH работал, но некоторые другие протоколы не хотели, т.к. пытались выплюнуть большие пакеты в сеть, и че-то не сразу такое развитие событий пришло на ум…
начались странные проблемы с резервным свитчём: ему стало мало памяти и CPU периодически был сильно загружен.

Из-за чего — выяснили?
Разные мировоззрения производителей Juniper Networks, Extreme Networks и Cisco Systems на, казалось бы, полностью стандартизованные протоколы STP и MPLS

Вы что, не тестировали заранее? :) И у вас не было сервисного контракта? Я слышал, у Juniper хорошая поддержка. Прямо-таки бесценная, если одним махом внедряется целая гора непривычных сетевикам железок…
Некоторые свитчи клиентов, подключенных к нашим access-свитчам, также были некорректно настроены и влияли на нашу сеть.

Как? Имели меньший STP приоритет, чем ваши свитчи? Что-то ничего другого, с чем нельзя одним пальцем разобраться в режиме конфигурации порта со стороны провайдера, не могу придумать.

В общем, побольше технических подробностей. Я не ваш клиент, но интересно же :)
UFO just landed and posted this here
Для того чтобы проблем с клиентскими свичами не было нужно настраивать RootGuard на доступе.

Беда в том, что он глушит порт, т.е. все равно требуется пинать клиента, чтобы тот поправил косяк.
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 и так далее.
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.
UFO just landed and posted this here
Обойтись без STP – не собирать схемы при которых он нужен.

Это да. Но это не всегда удается. Как сохранить избыточность? Варианты:
1) mLAG до каждого вышестоящего уровня. Но оно может не поддерживаться. Или поддерживаться только до стеков (один control plane на несколько железок), которые я недолюбливаю. Например, я столкнулся с немалым числом проблем с VSS из пары 6500-х, связанных именно с самим VSS. На нексусах с vPC можно сделать mLAG без объединения мозгов, но это есть только на нексусах.
2) TRILL-образные протоколы. Поддерживается мало где, экзотика.

Есть и что-то вроде fabricpath у жуниперов, но снова — не всегда и не везде, с весьма серьезным ценником.

Я тоже терпеть не могу STP, тоже предпочитаю собирать топологии, где он в штатном режиме ничего не блокирует, но я могу понять людей, у которых нет возможности добиться такого.
UFO just landed and posted this here
Я как раз имел ввиду стэкирование на доступе, 3750 либо EX4200 на мой взгляд лучше бы смотрелось.

У меня как-то снесло крышу правильно собранному стеку из 3750-х при вылетании одного из них (подробностей уже не помню). После этого стек решили разобрать. Да, там работает MST в паре зон, блокируя половину аплинков для каждой. Некрасиво? Конечно. Однако, оно ни разу не ломалось.
В общем, технологии класса «один control plane на N девайсов» — это стрёмно. Нексусы собираются в vPC кластер, сохраняя мозги на каждой из железок. Причем есть автоматическая синхронизация конфигов портов, и трафик, прилетевший на один из свитчей и предназначенный int vlan, будет маршрутизироваться именно этим свитчем, не улетая на соседа, который HSRP active. Красиво.
«3750-х» читать как «тридцать семь пятьдесятых».
UFO just landed and posted this here
Всяко лучше ручного копипаста :)
Вообще-то в приведённой ссылке как раз более чем убедительно показывается, почему на STP полагаться не стоит. У нас нет дата-центра (городская сеть), но тем не менее STP не используем — проблем от него больше, чем решений.
В приведенной ссылке убедительно показывается, что в ЦОДе без колец и с включенным STP подключение нового устройства или банальное объединение двух портов патч-кордом способно вызвать армагеддон.

И опять же, возвращаемся к вопросу о том, что если требуется обеспечить резервирование на L2, то не всегда можно обойтись без блокируемых STP линков. Стеки снижают резервирование, вводя единую точку отказа в виде активного управляющего процессора. Ведь он запросто может заглючить так, что сеть ляжет, но фейловера не произойдет — у меня такое бывало.
UFO just landed and posted this here
Да, вещи имеют свойство меняться. Обрастать новыми фичами, новыми багами. Концепция «одни мозги на двоих и более» ИМХО априори менее надежна, чем «два разных устройства, каждое со своими мозгами».
Ну и по поводу поддержки:
1) Парни сказали, что долго устраняли петлю. Да, неприятное явление, но обычно 15-и минут на ее разгребание должно хватить. Не знаю, как жуниперы, но те же cat6500 прекрасно отзываются по консоле при лупе — ищется порт, который на 100% загружен на input и либо глушится, либо нужно перейти к устройству за этим портом и повторить операцию. Но у каталистов есть storm control, который позволит сети почти нормально функционировать при петле и будет сразу писать в логи, на какой порт приходит слишком много броадкастов/мультикастов/unknown unicast'ов. Наверняка у жуниперов есть аналогичная технология. Ну не может не быть, иначе я в них разочаруюсь.
Если устранение петли (с личным присутствием в ЦОДе) заняло часы, то тут явно и косяк в дизайне, и недостаточные навыки работы с железом.
2) Еще несколько часов ребята осознавали, что у жуниперов и цисок немного разное понимание слова «MTU» и того, какие заголовки учитываются в нем. Опять же, это не может не быть упомянуто в любой базе знаний саппорта вендора.

Ну а вообще, переходили бы на нексусы 7000 — не столкнулись бы с этими проблемами :) Все-таки 6-тонник действительно устарел и не годится для серьезных ЦОДов (хотя там уже не «2х20Гбит/сек на слот», а поболее, но все равно мало). Нексусы 7k дают 550гб/с на слот.
UFO just landed and posted this here
Написано об этом на каждом углу.

Могу предположить, что они просто не ожидали грабель в этом направлении. То есть — недостаток опыта для настолько серьезной миграции.
TAC Cisco, отвечает оперативнее JTAC Juniper

Справедливости ради: у меня при телефонном звонке не удавалось попасть на инженера быстрее чем за 15 минут…
По поводу оборудования, нужно плясать от конкретной задачи

Я исхожу из написанного: «шеститонники всем устраивали, но в какой-то момент стало не хватать емкости на слот». Нексусы — специализированные коммутаторы для ЦОДов, они во многом похожи на IOS устройства вроде каталистов, совместимость на уровне протоколов полная, переучивание недолгое.
UFO just landed and posted this here
Я всегда открываю case через сайт.

Только severity 3-4, в переводе «что-то нехорошо, надо как-нибудь неспеша починить». А когда сеть умерла — это severity 1-2, заводятся только по телефону, и оператор сразу переводит звонок на инженера. Теоретически. На практике — пока продиктуешь серийники, пока инженеры разберутся между собой, в чьей зоне ответственности лежит проблема — часики тикают.
UFO just landed and posted this here
Из-за чего — выяснили?

Пока разбираемся. Сейчас через него идёт около 8Гбит/сек (половина от той нагрузки, которую он лопатил до этого) и проблем нет.
Вы что, не тестировали заранее? :) И у вас не было сервисного контракта? Я слышал, у Juniper хорошая поддержка. Прямо-таки бесценная, если одним махом внедряется целая гора непривычных сетевикам железок…

У нас есть и сервисная поддержка и next day замена неисправного оборудования. Мы тестировали всё оборудование до ввода в строй. Мало того, оно уже работало включенным в наше кольцо и проблем с ним не было. Даже гоняло через себя пару гигабит трафика с тестовых серверов.
В общем, побольше технических подробностей. Я не ваш клиент, но интересно же :)

Подробности будут в течение рабочей недели. Когда всё окончательно выясним. :-) Разумеется тут о них надо написать, чтобы другие не натыкались на те же грабли.
Однако уже после переноса подключений и начала демонтажа роутера Cisco Catalyst

То есть старое оборудование начали демонтировать в ту же ночь?
То есть старое оборудование начали демонтировать в ту же ночь?

Старое оборудование было демонтировано и продано на запчасти в ту же ночь, т.к. на его место устанавливалось новое оборудование. Вообще у меня уже был план откатить всё назад, но потом проблема по чуть-чуть, но начала решаться. А откатываться назад в это время было бы только хуже — время на откат было бы затрачено больше.
[irony]
Очень нравятся фото панелек оборудования! Чем больше размер бренда, тем лучше. Чем больше лампочек в кадре, тем лучше!

Кстати, почему каждая железка в одном экземпляре, когда можно по 2 в шасси? Подключать клиентов с помощью AE в разные устройства. Проводить апгреды без перерыва сервиса. Экономите?
[/irony]

Выделить из бюджета деньги на MX960 3D и EX8200 и поставить их по технологии plug-and-plug все же мало. Нужно узнать, как они работают, и научиться ими управлять. Жаль мне ваших клиентов, им с вашим администрированием еще жить.
UFO just landed and posted this here
Софта, но не железа. Многобайт же менял железо недавно как раз. LINX, например, двумя RE не ограничился.
UFO just landed and posted this here
Согласен. Учтя эту мысль, но все же решив, что помпезный текст и намек на крутые фото крутого оборудования излишни, комментарий про резервирование разместил в блоке с намеком на иронию.

IMHO, у них есть деньги на это. Их же конкуренты могут позволить себе по 2 MX и EX. Тот же vk.com ставит Нексусы и ЕХы пачками.
То что у конторы есть деньги на такое оборудование, не значит что есть деньги на резервирование.

У нас внутри оборудования всё отрезервировано. То есть в шасси стоят по 3 SCB-E и по 2 RE (для MX) и по 8 SF и 2 RE (для EX). Резервировать сами шасси в некоторых ситуациях невозможно, например, поставить на М9 два MX960 для резервирования друг друга.
Я правильно понял, что на шасси там по одной управляющей карте? Ш-ш-шикарно :)
UFO just landed and posted this here
Нет, везде всё отрезервировано. Ставить по одному RE крайне глупо.
Спасибо за то что рассказали что случилось и как решали проблемы а не «Она утонула». Интересно почитать с чем сталкиваются работники ЦОДов.
Мне, как работнику ЦОД, такое присниться только в кошмарах. Когда я менял 7K на ЕХ + MX, то управился за 15 минут даунтайма на клиента. Клиенты переносились по очереди. Книжки и мануалы читал до работ, а не во время.
> Все пострадавшие клиенты получат компенсации и приятные бонусы – в этом можно не сомневаться.

М-да? Приятно, конечно, но у нас суточные потери из-за простоя больше чем мы вам в квартал платим…
значит, вы совсем не думаете о надежности своего сервиса.
если вам слишком дорого переживать простои — у вас должна быть резервированная система.
переключили за 5 минут DNS, и продолжаете жить
> Из-за проблем с access-свитчами наш сайт, а также телефония временно были выведены из работоспособности. Этим-то и вызваны жалобы клиентов, что они не могли до нас дозвониться.

Именно поэтому в телекому принятно не держать у себя свой сайт и телефоны — чтобы в случае проблем/перенастроек и прочего не потерять связь.
Можно пример хостингового телекома, который хостит сайт не у себя? :)

А про телефонию, согласен. Можно хотя бы в письме с оповещением давать номера мобильных телефонов саппорта. Или взять какой-нибудь Е1, или IP-телефонию пустить не через свою сеть. Или иметь резервный номер. Вариантов много. И их применяют некоторые хостинговые фирмы в России.
Молодцы, наняли хорошего пиарщика, который серьезный сбой представил в позитиве, заодно прорекламировал как вы растете.
Мы не нанимали пиаршика. Статью написал я сразу по горячим следам. Чтобы и пострадавшим клиентам и сообществу IT было понятно что у нас случилось. А то обычно после аварий у телекомов на форумах появляются сообщения типа «я в саппорт своего хостера звонил… ну они в этом же дата-центре стоят… хостер сказал, что на дата-центр упал метеорит» или «я не клиент дата-центра, но слышал, что там гендиректор сошёл с ума и расстрелял из автомата сервера». :-)
Хорошо, что по горячим следам осветили информацию. а не замалчивали или пытались пустить в глаза. ок
12 часов простоя и пост об этом на открытом Хабре не вырубить топором.
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 на ЕХ.
14ть часов не смертельный простой. Молодцы, что смогли быстро решить проблему! Главное теперь не повторить подобного:)
UFO just landed and posted this here
Ребята! Почему Ваш «качественный взлёт» сегодня снова рухнул?
Потому что качество продукта либо услуги это не цель которую можно достигнуть. Это процесс, который стоит дорого а видимой отдачи в короткие сроки не видно.
Так можно сказать о новой машине, у которой обкатываются все детали и со временем она начинает работать лучше, но не а дата-центре высокого класса, который падает по 3 раза в месяц.
Sign up to leave a comment.