Comments 111
Хороший материал, спасибо.
<КрикДуши>Господи, 56 Гб/с, дайте хотя бы сотую часть этой скорости, капиталистические провайдеры, читать же больно</КрикДуши>
Интересно, но сомнительно.
На практике очень-очень редко и 10G загружается от 1 хоста, а с учетом правильной практики дублирования этого линка там и 20G есть на хост.
1) У вас же для СХД FC протокол применяется, при чем тут «ускорить работу, например, СХД»?
2) Почему не Ethernet 40G? Решений и поставщиков намного больше чем для Infiniband и никаких «гомо»генных решений
На практике очень-очень редко и 10G загружается от 1 хоста, а с учетом правильной практики дублирования этого линка там и 20G есть на хост.
1) У вас же для СХД FC протокол применяется, при чем тут «ускорить работу, например, СХД»?
2) Почему не Ethernet 40G? Решений и поставщиков намного больше чем для Infiniband и никаких «гомо»генных решений
Да, возник тот же самый вопрос. Если облако серьезное, то 10GE должен быть как минимум двумя кабелями идти до свичей. Алсо, при гармотно сконфигурированном bonding'е (например, в режиме l3+l4) он выдаст без особых проблем 15-17Gbps.
Ну и да, тоже вопрос про 40GE, ниужели полная смена топологии сети вышла дешевле чем внедрение во многом совместимого с 10GE стандарта?
Ну и да, тоже вопрос про 40GE, ниужели полная смена топологии сети вышла дешевле чем внедрение во многом совместимого с 10GE стандарта?
1. Под «косвенно ускорить работу, например, СХД» подразумевалось увеличить производительность дисковой подсистемы за счет перехода коннекта нод гипервизора к кластерной ФС с Ethernet на RDMA. Плюс СХД будут подключаться напрямую по Infiniband, а не по FC, как это было у нас ранее.
2. Потому что был необходим RDMA, для увеличения производительности нашей кластерной ФС. Также, как отмечал выше, в Infinband возможности построения Leaf-Spine топологии, RDMA, автонастройки уже существуют давно и проектировались на уровне протоколов, а не добавлялись как AD-HOC решения, как Ethernet-е. Плюс Infiniband дешевле чем 40G.
2. Потому что был необходим RDMA, для увеличения производительности нашей кластерной ФС. Также, как отмечал выше, в Infinband возможности построения Leaf-Spine топологии, RDMA, автонастройки уже существуют давно и проектировались на уровне протоколов, а не добавлялись как AD-HOC решения, как Ethernet-е. Плюс Infiniband дешевле чем 40G.
И что, вы реально загружаете все 10/20/40 гигабит канала к дискам? Что же у вас за хранилище такое, на сколько дисков? Или AllFlash?
Динамика показывает, что это ненадолго.
Итого: Вкладываться в нишевую технологию сегодня имеет экономический смысл только в том случае, если вы не можете этого сделать «общедоступными» способами. Иначе, в том варианте, как вы описали, это экономически бессмысленно.
Плюс Infiniband дешевле чем 40G.
Динамика показывает, что это ненадолго.
Итого: Вкладываться в нишевую технологию сегодня имеет экономический смысл только в том случае, если вы не можете этого сделать «общедоступными» способами. Иначе, в том варианте, как вы описали, это экономически бессмысленно.
Да не нагружают они, это очевидно. У нас в Nutanix 2x10G торчит на каждом ноде, в throughput и сетевую лейтенси (при условии нормальных коммутаторов типа Артисты) ни разу не видел упора.
Упираются сейчас в процессоры клиенты в основном, ждем с нетерпением Haswell.
Конечно Крок жестко насмешил по поводу 500 VM — на нутаниксе это пара блоков на 4U (если средненагруженные виртуалки).
Ну даже если тяжелые — максимум стойка оборудования — на тысячи виртуалок и миллионы IOPS.
Я называю такие вещи жесткой пионерией :)))
Один клауд хостинг уже был в РФ на Infiniband, закрылся не столь давно.
Упираются сейчас в процессоры клиенты в основном, ждем с нетерпением Haswell.
Конечно Крок жестко насмешил по поводу 500 VM — на нутаниксе это пара блоков на 4U (если средненагруженные виртуалки).
Ну даже если тяжелые — максимум стойка оборудования — на тысячи виртуалок и миллионы IOPS.
Я называю такие вещи жесткой пионерией :)))
Один клауд хостинг уже был в РФ на Infiniband, закрылся не столь давно.
Толсто )
Про 500 машин и Infiniband соглашусь. Точно также с экономической точки зрения не понимаю выгоды использования FDR, вполне хватило бы 4x QDR на 40Гб, какой кстати и был в упоминаемом вами небезызвестном клауд хостинге. :)
P.S.: Кстати забавные стали хвосты делать у коннекторов. Я только пластиковые ушки видел, наподобие таких:
Они имели свойство иногда заедать, т.е. тяжело кабель вынимается. А еще помню кто-то умудрился сломать эти пластмассовые уши на одном из серверов, в результате чего голыми руками кабель извлечь было практически нереально. И все надеялись на волю случая, что в ближайшем будущем ничего не произойдет и этот сервер трогать не придется. :)
P.S.: Кстати забавные стали хвосты делать у коннекторов. Я только пластиковые ушки видел, наподобие таких:
Они имели свойство иногда заедать, т.е. тяжело кабель вынимается. А еще помню кто-то умудрился сломать эти пластмассовые уши на одном из серверов, в результате чего голыми руками кабель извлечь было практически нереально. И все надеялись на волю случая, что в ближайшем будущем ничего не произойдет и этот сервер трогать не придется. :)
Это разъем CX4, а на картинках в посте — QSFP.
Не уверен, что по ценам они сильно отличаются. Кроме того, у FDR КПД выше, так как кодирование сменили — в 4x QDR скорость передачи данных была 32 гбит/с.
Точно также с экономической точки зрения не понимаю выгоды использования FDR, вполне хватило бы 4x QDR на 40Гб
Не уверен, что по ценам они сильно отличаются. Кроме того, у FDR КПД выше, так как кодирование сменили — в 4x QDR скорость передачи данных была 32 гбит/с.
Потому что был необходим RDMA
А что, разве есть 10/40G без RDMA? Серьезно?
Итересно, какая у Вас глубина реков. На фото кабеля столь вольготно висят. И какой допустимый радиус скругления у кабелей?
На четвертой фотографии с конца показалось, что парень использует визитку Яроша в процессе монтажа, но вы решили попытаться скрыть сей факт :)
Расмматривали вариант ethernet cut-through? Почему отклонили?
Там задержки 1.8-3.5мкс
www.extremenetworks.com/product/summit-x770-series-2/
Там задержки 1.8-3.5мкс
www.extremenetworks.com/product/summit-x770-series-2/
With this non-blocking and/or oversubscription flexibility, you can build small network fabrics using just Summit X770 switches with less than 1.8 microseconds of latency through the network. Using the Summit X770 in conjunction with the BDX8, you can build very large network fabrics with different non-blocking and/or oversubscription options with less than 3.5 microseconds of latency through the entire fabric.Это решение появилось на рынке относительно недавно, в период поиска (несколько лет назад) оптимального решения для нашего облака на Компрессоре его ещё не было. А нам вторую облачную площадку нужно было подстроить под первую. Но даже если рассматривать, цена за коммутаторы с поддержкой cut-through все равно значительно выше, чем за оборудование Mellanox.
А можно поподробнее про «в нашем случае Infiniband работал бы в пять раз быстрее, чем Ethernet, а стоил бы столько же». Тут 10GE Ethernet сравнивается c 56 GE Infiniband или что-то иное? Первый раз вижу, чтобы Infiniband был дешевле и очень интересна калькуляция хотя бы в общих чертах.
" на почти 500 виртуальных машинах, размещенных на примерно сотне физических серверов."
Очень, очень крупный проект. Которому обязательно требуется Infiniband :))
…
Реалии таковы что на облачных хостингах Infiniband не нужен и даже вреден. Упор — не в полосу пропускания, а в IOPS. Какая виртуальная машина может сгенерировать 50 гигабит трафика??? Там обычных пару 10G интерфейсов на сервер — более чем достаточно.
По лейтенси — задержка на дисковых системах все равно намного выше, и коммутатор типа Arista Networks с 300 наносекунд задержки по 10/40G — более чем достаточно.
Очень, очень крупный проект. Которому обязательно требуется Infiniband :))
…
Реалии таковы что на облачных хостингах Infiniband не нужен и даже вреден. Упор — не в полосу пропускания, а в IOPS. Какая виртуальная машина может сгенерировать 50 гигабит трафика??? Там обычных пару 10G интерфейсов на сервер — более чем достаточно.
По лейтенси — задержка на дисковых системах все равно намного выше, и коммутатор типа Arista Networks с 300 наносекунд задержки по 10/40G — более чем достаточно.
Латентность Infiniband FDR порядка 1-1,5 микросекунд, а на Ethernet порядка 30-100 микросекунд. То есть разница в два порядка, на практике в данном конкретном случае тоже примерно так.
Вы сильно отстали от жизни. Датацентровые коммутаторы давно уже имеют latency порядка 1-ой микросекунды. Да и 56Гиг/с уже маловато когда есть интерфейсы 100Гбит/с с такой же задержкой. И сомневаюсь что цена будет сильно отличаться от вашего решения. F3 карты у Nexus 7000.
Ариста имеет 320 наносекунд для своих TOR свитчей.
Впрочем, от «Крока» я и не такие перлы слышал :)
Впрочем, от «Крока» я и не такие перлы слышал :)
А это для фреймов каких размеров? А то у Cisco и 51 наносекунда есть :)
Чуток повангую, думаю для 512 байт.
Чуток повангую, думаю для 512 байт.
У Cisco это все маркетинговая разводка и реально сильно плавает.
У артисты как раз не важно какой размер и функционал, даже для L4 лейтенси остается такой-же.
Недаром РТС взяли Аристу (насколько я знаю делают NAT прямо на коммутаторе для подключения к London Stock Exchange)
Фактически, Ариста сейчас мрачно выносит Cisco на рынке коммутации.
Про Juniper я молчу. Капитализация Аристы уже выше Brocade насколько помню.
Кстати Interrop 2013 они тоже взяли — 11U коробка с 120010G портов, или 40-ки или 100-ки. Тобишь официально признаны лучшим коммутатором в мире.
www.interop.com/lasvegas/expo/best-of-interop-awards.php
DATA CENTER FINALISTS
Arista Networks– Arista 7300X 10/40GbE Data Center Switch and EOS Programmability (SSU)
Cisco – Cisco Nexus 9516 Switch
Stratus Technologies – Stratus everRun Enterprise
У артисты как раз не важно какой размер и функционал, даже для L4 лейтенси остается такой-же.
Недаром РТС взяли Аристу (насколько я знаю делают NAT прямо на коммутаторе для подключения к London Stock Exchange)
Фактически, Ариста сейчас мрачно выносит Cisco на рынке коммутации.
Про Juniper я молчу. Капитализация Аристы уже выше Brocade насколько помню.
Кстати Interrop 2013 они тоже взяли — 11U коробка с 120010G портов, или 40-ки или 100-ки. Тобишь официально признаны лучшим коммутатором в мире.
www.interop.com/lasvegas/expo/best-of-interop-awards.php
DATA CENTER FINALISTS
Arista Networks– Arista 7300X 10/40GbE Data Center Switch and EOS Programmability (SSU)
Cisco – Cisco Nexus 9516 Switch
Stratus Technologies – Stratus everRun Enterprise
2013 Winners
Best of Interop Grand Award and Networking Cateogry Winner
Arista Networks — Arista 7500E Data Center Switch
Best of Interop Grand Award and Networking Cateogry Winner
Arista Networks — Arista 7500E Data Center Switch
Слабо мне верится что эти 320 нс тоже не маркетинг.
Вот например нексус 3548 хвастается 190нс. И 250нс c влюченным NAT. Включил Ixia. Проверил latency. Не врут.
Есть у кого ариста с трафик генератором проверить?
Кстати если кто не знал. Аристу основали выходцы из Cisco те кто занимались 4500.
Вот например нексус 3548 хвастается 190нс. И 250нс c влюченным NAT. Включил Ixia. Проверил latency. Не врут.
Есть у кого ариста с трафик генератором проверить?
Кстати если кто не знал. Аристу основали выходцы из Cisco те кто занимались 4500.
Зря не веришь :).
Кто основал Аристу я прекрасно знаю, я живу на одной улице через два дома с топ-менеджером Артисты по Восточной Европе (и РФ) — Peter Major :)
А так — поговори например с Ляминым из Qrator / HighLoad Lab — они тестили все, в итоге единственный (!) коммутатор который не сдох — это Ариста.
Cisco кстати умирает быстрее всех :))))
qrator.net
Кто основал Аристу я прекрасно знаю, я живу на одной улице через два дома с топ-менеджером Артисты по Восточной Европе (и РФ) — Peter Major :)
А так — поговори например с Ляминым из Qrator / HighLoad Lab — они тестили все, в итоге единственный (!) коммутатор который не сдох — это Ариста.
Cisco кстати умирает быстрее всех :))))
qrator.net
> Cisco кстати умирает быстрее всех :))))
Её некому больше исправлять, все разбежались? :)
Её некому больше исправлять, все разбежались? :)
Arista — не свитч.
Cisco — не свитч.
Свитчи — это 7500E, 6500 и так далее.
Цискин свитч умер быстрее всех? Вполне возможно. Например, кто-то умный решил сделать ip tcp adjust-mss и пустить гигабитный syn флуд — это верная смерть для любой платформы. Или подняли NAT на 6500 (где он «assisted») и тоже пустили syn flood. Есть много способов накосячить и убить коммутатор, если не знать, как он работает. Может, они умышленно запороли тестирование конкурентов, потому что по разным причинам хотели конкретно аристу, а внутренние процедуры требовали «объективного» сравнения.
Но если не накосячить и не вызвать высокое число punt'ов, то железо будет выдавать приблизительно заявленные pps (с поправкой на то, что на внутренних соединениях тоже могут быть затыки), которых обычно с запасом хватит в контексте пропускания ddos атак (это когда высокая нагрузка на небольшом числе интерфейсов, а не могучий обмен между всеми портами, генерируемый железом Spirent). И даже синтетическая 100% нагрузка на все интерфейсы разом не должна убить устройство. Data plane стонет, транзитный трафик теряется, но RP почти простаивает, потому что транзитный трафик обычно не должен его касаться.
Так как вы определенно не знаете даже название линейки тестируемого оборудования, не говоря уже о настроенных на data plane фичах и характере тестирования — предлагаю прекратить распространение откровенной дезинформации.
Cisco — не свитч.
Свитчи — это 7500E, 6500 и так далее.
Цискин свитч умер быстрее всех? Вполне возможно. Например, кто-то умный решил сделать ip tcp adjust-mss и пустить гигабитный syn флуд — это верная смерть для любой платформы. Или подняли NAT на 6500 (где он «assisted») и тоже пустили syn flood. Есть много способов накосячить и убить коммутатор, если не знать, как он работает. Может, они умышленно запороли тестирование конкурентов, потому что по разным причинам хотели конкретно аристу, а внутренние процедуры требовали «объективного» сравнения.
Но если не накосячить и не вызвать высокое число punt'ов, то железо будет выдавать приблизительно заявленные pps (с поправкой на то, что на внутренних соединениях тоже могут быть затыки), которых обычно с запасом хватит в контексте пропускания ddos атак (это когда высокая нагрузка на небольшом числе интерфейсов, а не могучий обмен между всеми портами, генерируемый железом Spirent). И даже синтетическая 100% нагрузка на все интерфейсы разом не должна убить устройство. Data plane стонет, транзитный трафик теряется, но RP почти простаивает, потому что транзитный трафик обычно не должен его касаться.
Так как вы определенно не знаете даже название линейки тестируемого оборудования, не говоря уже о настроенных на data plane фичах и характере тестирования — предлагаю прекратить распространение откровенной дезинформации.
Запросите детали у Лямина из Qrator, он вполне публичен и поделится тестовыми данными.
Лень. Это лишь любопытство. У меня есть свои тестовые данные, я знаю архитектуру многих железок, и я вполне уверен, что в их тестировании была допущена грубая ошибка либо по невежеству, либо по умыслу.
Если хотите, можете сами попросить его опубликовать результаты. Что за трафик, через что он шел, какая была конфигурация оборудования, что произошло, что при этом было на определенных счетчиках и в логах и т.д. Мне кажется, никто не даст вам эту информацию в достаточном объеме, будет лишь что-то вроде «влили трафик в свитч, и он перестал отзываться».
Если хотите, можете сами попросить его опубликовать результаты. Что за трафик, через что он шел, какая была конфигурация оборудования, что произошло, что при этом было на определенных счетчиках и в логах и т.д. Мне кажется, никто не даст вам эту информацию в достаточном объеме, будет лишь что-то вроде «влили трафик в свитч, и он перестал отзываться».
Вообще-то я очень плотно работаю с Arista, включая HQ, а с Ляминым лично общался.
Так что про дезинформацию — просьба громкими фразами не разбрасываться.
Впрочем, такой бурной реакции от «Cisco. CCNP, CCIP.» вполне стоит ожидать. Ровно так-же на Nutanix реагируют ребята из EMC и прочих :)
Так что про дезинформацию — просьба громкими фразами не разбрасываться.
Впрочем, такой бурной реакции от «Cisco. CCNP, CCIP.» вполне стоит ожидать. Ровно так-же на Nutanix реагируют ребята из EMC и прочих :)
>Вообще-то я очень плотно работаю с Arista, включая HQ
А причем тут Arista, когда речь идет про Cisco? Я верю, что аристина железка не умерла под трафиком, потому что вообще-то свитчам не положено умирать под трафиком.
> а с Ляминым лично общался.
Вы поверили человеку, с которым «лично общался», не удосужившись выяснить детали? Ну так я тоже лично общался с огромным числом некомпетентных людей, и это вовсе не означает, что они компетентны. Но в этом плане я по сравнению с отписывавшимся выше Анатолием вообще никто, он каждый день разговаривает с десятками разного уровня грамотности людей из разных организаций :)
>Впрочем, такой бурной реакции от «Cisco. CCNP, CCIP.» вполне стоит ожидать.
Какой именно бурной реакции? Вы сказали примерно следующее — «кто-то что-то потестировал, и что-то где-то упало». Если бы упал свитч Arista, то моя реакция была бы идентичной. Вы не знаете ни малейших деталей, вы даже не знаете, что и как тестировали, но фактически безапелляционно называете всю продукцию вендора (много-много сотен моделей очень разного оборудования) хламом. Это уже проявление глупости, честное слово.
Другой дурак многократно уверял меня «если пустить через циску много трафика, то он будет протекать через запрещающие записи в ACL, потому циска хлам». Выяснилась проблема, и даже не одна:
1) Это было лет 10 назад.
2) Он только слышал об этом, но сам такого не видел.
3) Он даже примерно не знал, про какое оборудование шла речь. Видимо, он не в курсе, что бывают как минимум софтовые маршрутизаторы, коммутаторы и пиксы, а на самом деле категория железа куда больше…
4) Кажется, никому и никогда не удавалось воспроизвести это.
Ну и так как ACL check находится в цепочке обработки пакета — у перегруженной железки как бы нет причин пропускать этот этап конвейера, скорее разрешенные пакеты будут дропнуты из-за нехватки ресурсов.
В общем, не люблю громкие заявления от некомпетентных людей, не удосужившихся хотя бы немного изучить вопрос.
А причем тут Arista, когда речь идет про Cisco? Я верю, что аристина железка не умерла под трафиком, потому что вообще-то свитчам не положено умирать под трафиком.
> а с Ляминым лично общался.
Вы поверили человеку, с которым «лично общался», не удосужившись выяснить детали? Ну так я тоже лично общался с огромным числом некомпетентных людей, и это вовсе не означает, что они компетентны. Но в этом плане я по сравнению с отписывавшимся выше Анатолием вообще никто, он каждый день разговаривает с десятками разного уровня грамотности людей из разных организаций :)
>Впрочем, такой бурной реакции от «Cisco. CCNP, CCIP.» вполне стоит ожидать.
Какой именно бурной реакции? Вы сказали примерно следующее — «кто-то что-то потестировал, и что-то где-то упало». Если бы упал свитч Arista, то моя реакция была бы идентичной. Вы не знаете ни малейших деталей, вы даже не знаете, что и как тестировали, но фактически безапелляционно называете всю продукцию вендора (много-много сотен моделей очень разного оборудования) хламом. Это уже проявление глупости, честное слово.
Другой дурак многократно уверял меня «если пустить через циску много трафика, то он будет протекать через запрещающие записи в ACL, потому циска хлам». Выяснилась проблема, и даже не одна:
1) Это было лет 10 назад.
2) Он только слышал об этом, но сам такого не видел.
3) Он даже примерно не знал, про какое оборудование шла речь. Видимо, он не в курсе, что бывают как минимум софтовые маршрутизаторы, коммутаторы и пиксы, а на самом деле категория железа куда больше…
4) Кажется, никому и никогда не удавалось воспроизвести это.
Ну и так как ACL check находится в цепочке обработки пакета — у перегруженной железки как бы нет причин пропускать этот этап конвейера, скорее разрешенные пакеты будут дропнуты из-за нехватки ресурсов.
В общем, не люблю громкие заявления от некомпетентных людей, не удосужившихся хотя бы немного изучить вопрос.
«Вы поверили человеку, с которым «лично общался», не удосужившись выяснить детали? Ну так я тоже лично общался с огромным числом некомпетентных людей, „
Это феерично.
И это совсем ничего, что Лямин сейчас фактически один из ведущих специалистов в РФ по защите от DDOS атак и прочих радостей? И реально оперирует огромными трафиками?
Пардон, но тут остается лишь заметить “чья корова бы мычала».
И советую-таки изучить архитектуру Аристы — она уникальна и аналогов на рынке нынче не имеет. За счет этого и нет проблем с прыгающим лейтенси, и прочее.
Это феерично.
И это совсем ничего, что Лямин сейчас фактически один из ведущих специалистов в РФ по защите от DDOS атак и прочих радостей? И реально оперирует огромными трафиками?
Пардон, но тут остается лишь заметить “чья корова бы мычала».
И советую-таки изучить архитектуру Аристы — она уникальна и аналогов на рынке нынче не имеет. За счет этого и нет проблем с прыгающим лейтенси, и прочее.
>Лямин сейчас фактически один из ведущих специалистов в РФ по защите от DDOS атак и прочих радостей
Очень круто. Наверное, вам надо основать фан-клуб.
Лямин — директор молодой, динамично развивающейся компании, которая, одна из многих, занимается защитой от DDOS. Когда-то он был инженером. Я сильно сомневаюсь, что за это время он не забыл матчасть напрочь. Особенно — глубокую матчасть, вроде аппаратной архитектуры коммутаторов. Специалистом может быть один из его сотрудников, или даже несколько.
>И советую-таки изучить архитектуру Аристы — она уникальна и аналогов на рынке нынче не имеет.
Аналогов не имеет архитектура N9K. Что до аристы — расскажите, что именно так такого волшебного сделано, что cut-through свитч на общеиспользуемых ASICах никогда не должен буферизировать пакеты, несмотря на огромных размеров буфера (зачем они тогда нужны?).
Очень круто. Наверное, вам надо основать фан-клуб.
Лямин — директор молодой, динамично развивающейся компании, которая, одна из многих, занимается защитой от DDOS. Когда-то он был инженером. Я сильно сомневаюсь, что за это время он не забыл матчасть напрочь. Особенно — глубокую матчасть, вроде аппаратной архитектуры коммутаторов. Специалистом может быть один из его сотрудников, или даже несколько.
>И советую-таки изучить архитектуру Аристы — она уникальна и аналогов на рынке нынче не имеет.
Аналогов не имеет архитектура N9K. Что до аристы — расскажите, что именно так такого волшебного сделано, что cut-through свитч на общеиспользуемых ASICах никогда не должен буферизировать пакеты, несмотря на огромных размеров буфера (зачем они тогда нужны?).
Лямин был и остается офигенным инженером. Так, к слову. Пользуемся их услугами уже пару лет — круче них никого нет.
Из «компания оказывает качественный сервис» не следует «директор хорошо знает матчасть». Особенно новые железки. Если у директора компании есть время заниматься этим, то он что-то делает не так.
А с кем вы сравнивали, чтобы утверждать «круче них никого нет»?
А с кем вы сравнивали, чтобы утверждать «круче них никого нет»?
Я сравнивал почти со всеми, из крупняка — dragonara, voxility и еще десяток контор поменьше.
Для затравки дам задачу — защита HTTPS фронтэндов от валидных SSL запросов от сотен тысяч ботов ежесекундно без какой-либо зависимости в телах запросов и запросы шли из сетей с легитимными клиентами. Мы с этой задачей обошли почти всех — помогли лишь Qrator.
Вы вообще в теме, уважаемый? Погуглите что-ли «Лямин Александр» на Slideshare и Youtube и убедитесь, что он ОТЛИЧНО знает то, чем занимается его компания.
Тут вышел какой-то фан клуб, но я искренее рад, что есть такие люди, за которых можно пофанатеть, таких спецов исчезающе мало, но они крайне нужны.
А вот чего достигли вы — я что-то не могу найти ни в гугле, ни в яндексе. Это банальная зависть?
Для затравки дам задачу — защита HTTPS фронтэндов от валидных SSL запросов от сотен тысяч ботов ежесекундно без какой-либо зависимости в телах запросов и запросы шли из сетей с легитимными клиентами. Мы с этой задачей обошли почти всех — помогли лишь Qrator.
Вы вообще в теме, уважаемый? Погуглите что-ли «Лямин Александр» на Slideshare и Youtube и убедитесь, что он ОТЛИЧНО знает то, чем занимается его компания.
Тут вышел какой-то фан клуб, но я искренее рад, что есть такие люди, за которых можно пофанатеть, таких спецов исчезающе мало, но они крайне нужны.
А вот чего достигли вы — я что-то не могу найти ни в гугле, ни в яндексе. Это банальная зависть?
>Я сравнивал почти со всеми, из крупняка — dragonara, voxility и еще десяток контор поменьше.
Первый загуглил. Сайт не нашел. Упоминания о том, что это scam, нашел.
А вы сравнивали, скажем, с cloudflare, касперскими (которые ценны в том числе базами адресов)?
Ну и, конечно, вы отдавали им приватные ключи? Боюсь, на такое немного кто может пойти, а без этого много не нафильтруешь.
>Вы вообще в теме, уважаемый?
Вообще ни разу :)
>Погуглите что-ли «Лямин Александр» на Slideshare и Youtube и убедитесь, что он ОТЛИЧНО знает то, чем занимается его компания.
Я допускаю, что он понимает, чем занимается его компания. Но вы заметили, какой вопрос изначально обсуждался? Знание архитектуры конкретных современных железок. Например, даже shapa, являющийся инженером и оргазмирующий от продукции Arista, понятия не имеет, как устроено современное сетевое оборудование и на любые вопросы пытается перевести стрелки на других людей.
Так что я вовсе не уверен, что Лямин или кто-либо из работающих на него людей обладают достаточной квалификацией для тестирования оборудования. Потому и предлагал опубликовать более подробную информацию о тестировании, в котором умерло всё кроме арист. Кстати, без комментариев вендоров (в случае циски — от TAC) тоже никуда.
>А вот чего достигли вы
Я шизею с такой аргументации…
Скажите — а кто кроме простого инженера может оценить техническую грамотность другого человека? Я пока вижу в топике кучку детей, с разинутым ртом внимающих любым словам «авторитета», даже не пытающихся включить мозг и обдумать услышанное. Меня такой подход не устраивает. Я поверю, что в Qrator есть хотя бы один грамотный сетевик, когда увижу конкретные данные. Например, детали упомянутого тестирования, в котором легли все кроме аристы. У них ведь нет задач работать с действительно огромным трафиком, типовой DDOS — это много (а чаще даже мало) данных по небольшому числу портов (от чего ни одному свитчу не положено скопытиться). Ах да, еще им положено уметь крутить BGP, мягко говоря не самый сложный в мире протокол.
100к TPS SSL, которые вас так впечатлили — это ведь самый край сотни мегабит трафика. С точки зрения сетевика — копейки. С точки зрения приложения, которое терминирует SSL, и HTTP сервера — да, дофига. Ну что же, одна топовая железяка от F5 по спекам способна принять 75к TPS и миллион TCP соединений в секунду (HTTP запросов — больше). Таких железок можно поставить несколько. И я еще не говорю о специализированных железках вроде Arbor Peakflow.
Так что думайте, анализируйте. Если вы не можете адекватно оценить уровень знаний другого человека (для этого надо самому хоть что-то знать, иначе вы автоматически признаете экспертом любого наговорившего непонятных вам слов), то он не может быть авторитетом, и любая полученная от него информация автоматически ставится под сомнение. И из хорошего знания человеком одной предметной области ни при каких обстоятельствах не вытекает хорошее знание им другой предметной области — глупейшая логическая ошибка, которую совершили минимум два человека в этой теме.
Первый загуглил. Сайт не нашел. Упоминания о том, что это scam, нашел.
А вы сравнивали, скажем, с cloudflare, касперскими (которые ценны в том числе базами адресов)?
Ну и, конечно, вы отдавали им приватные ключи? Боюсь, на такое немного кто может пойти, а без этого много не нафильтруешь.
>Вы вообще в теме, уважаемый?
Вообще ни разу :)
>Погуглите что-ли «Лямин Александр» на Slideshare и Youtube и убедитесь, что он ОТЛИЧНО знает то, чем занимается его компания.
Я допускаю, что он понимает, чем занимается его компания. Но вы заметили, какой вопрос изначально обсуждался? Знание архитектуры конкретных современных железок. Например, даже shapa, являющийся инженером и оргазмирующий от продукции Arista, понятия не имеет, как устроено современное сетевое оборудование и на любые вопросы пытается перевести стрелки на других людей.
Так что я вовсе не уверен, что Лямин или кто-либо из работающих на него людей обладают достаточной квалификацией для тестирования оборудования. Потому и предлагал опубликовать более подробную информацию о тестировании, в котором умерло всё кроме арист. Кстати, без комментариев вендоров (в случае циски — от TAC) тоже никуда.
>А вот чего достигли вы
Я шизею с такой аргументации…
Скажите — а кто кроме простого инженера может оценить техническую грамотность другого человека? Я пока вижу в топике кучку детей, с разинутым ртом внимающих любым словам «авторитета», даже не пытающихся включить мозг и обдумать услышанное. Меня такой подход не устраивает. Я поверю, что в Qrator есть хотя бы один грамотный сетевик, когда увижу конкретные данные. Например, детали упомянутого тестирования, в котором легли все кроме аристы. У них ведь нет задач работать с действительно огромным трафиком, типовой DDOS — это много (а чаще даже мало) данных по небольшому числу портов (от чего ни одному свитчу не положено скопытиться). Ах да, еще им положено уметь крутить BGP, мягко говоря не самый сложный в мире протокол.
100к TPS SSL, которые вас так впечатлили — это ведь самый край сотни мегабит трафика. С точки зрения сетевика — копейки. С точки зрения приложения, которое терминирует SSL, и HTTP сервера — да, дофига. Ну что же, одна топовая железяка от F5 по спекам способна принять 75к TPS и миллион TCP соединений в секунду (HTTP запросов — больше). Таких железок можно поставить несколько. И я еще не говорю о специализированных железках вроде Arbor Peakflow.
Так что думайте, анализируйте. Если вы не можете адекватно оценить уровень знаний другого человека (для этого надо самому хоть что-то знать, иначе вы автоматически признаете экспертом любого наговорившего непонятных вам слов), то он не может быть авторитетом, и любая полученная от него информация автоматически ставится под сомнение. И из хорошего знания человеком одной предметной области ни при каких обстоятельствах не вытекает хорошее знание им другой предметной области — глупейшая логическая ошибка, которую совершили минимум два человека в этой теме.
CloudFlare нас откровенно кинул на тарифе за 200 евро/месяц. Сайт в половину случаев не открывался вообще, все попытки общения с саппортом приводили к ответу «проблема у вас на сервере», причем они отвечали часов через 5. После смены на Qrator все чудом поднялось и заработало.
Касперский со своими ценами гхм, в общем дороже разумных пределов по цене за далеко не первичную услугу.
Касперский со своими ценами гхм, в общем дороже разумных пределов по цене за далеко не первичную услугу.
ArborPakflow не умеет защищать SSL. К нему, конечно, есть _внешние_ спец модули для этой задачи, но даже сами sales Arbor их не особо рекомендуют из-за «совершенно неадекватной цены».
Да и вообще сравнивать Arbor и сервис по защите от атак — дело весьма странное. Я пользовался и тем и другим и могу сказать, что Arbor это не вещь класса «защита в один клик», а лишь продвинутый фильтр пакетов, не более, не менее. К которому должен прилагаться либо внешний код либо грамотный сетевик.
Да и вообще сравнивать Arbor и сервис по защите от атак — дело весьма странное. Я пользовался и тем и другим и могу сказать, что Arbor это не вещь класса «защита в один клик», а лишь продвинутый фильтр пакетов, не более, не менее. К которому должен прилагаться либо внешний код либо грамотный сетевик.
Дмитрий,
Ну не надо из «архитектуры свитчей» строить священную коровую. Раньше, может да.
Сейчас? Свитчи у вендоров как правило на одном и том-же чипье и даже коробки идентичные. Ну может цветом и этикеткой отличаются.
Все «понимание» сводится к знанию на что данный FCPGA способен и аккуратности написания того что в tcam попадает.
Вся разница. А дальше только аккуратность кодеров…
Рынок коммутационного оборудования коммодитизировался. Если вы этого не видите, возможно вы просто ослепли ;)
Ну не надо из «архитектуры свитчей» строить священную коровую. Раньше, может да.
Сейчас? Свитчи у вендоров как правило на одном и том-же чипье и даже коробки идентичные. Ну может цветом и этикеткой отличаются.
Все «понимание» сводится к знанию на что данный FCPGA способен и аккуратности написания того что в tcam попадает.
Вся разница. А дальше только аккуратность кодеров…
Рынок коммутационного оборудования коммодитизировался. Если вы этого не видите, возможно вы просто ослепли ;)
Свитчи у вендоров как правило на одном и том-же чипье и даже коробки идентичные
Да, у большинства вендоров. Свое делать — дорого и обычно не нужно. Броадкомовские чипы достаточно хороши для базовых задач, когда особый функционал не требуется, как и особая производительность. Но вот сильно сомневаюсь, что Trident 2 настолько плох, что не выдает указанную в спецификации производительность…
Рынок коммутационного оборудования коммодитизировался
Рассматривая вендоров второго эшелона — да, спору нет, основная разница у них — в софте, наборе портов, цвете коробки и т.д.
|Trident 2 настолько плох, что не выдает указанную в спецификации производительность…
Само железо может и ничего, а вот SDK там АДОВ ;)
Ну и руки разные софт пишут. Вы порекомендуйте какую кошку нам замучать, а мы расскажем на Хабре ;)
Само железо может и ничего, а вот SDK там АДОВ ;)
Ну и руки разные софт пишут. Вы порекомендуйте какую кошку нам замучать, а мы расскажем на Хабре ;)
Вы порекомендуйте какую кошку нам замучать
Исходя из озвученных задач — наверное, даже Cat2960 сгодится. Он должен осилить line rate по всем портам.
|Исходя из озвученных задач — наверное, даже Cat2960 сгодится. Он должен осилить line rate по всем портам.
Дмитрий, простите великодушно. Мне просто в голову не могл прийти что вы подумаете про FastEthernet.
Конечно-же минимальная скорость портов в коробке 10Gbps.
Дмитрий, простите великодушно. Мне просто в голову не могл прийти что вы подумаете про FastEthernet.
Конечно-же минимальная скорость портов в коробке 10Gbps.
Мне просто в голову не могл прийти что вы подумаете про FastEthernet.
Так учитесь формулировать задачи :)
Хорошо, тогда относительно универсальный вариант (так как я все равно не понял, где у вас что-либо специфическое и необычное) — Nexus 5672. Обещан полный line rate на любых пакетах. Тестируйте. Для 40G портов можете взять, скажем, 6004.
|Рассматривая вендоров второго эшелона
Нам вообще все-равно какие «лычки» на вендоре, не очень увлекательное и дорогое занятие ;)
Нам вообще все-равно какие «лычки» на вендоре, не очень увлекательное и дорогое занятие ;)
|Ну и, конечно, вы отдавали им приватные ключи? Боюсь, на такое немного кто может пойти, а без этого много не нафильтруешь.
Дима, ну ознакомьтесь с мат.частью. Одна из «фишек» Qrator это фильтрация SSL L7 без раскрытия приватных ключей.
Ну что за троллинг неуместный :(
Дима, ну ознакомьтесь с мат.частью. Одна из «фишек» Qrator это фильтрация SSL L7 без раскрытия приватных ключей.
Ну что за троллинг неуместный :(
Лямин != Ленин :)
В чем-то Дмитрий прав. Административка жрет кучу времени. НО, это еще не повод забить на любимое дело ;)
В чем-то Дмитрий прав. Административка жрет кучу времени. НО, это еще не повод забить на любимое дело ;)
Дмитрий, а какие Cisco-switches вы порекомендуете в качестве loadbalancer для фермы очистки трафика?
Можно эти свитчи к нам в лабу пригласить, чтобы воздух здесь не сотрясать?
Можно эти свитчи к нам в лабу пригласить, чтобы воздух здесь не сотрясать?
Свитч? В роли loadbalancer? Уже интересно. Опишите для начала задачу.
Кстати, на DPSS не смотрели?
Кстати, на DPSS не смотрели?
да все просто…
a. есть inbound LACP на 4-8 портов.
b. есть outbound 8-16 портов на которых живет ферма очистителей. Прилетевшие пакеты надо распихать так, чтобы поток определялся в пару портов и к ней привязывался на все время своего существования.
потоки желательно распихивать по портам не только в режиме roundrobin но и по весам портов.
Bonus track:
желательно чтобы на выходе тоже была LACP, а не еденичный порт.
bgp flowspec (limited capability)
a. есть inbound LACP на 4-8 портов.
b. есть outbound 8-16 портов на которых живет ферма очистителей. Прилетевшие пакеты надо распихать так, чтобы поток определялся в пару портов и к ней привязывался на все время своего существования.
потоки желательно распихивать по портам не только в режиме roundrobin но и по весам портов.
Bonus track:
желательно чтобы на выходе тоже была LACP, а не еденичный порт.
bgp flowspec (limited capability)
Прилетевшие пакеты надо распихать так, чтобы поток определялся в пару портов и к ней привязывался на все время своего существования.
Это — стандарт. Любой свитч обязан так уметь. Per-packet loadsharing мертв.
потоки желательно распихивать по портам не только в режиме roundrobin но и по весам портов.
См. «802.3ad LAG with WLB». Смысл данного действия в случае LACP мне не очень понятен, но как угодно.
Итого — «берите любой свитч». Ну практически. Вроде weight для LACP появился лишь несколько лет назад, т.е. надо смотреть версию софта. Все остальное скучно и банально. Не понимаю, какие у вас могли появиться затруднения…
bgp flowspec (limited capability)
Нехарактерная фича для коммутаторов. Ну что же, можете посмотреть на ASR9k. Если есть AM в циске — можете спросить, когда выйдет для NX-OS и IOS.
|Если есть AM в циске — можете спросить, когда выйдет для NX-OS и IOS.
Оно «на роадмапе» последних года 3 как ;)
Да, фича нехарактерная, но полезная и в Ариста мы ее себе «докрутили».
Оно «на роадмапе» последних года 3 как ;)
Да, фича нехарактерная, но полезная и в Ариста мы ее себе «докрутили».
|См. «802.3ad LAG with WLB». Смысл данного действия в случае LACP мне не очень понятен, но как угодно.
Вполне разумно распределять трафик с учетом загрузки очистителей? Разве нет? Что тут непонятного?
Вполне разумно распределять трафик с учетом загрузки очистителей? Разве нет? Что тут непонятного?
Вполне разумно распределять трафик с учетом загрузки очистителей?
У них 10G интерфейсы? Вы работаете с DDOS, то есть вал примерно одинакового и отлично параллелящегося трафика? У вас примерно одинаковые по производительности очистители? Да, мне непонятно, зачем вызывать неравномерную нагрузку на интерфейсы.
| то есть вал примерно одинакового и отлично параллелящегося трафика?
Умываю руки.
Элвис покинул здание…
Умываю руки.
Элвис покинул здание…
И впрямь. Видимо, DDOS — это мало тяжелых по трафику сессий, а не очень очень сравнительно небольших. Век живи, век учись.
Ну и все-таки при случае опишите методику тестирования свитчей. Всё, что я услышал, под силу самому простому железу, никаких наворотов нет, и мне кажется очень подозрительным, что только продукция одного вендора, принципиально не использующего ничего кроме merchant silicon, выдерживает испытание.
Ну и по «wirespeed + 0-drop» тоже мечтаю услышать поподробнее — про такие требования не каждый день слышишь, и под них целая куча костылей придумана (см. FCoE, где, в отличие от сервиса по защите от DDOS, каждый потерянный пакет — действительно серьезная проблема).
Ну и все-таки при случае опишите методику тестирования свитчей. Всё, что я услышал, под силу самому простому железу, никаких наворотов нет, и мне кажется очень подозрительным, что только продукция одного вендора, принципиально не использующего ничего кроме merchant silicon, выдерживает испытание.
Ну и по «wirespeed + 0-drop» тоже мечтаю услышать поподробнее — про такие требования не каждый день слышишь, и под них целая куча костылей придумана (см. FCoE, где, в отличие от сервиса по защите от DDOS, каждый потерянный пакет — действительно серьезная проблема).
и вы опустили совершенно вот этот момент ;)
|b. есть outbound 8-16 портов на которых живет ферма очистителей. Прилетевшие пакеты надо распихать так, чтобы поток определялся в пару портов и к ней привязывался на все время своего существования
|b. есть outbound 8-16 портов на которых живет ферма очистителей. Прилетевшие пакеты надо распихать так, чтобы поток определялся в пару портов и к ней привязывался на все время своего существования
Прилетевшие пакеты надо распихать так, чтобы поток определялся в пару портов и к ней привязывался на все время своего существования
Разумеется. Считается хеш от 5-tuple, назначается соответствующему bucket'у. Пока что-то не изменится в конфигурации портов — поток будет прибит к соответствующему порту. Стандартный функционал, причем stateless.
Arista скотски дорога по сравнению с похожими Juni, например.
Но в лабе нам ее запинать не получилось, включая advanced features как ECMP. Плюс SDK модный, что для нас важно. Вообщем для нас, с нашими паттернами трафика и иногда странными «хотелками» альтернатив Arista пока нет.
А еще у аристы время на обработку пакета практически константа ;)
Но в лабе нам ее запинать не получилось, включая advanced features как ECMP. Плюс SDK модный, что для нас важно. Вообщем для нас, с нашими паттернами трафика и иногда странными «хотелками» альтернатив Arista пока нет.
А еще у аристы время на обработку пакета практически константа ;)
Но в лабе нам ее запинать не получилось, включая advanced features как ECMP
Что-что? Advanced фича? ECMP? Который на знакомом мне оборудовании работает изначально, из коробки?
А еще у аристы время на обработку пакета практически константа
При «самых больших буферах на рынке», хе-хе. Все-таки было бы здорово узнать, каким образом вы тестируете оборудование, что результаты напрочь противоречат здравому смыслу. Кстати, ариста может дать детальную статистику по времени прохождения пакетов и слать алерт при превышении указанного порога в наносекундах, а заодно выплюнуть задержанный излишне долго (или дропнутый) пакет в SPAN порт, но не выплевывать туда нормальный трафик?
Любопытства ради. А какое вашей конторе дело до сотен наносекунд или единиц микросекунд? Трафик же приходит от провайдеров и затем уходит провайдерам, теряются миллисекунды или их десятки.
Ну они противоречат вашему восприятию здравого смысла. Не более и не менее.
Зачем сложности со SPAN, если можно просто мерять drop.
Для нас принципиально: wirespeed + 0-drop.
С этим, на наших обьемах трафика и пакетрейте для вендоров это обычно проблема ;)
Arista стала приятным исключением.
Precision timestamping? Да, поддерживается. И очистителями и Arista.
Микро и нано-секунды имеют дурацкую привычку суммироваться. Вот так по-мелочи и набегает :(
Плюс, некоторые «кишки» не очень любят latency внутри площадки одной.
Зачем сложности со SPAN, если можно просто мерять drop.
Для нас принципиально: wirespeed + 0-drop.
С этим, на наших обьемах трафика и пакетрейте для вендоров это обычно проблема ;)
Arista стала приятным исключением.
Precision timestamping? Да, поддерживается. И очистителями и Arista.
Микро и нано-секунды имеют дурацкую привычку суммироваться. Вот так по-мелочи и набегает :(
Плюс, некоторые «кишки» не очень любят latency внутри площадки одной.
Для нас принципиально: wirespeed + 0-drop.
То есть ECN и прочие плюшки? У вас развернут DCB? Каким образом сигнализируете провайдерам о надобности замедлить передачу пакетов, и до какого уровня они слушаются?
на наших обьемах трафика и пакетрейте для вендоров это обычно проблема
Какие объемы и какой пакетрейт? Десятки гигабит? Сотни гигабит? Это не должно вызвать проблем на современных чипах.
Микро и нано-секунды имеют дурацкую привычку суммироваться.
Их не надо суммировать. Представьте себе, например, трубопровод, по которому идет газ. Вот он запущен. Вас сильно заботит, сколько времени каждая конкретная молекула путешествует по тому трубопроводу? :)
некоторые «кишки» не очень любят latency внутри площадки одной.
Так про какой именно latency идет речь? Есть очень мало задач, которые чувствительны к единицам микросекунд.
>У Cisco это все маркетинговая разводка и реально сильно плавает.
>У артисты как раз не важно какой размер и функционал, даже для L4 лейтенси остается такой-же.
Ну положим это тоже маркетинговое гонево, и задержка будет плавать у любых cut-through свитчей при достаточном трафике. Если считали заголовок пришедшего пакета, применили rewrite'ы и выбрали исходящий порт, но в текущий момент времени в тот порт уже кто-то лезет — пакет будет буферизирован. Без вариантов — чудес не бывает, два пакета разом по одному патч-корду передать не получится. Задержка сразу же взлетает в разы.
В общем, я смотрю, Arista очень хорошо работает в плане промывания мозгов :)
>У артисты как раз не важно какой размер и функционал, даже для L4 лейтенси остается такой-же.
Ну положим это тоже маркетинговое гонево, и задержка будет плавать у любых cut-through свитчей при достаточном трафике. Если считали заголовок пришедшего пакета, применили rewrite'ы и выбрали исходящий порт, но в текущий момент времени в тот порт уже кто-то лезет — пакет будет буферизирован. Без вариантов — чудес не бывает, два пакета разом по одному патч-корду передать не получится. Задержка сразу же взлетает в разы.
В общем, я смотрю, Arista очень хорошо работает в плане промывания мозгов :)
Ну реально, не надо «ля-ля».
Я понимаю что зарабатываешь на Cisco и «жизнь положена» на них, но с точки зрения реальной лейтенси (да и тонны других точек зрения) — Arista «рвет» коммутаторы Cisco (включая топовые / high-end) как тузик грелку.
Мир меняется, селяви.
Дело в том что у нас в Nutanix все очень жестко завязано на качественно работающую сеть и лейтенси. Так вот — в мире наибольшее количество проблем у клиентов — это с Nexus. Печальная статистка.
По Аристам статистика — проблем практически ноль.
И да, я не работаю на Аристу — мне просто для решения моих задач (построения сверхплотных / быстрых инфраструктур) нужны максимально надежные и предсказуемые коммутаторы.
Я понимаю что зарабатываешь на Cisco и «жизнь положена» на них, но с точки зрения реальной лейтенси (да и тонны других точек зрения) — Arista «рвет» коммутаторы Cisco (включая топовые / high-end) как тузик грелку.
Мир меняется, селяви.
Дело в том что у нас в Nutanix все очень жестко завязано на качественно работающую сеть и лейтенси. Так вот — в мире наибольшее количество проблем у клиентов — это с Nexus. Печальная статистка.
По Аристам статистика — проблем практически ноль.
И да, я не работаю на Аристу — мне просто для решения моих задач (построения сверхплотных / быстрых инфраструктур) нужны максимально надежные и предсказуемые коммутаторы.
>Я понимаю что зарабатываешь на Cisco и «жизнь положена» на них
Беда… Вы, кажется, всерьез считаете, что сетевики знают в основном не «как устроены протоколы и технологии», а «как настраивать железки». Очень печальная точка зрения.
>но с точки зрения реальной лейтенси (да и тонны других точек зрения) — Arista «рвет» коммутаторы Cisco (включая топовые / high-end) как тузик грелку.
Про какой именно хай-енд идет речь? Назовите конкретные модели и методику сравнения. И почему я не знаю про существование у циски high-end low-latency свитчей? Вы вообще с чем сравнивали? Может, с каким-нибудь шеститонником?
Перестаньте быть голословным. Называйте конкретные модели оборудования и конкретные методики тестирования и проблемы.
>в мире наибольшее количество проблем у клиентов — это с Nexus. Печальная статистка.
>По Аристам статистика — проблем практически ноль.
Почему-то сходу напрашивается объяснение «потому что в мире наибольшее количество клиентов владеет нексусами, а у практически нуля клиентов — аристы». Впрочем, да, я допускаю, что у аристы софт стабильнее будет. У циски с этим не первый десяток лет беда.
>мне просто для решения моих задач (построения сверхплотных / быстрых инфраструктур) нужны максимально надежные и предсказуемые коммутаторы.
Если вы строите сети, но не понимаете даже самой базовой теории (например, чем cut-through отличается от store-and-forward и в каких случаях первый становится вторым), то у меня для вас плохие новости. И для тех людей, которым вы строите инфраструктуры, тоже.
Давайте так. Вот есть некоторый коммутатор (пусть будет ариста). У него поднято три порта. В первые два с интервалом в одну наносекунду начинает поступать по пакету, оба пакета адресованы третьему порту. Вопрос — что дальше происходит с этими пакетами, и с какой задержкой они будут переданы дальше?
Беда… Вы, кажется, всерьез считаете, что сетевики знают в основном не «как устроены протоколы и технологии», а «как настраивать железки». Очень печальная точка зрения.
>но с точки зрения реальной лейтенси (да и тонны других точек зрения) — Arista «рвет» коммутаторы Cisco (включая топовые / high-end) как тузик грелку.
Про какой именно хай-енд идет речь? Назовите конкретные модели и методику сравнения. И почему я не знаю про существование у циски high-end low-latency свитчей? Вы вообще с чем сравнивали? Может, с каким-нибудь шеститонником?
Перестаньте быть голословным. Называйте конкретные модели оборудования и конкретные методики тестирования и проблемы.
>в мире наибольшее количество проблем у клиентов — это с Nexus. Печальная статистка.
>По Аристам статистика — проблем практически ноль.
Почему-то сходу напрашивается объяснение «потому что в мире наибольшее количество клиентов владеет нексусами, а у практически нуля клиентов — аристы». Впрочем, да, я допускаю, что у аристы софт стабильнее будет. У циски с этим не первый десяток лет беда.
>мне просто для решения моих задач (построения сверхплотных / быстрых инфраструктур) нужны максимально надежные и предсказуемые коммутаторы.
Если вы строите сети, но не понимаете даже самой базовой теории (например, чем cut-through отличается от store-and-forward и в каких случаях первый становится вторым), то у меня для вас плохие новости. И для тех людей, которым вы строите инфраструктуры, тоже.
Давайте так. Вот есть некоторый коммутатор (пусть будет ариста). У него поднято три порта. В первые два с интервалом в одну наносекунду начинает поступать по пакету, оба пакета адресованы третьему порту. Вопрос — что дальше происходит с этими пакетами, и с какой задержкой они будут переданы дальше?
Я не считаю что не знают «как устроены». Я считаю что не знают архитектуры конкретных решений.
Обладая очень большим опытом (я строил проекты в тч на сотни миллионов пользователей типа Badoo.com, всю тех часть включая сетевую инфраструктуру), я при этом исхожу из бизнес-логики в том числе.
На аристе я ни разу не видел проблем с лейтенси, на Nexus вижу постоянно. И не только с лейтенси. И не надо мне рассказывать «про не умею готовить». Умею, еще как.
Хочется спорить о деталях аппаратной реализации — можно подтащить инженеров Аристы.
По пакетам «в одну наносекунду» — какие проблемы-то?
Аристы имеют одни из самых больших буферов на рынке (даже единственная 1G модель), нет ни одного коммутатора с переподпиской (чем активно грешит в т.ч. Cisco), никаких извратов типа экстендеров на Нексусах и прочего.
Если вы пытаетесь влить в 10G порт 20G трафика — очевидно, это нереально. Впрочем за 20-30$k взять 2U коробку аристы с 96x10G портов + 8x40G — и проблем с аплинками не будет.
Реально, хочется спорить — рекомендую с инженерами Аристы.
Но не даром даже начальник отдела разработки Cisco ушла в Аристу.
На аристе я ни разу не видел проблем с лейтенси, на Nexus вижу постоянно. И не только с лейтенси. И не надо мне рассказывать «про не умею готовить». Умею, еще как.
Хочется спорить о деталях аппаратной реализации — можно подтащить инженеров Аристы.
По пакетам «в одну наносекунду» — какие проблемы-то?
Аристы имеют одни из самых больших буферов на рынке (даже единственная 1G модель), нет ни одного коммутатора с переподпиской (чем активно грешит в т.ч. Cisco), никаких извратов типа экстендеров на Нексусах и прочего.
Если вы пытаетесь влить в 10G порт 20G трафика — очевидно, это нереально. Впрочем за 20-30$k взять 2U коробку аристы с 96x10G портов + 8x40G — и проблем с аплинками не будет.
Реально, хочется спорить — рекомендую с инженерами Аристы.
Но не даром даже начальник отдела разработки Cisco ушла в Аристу.
Очень много здесь намешано.
Cisco не грешит переподпиской(звучит-то как). Открыто заявляет, что есть такое и в каких пропорциях и на каких группах портов. Если нужна неблокирующая производительность, то всегда найдется такой модуль. Если у конкурентов этого нет, то это скорее недостаток. Не вижу здесь почвы для неприязни или наоборот. Каждый выбирает по кошельку и надобностям.
96х10Г пффф, не впечатлен. Как насчет 36х40Г в тех же двух юнитах? Это 144х10Г неблокируемой производительности. И это все равно больше даже с учетом +8х40Г портов.
Про буферы и cut-through тоже очень странное заявление. Много буферов — больше задержка :)
FEX далеко не изврат. То что он вам не нужен, не значит, что это плохое решение.
Спорить можно много. Я специализируюсь как раз на архитектурах и внутренностях этих железок. Могу открыть тайну, большенство из них сделано на одном и том же merchant silicon, что ариста что cisco. trident 2 до сих пор рулит. Но вот главное отличие cisco от ариста. Ариста не делает своих ASIC. Это у них принцип такой. А cisco делает, и это серъезный вклад в увеличение производительности. У конкурентов просто тупо неоткуда взять большей производительности чем купить у дяди, а там купить каждый может. Хоть dlink.
Проблемы точно есть на любом оборудовании, не важно кто вендор. Если ни разу не встречался, то это как с сусликом.
Но не даром даже начальник отдела разработки Cisco ушла в Аристу.Это не так, как Вы говорите. Нужно знать как устроена Cisco чтобы делать такие заявления. Звучит громко, но на самом деле все иначе.
Cisco не грешит переподпиской(звучит-то как). Открыто заявляет, что есть такое и в каких пропорциях и на каких группах портов. Если нужна неблокирующая производительность, то всегда найдется такой модуль. Если у конкурентов этого нет, то это скорее недостаток. Не вижу здесь почвы для неприязни или наоборот. Каждый выбирает по кошельку и надобностям.
96х10Г пффф, не впечатлен. Как насчет 36х40Г в тех же двух юнитах? Это 144х10Г неблокируемой производительности. И это все равно больше даже с учетом +8х40Г портов.
Про буферы и cut-through тоже очень странное заявление. Много буферов — больше задержка :)
FEX далеко не изврат. То что он вам не нужен, не значит, что это плохое решение.
Спорить можно много. Я специализируюсь как раз на архитектурах и внутренностях этих железок. Могу открыть тайну, большенство из них сделано на одном и том же merchant silicon, что ариста что cisco. trident 2 до сих пор рулит. Но вот главное отличие cisco от ариста. Ариста не делает своих ASIC. Это у них принцип такой. А cisco делает, и это серъезный вклад в увеличение производительности. У конкурентов просто тупо неоткуда взять большей производительности чем купить у дяди, а там купить каждый может. Хоть dlink.
Проблемы точно есть на любом оборудовании, не важно кто вендор. Если ни разу не встречался, то это как с сусликом.
". Звучит громко, но на самом деле все иначе."
О да ;)
www.arista.com/en/company/management-team
Jayshree Ullal
President and Chief Executive Officer
Jayshree Ullal is a networking executive veteran with 25+ years of experience and was named one of the «50 Most Powerful People» in 2005 Network World and one of the «Top Ten Executives» at VMWorld 2011. As President and CEO of Arista Networks, she is responsible for building the company's business in cloud networking.
Formerly, Jayshree was Senior Vice President at Cisco and responsible for $10B in annual revenue from Data Center, Switching and Services, including Cisco's flagship Nexus 7000 and Catalyst 4500 and 6500 product lines.
По поводу «своих ASIC» — это скорее (и даже — точнее) реальный минус, нежели плюс.
То что делается все на одинаковом кремнии — это давно известный факт, мне смешно слышать про это как «секрет».
Делается все в том числе на fulcrum, приобретенным не столько Intel.
Ариста делает свое ПО (которое реально по архитектуре одно из лучших, если не лучшее решение) + обвязку.
Так-же как сейчас на рынке из generic производителей X86 CPU остался реально один игрок — Intel, и никто от этого не стенает, выпуская множество различных интересных решений с совершенно разной функциональностью и надежностью.
«буферы и cut-through тоже очень странное заявлени» — если вдумчиво читать, то ничего странного нет.
Если пытаться запихать невпихуемое (два порта 10-ки лить в один), то тут как-то помогут только буфера.
Собственно, поэтому единственный 1G коммутатор у Аристы сделан с очень большими буферами.
«FEX далеко не изврат.» о да. Дополнительные точки отказа, почти всегда — переподписка и прочие радости. Мы (в Nutanix) уже фактически запрещаем клиентам использовать FEX, ввиду крайне серьезных проблем производительности и постоянно жестко прыгающей лейтенси.
" Это 14х10Г неблфкируемой производительности" — ну надо же, 1.44 терабита на 2U? :)
Смотрим на Arista 7280SE-72 — и что видим? Да, 1.44 терабита. В 1U. И что и где там «больше»?
О да ;)
www.arista.com/en/company/management-team
Jayshree Ullal
President and Chief Executive Officer
Jayshree Ullal is a networking executive veteran with 25+ years of experience and was named one of the «50 Most Powerful People» in 2005 Network World and one of the «Top Ten Executives» at VMWorld 2011. As President and CEO of Arista Networks, she is responsible for building the company's business in cloud networking.
Formerly, Jayshree was Senior Vice President at Cisco and responsible for $10B in annual revenue from Data Center, Switching and Services, including Cisco's flagship Nexus 7000 and Catalyst 4500 and 6500 product lines.
По поводу «своих ASIC» — это скорее (и даже — точнее) реальный минус, нежели плюс.
То что делается все на одинаковом кремнии — это давно известный факт, мне смешно слышать про это как «секрет».
Делается все в том числе на fulcrum, приобретенным не столько Intel.
Ариста делает свое ПО (которое реально по архитектуре одно из лучших, если не лучшее решение) + обвязку.
Так-же как сейчас на рынке из generic производителей X86 CPU остался реально один игрок — Intel, и никто от этого не стенает, выпуская множество различных интересных решений с совершенно разной функциональностью и надежностью.
«буферы и cut-through тоже очень странное заявлени» — если вдумчиво читать, то ничего странного нет.
Если пытаться запихать невпихуемое (два порта 10-ки лить в один), то тут как-то помогут только буфера.
Собственно, поэтому единственный 1G коммутатор у Аристы сделан с очень большими буферами.
«FEX далеко не изврат.» о да. Дополнительные точки отказа, почти всегда — переподписка и прочие радости. Мы (в Nutanix) уже фактически запрещаем клиентам использовать FEX, ввиду крайне серьезных проблем производительности и постоянно жестко прыгающей лейтенси.
" Это 14х10Г неблфкируемой производительности" — ну надо же, 1.44 терабита на 2U? :)
Смотрим на Arista 7280SE-72 — и что видим? Да, 1.44 терабита. В 1U. И что и где там «больше»?
>По поводу «своих ASIC» — это скорее (и даже — точнее) реальный минус, нежели плюс.
То есть поддержка дополнительного функционала — это плохо. Ну хоть к примеру ACI в N9K. Класс.
d2zmdbbm9feqrf.cloudfront.net/2014/anz/pdf/BRKDCT-3640.pdf — на страницах 8-9 можете посмотреть, чем циску не устроил Trident 2.
>Ариста делает свое ПО (которое реально по архитектуре одно из лучших, если не лучшее решение) + обвязку.
И всё? А как же их инновации, про которые вы как-то забыли рассказать? И заодно, раз вы обладаете достаточными знаниями для сравнения программных архитектур — назовите конкретные преимущества аристиного софта по сравнению с NX-OS.
>Если пытаться запихать невпихуемое (два порта 10-ки лить в один), то тут как-то помогут только буфера.
Ну-ка с этого места поподробнее. Как именно (в каком случае) большие буфера помогут впихнуть 2х10G в 1x10G? И как быть с задержкой?
У меня возникает ощущение, что вы вообще не понимаете назначение пакетного буфера.
>Дополнительные точки отказа, почти всегда — переподписка и прочие радости.
Фекс — это не большая точка отказа, чем, скажем, линейная карта. Он фактически и является безмозглой линейной картой.
Переподписка — дело сугубо добровольное. Ничто не мешает воткнуться так, чтобы ее не было. Если надо. Большинству не надо, их более чем устраивает классическое датацентровое 1:3.
>" Это 14х10Г неблфкируемой производительности" — ну надо же, 1.44 терабита на 2U? :)
Вы как-то плохо считаете. Обычно вендоры выводят «терабиты на юнит/слот» из суммарной емкости портов помножить на два (ибо full duplex). Так что на самом деле. 2.88тб/с на два юнита. Ваша ариста — 48 x SFP+, 2 x MXP. Рядом с 36х40G выглядит раза в два более уныло, то есть емкость на юнит одинаковая… Кстати, у аристы есть компактные свитчи уровня агрегации с таким количеством 40G портов?
Htol говорил про www.cisco.com/c/en/us/products/switches/nexus-9336pq-aci-spine-switch/index.html. Это — ACI свитч, с точки зрения функционала data plane сравнивать с ним аристу — это как сравнивать пятилетнего ребенка с Вассерманом :) Ну совершенно разные весовые категории.
Если надо в одном юните, то посмотрите на 5672UP. Те же 1.44тб/с.
То есть поддержка дополнительного функционала — это плохо. Ну хоть к примеру ACI в N9K. Класс.
d2zmdbbm9feqrf.cloudfront.net/2014/anz/pdf/BRKDCT-3640.pdf — на страницах 8-9 можете посмотреть, чем циску не устроил Trident 2.
>Ариста делает свое ПО (которое реально по архитектуре одно из лучших, если не лучшее решение) + обвязку.
И всё? А как же их инновации, про которые вы как-то забыли рассказать? И заодно, раз вы обладаете достаточными знаниями для сравнения программных архитектур — назовите конкретные преимущества аристиного софта по сравнению с NX-OS.
>Если пытаться запихать невпихуемое (два порта 10-ки лить в один), то тут как-то помогут только буфера.
Ну-ка с этого места поподробнее. Как именно (в каком случае) большие буфера помогут впихнуть 2х10G в 1x10G? И как быть с задержкой?
У меня возникает ощущение, что вы вообще не понимаете назначение пакетного буфера.
>Дополнительные точки отказа, почти всегда — переподписка и прочие радости.
Фекс — это не большая точка отказа, чем, скажем, линейная карта. Он фактически и является безмозглой линейной картой.
Переподписка — дело сугубо добровольное. Ничто не мешает воткнуться так, чтобы ее не было. Если надо. Большинству не надо, их более чем устраивает классическое датацентровое 1:3.
>" Это 14х10Г неблфкируемой производительности" — ну надо же, 1.44 терабита на 2U? :)
Вы как-то плохо считаете. Обычно вендоры выводят «терабиты на юнит/слот» из суммарной емкости портов помножить на два (ибо full duplex). Так что на самом деле. 2.88тб/с на два юнита. Ваша ариста — 48 x SFP+, 2 x MXP. Рядом с 36х40G выглядит раза в два более уныло, то есть емкость на юнит одинаковая… Кстати, у аристы есть компактные свитчи уровня агрегации с таким количеством 40G портов?
Htol говорил про www.cisco.com/c/en/us/products/switches/nexus-9336pq-aci-spine-switch/index.html. Это — ACI свитч, с точки зрения функционала data plane сравнивать с ним аристу — это как сравнивать пятилетнего ребенка с Вассерманом :) Ну совершенно разные весовые категории.
Если надо в одном юните, то посмотрите на 5672UP. Те же 1.44тб/с.
>На аристе я ни разу не видел проблем с лейтенси, на Nexus вижу постоянно.
Так конкретнее говорите. Что за проблемы, как и в каких условиях проявляются, на каких нексусах (они все очень-очень разные)?
>И не надо мне рассказывать «про не умею готовить». Умею, еще как.
Есть у меня некоторые обоснованные сомнения…
>По пакетам «в одну наносекунду» — какие проблемы-то?
>Аристы имеют одни из самых больших буферов на рынке
Я чуть перефразирую это.
«У аристы наибольший джиттер среди всех коммутаторов на рынке».
Именно поэтому сейчас предпочитают снижать размер буферов. В общем случае потерять пакет правильнее, чем держать его в очереди бешеное количество времени.
Но выше вы утверждаете, что у аристы наименьший джиттер, что подразумевает небольшие буфера. Что-то не сходится…
Дальше. Как считаете, как изменится задержка для пришедшего вторым пакета на cut-through свитче? Раньше вы утверждали, что она будет константной и равной заявленной задержки в сотни миллисекунд. Это так?
>никаких извратов типа экстендеров на Нексусах
То есть вы считаете сам факт поддержки весьма удобной технологии недостатком? Ведь у всех технологий свои применения. Фексы удобны там, где нет сотен гигабит в секунду трафика и хочется централизованного управления…
> хочется спорить — рекомендую с инженерами Аристы.
То есть вы не знаете, как устроено их оборудование? Меня прямо-таки съедает любопытство — как вы умудряетесь что-то проектировать? Или вы занимаетесь высокоуровневой архитектурой, а выбором железок и их конфигурацией занимаются другие?
Выше вы утверждаете, что у аристы какие-то потрясающие ноу-хау. Расскажите про них. Для начала я вынужден заметить, что они используют те же самые броадкомовские чипы, что и почти все остальные игроки на рынке, что делает практически невозможным наличие у них killer-фич в data plane. Вот циска за бешеные деньги проектирует собственные чипы, опережающие merchant silicon на несколько лет.
>Но не даром даже начальник отдела разработки Cisco ушла в Аристу.
О да, менеджеры переходят к конкурентам только потому что им больше нравятся железки конкурентов, конечно, других причин не бывает :)
Вам очень сильно промыли мозги. Честно. Включайте критическое мышление и старайтесь думать объективно.
/add: отвлекся минут на 10, вернулся, нажал «отправить», а выше уже почти то же самое написали…
Так конкретнее говорите. Что за проблемы, как и в каких условиях проявляются, на каких нексусах (они все очень-очень разные)?
>И не надо мне рассказывать «про не умею готовить». Умею, еще как.
Есть у меня некоторые обоснованные сомнения…
>По пакетам «в одну наносекунду» — какие проблемы-то?
>Аристы имеют одни из самых больших буферов на рынке
Я чуть перефразирую это.
«У аристы наибольший джиттер среди всех коммутаторов на рынке».
Именно поэтому сейчас предпочитают снижать размер буферов. В общем случае потерять пакет правильнее, чем держать его в очереди бешеное количество времени.
Но выше вы утверждаете, что у аристы наименьший джиттер, что подразумевает небольшие буфера. Что-то не сходится…
Дальше. Как считаете, как изменится задержка для пришедшего вторым пакета на cut-through свитче? Раньше вы утверждали, что она будет константной и равной заявленной задержки в сотни миллисекунд. Это так?
>никаких извратов типа экстендеров на Нексусах
То есть вы считаете сам факт поддержки весьма удобной технологии недостатком? Ведь у всех технологий свои применения. Фексы удобны там, где нет сотен гигабит в секунду трафика и хочется централизованного управления…
> хочется спорить — рекомендую с инженерами Аристы.
То есть вы не знаете, как устроено их оборудование? Меня прямо-таки съедает любопытство — как вы умудряетесь что-то проектировать? Или вы занимаетесь высокоуровневой архитектурой, а выбором железок и их конфигурацией занимаются другие?
Выше вы утверждаете, что у аристы какие-то потрясающие ноу-хау. Расскажите про них. Для начала я вынужден заметить, что они используют те же самые броадкомовские чипы, что и почти все остальные игроки на рынке, что делает практически невозможным наличие у них killer-фич в data plane. Вот циска за бешеные деньги проектирует собственные чипы, опережающие merchant silicon на несколько лет.
>Но не даром даже начальник отдела разработки Cisco ушла в Аристу.
О да, менеджеры переходят к конкурентам только потому что им больше нравятся железки конкурентов, конечно, других причин не бывает :)
Вам очень сильно промыли мозги. Честно. Включайте критическое мышление и старайтесь думать объективно.
/add: отвлекся минут на 10, вернулся, нажал «отправить», а выше уже почти то же самое написали…
… Мне помнится мы года 4 назад сдавали Nexus 5000-е в утилизацию / уничтожение (Juniper дал под это дело 85% скидки), ввиду того что эти железки даже на чистом L2 висли (Cisco меняла несколько раз лайн-карты). Можно расспросить DmitryVolodin (он сейчас в Ростелекоме)
Он расскажет явно много интересного про Nexus'ы.
Не cтоит рассказывать про промытие мозгов — я строю и эксплуатирую (разные, включая огромные) IT инфраструктуры.
Где сеть это всего лишь один из элементов.
Статистика по Cisco — крайне плохая, у множества клиентов реальные проблемы.
Статистика по Arista — проблем практически ноль.
При этом мне откровенно не очень важны детали проблем на глубоком уровне.
Лично я (от лица компании) бодался с Cisco несколько лет (!), они не могли исправить серьезнейшие / критикал баги ПО. Доходили до вице-президентов.
В итоге Cisco согласилось списать это оборудование (и даже не стали у нас его забирать — так-где то и валяется в ДЦ насколько помню) с зачетом денег в счет следующих закупок.
Это было кстати в Badoo.
При этом 6-тонники у Cisco были чрезвычайно хороши, это никто не пытается оспаривать. Для своего времени — потрясающе хорошее железо и лидер рынка.
«То есть вы не знаете, как устроено их оборудование? » — знаю, причем достаточно детально.
Мне просто не интересно с вами спорить — для меня сетевая инфраструктура лишь один из элементов (крайне важный, но далеко не самый).
Очевидно, спорить сетевым инженерам лучше между собой.
Он расскажет явно много интересного про Nexus'ы.
Не cтоит рассказывать про промытие мозгов — я строю и эксплуатирую (разные, включая огромные) IT инфраструктуры.
Где сеть это всего лишь один из элементов.
Статистика по Cisco — крайне плохая, у множества клиентов реальные проблемы.
Статистика по Arista — проблем практически ноль.
При этом мне откровенно не очень важны детали проблем на глубоком уровне.
Лично я (от лица компании) бодался с Cisco несколько лет (!), они не могли исправить серьезнейшие / критикал баги ПО. Доходили до вице-президентов.
В итоге Cisco согласилось списать это оборудование (и даже не стали у нас его забирать — так-где то и валяется в ДЦ насколько помню) с зачетом денег в счет следующих закупок.
Это было кстати в Badoo.
При этом 6-тонники у Cisco были чрезвычайно хороши, это никто не пытается оспаривать. Для своего времени — потрясающе хорошее железо и лидер рынка.
«То есть вы не знаете, как устроено их оборудование? » — знаю, причем достаточно детально.
Мне просто не интересно с вами спорить — для меня сетевая инфраструктура лишь один из элементов (крайне важный, но далеко не самый).
Очевидно, спорить сетевым инженерам лучше между собой.
>Мне помнится мы года 4 назад сдавали Nexus 5000-е в утилизацию… ввиду того что эти железки даже на чистом L2 висли
А с тех пор (линейка 5к уже давно EOL) вы ни разу с NX-OS устройствами не работали? И при этом говорите про современное состояние дел?
>ввиду того что эти железки даже на чистом L2 висли
Да они ничего кроме чистого L2 отродясь не умели… Но что значит «висли»? В каких условиях и как это выглядело?
>Cisco меняла несколько раз лайн-карты
А вот с этого момента поподробнее — что-то не сходится. N5K — свитч с фиксированной конфигурацией, в который можно добавить еще несколько портов. Допустим, менялись модули расширения. Так проблема была с ними, или со встроенными портами?
>Можно расспросить DmitryVolodin (он сейчас в Ростелекоме)
Интересно, вы сами хоть что-то можете сказать? :) Ну и надо ли говорить, что у оператора очень редко можно встретить датацентровое железо?
>Не cтоит рассказывать про промытие мозгов — я строю и эксплуатирую (разные, включая огромные) IT инфраструктуры.
Это очень печально, что при этом вы не знаете, как ваши инфраструктуры работают.
>Статистика по Cisco — крайне плохая, у множества клиентов реальные проблемы.
>Статистика по Arista — проблем практически ноль.
Так опять же — если сравнить доли рынка, то напрашивается очевидный вывод. А еще нормальна ситуация, когда люди поднимают функционал вроде того же vPC, не удосужившись изучить, как он работает, а дальше постоянно страдают.
Просто меня удивляют ваши наезды на нексусы, так как я сам ими пользуюсь, знаю немало весьма довольных ими людьми, а недовольных не знаю. Проблемы бывают, но все быстро решаются. А тут какой-то недо-архитектор на основании шапочного знакомства с людьми, немного работавшими с давно снятыми с производства свитчами, объявляет всю линейку очень популярного оборудования хламом. Странно как-то, и немного нелогично. Тем более что все нексусы разные, и даже 5500 очень сильно отличается от 5000…
>При этом мне откровенно не очень важны детали проблем на глубоком уровне.
В этом и проблема. Вы не знаете, как оно работает. И даже самых общих деталей не знаете. Это было бы нормально, если бы вы были менеджером. Но вы утверждаете, что являетесь инженером и архитектором. А дальше всё сказанное вами читается как «у нас не было мозгов, мы не осилили изучить документацию и тем более даже не подумали предварительно потестировать оборудование». Потому не очень понятно, каким образом тот же Badoo умудряется хотя бы иногда работать.
>Лично я (от лица компании) бодался с Cisco несколько лет (!), они не могли исправить серьезнейшие / критикал баги ПО. Доходили до вице-президентов.
И когда вы дадите пример такого бага (жду) — наверняка окажется, что дело было вовсе не так, как вы говорите :) Кстати, заодно будет неплохо, если найдете номер кейса. Тут есть кому посмотреть. Может, выяснится, что это не баг, а аппаратная особенность, и вы хотели от железки того, под что она изначально вообще не разрабатывалась. У 5000 действительно много ограничений и детских болячек, это скорее проба пера.
Я тоже изредка (от лица компании) с ними бодался. Обычно достаточно эскалировать до АМ, дальше оперативно дают дебаг-образ.
>Очевидно, спорить сетевым инженерам лучше между собой.
Очевидно, что вам лучше не лезть на ту территорию, где вы ничего кроме имен по вашему мнению знающих людей не знаете :)
А с тех пор (линейка 5к уже давно EOL) вы ни разу с NX-OS устройствами не работали? И при этом говорите про современное состояние дел?
>ввиду того что эти железки даже на чистом L2 висли
Да они ничего кроме чистого L2 отродясь не умели… Но что значит «висли»? В каких условиях и как это выглядело?
>Cisco меняла несколько раз лайн-карты
А вот с этого момента поподробнее — что-то не сходится. N5K — свитч с фиксированной конфигурацией, в который можно добавить еще несколько портов. Допустим, менялись модули расширения. Так проблема была с ними, или со встроенными портами?
>Можно расспросить DmitryVolodin (он сейчас в Ростелекоме)
Интересно, вы сами хоть что-то можете сказать? :) Ну и надо ли говорить, что у оператора очень редко можно встретить датацентровое железо?
>Не cтоит рассказывать про промытие мозгов — я строю и эксплуатирую (разные, включая огромные) IT инфраструктуры.
Это очень печально, что при этом вы не знаете, как ваши инфраструктуры работают.
>Статистика по Cisco — крайне плохая, у множества клиентов реальные проблемы.
>Статистика по Arista — проблем практически ноль.
Так опять же — если сравнить доли рынка, то напрашивается очевидный вывод. А еще нормальна ситуация, когда люди поднимают функционал вроде того же vPC, не удосужившись изучить, как он работает, а дальше постоянно страдают.
Просто меня удивляют ваши наезды на нексусы, так как я сам ими пользуюсь, знаю немало весьма довольных ими людьми, а недовольных не знаю. Проблемы бывают, но все быстро решаются. А тут какой-то недо-архитектор на основании шапочного знакомства с людьми, немного работавшими с давно снятыми с производства свитчами, объявляет всю линейку очень популярного оборудования хламом. Странно как-то, и немного нелогично. Тем более что все нексусы разные, и даже 5500 очень сильно отличается от 5000…
>При этом мне откровенно не очень важны детали проблем на глубоком уровне.
В этом и проблема. Вы не знаете, как оно работает. И даже самых общих деталей не знаете. Это было бы нормально, если бы вы были менеджером. Но вы утверждаете, что являетесь инженером и архитектором. А дальше всё сказанное вами читается как «у нас не было мозгов, мы не осилили изучить документацию и тем более даже не подумали предварительно потестировать оборудование». Потому не очень понятно, каким образом тот же Badoo умудряется хотя бы иногда работать.
>Лично я (от лица компании) бодался с Cisco несколько лет (!), они не могли исправить серьезнейшие / критикал баги ПО. Доходили до вице-президентов.
И когда вы дадите пример такого бага (жду) — наверняка окажется, что дело было вовсе не так, как вы говорите :) Кстати, заодно будет неплохо, если найдете номер кейса. Тут есть кому посмотреть. Может, выяснится, что это не баг, а аппаратная особенность, и вы хотели от железки того, под что она изначально вообще не разрабатывалась. У 5000 действительно много ограничений и детских болячек, это скорее проба пера.
Я тоже изредка (от лица компании) с ними бодался. Обычно достаточно эскалировать до АМ, дальше оперативно дают дебаг-образ.
>Очевидно, спорить сетевым инженерам лучше между собой.
Очевидно, что вам лучше не лезть на ту территорию, где вы ничего кроме имен по вашему мнению знающих людей не знаете :)
Интересная статья. Но если честно, неочень информативная.
Если это не коммерческая тайна, не могли бы вы описать чуть подробнее:
1. Архитектуру вашей виртуализации (название платформы), поддерживает ли она уже сейчас RDMA без IPoIB?
2. Возможно вы используете некую кластерную FS, с поддержкой RDMA? если да, то какую?
3. Как вы измеряли пропускную способность FDR на вашем оборудовании, откуда взялась цифра в 5 раз?
4. Какое конечное оборудование используется?
5. Что выступает SM manager'ом? Коммерческая или openSM реализация? Как решена проблема отказоустойчивости SM?
6. Какие операционные системы и драйверы Infiniband используются(Mellanox или OFED)?
7. Какое SAN хранилище(а) у вас используется, интегрировано ли оно в виртуализацию? по RDMA (возможно SRP или iSER) или IPoIB(NFS)?
Увы без подробностей, это только красивая история… Спасибо.
Если это не коммерческая тайна, не могли бы вы описать чуть подробнее:
1. Архитектуру вашей виртуализации (название платформы), поддерживает ли она уже сейчас RDMA без IPoIB?
2. Возможно вы используете некую кластерную FS, с поддержкой RDMA? если да, то какую?
3. Как вы измеряли пропускную способность FDR на вашем оборудовании, откуда взялась цифра в 5 раз?
4. Какое конечное оборудование используется?
5. Что выступает SM manager'ом? Коммерческая или openSM реализация? Как решена проблема отказоустойчивости SM?
6. Какие операционные системы и драйверы Infiniband используются(Mellanox или OFED)?
7. Какое SAN хранилище(а) у вас используется, интегрировано ли оно в виртуализацию? по RDMA (возможно SRP или iSER) или IPoIB(NFS)?
Увы без подробностей, это только красивая история… Спасибо.
Ох, вы затрагиваете довольно много вопросов, где информация коммерческая. Что смогу — расскажу. Гипервизор qemu-kvm. RDMA используется только для кластерной ФС, она не требует наличия IPoIB. В нашем случае IPoIB используется для коннекта хостов при построении SDN сетей. Кластерная ФС с поддержкой RDMA. Измерения пропускной способности IPoIB проводились с помощью iperf, тестирование производительности RDMA проводилось с помощью утилит из OFED. Конечное оборудование — коммутаторы Mellanox SX6036, SX6025 и в серверах у нас стоят ConnectX-3 VPI. В качестве spine коммутаторов используются Mellanox SX6036, которые выполняют роль SM. В каждом кластере несколько таких коммутатором, на каждом настроем SM с различным приоритетом. В облаке используется RHEL 6.x, используются нативные драйвера, поставляемые с ОС.
Благодарю за развёрнутый ответ.
Дело в том что был похожий проект, правда без миграции «на лету», и полученные данные по скорости и стабильности, прямо сказать, не впечатлили…
Наш кластер делался следующим образом:
Оборудование:
Supermicro
корзины со свитчами Infiniband QDR
лезвия с mezzanin Infiniband QDR
несколько Qloqic 12300 в качестве SM менеджеров.
Платформа:
Ovirt 3.3-3.5,
с поддержкой GlusterFS (с поддержкой RDMA)
Операционки для нод — Centos6.5
Драйверы: Mellanox, OFED, нативные.
Как видно, конфигурация очень похожая.
Было решено, что RDMA и IPoIB смешивать не стоит, одно другому не нужно.
(fail 1)
От идеи сразу же пришлось отказаться, дело в том что GlusterFS, создаёт свой RDMA кластер именно на основе IP адресов нод… Ovirt не поддерживает RDMA нативно, точнее никак не поддерживает, даже с трудом живёт с Infiniband интерфейсами, потому как создать мост между Ethernet и Infiniband он не может, да и созданный вручную, такой мост нормально не работает…
Тогда решили, пусть ноды живут через IPoIB, и GlusterFS пусть работает так же.
(fail 2)
Увы, тест с глубиной очереди хотя бы в 20 разрывал этот кластер (даже на соседних лезвиях в одной корзине), и он попросту разваливался, поэтому от хранения образов виртуалок в GlusterFS'е решено было отказаться…
ОК, решили построить SAN на базе сервера с несколькими QDR картами, и да, здесь был частичный успех, SRP заработал, но таргет удалось реализовать только на Debian7 с паченым/перепаченым ядром (SCST), и с инициатором было не меньше проблем — приходилось подгонять время инициирования подключения после ребута сервера, вручную.
Правда оно того стоило, icsci через RDMA без использования IP, скорость обращения к локальному SSD в лезвии и к такому же на таргете (такому же лезвию где-то в Infiniband сети), сравнялась.
(fail 3)
Но и тут ждало разочарование:
Одновременное подключение к одному таргету невозможно. Поэтому прицепить ферму виртуализации к такому SAN не получится (только одну ноду). Ovirt, не умеет работать с SRP, да с ним ничего не умеет нативно работать, поэтому настроить автоматическое пере подключение другой ноды, при падении подключенной, средствами Ovirt'a нельзя.
Отказоустойчивость реализуется только на стороне таргета, между Infiniband портами.
Параллельно решили по тестировать пропускную способность Infiniband QDR 40Гб/сек (в теории).
Тестовый стенд:
2 лезвия, Haswell + 128GB RAM + SSD + Infiniband QDR (mezzanin), в одной корзине, свитч в корзине QDR (упираться не во что).
После несчётных переустановок и тюнинга драйверов, результаты приблизительно следующие:
Обе ноды: Centos6.3(включен SDP)(Mellanox 1.5.3|OFED 1.8)
OFED тесты = 16Гб/с
scp = 400 Мб/с!!!
NFS копирование = 6.5 Гб/с…
Обе ноды: Centos6.5(SDP больше не поддерживается)(Mellanox 2.2|OFED 3.12)
OFED тесты = 14.6Гб/с
scp = 330 Мб/с!!!
NFS копирование = 4.8 Гб/с…
Обе ноды: Centos6.5(нативный драйвер)
OFED тесты = 12Гб/с
scp = 290 Мб/с!!!
NFS копирование = 4.1 Гб/с…
Обе ноды: Windows2012 (Mellanox)
Копирование: 9.8Гб/с (среднее значение)
FreeBSD9.1 (нативно) / Windows2008 (Mellanox)
samba копирование = 7.5Гб/с (среднее значение)
Ещё мы прорабатывали варианты с Proxmox/Cepf, OpenNebula/GlusterFS, XEN…
И везде всё то же самое:
«RDMA — нет не знаем»
«Infininiband — нет не поддерживаем»
«Ждите, может быть когда-нибудь»
В итоге:
1. Да, IPoIB.
2. Ноды видят друг друга и SANы через IPoIB.
3. На каждой ноде есть Ethernet интерфейс, виртуалки сбриджены к ним.
4. Роутеры Ethernet/Infiniband сервера с QDR картами, маршрутизация на уровне IP.
5. Работает, но 10Гб/сек при очень хорошей погоде в вакууме…
Возможно мы просто не умеем готовить Infiniband, но мне кажется, дело не только в этом…
Буду очень благодарен, если вы найдёте время прочесть это, и что-нибудь ответить, подозреваю, вы тоже сталкивались с подобными проблемами при построении своего облака.
Извиняюсь за много букаф!
Дело в том что был похожий проект, правда без миграции «на лету», и полученные данные по скорости и стабильности, прямо сказать, не впечатлили…
Наш кластер делался следующим образом:
Оборудование:
Supermicro
корзины со свитчами Infiniband QDR
лезвия с mezzanin Infiniband QDR
несколько Qloqic 12300 в качестве SM менеджеров.
Платформа:
Ovirt 3.3-3.5,
с поддержкой GlusterFS (с поддержкой RDMA)
Операционки для нод — Centos6.5
Драйверы: Mellanox, OFED, нативные.
Как видно, конфигурация очень похожая.
Было решено, что RDMA и IPoIB смешивать не стоит, одно другому не нужно.
(fail 1)
От идеи сразу же пришлось отказаться, дело в том что GlusterFS, создаёт свой RDMA кластер именно на основе IP адресов нод… Ovirt не поддерживает RDMA нативно, точнее никак не поддерживает, даже с трудом живёт с Infiniband интерфейсами, потому как создать мост между Ethernet и Infiniband он не может, да и созданный вручную, такой мост нормально не работает…
Тогда решили, пусть ноды живут через IPoIB, и GlusterFS пусть работает так же.
(fail 2)
Увы, тест с глубиной очереди хотя бы в 20 разрывал этот кластер (даже на соседних лезвиях в одной корзине), и он попросту разваливался, поэтому от хранения образов виртуалок в GlusterFS'е решено было отказаться…
ОК, решили построить SAN на базе сервера с несколькими QDR картами, и да, здесь был частичный успех, SRP заработал, но таргет удалось реализовать только на Debian7 с паченым/перепаченым ядром (SCST), и с инициатором было не меньше проблем — приходилось подгонять время инициирования подключения после ребута сервера, вручную.
Правда оно того стоило, icsci через RDMA без использования IP, скорость обращения к локальному SSD в лезвии и к такому же на таргете (такому же лезвию где-то в Infiniband сети), сравнялась.
(fail 3)
Но и тут ждало разочарование:
Одновременное подключение к одному таргету невозможно. Поэтому прицепить ферму виртуализации к такому SAN не получится (только одну ноду). Ovirt, не умеет работать с SRP, да с ним ничего не умеет нативно работать, поэтому настроить автоматическое пере подключение другой ноды, при падении подключенной, средствами Ovirt'a нельзя.
Отказоустойчивость реализуется только на стороне таргета, между Infiniband портами.
Параллельно решили по тестировать пропускную способность Infiniband QDR 40Гб/сек (в теории).
Тестовый стенд:
2 лезвия, Haswell + 128GB RAM + SSD + Infiniband QDR (mezzanin), в одной корзине, свитч в корзине QDR (упираться не во что).
После несчётных переустановок и тюнинга драйверов, результаты приблизительно следующие:
Обе ноды: Centos6.3(включен SDP)(Mellanox 1.5.3|OFED 1.8)
OFED тесты = 16Гб/с
scp = 400 Мб/с!!!
NFS копирование = 6.5 Гб/с…
Обе ноды: Centos6.5(SDP больше не поддерживается)(Mellanox 2.2|OFED 3.12)
OFED тесты = 14.6Гб/с
scp = 330 Мб/с!!!
NFS копирование = 4.8 Гб/с…
Обе ноды: Centos6.5(нативный драйвер)
OFED тесты = 12Гб/с
scp = 290 Мб/с!!!
NFS копирование = 4.1 Гб/с…
Обе ноды: Windows2012 (Mellanox)
Копирование: 9.8Гб/с (среднее значение)
FreeBSD9.1 (нативно) / Windows2008 (Mellanox)
samba копирование = 7.5Гб/с (среднее значение)
Ещё мы прорабатывали варианты с Proxmox/Cepf, OpenNebula/GlusterFS, XEN…
И везде всё то же самое:
«RDMA — нет не знаем»
«Infininiband — нет не поддерживаем»
«Ждите, может быть когда-нибудь»
В итоге:
1. Да, IPoIB.
2. Ноды видят друг друга и SANы через IPoIB.
3. На каждой ноде есть Ethernet интерфейс, виртуалки сбриджены к ним.
4. Роутеры Ethernet/Infiniband сервера с QDR картами, маршрутизация на уровне IP.
5. Работает, но 10Гб/сек при очень хорошей погоде в вакууме…
Возможно мы просто не умеем готовить Infiniband, но мне кажется, дело не только в этом…
Буду очень благодарен, если вы найдёте время прочесть это, и что-нибудь ответить, подозреваю, вы тоже сталкивались с подобными проблемами при построении своего облака.
Извиняюсь за много букаф!
> Буду очень благодарен, если вы найдёте время прочесть это, и что-нибудь ответить, подозреваю, вы тоже сталкивались с подобными проблемами при построении своего облака.
habrahabr.ru/company/oversun/blog/116683/
Могу также ответить на некоторые технические вопросы.
habrahabr.ru/company/oversun/blog/116683/
Могу также ответить на некоторые технические вопросы.
Большое спасибо за ссылку.
Теперь всё встало на свои места.
У вас замечательный проект.
Если позволите, ещё пару вопросов по SRP.
В терминологии той статьи:
VRT (ViRTualization) — бездисковые серверы виртуализации, на которых запущены клиентские виртуальные машины.
IBRP (IB Raid Proxy) — прокси-серверы системы хранения, задача которых обслуживать рейды.
IBRN (IB Raid Node) — узлы системы хранения, в которых находятся диски и кэши.
Как я понимаю, основной принцип построения не изменился и сегодня?
Тогда возникает вопрос — SRP(SCST) — это соединение «точка — точка», нельзя подключить к одному таргету(луну) несколько инициаторов. (или я не прав?)
Возьмём один IBRN, создадим на нём несколько SCST лунов, по количеству дисков, или массивов, если используются контроллеры.
Возьмём ещё один IBRN, и сделаем то же самое.
Возьмём IBRP, и подсоединим к нему наши луны с обоих IBRN через SRP. (вероятно, можно же запустить несколько инициаторов на одном сервере?)
Теперь соберём с помощью md массив 1 + 0 из из присоединённых лунов.
И разобьём с помощью LVM, получившийся диск, как нам нужно.
Итого: мы получили связку IBRP + 2 IBRN.
Теперь, повторим процесс нужное количество раз в формате 1 + 2, и получим несколько таких связок. (IBRP + 2 IBRN)
(надеюсь, до этого момента, я рассуждал правильно)
Теперь возьмем любой из наших IBRP и создадим на нём лун(SCST) из… из чего? (из локальной LVM группы? из отдельного тома?)
Сделаем то же самое на всех IBRP.
Возьмём VRT, и подсоединим его ко всем нашим IBRP по SRP. (точнее настроим multipath, чтобы VRT, в каждый момент времени видел только один IBRP)
Создадим виртуалку на VRT, в качестве диска укажем ей диск LVM на IBRP? или просто положим образ виртуалки на LVM раздел?
А теперь представим, что IBRN выключился по питанию… ОК, ничего страшного, у нас же массив, никто и не заметит.
А если выключился IBRP? Он ведь был единственной связующей точкой межу VRT и парой IBRN. Информация недоступна, как быть?
Значит должна быть некая репликация, но где она?
Подключить к каждой паре IBRN каждый IBRP мы не можем, SRP нам не даст подключить несколько инициаторов к одному таргету?
Сделать репликацию на уровне IBRP между собой? (и чем? кластерной FS?) Но это ещё как минимум в 2 раза снизит количество полезной ёмкости хранилищ.
Сделать некий механизм переключения SRP подключений и LVM? (например IBRP#1 был подключен к IBRN#1 и IBRN#2, IBRP#1 выключился, IBRP#2 автоматически подключается к IBRN#1 и IBRN#2 и настраивает у себя корректно md и LVM ?) (а мониторинг реализовать на основе fencing ?)
В общем главный вопрос, по сути — как же реализовать отказоустойчивость IBRP? (или я, просто, как-то неправильно понимаю всю схему работы SRP с прокси?)
Теперь всё встало на свои места.
У вас замечательный проект.
Если позволите, ещё пару вопросов по SRP.
В терминологии той статьи:
VRT (ViRTualization) — бездисковые серверы виртуализации, на которых запущены клиентские виртуальные машины.
IBRP (IB Raid Proxy) — прокси-серверы системы хранения, задача которых обслуживать рейды.
IBRN (IB Raid Node) — узлы системы хранения, в которых находятся диски и кэши.
Как я понимаю, основной принцип построения не изменился и сегодня?
Тогда возникает вопрос — SRP(SCST) — это соединение «точка — точка», нельзя подключить к одному таргету(луну) несколько инициаторов. (или я не прав?)
Возьмём один IBRN, создадим на нём несколько SCST лунов, по количеству дисков, или массивов, если используются контроллеры.
Возьмём ещё один IBRN, и сделаем то же самое.
Возьмём IBRP, и подсоединим к нему наши луны с обоих IBRN через SRP. (вероятно, можно же запустить несколько инициаторов на одном сервере?)
Теперь соберём с помощью md массив 1 + 0 из из присоединённых лунов.
И разобьём с помощью LVM, получившийся диск, как нам нужно.
Итого: мы получили связку IBRP + 2 IBRN.
Теперь, повторим процесс нужное количество раз в формате 1 + 2, и получим несколько таких связок. (IBRP + 2 IBRN)
(надеюсь, до этого момента, я рассуждал правильно)
Теперь возьмем любой из наших IBRP и создадим на нём лун(SCST) из… из чего? (из локальной LVM группы? из отдельного тома?)
Сделаем то же самое на всех IBRP.
Возьмём VRT, и подсоединим его ко всем нашим IBRP по SRP. (точнее настроим multipath, чтобы VRT, в каждый момент времени видел только один IBRP)
Создадим виртуалку на VRT, в качестве диска укажем ей диск LVM на IBRP? или просто положим образ виртуалки на LVM раздел?
А теперь представим, что IBRN выключился по питанию… ОК, ничего страшного, у нас же массив, никто и не заметит.
А если выключился IBRP? Он ведь был единственной связующей точкой межу VRT и парой IBRN. Информация недоступна, как быть?
Значит должна быть некая репликация, но где она?
Подключить к каждой паре IBRN каждый IBRP мы не можем, SRP нам не даст подключить несколько инициаторов к одному таргету?
Сделать репликацию на уровне IBRP между собой? (и чем? кластерной FS?) Но это ещё как минимум в 2 раза снизит количество полезной ёмкости хранилищ.
Сделать некий механизм переключения SRP подключений и LVM? (например IBRP#1 был подключен к IBRN#1 и IBRN#2, IBRP#1 выключился, IBRP#2 автоматически подключается к IBRN#1 и IBRN#2 и настраивает у себя корректно md и LVM ?) (а мониторинг реализовать на основе fencing ?)
В общем главный вопрос, по сути — как же реализовать отказоустойчивость IBRP? (или я, просто, как-то неправильно понимаю всю схему работы SRP с прокси?)
> В терминологии той статьи…
Да
> Как я понимаю, основной принцип построения не изменился и сегодня?
Проект «Скалакси» в данный момент закрыт. Однако, приведенная архитектура со времени публикации статьи не менялась.
> Тогда возникает вопрос — SRP(SCST) — это соединение «точка — точка», нельзя подключить к одному таргету(луну) несколько инициаторов. (или я не прав?)
Можно. В общем-то, каждый VRT инициировал с каждой IBRP все собранные массивы, а каждая IBRP инициировала все диски с IBRN.
> Итого: мы получили связку IBRP + 2 IBRN.
До этого момента включительно все верно за исключением того, что IBRP не 1 штука, а две для отказоустойчивости.
> Теперь, повторим процесс нужное количество раз в формате 1 + 2, и получим несколько таких связок. (IBRP + 2 IBRN)
(надеюсь, до этого момента, я рассуждал правильно)
Количество IBRP не увеличивается, одна пара IBRP обслуживает все пары IBRN, LUN-ы с каждой пары IBRN собираются на каждой проксе в один RAID10 массив. Т.о., если у нас есть 2N IBRN, то мы получаем по N массивов на каждой IBRP. Каждый такой массив является SRP-target-ом, который экспортируется на каждую VRT. Через какой IBRP пойдет IO, определяется multipath-ом.
> Создадим виртуалку на VRT, в качестве диска укажем ей диск LVM на IBRP?
Нет, к виртуалкам цепляются device mapper устройства, созданные по DM-таблицам, созданным LVM-ом на на проксях и сохраненным в БД. Сам LVM используется только на проксях для управления томами и за их пределы не выходит.
> А если выключился IBRP?
Есть второй IBRP. Multipath на VRT-шках обноружит потерю пути и переключит при необходимости.
Да
> Как я понимаю, основной принцип построения не изменился и сегодня?
Проект «Скалакси» в данный момент закрыт. Однако, приведенная архитектура со времени публикации статьи не менялась.
> Тогда возникает вопрос — SRP(SCST) — это соединение «точка — точка», нельзя подключить к одному таргету(луну) несколько инициаторов. (или я не прав?)
Можно. В общем-то, каждый VRT инициировал с каждой IBRP все собранные массивы, а каждая IBRP инициировала все диски с IBRN.
> Итого: мы получили связку IBRP + 2 IBRN.
До этого момента включительно все верно за исключением того, что IBRP не 1 штука, а две для отказоустойчивости.
> Теперь, повторим процесс нужное количество раз в формате 1 + 2, и получим несколько таких связок. (IBRP + 2 IBRN)
(надеюсь, до этого момента, я рассуждал правильно)
Количество IBRP не увеличивается, одна пара IBRP обслуживает все пары IBRN, LUN-ы с каждой пары IBRN собираются на каждой проксе в один RAID10 массив. Т.о., если у нас есть 2N IBRN, то мы получаем по N массивов на каждой IBRP. Каждый такой массив является SRP-target-ом, который экспортируется на каждую VRT. Через какой IBRP пойдет IO, определяется multipath-ом.
> Создадим виртуалку на VRT, в качестве диска укажем ей диск LVM на IBRP?
Нет, к виртуалкам цепляются device mapper устройства, созданные по DM-таблицам, созданным LVM-ом на на проксях и сохраненным в БД. Сам LVM используется только на проксях для управления томами и за их пределы не выходит.
> А если выключился IBRP?
Есть второй IBRP. Multipath на VRT-шках обноружит потерю пути и переключит при необходимости.
Спасибо!
Правда, Ваш ответ несколько перевернул моё представление об SRP.
Не могли бы вы дать ссылочку, где почитать про тонкую настройку SRP (SCST)?
На какой операционке изначально SCST разрабатывался? с какой лучше всего совместим?
Как, всё таки, организовать подключение к одному таргету(луну)(SCST) больше одного инициатора? (почитать, или если несложно на пальцах)
Ещё раз, большое спасибо!
Правда, Ваш ответ несколько перевернул моё представление об SRP.
Не могли бы вы дать ссылочку, где почитать про тонкую настройку SRP (SCST)?
На какой операционке изначально SCST разрабатывался? с какой лучше всего совместим?
Как, всё таки, организовать подключение к одному таргету(луну)(SCST) больше одного инициатора? (почитать, или если несложно на пальцах)
Ещё раз, большое спасибо!
> Не могли бы вы дать ссылочку, где почитать про тонкую настройку SRP (SCST)?
Если идущей с SCST документации не хватает, то только списки рассылки и сорцы.
> На какой операционке изначально SCST разрабатывался?
Линукс. В общем-то, до сих пор только под ним и работает.
> Как, всё таки, организовать подключение к одному таргету(луну)(SCST) больше одного инициатора?
Не помню, чтобы с этим вообще какие-то проблемы были. Возможно, вы что-то делаете не так, а на память я вам в таких деталях помочь не смогу.
Еще хотелось бы заметить, что стоит дважды подумать перед тем, как копировать дизайн СХД скалакси, т.к. в эксплуатации она была довольно непростой: под десяток уровней абстракции с необходимостью думать на половине из них даже при такой «элементарной» операции, как замена диска с угрозой «повесить» всю СХД в случае неосторожности (диски меняли только по ночам, пристально смотря в мониторинг, с определенными приготовлениями и составленным планом действий, в котором только для happy way был десяток шагов).
Если идущей с SCST документации не хватает, то только списки рассылки и сорцы.
> На какой операционке изначально SCST разрабатывался?
Линукс. В общем-то, до сих пор только под ним и работает.
> Как, всё таки, организовать подключение к одному таргету(луну)(SCST) больше одного инициатора?
Не помню, чтобы с этим вообще какие-то проблемы были. Возможно, вы что-то делаете не так, а на память я вам в таких деталях помочь не смогу.
Еще хотелось бы заметить, что стоит дважды подумать перед тем, как копировать дизайн СХД скалакси, т.к. в эксплуатации она была довольно непростой: под десяток уровней абстракции с необходимостью думать на половине из них даже при такой «элементарной» операции, как замена диска с угрозой «повесить» всю СХД в случае неосторожности (диски меняли только по ночам, пристально смотря в мониторинг, с определенными приготовлениями и составленным планом действий, в котором только для happy way был десяток шагов).
Спасибо за предупреждение.
Но даже если нам удастся повторить конфигурацию скалакси, конечно же это не пойдёт в продакшен.
Да и честно сказать, у нас нет столько бюджета и железок, чтобы строить нечто подобное.
SRP вполне реально использовать в «локальной» виртуализации, без строгих рамок отказоустойчивости.
В тех местах, где скорость важнее.
Но даже если нам удастся повторить конфигурацию скалакси, конечно же это не пойдёт в продакшен.
Да и честно сказать, у нас нет столько бюджета и железок, чтобы строить нечто подобное.
SRP вполне реально использовать в «локальной» виртуализации, без строгих рамок отказоустойчивости.
В тех местах, где скорость важнее.
Чтобы полноценно использовать IB для хранилища сегодня можно использовать только ISCSI (iSER или SRP).
Или ipoib и подымать что угодно хоть cepth. Но тогда ~ 10Гбит.
Еще есть какие то варианты?
Или ipoib и подымать что угодно хоть cepth. Но тогда ~ 10Гбит.
Еще есть какие то варианты?
Какой гипервизор используется в проекте? esxi насколько знаю не умеет делать ipoib на таких скоростях, только 10г.
И как с реальной производительностью? ipoib не выглядит как быстрая и надёжная штука, особенно, в свете «голым задом в интернеты».
Почему не оптика?
Sign up to leave a comment.
Как мы переводили облако с Ethernet 10G на Infiniband 56G