Мониторинг основных показателей приложений. Часть 2

Во второй части статьи мы рассмотрим сервисы, которые может предоставлять операционная система сама по себе, в базовой комплектации. А затем — дополнительные функции, такие как exchange и sql server.

Служба файлов

При мониторинге этой службы надо обратить внимание на следующие аспекты.

Во многих случаях служба доступа к файлам организована не очень удачно, как в отношении физического расположения, так и по правам доступа. Это ведет как к проблемам с проверкой доступа к данным, так и к распространению вредоносного программного обеспечения. В подобной ситуации требуется оптимизация предоставления службы в плане расположения точек доступа к данным (так называемых общих папок) и организация корректной политики раздачи прав доступа.
В некоторых случаях необходима синхронизация данных во множественных точках доступа. Например, при работе с файловыми данными в нескольких географически разнесенных подразделениях организации.
При использовании инфраструктуры AD механизмы службы и синхронизация используются в системных целях, для синхронизации SYSVOL. Это требует отдельного мониторинга.
Могут применяться перемещаемые профили пользователей. Они обеспечивают свободу при перемещении пользователей внутри локальных сетей. При этом они требуют повышенного внимания с точки зрения обеспечения безопасности и сохранности данных.
Для обеспечения конфиденциальности данных может применяться шифрование EFS.
Для обеспечения хранения разных версий документов может использоваться технология Volume Shadow Copy.

Требования клиентов к службе понятны: высокая доступность; сохранность данных, а при использовании различных файловых приложений, например «1С» или перемещаемые профили, это требование становится критическим; возможность быстрого доступа из удаленных подразделений; обеспечение конфиденциальности данных; простота применения.

При работе службы, в зависимости от используемых функций, может быть задействовано большое количество различных механизмов, за исключением служб преобразования имен. Собственно файловая система и механизмы разграничения прав зависят от:

свободного места на дисках;
информации о состоянии дисков и массивов дисков;
производительности дисковой подсистемы;
службы теневого копирования;
квот файловой системы;
EFS;
инфраструктуры PKI;
службы DFS и ее новой версии — DFS-R.

Для передачи данных используются протоколы SMB и SMBv2. Для обеспечения доступности достаточно организовать работу сервера на стабильном аппаратном обеспечении. Для сохранности данных необходима политика резервного копирования, разрабатываемая в зависимости от требований к скорости восстановления, объемам резервных копий, объемам хранимой истории и т. д.

Под возможностью быстрого доступа понимается возможность использования локальных по отношению к географическому положению или к каналам связи файлов и данных. Таким образом, работа с файлами на медленных каналах связи в течение рабочего времени должна быть минимизирована. Для этого могут применяться различные технологии, от автономных папок до DFS.

С точки зрения конфиденциальности могут применяться как стандартные права доступа файловой системы и общих ресурсов, так и механизмы EFS. Для корректной организации доступа необходимо разработать политику безопасности, которая будет описывать, кому и какие данные доступны; какие данные требуют повышенных средств защиты и применяется ли к ним шифрование; применяются ли агенты восстановления и правила использования учетных записей и ключей агентов и политика их сертификатов.

Ввиду сказанного необходимо наблюдать за доступностью файлового сервера в сети (с помощью ping) и разрешением его имени с использованием различных систем разрешения имен, а также за службами, обеспечивающими сетевой доступ, как минимум за Server и Netlogon.

О состоянии аппаратного обеспечения сервера и дисковой подсистемы свидетельствуют:

аппаратные ошибки дисков;
состояние функции SMART;
дополнительная диагностика RAID;
производительность и загрузка дисковой подсистемы;
скорость реакции дисковой подсистемы;
объем занятого/свободного места на дисках;
исполнение процедур резервного копирования;
события аудита доступа к ресурсам файлового сервера;
события, связанные с квотами файловой системы;
конфигурация сетевого экрана, касающаяся файлового сервера;
DFS/FRS, DFS-R.

Средства технической реализации мониторинга различны. Простую проверку соединения можно выполнить с помощью команды Powershell 2.0

test-connection -computername

а проверку служб server и netlogon — в коде

function fileserverServices ($servername=
'localhost'){
   $status = get-service -ComputerName
   $servername lanmanserver,
   netlogon -ErrorActionSilentlyContinue
   Write-Output $status[0].status,
   $status[1].status
}

Состояние дисков можно проверить в том случае, если драйвер поддерживает соответствующий механизм WMI

get-wmiobject -namespace root\wmi -class
   MSStorageDriver_FailurePredictStatus

Кроме того, Microsoft не гарантирует корректности этого метода.

Дополнительный мониторинг производительности дисковой подсистемы возможен с помощью счетчиков из таблицы 1.

Таблица 1. Мониторинг производительности дисковой подсистемы

Свободное место укажет счетчик \LogicalDisk (*)\% Free Space. Счетчик применим к каждому отдельному экземпляру логического диска. Получить его данные можно таким образом:

Get-Counter -Counter '\LogicalDisk
   (c:)\% Free Space'

а для всех дисков так:

Get-Counter -Counter '\LogicalDisk (*)\%
   Free Space'

Квоты можно получить с помощью кода

$strComputer = "."
$colItems = get-wmiobject -class
   "Win32_DiskQuota" -namespace
   "root\CIMV2" `
-computername $strComputer
foreach ($objItem in $colItems) {
   write-host "Disk Space Used:"
   $objItem.DiskSpaceUsed
   write-host "Limit:" $objItem.Limit
   write-host "Quota Volume:"
   $objItem.QuotaVolume
   write-host "Status:" $objItem.Status
   write-host "User:" $objItem.User
   write-host "Warning Limit:"
   $objItem.WarningLimit
   write-host
}

Сетевой экран настраивается при помощи команды netsh из сценария, это обусловлено тем, что из сценария на powershell можно вызывать обычные консольные утилиты. С другой стороны, для этого может использоваться COM-объект HNetCfg.FWPolicy2. Например, получить список правил можно так:

$fw = New-Object -ComObject
   HNetCfg.FWPolicy2
$fw.Rules | Format-Table Name,
   Enabled, Direction -AutoSize

Службы печати

Простая служба доступа к общим принтерам организации во многих случаях тоже предоставляется довольно неорганизованно. В итоге процессы печати и использование ресурсов принтеров оказываются неэффективными, затратными. Для эффективного использования требуется наличие специализированных принтеров или специального оборудования. Правда, сейчас такое оборудование стоит сравнительно недорого.

Требования клиентов к службе таковы: высокая доступность, легкость использования и простота настройки клиентов. Для обслуживания очереди печати используется служба очереди печати spooler service. Задания на печать могут сохраняться в специальном файле на диске. В результате, если на диске с файлом недостаточно места, клиенты могут получить отказ при попытке печати. В Windows 2003 по умолчанию файл очереди печати хранится в папке %systemroot%\System32\Spool\Printers, однако может быть перемещен в целях повышения производительности на диск, отличный от того, на который установлена операционная система. Кроме того, согласно документу базы знаний Microsoft за номером kb314105 (http://support.microsoft.com/kb/314105), файл очереди может быть перемещен для каждого принтера в отдельности.

Ввиду сказанного необходимо наблюдать за:

доступностью файлового сервера в сети (ping) и разрешением его имени с использованием различных систем разрешения имен;
службами, обеспечивающими сетевой доступ; как минимум, за состоянием служб Server, Netlogon и Spooler;
доступностью сетевых принтеров (ping);
наличием места на диске, содержащем очередь печати;
настройками сетевого экрана, которые касаются сервера печати.

Средства реализации мониторинга

Команда Powershell 2.0:

test-connection -computername

Службы server и netlogon проверяются так:

function fileserverServices
    ($servername='localhost'){
$status = get-service -ComputerName
   $servername lanmanserver, netlogon,
   spooler -ErrorAction SilentlyContinue
Write-Output $status [0].status,$status
   [1].status,$status [2].status}

Свободное место опишет счетчик \LogicalDisk (*)\% Free. Замечу, что службы факсов зависят от служб печати. Для их мониторинга надо наблюдать за службой fax service.

Active Directory

По большому счету AD — это не просто «каталог служб». Это средство, позволяющее повысить эффективность использования сетевой инфраструктуры и различных ресурсов. Упростить работу в сети, облегчить обмен документами, ускорить бизнес-процессы. Конечно, сама по себе AD этого не делает. Она используется как фундамент для построения сетевой инфраструктуры, позволяющей это сделать.

Служба AD очень сложна в устройстве и функционировании. Сложность растет пропорционально росту структуры AD, то есть росту сети. Особенно если сеть представляет собой сложную систему с удаленными подразделениями, офисами и т. п. Однако в таких системах ее применение, при правильном проектировании, значительно упрощает поддержку самой системы и пользователей. Сложность системы обусловлена большим количеством компонентов, процессов и механизмов, которые применяются для ее работы. В частности, для работы AD используются следующие службы:

Active Directory/LSA;
обозреватель компьютеров;
распределенная файловая система;
служба репликации файлов;
центр распространения ключей Kerberos;
Net Logon;
удаленный вызов процедур (RPC);
служба сервера;
протокол SMTP (в случае соответствующей настройки);
WINS (в Windows Server 2003 с пакетом обновления 1 (SP1) и более новых версиях для резервных репликаций Active Directory, если служба DNS не работает);
служба времени Windows;
служба веб-публикации.

Многие из указанных служб критичны. Некоторые, такие как обозреватель компьютеров, не очень. Кроме того, в простой однодоменной структуре существует большое количество различных логических объектов, выполняющих ту или иную роль в функционировании системы, например роли FSMO, контроллеры домена, каталог Global Catalog, центр KDC, служба KCC, репликации контроллеров домена внутри домена и между сайтами и т. д. И если за службами можно наблюдать непосредственно, то состояние многих логических объектов можно контролировать только посредством использования системных журналов или консольных утилит. Параметры, за которыми стоит наблюдать, описаны в статье http://technet.microsoft.com/en-us/library/cc180912.aspx.

Обязательной является корректная процедура резервного копирования контроллеров доменов, баз DNS и DHCP.

Выводы с точки зрения мониторинга требуют слежения за следующими объектами и событиями:

Состояние (Ping).
Службы на контроллерах домена: распределенная файловая система, служба репликации файлов, центр распространения ключей Kerberos, Net Logon, удаленный вызов процедур (RPC), серверпротокол SMTP (в случае соответствующей настройки), WINS (в Windows Server 2003 с пакетом обновления 1 (SP1) и более новых версиях для резервных репликаций Active Directory, если служба DNS не работает), служба времени Windows, DNS.
Объекты репликаций между DC.
«Здоровье» сервера — состояние дисков (SMART), свободное место, загрузка процессора, загрузка памяти.
Процесс резервного копирования.
Некоторые системные события.
Доступность ролей FSMO, их правильное расположение и доступность поддерживающих их серверов.

Опишу только те методы, которые не были описаны выше для других служб. К сожалению, простых механизмов типа готовой команды, позволяющих просто запросить состояние репликации, не существует. Однако в статье по адресу http://blogs.msdn.com/b/adpowershell/archive/2009/11/01/accessing-replication-metadata-using-adpowershell.aspx описан метод получения метаданных репликации из AD и их дальнейшего анализа. Состояние сервера можно отслеживать при помощи счетчиков и команды get-counter. Для сбора системных событий существует команда get-eventlog.

DNS Server

Сервер DNS обеспечивает разрешение имен в сетях, основанных на протоколах TCP/IP. Иначе говоря, он позволяет пользователям клиентских компьютеров применять для идентификации удаленных узлов имена, а не числовые IP-адреса. Клиентский компьютер при этом отправляет имя удаленного узла серверу DNS, а тот возвращает компьютеру соответствующий IP-адрес. После этого клиентский компьютер может отправлять сообщения непосредственно на IP-адрес удаленного узла. Если в базе данных сервера DNS нет записи, соответствующей удаленному узлу, он может возвратить клиенту адрес сервера DNS, у которого, возможно, есть сведения об этом удаленном узле, или самостоятельно запросить эти сведения у другого сервера DNS. Данный процесс может выполняться рекурсивно до тех пор, пока клиентский компьютер не получит необходимый ему IP-адрес или пока не выяснится, что указанное имя не относится к узлу в определенном пространстве имен DNS. Выводы с точки зрения мониторинга следующие:

выполнение Ping по адресу;
мониторинг состояния службы DSN Server и активности DNS при помощи журнальных файлов (http://technet.microsoft.com/en-us/library/cc776384(WS.10).aspx);
мониторинг производительности DNS, если он нужен (http://technet.microsoft.com/en-us/library/cc778608(WS.10).aspx);
тестовые попытки разрешения имен при помощи nslookup.

DHCP Server

Dynamic Host Configuration Protocol (DHCP) — это клиент-серверный протокол, призванный облегчить конфигурирование сетевых настроек рабочих станций. Он динамически предоставляет рабочим станциям такие сетевые настройки, как IP-адрес, адрес DNS-сервера, шлюза по умолчанию. Операционные системы Windows Server включают реализацию DHCP. Выводы с точки зрения мониторинга:

выполнение Ping по адресу;
мониторинг состояния службы DHCP Server;
мониторинг производительности DHCP, если он нужен (http://technet.microsoft.com/en-us/library/cc783018(WS.10).aspx);
мониторинг активности DHCP при помощи файлов журнала (http://technet.microsoft.com/en-us/library/cc776384(WS.10).aspx).

Службы удаленных рабочих столов

Существует два режима работы терминальных служб: режим администрирования и собственно терминальный сервер. Режим администрирования не требует дополнительного лицензирования и службы terminal server licensing. При этом он предусматривает всего два подключения к серверу. Терминальный режим соответственно мощнее, но и требует лицензирования. В обоих случаях используется протокол RDP. Во втором случае необходим сервер лицензий. При этом если используется windows 2000 TS, то сервер лицензий должен располагаться на контроллере домена. Для windows 2003 этого не требуется. Для проверки доступности самого терминального сервера можно проверить ping и возможности подключения к RDP. Выводы с точки зрения мониторинга:

Ping;
запущены ли службы TermService и TermServLicensing;
состояние выданных лицензий;
конфигурация сетевого экрана.

Связь с подразделениями

Этот механизм стоит рассматривать не только как связь между удаленными подразделениями одной организации, а вообще как несколько высокоскоростных сетей, связанных между собой одним или несколькими каналами связи разных типов. Под высокоскоростными сетями стоит понимать локальные сети типа ethernet и т. д. А под каналами — низкоскоростные соединения между ними. Каналы могут быть образованы на основе различных технологий, что может усложнить мониторинг. Такие сети могут разбиваться на различные подсети ip. Во многих случаях такое разбиение может быть неоптимальным или некорректным. Все это в свою очередь требует применения тех или иных механизмов поддержки маршрутизации. В худшем случае применяются статические методы. Выбор протокола маршрутизации зависит от топологии сети и требований к отказоустойчивости и скорости.

Основным требованием клиентов к службе является возможность бесперебойного обмена данными с критичными подразделениями. Чаще всего этого не требуется, но порой такая необходимость все же возникает. Тогда нужно провести дополнительное изучение сети клиента и предложить те или иные решения.

Во многих случаях разбиение на подсети происходит довольно странным образом, что в свою очередь приводит к неверной или излишне перегруженной маршрутизации, некорректным направлениям трафика, перегрузке каналов и т. д. Для борьбы с этим необходим как мониторинг, так и тщательное проектирование сети, правильный выбор разбиения, протоколов маршрутизации и топологии сети.

Вывод с точки зрения мониторинга: для упрощения мониторинга состояния каналов, дабы избежать наблюдения за большим числом различных типов соединений, лучше всего использовать стандартный ping. Кроме того, с точки зрения клиентов, не важно, функционирует канал или нет. Их интересует, можно ли отправить почту, забрать или записать файлы на удаленные сетевые ресурсы или принтеры. Поэтому, кроме ping, нужно обращать внимание на доступность клиентских служб, хотя бы в режиме доступен/недоступен, и загрузку каналов. Ping в этом случае служит скорее методом поиска причины неисправности. Итак:

Ping.
Tracert.
Загрузка каналов.
Доступность служб.
Перечисление содержимого общих папок.
Разрешение имен.
Синхронизация времени.

Сайты

Мне думается, что если подойти к этой задаче с более подробным мониторингом, то можно не только сразу заметить наличие проблемы, но и определить ее причину. Если, к примеру, отправить только запрос http, в случае его неудачи будет ясно, что проблема есть. А чтобы ее решить, нужно провести дополнительную диагностику. С расширенным мониторингом основные проблемы можно выявить сразу:

Ping.
Разрешение имени.
Запрос http/https.

Почтовые службы

В простейшем случае почтовые службы представляют собой обычный почтовый сервер, используемый для обмена почтовыми сообщениями как внутри организации, так и с внешним миром. Требования клиентов к службе: высокая доступность, скорость доставки, ведение журнала писем, защита от спама.

Ввиду большого количества различных почтовых серверов, остановлюсь на Exchange Server 2003, как на наиболее распространенном в данный момент. Основные службы, используемые при функционировании сервера, перечислены в таблице 2.

Таблица 2. Основные службы Exchange Server 2003

Кроме того, если данная служба используется для отправки писем в Интернет, для нее существует почтовый домен и т. д., то необходим дополнительный мониторинг сетевых подключений в Интернет. Вывод с точки зрения мониторинга — необходимо наблюдать за:

службами Exchange;
доступностью сервера изнутри сети (ping);
очередями сообщений;
корректным разрешением имен Интернета;
корректностью установки соединений smtp с внешними почтовыми серверами;
свободным местом на дисках, где хранятся база и журналы транзакций Exchange;
состоянием резервного копирования базы;
доступностью AD.

Замечу, что новые версии Exchange имеют сходную архитектуру и более развитые средства мониторинга.

SQL Server

Мощная и сравнительно простая в использовании база данных. Существует в нескольких редакциях, от бесплатной http://www.microsoft.com/express/Database/ до дорогого кластерного решения. Для малого и среднего бизнеса вполне достаточно бесплатной версии, однако у нее есть ограничения. Требования клиентов к службе — доступность, скорость, отказоустойчивость. Под последней понимается не столько устойчивость к падениям, с этим обычно нет проблем, сколько возможность восстановления данных после сбоя или ошибки ввода/удаления данных.

SQL Server в ее нынешнем виде может состоять из большого количества различных служб, представляющих разные компоненты. Эти службы входят в различные редакции сервера, в частности в бесплатный вариант входит только служба DB Engine. На физическом сервере может быть запущен как один экземпляр сервера баз данных, так и несколько именованных экземпляров. Это необходимо учитывать при мониторинге. Также стоит иметь в виду, что мониторинг и оптимизация производительности сервера баз данных и просто мониторинг его «здоровья» — две совершенно разные задачи. Мониторинг состояния — задача сравнительно простая, требующая контроля всего нескольких параметров как самой базы данных, так и некоторых стандартных параметров операционной системы. Мониторинг и оптимизация производительности — задача намного более обширная и сложная. Она требует расширенного мониторинга большого списка параметров как SQL Server, так и Windows, аппаратного обеспечения и т. д. В данном случае речь идет о мониторинге состояния сервера баз данных.

В простейшем случае для работы DB Engine может быть задействовано три системных службы. Это основные. Кроме того, сервер активно использует память, диск и процессор. Для обеспечения отказоустойчивости в указанном смысле базы данных должны быть определенным образом настроены. Кроме того, необходимо настроить резервное копирование баз, согласно разработанному плану резервного копирования, который, в свою очередь, отражает требования к необходимости восстановления тех или иных баз, скорости этого процесса и гранулярности восстановления. То есть нужно иметь возможность откатывать транзакции на определенное время (часы, минуты, секунды) или достаточно просто восстановить конкретный день или месяц.

Выводы с точки зрения мониторинга:

Ping.
Запущены ли службы default instance database engine, sql server agent, server browser (не обязательно).
Процессор.
Загрузка памяти.
Свободное место на дисках с базами.
Процесс резервного копирования.

Андрей Вернигора (eosfor@gmail.com) — системный администратор, ведет блог http://eosfor.blogspot.com. Имеет сертификаты MCSA, MCDBA, MCSE, MCT