Не хватает этого
Для жирного стореджа нужна выделенная сеть
В требованиях цефа, например, это явно сказано

В цеф при ребалансе кластера в несколько десятков тб 10гбит сеть укладывается в полку
Если кластер побольше, то сеть нужна побольше
И если ты уложил все 10 гиг и на данные у тебя вообще ничего не осталось, приложение по сути становится недоступным

У цефа нельзя выставить лимит нв ичпользование сети?

Отдельную сеть это точно так же положит

Не до конца
Кластер при ребалансе будет продолжать отвечать
Ребаланс это копирование данных с одних узлов на другие, чтобы сохранить нужное количество копий
Видимо, цеф умеет ребаланс делать так, что на обычную работу стореджа сеть тоже остаётся

Тогда лимит нужно и приложению выставлять, а это сложнее

Повторю, проблема не только в нужной ширине канала, но и в задержках
Они должны быть минимальными
А регулировать задержки в сети, где пользователей много, не выйдет

а теперь вопрос какая разница отдельная эта сеть или нет ? у вас и там и там много пользователей и в случае хостинга слабоподконтрольных. то есть на уровне приложений выставить ничего нельзя

все что вам доступно это ограничения в среде вирутализации и возможный qos на сети

более того на моей текущей работе инженер из команды виртуализации сказал чтобы я себе ограничивал 1,5GB/S по диску, в светлое время суток ибо сеть не резиновая, для понимая мне сожрать 15GBS вообще не проблема, и такие действия нужны на регулярной основе. ну и да сеть для стораджей построена на FC и она выделенная.  и возвращаясь к нашему вопросу о том что одна и таже сеть для стораджей и сетевого доступа это плохо могу сказать что это не так,  ибо любую сеть можно забить трафиком, вопрос в том как не дать этому случится.  а отдельная сеть это или нет уже не важно.

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/1.3/html/hardware_guide/networking_recommendations
For network optimization, we recommend a jumbo frame for a better CPU/bandwidth ratio. We also recommend a non-blocking network switch back-plane.
Например, джамбо фреймы рекомендуются
Нафиг тебе джамбо в сети виртуалок, например
А в сети стореджа рекомендуется

когда мы делали с редхатом опенстэк, первоначальный дизайн был ноды 40гигабит, разбитый на вланы.
второй дизайн учел ошибки прошлого и уже было две сети по 20гигабит. фронт и бэк. фронт - для внешних данных, бэк - для стореджа и мониторинга. решили, что так проще избегать проблем с тем, о чем @vadimisakanov  говорил. сторадж был на синдере (+свифт), не на сефе.

да, джамбо фреймы по 9кб были

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

"учел ошибки" а какие ?

там много ошибок было. но делать все в одной сети с млагом было признано ошибкой, решили, что сторадж должен быть отдельно. поэтому и сделали два отдельных интерфейса вместо одного на 40 гигагбит

любую сеть можно забить трафиком, вопрос в том как не дать этому случится.

нет ничего плохого в том что твой условный гигабит забился

когда идет синхронизация реплик данных

чем быстрее она пройдет, тем лучше. но и клиенты не должны страдать при этом