Загрузка сетевого интерфейса windows
Анализ загрузки сети, Всего байт/сек (Bytes total/sec), применение Сетевого монитора (Network Monitor)
Последняя физическая подсистема сервера, мониторинг которой имеет смысл производить, — сетевая подсистема. Как правило, пользователи подключаются к SQL Server по сети.
Обычно какие-то проблемы с производительностью работы сети, вызванные именно работой SQL Server , возникают редко. Как правило, сеть намного активнее загружается другими приложениями (например, приложениями на основе настольных баз данных — FoxPro , Access , Clipper , Paradox и т. п.).
На предприятиях часто встречаются ситуации, когда за работу сети отвечает один человек (или подразделение), а за работу приложения, использующего SQL Server , — другой. И договориться им часто бывает сложно. Рассмотрим возможности мониторинга загруженности сети с точки зрения администратора SQL Server .
Проблемы с производительностью работы сети могут встретиться в двух вариантах. Первый вариант — не хватает производительности конкретного сетевого адаптера, установленного на сервере. Чтобы проверить это, можно воспользоваться счетчиком Всего байт/сек (Bytes total/sec) для объекта Сетевой интерфейс (Network Interface) (выбрав нужный сетевой интерфейс из списка). Значение этого счетчика предлагается сравнивать с паспортным значением для данного сетевого интерфейса. Если сетевой интерфейс действительно работает на пределе своих возможностей, то его можно заменить на специальный серверный мультипортовый адаптер.
Намного чаще возникает другая ситуация — когда проблема не в сетевом интерфейсе, а в общем уровне загрузки сети. В этом случае работа клиентов с SQL Server может серьезно замедлиться. Могут происходить тайм-ауты при установке соединений, разрывы уже установленных соединений и т. п. Как отследить общий уровень загрузки сети и в случае необходимости представить доказательства сетевому администратору?
В Системном мониторе подходящего объекта нет. Он был в Windows NT 4.0 (и назывался Сетевой сегмент ( Network Segment )), но в Windows 2000 и 2003 его убрали (мотивируя это заботой о безопасности). Поэтому придется использовать другие способы. Средства оценки производительности сети встроены в большинство снифферов (одни из самых мощных — в Net Observer ), в том числе в сниффер от Microsoft , который называется Сетевой монитор ( Network Monitor ). Правда, использовать для анализа загрузки сети ту версию Сетевого монитора, которая поставляется с Windows 2000 и 2003 (ее можно установить, выбрав в списке необязательных компонентов операционной системы), бесполезно. Этот сниффер видит только трафик, который передается с этого компьютера, на этот компьютер, широковещательный трафик и трафик групповой рассылки. Если трафик генерируется другими компьютерами, то стандартная версия Сетевого монитора просто его не увидит и, соответственно, не отобразит при анализе уровня загрузки. Поэтому нужно использовать версию Сетевого монитора, которая поставляется с Systems Management Server .
После установки запуска Сетевого монитора вам нужно выбрать сетевой адаптер, который будет использоваться для перехвата пакетов в сети. Затем нужно будет в меню Захват (Capture) выбрать команду Старт (Start), чтобы начать захват данных. Информация о загрузке сети (% загрузки сети) будет представлена как в графическом, так и в цифровом виде (в правой части экрана).
Отметим, что для обычной сети на хабах (без применения свитчей) пороговое значение этого счетчика, согласно Microsoft , составляет всего 40%. Превышение этого значения ведет к прогрессирующему уменьшению производительности (чем больше нагрузка, тем больше коллизий и повторов передачи данных, а соответственно опять происходит увеличение нагрузки, и так по нарастающей).
В реальной работе часто возникают ситуации, когда производительность работы сети ограничена по объективным причинам. Например, пользователи подключаются к SQL Server из филиалов по низкоскоростным каналам связи. Иногда нужно обеспечить возможность подключения пользователей через брандмауэр, за настройки которого ответственны другие администраторы. И в том и в другом случае имеет смысл подумать о двух вариантах решения:
q использовать приложение с Web -интерфейсом;
q использовать терминальный доступ при помощи Microsoft Terminal Services или Citrix MetaFrame .
Первый вариант требует наличия специальной Web -версии клиентского приложения, которая есть далеко не всегда (а самостоятельно создать ее бывает сложно, особенно учитывая то, что подробной информации о структуре базы данных в вашем распоряжении может и не быть). Зато второй вариант можно использовать в большинстве ситуаций. При этом пользователи работают с обычным вариантом клиентского приложения, но физически оно запускается не на их компьютере, а на специальном сервере. С клиентской рабочей станции на терминальный сервер передаются только нажатия клавиш и щелчки мышью, а с сервера на рабочую станцию — изменения в экране. Преимуществ у такого решения — множество:
q терминальные решения требуют минимального трафика в сети и обычно нормально работают даже по модемным коммутируемым соединениям;
q в случае разрыва соединения пользователь может заново подключиться к своему сеансу и продолжить работу с того же места;
q на клиентский компьютер не нужно устанавливать практически никаких клиентских приложений (кроме клиента терминального сервера). Это хорошо и с точки зрения безопасности, и с точки зрения снижения нагрузки на администратора;
q на клиентском компьютере может быть установлена практически любая операционная система (при использовании Citrix MetaFrame , в том числе и DOS , и Unix ). Требования к системным ресурсам компьютера также минимальны;
q трафик Citrix MetaFrame и Microsoft Terminal Server автоматически шифруется (в отличие от трафика работы обычных клиентов с SQL Server , которые подключаются, например, по OLE DB или ODBC );
q если сетевое соединение защищено брандмауэром, то открыть доступ для терминальных соединений обычно проще, чем для подключения обычных приложений к SQL Server .
Недостатков у терминальных решений не так много: требуются лицензии на терминальный сервер; нужен дополнительный сервер (достаточно мощный, если он будет обслуживать большое количество пользователей); некоторые специальным образом защищенные (например, ключами HASP ) или очень ресурсоемкие приложения могут не работать на терминальном сервере. Однако в настоящее время популярность терминальных решений растет очень быстро (например, для клиент-серверной версии 1С), и помнить о такой возможности определенно стоит.
Другие варианты повышения производительности сетевой подсистемы при работе с SQL Server обычно включают в себя использование свитчей вместо хабов, обновление сетевой инфраструктуры (с 10 Мбит до 100, с 100 Мбит — до 1 Гбит и т. п.), а также выделение клиентов вместе с SQL Server в отдельный сегмент сети.
Решение проблем с соединениями в сетях Windows
Посетителей: 23564 | Просмотров: 37329 (сегодня 0)
Итак, в этой серии я рассказал вам, как диагностировать массу проблем, связанных с соединениями. Этой статьей я завершаю эту серию, рассказывая, как проблемы с таблицами маршрутизации Windows могут вызывать проблемы с соединениями.
Во всей серии я много говорил о маршрутизации. Специально для новичков в сетевых технологиях: маршрутизатор – это устройство, позволяющее пакетам путешествовать от одного сегмента сети к другому. Маршрутизатор всегда связан как минимум с двумя сегментами сети, но часто случается, что он связан с несколькими сегментами. И в этом случае маршрутизатор должен знать способ вычисления сегмента, которому нужно передавать пакет, чтобы тот достиг назначения. И тут в игру вступают таблицы маршрутизации.
Таблицы маршрутизации позволяют маршрутизаторам принимать решения о пересылке пакетов, но вы можете и не знать, что существуют также таблицы маршрутизации, встроенные в операционную систему Windows. Вы можете увидеть эти таблицы маршрутизации, открыв командную строку и введя команду ROUTE PRINT, как показано на Рисунке A.
Рисунок A: Таблицы маршрутизации Windows
На первый взгляд, изображение экрана выше может показаться пугающим. Но вы должны помнить, что я сделал его в Windows Vista. В Windows Vista информация о маршрутизации IPv6 смешана со стандартной информацией IPv4. Если бы вы попробовали команду Route Print в одной из предыдущих версий Windows, информация IPv6 отсутствовала бы, поэтому все выглядело бы проще.
Однако и в нашем варианте с IPv6, информация о маршрутизации не так сложна, как кажется на первый взгляд. Как видно из рисунка, информация о маршрутизации разделена на три раздела: интерфейсный список, таблица маршрутизации IPv4 и таблица маршрутизации IPv6. В данной статье я не буду рассматривать таблицу IPv6, так как пока еще немногие используют IPv6 в данный момент.
Список интерфейсов
Список интерфейсов создан, чтобы показать вам все сетевые интерфейсы, которые видит Windows. Я изолировал секцию списка интерфейсов на выходе на Рисунке B.
Рисунок B: В списке интерфейсов перечислены все сетевые адаптеры машины
Если вы посмотрите на рисунок выше, вы увидите, что первые два элемента списка соответствуют физическим сетевым адаптерам. Тот факт, что эти адаптеры присутствуют в списке, указывает на то, что:
- Windows видит адаптер.
- Для адаптера установлен драйвер.
- Windows считает адаптер возможным путем для трафика IPv4.
Третий элемент, показанный в списке, — это адаптер обратной связи. Это не физический сетевой адаптер, а логический механизм, используемый Windows для внутренних взаимодействий. Адаптер обратной связи обязан присутствовать всегда для нормальной работы Windows. Если он отсутствует, я бы предложил удалить различные сетевые компоненты и переустановить их.
Четвертый элемент в списке на Рисунке B – это адаптер 6TO4. Это логический механизм, используемый Windows для маршрутизации трафика IPv6 через сеть IPv4. Этот механизм присутствует только в Windows Vista.
Остальные элементы в списке указывают на то, что IPv6 связан с двумя физическими сетевыми адаптерами машины.
Таблицы маршрутизации
Хотя иногда бывает полезным иметь возможность проверить, признает ли Windows существование ваших сетевых адаптеров, именно таблицы маршрутизации полностью определяют, куда будет направлен трафик. На Рисунке C показано, как выглядят таблицы маршрутизации IPv4.
Рисунок C: Таблица маршрутизации IPv4
Таблицы маршрутизации, показанные выше, немного сложнее, чем те, с которыми вы будете обычно работать, так как машина, с которой брались снимки, содержит несколько сетевых адаптеров. Однако, вне зависимости от того, как настроена ваша машина, в таблице маршрутизации должны обязательно присутствовать некоторые записи. На схеме ниже перечислены все эти записи, а также указано их значение:
| Сетевой адрес | Описание |
| 0.0.0.0 | Это маршрут по умолчанию, используемый, когда не найдено других возможных маршрутов. |
| 127.0.0.0 | Это адрес обратной связи, используемый для внутренних взаимодействий. |
| 147.100.0.0 | Это адрес локальной подсети. В данном конкретном случае, этот адрес относится к моей сети, так как мои адреса находятся в адресном диапазоне 147.100.x.x. Если бы в моей сети использовался более привычный диапазон 192.168.1.x, тогда это значение было бы 192.168.1.0. |
| 147.100.100.40 | Это IP адрес, связанный с моей сетевой картой. Опять же, этот адрес относится только к моей подсети, но у вас также должны быть запись, отражающая ваш IP адрес. |
| 147.100.255.255 | Это адрес широковещательной рассылки для подсети. Опять же, этот адрес для конкретно моей подсети. Просто чтобы показать, как он может выглядеть, в случае, если вы используете более обычный диапазон 192.168.1.x, этот адрес был бы 192.168.1.255. |
| 224.0.0.0 | Это адрес групповой передачи Windows. |
| 255.255.255.255 | Это адрес ограниченной широковещательной рассылки Windows . |
Как вы видите, некоторые из адресов в таблице выше относятся к конкретной сети. Если вам нужна помощь в понимании предназначения этих адресов, вы можете использовать команду IPCONFIG /all, чтобы узнать, как настроен TCP/IP для каждого сетевого адаптера. Вы сможете использовать эту информацию, чтобы определить адреса, которые нужно использовать в таблицах маршрутизации.
Нужно помнить также, что если ваша система использует несколько сетевых адаптеров, вам нужно иметь несколько записей для каждого конкретного сетевого адаптера. К примеру, если вы посмотрите на рисунок выше, вы заметите несколько записей в диапазоне 196.254.x.x. Эти адреса соответствуют второму сетевому адаптеру моей системы.
Теперь, когда вы знаете, чего ожидать от таблиц маршрутизации, встает вопрос, что нужно делать в том случае, если информация в ваших таблицах маршрутизации неверна или неполна. В такой ситуации у вас два выхода. Вы можете либо удалить и переустановить сетевые компоненты Windows, либо вручную исправить таблицу маршрутизации.
Если вас заинтересовала реконструкция таблиц маршрутизации, или вам просто хочется узнать больше об этих таблицах, о том, что означают различные колонки в этих таблицах, я рекомендую прочитать мою статью Making Sense of Windows Routing Tables.
Заключение
В этой серии статей я объяснил, что, хотя много чего было предпринято Microsoft для упрощения сетевого взаимодействия, при этом все еще могут возникать ошибки. Затем я рассказал, как вы можете использовать встроенные в Windows средства для решения различного типа проблем с соединениями.
Настройка сетевого адаптера в Windows
Инструкция по настройке сетевого интерфейса Windows после подключения сервера к сети.
Шаг 1
Подключитесь к виртуальному серверу по RDP и откройте Network and Sharing Center, для этого на рабочем столе Windows в правом нижнем углу правой кнопкой мыши кликните Настройки сетевых подключений.
В открывшемся окне выбирете нужный интерфейс, у которого нет доступа к сети.
Откроется окно состояния интерфейса. Чтобы убедиться, что выбран нужный интерфейс откройте его детали с помощью кнопки Details.
Сравните значение поля Physical Address со значением поля MAC в панели управления.
Шаг 2
Если при создании сети в панели вы активировали опцию DHСP, то настройка сетевого адаптера Windows будет выполнена автоматически. Проверить включена или выключена опция можно в свойствах сети в панели управления.
Шаг 3
Если при создании сети в панели управления вы НЕ активировали опцию DHСP, то настройку необходимо выполнить вручную. Откройте свойства адаптера с помощью клавиши Properties.
Выбирете соединение IPv4 и нажмите Properties.
В открывшемся окне в поле IP-address введите выданный адрес, в поле Subnet mask введите маску подсети. Все значения можно посмотреть в панели в настройках сервера (раздел Сети) или в меню Сеть.
Шаг 4
Чтобы проверить настройку сетевого адаптера выполните команду ping на адрес шлюза по умолчанию, например:
Примечание: для проверки на Windows Server 2016 необходимо выполнить пинг на другой локальный сервер.
