Перейти к содержимому
Калькуляторы

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

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

Начну с того как есть на данный момент. В качестве парка серверов для собственных нужд используем 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% и будет в районе погрешности? На что еще следует обратить внимание?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Обычно Nexus.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, alibek сказал:

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

Обычно Nexus.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, alibek сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
39 минут назад, jffulcrum сказал:

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, amihalchuk сказал:

2500qps

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас