Выбор коммутатора для СХД

[amihalchuk]

Доброго времени суток, уважаемые коллеги! Пытаюсь модернизировать серверный парк и СХД компании, наткнулся на пробелы с собственных знаниях.

Начну с того как есть на данный момент. В качестве парка серверов для собственных нужд используем 2 железки HP Proliant DL160 G6  и одну ML350 G5 на гипервизорах ESXi 5.0 в кластере. Подключены они по iSCSI 1G кабелями непосредственно к системе хранения QSAN P300Q-D212, которая на сегодня не соответсвует потребностям компании (сейчас в ней собрано 4 группы разными SATA-дисками, диски сыпятся, при ребилде все становится вообще очень плохо). Внедрено все это было задолго до меня, почему именно эта хранилка была выбрана не знаю.

Обновление парка начал с модернизации СХД. Выбрал Dell MD3820i в качестве нового датастора для гипервизоров (тоже в планах обновить), 24x1,8Tb 10k SAS, 2 контроллера с 4G cache на каждый, по 2 медных порта 10G iSCSI на голову. И вот тут как раз возникла проблема с подключением 1G Initiator`ов: их как минимум больше 2, гасить нельзя, машины мигрировать могу только между двумя... Да и подключать новые гиперизоры тоже куда-то нужно будет. Потребуется какой-либо коммутатор.

Изучил документ IP SAN BEST PRACTICES от делл и сделал для себя следующие выводы: сеть SAN будет изолирована от основной, коммутаторов потребуется 2, источников бесперебойного питания тоже 2 (уже есть). В эту же SAN включу и старый СХД для бекапов и медленных данных (логи, потоки netflow, etc.). Из L2-фич коммутатора: STP и Unicast storm control будет выключен, Flow Control и Jumbo frame включены (т.к. у серверов с ESXi программный инициатор и обычные NIC), L3-фичи вроде как бы не нужны (делл, насколько я понял, всякие QOS и expedited forwarding рекомендуют использовать если трафик iSCSI ходит по общей сети).

Собственно в чем вопросы... Рассматриваем 2 разных класса коммутаторов: уровня top of rack (основная фича - снижение задерки за счет передачи трафика мимо буфера) и уровня агрегации (да хоть простой длинк на 8 10G медных портов и пару SFP), ну и разница в цене на порядок. Естественно, сравнивая их "в лоб" есть отличия - размер буфера, коммутационная матрица и т.д. Касаемо низкой задерки коммутации - на сколько это критично и важно? Будет ли от этого значительный прирост в приложениях, либо он составит 2-3% и будет в районе погрешности? На что еще следует обратить внимание?

Может быть кому-то, у кого есть опыт проектирования и интегреции СХД, эти вопросы покажутся простыми (может даже глупыми), но меня это сейчас останавливает, куда копать пока тоже не совсем понимаю.

[alibek]

Для выделенной сети SAN обычно используют cut-through коммутаторы.

Обычно Nexus.

[amihalchuk]

3 минуты назад, alibek сказал:

Для выделенной сети SAN обычно используют cut-through коммутаторы.

Обычно Nexus.

Спасибо, однако хотелось бы понимать почему. Насколько понял, для FCoE это критично, насколько это критично и что дает для iSCSI из Вашего ответа я не понял.

[alibek]

Чем меньше задержка и больше пакеты, тем выше пропускная способность.

[amihalchuk]

3 часа назад, alibek сказал:

Чем меньше задержка и больше пакеты, тем выше пропускная способность.

Про большие пакеты я понял из IP SAN BEST PRACTICES, про низкую задержку - не совсем понятно... По крайней мере насколько эта разница велика. Cisco Nexus купить есть возможность, однако 2 подобные железки не будут ли избыточны для этих целей?

[jffulcrum]

 

[catalist]

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

[amihalchuk]

39 минут назад, jffulcrum сказал:

 

Спасибо! Собственно, вместе с ТС этой ветки задачей совместно и занимаемся, что-то я не догадался в его ветку написать. В нашем случае highload-систем с тяжелыми БД не прогнозируется. Самая большая нагрузка в плане БД - bgbilling с его 2500qps в пике и 300qps в среднем и, как не удивительно, сервер zabbix.

[jffulcrum]

2 часа назад, amihalchuk сказал:

2500qps

Вы там нолик лишний не приписали? Если что, 300 qps на типовой MySQL - это четыре физических ядра в полке. Может, конечно, в каждой query у вас по битику меняется, но что-то не верится.