В настоящее время мы оцениваем оборудование и топологические решения для новой среды с использованием GFS + iSCSI и хотели бы получить некоторые предложения / советы. Мы развернули аналогичное решение в прошлом, где все хосты, обращающиеся к узлам GFS, сами были узлами GFS. Новая топология должна отделить узлы GFS от клиентов, обращающихся к ним.
Базовая диаграмма будет выглядеть так:
GFS_client <-> gigE <-> узлы GFS <-> gigE <-> устройство iSCSI SAN
Единственная часть этого вопроса, на которую я могу предположить ответ, - это №4.
Мы оценили и рассмотрели 10GbE для нашей SAN и решили, что дешевле, эффективнее и безопаснее придерживаться совместных / сбалансированных по нагрузке адаптеров 1Gb. Достижение того же уровня избыточности с 10GigE было астрономическим и обеспечило номинальное увеличение производительности для клиентов (в конце концов, вы не собираетесь ставить карту 10GbE в каждого клиента).
Я не думаю, что есть «оптимальная» настройка. Просто убедитесь, что вы запускаете инициатор iSCSI до GFS. Вы уже указали связывание как показатель избыточности / производительности. Вам, вероятно, также следует подумать о настройке многопутевого соединения с вашей целью, если у вас есть 4 NIC, возможно, создайте 2 пути через 2 связанных интерфейса для лучшей избыточности. Вам также следует подумать об использовании Jumbo-кадров, если у вас есть выделенный коммутатор iSCSI, который поддерживает эту функцию.
GFS как подсистема не очень тяжелая для системы. В ядре есть блокировки, некоторая информация о членстве / пульс бегают между узлами, и это почти все. С другой стороны, поскольку вы планируете сделать из них и узлы GFS, и сервер, к которому будут обращаться клиенты, вам, вероятно, следует инвестировать в свои сетевые адаптеры / коммутаторы и оперативную память для серверов.
Jumbo-кадры. 803.2. По возможности используйте агрегацию ссылок с обеих сторон (iscsi и клиентов). Оптимизация стека tcp (/ proc / sys / net / ipv4 / tcp_rmem | wmem)
Пропущу, стоимость 10ге не имею.
Вы думали о резервировании сети? Кластеры GFS очень уязвимы для пропущенных тактов. Мы используем связывание интерфейсов для всех наших кластеров и каналов iSCSI, подключенных к отдельным коммутаторам.
Просто чтобы добавить к # 3 и 4
Джамбо может сделать огромный выгодная разница в производительности, особенно для сетей "хранения", где 99,99% пакетов будут большими. Просто не забудьте сначала провести аудит, чтобы убедиться, что все хосты в сети поддерживают их.
Во-вторых, стоит убедиться, что все эти дополнительные интерфейсы GigE дают вам большую скорость, большинство коммутаторов (по умолчанию) фактически используют хэши на основе MAC или IP, поэтому вы можете не видеть больше 1 ГБ между одной парой хостов.
К тому времени, как вы установите 10Gbe, вы должны просто укусить пулю и использовать FC, который намного быстрее при той же скорости соединения, или подождать до начала следующего года, когда материалы конвергентного Ethernet, наконец, должны быть доставлены по цене ниже "раннего последователя" ценообразование.
Мы оцениваем решение для нашей новой SAN, и продукт Equalogic действительно отлично подходит для iscsi. В каждой связке 15 дисков и 2 контроллера (A / P 4 ГБ каждый). При добавлении 2 контроллеров на 15 дисков производительность увеличивается линейно при увеличении емкости хранилища.
Они пока не идут на 10Ge, но у каждого контроллера есть 4 линка. Они обеспечивают реальное тонкое обеспечение
Я не могу (пока) комментировать пост LapTop006, но он абсолютно на высоте!
Проблема в том, что все ваше сетевое оборудование в IP-SAN должно поддерживать одинаковое количество MTU (Maximum Transmission Unit). Если я правильно помню, максимальный MTU для Jumbo Frames по спецификации составляет 9000 байт, но я видел людей, использующих 9100 и выше ..