Не торт. Маленькие дочерние платы это DC-DC преобразователи, смысл делать энергоэффективные сервера в которых два раза преобразуют питание и каждый раз с потерями 10% :-/
Для сравнения рекомендую посмотреть HP Moonshot в котором в шаcси размером 4U (в два раза больше этого) влазит 45 серверов (8х Core Atom, 32G RAM, 1x2.5HDD/SSD) + два коммутатора c 10G аплинками. :)
Конечно не приведу, где вы видели коммутаторы с грозозащитой? Не перепаивать же их после каждой грозы :)
А вот отдельно грозозащита за 200-300 рублей + коммутатор с PoE будет дешевле и практичней чем это устройство + коммутатор без PoE.
Хотя если честно мне сложно представить зачем это вообще нужно, обычно грозозащиту ставят провайдеры для домашнего ethernet'а, а PoE нужен для телефонии или видеонаблюдения то есть офисы и предприятия, а на таких объектах нормальная СКС и грозозащита попросту не нужна :)
Кстати, а что делать с этим устройством когда порт после грозы выгорает? В специальных шасси с грозозащитой порты модульные, а тут нет :)
В Шатле тоже не все так просто :) Там при посадке запас кинетической энергии есть на случай если измениться ветер, а если он не изменился то они наматывают лишний круг над ВПП что бы ее убрать :)
вот что нашел в wiki «Влияние невесомости неизбежно учитывается в конструкции жидкостного ракетного двигателя, предназначенного для запуска в невесомости. Жидкие компоненты топлива в баках ведут себя точно так же, как и любая жидкость (образуют жидкие сферы). По этой причине подача жидких компонентов из баков в топливные магистрали может стать невозможной. Для компенсации такого эффекта применяется специальная конструкция баков (с разделителями газовой и жидкой сред), а также — процедура осадки топлива перед запуском двигателя. Такая процедура состоит во включении вспомогательных двигателей корабля на разгон; создаваемое ими небольшое ускорение осаживает жидкое топливо на днище бака, откуда система подачи направляет топливо в магистрали»
То есть сначала ракете нужно придать небольшое ускорение что бы топливо по инерции собралось на дне бака, а потом открывать магистраль в противном случаи вместо топлива пойдут газы наддува бака которые это топливо должны вытеснять.
И, кстати, в одной из предыдущих статей было написано, что при разработке первых космических ракет инженеры не могли гарантировать запуск двигателей в невесомости. Почему?
Насколько я понимаю тогда еще не было хорошо изучено поведения топлива в баках в невесомости. Это как газовый сифон или огнетушитель где рабочее тело выталкивается газом давящим сверху, но если жидкость будет плавать то это не получиться.
Было бы интересно почитать о системах управления такие как: типы гироскопов, бортовые компьютеры, стартовое оборудование, связь всего этого вместе между собой, а так же системы питания, RCS, телеметрии итд итп. То есть вся мелкая начинка :)
И большое вам спасибо за очередную интересную статью! :)
Полностью с вами согласен. Недавно столкнулся с сетевым оборудованием HP, на бумаге все так красиво, а как только начинаешь читать как это настроить то начинаешь понимать почему все любят Cisco :)
Комбинированные FC/Eth в рамках одного свича? MPLS/VPLS, MLAG?
Там же на картинке видно что есть VLAG (аналог Cisco VPC и MLAG) и DCB/Lossless ethernet (FCoE), ну а MPLS на таких коробках не нужен и у других вендоров насколько я знаю его тоже нет в TOR коммутаторах.
Давайте, кроме цены есть еще удобность поддержки и если вся сеть построенная на Cisco то нету смысла покупать одну железку другого вендора только потому что она дешевле.
Не соглашусь (если под «платформа» понимаете «конкретная линейка нехусов»). Код, реализующий конкретные фичи, кочует из ветки в ветку, с младших на старших обычно. Это разумно — крайне сложно разрабатывать и тестировать несколько почти одинаковых реализаций одного и того же на разных платформах. Соответственно, баги там одни и те же, плюс-минус.
Вот только все эти 9k, 7700, 6к анонсировали в последние пол года, а до этого 5 лет был только 7000 (5к можно не считать потому что абсолютно другая и общего у них мало), да и некоторые компании до сих пор пользуются 1 супом и первой версией линейных карт именно по причине сырости обновленных модулей и софта. Баги о которых говорил я тоже с первой версии железа. Выходит что у них действительно было 5 лет для вылизывания.
По поводу переносимость, то что конечный пользователь видеть одну и ту же cli и те же сетевые протоколы никоим образом не означает что внутри там тот же код в подтверждении этого можно назвать пример когда баг в реализации общего для нескольких платформ функционала задевает только одну платформу. Я не исключаю возможности использования общего кода, но как объяснить тот факт что на данный момент они активно разрабатывают: IOS, IOS-XE, IOS-XR, NX-OS? Я склоняюсь к идеи что им просто дешевле поддерживать и развивать 4 разные ветки, а не делать переносимость. Да и каким образом они будут это делать когда IOS это внутренняя разработка, IOS-XE/NXOS это две разные OS которые работают внутри Linux, а IOS XR это вообще QNX. Кстати сейчас они вообще виртуализацию XR решили замутить когда их софт будет работать внутри QNX который будет работать внутри Linux KVM :)
При гибели одного из центров, в случае STP без разных инстансов емкость не теряется вообще, а вот именно по FP и прочим TRILL'образным такое бьет сильно
Возможно я вас не правильно понял, я плохо себе представляю топологию с STP где ничего не простаивает и не теряется емкость в любом состоянии, а вот с FP/TRILL если у нас например 4 Spine, то потеряем только 25% емкости. FP/TRILL всегда лучше STP в безаварийно ситуации и лучше в аварийных в ситуации когда количество Spine больше двух.
Наличие/отсутствие багов не зависит от возраста платформы (сколько лет cat6500 sup720 или 3750?). Вопрос в возрасте софта.
Этот софт полностью привязан к платформе, это не IOS/IOS-XR который уже несколько поколений платформ сменил, да и часть багов фиксят для какой-то конкретной модели модулей через EPDL.
Внутри ЦОДов это обычно не такая большая проблема. А учитывая популярность двухточечной звезды — падение одной железки может сразу ополовинить емкость как минимум куска площадки. Вот магистрали, в том числе между площадками — да, проблема, ибо реально дорого, и 90% утилизации — это повод для гордости.
В консервативных ЦОДа особенно в тех где есть старые СХД или финансовых организациях в которых простаивание целого ЦОДа это нормально, но в интернет компаниях уже избавляются от этого. STP именно по этому заменяют, да и fabric path/TRILL придумали именно для того что бы утилизировать неиспользуемые ресурсы.
А у кого-нибудь есть информация о том, что же там произошло? Пишут что-то про «коммутаторы». Ума не приложу, что должно с ними случиться, чтобы факап длился СТОЛЬКО времени. Ну разве что если у них не было даже холодного резерва, какая-то важная центральная железка скопытилась, и они ждали RMA… Даже на redistribute bgp не похоже.
Я тоже видел сообщение о коммутаторах, что интересно в прошлом году когда украинские сервера вконтакте конфисковали, вконтакте заявил что помимо серверов на площадке у них стоял коммутатор Cisco Nexus. Я так понимаю в остальных датацентрах они тоже используют эту платформу. Это вполне логично учитывая что контент провайдерам не нужны особые функции, кроме пропускной способности, плотности портов и надежности. Если это действительно так и если не учитывать ошибки в конфигурации/эксплуатации то произойти могло что угодно :) Даже спустя 5 лет Cisco все еще ловит баги на этой платформе, иногда даже страшно багрепорты читать :) Например в прошлом году с предпоследней версией я ловил такие проблемы как коммутатор просто перестает форвардить трафик для определенного префикса или sh bgp regexp разрывает все bgp adjacency. Не смотря на это я по прежнему считаю Nexus самым вменяемым выбором для датацентров.
Держать всё в одной AS плохо (подчеркну: не технически), т.к. подразумевается, что внутри AS все «свои» и никто ну точно не нагадит.
А сколько нужно AS для такой сети которую эксплуатируют в Google? 5, 10, 50?
ВКонтакте — удивительно похожая история.
И там и там была деградация сервиса и в обоих случаях официально признали проблемы с сетевой инфраструктурой, на этом схожести заканчиваются. По поводу гадить, для этого есть ITSM.
Вывод: либо делать сразу с умом (как, судя по всему, сделано в Google — никто ведь не помнит, чтобы сетевая инфраструктура Google-а падала?):
Вы все таки определитесь у них с умом или «epic fail» они кстати испытывали проблемы на всех сервисах в течении 3-5 минут в прошлом году
если всё в одной AS — размазывать по ней равномерно сервисы тонким слоем и позаботиться, чтобы AS падала частями
Было бы интересно узнать как выглядит размазывание сервисов по AS
либо поднимать две независимые AS и распределять сервисы между ними. Хотя тут тоже есть варианты и это не всегда удобно.
Согласен, в случаи с google это будет не очень удобно потому что в 2012 году они полностью перешли на SDN :)
Падение половины инфраструктуры для них смерти подобно потому что каналы они утилизируют на 90%.Большие операторы связи и контент провайдеры уже много лет не используют active-backup конфигурации где возможен сбой 50% инфраструктуры потому что держать простаивающими 50% это очень большие деньги, они просто проиграют конкурентам.
Кстати, хотел спросить — у Вас ник просто так или с места работы?
Для сравнения рекомендую посмотреть HP Moonshot в котором в шаcси размером 4U (в два раза больше этого) влазит 45 серверов (8х Core Atom, 32G RAM, 1x2.5HDD/SSD) + два коммутатора c 10G аплинками. :)
А вот отдельно грозозащита за 200-300 рублей + коммутатор с PoE будет дешевле и практичней чем это устройство + коммутатор без PoE.
Хотя если честно мне сложно представить зачем это вообще нужно, обычно грозозащиту ставят провайдеры для домашнего ethernet'а, а PoE нужен для телефонии или видеонаблюдения то есть офисы и предприятия, а на таких объектах нормальная СКС и грозозащита попросту не нужна :)
Кстати, а что делать с этим устройством когда порт после грозы выгорает? В специальных шасси с грозозащитой порты модульные, а тут нет :)
То есть сначала ракете нужно придать небольшое ускорение что бы топливо по инерции собралось на дне бака, а потом открывать магистраль в противном случаи вместо топлива пойдут газы наддува бака которые это топливо должны вытеснять.
И большое вам спасибо за очередную интересную статью! :)
Там же на картинке видно что есть VLAG (аналог Cisco VPC и MLAG) и DCB/Lossless ethernet (FCoE), ну а MPLS на таких коробках не нужен и у других вендоров насколько я знаю его тоже нет в TOR коммутаторах.
Давайте, кроме цены есть еще удобность поддержки и если вся сеть построенная на Cisco то нету смысла покупать одну железку другого вендора только потому что она дешевле.
Вот только все эти 9k, 7700, 6к анонсировали в последние пол года, а до этого 5 лет был только 7000 (5к можно не считать потому что абсолютно другая и общего у них мало), да и некоторые компании до сих пор пользуются 1 супом и первой версией линейных карт именно по причине сырости обновленных модулей и софта. Баги о которых говорил я тоже с первой версии железа. Выходит что у них действительно было 5 лет для вылизывания.
По поводу переносимость, то что конечный пользователь видеть одну и ту же cli и те же сетевые протоколы никоим образом не означает что внутри там тот же код в подтверждении этого можно назвать пример когда баг в реализации общего для нескольких платформ функционала задевает только одну платформу. Я не исключаю возможности использования общего кода, но как объяснить тот факт что на данный момент они активно разрабатывают: IOS, IOS-XE, IOS-XR, NX-OS? Я склоняюсь к идеи что им просто дешевле поддерживать и развивать 4 разные ветки, а не делать переносимость. Да и каким образом они будут это делать когда IOS это внутренняя разработка, IOS-XE/NXOS это две разные OS которые работают внутри Linux, а IOS XR это вообще QNX. Кстати сейчас они вообще виртуализацию XR решили замутить когда их софт будет работать внутри QNX который будет работать внутри Linux KVM :)
Возможно я вас не правильно понял, я плохо себе представляю топологию с STP где ничего не простаивает и не теряется емкость в любом состоянии, а вот с FP/TRILL если у нас например 4 Spine, то потеряем только 25% емкости. FP/TRILL всегда лучше STP в безаварийно ситуации и лучше в аварийных в ситуации когда количество Spine больше двух.
Этот софт полностью привязан к платформе, это не IOS/IOS-XR который уже несколько поколений платформ сменил, да и часть багов фиксят для какой-то конкретной модели модулей через EPDL.
В консервативных ЦОДа особенно в тех где есть старые СХД или финансовых организациях в которых простаивание целого ЦОДа это нормально, но в интернет компаниях уже избавляются от этого. STP именно по этому заменяют, да и fabric path/TRILL придумали именно для того что бы утилизировать неиспользуемые ресурсы.
Я тоже видел сообщение о коммутаторах, что интересно в прошлом году когда украинские сервера вконтакте конфисковали, вконтакте заявил что помимо серверов на площадке у них стоял коммутатор Cisco Nexus. Я так понимаю в остальных датацентрах они тоже используют эту платформу. Это вполне логично учитывая что контент провайдерам не нужны особые функции, кроме пропускной способности, плотности портов и надежности. Если это действительно так и если не учитывать ошибки в конфигурации/эксплуатации то произойти могло что угодно :) Даже спустя 5 лет Cisco все еще ловит баги на этой платформе, иногда даже страшно багрепорты читать :) Например в прошлом году с предпоследней версией я ловил такие проблемы как коммутатор просто перестает форвардить трафик для определенного префикса или sh bgp regexp разрывает все bgp adjacency. Не смотря на это я по прежнему считаю Nexus самым вменяемым выбором для датацентров.
А сколько нужно AS для такой сети которую эксплуатируют в Google? 5, 10, 50?
И там и там была деградация сервиса и в обоих случаях официально признали проблемы с сетевой инфраструктурой, на этом схожести заканчиваются. По поводу гадить, для этого есть ITSM.
Вы все таки определитесь у них с умом или «epic fail» они кстати испытывали проблемы на всех сервисах в течении 3-5 минут в прошлом году
Было бы интересно узнать как выглядит размазывание сервисов по AS
Согласен, в случаи с google это будет не очень удобно потому что в 2012 году они полностью перешли на SDN :)
Падение половины инфраструктуры для них смерти подобно потому что каналы они утилизируют на 90%.Большие операторы связи и контент провайдеры уже много лет не используют active-backup конфигурации где возможен сбой 50% инфраструктуры потому что держать простаивающими 50% это очень большие деньги, они просто проиграют конкурентам.
Просто так.