Пять сетевух для разгрузки траффика - как?
Знакомый админ задал мне задачку, решить которую я не смог. Имеется 5 сегментов сети (по этажам) по 5-10 машин в каждой. Имеется сервер под Windows 2003 Enterprise на коем 1С, консультант и прочие бэкапы. Сервер не справляется с нагрузками в том числе по пропускной способности сети (особенно на подключениях консультанта). Админ принял решение доустановить 3 сетевухи в сервер и использовать каждую на свой сегмент. (Траффик между сегментами желателен, но не обязателен.) Схема, естественно, не заработала. Одновремено работает не более двух сегментов, остальные не видят сервер, ругаются по поводу ДНС, точнее не сказали. Адреса изначально были в одной подсети, но пробовалось разносить сегменты по своим подсетям. Не помогает.
ИМХО, красиво было бы вообще объеденить сетевухи в "пул" с одним IP на всех, но не знаю возможно ли это в Win при отсутсвии кластера.
Суть задачи - разнести нагрузку с пяти сегментов на пять интерфейсов. ОС Win 2003. У кого есть опыт по такому вопросу?
ЗЫ: Что забавно - мозг по данному вопросу мне компостировали в поезде на Питер (Привет, соседи! =), куда я приехал сдавать какой-то экзамен майкрософту. Экзамен я сдал, а из-за этого админа ощущение что провалил.
Прошивка и настройка BIOS, переделка и ремонт материнских плат, БП, видеокарт, HDD.
ROM.by 2002-2019 © apple_rom
В этой оснастке есть мастер по настройке, есть пространный файл помощи. Попробуйте сначала это, а по мере возникновения проблем, будем пытаться решать вместе. Если честно, мне эта оснастка много крови попортила, но разобраться там можно. Может быть Вы для тренировки соберете простенькую машинку с несколькими сетевыми картами и потренируетесь на ней? Ведь ее функция только маршрутизация между сегментами и трансляция адресов для доступа в интернет.
Сетевые адреса каждой сетевой карте можно присвоить в через "Сетевое окружение", оснастка будет манипулировать уже с этими настройками, Вам надо будет настроить сервер как маршрутизатор (поставить галочку на одной из вкладок, где выбирается роль, которую будет играть сервер), установить NAT, добавить в него нужные интерфейсы и прописать их роли, т.е. внешний или внутренний. Без установки NAT сервер будет работать только как маршрутизатор между сегментами, NAT дает выход в интернет, причем, интернет будет только в тех сегментах сети, интерфейсы которых включены в NAT.
Хм, ну ставим драйвера Интеловских сетевух по полной (там мегабайт 10, файл у меня PRO2KXP.exe, скачан с Интела), лезем в Свойства сетевух, там есть закладка Teaming. Создаем Team, добавляем в него, что добавляется...
А кому счас легко...
"Как же быть, нам султанам, ясность тут нужна". Джентльмены, на ваш опытный взгляд какой же путь лучьше подойдёт: маршрутизация или TEAM? Что будет проще и надёжнее, заметно прибавит скорости и создаст полную видимость в сети?
TEAM нашёл в точности как и было рассказано, но что в результате будет и что указать в настройках этих адаптеров, т.е. что следует сделть и что делать ни в коем случае не следует? Боюсь, что ответов здесь ни у Интела, ни у MS, мне будет не найти.
При настройки маршрутизации и удалённого доступа предлагается слишком большой выбор, а в описаниях ограничиваются всего двумя сетевыми адаптерами.
Правильным ли будет этот выбор?
Дрим тим.
Подозреваю, что 1С не SQL.
Значит, это именно тот случай, когда надо работать в терминальном доступе.
Давайте посмотрим, что можно выиграть, если подключить 5 сетевых карт.
Вариант, когда они ставятся вместо центрального коммутаторя, рассматривать не имеет смысла - все пересылки между сегментами пойдут через сервер и вчистую загубят всю работу.
Если их подключить параллельно центральному, объединить их в "команду" Intel для балансировки нагрузки мы сразу упремся в производительность жестких дисков - ведь 1Gbit это 100 мБайт, которые перекрывает только Raid ) да и то при последовательном чтении.
Значит, двух плат с лихвой хватит, даже если большая чась информации находится в кэше. Дальше -шина.
Если мать серверная, то там PCI 64. Считаем 33мгцХ64 бит - 2 Gbit. Снова две платы?
Что еще кроме потоковой производительноси при 5 платах получаем ?
Экономится одна пересылка через коммутатор.
Если, конечно, он включен в обычном режиме - Store & Fоrward, когда пакет полностью принимается коммутатором и только после этого выдается в порт назначения.
Но современные коммутаторы(по крайней мере, Cisco) работают Port Fast - после чтения заголовка(4 байта?), пакет начинает передаваться в порт назначения. Задержка 4 байта из 1512.
Оп. Вспомнилось. В одном из первых сравений гигабитных коммутаторов в "Компьютерном обозрении" упоминалось, что на гигабитных платах с обычными пакетами не удалось получить скорость выше 400 мегабит, а только пакеты Jumbo по 8 кбайт дали потоковую производительность до 800 мбит.
И снова я возвращаюсь к терминальному доступу - 90 дней его можно использовать в тестовом режиме. После очистки одной ветки реестра тестовый период начинается снова.
1С версии 6(не SQL) очень хорошо в нем работает. Ну, раза в 3, наверное.
Мы в 99 году купили сервер за 25k$ с сетевыми картами на Intel960 и кешом в 1 мбайт(на карте:). Правда, 100 мбитными. Тогда я и игрался с балансировкой нагрузки, агрегированием каналов. Для провайдера, да, это полезно. Но не для работы с софтом, базами. Здесь нужен другой подход.
IMHO
У кошки 4 ноги... Вход, выход, земля и питание.
"Так сколько жён в самый раз, три или одна?"
Savely, про Teaming удалось отыскать следующее.
Агрегирование канала (teaming) позволяет объединить два гигабитных интерфейса в один двухгигабитный, что должно серьезно увеличить пропускную способность системы на nForce 570/590. Более того, драйвер сети производит балансировку нагрузки в агрегированном канале (по возможности равномерно загружая оба физически присутствующих интерфейса), а в случае отказа одного из портов соединения (или обрыва кабеля) — переводит весь трафик на другой (разумеется, снижая пропускную способность канала вдвое), так что обрыва связи для клиентов такого сервера не происходит, осуществляя таким образом резервирование канала.
отсюда следует, что агрегирование используется не с отдельными сегменами, а с серверным коммутатором, да это как раз о том, о чём выше говорили. Расширение полосы между сервером и серверным коммутатором в итоге и есть то, одно, из самого необходимого, но в этом случае скорее всего придётся менять все настройки на сервере и на рабочих станциях. Не подскажите ли здесь правило, ведь пробы пути (эксперименты ) будут иметь побочные потери - простой работы в сети?
Ничего менять не надо. При обединении в Teaming от физических сетевых отвязываются транспортные простоколы (TCP/IP) и создается еще одна виртуальная сетевая карта <Имя Team>. Все. Было 3 карты, стала одна. Или была одна, добавили в комп вторую, создали Team, настройки протокола (IP-адрес и т.п.) c первой переписали на виртуальную сетевую карту <Имя Team>, никто из юзеров ничего не заметит. Если кто-то из сервисов был ЯВНО завязан на первую сетевую - "перезавязать" на Team (к примеру, у меня счетчик траффика пришлось "перезавязать").
P.S. Ну, не буду я пошагово расписывать. Я просто дал направление мысли и поиска. Я не специалист в Teaming - один раз побаловался, причем без тестов - просто посмотреть.
А кому счас легко...
упс... не туда.
По очень настоятельной просьбе трудящихся - ориджин удалён и больше не появится. Гарантировать же отсутствие публикации статей со своей стороны не могу :P
Попробовал TEAMING из четырёх интеловских гигабитных сетевых адаптеров. Прав Savely - настройки никаких затрудений не вызвали. После включения TEAM каждому сетевому адаптеру добавилась приставка TEAM:, появился дополнительный пятый сетевой адаптер, который и можно настраивать, а вот возможность настроить те четыре физических адаптера заблокирована. Единственное, при включении TEAM нужно угадать выбираемый тип, один из четырёх:
Adapter Fault Tolerance
Adaptive Load Balancing
Static Link Aggregation
IEEE 802.3ad Dynamic Link Aggregation
Здесь, чёрт возьми, ничего знакомого. В результате нагрузка сети на сервере упала почти до нуля, но в среднем держится почти на 3%, правда, ускорения работы на рабочих станциях по выполнению сетвых запросов на сервере как-то не ощутили. Наверное нужно подумать чтобы такого изменить в дисковом массиве.
Чего и следовало ожидать.
А что сейчас в массиве ?
SCSI/SAS 10000 ?
Дефрагментация часто делается ?
Файл подкачки на отдельном винте ?
Критических пользователей - на терминальный доступ!
Его включить не сложнее чем включить агрегирование. Не сложнее чем настроить права пользователя.
У кошки 4 ноги... Вход, выход, земля и питание.
Попробовал три из 4 указанных режима (4-ый не пригоден, его у нас нет - дороговато).
1-ый ничего не ускоряет. Работает только один адаптер, остальные находятся в резерве на случай, если активный выйдет из строя или пропадёт коннект, или активного захлебнёт нагрузка).
2-ой интересен. Работают все адаптеры, при чём один только на входящий трафик, а остальные на исходящий - убедился, весьма и весьма актуально для подавляющего большинства задач.
3-ий самый быстрый. Все показатели указывают на работу адаптера на скорости 4 Гб/сек, да ещё в полном дуплексе.
На рабочих станциях ощутимо быстро работает регистрация в домене, обзор сети, пользователей, принтеров, обмен сообщениями и прочие мелкие штучки, я бы даже скажал, всё работает мгновенно - просто летают. Ну, а запуск крупных программ, открытие большого числа баз, в кратности быстрее не стало. Что поделаешь, ведь самое медленное устройство в компьютере - жёсткий диск. Массив SAS10000, файл подкачки на отдельном диске (системном, не на сетевом ресурсе) за дефрагментацией слежу регулярно, но идеала на разделяемом ресурсе быть не может.
Меня настораживают модули памяти, они греются и температура их держится на уровне 57-63. Модули 667МГц с ECC, коррекцией ошибок, буферизированные. Считается, что такие не критично медленнее обычных.
Отправить комментарий