Как стать автором
Обновить

Комментарии 10

А заказчик активно юзает все богатство автоматизации и как много систем/серверов? multipod быстро упирается в policy cam при большом количестве правил взаимодействий. Или ACI просто как сеть без полноценного appcentric?

Заказчик, понятное дело, только осваивает новую для него технологию. Поэтому на первом этапе и запускались в модели Network centric. Appcentric в прод еще не двигался.
Насколько я могу оценивать вычислительную часть сети Банка, вряд ли она потребует большого количества EPG в среднесрочной перспективе. И, вероятнее всего, они смогут использовать vzAny группы, что облегчает ситуацию с TCAM.
В целом, методы оптимизации использования TCAM известны и думаю, что вряд ли Банк упрется в эти ограничения на сроке жизни используемого оборудования.

Это только начало страшной сказки: "А потом пришли требования по импортозамещению и остался Заказчик без запчастей, без поддержки и с необходимостью скрещивания ежиков с удавами... Но так ему и надо, ибо сознание определяет бытие."

Российские требования по импортозамещению заказчика без запчастей и поддержки не оставят - они нацелены на новые закупки. Да и всегда есть вариант доказывать, что аналогов на российском оборудовании не существует.

Вот если вопрос встанет не про импортозамещение, а про санкции со стороны вендора - тут будет печальнее, конечно. Но эти санкции пока что достаточно точечные и этот конкретный Банк пока не затрагивают. А если начнутся "ковровые бомбардировки" - тут тема ACI и вообще сети будет очень небольшой частью огромного набора проблем, основными в котором будут вычислительные системы. Если соскочить на российское сетевое оборудование будет болезненно, но возможно, то перейти с тяжелых вычислительных платформ на Эльбрусы так просто не получится.

Насчет закупок - ошибаетесь. Требования доводятся в части импортозамещения на существующее (находящееся в эксплуатации) ПО/оборудование. По обосновыванию отсутствия аналогов также все становится не радужно - на стороне принятия решения тоже производится анализ обоснований и есть специалисты. Про риски вендоров - Вы абсолютно правы и хорошо изложили. Далее учитываем максимальный срок эксплуатации оборудования - 7 лет, что с учетом развертывания/внедрения равно 4-5 годам и приходим к риску невозможности плановой замены оборудования с внедренным стеком технологий. Исходя из вышеизложенного, я бы попытался минимизировать риски.

На данный момент в области сетевого оборудования ЦОД импортозамещение практически невозможно. Если на Leaf еще можно что-то подобрать, то для Spine-коммутаторов в едином реестре российской радиоэлектронной продукции нет вообще ничего. Некоторые российские вендоры обещают появление чего-то подходящего в 2023, но до этого момента надо еще дожить.

Поэтому заранее ухудшать собственную сеть, опираясь на опасения проблем, вероятность которых на данный момент невысока - так себе выбор.

Конечно, мы со многими заказчиками уже прорабатываем альтернативные варианты на оборудовании из ЕРРРП, строим тестовые окружения и пишем планы на случай. Но "сломайте мне всё прямо сейчас" пока ни один не попросил.

А скажите, чего в имеющихся коммутаторах не хватает для уровня спайна? Ну из самого главного/критичного?

Высокоскоростных даунлинков.

Если мы строим современную сеть ЦОД, то в сторону хостов у нас смотрят минимум 10G. Значит, аплинки лифов (и, соответственно, даунлинки спайнов) должны быть хотя бы 40G, иначе разумного уровня переподписки добиться не получится.

И на этом весь ЕРРРП закончился. Там коммутаторов с даунлинками быстрее 10G нет и российские вендоры обещают, что, "наверное, в 2023 году".

Ага, ну то есть коммутатора с 32x100GE в первом приближении должно хватить.

Если найдете в ЕРРРП такой - дайте знать :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий