amihalchuk Опубликовано 18 января, 2019 · Жалоба Доброго времени суток, уважаемые коллеги! Пытаюсь модернизировать серверный парк и СХД компании, наткнулся на пробелы с собственных знаниях. Начну с того как есть на данный момент. В качестве парка серверов для собственных нужд используем 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% и будет в районе погрешности? На что еще следует обратить внимание? Может быть кому-то, у кого есть опыт проектирования и интегреции СХД, эти вопросы покажутся простыми (может даже глупыми), но меня это сейчас останавливает, куда копать пока тоже не совсем понимаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 18 января, 2019 · Жалоба Для выделенной сети SAN обычно используют cut-through коммутаторы. Обычно Nexus. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
amihalchuk Опубликовано 18 января, 2019 · Жалоба 3 минуты назад, alibek сказал: Для выделенной сети SAN обычно используют cut-through коммутаторы. Обычно Nexus. Спасибо, однако хотелось бы понимать почему. Насколько понял, для FCoE это критично, насколько это критично и что дает для iSCSI из Вашего ответа я не понял. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 18 января, 2019 · Жалоба Чем меньше задержка и больше пакеты, тем выше пропускная способность. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
amihalchuk Опубликовано 18 января, 2019 · Жалоба 3 часа назад, alibek сказал: Чем меньше задержка и больше пакеты, тем выше пропускная способность. Про большие пакеты я понял из IP SAN BEST PRACTICES, про низкую задержку - не совсем понятно... По крайней мере насколько эта разница велика. Cisco Nexus купить есть возможность, однако 2 подобные железки не будут ли избыточны для этих целей? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 18 января, 2019 · Жалоба Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 18 января, 2019 · Жалоба Задержка это краеугольный камень например у БД, чем она меньше тем быстрей работает БД Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
amihalchuk Опубликовано 18 января, 2019 · Жалоба 39 минут назад, jffulcrum сказал: Спасибо! Собственно, вместе с ТС этой ветки задачей совместно и занимаемся, что-то я не догадался в его ветку написать. В нашем случае highload-систем с тяжелыми БД не прогнозируется. Самая большая нагрузка в плане БД - bgbilling с его 2500qps в пике и 300qps в среднем и, как не удивительно, сервер zabbix. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 18 января, 2019 · Жалоба 2 часа назад, amihalchuk сказал: 2500qps Вы там нолик лишний не приписали? Если что, 300 qps на типовой MySQL - это четыре физических ядра в полке. Может, конечно, в каждой query у вас по битику меняется, но что-то не верится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...