Производительность в основном зависит от того, какая СХД используется в качестве бэкенда для эмуляции. В статье говорится о Ceph, который применяется не для производительности, а скорее для минимизации стоимости решения и достижения максимальной емкости хранения.
Если нужна производительность — используете СХД с NVMe дисками и поддержкой NVMe over Fabrics.
Сейчас эта технология позволяет получить производительность в ~4.7M IOPS @ 4K (randread) и средним latency в ~15 мкс на эмулируемом NVMe диске, подключенном к remote Storage таргету по NVMe over Fabrics (это на 100GbE картах).
Так что, при желании, провайдер может дать покупателю облачного сервера производительность в несколько раз выше локального NVMe диска :)
И еще хотел бы уточнить несколько вопросов по flow control в фабрике.
Сам по себе RoCE никак не гарантирует Lossless коммуникацию. Для этого есть другие протоколы и методики, как например buffer credits в InfiniBand, или же PFC и/или ECN в Ethernet.
Используется ли PFC в AI фабрике? Если да, то как решается проблема incast congestion spreading и victim flow с PFC?
Используется ли ECN? В связке с PFC или без него?
Используется ли flow control на NIC? В Mellanox или HiSilicon?
Какая протестированная масштабируемость AI Fabric? Кол-во конечных узлов? В какой топологии?
Можете поделиться какими-либо реальными бенчмарками на трейнинге со стандартными моделями (ResNet/VGG/etc.)?
Comware 7 имеет модульную архитектуру с изоляцией процессов, разделением data, control и management plane, поддержкой обновлений без остановки сервиса (в том числе обновлений отдельных модулей системы), а также ряда новых интересных функций, таких как:
TRILL, EVB/VEPA, MDC, EVI, FCoE, ADVPN и многих других.
Изначально появилась на оборудовании ЦОД, однако сейчас идет миграция всего нашего портфеля на новую ОС.
Также есть планы по миграции с v5 на v7 для отдельных линеек оборудования.
ProCurve пока на своей Provision OS, но есть продвижение в плане унификации синтаксиса командой строки (в сторону Comware). Но в принципе уже ходят слухи… :)
Нумерация фаз несколько отличается. Динамические спок-ту-спок туннели у нас уже реализованы в первой фазе.
Далее пойдут 2 и 3 фазы со своими новыми фичами и улучшениями (включая иерархию хабов).
В любом случае, реальных цифр по масштабируемости одного хаба для той же платформы ASR1k я нигде не нашел. Из этого можно вычислить или предположить возможности масштабирования всего решения.
Мы же в свою очередь приводим их в документации или по запросу.
В том то и дело, что это не caveat, а limitation.
Чтобы не спорить, предлагаю Вам, как человеку с глубоким опытом работы с Cisco, уточнить у них актуальные значения напрямую.
Благодаря измененной архитектуре DVPN с возможностью выноса control plane на отдельное устройство, и достигаются цифры в 3к споков на домен (+ 10 доменов на VAM-сервер и хаб).
Пока не реализована вторая и третья фаза DVPN с возможностью строить иерархические топологии аналогично с Phase 3 DMVPN, такого показателя масштабируемости должно хватить большинству заказчиков. Ждем следующего года.
Пока аналога такой технологии на маршрутизаторах HP нет (старый добрый QoS с политиками по IP-destination для каждого или для группы споков).
Однако в следующем году планируется выход Phase 2 и 3 DVPN со множеством улечшений, включая и per-tunnel qos.
Касательно использования BGP и DVPN согласен, тут добавятся настройки пиринга с хабом на споках и пиринга со споками на самом хабе. Для хаба, процесс можно оптимизировать с помощью IMC и модуля BIMS, которые позволят автоматически забивать конфиг BGP пиров на хабе для кучи споков и делать аналогичный provisioning на сами споки.
Соседства BGP же строятся между интерфейсами. По времени реконвергенции в случае отказа одного из подключений на споке конечно не все так радужно как с EIGRP, однако и тут есть различные механизмы его сокращения.
Плюс, до какой степени масштабируется DMVPN с маршрутизацией на EIGRP?
Навскидку:
1. Control Plane (VAM сервер) у DVPN может быть вынесен на отдельное устройство в отличие от DMVPN, где он привязян к хабу.
2. П.1 позволяет DVPN лучше масштабироваться. До 3к туннелей с BGP маршрутизацией на домен у HP 6600 против 1.5k на хаб Cisco ASR1000.
3. Для масштабирования не требуется использовать сложные схемы с балансировщиками нагрузки (см. презентации по DMVPN scalability).
Ну и мелочи вроде отсутствия потребности в дополнительном лицензировании (следовательно, ниже стоимость), шифрование управляющего трафика, настройка и мониторинг с помощью системы управления.
Как ни странно, но это решение также может быть использовано и для SMB. Для подключения 20 филиалов, большинство из которых сидит за NAT'ом, отлично подойдут маршрутизаторы начального уровня серии MSR 900/920.
Если оба филиала находятся за NAT'ом, то трафик между ними автоматически пойдет через хаб, если же только один из них — в DVPN есть поддержка NAT traversal, при котором spoke-узлы установят прямой туннель друг с другом с помощью хаба.
Разъемы и кабели надежнее :)
Производительность в основном зависит от того, какая СХД используется в качестве бэкенда для эмуляции. В статье говорится о Ceph, который применяется не для производительности, а скорее для минимизации стоимости решения и достижения максимальной емкости хранения.
Если нужна производительность — используете СХД с NVMe дисками и поддержкой NVMe over Fabrics.
Сейчас эта технология позволяет получить производительность в ~4.7M IOPS @ 4K (randread) и средним latency в ~15 мкс на эмулируемом NVMe диске, подключенном к remote Storage таргету по NVMe over Fabrics (это на 100GbE картах).
Так что, при желании, провайдер может дать покупателю облачного сервера производительность в несколько раз выше локального NVMe диска :)
И еще хотел бы уточнить несколько вопросов по flow control в фабрике.
Сам по себе RoCE никак не гарантирует Lossless коммуникацию. Для этого есть другие протоколы и методики, как например buffer credits в InfiniBand, или же PFC и/или ECN в Ethernet.
Где почитать про то, как работает AI Chipset в деталях?
TRILL, EVB/VEPA, MDC, EVI, FCoE, ADVPN и многих других.
Изначально появилась на оборудовании ЦОД, однако сейчас идет миграция всего нашего портфеля на новую ОС.
Также есть планы по миграции с v5 на v7 для отдельных линеек оборудования.
По MSR — зависит от модели, нужно подбирать.
Далее пойдут 2 и 3 фазы со своими новыми фичами и улучшениями (включая иерархию хабов).
Мы же в свою очередь приводим их в документации или по запросу.
Чтобы не спорить, предлагаю Вам, как человеку с глубоким опытом работы с Cisco, уточнить у них актуальные значения напрямую.
Можно предположить, что более 1.5k споков на один хаб он тянет с трудом.
Благодаря измененной архитектуре DVPN с возможностью выноса control plane на отдельное устройство, и достигаются цифры в 3к споков на домен (+ 10 доменов на VAM-сервер и хаб).
Пока не реализована вторая и третья фаза DVPN с возможностью строить иерархические топологии аналогично с Phase 3 DMVPN, такого показателя масштабируемости должно хватить большинству заказчиков. Ждем следующего года.
Однако в следующем году планируется выход Phase 2 и 3 DVPN со множеством улечшений, включая и per-tunnel qos.
Соседства BGP же строятся между интерфейсами. По времени реконвергенции в случае отказа одного из подключений на споке конечно не все так радужно как с EIGRP, однако и тут есть различные механизмы его сокращения.
Плюс, до какой степени масштабируется DMVPN с маршрутизацией на EIGRP?
1. Control Plane (VAM сервер) у DVPN может быть вынесен на отдельное устройство в отличие от DMVPN, где он привязян к хабу.
2. П.1 позволяет DVPN лучше масштабироваться. До 3к туннелей с BGP маршрутизацией на домен у HP 6600 против 1.5k на хаб Cisco ASR1000.
3. Для масштабирования не требуется использовать сложные схемы с балансировщиками нагрузки (см. презентации по DMVPN scalability).
Ну и мелочи вроде отсутствия потребности в дополнительном лицензировании (следовательно, ниже стоимость), шифрование управляющего трафика, настройка и мониторинг с помощью системы управления.