Comments 31
Было бы интересно еще увидеть реакцию на катастрофическое отключение и корректность восстановления работы после него.
Думал посмотрю как грузовик таранит датацентр.)
Поочередное отключение Inter Switch Link между коммутаторами Cisco Nexus 5548
А почему весь peer-link не погасили? Это ведь тоже единая точка отказа, так как единый логический интерфейс. Вы ведь, надеюсь, не забыли протянуть peer-keepalive link?
Что будет, если к примеру сбрендившая сетевая карта контроллера начнет слать броадкасты на скорости в 10G? Предусмотрели storm control на edge портах?
Допустим, кто-то повредит один из оптических линков (ну там стяжкой перетянули например, или загрязнили коннектор), и на нем начнут теряться пакеты (но линк не пропадет). Как на это отреагирует сервис?
Да и вообще, площадка по размеру детская какая-то.
Peer-keepalive link там есть. Можно протестировать обрыв обоих пир-линков и убедиться, что трафик ходит только через первый нексус. Спасибо за замечание.
В стенде еще 16 серверов Cisco UCS.
В стенде еще 16 серверов Cisco UCS.
Peer-keepalive link у них, наверно, через интерфейсы mgmt0 настроены. И они подключены в какую то отдельный менеджмент Vlan через отдельный switch. Просто на схеме это не показано.
Peer-keepalive link у них, наверно, через интерфейсы mgmt0 настроены. И они подключены в какую то отдельный менеджмент Vlan через отдельный switch.
Фишка в том, что те интерфейсы рекомендуется задействовать исключительно под keepalive-link (не под общий менеджмент), настроить на них сеть 1.1.1.0/24 (снова официальная рекомендация черным по белому) и соединять напрямую патч-кордом, без промежуточных свитчей. Этот линк должен быть настолько надежным, насколько это вообще возможно. Если умрут все агрегированные линки между свитчами, то те несчастные 8 медных жил будут способны превратить катастрофу с даунтаймом в небольшое падение пропускной способности сети.
Интересно было бы притащить немного промышленных печек и погреть ДЦ.
А до кучи в этот момент в ДЦ еще и проводное электричество вырубить.
Вот это тест так тест.
А до кучи в этот момент в ДЦ еще и проводное электричество вырубить.
Вот это тест так тест.
В таких тестированиях и схемах, я обычно задаюсь одним, наверняка дилетантским, вопросом: почему отключение отдельных узлов проверяется последовательно? Расчет на низкую вероятность одновременного сбоя в двух узлах-«коллегах»?
Именно так. Этот расчет зачастую ошибочен, так как для тех двух узлов обязательно (см. законы Мерфи) найдется нечто общее, способное положить оба разом.
Да и серьезные сбои оборудования чаще происходят не из-за «устройство отключилось», а из-за «устройству надо было отключиться, но оно НЕ отключилось». Допустим, любое из нарисованных в схеме устройств начнет терять половину пакетов, но полностью не отключится, т.е. нет триггера для быстрого автоматического переключения на резерв…
Да и серьезные сбои оборудования чаще происходят не из-за «устройство отключилось», а из-за «устройству надо было отключиться, но оно НЕ отключилось». Допустим, любое из нарисованных в схеме устройств начнет терять половину пакетов, но полностью не отключится, т.е. нет триггера для быстрого автоматического переключения на резерв…
Если устройство начнет терять половину пакетов, наши системы мониторинга это сразу обнаружат. Далее проблему будут решать инженеры.
Если устройство начнет терять половину пакетов, наши системы мониторинга это сразу обнаружат.
Но потребуется ручное исправление проблемы. Т.е. время восстановления взлетает с секунд до минут или десятков минут.
А еще, в случае к примеру сбойного линка, на cut-through свитчах вроде N5K инженеры должны уметь локализовывать проблему, потому что в счетчиках show int дропы будут расти где угодно кроме того места, где пакеты бьются.
Вы не беспокойтесь, локализуют и исправят.
Так этот же подход работает и в случае «подключить всё к одному свитчу, а если умрет — быстро заменить».
И получается, что фраза «инфраструктура облачного провайдера действительно не имеет единой точки отказа» — преднамеренная ложь. Вы скрываете тот факт, что отказы бывают всякие, не только «отключилось питание на одном свитче», что скучно и неинтересно.
И получается, что фраза «инфраструктура облачного провайдера действительно не имеет единой точки отказа» — преднамеренная ложь. Вы скрываете тот факт, что отказы бывают всякие, не только «отключилось питание на одном свитче», что скучно и неинтересно.
Так этот же подход работает и в случае «подключить всё к одному свитчу, а если умрет — быстро заменить».
Разочарую вас, подключить к одному свичу — это не подход.
И рассмотренная инфраструктура действительно отказоустойчива и надежна. Если у вас есть конкретные предложения по улучшению или какое-то новое инженерное решение, будем рады услышать.
А повеселить может только грузовик, таранящий датацентр. :-)
подключить к одному свичу — это не подход.
Почему не подход? Вполне подход. Зависит от требований к доступности и к времени восстановления. И что самое смешное — с большой вероятностью с тем свитчем ничего не случится в течение нескольких лет…
И рассмотренная инфраструктура действительно отказоустойчива и надежна.
Но утверждения о том, что она совершенно надежна и не имеет точек отказа — ложь. Предложения по повышению надежности? Ну например отказ от vPC, потому что это — единый management plane и повышенный риск положить одним багом оба свитча.
Где все были, когда эти ребята собирали замечания к плану тестирования?
habrahabr.ru/post/234213/
habrahabr.ru/post/234213/
Вероятность отказа всего и сразу равна вероятности конца света.
Любопытное утверждение. Вы исключаете возможность существования факторов, влияющих сразу на все задействованные в некоторой системе компоненты? Вот пример, способный разом грохнуть оба несуса (а так как конфиги vPC надо править через conf sync, огромное число багов может ударить сразу по двум устройствам). И вы исключаете существование пакета смерти, который пройдет через один свитч, вызовет его сбой, топология перестроится, и тот же пакет прикончит второй свитч с идентичными железом, софтом и конфигом? А я с таким пакетом сталкивался, он как-то положил мне два резервирующих друг друга ASR1k, было неприятно.
Я бы побоялся доверять что-то важное людям, которые то ли врут мне в лицо, то ли действительно некомпетентны.
Я бы побоялся доверять что-то важное людям, которые то ли врут мне в лицо, то ли действительно некомпетентны.
Я думаю никто здесь не отрицает, что вероятность таких факторов всегда и всегда присутствует. Я не представляю схемы резервирования, при которой будет стопроцентная отказоустойчивость, так как в самой системе отказоустойчивости всегда могут быть сбои, всегда где-то найдется один кабель, один блок питания, одна mng plane. Но для таких случаев есть SLA.
А вам, судя по всему, нравится через призму ретроспективы указывать на эксклюзивные баги, вызывающие сбои, с которыми вы лично раньше сталкивались, но, как видно из сообщений, заранее их вероятность никак не предусматривали.
А вам, судя по всему, нравится через призму ретроспективы указывать на эксклюзивные баги, вызывающие сбои, с которыми вы лично раньше сталкивались, но, как видно из сообщений, заранее их вероятность никак не предусматривали.
Я думаю никто здесь не отрицает, что вероятность таких факторов всегда и всегда присутствует.
Так ведь ТС отрицает. Говорит, что вероятность наступления такого события равна вероятности конца света. Парой комментариев выше. И в самом топике заявляют, что нет у них ни одного SPOF. Так что же это — ложь или некомпетентность?
заранее их вероятность никак не предусматривали
Вероятность предусматривалась. Я знал, что когда друг друга резервируют два одинаковых устройства, то такое событие рано или поздно произойдет, но если от такого страховаться — существенно повысится сложность сопровождения, снизится штатная надежность, функционал, да и другие свои болячки появятся. И событие произошло. В итоге — около 10 минут даунтайма большой порции региональной сети на ровном месте посреди дня (один раз за много лет), именно столько времени оба резервирующих друг друга устройства лежали одновременно, но удалось угадать с воркараундом и предотвратить повторные падения. Да, это — серьезная проблема, но я продолжаю считать, что страховаться от такого события было нецелесообразно, та страховка только снизила бы надежность.
Но в любом случае получается, что два совершенно независимых с точки зрения control plane и management plane (т.е. ситуация лучше, чем на нексусах) устройства имели единую точку отказа в виде общего data plane (от этого вообще никуда не денешься) и одинаковой версии control plane с примерно одинаковой конфигурацией и одинаковыми багами.
Плохо размыли и не везде. Зачем вообще размывать? Закрашивайте плашками или удаляйте.
А вообще ребята молодцы. Провели и описали хороший тест, основываясь на используемых технологиях резервирования. Адский нестандартный треш все равно заранее не предвидеть (Например глюки в NX-OS), но для этого у них есть специалисты.
Sign up to leave a comment.
Краш-тест облачной платформы высокой доступности