Август 2008 Август 2008
SQL Server: Лучшие советы по эффективному обслуживанию баз данных
Слишком часто люди, не являющиеся подготовленными администраторами баз данных, оказываются ответственными за базу данных. Для обслуживания ее им не хватает подготовки и знаний, что ведет к появлению проблем. Это учебник для всех невольных администраторов баз данных, которым необходим ускоренный курс методов обслуживнаия баз данных. Пол С. Рэндал (Paul S. Randal)
Администрирование в Windows: Измерьте пульс вашего сервера
Пользователи жалуются на плохую работу серверазнаете ли вы, что делать, чтобы определить проблему? Монитор производительности может оказаться незаменимым средством в этой ситуации, поскольу он обладает множеством диагностических возможностей. Ознакомьтесь с обзором основных показателей, которые следует использовать для дианостики множества распространенных узких мест, замедляющих работу ваших серверов. Стивен Чой (Steven Choy)
System Center: Windows PowerShell в System Center Operations Manager
В System Center Operations Manager 2007 интегрирован Windows PowerShell, что значительно упростило выполнение основных задач администрирования за счет автоматизации. В статье приводится обзор использования Windows PowerShell и OpsMgr при повседневном обслуживании, управлении агентами и др. Марко Шо
Internet Information Services: Масштабирование приложений ASP.NET: Извлеченные уроки
Ключом к успешному масштабированию приложения ASP.NET является совместная работа между разработчиками сетевыми администраторами, с самого начала жизненного цикла приложения. Узнайте, какие факторы необходимы для масштабирования приложения и как это сотрудничество может помочь в обеспечении правильной работы приложения. Ричард Кэмпбелл (Richard Campbell)
Columns
Письмо редактора: Прямая связь с конференции TechEd: | Письма в редакцию: Мнения читателей: | Инструментарий: Новые продукты для специалистов по информационным технологиям:
Вопросы и ответы по SQL: Секционирование, проверки согласованности и другое: Пол Рэндал ответить на ваши вопросы по SQL Server, покажет, как производить проверки целостности и другое обслуживание больших баз данным, как справиться со случайным обновление и т.д.Пол С. Рэндал (Paul S. Randal) | Обзор служебных программ: Служебная программа очистки файлов установщика Windows: Остаточные данные настроек установщика Windows могут привести к осложнениям при попытках обновления или удаления приложений. Можно разрешить проблемы с помощью служебной программы очистки файлов установщика Windows, которая поможет удалить информацию установщика Windows для приложения, а затем переустановить приложение.Лэнс Уитни (Lance Whitney) | Sharepoint изнутри: Поиск и устранение неполадок в интеграции с единой системой обмена сообщениями: Интеграция SharePoint в защищенную среду обмена сообщениями — задача нетривиальная, однако повышение производительности, полученное в результате, стоит всех потраченных усилий. В этой статье приводится ряд советов по поиску и устранению неполадок, возникающих при настройке интегрированной среды.Пав Черны (Pav Cherny)
Язык сценариев Windows PowerShell: Краткий обзор удаленного управления в версии 2.0: В настоящий момент идет работа над Windows PowerShell 2.0, а версия CTP предоставляет несколько новых отличных возможностей. В статье рассматривается удаленная работа – одна из самых замечательных функций версии CTP2 Windows PowerShell 2.0.Дон Джонс (Don Jones) | Эй, сценарист!: Выбираем быстрый путь: С появлением Windows Vista элемент управления ActiveX UserAccounts.CommonDialog для открытия диалогового окна открытия файлов прекратил свое существование. В статье представлен способ решения этой проблемы с помощью Visual Basic Express Edition.Создатели сценариев корпорации Майкрософт | Материалы о рабочей среде: Введение в работу служб развертывания Windows: Изучите различные версии служб развертывания Windows, познакомьтесь с записью индивидуализированного образа ОС и узнайте, что необходимо для повышения автоматизации установок.Уэс Миллер (Wes Miller)
На страже безопасности: Пароли и кредитные карты, часть 2: В последней части серии из трех статей Джеспер Йоханссон обсуждает то, как поставщики программного обеспечения, наборы безопасности и маркетинговая деятельность препятствуют попыткам действительного обеспечения безопасности, и как подобные действия могут привести к обвалу экосистемы безопасности технологии.Йеспер М. Йоханссон (Jesper M. Johansson) | Экологически безопасная компьютеризация: Отфильтровать «зеленый камуфляж»: Знакомство со структурой энергопотребления теперь является ключевой частью управления информационной инфраструктурой. Узнайте о стратегиях, которые можно использовать для организации наблюдения за энергопотреблением в своей среде, чтобы лучше знать энергопотребление устройств в своей организации.Дейв Охара (Dave Ohara) | Заметки разъездного инженера: IMAP спасает мир: Ваша электронная почта сохранена в куче разных мест, в разных форматах и на разных операционных системах? Рыкандар Коррати демонстрирует доступ к электронной почте из одного места с помощью IMAP4.Рыкандар Коррати (R'ykandar Korra'ti)
О Windows из первых рук: Строительство на старом фундаменте: Рэймонд объясняет, как некогда мощная система Alpha AXP вышла из отставки, чтобы помочь разработать новое поколение 64-разрядных систем.Рэймонд Чен (Raymond Chen)


SQL Server
Лучшие советы по эффективному обслуживанию баз данных
Пол С. Рэндал (Paul S. Randal)
Краткий обзор.
  • Управление файлами данных и журналов транзакций
  • Устранение фрагментации индекса
  • Обеспечение наличия точной, свежей статистики
  • Обнаружение поврежденных страниц базы данных
  • Организация эффективной стратегии резервного копирования

Cодержание
Управление файлами данных и журналов
Фрагментация индекса
Статистика
Обнаружение повреждений
Резервные копии
Заключение
По нескольку раз в неделю у меня проcят совета, как эффективно обслуживать рабочую базу данных. Порой вопросы исходят от администраторов баз данных, которые применяют новые решения и ищут помощи в
подгонке практики обслуживания под характеристики новых баз данных. Чаще вопросы исходят от людей, которые не являются профессиональными администраторами баз данных, но, по той или иной причине, владеют базой данных или несут за нее ответственность. Я предпочитаю называть их «невольными администраторами баз данных». Задача этой стать состоит в предоставлении учебника по наилучшим вариантам обслуживания баз данных для .
Как и в случае с большинством задач и процедур в мире информационных технологий, годящегося на любой случай эффективного решения обслуживания баз данных не существует, но есть несколько ключевых областей, которые почти всегда требуют внимания. Моя личная первая пятерка этих областей, перечисленная без определенного порядка важности:
  • Управление файлами данных и журналов
  • Фрагментация индекса
  • Статистика
  • Обнаружение повреждений
  • Резервные копии
У необслуживаемой (или плохо обслуживаемой) базы данных могут возникнуть проблемы в одной или нескольких из этих областей, что со временем может привести к плохой работе приложений или даже простоям и потере данных.
В этой статье я объясню, почему эти проблемы важны, и покажу некоторые простые пути их смягчения. Мои объяснения будут основаны на SQL Server® 2005, но я также выделю основные отличия, с которыми можно столкнуться в SQL Server 2000 и предстоящем SQL Server 2008.

Управление файлами данных и журналов
Первая область, которую я всегда рекомендую проверить при принятии управления базой данных – это параметры, связанные с управлением файлами данных и журнала (транзакций). Точнее говоре, следует убедиться, что:
  • Файлы данных и журнала отделены друг от друга, а также изолированы от всего остального
  • Автоматическое увеличение настроено верно
  • Настроена автоматическая инициализация файлов
  • Автоматическое сжатие отключено, и сжатие не является частью какого-либо плана обслуживания
Когда файлы данных и журнала (которые, в идеале, вообще должны быть на разных томах) находятся в одном томе с любым другим приложением, которое создает или расширяет файлы, возникает возможность для фрагментации файлов. В файлах данных избыточная фрагментация файлов может давать небольшой вклад в плохую работу запросов (особенно тех, что просматривают очень большие объем данных). В файлах журналов она может нанести гораздо более серьезный удар по производительности, особенно если автоматическое расширение установлено лишь на очень небольшое увеличение размера файла каждый раз, как в нем возникает потребность.
Файлы журнала внутренне разделены на разделы, именуемые виртуальными файлами журнала (Virtual Log Files – VLF), и чем выше фрагментация в файле журнала (я использую здесь единственное число, поскольку наличие нескольких файлов журнала не имеет большого смысла – в базе данных следует держать только один), тем больше число VLF. После того, как число VLF в файле журнала превышает, скажем, 200, может ухудшиться производительность связанных с журналом операций, таких как чтение журнала (скажем, для транзакционной репликации/отката), резервное копирование журнала и даже триггеров в SQL Server 2000 (реализация триггеров изменилось в SQL Server 2005 с журнала транзакций на инфраструктуру версий строк).
Что касается размеров файлов данных и журнала, лучше всего создавать их с подходящим первоначальным размером. Для файлов данных при выборе первоначального размера должна приниматься во внимание возможность добавления к базе дополнительных данных в ближайшей перспективе. Например, если первоначальный размер данных равен 50 ГБ, но известно, что в течение следующих шести месяцев будет добавлено еще 50 ГБ данных, имеет смысл сразу создать файл данных размером в 100 ГБ вместо того, чтобы выращивать его до этого размера в течение нескольких месяцев.
С файлами журналов дело, увы, обстоит несколько сложнее – необходимо учитывать такие факторы, как размер транзакции (долгосрочные транзакции не могут быть удалены из журнала до своего завершения) и частоту резервного копирования журнала (поскольку именно при нем удаляются неактивные части журнала). Дополнительные сведения приведены в "8 Steps to Better Transaction Log Throughput («8 шагов к улучшению пропускной способности журнала транзакций»)", популярной записи в блоге на SQLskills.com, написанной моей женой, Кимберли Трипп (Kimberly Tripp).
После того, как размеры файлов установлены, за ними следует наблюдать в различные моменты, и их следует заранее увеличивать вручную в подходящее время суток. Автоматическое увеличение следует оставить в качестве предосторожности на всякий случай, чтобы файлы могли расти по мере необходимости в случае какого-либо необычного события. Причина, по которой управление файлами не следует целиком оставлять автоматическому увеличению, состоит в том, что автоматическое увеличение небольшими кусками ведет к фрагментации файлов и что автоматическое увеличение может занимать много времени, тормозя работу приложения в неожиданные моменты.
Размер автоматического увеличения следует установить на определенное значение, а не на процент, чтобы ограничивать время и место, необходимые для выполнения автоматического увеличения, если оно происходит. Например, в случае 100-гигабайтного файла данных желательно зафиксировать размер автоматического увеличения как 5 ГБ, а не, скажем, 10%. Это значит, что он всегда будет увеличиваться на 5 ГБ вне зависимости от текущего размера файла, а не на объем, увеличивающийся после каждого увеличения файла (10 ГБ, 11 ГБ, 12 ГБ и так далее).
Когда журнал транзакций увеличивается (либо вручную, либо через автоматическое увеличение), он всегда инициализируется нулями. Файлы данных имеют то же поведение по умолчанию в SQL Server 2000, но начиная с SQL Server 2005 в них можно включить мгновенную инициализацию файла, которая пропускает инициализацию файлов нулями и, как следствие, делает увеличение и автоматическое увеличение практически мгновенными. В противоположность распространенным представлениям, эта функция доступна во всех выпусках SQL Server. Дополнительные сведения можно найти, введя "instant file initialization" («мгновенная инициализация файла») в указателе электронной документации для SQL Server 2005 или SQL Server 2008.
Наконец, следует позаботиться, чтобы никоим образом не было включено сжатие. Сжатие можно использовать для уменьшения размера файла данных или журнала, но это очень грубый, ресурсозатратный процесс, который вызывает широкую логическую фрагментацию просмотра в файлах данных (подробности см. ниже) и ведет к низкой производительности. Я изменил запись о сжатии в электронной документации SQL Server 2005, включив предупреждение об этом. Впрочем, сжатие отдельных файлов данных и журнала вручную может быть допустимо при особых обстоятельствах.
Видео
Здесь Пол Рэндал демонстрирует, как сжатие и автоматическое сжатие могут вызывать серьезные проблемы с фрагментацией в базе данных.

Автоматическое сжатие особенно вредно, поскольку оно запускается каждые 30 минут в фоновом режиме и пытается сжимать базы данных, для которых выставлен параметр автоматического сжатия. Этот процесс не вполне предсказуем в том, что он сжимает лишь базы данных с более чем 25% свободного места. Автоматическое сжатие использует массу ресурсов и вызывает понижающую производительность фрагментацию, так что оно нежелательно при любых обстоятельствах. Его всегда следует отключать с помощью:
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
План регулярного облуживания, включающий выдачу базе данных команды на сжатие вручную, почти столь же плох. Если обнаружится, что база данных постоянно растет после того, как план обслуживания сжимает ее, то это вызвано тем, что базе данных данное пространство нужно для работы.
Лучше всего позволить базе данных вырасти до размера стабильного состояния и избегать сжатия вообще. Дополнительные сведения о недостатках использования сжатия, а также кое-какие комментарии по новым алгоритмам в SQL Server 2005 можно найти в моем старом блоге MSDN® на blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx.

Фрагментация индексов
Помимо фрагментации на уровне файловой системы и внутри файла журнала, также возможна фрагментация внутри файлов данных, в структурах, хранящих данные таблиц и индексов. Внутри файла данных может произойти два базовых типа фрагментации:
  • Фрагментация внутри отдельных страниц данных и индекса (порой именуемая внутренней фрагментацией)
  • Фрагментация внутри структур индекса или таблиц, состоящих из страниц (именуемая логической фрагментацией просмотра и фрагментацией просмотра по экстентам)
Внутренняя фрагментация – это наличие в странице больших пустых пространств. Как показывает рис. 1, каждая страница в базе данных имеет размер 8 КБ и 96-байтный заголовок; как следствие, страница может хранить примерно 8096 байтов данных индексов или таблиц (конкретные внутренние структуры таблиц и индексов для данных и структур строк можно найти в моем блоге по адресу sqlskills.com/blogs/paul, в категории Inside The Storage Engine («Внутри механизма хранения»)). Пустое пространство может возникнуть, если каждая таблица или запись в индексе превышают по размерам половину страницы, поскольку тогда на странице можно сохранить лишь одну запись. Исправить это очень сложно или невозможно, поскольку для исправления необходимо изменение схемы таблицы или индекса, например, путем изменения ключа индекса на что-то, что не вызывает случайные точки вставки, как это делает GUID.
Рис. 1. Структура страницы базы данных (щелкните изображение, чтобы увеличить его)
Чаще внутренняя фрагментация вызывается изменениями данных, такими как вставки, обновления и удаления, что может оставить на странице пустые места. Неверное распоряжение коэффициентом заполнения также может способствовать фрагментации, подробности приведены в технической документации. В зависимости от схемы таблицы/индекса и характеристик приложения это пустое место может оказаться непригодным для повторного использования после его появления, что может привести к постоянному росту неиспользуемого места в базе данных.
Рассмотрим, для примера, таблицу из 100 миллионов строк, где средняя запись имеет размер 400 байтов. Со временем шаблон изменения данных приложения приведет к появлению в среднем 2800 байтов свободного пространства на страницу. Общее пространство, требуемое таблицей, составляет 59 ГБ, это выводится путем следующего расчета: 8096-2800 / 400 = 13 записей на 8-килобайтную страницу, затем делим 100 миллионов на 13, чтобы получить число страниц. Если бы пространство не пропадало, то на одной странице можно было бы уместить 20 записей, что уменьшает общее требуемое пространство до 38 ГБ. Огромная экономия!
Неиспользуемое место на страницах данных/индекса может, таким образом, привести к хранению того же объема данных на большем числе страниц. Это не только приводит к большему расходу места на диске, но и значит, что запросу надо провести больше операций ввода/вывода, чтобы прочесть тот же объем данных. И все эти дополнительные страницы занимают больше места в кэше данных, занимая тем самым память сервера.
Логическая фрагментация просмотра вызывается операцией, именуемой разбиением страницы. Это происходит, когда запись необходимо вставить на определенную страницу индекса (согласно определению ключа индекса), но на странице недостаточно места, чтобы разместить вставляемые данные. Страница разбивается пополам, и примерно 50% записей перемещаются на свежевыделенную страницу. Эта новая страница обычно не является физически смежной со старой и, следовательно, именуется фрагментированной. Концепция фрагментации просмотра по блокам аналогична. Фрагментация внутри структур таблиц/индексов влияет на возможность SQL Server выполнять эффективные просмотры как по всей таблице/индексу, таки и ограниченные предложением WHERE запроса (такие как SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000).
На рис. 2 показаны свежесозданные страницы индекса со 100-процентным коэффициентом заполнения – страницы полны, и физический порядок страниц совпадает с логическим порядком. На Рис. 3 показана фрагментация, которая может происходить после случайных вставок/обновлений/удалений.
Рис. 2. Свежесозданные страницы индекса без фрагментации, страницы полны на 100% (щелкните изображение, чтобы увеличить его)
Рис. 3 Страницы индекса, показывающие внутреннюю фрагментацию и фрагментацию логического просмотра после случайных вставок, обновлений и удалений (щелкните изображение, чтобы увеличить его)
Фрагментацию порой можно предотвратить, изменив схему таблицы/индекса, но, как я упомянул выше, это может быть очень сложным или невозможным. Если предотвращение нереально, существуют способы устранения фрагментации после ее возникновения – в частности, путем восстановления или реорганизации индекса.
Восстановление индекса подразумевает создание новой копии индекса (аккуратно сжатой и настолько непрерывной, насколько это возможно, с последующим отказом от старой и фрагментированной). Поскольку SQL Server создает новую копию индекса перед удалением старой, ему требуется свободное место в файлах данных, приблизительно равное размеру индекса. В SQL Server 2000, восстановление индекса всегда проводилось в автономном режиме. Однако в SQL Server 2005 Enterprise Edition восстановление индекса можно выполнить в интерактивном режиме с некоторыми ограничениями. Реорганизация, с другой стороны, использует имеющийся алгоритм для сжатия и дефрагментации индекса; она требует лишь 8 КБ дополнительного пространства для выполнения – и всегда работает в интерактивном режиме. Кстати, в SQL Server 2000 я специально написал код реорганизации как интерактивную, экономящую пространство альтернативу перестройке индекса.
В SQL Server 2005 следует обратить внимание на команды ALTER INDEX … REBUILD для восстановления индексов и ALTER INDEX … REORGANIZE для их реорганизации. Этот синтаксис заменяет команды SQL Server 2000 DBCC DBREINDEX и DBCC INDEXDEFRAG, соответственно.
Между этими методами есть много различий, влияющих на выбор одного из них, таких как создаваемый объем журнала транзакций, требуемый объем свободного пространства в базе данных и возможность прервать процесс без потери выполненной работы. Технический документ, к котором обсуждаются эти различия, и прочее можно найти на microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. Этот документ основан на SQL Server 2000, но концепции хорошо переносятся на поздние версии.
Некоторые пользователи просто решают восстанавливать или перестраивать все индексы каждую ночь или каждую неделю (используя, например, вариант с планом обслуживания) вместо того, чтобы выяснять, какие индексы фрагментированы и какое преимущества даст устранение фрагментации. Хотя это может быть хорошим решением для невольного администратора базы данных, который просто желает применить какое-то решение с минимальными усилиями, это может оказаться очень плохим выбором для более крупных баз данных и систем, где ресурсы в дефиците.
Более сложный подход подразумевает использование динамического административного представления sys.dm_db_index_physical_stats (или DBCC SHOWCONTIG в SQL Server 2000) для периодического определения фрагментированных индексов и выбора того, следует ли работать на них, и если да, то как. В данном техническом документе также обсуждается использование этих более узких выборов. Вдобавок, некоторые образцы кода для выполнения этой фильтрации можно найти в примере D записи электронной документации, посвященной динамическому административному представлению sys.dm_db_index_physical_stats в SQL Server 2005 (msdn.microsoft.com/library/ms188917) или примере E записи электронной документации, посвященной DBCC SHOWCONTIG в SQL Server 2000 и далее (на msdn.microsoft.com/library/aa258803).
Какой бы метод ни использовался, настоятельно рекомендуется регулярно искать и устранять фрагментацию.
Обработчик запросов является частью SQL Server, которая решает, как следует исполнять запрос – а именно, какие таблицы и индексы использовать и какие операции выполнять на них для получения результатов; это именуется планом запросов. В число наиболее важных входных данных этого процесса принятия решений входит статистика, описывающая распределение значений данных для столбцов внутри таблицы или индекса. Очевидно, чтобы быть полезной для обработчика запросов, статистика должна быть точной и свежей, иначе могут быть выбраны непроизводительные планы запросов.
Статистика создается путем считывания данных таблицы/индекса и определения распределения данных для соответствующих столбцов. Статистика может быть построена путем проверки всех значений данных для определенного столбца (полной проверки), но ее также можно построить на основе указанного пользователем процента данных (проверки примеров). Если распределение значений в столбце является относительно равномерным, то проверки примеров может быть достаточно, и это делает создание и обновление статистики более быстрым, чем при полной проверке.
Обратите внимание, что статистику можно автоматически создавать и поддерживать, включив параметры базы данных AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS, как показано на рис. 4. Они включены по умолчанию, но тем, кто только что унаследовал базу данных, стоит проверить их, чтобы убедиться. Порой статистика может устареть – в этом случае возможно ее обновление вручную с помощью операции UPDATE STATISTICS для конкретного набора статистических показателей. В качестве альтернативы можно использовать хранимую процедуру sp_updatestats, которая обновляет всю устаревшую статистику (в SQL Server 2000 sp_updatestats обновляет всю статистику вне зависимости от возраста).
Рис. 4. Изменение параметров базы данных через SQL Server Management Studio (щелкните изображение, чтобы увеличить его)
Если нужно обновлять статистику как часть плана регулярного обслуживания, то нужно помнить об одной хитрости. И UPDATE STATISTICS, и sp_updatestats по умолчанию используют ранее указанный уровень сбора данных (если указан какой-то) – и он может быть ниже, чем полная проверка. Восстановления индекса автоматически обновляют статистику с помощью полной проверки. В случае обновления статистики вручную после восстановления индекса можно получить еще менее точную статистику! Это может произойти, если проверка примеров из обновления вручную перепишет полную проверку, созданную восстановлением индекса. С другой стороны, при реорганизации индекса статистика вообще не обновляется.
Опять-таки, многие имеют план обслуживания, обновляющий всю статистику в какой-либо момент до или после восстановления всех индексов – и сами того не зная, они могут оказаться с менее точной статистикой. Если выбрано простое восстановление всех индексов время от времени, то оно позаботится и о статистике. Если выбран более сложный путь с устранением фрагментации, это стоит делать и для обслуживания статистики. Я предлагаю следующее:
  • Проанализируйте индексы и определите, на каком индексе следует работать и как провести дефрагментацию.
  • Обновите статистику для всех индексов, которые были восстановлены.
  • Обновите статистику для всех неиндексированных столбцов.
Дополнительную информацию о статистике можно найти в техническом документе "Statistics Used by the Query Optimizer in Microsoft® SQL Server 2005" («Статистика, используемая оптимизатором запросов в Microsoft SQL Server 2005») (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Обнаружение повреждений
Я рассказал об обслуживании, связанном с производительностью. Теперь пора переключиться на рассказ об обнаружении повреждений и смягчении последствий.
Крайне маловероятно, чтобы в базе данных содержалась совершенно бесполезная информация, которая никого не волнует – так как же можно убедиться, что данные остаются неповрежденными и восстанавливаемыми в случае аварийной ситуации? Подробности сведения воедино полной стратегии аварийного восстановления и высокой доступности выходят за пределы темы этой статьи, но для начала можно сделать несколько простых вещей.
Подавляющее большинство повреждений вызываются «оборудованием». Почему оно в кавычках? Ну, оборудование здесь – это на самом деле условное обозначение для «что-то в подсистеме ввода-вывода, под SQL Server». Подсистема ввода/вывода состоит из таких элементов, как операционная система, драйверы файловой системы, драйверы устройств, контроллеры RAID, кабели, сеть и сами диски. Масса мест, где могут возникнуть (и возникают) неполадки.
Одной из наиболее распространенных проблем является сбой питания в момент, когда диск ведет запись на страницу базы данных. Если диск не сможет завершить запись, прежде чем у него кончится электричество (или если операции записи кэшируются и резервного источника питания не хватит для очистки кэша диска), результатом может стать незавершенный образ страницы на диске. Это может произойти, поскольку 8-килобайтная страница базы данных на деле состоит из 16 смежных 512-байтных секторов диска. Неполная запись могла записать некоторые из секторов из новой страницы, но оставить некоторые из секторов из образа предыдущей страницы. Такая ситуация называется разорванной страницей. Как можно обнаружить, когда это случается?
У SQL Server есть механизм для обнаружения такой ситуации. В него входят сохранение нескольких битов из каждого сектора страницы и запись определенного шаблона на их месте (это происходит непосредственно перед записью страницы на диск). Если при считывании страницы шаблон изменился, то SQL Server знает, что страница «порвана», и выдает ошибку.
В SQL Server 2005 и более поздних версиях доступен более полный и способный определить любые повреждения на странице механизм, именуемый контрольными суммами страниц. В него входят запись контрольной суммы всей страницы на страницу прямо перед ее записью и затем ее проверка при считывании только что записанной информации, точно так же, как при обнаружении порванных страниц. После включения контрольных сумм страниц страницу необходимо прочитать из буферного пула, изменить каким-либо образом и записать на диск снова, чтобы она стала защищена контрольной суммой страницы.
Так что лучше всего включить контрольные суммы страниц начиная с SQL Server 2005 и далее, а для SQL Server 2000 включить обнаружение разорванных страниц. Чтобы включить контрольные суммы страниц, используйте следующий оператор:﻿
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
Чтобы включить обнаружение разорванных страниц для SQL Server 2000, используйте следующий оператор:
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
Эти механизмы позволяют обнаружить наличие повреждений на странице, но только при чтении страницы. Как можно легко организовать чтение всех распределенных страниц? Лучшим методом для выполнения этого (и обнаружения повреждений любого другого рода) является использование команды DBCC CHECKDB. Вне зависимости от указанных вариантов эта команда всегда будет читать все страницы в базе данных, таким образом заставляя проверять все контрольные суммы страниц или обнаружение порванных страниц. Следует также установить предупреждения, чтобы можно было узнать, когда пользователи сталкиваются с повреждениями при выполнении запросов. Пользователь также может быть уведомлен о всех вышеописанных проблемах, используя предупреждение о ошибках уровня серьезности 24 (рис. 5).
Рис. 5. Установка предупреждения для всех ошибок серьезности 24 (щелкните изображение, чтобы увеличить его)
Так что другой хорошей рекомендацией является регулярное выполнение DBCC CHECKDB на базах данных для проверки их целостности. Существует много вариантов этой команды и вопросов о том, как часто ее следует выполнять. Увы, технического документа, в котором это бы обсуждалось, сейчас не существует. Однако, поскольку DBCC CHECKDB была основной частью кода, которой я написал SQL Server 2005, я много писал о ней в блогах. См. категорию моего блога "CHECKDB From Every Angle" («CHECKDB со всех сторон»)(sqlskills.com/blogs/paul), в которой имеется много подробных статей, посвященных проверке целостности, рекомендациям и практическим советам. Для невольных администраторов баз данных хорошим правилом является выполнение DBCC CHECKDB после каждого полного резервного копирования базы данных. Я рекомендую выполнять следующую команду:
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
Если эта команда что-то выдает, DBCC нашел повреждения в базе данных. Тогда вопрос превращается в: «Что делать, если DBCC CHECKDB находит повреждения?». Здесь-то на сцене и появляются резервные копии.
При возникновении повреждения или иного сбоя наиболее эффективным способов восстановления является восстановление базы данных из резервных копий. Конечно, это предполагает наличие таковых копий и то, что сами они не повреждены. Слишком часто пользователи хотят знать, как заставить серьезно поврежденную базу данных работать вновь, когда у них нет резервной копии. Простой ответ состоит в том, что это невозможно, во всяком случае без потери данных, способной исковеркать всю бизнес-логику и реляционную целостность данных.
Так что регулярное резервное копирование весьма рекомендуется. Тонкости использования резервного копирования и восстановления выходят далеко за пределы этой статьи, но позвольте мне дать краткую инструкцию по созданию стратегии резервного копирования.
Во-первых, следует регулярно выполнять полное резервное копирование базы данных. Это дает единое состояние на момент времени, до которого затем можно восстанавливать. Полную резервную копию базы данных можно сделать, используя команду BACKUP DATABASE. Примеры имеются в электронной документации. Для дополнительной защиты можно использовать параметр WITH CHECKSUM, который проверяет контрольные суммы (если они есть) читаемых страниц и вычисляет контрольную сумму для всей резервной копии. Следует выбрать частоту, отражающую потерю данных или работ, которую можно себе позволить. Например, резервное копирование всей базы данных раз в день означает, что в случае сбоя может быть потеряна дневная работа в данных. В случае использования лишь полного резервного копирования базы данных следует быть в модели восстановления SIMPLE (обычно именуемой режимом восстановления), чтобы избежать сложностей, связанных с управлением ростом журнала транзакций.
Во-вторых, держите резервные копии по нескольку дней на случай, если одна из них будет повреждена – старая резервная копия лучше, чем никакой. Также следует проверять целостность своих резервных копий, используя команду RESTORE WITH VERIFYONLY (опять же, см. электронную документацию). Если при создании резервной копии был использован параметр WITH CHECKSUM, при использовании команды проверки будет проверено, верна ли еще контрольная сумма резервной копии, а также контрольные суммы страниц внутри нее.
В-третьих, если ежедневное полное копирование базы данных может привести к недопустимому для компании уровню потерь данных/сделанной работы, возможно, стоит заглянуть в разностные резервные копии базы данных. Разностная резервная копия базы данных основана на полной резервной копии базы данных и содержит запись всех изменений с момента создания последней полной копии (часто считается, что разностные резервные копии являются добавочными – это не так). В качестве примера стратегии можно привести ежедневное снятие полной резервной копии с созданием разностной копии каждые четыре часа. Разностная копия предоставляет вариант восстановления к состоянию на дополнительный момент времени. В случае использования только полного и разностного резервного копирования баз данных также следует использовать модель восстановления SIMPLE.
Наконец, наилучшие возможности по восстановлению предоставляет резервное копирование журналов. Оно доступно лишь в моделях восстановления FULL (и BULK_LOGGED) и предоставляет резервные копии всех записей журнала, созданных с момента последнего резервного копирования журнала. Поддержание набора резервных записей журнала, а также периодическое проведение полного (и, возможно, разностного) резервное копирования позволяет восстановить состояние на любой момент времени с точностью до минуты. Платить за это приходится тем, что журнал транзакций растет, пока его не «освобождают», создав резервную копию. В качестве примера стратегии здесь можно привести ежедневное снятие полной резервной копии с созданием разностной копии каждые четыре часа и резервной копии журнала каждые полчаса.
Выбор стратегии резервного копирования и организация ее применения могут быть непростыми. Как минимум, следует регулярно выполнять полное резервное копирование базы данных, чтобы убедиться в наличии как минимум одного момента времени, состояние базы данных на который может быть восстановлено.
Как можно увидеть, обеспечение работоспособности и доступности базы данных требует выполнения нескольких обязательных задач. Вот мой последний контрольный список для невольных администраторов баз данных, которым досталось управление базами:
  • Удалите избыточною фрагментации файла журнала транзакций.
  • Верно установите автоматическое увеличение.
  • Отключите любые запланированные операции сжатия.
  • Включите мгновенную инициализацию файлов.
  • Создайте регулярный процесс обнаружения и удаления фрагментации индекса.
  • Включите AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS и создайте регулярный процесс для обновления статистики.
  • Включите контрольные суммы страниц (или, как минимум, обнаружение порванных страниц на SQL Server 2000).
  • Убедитесь в наличии регулярного процесса для выполнения DBCC CHECKDB.
  • Убедитесь в наличии регулярного процесса для выполнения полного резервного копирования базы данных, а также разностного резервного копирования и копирования журнала для восстановления состояния на момент времени.
Я привел в статье команды T-SQL, но многое можно сделать и из Management Studio. Надеюсь, что я дал вам кое-какие полезные указания по эффективному обслуживанию баз данных. Если у вас есть комментарии или вопросы, отправьте их мне —paul@sqlskills.com.

Пол С. Рэндал (Paul S. Randal), генеральный директор SQLskills.com является обладателем звания MVP по SQL Server. Он работал в группе подсистемы хранения SQL Server в корпорации Microsoft с 1999 по 2007. Пол является специалистом по аварийному восстановлению, высокой доступности и обслуживанию баз данных. Он ведет блог по адресу SQLskills.com/blogs/paul.

© 2008 Microsoft Corporation and CMP Media, LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.


Администрирование в Windows
Измерение ритма работы сервера
Стивен Чой (Steven Choy)
Краткий обзор.
  • Настройка монитора производительности
  • Рекомендации по измеряемым параметрам и частоте измерений
  • Обзор основных счетчиков и рекомендации по поиску информации

Cодержание
Представление результатов в удобочитаемой форме
Что и когда измерять
Узкое место, связанное с жестким диском
Узкое место, связанное с памятью
﻿Узкое место, связанное с процессором
Узкое место, связанное с сетью
Узкое место, связанное с процессами
Заключение
Представьте себе утро понедельника — вы только что прибыли в офис, и вас приветствует нетерпеливый пользователь, жалующийся на то, что его сервер работает слишком медленно. С чего же следует начинать, чтобы помочь ему? Монитор
производительности, удобное средство, встроенное в Windows®, поможет диагностировать проблему.
Чтобы получить доступ к монитору производительности, наберите «perfmon» в командной строке или выберите в меню «Администрирование» пункт «Производительность» или «Монитор надежности и производительности» (в Windows Vista® и Windows Server® 2008). Для добавления счетчиков производительности и объектов наблюдения просто щелкните знак «плюс» и сделайте выбор из множества возможных вариантов.
Итак, каким образом измеряется ритм работы сервера? Существует более 60 базовых объектов производительности, и каждый объект содержит множество счетчиков. В этой статье будут обсуждаться счетчики, определяющие основные показатели сервера. Будут описаны типичные интервалы между измерениями, которые наиболее часто используются инженерами службы технической поддержки Майкрософт (Microsoft® Service Support) для поиска и устранения неполадок, влияющих на производительность.
Безусловно, при поиске и устранении неполадок важнейшей точкой отсчета являются базовые показатели. Поскольку загрузка сервера определяется производственными требованиями и зачастую изменяется во времени в зависимости от производственного цикла, важно установить базовые показатели, определяемые обычной рабочей нагрузкой за указанный период времени. Это позволит наблюдать за изменениями и определять тенденции этих изменений.

Представление результатов в удобочитаемой форме
Прежде чем углубиться в анализ счетчиков, представляющих основные показатели серверов, я поделюсь двумя приемами, облегчающими измерение основных показателей серверов с помощью монитора производительности. Отмечу, что эти приемы не являются необходимыми в Windows Vista и Windows Server 2008, но, если вы запускаете монитор производительности на предыдуших версиях Windows, эти две настройки могут оказаться очень удобными.
Во-первых, можно избавиться от всех отвлекающих внимание избыточных измерений, ухудшающих графическое представление тенденции изменения показателей. В Windows Vista and Windows Server 2008 монитор производительности в состоянии отображать в графическом представлении до 1000 точек данных. В предыдущих версиях Windows предельное число точек данных составляло 100. Если точек более 100, монитор производительности формирует «сегменты» точек данных. Сегментирование представляется вертикальной линией, указывающей минимальное, среднее и максимальное число точек измерения, включаемых в сегмент.
Как можно судить по графику на рис. 1, трудно определить линию тренда при одновременном отображении такого большого количества данных. Из графика на рис. 2 видно, насколько легче быстро взглянуть на данные, если отключена посторонняя визуальная информация. Подробнее об отключении этих вертикальных линий рассказано в статье базы знаний на веб-странице по адресу support.microsoft.com/kb/283110.
Рис. 1 Показатели производительности, отображаемые с посторонними сегментами и в отсутствие запятых (щелкните изображение для его увеличения)
Рис. 2. Очищенное представление данных с использованием запятых в качестве разделителей (щелкните изображение для его увеличения)
Второй прием заключается в добавлении в числа запятых-разделителей, что облегчает чтение значений, отображенных в счетчиках. В Windows Vista и Windows Server 2008 разделители в виде запятых активированы по умолчанию. В предыдущих версиях Windows, однако, монитор производительности не допускает применение запятых по умолчанию.
Возможно, это покажется неважным, но взгляните на рис. 1, на котором отображаются счетчики производительности без запятых, а потом посмотрите на рис. 2, где счетчики отображены с запятыми. Я считаю, что в последнем случае считывать данные гораздо легче. Для получения некоторых простых рекомендаций по добавлению запятых-разделителей в счетчики производительности операционной системы Windows XP воспользуйтесь статьей базы знаний на веб-странице по адресу support.microsoft.com/kb/300884.

Что и когда измерять
Узкие места возникают в тех случаях, когда ресурс достигает своей предельной производительности, вызывая снижение производительности системы в целом. Обычно узкие места вызываются недостатком или неправильной настройкой ресурсов, неисправными компонентами и ненадлежащим запросом ресурсов со стороны программы.
Пять основных областей ресурсов вызывают возникновение узких мест и оказывают влияние на производительность сервера: физический диск, память, обработка, ЦП и сеть. Если какой-либо из этих ресурсов используется слишком часто, сервер или приложение может заметно замедлиться или даже перестать работать. Я подробно рассмотрю каждую из этих пяти областей, дам рекомендации относительно счетчиков, которые следует использовать, и сообщу предлагаемые пороговые значения для измерения ритма работы ваших серверов.
Поскольку интервал между измерениями оказывает существенное влияние на размер файла журнала и загрузку сервера, этот интервал следует задавать исходя из среднего времени, проходящего между возникновением неполадок, чтобы можно было установить базовые показатели до того, как неполадка вновь возникнет. Такой подход позволит определить все тенденции, приводящие к неполадке.
Пятнадцатиминутный интервал является хорошим окном для установления базовых показателей во время нормальной работы. 15-секундный интервал между измерениями рекомендуется установить, если среднее время между неполадками составляет приблизительно четыре часа. Если неполадка возникает через восемь или более часов, интервал между измерениями должен быть не менее пяти минут; в противном случае будет получен крайне объемный файл журнала, что усложняет анализ данных.

Узкое место, связанное с жестким диском
Поскольку дисковая система хранит и обрабатывает программы и данные на сервере, узкое место, сказывающееся на использовании дискового пространства и скорости, оказывает большое влияние на общую производительность сервера.
Обратите внимание на то, что, если объекты диска не были включены на вашем сервере, для их включения потребуется использовать средство командной строки Diskperf. Кроме этого, обратите внимание, что показатель «Процент активности диска» может превышать 100 процентов, и вследствие этого,я предпочитаю использовать «Процент времени бездействия», «Среднее время чтения с диска (сек)» и «Среднее время записи на диск (сек)», чтобы получать более точную картину занятости жесткого диска. Подробнее о показателе «Процент активности диска» рассказано в статье базы знаний на веб-странице по адресу support.microsoft.com/kb/310067.
Далее перечислены счетчики, на основании которых инженеры службы технической поддержки корпорации Майкрософт осуществляют контроль за работой дисков.
Логический диск\Процент свободного пространства Измеряет долю свободного места на выбранном логическом диске. Обратите внимание на то, что если падение его значения ниже 15 процентов, то возникает опасность нехватки свободного места для хранения важных файлов операционной системы. Одно из очевидных решений в этом случае состоит в добавлении места на диске.
Физический диск\Процент времени бездействия Измеряет долю интервала между измерениями, в течение которой диск бездействовал. Если значение счетчика опускается ниже 20 процентов, это означает, что дисковая система перегружена. Можно обдумать замену текущей дисковой системы на более быстродействующую.
Физический диск\Среднее время чтения с диска (сек) Измеряет среднее время в секундах, требуемое для чтения данных с диска. Если число превышает 25 миллисекунд (мс), это означает, что дисковая система испытывает задержку при чтении данных с диска. Для критически важных серверов, где размещаются SQL Server® и Exchange Server, приемлемый порог гораздо ниже, приблизительно 10 мс. Наиболее логичным решением в этом случае будет замена текущей дисковой системы на более быстродействующую.
Физический диск\Среднее время записи на диск (сек) Измеряет среднее время в секундах, требуемое для чтения данных с диска. Если число превышает 25 миллисекунд (мс), это означает, что дисковая система испытывает задержку при выполнении записи на диск. Для критически важных серверов, на которых размещаются SQL Server® и Exchange Server, приемлемый порог гораздо ниже, приблизительно 10 мс. Наиболее логичным решением в этом случае будет замена текущей дисковой системы на более быстродействующую.
Физический диск\Средняя длина очереди диска Указывает, сколько операций ввода/вывода ожидают, когда жесткий диск станет доступным. Если это значение превышает число дисков плюс два, значит, возможно, сам диск является узким местом.
Память\Байт кэш-памяти Указывает объем памяти, используемый для кэша файловой системы. Если это значение превышает 200 МБ, возможно, узкое место связано с диском.

Узкое место, связанное с памятью
Недостаток памяти вызывается обычно недостаточным объемом ОЗУ, утечкой памяти или параметром управления памятью, помещенным в файл boot.ini. Прежде чем обсуждать счетчики памяти, следует рассмотреть параметр /3GB.
При большом объеме памяти снижается активность дискового ввода-вывода, и, в свою очередь, повышается производительность приложений. Параметр /3GB был введен в Windows NT®, чтобы обеспечить способ предоставления большего объема памяти программам, работающим в пользовательском режиме.
В Windows используется виртуальное адресное пространство объемом 4 ГБ (независимо от того, каким объемом физической ОЗУ располагает система). По умолчанию 2 ГБ в нижних адресах зарезервированы для программ, работающих в пользовательском режиме, а 2 ГБ в верхних адресах зарезервированы для программ, работающих в режиме ядра. Параметр /3GB позволяет отдать 3 ГБ памяти процессам пользовательского режима. Это, конечно, происходит за счет памяти ядра, которому остается только 1 ГБ виртуального адресного пространства. Это приводит к проблемам, поскольку байты невыгружаемого пула памяти, байты выгружаемого пула памяти, свободные элементы таблицы страниц и куча рабочей среды все вмещаются в этот 1 ГБ адресного пространства. Следовательно, параметр /3GB следует использовать только после тщательного тестирования рабочей среды.
Это следует учесть, если возникает подозрение, что узкое место связано с памятью. Если параметр /3GB не является источником проблемы, эти счетчики можно использовать для диагностики возможного узкого места, связанного с памятью.
Память\Процент использования выделенной памяти Измеряет отношение числа байт выделенной виртуальной памяти к пределу выделенной виртуальной памяти, или, другими словами, долю используемой виртуальной памяти. Если это число превышает 80 процентов, это указывает на недостаточный объем памяти. Очевидным решением в этом случае является добавление памяти.
Память\Доступно МБ Измеряет в мегабайтах количество физической памяти, доступной выполняющимся процессам. Если это значение не превышает 5 процентов общего объема физического ОЗУ, значит, памяти недостаточно и может увеличиться активность страничного обмена. Для устранения этой проблемы следует просто увеличить объем памяти.
Память\Свободных элементов таблицы страниц Указывает число элементов таблицы страниц, не используемых системой в текущий момент. Если число не превышает 5000, возможно, имеется утечка памяти.
Память\Байт в невыгружаемом страничном пуле Измеряет в байтах объем невыгружаемого страничного пула памяти. Это область памяти системы, предназначенная для объектов, которые нельзя выгружать на диск и которые должны оставаться в выделенной им физической памяти. Если это значение превышает 175 МБ (или 100 МБ при использовании параметра /3GB), возможно, имеет место утечка памяти. Обычно в таком случае в журнал системных событий записывается событие с идентификатором 2019.
Память\Байт в выгружаемом страничном пуле Измеряет в байтах объем выгружаемого страничного пула памяти. Это область памяти системы, используемая объектами, для которых предусмотрена выгрузка на диск в том случае, если они не используются. Если это значение превышает 250 МБ (или 170 МБ при использовании параметра /3GB), возможно, имеется утечка памяти. Обычно в таком случае в журнал системных событий записывается событие с идентификатором 2020.
Память\Обмен страниц в сек Измеряется скорость считывания страниц с диска или записи на диск для разрешения запросов на страницу, отсутствующую в физической памяти. Если в результате избыточного страничного обмена это значение превышает 1000, возможно, имеет место утечка памяти.

﻿Узкое место, связанное с процессором
Перегрузка процессора может вызываться недостаточной мощностью процессора или неэкономичностью приложения. Необходимо дополнительно проверить, не является ли загруженность процессора операциями страничного обмена результатом недостатка физической памяти. При исследовании возможного узкого места, связанного с процессором инженеры службы технической поддержки корпорации Майкрософт пользуются следующими счетчиками.
Процессор\% загруженности процессора Измеряет долю времени, затрачиваемого процессором на обработку всех потоков команд, кроме простаивающего. Если процент загруженности превышает 85 процентов, процессор перегружен, и серверу, возможно, требуется более быстрый процессор.
Процессор\% работы в пользовательском режиме Измеряет долю времени, затрачиваемого процессором на работу в пользовательском режиме. Высокое значение этого параметра говорит о том, что сервер занят приложением. Одно из возможных решений заключается в оптимизации приложения, использующего ресурсы процессора.
Процессор\% времени прерываний Измеряет время, затрачиваемое процессором на прием и обслуживание аппаратных прерываний во время конкретных интервалов измерений. Этот счетчик указывает на возможность возникновения неполадки оборудования, если значение превышает 15 процентов.
Система\Длина очереди процессора Измеряет число потоков в очереди процессора. Если в течение длительного времени это значение более чем в два раза превышает число процессоров, то серверу недостаточно процессорной мощности.

Узкое место, связанное с сетью
Узкое место, связанное с сетью, безусловно, оказывает влияние на способность сервера отправлять и получать данные по сети. Возможно, проблема вызвана сетевой картой сервера или, возможно, сеть перегружена и ее необходимо сегментировать. Для диагностики потенциальных узких мест в сети можено использовать следующие счетчики.
Сетевой интерфейс\Всего байт/сек Измеряет скорость отправки и приема байт через каждый сетевой адаптер, включая символы оформления кадров. Сеть перегружена, если выясняется, что используется более 70 процентов интерфейса. В случае сетевой карты со скоростью обмена 100 Мбит/с потребляемый интерфейс составляет 8,7 МБ/с (100 Мбит/с = 100 000 кбит/с = 12,5 МБ/с* 70 процентов). В подобной ситуации, возможно, придется установить более быструю сетевую карту или провести сегментирование сети.
Сетевой интерфейс\Длина очереди вывода Определяет количество исходящих пакетов в очереди. Перегрузка сети наступает при превышении показателем значения 2. Разрешить эту проблему можно посредством установки более быстрой сетевой карты или сегментирования сети.

Узкое место, связанное с процессами
На производительность сервера существенное влияние оказывает наличие процесса с неправильным поведением или неоптимизированных процессов. Утечки потоков и дескрипторов приводят в конечном итоге к остановке сервера, а перегрузка процессора приводит к существенному замедлению работы сервера. Следующие счетчики совершенно необходимы при диагностике узких мест, связанных с процессами.
Процесс\Счетчик дескрипторов Определяет общее число дескрипторов, открытых процессом на текущий момент. Этот счетчик указывает на возможность утечки дескрипторов, если число превышает 10 000.
Процесс\Счетчик потоков Определяет общее число потоков процесса, активных в текущий момент. Возможно, имеет место утечка потоков, если это число превышает 500 в интервале между минимальным и максимальным числом потоков.
Процесс\Байт исключительного пользования Указывает объем памяти, выделенный процессом, который не может использоваться совместно с другими процессами. Возможно, имеет место утечка памяти, если это число превышает 250 в интервале между минимальным и максимальным числом потоков.

Заключение
Теперь вам известно, какие счетчики используют инженеры службы технической поддержки корпорации Майкрософт для диагностики различных узких мест. Безусловно, скорее всего, вы создадите свой собственный набор предпочтительных счетчиков, соответствующий вашим конкретным потребностям. Возможно, вы предпочтете сэкономить время и не станете вручную добавлять предпочитаемые счетчики при каждой проверке серверов. К счастью, существует режим монитора производительности, который позволяет сохранить все счетчики в шаблоне для последующего использования.
Возможно, вы еще задаетесь вопросом о том, как запускать монитор произоводительности — локально или в дистанционном режиме. И каким именно будет снижение производительности в случае локального запуска монитора производительности? Все это зависит от конкретной рабочей среды. Снижение производительности на сервере является практически пренебрежимым, если задавать по крайней мере пятиминутные интервалы.
Локальное выполнение монитора производительности может потребоваться в том случае, когда известно, что на сервере имеется проблема с производительностью, так как монитор производительности будет, возможно, не в состоянии собрать данные на удаленной машине, если он работает на сервере в условиях нехватки ресурсов. Его удаленное выполнение с центрального компьютера на самом деле наиболее подходит для случаев, когда необходимо наблюдать за удаленными серверами или получить данные их предварительного обследования.

Стивен Чой (Steven Choy) работает в должности старшего специалиста по эксплуатации в отделе эксплуатации корпорации Майкрософт. Он занимался поддержкой государственных агенств и коммерческих клиентов в работе над проектами по развертыванию настольных систем и миграции, управлению исправлениеми и групповым политикам. В настоящее время он занимается, главным образом, виртуализацией серверов и проблемами работоспособности серверов.


System Center
Windows PowerShell в System Center Operations Manager
Марко Шо (Marco Shaw)
Краткий обзор.
  • Интерпретатор команд OpsMgr.
  • Поставщик отслеживания OpsMgr.
  • Автоматизация основных задач администрирования.
  • Реальные примеры работы Windows PowerShell.

Cодержание
Интерпретатор команд Operations Manager.
Поставщик наблюдения OpsMgr.
Автоматизация основных задач.
Практические примеры.
Заключение.
Диспетчер System Center Operations Manager 2007 (OpsMgr) дал администраторам доступ к Windows PowerShell, новому языку сценариев, позволяющему автоматизировать многие задачи. Официальный выпуск диспетчера состоялся в ноябре 2006 года, и с тех пор его загрузили более двух миллионов раз.
В этой статье мы обсудим оболочку Windows PowerShell® и ее связь с диспетчером Operations Manager. Мы поговорим о том, какие задачи Windows PowerShell позволяет автоматизировать (и тем самым упростить их выполнение), а также укажем несколько веб-узлов, на которых можно найти готовые сценарии и пояснения. Мы собрали воедино советы и сообщения в блогах многих специалистов, работающих с Windows PowerShell.
Корпорация Майкрософт приступила к выпуску версий CTP Windows PowerShell 2.0, однако они еще не готовы к использованию в реальной производственной среде, они не тестировались на совместимость с OpsMgr.

Интерпретатор команд Operations Manager
Доступ к Windows PowerShell из OpsMgr осуществляется через интерпретатор команд, схожий со стандартной средой Windows PowerShell, за исключением того что он загружает файл консоли и сценарий, который выполняет инициализацию среды, вместе с командлетами, функциями и подключением по умолчанию OpsMgr.
Запустить интерпретатор команд можно при помощи значка в папке OpsMgr в меню «Пуск» или щелкнув правой кнопкой мыши имя компьютера в пользовательском интерфейсе консоли OpsMgr (см. рис. 1). После запуска сразу открывается каталог по пути наблюдения OpsMgr (его мы рассмотрим ниже).
Рис. 1 Запуск интерпретатора команд из пользовательского интерфейса OpsMgr (Щелкните изображение, чтобы его увеличить.)
Windows PowerShell стыкуется с диспетчером Ops Mgr через пакет SDK для OpsMgr. К радости администраторов, для большинства основных операций, которые удобно автоматизировать и выполнять из командной строки, уже имеются готовые командлеты. Если для какой-то задачи командлет не создан, можно использовать Windows Power Shell совместно с пакетом SDK.
Команды, с которыми можно работать в командной оболочке Operations Manager, содержатся в отдельной оснастке — в библиотеке DLL, которая загружается оболочкой Windows PowerShell и включает в себя командлеты для администрирования через OpsMgr. В эту же оснастку входит поставщик Windows PowerShell OperationsManager Monitoring. Это средство — его еще называют поставщиком наблюдения — позволяет просматривать подключения, группы и объекты наблюдения примерно так же, как составляющие файловой системы.
Список всех командлетов OpsMgr можно получить при помощи командлета Get-OperationsManager Command (см. рис. 2). (В первой версии это была функция, не поддерживавшая автозавершение при помощи клавиши табуляции; в пакете обновления 1 (SP1) вместо нее был реализован командлет.) В исходную версию диспетчера Operations Manager входили 74 командлета; в OpsMgr с пакетом обновления 1 (SP1) их 87.
Рис. 2 Получение списка командлетов OpsMgr (Щелкните изображение, чтобы увеличить его.)

Поставщик наблюдения OpsMgr
При помощи командлета Set-Location или его псевдонима cd можно переходить по группам и компьютерам. Базовая схема для диска Monitoring по умолчанию выглядит примерно так:
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
Отсюда уже можно переходить к конкретным объектам. Здесь мы работаем с простейшей средой, в которой есть лишь один сервер управления. Первый сервер управления в группе управления называется корневым.
При запуске интерпретатор команд создает диск с именем Monitoring, сопоставляет его корневому каталогу поставщика OperationsManager Monitoring и устанавливает текущее положение или путь к корневому каталогу диска Monitoring (путь к нему). Затем интерпретатор команд пытается найти в реестре имя корневого сервера управления, используемого по умолчанию. Если удается установить подключение к нему, то текущему положению (пути) назначается имя этого подключения (корневого сервера управления), как показано на рис. 3.
Рис. 3 В качестве местоположения интерпретатора команд устанавливается имя корневого сервера управления (Щелкните изображение, чтобы его увеличить.)

Автоматизация основных задач
Рассмотрим, как Windows PowerShell помогает выполнять основные задачи администрирования.
Режим контрольного обслуживания Вне зависимости от того, какую задачу вы выполняете, вы обычно указываете дату и время проведения операций. Командлет Get-Date значительно упрощает это действие. На рис. 4 показано несколько примеров.
Рис. 4 Использование командлета Get-Date (Щелкните изображение, чтобы увеличить его.)
Можно видеть, что мы создали переменную $date, в которой содержится объект, представляющий текущее время. Затем мы использовали ряд документированных методов, поддерживаемых этим объектом, для демонстрации того, как просто можно получить дату и время, отступающее от текущего на пять минут или на пять часов. Чтобы получить значения, относящиеся к прошлому, нужно использовать не (5), а (-5).
Если требуется блокировать все предупреждения, приходящие с компьютера, можно включить режим обслуживания. Диспетчер OpsMgr 2007 позволяет перевести в режим обслуживания отдельную службу Windows®, даже отдельную базу данных, а не только весь компьютер или целую группу. Существует три командлета, непосредственно связанных с режимом обслуживания: Get-MaintenanceWindow, New-MaintenanceWindow и Set-MaintenanceWindow.
Чтобы перевести компьютер в режим обслуживания из интерпретатора команд, найдите нужный компьютер или объект наблюдения через поставщик наблюдения и вызовите командлет New-MaintenanceWindow, как показано на рис. 5. В нашем примере компьютер Denver.contoso.com переводится в режим обслуживания. Мы определили окно обслуживания таким образом, чтобы работы начинались в текущий момент времени, а заканчивались через час. Обратите внимание на то, что при таком переводе компьютера в режим обслуживания предупреждения не блокируются, поскольку экземпляры HealthService и HealthService Watcher для данного объекта по-прежнему работают.
Рис. 5 Использование командлета New-MaintenanceWindow (Щелкните изображение, чтобы его увеличить.)
Борис Янушпольский, руководитель программы в группе разработчиков Microsoft Ops Mgr, предоставил несколько весьма полезных фрагментов кода на языке Windows PowerShell, которые можно использовать для перевода всех объектов, соответствующих компьютерам, в режим обслуживания. Кроме того, он объясняет, как их использовать после создания сценария. Дополнительную информацию можно найти в его блоге по адресу blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.
Бывают ситуации, когда нужно определить, нет переведены ли в режим обслуживания лишние объекты. Перебор же всех объектов может оказаться задачей трудоемкой. К счастью, и тут Борис Янушпольский приходит на помощь: он разработал сценарий Windows PowerShell, задействующий пакет SDK для OpsMgr. Можно загрузить код непосредственно из его блога (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) и вставить его в окно интерпретатора команд. На выходе вы получите список всех объектов, переведенных в режим обслуживания.
Иногда требуется завершить режим обслуживания объекта до наструпления ранее указанного срока окончания обслуживания. Человек, знакомый с Windows PowerShell, будет искать какой-нибудь командлет с глаголом stop или remove в названии, но на самом деле используется командлет Set-MaintenanceWindow (см. рис. 6).
Рис. 6 Использование командлета Set-MaintenanceWindow для изменения времени окончания обслуживания (Щелкните изображение, чтобы увеличить его.)
Управление агентами Администраторам нередко приходится иметь дело с агентами. В текущей версии диспетчера есть одна функция и шесть командлетов, помогающих выполнять задачи, связанные с агентами. Их список можно получить при помощи следующей команды:
Get-Command *-agent*
В пакете обновления 1 (SP1) Install-AgentBy Name представляет собой не функцию, а командлет. Рекомендуется использовать командлет Install-AgentByName, поскольку в таком случае улучшается поддержка и повышается согласованность операций.
Во встроенной справке интерпретатора команд есть несколько неплохих примеров использования командлетов Install-Agent и Uninstall-Agent. Роджер Спрэг (Roger Sprague), старший инженер-разработчик в группе Microsoft Ops Mgr, в своем блоге рассказал об альтернативном методе: он приведен на рис. 7 (исходное сообщение расположено на странице blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).
Этот сценарий отлично работает в версии RTM диспетчера OpsMgr (запускать его нужно из корневого каталога поставщика наблюдения, в наших примерах это каталог monitoring:\oxford.contoso.com), а вот в OpsMgr с пакетом обновления 1 (SP1) он дает сбой. В обновленной версии диспетчера нужно первую команду в коде, приведенном на рис. 7, изменить следующим образом:
$managementServer = Get-RootManagementServer
Рис. 7. Установка агента
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
Итак, агент установлен в удаленной системе, за которой мы будем наблюдать. Осталось одно: сервер управления должен принять новый агент, прежде чем за ним можно будет наблюдать. Если никаких действий не предпринимать, сервер управления автоматически примет новый агент. Однако процесс принятия можно отслеживать при помощи командлета Get-AgentPendingAction. Вот однострочник, который позволит проверить ход принятия агента:
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
Если его выходные данные направить в командлет Reject-AgentPending Action, а не в командлет Approve-AgentPending Action, можно блокировать принятие данного агента сервером OpsMgr. Так можно поступить, если агент еще не принят. В противном случае нужно использовать командлет Uninstall-Agent.
Как уже упоминалось выше, при помощи командлета Install- AgentByName можно напрямую из командной строки указать, на каком компьютере должен быть установлен агент.
Работа с пакетами управления существуют четыре командлета, помогающие выполнять различные задачи при работе с пакетами управления. Их список можно получить следующим образом:
Get-Command –noun ManagementPack
При помощи вот такой несложной команды составляется список установленных пакетов управления с указанием версий:
Get-ManagementPack | Format-Table –autosize
Рассмотрим процедуру установки двух распространенных пакетов управления через интерпретатор команд. Использовать будем два установщика:
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
Поскольку цель наша в том, чтобы показать, как интерпретатор команд способен упростить выполнение рутинных задач, мы будем использовать такую процедуру установки, в которой меньше всего команд (см. рис. 8). Можно было бы изменить процедуру установки, передав установщику (файлу MSI) параметр quiet, но мы предпочли указать место распаковки файлов вручную.
Рис. 8 Установка пакетов управления (Щелкните изображение, чтобы его увеличить.)
Теперь необходимо установить общие библиотеки. Сделать это можно следующим образом:
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Теперь установим остальные необходимые пакеты управления:
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Как видно из рис. 9, во встроенной справке интерпретатора команд имеется прекрасный пример использования командлета Export-ManagementPack для экспорта незапечатанных пакетов управления. Если нужно экспортировать все пакеты, измените следующую строку:
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
Рис. 9 Экспорт пакета управления (Щелкните изображение, чтобы его увеличить.)
Работа с ролями пользователей Командлет Get-UserRole выполняет ряд функций, связанных с администрированием пользователей, однако, как ни странно, не имеет парного командлета Set, поэтому обычно он не используется для изменения и обновления ролей (согласно документации к пакету Windows PowerShell SDK). На рис. 10 показано, как мы получаем список имеющихся ролей пользователей. Затем мы добавляем пользователя в группу операторов только для чтения (см. рис. 11).
Рис. 10 Получение списка ролей пользователей (Щелкните изображение, чтобы его увеличить.)
Рис. 11 Добавление пользователя (Щелкните изображение, чтобы его увеличить.)
Включение служб ACSСлужбы ACS — это дополнительная функция, появившаяся в Operations Manager 2007. Это средство централизованной обработки данных аудита безопасности. По умолчанию службы ACS отключены. Обычно их можно настроить на более позднем этапе развертывания диспетчера OpsMgr.
Бывают ситуации, когда требуется включить большое количество агентов для служб ACS, и тут на помощь приходит Windows PowerShell, позволяющий автоматизировать установку. На этапе бета-тестирования диспетчера OpsMgr специалисты корпорации Майкрософт добавили сценарий для включения служб ACS для всех агентов. Нил Браун (Neale Browne), ведущий блог на узле SystemCenterForum.org, расширил его, добавив поддержку дополнительных параметров.
На веб-узле SystemCenterForum.org (это узел сообщества, в котором обсуждаются решения Microsoft® System Center) имеются два разных сценария Windows PowerShell для автоматизации установки служб ACS. Для настройки всех агентов в отдельно взятой группе используйте файл systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Для настройки всех наблюдаемых агентов нужен файл systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.
Включение прокси для агентов В среде OpsMgr могут существовать отслеживаемые устройства без агентов. Таким устройствам нужно обязательно назначить сервер управления или устройство, управляемое агентом, которое будет обеспечивать удаленное наблюдение. Подробные указания по использованию сценариев Windows PowerShell для одновременной настройки большого числа агентов приведены на веб-узле systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Обновленная версия сценария доступна по ссылке systemcenterforum.org/wp-content/uploads/Set AgentProxyBulk_FQDN.zip.
Существуют и другие ситуации, в которых для того или иного пакета управления требуется, чтобы агент выступал в роли прокси. Подробные сведения приведены в документации к пакету управления.

Практические примеры
Ниже приведено несколько примеров, демонстрирующих возможности Windows PowerShell в сфере автоматизации.
Обработка предупреждений Вам доводилось сталкиваться с необходимостью устранить сразу несколько предупреждений на отдельно взятом компьютере? Возможно, произошел какой-то сбой в приложении, и предупреждения не были обработаны вовремя. Следующий однострочник позволяет обработать все предупреждения с нулевым состоянием разрешения:
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
Следующий код выполняет то же самое, но в масштабных средах с большим количеством необработанных предупреждений он работает гораздо быстрее:
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
Причина такой разницы в производительности заключается в том, что при использовании параметра критерия передаваемое значение предоставляется непосредственно базе данных SQL Server®, и возвращаются только нужные данные. Тем самым сокращается количество объектов, которые нужно передать в консоль Windows PowerShell.
Итак, у нас есть простой способ устранить все необработанные предупреждения на отдельно взятом компьютере. Если необходимо, можно запланировать автоматический запуск этого кода.
Следующая несложная команда позволяет просмотреть все предупреждения за определенный день:
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
Дата в ней меняется без труда. Выходные данные этой команды можно передать в командлет Resolve-Alert.
Тестовые предупреждения Бывают ситуации, в которых требуется способ наблюдения за определенными событиями в средстве просмотра событий Windows и проверки на них. Следующие две строки кода создают запись в журнале событий:
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
По умолчанию, правда, запись выполняется в журнал событий Operations Manager, который далеко не всегда используется для поиска каких-то определенных событий. К счастью, Стефан Стрэнджер (Stefan Stranger), один из главных специалистов по эксплуатации в корпорации Майкрософт, написал сценарий, позволяющий создавать события в средстве просмотра событий Windows. Этот сценарий дает большую свободу действий, нежели тот код, который выполняет запись только в конкретный журнал. Сценарий можно найти на странице go.microsoft.com/fwlink/?LinkId=120308. (Стефан упаковал его в файл CAB. Вам нужно будет загрузить файл и щелкнуть его правой кнопкой мыши, чтобы извлечь сценарий.)
Единственное, что нужно пояснить: значение, которое указывается для источника событий, определяет, в какой журнал будут вноситься записи. Наверное, самый простой способ гарантировать правильный выбор журнала — открыть средство просмотра событий Windows и найти источник последней записи.
Установка владельца Иногда бывает удобно установить владельца предупреждения автоматически. Вот простой способ сделать это из интерпретатора команд:
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
В первой строке этого кода мы получаем идентификатор конкретного объекта оповещения и передаем его в переменную $alert. Во второй строке эта переменная используется для установки владельца. После всего этого обновление применяется к базе данных OpsMgr. Если при помощи следующей команды проверить владельца, мы увидим, что он изменился:
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
Чтобы настроить владельца для нескольких предупреждений одновременно, нужно использовать следующий код:
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
Восстановление состояния наблюдения Наверное, вам приходилось сталкиваться с агентами в «ненаблюдаемом» состоянии. В таком случае нужно быстро восстановить режим наблюдения для всех агентов, а потом уж выяснять, что произошло. Сеценарий, приведенный на рис. 12, при запуске непосредственно из командной строки восстанавливает режим наблюдения для всех агентов, затронутых неполадкой.
Рис. 12. Восстановление хранилища службы работоспособности
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
Взгляните на код, показанный на рис. 12. После объявления переменной мы получаем список всех агентов для данного корневого сервера управления, а потом отбираем те, которые работают некорректно. После этого мы асинхронно вызываем задачу, восстанавливающую хранилище службы работоспособности для всех отобранных агентов.
Привязка предупреждений к пакетам управления На рис. 13 показано, как получить список всех новых предупреждений с указанием связанных с ними пакетов управления.
В этом коде использовано несколько нестандартных приемов для проверки возможности разрешения всех имен пакетов управления. Набор используемых командлетов будет различаться в зависимости от источника предупреждения (правило или монитор). (Обратите внимание на то, что в коде на рис. 13 использовано небольшое обходное решение для командлета Get-Monitor. В диспетчере OpsMgr с пакетом обновления 1 (SP1) этот командлет поддерживает новый параметр идентификатора, что несколько упрощает код.)
Рис. 13. Поиск пакета управления
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
Упрощение отчетов При обновлении среды бывает полезным контролировать версии установленных агентов. Элементарный сценарий, приведенный ниже, выводит на печать соответствующий отчет.
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
На рис. 14 показаны выходные данные этого сценария. Он представляет собой расширенную версию примеров, приведенных на странице systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Рис. 14 Выходные данные с указанием версий агентов (Щелкните изображение, чтобы увеличить его.)
Планирование задач Некоторые сценарии Windows PowerShell нужно запускать регулярно. Допустим, мы используем клиентский компьютер для подключения к серверу OpsMgr и управления им. На этом компьютере установлены средства администрирования OpsMgr. Требуется ежедневно составлять отчет о версиях агентов и сохранять его в файл, имя которого должно представлять собой текущую дату. Для запуска сценария с локального компьютера можно использовать встроенный планировщик задач Windows.
В нем просто создается новая задача, в качестве программы указывается powershell.exe (обычно она располагается в каталоге C:\Windows\System32\WindowsPowerShell\v1.0). Созданная задача настраивается и запускает примерно следующим образом:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Выясняется, что в исходный код Windows PowerShell приходится вносить довольно много изменений (см. рис. 15). Мы добавили оснастку OpsMgr PowerShell, создали диск Monitor, соответствующий поставщику Operations ManagerMonitoring, создали подключение к корневому серверу управления. Кроме этого, мы загрузили пользовательский сценарий Windows Power Shell (Microsoft.Enterprise Management.OperationsManager.ClientShell.Startup.ps1) для загрузки функций, относящихся к диспетчеру OpsMgr.
Рис. 15. Планирование запуска сценария для определения версий агентов
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
И это еще не все. Вы, возможно, обратили внимание на то, что при каждом запуске сценария появляется черное окно консоли, если кто-то входит в систему до окончания работы сценария. Решение этого вопроса описано Доном Джонсом (Don Jones) и Джеффри Хиксом (Jeffery Hicks) из Sapien в блоге blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.
Грубо говоря, нужно обернуть сценарий в VBScript. Код будет выглядеть примерно так, как показано на рис. 16. Он используется вместо запуска из запланированной задачи следующего кода:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Рис. 16. Сокрытие всплывающих окон
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
В задаче будет использоваться программа wscript.exe, и вызов ее будет выглядеть примерно следующим образом:
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
В конечном итоге, отчеты будут создаваться автоматически и незаметно для пользователя.

Заключение
Эта статья — лишь краткий обзор функций автоматизации, предоставляемых диспетчером OpsMgr 2007, и возможностей Windows PowerShell в сфере администрирования OpsMgr.
Нам хотелось бы поблагодарить всех тех, кого мы упомянули в статье, а таже Пита Зергера (Pete Zerger), основателя SystemCenterForum.org, обладателя звания MVP по MOM, за неоценимую помощь.

Марко Шо (Marco Shaw) работает аналитиком информационных систем в канадской телекоммуникационной компании. Он трудится в сфере ИТ более 10 лет. Не так давно Марко получил звание MVP по Windows PowerShell. Кроме того, Марко является помощником директора сообщества PowerShell Community (powershellcommunity.org). Его блог находится по адресу marcoshaw.blogspot.com.


Internet Information Services
Масштабирование приложений ASP.NET: извлеченные уроки
Ричард Кэмпбелл (Richard Campbell)
Краткий обзор.
  • Важность сотрудничества разработчиков со специалистами по ИТ
  • Знакомство с основными стратегиями масштабирования
  • Обмен знаниями между группами
  • Согласование основного набора знаний

Cодержание
Основы масштабирования
Встреча разумов
Что специалистам по сетям нужно узнать от разработчиков
Что разработчикам нужно узнать от специалистов по сетям
Возвращаясь к масштабированию
Совместная борьба с огнем
Каждое успешно масштабирующееся приложение ASP.NET, с которым я когда-либо работал в качестве консультанта, было результатом совместных усилий разработчиков (создавших его) и сетевых администраторов (реально работающих на нем). Увы, в начале жизненного цикла приложения
не всегда ясно, что это сотрудничество является ключевым. Как следствие, мне почти не предоставлялось возможности вмешаться в начале жизненного цикла приложения – лишь в печальном конце, там где появляются проблемы.
Простая истина состоит в том, что ни одно приложение не масштабируется эффективно с первого раза – сделать все правильно с ходу невозможно. Чтобы успешно масштабировать приложение, необходимо понимать, как оно было построено, а также как работает его среда эксплуатации. Другими словами, необходима информация как от разработчиков, так и от специалистов по сетям. Без этих общих знаний успех невозможен.

Основы масштабирования
Перед погружением в тему, давайте определим, что требуется для реального масштабирования приложения ASP.NET. Обычно применяются две фундаментальные стратегии, специализация и распределение, и в большинстве крупных масштабируемых приложений ASP.NET применяются обе. Более того, все известные приемы, помогающие в масштабировании приложения ASP.NET, сводятся к тому или другому.
Специализация включает выделение элементов приложения, чтобы масштабировать их независимо. Например, можно создать специальные серверы изображений вместо использования тех же серверов, что визуализируют страницы ASP.NET. Оптимальная настройка сервера изображений существенно отличается от таковой для сервера ASP.NET. Кроме того, отделение запросов изображений от остальной части приложения открывает возможность использования ресурсов от сторонних производителей для предоставления изображений. Тот же подход применим к другим файлам ресурсов.
Распределение, с другой стороны, подразумевает симметричное растягивание приложения на несколько серверов, обычно именуемых веб-фермой. Приложения ASP.NET в особенности подходят для распределения, поскольку каждый отдельный запрос страницы относительно мал и взаимодействия определенного пользователя во многом зависят от других пользователей. Распределение на деле является воплощением философии «масштабирования в стороны», при которой несколько серверов средней производительности работают вместе, обслуживая пользователей, а не подхода «масштабирования вверх», при котором все делает один большой сервер.
Сочетание специализации и распределения повышает эффективность – распределять можно только элементы приложения, нуждающиеся в дополнительной производительности. Например, если созданы специальные серверы изображений, но предоставление изображений все еще неадекватно, можно добавить серверы лишь для изображений, а не для всего приложения. Важно помнить про эти стратегии, когда углубляешься в улучшение производительности и масштабируемости своего приложения ASP.NET.

Встреча разумов
В жизненном цикле каждого приложения ASP.NET есть момент, когда разработчики, и специалисты по сети/ИТ, вероятно, встретятся. Если повезет, это произойдет до развертывания приложения, но порой это происходит только после возникновения кризиса – например, когда приложение отлично работает в тестовой среде, затем поставляется пользователям и еле ползет у них. (В таких случаях и вызывают консультантов вроде меня.)
Когда разработчики и специалисты по сетям встречаются, основной целью является обмен информации. Разработчик обладают ключевыми знаниями о приложении, а обслуживающий персонал сети – о среде, где оно эксплуатируется. Обеим группам нужно усвоить данные друг друга, и чем раньше в жизненном цикле приложения это произойдет, тем лучше.
Эта встреча не должна впервые состояться в момент кризиса. Без общего взаимопонимания между двумя группами понять, почему приложение не работает так, как требуется, очень сложно. Вдобавок, слишком просто, выгораживая себя, решить, что проблема является исключительно проблемой другой группы. А это просто не может быть верным – для решения любой проблемы существенной сложности неизбежно требуются усилия обеих групп.
Но и в хорошие времена такая встреча может быть непростой. Те, которые устраивал я, обычно начинались с сетевиками на одной стороне стола, а разработчиками на другой. Следует дуэль взглядов. Чтобы начать разговор, я обрисовываю цель встречи, а именно обмен знаниями. Не имеет значения, с кого начинать. Я начну с того, что специалистам по сетям нужно узнать от разработчиков.

Что специалистам по сетям нужно узнать от разработчиков
Каждое приложение ASP.NET имеет свои тонкости, существуют ключевые элементы, применимые во всех случаях. Одним из них является файл web.config (см. рис. 1). Web.config – это точка пересечения между разработкой и работой с сетью. Порой он настраивается разработчиками, порой специалистами по сетям. Так или иначе, содержание web.config накладывает ограничения на состав оборудования и настройку сети и прямо влияет на работу приложения. Подробное изучение всех мелких аспектов файла web.config может легко занять целую книгу; здесь же следует просто понять, что обеим группам необходимо изучить файл web.config и согласиться насчет того, что значит представляемая им настройка, а также того, какое влияние различные параметры будут иметь на приложение и на среду.
Рис. 1 Базовый файл web.config, показывающий некоторые параметры приложения и индивидуализированную настройку ошибок (щелкните изображение, чтобы увеличить его)
Например, раздел <authorization> файла web.config указывает, как будет проводиться проверка пользователей в приложении, определяя тем самым зависимость. Если приложение использует проверку подлинности Windows®, оно может зависеть от Active Directory®. Если оно использует проверку подлинности на основе форм, зависимость будет от хранилища данных учетных записей пользователей. Это определенно стоит беседы.
Стоит отметить раздел <customErrors>, поскольку он определяет, как сбой видят пользователи. Это несложный параметр, но его стоит обсудить просто ради того, чтобы понять, какими будут страницы ошибок. На раннем этапе цикла сотрудничества специально настроенные страницы ошибок, вероятно, отсутствуют – об этом тоже стоит побеседовать.
Раздел <appSettings> файла web.config может быть особенно важен. В нем разработчики обычно припрятывают глобальные значения, такие как строки подключения для баз данных. Это отличный источник зависимостей и ключевая часть планирования отказоустойчивости, смягчения проблем и т.д. Но поскольку раздел <appSettings> полностью индивидуален, он может содержать что угодно, а его содержимое – требовать долгих объяснения для понимания. В этом разделе часто оставляются потерянные объекты – значения которые на деле не используются нигде в приложении.
Даже если разработчики не используют <appSettings>, сетевики/эксплуатационщики могут желать, чтобы они его использовали, – сведение всех строк подключения к базам данных сюда является эффективным способом создания простой стратегии отказоустойчивости. Если сервер базы данных ломается, можно вставить строку замены, указывающую на другой сервер базы данных. Ухватившись за эту возможность на раннем этапе разработки, можно повысить надежность приложения и простоту его обслуживания.
Наконец, стоит обратить внимание, что с точки зрения масштабирования абсолютным значением ключа в файле web.config является тег <sessionState>, определяющий, где будут храниться данные сеанса для приложения. По умолчанию, данные сеанса хранятся "InProc", или в пространстве процессов приложения ASP.NET. Если данные сеанса настраиваются с учетом этого, то вся балансировка нагрузок должна быть «прилипчивой» – определенный пользователь всегда должен возвращаться к тому же серверу, где находятся данные сеанса. Это предмет для большого разговора между разработчиками и сетевиками, поскольку он прямо влияет на способы масштабирования и отказоустойчивости. Ранее обсуждение этого может сэкономить массу нервов, ушедших бы на устранение неполадок приложения.
После того, как разговор доходит до состояния сеанса, оттуда легко перейти к требованиям балансировки нагрузки приложения в целом. Некоторым средам необходимо специальное оборудование для балансировки нагрузки с конкретными функциями – но если приложение не поддерживает эти функции, они немногого стоят. Я сталкивался с ситуациями, когда аппаратная балансировка нагрузки использовалась с приложением ASP.NET, хранившим данные сеанса в процессе. В результате порой безо всякого объяснения терялись сеансы. Это выглядело как ошибка в приложении, но на деле было следствием неправильной настойки.
Специалистам по сети нужно четко знать от разработчиков, какие именно схемы балансировки нагрузки будут работать для приложения. Это вполне двустороннее обсуждение того, какие схемы балансировки нагрузки доступны и что приложение может выдержать. Серьезным преимуществом проведения такого обсуждения на раннем этапе разработки приложения заключается в том, что можно заранее запланировать переход на беспроцессную, не имеющую привязок, схему балансировки нагрузки.
К тому времени, как приложение ASP.NET готово к развертыванию (или находится в процессе первоначального развертывания), разработчики будут иметь хорошее представление о том, какие области приложения работают быстро, а какие медленно. Что важнее всего, они будут чувствовать, где в системе находятся «узкие места» и потенциальные опасные точки. Если группа работы с сетью/эксплуатации знает об этих узких местах, она может подготовиться к проблемам заранее и, возможно, даже избежать их.
Например, я однажды работал с приложением, производившим обширный процесс загрузки данных каждую ночь во время простоя приложения. Разработчики создали механизм загрузки данных, протестировали его и поняли, как он работает. Они знали, что он создавал большую нагрузку для базы данных, но он был эффективным и хорошим путем решения проблемы.
Но они не удосужились сообщить работающей с сетью группе, что такой процесс существует или что по расписанию он происходит в час ночи – точно во время, на которое последняя запланировала резервное копирование базы. База оставалась в рабочем состоянии, но работала гораздо медленнее во время процесса резервного копирования, поскольку все транзакции, отправляемые базе данных, удерживались в журнале транзакций.
Конфликт был определен, лишь когда сочетание одновременной загрузки данных и резервного копирования вызвало исчерпание журналом транзакций свободного места на диске. Перенос загрузки данных на три часа ночи полностью решил проблему – но лишь после нескольких дней кризиса.
Ранняя беседа об элементах рабочей нагрузки такого рода в приложении может спасти от многих неприятностей впоследствии.

Что разработчикам по сетям нужно узнать от специалистов по сетям
Я люблю начинать часть встречи, где народ, работающий с сетью, объясняет свой мирок разработчикам, с представления схемы сети. Слишком часто разработчики видят сеть, как показано на рис. 2 – то есть, не как сеть, а просто как веб-серверы, обозреватели и Интернет.
Рис. 2. Простое представление сети в глазах разработчика (щелкните изображение, чтобы увеличить его)
Реальность, само собой, куда сложнее. Схема, подобная рис. 3, ближе к истине, хоть и является упрощенной. При взгляде на рис. 3 немедленно возникают дополнительные вопросы, вроде: «Как пользователи виртуальной частной сети (Virtual Private Network – VPN) работают с этим приложением» или: «В чем разница проверки подлинности для внутреннего пользователя и общего пользователя» и так далее.
Рис. 3. Реальная картина сети, которую нужно понять разработчикам (щелкните изображение, чтобы увеличить его)
Очевидно, что простого предоставления схемы сети недостаточно. Также важно объяснить сеть во всех подробностях, поскольку по простому взгляду на схему нельзя сказать, какие элементы повлияют на приложение. Необходимо рассказать о реальном процессе подключения общего пользователя, пользователя VPN и внутреннего пользователя. А рассказ о различных существующих, особенно в более сложных сетевых архитектурах в стиле DMZ, правилах брандмауэра естественным образом высветит потенциальные проблемы приложения.
Очевидно, что лучше всего провести все эти беседы до развертывания приложения и даже до начала разработки – но, что бы не произошло, рано или поздно они состоятся, и знакомство со всей схемой сети всех присутствующих за столом абсолютно необходимо для них.
Работа с сетью также является ареной моделей отказоустойчивости и избыточности, но без некоторой поддержки в программе или, как минимум, учета поведения эти модели редко работают как планируется. Необходимо подробно обсудить, на что похожи различные случаи сбоев. Если в базе данных действует кластеризация, это повлияет на код, связанный с доступом к базе данных. Например, могут ли запросы выполняться повторно после переключения сервера? Если доступен избыточный веб-узел, как на него будут реплицироваться данные? Как происходит переключение с одного узла на другой?
Опять же, проведение обсуждения пораньше помогает, но лучше поздно, чем никогда, – всем, кто связан с приложением, нужно понимать, как работают такие вещи. Нет ничего более раздражающего, чем отказоустойчивое решение, которое не работает, когда это нужно.
Наконец, следует поделиться еще одним ключевым сетевым ресурсом – рабочими журналами. Я всегда рекомендую делать рабочие журналы доступными группе разработки. Обычная реакция от людей, работающих с сетью на такой запрос: «Попросите их у меня, и я отошлю их вам». Я не думаю, что этого достаточно – гораздо эффективнее дать разработчикам возможность извлекать журналы самим, как правило, с веб-узла резервного копирования.
Рабочие журналы важны в ходе кризиса. Часто они являются лучшим (и единственным) источником реальных, опытных данных о том, что случилось. Но они не менее ценны и в более нормальных обстоятельствах. Когда разработчики имеют постоянный доступ к рабочим журналам, они могут проверять в них, как ведет себя новая функция. А это отличный способ обнаружить, что функция не делает того, что от нее ожидается, и исправить проблему, пока она не переросла в кризис. Когда у всех есть доступ к журналам, можно быстрее реагировать на проблемы и скорее исправлять их.

Возвращаясь к масштабированию
Смысл встречи между разработчиками и сетевиками заключается в понимании всего масштаба проблем, окружающих масштабирование приложения ASP.NET. Реальная среда, в которой эксплуатируется приложение, прямо влияет на то, как будет работать выполняемый приложением код. Все имеющиеся стратегии, связанные с масштабированием, влияют на его поведение в среде. Применение стратегии специализации, такой как выделение связанных с SSL частей приложения, может потребовать изменений в сетевой среде и, возможно, в самих серверах.
Даже изменение, которое, на первый взгляд, затрагивает лишь код, скажем использование кэширования, может затронуть среду. Это вызвано тем, что при добавлении кэширования данных к приложению ASP.NET уменьшается число вызовов к базам данных, в обмен на увеличение использования памяти. В результате может возрасти нужное число серверов ASP.NET или число повторных использований рабочих потоков на серверах, что вызовет события на стороне наблюдения за сетью.
Масштабирование приложения ASP.NET влияет как на персонал, занимающийся разработкой, так и работающий с сетью – так что имеет смысл задействовать в принятии решений обе группы. Часто сотрудничество может дать оригинальные решения, которые не обнаружились бы при работе по отдельности. Например, люди, работающие с сетью, могут знать о существующих аппаратных решениях внутри компании, которые могут помочь разработчикам обеспечить выполнение требований к производительности и масштабированию. Обсуждение различных деталей приложения и среды откроет эти возможности.

Совместная борьба с огнем
Материалы по масштабированию приложений ASP.NET

  • Разработка высокропроизводительных приложений ASP.NET
  • Указания: масштабирование приложений .NET
  • Указания: Настройка и масштабирование приложений, построенных на основе.NET Framework
  • Применение масштабируемой архитектуры
  • Достижение наибольшей производительности IIS
  • Стратегии масштабирования для приложений ASP.NET
Кризис в масштабировании не является автоматически плохой вещью – на деле это обычно хорошая вещь, поскольку он создается избытком пользователей, желающих использовать приложение, что доказывает ценность приложения! Однако теперь необходимо заставить приложение работать.
Порой кризисы масштабирования вызываются каким-то другим событием – возможно, компания проводит рекламную акцию, или о ней заговорили в блогах, или социальная сеть одновременно направила на ее веб-узел огромное количество людей. И внезапно сотрудникам приходится тушить пожар кризиса, чтобы работа приложения продолжилась. Как можно догадаться, сценарий такого рода лучше проработать прежде, чем он произойдет реально. А демонстрация того, как сотрудничество может помочь организации пережить подобный кризис, является отличным способом завершить встречу между разработчиками и сетевиками.
Первый вопрос по борьбе с кризисом такой: «Как мы обнаруживаем, что веб-узел задыхается под нагрузкой?» Слишком часто ответ бывает: «Мы получаем звонок от руководителя технологического отдела». Когда первым признаком проблем с веб-узлом является звонок от кого-то извне, это проблема. Приличное измерение должно сообщить о проблеме прежде, чем зазвонит телефон. Оно не остановит сам звонок, но, по крайней мере, даст время подготовиться к ответу. Ответы типа "В самом деле?" не улучшают карьерных перспектив.
Следующий вопрос – кому звонить первому? Кто отвечает за событие? Часто человек, работающий с сетью, получает первое предупреждение, а он может быть относительно неопытен, так что необходим четкий план решения. Кому звонить дальше? Задача состоит в выполнении ранней, быстрой диагностики, чтобы установить тип возникшей проблемы. Если это сбой в работе сети, дело одно. Но если это проблема масштабирования, то совсем другое. В случае проблем масштабирования рекомендуется раннее подключение кого-нибудь из группы разработки.
Всем вовлеченным в пожарные меры нужна хорошая информация, ключом к которой являются эффективные права доступа. Цель состоит в том, чтобы распределить как можно больше информации, чтобы можно было эффективно поставить диагноз, и это должно в итоге диктовать масштаб решения.
Часто если единственным решением является написание кода, событие закончится, прежде чем это можно будет сделать. Само собой, событие следует отметить, чтобы уточнить приоритеты разработки на будущее, но вряд ли разумно пытаться написать кучу кода и воткнуть его в рабочую среду без тщательного тестирования. Правило №1 любого пожарного – не раздувайте огонь.
Когда дело доходит до проблем масштабирования, порой решение заключается в том, чтобы просто переждать. Но это остается решением, которое можно принять.
В то же время планирование на подобные случаи означает возможность быстро применить различные приемы. Направление ресурсов как отдела работы с сетью, так и отдела разработки на решение проблемы масштабирования часто решает ее за примечательно быстрое время, возможно достаточно быстро, чтобы сделать рекламную акцию еще большим успехом.
В заключение можно сказать, что урок, преподанный рассмотрением вопроса с точки зрения сети, состоит в том, что хорошо масштабируемое, высокопроизводительное приложение ASP.NET представляет успешное взаимодействие между людьми, создающими приложение, и теми, кто развертывает и эксплуатирует его.
Сотрудничество неизбежно, так что лучше начать его раньше, со встреч между группами для обмена информацией. Цель встречи заключается в достижении понимания и согласия по всем элементам приложения, тому, что оно делает, как оно работает, от чего оно зависит, как оно ведет себя под нагрузкой и как оно переносит проблемы, возникающие с течением времени.
Когда такое сотрудничество действительно эффективно, результатом является более гибкая компания, способная быстро отвечать на проблемы и четко довести до всех, кому необходимо, что требуется приложению для успеха в будущем.

Ричард Кэмпбелл (Richard Campbell) является региональным директором Майкрософт, обладателем звания MVP по ASP.NET, и одним из ведущих .NET Rocks, Интернет-аудиопрограммы для разработчиков .NET (посетите ее на dotnetrocks.com). Он провел годы, консультируя компании на темы производительности и масштабирования ASP.NET, а также является одним из основателей компании Strangeloop Networks.


От редактора Прямой эфир с Tech•Ed
Джошуа Хоффман (Joshua Hoffman)

Когда я сажусь написать статью для рубрики «От редактора», я всегда сталкиваюсь с небольшим затруднением. Придумать тему обычно несложно, поскольку интересных предметов для разговора хватает всегда. Нет, проблема в том, что «От редактора» необходимо писать примерно за шесть недель до того, как ее прочтут (отчасти для того, чтобы было время напечатать журнал, но в основном затем, чтобы дать литературным сотрудникам достаточно времени для исправления всех моих ошибок). В отличие от ведения блогов, которое может следовать непосредственно за событиями, в таких условиях сложно писать о «новостях», поскольку к моменту их прочтения они перестанут быть новостями.
Но вот он я, на конференции Tech•Ed 2008, в «солнечном» Орландо, и это событие действительно важнее всего остального, что происходит сейчас в нашей области. Так что хоть эта статья и может быть немного устаревшей, когда вы ее прочитаете... что ж, придется потерпеть.
Tech•Ed – захватывающее событие для нас по ряду причин. Начнем с того, что это один из немногих случаев, когда мы можем увидеть столь многих наших читателей (и даже наших авторов) вживую! Мы можем пользоваться электронной почтой, обменом мгновенными сообщениями и телефонными звонками круглый год, но ничто не сравнится с потоком идей и интересных бесед, вырастающим из собрания такого количества людей.
Tech•Ed также является отличным моментом, чтобы заглянуть вперед, в будущий год. Там будут руководители высокого уровня, раскрывающие общую стратегию, что, конечно, информативно. Мы узнаем многое о новых направлениях в виртуализации, следующем поколении сети, революционных концепциях в управлении системами и многих других вещах.
Тем не менее, я здесь ради будничных подробностей. Марк Руссинович (Mark Russinovich), технический специалист корпорации Майкрософт и пишущий редактор, расскажет о переопределении границ безопасности. Стив Райли (Steve Riley), еще один пишущий редактор, будет говорить о полном исчезновении сетевых границ – особенно захватывающая и оригинальная концепция! А Марк Минаси (Mark Minasi), Роми Махаян (Romi Mahajan), Дхармеш Годха (Dharmesh Godha) и я организуем круговое обсуждение потребительского перерождения информационных технологий.
Я также буду рассказывать о том, с чего начать, если вы хотите писать статьи для TechNet Magazine, – презентация, подача которой доставляла мне удовольствие последние несколько лет и которая вдохновила не одного начинающего автора. К тому времени, как эта статья появится в журнале, слайды с моей лекции будут размещены на blogs.technet.com/tnmag – приглашаю всех желающих посмотреть. Кто знает? Может быть, в следующий раз вы появитесь на Tech•Ed как один из наших авторов!
Да, не стоит забывать о вечеринках на Tech•Ed. Мы любим и их тоже.
—Джошуа Хоффман (Joshua Hoffman)

Мы бы хотели поблагодарить следующих технических специалистов корпорации Майкрософт: Сунила Агарвала (Sunil Agarwal), Эрика Чаррэна (Eric Charran), Трину Горман (Trina Gorman), Санджива Нэйра (Sanjeev Nair), Исаака Ройбала (Isaac Roybal), Джеза Садлера (Jez Sadler), Роджера Спрэга (Roger Sprague), Стефана Стрэйнджера (Stefan Stranger), Кевина Салливана (Kevin Sullivan), Джима Трухера (Jim Truher), Алана фон Велтина (Alan von Weltin), Майкла Уолша (Michael Walsh) и Бака Вуди (Buck Woody).


Письма в редакцию Мнения читателей

Типы содержимого SharePoint
Я ищу информацию, которая дала бы мне подробное представление об использовании типов содержимого Microsoft® SharePoint®. Где можно найти ее?
—E.A.

Хорошим источником такой информации является блог группы продуктов и технологий Microsoft SharePoint (доступный по адресу blogs.msdn.com/sharepoint), а Пав Черны написал статью по стандартизации управления данными с помощью специальных типов содержимого, которую можно найти на technet.microsoft.com/magazine/cc194408. Существует технический документ по управлению корпоративными метаданными, который вы можете счесть полезным, доступный по адресу technet.microsoft.com/library/cc262729.
Другим ресурсом, который вы можете пожелать изучить, является блог Эндрю Мэя (Andrew May) по адресу blogs.msdn.com/andrew_may. Эндрю – программист и разработчик документации в Майкрософт, ответственные за написание документации для разработчиков по функциям управления содержимым в Windows® SharePoint Services 3.0 и Microsoft Office SharePoint Server 2007. Он ведет блог по типам содержимого и предлагает плакаты с техническими иллюстрациями, которые относятся к типам содержимого и объясняют более сложные аспекты управления корпоративным содержимым в среде SharePoint.

Углубляя безопасность
Мне понравилась статья «Великий спор: безопасность через незаметность» (июнь 2008, technet.microsoft.com/magazine/cc510319). Однако я был немного разочарован, что основное внимание во всей статье уделено было только изменению одного лишь имени администратора. Я в основном стою на стороне Роджера Граймса и Аарона Маргосиса в споре об имени администратора, поскольку я согласен, что это лучше, чем ничего, и не создает больших проблем с управлением. Но ведь существует так много более содержательных задач – общие административные ресурсы были упомянуты, но группа не углублялась в них, а ведь их блокирование вызывает серьезные проблемы с управлением.
Я бы также не отказался увидеть обсуждение группой плюсов и минусов попыток «уменьшить область, доступную для атак». Уменьшение области, доступной для атак, является несущественно отличающимся вариантом безопасности через незаметность, поскольку, как правило, пользователи вырывают то, что рассылает местонахождение или идентификацию. Например, многие из моих клиентов вырывали IPv6 во имя безопасности через незаметность. Удаление служб часто выполняется в манере средневековых докторов – закрой глаза, дотянись до чего попало и надейся, что это не убьет пациента.
—Шелли Б.

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

Недостаточно незаметно
«Великий спор: Безопасность через незаметность» была хорошей статьей. Думая о ней, я понял две вещи. Во-первых, я полагаю, что пока прибыль от инвестиций в незаметность достаточно высока, незаметность остается хорошей вещью. Во-вторых, я осознал, что большая часть безопасности ИТ всегда имела компонент незаметности.
Возьмем, к примеру, пароли. Мы всегда делали так, чтобы их было все сложнее и сложнее заметить. Поначалу пароль не был необходим на большинстве ПК. Затем, когда компьютеры стали более тесно связанными, было достаточно иметь простой пароль. По мере повышения степени связи сделался важным пароль минимум из восьми символов. Когда это оказалось недостаточно безопасным, нам пришлось перейти к смешанным символам, затем к кодовым фразам и так далее. Я подозреваю, что наши старые меры незаметности продолжат становиться недостаточно незаметными.
—Том Б.

Спасибо за весьма проницательные комментарии, Том. Будет интересно увидеть, куда приведет эта тенденция, особенно по мере того, как такие концепции безопасности, как многофакторная проверка подлинности (смарт-карты плюс пароли, например), станет более распространенной.

Плакаты TechNet Magazine
Я хотел бы добыть плакаты Майкрософт, входившие в последние несколько выпусков TechNet Magazine, для разработчиков в моей компании. Не могли бы вы сказать, как купить их?
—Хелен Г.

Доступны три следующих плаката: «Архитектура компонентов Microsoft Exchange Server 2007»; «Центральные компоненты Active Directory в Windows Server® 2008 ® и «Центральные компоненты Windows Server 2008». Их можно приобрести, позвонив по номеру 800-444-4881 в США и Канаде или 785-838-7500 в любой другой стране.


Инструментарий Новые продукты для специалистов по информационным технологиям
Грег Стин (Greg Steen)

Мониторинг серверов
PA Server Monitor Pro
poweradmin.com/servermonitor
Необходимо следить за работой всех частей вашей инфраструктуры. Предупреждение некорректных действий до того, как ваши конечные пользователи их осуществят, имеет серьезное значение для отслеживания поломок и сообщения о них. (Кроме этого, шеф, который дышит вам в затылок, – не самая увлекательная перспектива.) Одним из средств, облегчающих наблюдение за работой серверной инфраструктуры, является PA Server Monitor Professional Edition компании Power Admin LLC.
Освоение PA Server Monitor и работа с ним не представляет трудностей, особенно при помощи встроенного в приложение процесса автоматической настройки, обнаруживающего машины в вашей ЛВС и автоматически настраивающего для каждой из них набор мониторов. Если вы не заинтересованы в прохождении процедуры обнаружения, можно импортировать список машин, для которых требуется настроить проверки наблюдения. После того как машина настроена, можно экспортировать эту настройку герез графический интерфейс для повторного использования ее в качестве шаблона для других машин или в качестве резервной копии на случай возможной повторной установки.
PA Server Monitor предлагает 18 разных мониторов, которые можно назначить каждому из серверов. Эти мониторы выполняют стандартные проверки, такие как наблюдение за местом на диске, ошибками журнала событий, удаленноым выполнением сценариев, изменениями файлов и каталогов, использованием ЦП и памяти, откликом протокола ICMP (ping) и состоянием служб Windows®.
Существует еще несколько чрезвычайно удобных мониторов, к которым относится монитор для порта TCP, который проверяет основное состояние порта, а также отправляет текст команды и сравнивает ее результат с предусмотренным значением. Во время наблюдения за файлом журнала выполняется проверка файла журнала на вхождение текста, который можно определить как регулярное выражение или простой текст. Монитор квоты каталогов позволяет следить за тем, чтобы конечные пользователи не превышали отведенных им пределов, и уведомляет пользователей по электронной почте, если они превышают квоты. Предусмотрено наблюдение за выполнением сценария для любых пользовательских задач, которые требуется выполнить. И, наконец, можно использовать наблюдение за возрастом файлов для слежения за очередью почты и предотвращения ее резервного копирования.
После того как для сервера определен монитор, необходимо определить действие, которое должно выполняться при достижении порогового значения монитора. PA Server Monitor предоставляет 15 встроенных действий, включающих использование электронной почты, журнала событий, окон сообщений, файлов журналов, перезапуска служб, протокола SNPP (Simple Network Paging Protocol) и пользовательских сценариев для пользовательских действий. При определении действий определяется также цепочка расширения действий, в которой будут выполняться дополнительные действия, если монитор остается в состоянии ошибки долее предусмотренного интервала времени. Например, можно установить действие, при котором сначала выполняется автоматический перезапуск веб-узла. Затем, если после очередных пяти минут проверка по-прежнему дает отрицательный результат, на ваше карманное устройство отправляется сообщение электронной почты, информирующее о состоянии узла.
Со временем вам, вероятно, потребуется ознакомиться со статистикой на настроенных мониторах. В PA Server Monitor встроены функции фомирования отчетов, облегчающие получение информации теми, кому она необходима. Среди встроенных отчетов имеется сводка сервера, предоставляющая статистику и состояние конкретного сервера, общая сводка, предоставляющая по одной строке информации о каждой из контролируемых машин, и графическая карта состояний, на которой отображаются показатели для установок, находящихся в разных географических точках. Отчеты создаются на языке HTML, поэтому к ним возможен доступ с помощью веб-обозревателя, что будет приятной особенностью вашего центра эксплуатации. Кроме этого, предусмотрены также создание специальных отчетов с простыми графиками и диаграммами или экспорт в файл CSV для последующего использования. Предусмотрено также планирование отчетов, что позволяет регулярно получать последнюю статистику по электронной почте, автоматически отправленную приложением непосредственно вам.
PA Server Monitor не использует агентов. Одним из приятных преимуществ является то, что можно быстро приступить к работе с ним, если только контекст службы для приложения выполняется с достаточными полномочиями для установления связи с машинами вашей сети, чтобы запускаться посредством WMI и других удаленных служб администрирования, таких как удаленный вызов процедуры (RPC). Одним из недостатков, однако, является повышенный уровень учетной записи, необходимый для связи с удаленными машинами. Безусловно, существуют другие типы мониторов протоколов серверов, включая HTTP и SMTP, которые не требуют повышенных полномочий.
Еще одним потенциальным недостатком является то, что установление связи с машинами посредством сложной и рассредоточенной инфраструктуры и сетевой топологии может вызвать трудности и будет зависеть от уровня доверия домена и сети. Так что, подойдет ли в итоге вам подход без использования агента, будет зависеть от организации вашей инфраструктуры и того, как именно вы собираетесь использовать решение для наблюдения за серверами.
Цена: 99 долларов США (прямая продажа) за 1 активный монитор или 349 долларов США (прямая продажа) за 5 активных мониторов.
Следите за работой своих серверов с помощью монитора серверов PA Server Monitor Professional Edition (щелкните изображение для его увеличения)

Удаление дублирующихся файлов
dupeGuru
hardcoded.net/dupeguru
Если вы работаете с конечными пользователями или управляете местом на диске, совместно используемым пользователями, то наверняка заметили, что со временем в этом месте нарастает беспорядок. Зачастую это является следствием того, что один пользователь или даже многие пользователи сохраняют один и тот же файл в нескольких местах. При объединении и очистке такого пользовательского места совершенно необходимо средство поиска дубликатов. Хорошим вариантом является решение dupeGuru от Hardcoded Software.
Это средство выполняет поиск дубликатов в целевой папке или на диске, просматривая имена файлов и их содержимое. Но в dupeGuru базовое сравнение строк дополняется использованием алгоритма нечеткого соответствия для поиска дубликатов, которые могут быть пропущены при другом подходе. После того как дубликаты выделены, можно выбрать вариант дальнейших действий. Их можно отправить в корзину, удалить без возможности восстановления, переместить их в другую папку или открыть их в предусмотренном по умолчанию приложении для окончательной проверки. Для последующего просмотра результатов их можно экспортировать в XHTML.
В предпочтительных настройках можно указать, насколько жестко фильтр имен и содержимого файлов должен действовать при поиске и просмотре файлов; это позволяет увеличить число обнаруженных дубликатов, но приводит также к увеличению вероятности ошибки при установлении соответствия. В dupeGuru предусмотрена возможность выделения всех дубликатов, содержащих конкретное слово в имени файла. Это крайне полезно для поиска всех файлов типа «Копия», случайно созданных пользователями, и пустых папок с именем «New Folder», разбросанных по каталогам.
Существуют версии инструмента для операционной системы Windows 2000 и последующих выпусков, а также для Mac OS X. Если вы ищете способ сокращения числа дубликатов среди файлов с музыкой или фотографиями, имеет смысл ознакомиться со специальными версиями, dupeGuru ME и dupeGuru PE соответственно.
Цена: 19,95 долларов США (прямая продажа).
Удаление дублирующихся файлов с помощью dupeGuru (щелкните изображение для его увеличения)

Следите за своей рабочей средой
pt360 Tool Suite PRO
packettrap.com
Наличие единственного интерфейса, позволяющего просматривать и управлять целым набором средств для управления сетью и наблюденияза ней, может оказаться крайне удобным. Помимо значительной экономии времени (и ресурсов настольной системы), интегрированный пакет может облегчить совместное использование данных разными средствами наблюдения, позволяя наблюдать за несколькими мониторами одновременно и обеспечивая более полное представление о состоянии инфраструктуры.
Если это вам подходит, попробуйте средство pt360 Tool Suite PRO от PacketTrap Networks. Это приложение предлагает интегрированный пользовательский интерфейс для инструментов PacketTrap Networks с добавлением возможности централизации и создания консолидированных отчетов. Предусмотрена организация удобного вида средств и создание настраиваемой панели инструментов, позволяющей мгновенно получать доступ к наиболее часто используемым средствам и информации о состоянии инфраструктуры. Панель инструментов pt360 может быть развернута на весь экран. Это крайне существенно в центре эксплуатации, поскольку любой член группы имеет возможность, быстро взгянув на экран, оценить состояние различных сетевых и серверных ресурсов. Приложение поддерживает несколько панелей инструментов, поэтому в рабочей среде можно создавать разные виды в соответствии с конкретными потребностями.
Для настройки панели инструментов выберите из раскрывающегося списка ряд мини-приложений и, щелкнув каждое из них, выполните соответствующую настройку. Мини-приложения разделены на группы пяти категорий («Приложение», «Сеть», «Устройства», «Доступность» и «Прочее») и работают на основе протоколов SNMP (Simple Network Management Protocol) и WMI, отслеживая работу серверов, приложений и сетевых устройств. Мини-приложения группы «Приложение» позволяют работать с Active Directory®, Microsoft® Exchange Server и SQL Server®, а также предоставляют средство обзора. Мини-приложения группы «Сеть» предоставляют информацию об интерфейсах устройств и 10 основных сводок о средних потерях пакетов, максимальных задержках и интенсивности использования интерфейса, приходящейся на одного клиента. Мини-приложения из группы устройств предоставляют показатели производительности, относящиеся к ЦП и использованию памяти, доступное место на диске, перечень томов, использование сетевого интерфейса и многое другое. Эти показатели крайне удобны для отслеживания в режиме реального времени работы серверов посредством настраиваемых запросов WMI. Мониторы группы «Доступность» показывают длительность бесперебойной работы ваших машин в виде диаграммы, устройства измерения, текстовом формате или формате списка. И, наконец, в группу «Прочие» входят большие цифровые часы.
Помимо панели инструментов, набор инструментов pt360 предоставляет средства работы с сетью. Например, вы получаете Cisco Configurator. Это средство позволяет архивировать, изменять, выгружать, загружать и сравнивать файлы настройки оборудования Cisco. Кроме этого, вы получаете три разных средства проверки связи. Одно из них обеспечивает представление в виде допускающей сортировку таблицы, другой выводит графическое представление, а третий позволяет быстро выполнить проверку группы IP-адресов по ping. В число прочих типов средств проверки, которые вы получаете в свое распоряжение, входят средства проверки MAC-адресов, портов, SNMP и WMI.
Набор инструментов может выступать также в роли сервера системного журнала и отправлять, принимать, записывать и отображать сообщения системного журнала с любого и на любом устройстве вашей сети, поддерживающем системный журнал. При отображении поддерживается фильтрация, поэтому есть возможность быстро выделить важные сообщения, что ускоряет процесс поиска и устранения неполадок.
Данный набор работает в качестве сервера TFTP (Trivial File Transfer Protocol), что позволяет быстро перемещать файлы на устройства и с устройств в рамках сети. К прочим инструментам относятся средства маршрутизации трассировки, Whois и пробуждения от ЛВС. Безусловно, поскольку это решение для централизованного управления, осуществляющее связь с серверами посредством WMI и SNMP, критически важным является то, как набор хранит свои учетные данные. К счастью, набор использует хранилище учетных данных, зашифрованное на основе стандарта AES (Advanced Encryption Standard — улучшенный стандарт шифрования) с 256-битным ключом. Для этого хранилища предусмотрено добавление, обновление и удаление информации, необходимой для текущего контроля вашей инфраструктуры.
Цена: 999 долларов США (прямая продажа) за одну лицензию.
Рис. 36 Наблюдение за системами с помощью pt360 Tool Suite PRO (щелкните изображение, чтобы увеличить его)

Управление использованием места на диске
TreeSize Professional
jam-software.com/treesize/index.shtml
«И чем только занято все место на диске сервера!» Знакомый возглас? Приложение, осуществляющее наблюдение, только что отправило вам сообщение электронной почты с уведомлением о том, что достигнут нижний порог свободного места на диске. Хорошо, вы можете задать вопрос о том, как же можно приступить к расчистке пространства на такой машине. И каким образом можно быстро оценить, что правильнее всего подвергнуть операции «Shift-Delete». (Это быстрый способ удаления, при котором пропускается помещение в корзину.) Одним из средств, которое может помочь в поисках зеленого сигнала светофора при наблюдении за сервером, является TreeSize Professional от JAM Software.
Это приложение работает в среде Windows 2000 и более поздних выпусков как 32-, так и 64-разрядных версий Windows и обеспечивает расширенное представление файлов, занимающих место на ваших дисках. Все, что вам потребуется сделать, это выбрать диск, который нужно обследовать, а приложение автоматически выполнит проверку структуры папок. По завершении операции вы получаете доступ к семи различным представлениям диска. Первым является вид «Диаграмма», который, в свою очередь, предоставляет для анализа три разных диаграммы: круговую диаграмму, гистограмму и график, состоящий из прямоугольников соответствующих размеров. Каждая из этих диаграмм позволяет исследовать разные папки, что дает возможность быстро выявить пожирателей свободного места. Предусмотрена также настройка цвета и стиля диаграмм.
Второе представление, «Подробное представление», обеспечивает представление файлов в виде допускающей сортировку таблицы. В этом виде предусмотрен выбор ряда столбцов для отображения. Чаще всего пользователи предпочитают выбирать создателя файлов Microsoft Office, средний размер файла, долю объема родительского каталога, занимаемую этим файлом или папкой, и жесткие ссылки.
В представлении «Расширения» указываются типы файлов, занимающих основную часть места в каждом из каталогов по мере того, как вы углубляетесь в структуру папок. Представление «Пользователи» отображает составное представление пространства, занимаемого файлами пользовательской или системной учетной записи, что существенно помогает при определении проблемных пользователей. Представление «Возраст файлов» дает графическое представление доли файлов, подвергнутых изменениям, созданных или открывавшихся за прошедший день, месяц, год (можно выбрать любые временные рамки), что позволяет выделить старые файлы, которые можно безопасно заархивировать или удалить. Существует еще представление «100 наибольших», который определяет 100 самых объемных файлов на диске. И, наконец, есть представление «Журнал», предоставляющий характерные варианты использования файлов на диске в течение определенного времени.
Каждое из этих семи представлений можно распечатать, сохранить и скопировать в буфер обмена для последующего использования. Кроме этого, TreeSize ускоряет выполнение обычных задач обслуживания по чистке дисков с помощью панели инструментов, поскольку его функция поиска файлов позволяет быстро определить самые большие файлы, самые старые файлы, временные файлы, файлы кэша Интернета и дублирующиеся файлы. TreeSize Professional предусматривает также проверку по сети с помощью общих папок с адресами в формате UNC, но в этом случае существенно снижается производительность из-за сетевых издержек.
Приложение поддерживает также режим командной строки. Это крайне удобно для планирования и ночных запусков. Предусмотрено также создание плановой задачи проверки, настройка ее для проверки по некоторому пути и формирование набора отчетов в соответствии со стандартным расписанием. Это удобно для еженощного наблюдения за общим пользовательским местом и позволяет вести тщательное наблюдение за использованием места на диске.
Если вы задумываетесь над вопросом, как могло исчерпаться все пользовательское пространство терабайтного объема, возможно, TreeSize поможет вам понять, как используется пространство на ваших дисках, и перейти к более эффективному управлению им.
Цена: 49,95 долларов США (прямая продажа) за одну лицензию.
Управление использованием места на диске с помощью TreeSize Professional (щелкните изображение для его увеличения)

Грег Стин (Greg Steen) – специалист по информационным технологиям, предприниматель и энтузиаст. Он постоянно занят поиском новых средств, которые помогут специалистам по информационным технологиям упростить обеспечение качества, а также процессы разработки и эксплуатации.
© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.


Вопросы и ответы по SQL Секционирование, проверки согласованности и другое
Пол С. Рэндал (Paul S. Randal)

В: Я случайно присоединил производственную базу данных к серверу SQL Server® 2005 и теперь пытаюсь присоединить ее к правильному серверу, который работает под управлением SQL Server 2000. Я попробовал просто отсоединить базу данных и присоединить ее к SQL Server 2000, потом попробовал сделать то же самое через восстановление резервной копии, но оба способа не сработали. Почему это не работает на сервере SQL Server 2000? Эта копия базы данных у меня единственная.
О: Первое, что хотелось бы отметить, — очень важно иметь резервные копии. Администраторы обычно думают, что резервные копии нужны только для восстановления даных после их повреждения или какого-то другого происшествия. Однако ваш случай не столь очевиден: вы пострадали из-за того, что что-то пошло не так в ходе обновления базы данных, пусть даже это обновление и было непреднамеренным. Тем не менее наличие свежей и полной резервной копии базы данных необходимо на случай, если с базой данных что-то случается.
Обновление, запланированное или нет, является необратимой операцией, и ее результат очень трудно отменить. Во время обновления с одной версии SQL Server до другой над базой данных выполняется ряд операций. Каждая из них обычно предполагает некоторые физические изменения в базе данных, и после каждой операции номер версии базы данных увеличивается.
Например, одно из главных изменений, вносимых при обновлении базы данных SQL Server 2000 до SQL Server 2005, происходит со структурой системных каталогов (также называемых системными таблицами или метаданными), в которых хранятся данные о таблицах, индексах, колонках, распределениях и прочие сведения о физической структуре базы данных.
И с каждой операцией обновления увеличивается номер версии. Например, у баз данных SQL Server 7.номер версии 515, у баз данных SQL Server 2000 номер версии 539, а у баз данных SQL Server 2005 номер версии 611 (или 612, если включен тип vardecimal). По номеру версии SQL Server узнает, какой была последняя операция обновления, произведенная над базой данных.
SQL Server предыдущих версий не могут читать базы данных, обновленные до самых последних версий (например, SQL Server 2000 не может читать базы данных, обновленные до SQL Server 2005). Причина в том, что в старых версиях просто нет программного кода, который способен работать с обновленными структурами баз данных. В этом и состоит проблема вашей базы данных, которая была обновлена до SQL Server 2005: ее невозможно присоединить к SQL Server 2000.
В отсутствие полной резервной копии базы данных единственным выходом для вас будет экспорт всех данных из обновленной базы данных и перенос их в новую базу данных SQL Server 2000 вручную. Пока вы не использовали какие-либо новые возможности SQL Server 2005, можно выгрузить структуру базы данных с помощью сценария, создать базу данных той же структуры на SQL Server 2000, а затем экспортировать и импортировать данные.
Чтобы написать сценарий выгрузки базы данных SQL Server 2005, нужно воспользоваться обозревателем объектов SQL Server Management Studio (щелкните базу данных правой кнопкой мыши, выберите «Задания», затем пункт меню «Создать сценарий»). Интуитивно понятный мастер создаст сценарий, который выгрузит все объекты, индексы, ограничения, триггеры и так далее.
В: Недавно мы перепроектировали базу данных так, чтобы для главной таблицы использовать секционирование — нам сказали, что это поможет увеличить производительность. Наша база данных хранится на одном жестком диске объемом 120 Gb, а таблица полностью помещается в одну файловую группу. Скользящих окон создано не было, просто каждую неделю добавляются новые секции. Необходимо, чтобы все данные были доступны в сети. Большинство наших запросов обрабатывает данные в пределах одной недели, и только некоторые работают с данными за год. Использовать одну файловую группу показалось проще. Прав ли я, или что-то было пропущено?
О: Хотя может показаться проще использовать одну файловую группу, преимущества секционирования в этом случае вряд ли удастся заметить. Секционирование используется в основном для более эффективного сопровождения базы данных и для повышения доступности данных в случае аварии. Кроме того, можно создать такую схему, которая даст прирост производительности.
В классическом примере использования секционирования таблица продаж делится на 12 разделов, каждый из которых содержит данные за один месяц текущего года. В конце каждого месяца отключается (и архивируется или удаляется) самый старый раздел и подключается новый. Это и есть то скользящее окно, о котором вы писали. Раздел текущего месяца доступен и для записи, и для чтения; данные предыдущих месяцев доступны только для чтения. Каждый раздел хранится в отдельной файловой группе. В данной схеме используются все преимущества секционирования, но в некоторых условиях она может быть неоптимальной.
Моя жена Кимберли придумала изменение описанной выше схемы, приводящее к более эффективному индексированию. Разделим таблицу продаж на две: одна будет хранится на разделе, доступном для записи и чтения, а другая — на 11 разделах только для чтения. Также поверх обеих таблиц создадим секционированное представление.
Такой подход позволяет иметь небольшое количество индексов для таблицы, открытой на запись и чтение, и большее количество индексов, поддерживающее запросы для отчетности, для таблицы, открытой только для чтения. В свою очередь это позволяет существенно увеличить эффективность операций языка манипулирования данными (DML), поскольку им не придется поддерживать так много некластеризованных индексов.
Кроме того, запросам к данным для чтения и записи не придется обрабатывать данные только для чтения. В SQL Server 2005 удаление разделов из планов запросов несовершенно, особенно для сложных предикатов, однако в SQL Server 2008 оно значительно улучшено. Дополнительные сведения по этому вопросу находятся в записи в блоге Кимберли sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93.
Чтобы показать на примере, что я имею в виду, я расскажу о некоторых возможностях, доступных только при секционировании в разных файловых группах.
Частичная доступность базы данных Это способность базы данных быть доступной в сети во время восстановления после сбоя, если по сети доступна первичная файловая группа. В случае единственной файловой группы вся база данных будет недоступна до окончания восстановления. Если же данные распределены по нескольким файловым группам, то недоступны будут только поврежденные файловые группы, а само приложение может продолжать работу.
Поэтапное восстановление Эта схема похожа на схему частичной доступности базы данных. В единственной файловой группе единицей восстановления является или одна страница, или вся база данных. В случае нескольких файловых групп восстанавливать можно одну группу, тем самым предоставляя частичный доступ к базе данных.
Сопровождение секционированной базы данных Любая из обсужденных выше схем секционирования позволяет дефрагментировать индексы внутри раздела, даже если все разделы находятся в одной файловой группе. Однако в этом случае теряется возможность проводить проверки целостности на отдельных разделах, что могло бы существенно снизить количество данных, которое проверке целостности базы данных предстоит проверить (и, соответственно, нагрузку на CPU и операции ввода-вывода).
Проще говоря, хоть и можно разместить все разделы в одной файловой группе, использование нескольких файловых групп дает значительные преимущества.
В: Недавно мы сильно перепугались за один из наших современных серверов баз данных — неисправная планка памяти приводила к повреждениям данных. Мы обнаружили это, когда в приложении стали появляться произвольные данные. Мы запустили DBCC CHECKDB и обнаружили все типы повреждения данных. К сожалению, резервные копии тоже были испорчены, так что нам пришлось вручную избавляться от плохих данных.
Короче говоря — мы заменили оборудование и включили проверку контрольных сумм страницы. Нам бы хотелось делать регулярные проверки целостности, но у нас немного времени на обслуживание базы данных, а 2,4 TB проверяются долго. Что мы можем сделать?
О: Вопрос о том, как проводить проверку целостности и прочее обслуживание на VLDB (очень больших базах данных) становится все более и более популярным. Многие администраторы опускают руки, видя, что DBCC CHECKDB занимает больше времени, чем позволяет время запланированного обслуживания. (В некоторых случаях базы данных используются круглосуточно и без выходных, и времени для существенного повышения нагрузки на процессор и систему ввода-вывода, которыми сопровождается проверка целостности, просто нет).
Есть четыре варианта действий в этом случае, кроме прекращения регулярных проверок целостности (что, конечно же, не рекомендуется). Я лично помогал клиентам использовать все четыре подхода.
Использование параметра WITH PHYSICAL_ONLY программы DBCC CHECKDB Обычный запуск DBCC CHECKDB осуществляет большое количество проверок логической целостности данных, сильно нагружая процессор (в общем, именно эта операция и является процессорнозависимой). Параметр WITH PHYSICAL_ONLY ограничивает проверки запуском очень быстрого DBCC CHECKALLOC, который сначала проверяет целостность битового массива распределений, а затем читает и проверяет каждую распределенную страницу базы данных вместе с контрольными суммами. Таким образом, DBCC CHECKDB становится приложением, зависящим от ввода-вывода, с гораздо меньшим временем исполнения (иногда такая проверка на порядок быстрее полной проверки целостности, в результате чего экономится существенное время).
Разделить рабочую нагрузку проверки целостностиЭтот способ предусматривает разбивку таблиц в базе данных на группы равного размера (проще всего разбивать по количеству страниц) и запускать DBCC CHECKTABLE для проверки целостности всех таблиц в одной группе. Например, если сделать семь групп и проверять их по одной в день, используя DBCC CHECKALLOC и DBCC CHECKCATALOG, то будет достигнут результат DBCC CHECKDB, только растянутый на неделю.
Использовать секционирование таблиц с несколькими файловыми группамиСамы большие таблицы в VLDB можно разбить на несколько файловых групп. В примерной схеме проверки целостности можно использовать ежедневный запуск DBCC CHECKFILEGROUP на файловую группу с таблицами, использующимися для записи и чтения, и еженедельный запуск DBCC CHECKFILEGROUPs для файловых групп, содержащих разделы, открытые только для чтения. Логика здесь в том, что данные только для чтения полностью скопированы в резервные копии и не участвуют в ежедневной обработке. Таким образом, повреждение этих данных некритично и, следовательно, их целостность можно проверять реже.
Выгрузить проверку ссылочной целостности на другой сервер Этот вариант предполагает восстановление полной регулярной резервной копии базы данных на другой сервер и запуск DBCC CHECKDB на нем. Очевидно, что это полностью разгружает производственный сервер от проверки целостности. Недостаток этого способа в том, что если будет найдено повреждение данных, проверку целостности придется сделать на рабочем сервере — однако такое случается редко.
Как видите, существуют варианты, позволяющие DBA осуществлять проверки целостности VLDB и одновременно снизить количество дополнительных ресурсов, требующихся для полного DBCC CHECKDB. Как я упоминал раньше, я лично помогал клиентам использовать все четыре подхода. Думаю, и вы найдете подходящий вам вариант.
Совет. Использование триггеров для реализации логики на стороне сервера
В некоторых вариантах моделирования требуется реализовать логику на стороне сервера при помощи триггеров. При этом нобходимо избегать некоторых ошибок. Вот несколько важных моментов.
  • Триггеры выполняются по операторам, а не по записям. Таким образом, в триггере должна содержаться дополнительная логика на случай обработки нескольких записей или их отсутствия (триггеры выполняются по операторам, даже если не задействована ни одна запись). Измененные оператором данные находятся в виртуальных таблицах операторов языка модификации данных (DML). Эти таблицы можно соединять, тем самым позволяя работать с данными.
  • Триггеры выполняются синхронно внутри транзакции. Каждый раз, когда вам захочется вызвать внешнее приложение или обратиться к внешним данным, помните, что нельзя быть уверенным в приемлемом времени ответа. Например, если вы выполняете над таблицей оператор Update и этот оператор вызвал срабатывание триггера, то транзакция (неявная в случае оператора Update) не закончится до сих пор, пока не отработает вся логика триггера. Если внешнее приложение или процесс возвращают ошибку, SQL server может отменить транзакцию и откатить изменения (в зависимости от того, какая ошибка возникла и как определена ее обработка). Таким образом, если вам требуется что-то сделать внутри триггера с внешним ресурсом и это некритично для транзакции (или не должно выполняться в той же области видимости), то эту задачу нужно передать другому процессу, получая данные асинхронно. В SQL Server 2005 представлен SQL Server Service Broker, который делает выполняет это действие асинхронно.
  • Ошибку, вызванную оператором внутри триггера, очень сложно найти. Если в транзакции участвуют несколько таблиц, убедитесь в том, что проверили обработку ошибок в триггерах и, если необходимо, дописали ее. Если в базе данных меняется схема, убедитесь в том, что понимаете, как в таком случае будут работать триггеры, — иначе маленький триггер может сильно ухудшить производительность и стабильность. Другие особенности изменения схемы можно проверить, используя Visual Studio® для специалистов по базам данных. Он автоматически проверяет схему во время редактирования проекта и осуществляет статический анализ кода для выявления нессответствий.
— Дженс К. Сьюссмейер (Jens K. Suessmeyer), консультант корпорации Майкрософт по базам данных

Пол Рэндал генеральный директор SQLskills.com является MVP по SQL Server. Он работал в группе подсистемы хранения SQL Server в корпорации Microsoft с 1999 по 2007. Пол написал DBCC CHECKDB/исправление для SQL Server 2005 и во время разработки SQL Server 2008 отвечал за разработку Core Storage Engine. Пол, будучи специалистом по аварийному восстановлению, высокой доступности и обслуживанию баз данных, регулярно делает презентации на конференциях. Он ведет блог по адресу SQLskills.com/blogs/paul.


Обзор служебных программ Служебная программа удаления данных установщика Windows
Лэнс Уитни (Lance Whitney)

Вы пытаетесть удалить или обновить приложение на одном из ПК вашей рабочей среды, но выданная вами команда не выполняется. Вместо этого появляется сообщение об ошибке, связанной с тем, что приложение невозможно удалить или обновить. Звучит знакомо? Если это так, то вы наверняка хотите узнать, чем вызывается эта проблема.
При установке программного обеспечения с помощью технологии установщика Microsoft® Windows® (MSI) выполняется запись определенных файлов и параметров реестра. Если какой-либо из этих файлов или параметров отсутствует или поврежден, не исключено, что вам не удастся удалить, обновить или даже переустановить программу. В таком случае решение проблемы заключается в удалении всех данных установщика Windows, чтобы программу можно было переустановить без помех. Для этого корпорация Майкрософт предлагает бесплатную служебную программу удаления данных установщика Windows.
Служебная программа удаления данных установщика Windows удаляет все файлы и параметры реестра, связанные с настройкой установщика Windows для конкретной программы. Важно отметить, что данное средство не удаляет реальные установочные файлы или параметры реестра этой программы. Это средство не является также заменителем команды установки и удаления программ.
Наоборот, эта служебная программа выручает вас в том случае, когда не удается удалить или обновить приложение с помощью команды добавления и удаления программ или другими способами. Удаление данных установщика Windows должно позволить переустановить приложение. После этого можно оставить программу в таком виде, как она установилась, можно обновить или даже удалить ее.
Служебная программа удаления данных установщика Windows отображает список всех приложений, установленных на ПК с использованием установщика Window (щелкните изображение для его увеличения)
Некоторые из вас, возможно, знакомы с программой msizap командной строки Майкрософт, которая удаляет данные установщика Windows для некоторой программы. Что ж, эта команда никуда не делась: служебная программа удаления данных установщика Windows является попросту удобным пользовательским интерфейсом программы msizap, так что вам больше не придется бороться с громоздкими параметрами командной строки.
После установки служебной программы вы обнаружите подкаталог с именем Windows Installer Clean Up в каталоге Program Files. В этом подкаталоге находятся три файла: msicuu.exe, msizap.exe и readme.txt. Файл msicuu.exe отображает список всех приложений на ПК, установленных с помощью установщика Windows, и предоставляет возможность выбирать, отменять выбор и удалять любое из них. Затем эта программа передает результаты выбора команде msizap.exe, которая удаляет данные установщика Windows, относящиеся к выбранным приложениям.
Для запуска программы удаления данных установщика Windows перейдите к пункту меню «Пуск | Все программы» и отыщите ее папку; затем щелкните ярлык Windows Installer Clean Up. Отображается список всех приложений, установленных на ПК с использованием установщика Windows (как показано на снимке экрана). Выберите приложение, породившее проблему, и нажмите кнопку «Удалить». Приложение удаляется из из базы данных установщика Windows, что обеспечивает возможность беспрепятственной повторной установки.
Вы увидите, что после запуска средства удаления приложение исчезает из окна добавления и удаления программ. Следовательно, если в конечном итоге вам требуется удалить приложение, сначала его нужно повторно установить. Программа удаления данных установщика Windows работает только с программным обеспечением, использующим технологию установщика Windows, которая обычно представлена в установках, упакованных в виде файлов MSI.
Наконец, отметим, что для запуска программы удаления данных установщика Windows необходимы полномочия администратора. Это средство совместимо со всеми 32- и 64-разрядными версиями Windows. Для получения подробных сведений об этой служебной программе и загрузки программного обеспечения ознакомьтесь с веб-страницей по адресу support.microsoft.com/kb/290301.

Лэнс Уитни (Lance Whitney) — консультант по информационным технологиям, преподаватель и разработчик технической документации. Он провел бессчетные часы за настройкой рабочих станций и серверов Windows. Журналист по профессии, 15 лет назад он занялся изучением информационных технологий.


SharePoint изнутри Поиск и устранение неполадок в интеграции с единой системой обмена сообщениями
Пав Черны (Pav Cherny)

Загрузка кода возможна по следующей ссылке: SharePoint2008_08.exe (416 KB)
Cодержание
Общие методы поиска и устранения неполадок
Архитектура системы обмена сообщениями SharePoint
Сбор диагностической информации
Передача исходящих сообщений
Передача входящих сообщений
Управление списками рассылки
Заключение
Если среда SharePoint грамотно спроектирована, сотрудникам, занимающимся обработкой информации, не придется менять привычные процедуры обмена информацией внутри рабочей группы. Кроме того, узлы совместной работы не придется проверять вручную: система SharePoint способна доставлять документы и прочие материалы, например оповещения и предупреждения, непосредственно в почтовый ящик сотрудника.
Участники потоков работ могут отвечать на сообщения такого рода и отправлять новые элементы в библиотеки и списки документов по электронной почте.
Однако нужно отметить, что интеграция системы SharePoint® в среду безопасного обмена сообщениями — процесс непростой. Компоненты, не связанные с системой SharePoint, могут нарушать работу самой системы. Самая сложная задача — выявить и устранить исходные причины всех неполадок, возникающих при интеграции среды.
В этой статье процедура интеграции SharePoint рассматривается с точки зрения проверенных, эффективных стратегий поиска и устранения неполадок. Подход заключается в том, что сначала без лишних трудозатрат определяется источник неполадки, а потом для него подбирается процедура устранения проблемы.
В крупных организациях такой подход иногда предполагает передачу решения проблемы другому специалисту после предварительного анализа ситуации, особенно если причина ее кроется в компонентах, не связанных с системой SharePoint. В организациях менее масштабных администратор отдела ИТ чаще всего сам устраняет все неполадки, связанные с любыми используемыми системами, и в этом случае потребность в структурированном подходе становится еще более очевидной.
Дабы подчеркнуть практический характер этой статьи, мы использовали среду, в которую входят Active Directory®, Exchange Server 2007 и WSS 3.0. Поэтапные указания по формированию аналогичной тестовой среды, а также средства поиска и устранения неполадок, обсуждаемые в данной статье, имеются в разделе загрузки кода на веб-узле журнала TechNet Magazine.

Общие методы поиска и устранения неполадок
Система SharePoint, пожалуй, даже в большей степени, чем прочие системы совместной работы, требует структурированного подхода к поиску и устранению неполадок. Есть ряд факторов, усложняющих эту задачу.
Не вызывает сомнений тот факт, что работать вам приходится со сложной технологией. Ведя борьбу со сбоями передачи сообщений, преобразования форматов, обеспечения безопасности, управления каталогами, вы столкнетесь с тем, что некоторые сообщения об ошибках в SharePoint попросту непонятны. Группы новостей в Интернете полнятся незакрытыми обсуждениями неполадок, и в них встречаются такие советы, которые способны направить по ложному пути. Например, для бесперебойной передачи сообщений рекомендуют запускать все веб-приложения под удостоверением пула приложений «Центр администрирования SharePoint».
Но есть во всем этом и положительные моменты. Система SharePoint обладает большим запасом гибкости. Она сама может рассказать вам о том, как устранить неполадку, — нужно только знать, где эту информацию найти. Пара несложных сценариев способна здорово упростить работу по поиску и устранению неисправностей.
При решении проблемы первым делом нужно понять, в чем она, собственно, заключается. Нужно определить источник проблемы, выяснить, какие компоненты она затрагивает. Иногда приходится воспроизвести аналогичную ситуацию при различных настройках системы и изучить журналы событий Windows® и текстовые файлы журналов. Не всегда это просто сделать, поскольку бывают неполадки, которые возникают лишь от случая к случаю. И все же, чем точнее вы сможете воспроизвести проблемную ситуацию, тем быстрее отыщете и устраните ее первопричину. Еще одна важная задача, о которой часто забывают, — документировать все перенастройки и исправления и обеспечивать их применение на всех затронутых системах среды (например, всех серверах клиентского доступа отдельно взятой веб-фермы).

Архитектура системы обмена сообщениями SharePoint
Столкнувшись с проблемой, связанной с интеграцией системы обмена сообщениями, отойдите в сторонку, выпейте чашку чая или кофе, вернитесь, проверьте архитектуру интеграции системы обмена сообщениями SharePoint и только после этого приступайте к устранению неполадок. В противном случае может статься так, что вы исправите не ту проблему или не тот компонент. Например, появление сообщение «Доступ запрещен» при попытке создать объект-контакт в Active Directory не обязательно свидетельствует о том, что нужно исправлять права доступа в Active Directory, как станет видно дальше.
Как бы там ни было, важно понимать роль каждого компонента, задействованного в процессах интеграции систем обмена сообщениями, и принципы взаимодействия компонентов. На рис. 1 показаны важнейшие составляющие в случае интегрированной системы SharePoint-Exchange. Далее они будут рассмотрены более подробно.
Рис. 1 Архитектура интеграции системы обмена сообщениями SharePoint (Щелкните изображение, чтобы увеличить его.)

Сбор диагностической информации
Надежная диагностическая информация — одна из важнейших основ процесса устранения неполадок. Нетленная классика — журнал событий Windows. В центре администрирования SharePoint, помимо всего прочего, можно определить уровень подробности записей SharePoint в журнале событий Windows на веб-серверах (на странице «Операции», в блоке «Ведение журналов и составление отчетов», нужно щелкнуть пункт «Сбор данных диагностики»). Можно указать минимальный уровень важности событий, заносимых в журнал событий и журнал трассировки. Журнал трассировки (по умолчанию он хранится в папке %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) весьма полезен в том случае, когда требуются данные низкого уровня, но он очень быстро заполняется, поэтому использовать его нужно как можно реже.
Еще один способ сбора диагностической информации — использование отладки веб-приложения, в работе которого возникли неполадки. Включается отладка в соответствующем файле web.config (см. информацию в файле Web Application Config.pdf в сопровождающих материалах). Система SharePoint будет выдавать подробные данные трассировки непосредственно в пользовательском интерфейсе. Преимущество такого подхода состоит в том, что для поиска нужной информации об ошибке не приходится прочесывать мегабайты данных трассировки. Недостаток — в том, что нужно менять настройку веб-приложения. Не забудьте сделать резервную копию файла web.config и восстановить настройку, когда устраните проблему.
Кроме этого, можно настроить службу SMTP так, чтобы она записывала подробную информацию об обрабатываемых данных в журнал протокола SMTP (в диспетчере служб IIS нужно на вкладке «Общие» установить флажок «Вести журнал»). Обязательно установите модуль ведения журнала ODBC вместе со службой SMTP, даже если вы не планируете использовать журналы ODBC (см. информацию в файле SharePoint Messaging Integration.pdf в сопровождающих материалах). В противном случае служба SMTP вести журнал не сможет. По умолчанию журнал протокола SMTP хранится в папке %SystemRoot%\System32\LogFiles\SmtpSvc1. Он представляет собой текстовый файл, позволяющий подробно проанализировать процессы обмена данными по протоколу SMTP и определить, было ли сообщение отправлено с сервера SharePoint.
На транспортном сервере-концентраторе с установленной службой SMTP можно также включить ведение журнала протокола в настройке соединителей отправки и получения (см. указания в файле SharePoint Messaging Integration.pdf). Существует множество других средств, позволяющих отслеживать пути следования сообщений в среде Exchange Server 2007 при прохождение ими транспортных серверов-концентраторов и серверов почтовых ящиков: отслеживание сообщений, средство просмотра очереди, средство конвейерной трассировки. Подробную информацию о поиске и устранении неполадок, связанных с передачей сообщений в среде Exchange Server 2007, приведены в разделе «Неполадки в процессах передачи сообщений» на странице go.microsoft.com/fwlink/?LinkID=120145.
Чтобы собрать информацию, необходимую для устранения неполадок, на контроллерах доменов Active Directory, нужно включить функцию сбора данных диагностики для доступа к каталогам и других категорий (делается это путем настройки соответствующих разделов реестра в блоке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics). Если для некой категории установлено значение 0x0, в журнал заносятся только самые важные события; если установлено значение 0x5, заносятся все события. При уровне подробности записей более 0x3 производительность сервера может заметно снизиться, а журнал событий Windows быдет быстро переполняться. При нормальной работе систем следует использовать значение 0x0.
Сбор данных диагностики на серверах SharePoint, Exchange и Active Directory помогает быстрее и с большей степенью надежности обнаружить причину сбоя. Также могут оказаться полезными дополнительные средства поиска и устранения неполадок, например средства управления протоколом TCP/IP (проверка связи, tracert, telnet и т. д.) и сетевой монитор, поскольку обмен информацией между системами такого рода по большей части происходит через сеть. Сетевой монитор Microsoft® версии 3.1 можно загрузить на странице go.microsoft.com/fwlink/?LinkId=120143.

Передача исходящих сообщений
Материалы
  • Веб-узел «Продукты и технологии SharePoint»
  • Технический центр служб Windows SharePoint
  • Центр разработчиков для служб Windows SharePoint
  • Блог группы «Продукты и технологии Microsoft SharePoint»
Итак, у нас есть журнал событий, журналы трассировки, журналы протоколов, журналы отслеживания сообщений и сетевой трассировки. Можно приступать к поиску и устранению неполадок в процессах интеграции системы обмена сообщениями SharePoint. Начнем с самого простого: с передачи исходящих сообщений. Система SharePoint поддерживает различные настройки передачи исходящих сообщений, причем локальную службу SMTP на веб-серверах иметь совсем необязательно, однако в полном варианте интеграции системы обмена сообщениями ее все же рекомендуется использовать. На рис. 2 показаны основные компоненты такого варианта.
Рис. 2 Передача исходящих сообщений (Щелкните изображение, чтобы его увеличить.)
В этом варианте передача сообщения выполняется в четыре этапа: передача из системы SharePoint службе SMTP, обработка службой SMTP, передача на транспортный сервер-концентратор и передача сообщения сервером Exchange Server 2007 конечному получателю.
Если системе SharePoint не удается передать сообщение службе SMTP, обычно появляется сообщение об ошибке в пользовательском интерфейсе, например сообщение о том, что уведомление не удалось отправить по электронной почте. Причиной может быть неработающая служба SMTP. Другой вариант: в журнале протокола SMTP появляется запись о том, что служба SMTP отклонила попытку передачи с кодом ошибки 550 («Запрошенное действие не выполнено: почтовый ящик недоступен»). Такая запись говорит о том, что причиной сбоя является служба SMTP.
Убедиться в том, что проблема не связана с системой SharePoint, поможет несложный сценарий (см. файл SMTP.vbs в сопровождающих материалах). Он позволяет отправить через службу SMTP тестовое сообщение, содержащее те же данные об отправителе и получателе, что и реальное неотправленное сообщение. Если причина сбоя действительно кроется в службе SMTP, сценарий выполнить не удастся. Этот сценарий в действительности может дать ценные указания на истинную причину проблемы. Такие данные сам SharePoint, увы, не предоставит даже при включенной отладке (см. рис. 3).
Рис. 3 Сбой отправки сообщений (Щелкните изображение, чтобы его увеличить.)
Если предоставить службе SMTP разрешения на передачу сообщений веб-серверу и перезапустить ее, проблема отправки сообщений из системы SharePoint будет решена. Итак, сообщения поступают в службу SMTP. Следующий важный шаг — проверить, передает ли их служба SMTP на транспортный сервер-концентратор.
Если сообщение остается в папке очереди, значит, служба SMTP не может подключиться к транспортному серверу-концентратору. Либо служба транспорта Microsoft Exchange не работает, либо что-то не так с передачей данных в сети или настройкой сети. При помощи клиента Telnet можно без труда проверить, можно ли подключиться к тому порту соединителя получения, который указан в параметрах внутреннего обмена данными.
Это не обязательно должен быть протокол TCP, порт 25. На самом деле, если служба SMTP использует именно этот порт, сообщения могут доставляться на стандартный соединитель получения транспортного сервера-концентратора, который, в соответствии с его настройками, блокирует анонимную передачу сообщений. В таком случае в папке входящей почты появится файл сообщения. (Службу таймера служб Windows SharePoint необходимо остановить: в противном случае сообщение через несколько секунд будет удалено.) Файл сообщения представляет собой оповещение о состоянии доставки следующего содержания: «Diagnostic-code: smtp;530 5.7.1 Client was not authenticated» (клиент не прошел проверку подлинности).
Для решения этой проблемы нужно создать выделенный соединитель получения для серверов SharePoint. Поскольку серверы SharePoint являются внутренними системами, следует выбрать вариант проверки подлинности «Внешняя защита (например, с помощью IPsec)». Это позволит не не предоставлять излишних прав учетной записи ANONYMOUS LOGON. Кроме того, стоит использовать IPsec для защиты данных, передаваемых между серверами SharePoint и транспортным сервером-концентратором.
Если сообщения уходят из папки очереди SMTP, а в журналах протокола SMTP на сервере SharePoint и на транспортном сервере-концентраторе (в папке %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) нет записей о сбое передачи, можно считать проблему решенной при условии, что сервер Exchange Server 2007 доставляет сообщения конечному получателю. Как уже упоминалось ранее, для поиска и устранения неисправностей в работе системы Exchange Server 2007 можно использовать различные средства анализа процессов обмена сообщениями, поставляемые вместе с системой. На этом этапе причиной недоставки сообщения могут быть неправильно указанный адрес получателя, фильтры нежелательной почты, ограничения на размер сообщений.

Передача входящих сообщений
Передача сообщений в обратном направлении — процесс несколько более сложный, потому как потенциальные причины сбоев определить не так просто. К примеру, в документации к SharePoint рекомендуется настраивать записи MX в DNS для почтовых доменов SharePoint, а ведь такой подход легко может нарушить пути передачи сообщений в организации Exchange.
Для передачи сообщений в системе Exchange Server 2007 используются соединители отправки и связанные области адресов. Сообщения SharePoint могут передаваться на пограничный транспортный сервер для дальнейшей передаче через Интернет даже несмотря на то, что серверы SharePoint являются внутренними. Для внутренней передачи сообщений следует вместо этого использовать соединители отправки с подробными определениями пространств адресов, а в качестве промежуточных узлов в настройке соединителя следует указывать серверы SharePoint, на которых работает служба SMTP (см. информацию в файле SharePoint Messaging Integration.pdf в сопровождающих материалах). Правильно организованная топология маршрутизации, включающая в себя выделенные серверы-плацдармы, поможет добиться более высокой надежности передачи сообщений из Exchange в SharePoint.
Чтобы проверить, приходят ли сообщения на серверы SharePoint, остановите службу таймера Windows SharePoint Services. Сообщения будут накапливаться в папке входящих сообщений, поскольку именно служба таймера отвечает за обработку сообщений и размещение вложенных файлов в библиотеки документов, связанные с адресом получателя (см. рис. 4). Если сообщения в папку входящих сообщений не поступают, воспользуйтесь средством просмотра очереди на транспортном сервере-накопителе и проверьте, правильно ли Exchange выполняет маршрутизацию. Затем проверьте работу сети: сбои в этой области могут приводить к нарушению обмена данными между транспортным сервером-накопителем и службой SMTP на сервере SharePoint.
Рис. 4 Передача входящих сообщений (Щелкните изображение, чтобы увеличить его.)
Когда вы снова запустите службу таймера, проверьте, удаляются ли сообщения из папки входящих сообщений. Если вложения, присланные вместе с сообщениями, остаются в библиотеках назначения, хотя записи в журнале Windows говорят о том, что SharePoint успешно обрабатывает сообщения, значит, Exchange отправляет сообщения в формате Exchange RTF. Чтобы проверить, действительно ли это так, снова отключите службу таймера, отправьте еще одно сообщение с вложением из клиента Outlook®. Когда оно будет доставлено в папку входящих сообщений, откройте его в программе «Блокнот». Попытайтесь найти в файле строку winmail.dat. Если она там есть, значит, сервер Exchange отправляет сообщения в неправильном формате.
SharePoint требует, чтобы вложения кодировались в формате MIME или UUENCODE. Кроме того, система SharePoint не отражает в журнале событий Windows проблемы, связанные с обработкой winmail.dat (см. рис. 5). Файлы вложений просто не будут помещаться в библиотеку документов. В качестве средства поиска неполадок используйте «Блокнот». Для решения проблемы, связанной с неправильным форматированием, нужно исправить определение удаленного почтового домена SharePoint в консоли управления Exchange. На вкладке «Формат исходного сообщения, которое отправляется в виде вложения в отчет журнала» в поле «Формат RTF Exchange» выберите значение «Не использовать».
Рис. 5 Обработка сообщений Winmail.dat (Щелкните изображение, чтобы его увеличить.)

Управление списками рассылки
Одно из самых полезных событий службы таймера — событие 6873, в котором говорится, что произошла ошибка обработки входящего файла электронной почты из-за того, что указан неизвестный псевдоним. Такое происходит, когда пользователь Exchange неправильно вводит адрес электронной почты SharePoint при отправке сообщения, например если выбранная библиотека документов не существует.
Частично устранить вероятность таких ошибок можно путем настройки службы управления списками рассылки в параметрах входящих сообщений в центре администрирования SharePoint. Нужно, чтобы служба создавала объекты получателей в Active Directory для библиотек документов, работающих с почтой. Пользователи Exchange будут просто выбирать нужный объект получателя, а все контактные данные (проверенные, правильные) будут храниться в адресной книге.
Однако нужно четко понимать, что в этом случае открывается новое поле деятельности по устранению неполадок. Служба управления спсиками рассылки дает сбой в безопасной настройке системы, выполненной по принципу наименьших прав, поскольку на веб-сервере ей требуются расширенные разрешения. Нужно отметить, что в документации к продукту (например, на веб-узле technet.microsoft.com/library/cc262947.aspx) эти требования несколько преувеличиваются: там учетной записи пула приложений центра администрирования предлагается предоставлять права на создание, удаление учетных записей пользователей и управление ими в том подразделении, которое указано для объектов-получателей SharePoint в Active Directory.
Служба управления списками рассылки создает объекты-контакты и объекты-группы, следовательно, пул приложений центра администрирования должен иметь полный контроль над контактами и группами в данном подразделении, а вот разрешение на администрирование учетных записей пользователей ему ни к чему. Если настроить службу управления списками рассылки на веб-ферме так, как предложено, и попытаться включить для некой библиотеки документов возможность работы с почтой, велика вероятность того, что будет выдана ошибка «Доступ запрещен».
Появление такой ошибки говорит о том, что что-то не так с настройкой разрешений в Active Directory. Первым делом администратор предоставляет учетной записи «Все» полный контроль над подразделением SharePoint. Однако это лишь ослабляет защиту Active Directory, а саму проблему не решает.
Структурированный подход к поиску и устранению неполадок подразумевает, что сначала вы находите первопричину сбоя, а затем изменяете настройку только там, где нужно. При таком подходе, если заглянуть в журнал событий Windows на контроллере домена и проверить процессы передачи данных в сети при помощи сетевого монитора, можно обнаружить, что система SharePoint вовсе не обращается к Active Directory в момент возникновения неполадки. Следовательно, изменение настройки Active Directory вряд ли поможет справиться с проблемой. Причина ее кроется в сервере SharePoint.
К сожалению, получить еще какую-то полезную информацию в случае такого сбоя крайне сложно. SharePoint никаких дополнительных данных в журнал событий Windows не заносит. Однако, если включить отладку SharePoint, то по стеку вызовов (см. рис. 6) можно определить, что служба управления списками рассылки использует метод CreateContact веб-службы SharePoint. Пакет SharePoint SDK говорит о том, что это веб-служба интеграции электронной почты (<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx).
Рис. 6. Выходные данные отладки
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
Откроем файл SharepointEmailWS.asmx в обозревателе и взглянем на список поддерживаемых операций. Найдите метод CreateContact и щелкните ссылку — появится сообщение SOAP, которое нужно отправить веб-службе, чтобы создать контакт в Active Directory. Это весьма полезная информация, поскольку теперь мы можем создать средство поиска и устранения неполадок на основе сценариев (см. файл SharepointEmailWS.vbs в сопровождающих материалах), которое будет работать вне пользовательского интерфейса SharePoint, что упростит выбор учетных записей пользователей во время тестирования. На рис. 7 показаны данные, которые возвращает сценарий при запуске под учетной записью пула приложений центра администрирования (слева) и под учетной записью администратора SharePoint (справа).
Рис. 7 Два случая запрета доступа (Щелкните изображение, чтобы его увеличить.)
Сообщения об ошибке различаются! Оба говорят о том, что доступ запрещен, однако слева мы видим сбой обработки, а справа — нет. Так в чем же разница между учетной записью пула приложений и учетной записью администратора SharePoint?
Администратор SharePoint — это локальная учетная запись сервера SharePoint, в то время как учетные записи пула приложений таковыми не являются. Можно добавить учетные записи пула приложений в локальную группу администраторов. Проблема будет решена, однако это не лучший способ ее устранения. Мы считаем предоставление прав администратора учетным записям пула приложений на производственных веб-серверах недопустимым.
Почему учетная запись пула приложений может требовать такого расширения прав? И на этот вопрос может ответить упомянутый выше сценарий. Если на время тестирования предоставить всем пользователям права локального администратора веб-севрера, обнаружится, что учетные записи пула приложений могут использовать веб-службу интеграции электронной почты, тогда как для всех остальных учетных записей, включая администраторов SharePoint, доступ остается закрытым. Это означает, что веб-служба интеграции электронной почты при определении возможности доступа использует настройку пула приложений.
Настройка пула приложений — это часть метабазы служб IIS (или файла applicationHost.config в случае IIS 7.0), а доступ к ней по умолчанию для локальных администраторов ограничен. К счастью, учетным записям не администраторов можно предоставить доступ к метабазе при помощи проводника для метабазы, входящего в пакет IIS 6.0 Resource Kit. В IIS 7.0 предоставить полный контроль для файла applicationHost.config еще проще – нужно запустить следующую последовательность команд:
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
Итак, для создания объектов-контактов в Active Directory пулу приложений центра администрирования требуется полный контроль над объектами-контактами и объектами-группами в целевом подразделении. Учетным записям пула, назначенным веб-приложениям, требуется полный доступ к метабазе на серверах SharePoint веб-фермы. Вот теперь мы можем создавать объекты-контакты через пользовательский интерфейс SharePoint.
Нет, стоп. И это еще не все. Создание объектов получателей в Active Directory — лишь половина дела. Вторая половина — это создание атрибутов получателей для Exchange и обновление серверных адресных книг. Например, если обновить глобальный список адресов на сервере Exchange при помощи командной консоли Exchange (команда вида Update-GlobalAddressList "Глобальный список адресов, используемый по умолчанию") новые объекты получателей, созданные для библиотек документов SharePoint, появятся в адресной книге Outlook. Но при отправке сообщений таким получателям будет приходить отчет о недоставке, поскольку адрес указан неверно (см. рис. 8).
Рис. 8 Сообщение в библиотеку документов не доставлено (Щелкните сообщение, чтобы его увеличить.)
Аббревиатура IMCEAEX расшифровывается как Internet Mail Connector Encapsulated Address for Exchange. Это инкапсулированный адрес получателя, не входящего в организацию Exchange, в таком формате, который мог обрабатывать старый соединитель электронной почты Интернета Exchange. Но сейчас мы работаем с Exchange Server 2007 и встроенными соединителями отправки, основанными на SMTP.
Все дело в том, что веб-служба интеграции электронной почты не записывает те атрибуты адреса, которые требуются системе Exchange Server 2007 для передачи сообщения. Записывается только имя, фамилия, отображаемое имя и адрес назначения (и иногда еще атрибут ms-Exch-RequireAuthToSendTo). Ни почтовый псевдоним, ни устаревшее различенное имя Exchange (DN), ни адрес прокси не указываются, объекты получателей с политикой получателей Exchange не связываются.
Для устранения этой проблемы используется командлет Get-Mailbox командной консоли Exchange. Он выдает список всех объектов получателей, адрес которых указывает на почтовый домен SharePoint. Этот список подается на вход командлета Set-MailContact для активации политики получателей Exchange:
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
Другой способ — воспользоваться консолью управления Exchange: в свойствах объектов-контактов установить флажок «Автоматически обновлять адреса электронной почты на основании политики адресов электронной почты».

WSS 3.0 и MOSS 2007 полностью поддерживают интеграцию системы обмена сообщениями (предупреждения и уведомления, связанные с электронной почтой, потоки работ, передачу документов). Правильная настройка системы — задача нетривиальная, однако интеграция систем обмена сообщениями может значительно повысить производительность. В частности, одна из важных задач — обеспечить успешную передачу как входящих, так и исходящих сообщений. Кроме этого, должна быть выполнена интеграция каталога.
Сообщения об ошибках в SharePoint далеко не всегда понятны и информативны. И всё же существуют способы добраться до первопричин сбоя интеграции и устранить их, не подрывая систему безопасности серверов SharePoint.

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

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.


Windows PowerShell Краткий обзор удаленного управления в версии Version 2.0
Don Jones (Дон Джонс)

Эта статья основана на предварительной версии Windows PowerShell. Любые содержащиеся в ней сведения могут быть изменены.

Содержание
Два типа удаленной работы
Синхронная и асинхронная
Повторно используемые пространства выполнения
Удаленная работа слияния
«Убойное» приложение в версии 2.0
У вас уже была возможность поэкспериментировать с последней версией CTP Windows PowerShell 2.0? В последней версии, CTP2, удаленное управление еще больше переработано, и теперь пришло время приступить к ознакомлению с ее новыми возможностями. Прежде чем приступить к рассмотрению Windows PowerShell 2.0, необходимо
загрузить программу с веб-узла go.microsoft.com/fwlink/?LinkID=119707.
Прежде всего, позвольте мне уточнить ряд важных моментов. CTP – это предоставляемая корпорацией Майкрософт предварительная бета-версия кода, позволяющая нетерпеливым пользователям наподобие меня получить представление о направлении, в котором движется Майкрософт, при помощи следующей версии приложения. Каждая веха или выпуск CTP (как это называется в промышленности) может полностью отличаться от предыдущих выпусков. Это происходит потому, что группы разработки собирают отзывы пользователей, внимательно изучают их, а затем на основе этих отзывов вносят в приложение изменения. Такая методика обуславливает важное преимущество и ограничение использования CTP.
Видео
Просмотрите демонстрацию Доном Джонсом новых возможностей удаленного управления в версии CTP2 Windows PowerShell 2.0.

Преимущество заключается в том, что при использовании CTP вы можете предоставить отзыв (через веб-узел connect.microsoft.com) о продукте во время разработки, когда группа разработчиков может отреагировать на него! Если вы подождете до бета-версии или, что еще хуже, до стадии подготовки к выпуску, отреагировать на ваш отзыв гораздо сложнее. При подготовке к выпуску может случиться все, что угодно, и группа разработки при необходимости может внести большие и значительные изменения.
Это представляет для меня ограничение. Версия CTP не готова к выпуску. Конечно, версия CTP2 Windows PowerShell™ 2.0 может быть одной из самых устойчивых частей предварительной версии кода, которую вы когда-либо видели, но необходимо помнить, что следующая версия CTP может полностью отличаться от нее. Поэтому пока не следует полагаться на версию CTP2, потому что после выпуска следующей версии может потребоваться начать все сначала.
Имейте в виду, что версия CTP не может быть установлена вместе с Windows PowerShell 1.0. В идеале в системе также должна быть установлена платформа Microsoft® .NET Framework 3.5, чтобы обеспечить поддержку всех доступных функций. В противном случае функции будут ограничены.
Кроме того, поскольку версия CTP является очень ранней, пока корпорация Майкрософт уделяла основное внимание последним операционным системам, т.е. Windows Vista® и Windows Server® 2008. Совместимость с ОС в данный момент никоим образом не означает совместимости с ОС, которую можно ожидать в итоговом выпущенном коде. Портированию в более ранние версии уделяется внимание на последующих этапах цикла разработки.

Два типа удаленной работы
В мире удаленного управления обычно присутствуют два типа удаленного управления: удаленная работа слияния и развертывания. При удаленной работе слияния несколько администраторов подключаются к одному серверу по протоколу SSH. Windows PowerShell поддерживает подобное подключение безопасным и разделенным образом, чтобы, например, компания, размещающая Exchange Server, могла предоставить своим клиентам административный доступ к отдельным частям сервера. Удаленная работа слияния обеспечивает надежный удаленный интерактивный доступ к копии Windows PowerShell (только версии 2.0!), установленной на удаленном сервере.
Удаленная работа развертывания заключается в выдаче набора команд для группы удаленных серверов одновременно. Команды параллельно «разветвляются» с рабочей станции на группу серверов. Команды выполняются на всех серверах, а результаты — в форме объектов Windows PowerShell — возвращаются на рабочую станцию для просмотра и работы с ними. Windows PowerShell поддерживает две основные технологии для удаленной работы разветвления — инструментарий управления Windows® (WMI) и удаленное управление Windows (WinRM), которые впервые появились в составе Windows Server 2008, а затем были обновлены в версии CTP Windows PowerShell 2.0.

Синхронная и асинхронная
В действительности, еще в Windows PowerShell 1.0 существовали определенные возможности разветвления, привязанные к инструментарию управления WMI. Например, можно просто создать массив имен компьютеров, а затем получить из каждого класс WMI:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
Для выполнения методов, например, перезагрузки компьютера, необходимы некоторые дополнительные действия, поскольку версия 1.0 не предоставляет способ массового выполнения методов WMI. Однако это изменилось в версии 2.0 CTP благодаря командлету Invoke-WmiMethod:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
Однако этот метод имеет одну проблему. Он синхронный, что означает, что одновременно осуществляется обращение только к одному компьютеру, и для выполнения других команд необходимо подождать завершения. Но в версии CTP представлена новая концепция – фоновые задания, позволяющая выполнение подобных команд в фоновом режиме. В самом простом варианте команда WMI может быть выполнена в фоновом режиме простым добавлением параметра –AsJob:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
Можно просмотреть состояние итогового задания, выполнив Get-PSJob, а окончательные результаты задания можно просмотреть, выполнив Receive-PSJob. (Управление заданиями будет рассмотрено более подробно в следующей статье.) Однако командлет Invoke-Command предоставляет лучшие способы выполнения команд в фоновом режиме, например следующий:
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
Таким образом, команда Get-WmiObject передается всем указанным компьютерам, затем выполняется локально. Обычное выполнение происходит гораздо быстрее без необходимости использования подключений RPC инструментария WMI. Вместо этого Invoke-Command использует WinRM, который по умолчанию использует порт 80 или 443. Эти порты упрощают перемещение брандмауэров и являются полностью настраиваемыми. Invoke-Command также поддерживает дополнительные параметры для альтернативных учетных данных и регулирования, позволяя работать с сотнями компьютеров при параллельной работе всего некоторых из них. Это позволяет избежать перегрузки и излишних издержек.

Повторно используемые пространства выполнения
Если планируется удаленное управление определенным набором компьютеров более одного раза, следует рассмотреть использование пространств выполнения, а не простых списков имен компьютеров. Пространство выполнения в Windows PowerShell – это просто экземпляр механизма интерпретатора команд, выполняемый локально на компьютере как окно консоли интерпретатора команд или в фоновом режиме на удаленном компьютере. Запуск пространства выполнения осуществляется очень просто:
$names = @("server1","server2","server2")
New-RunSpace –computer $names
Поскольку пространства выполнения также используют WinRM, они также по умолчанию используют порт 80 (или 443, если указан параметр –UseSSL). Они также должны принимать альтернативные учетные данные и т. д. При получении итоговых объектов пространства выполнения их можно передать командлету Invoke-Command, и Windows PowerShell передаст команду компьютерам, на которых существуют пространства выполнения:
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
Преимущество заключается в том, что пространства выполнения остаются активными, пока интерпретатор команд открыт, поэтому их можно просто повторно использовать для дополнительных команд.

Удаленная работа слияния
Пространства выполнения также являются ключевыми объектами для удаленной работы слияния. Например, на рис. 1 показано созданное мною пространство выполнения на удаленном компьютере, полученная ссылка на это пространство выполнения и последующее использование командлета Push-Runspace для активации пространства выполнения. После этого я выполняю команды на удаленном компьютере аналогично тому, как позволяет SSH или средства удаленного интерпретатора команд. Выполнение Pop-Runspace возвращает исходное пространство выполнения «local», а командная строка оболочки помогает отслеживать местонахождение.
Рис. 1. Использование пространства имен для выполнения команд на удаленном компьютере (щелкните изображение, чтобы увеличить его)
Точная последовательность выполненных мною команд выглядит следующим образом:
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
Этот прием называется слиянием, поскольку одновременно удаленные интерактивные пространства выполнения на одном сервере могут быть открыты несколькими администраторами — происходит их «слияние» с отдельных рабочих станций на сервер. Новая модель безопасности в Windows PowerShell 2.0 позволяет создавать ограниченные интерпретаторы команд и командлеты, поэтому может быть запрещено внесение каждым администратором глобальных изменений. Каждый администратор ограничивается собственной областью в интерпретаторе команд. (Для этих новых методов обеспечения безопасности требуется установка определенного специального программного обеспечения на языке, предназначенном для платформы .NET Framework. Это выходит за рамки статьи о Windows PowerShell, но приятно знать, что такие возможности существуют.)

«Убойное» приложение в 2.0
В версию CTP Windows PowerShell 2.0 входит потрясающий список новых возможностей. По моему мнение, удаленная работа – это «убойное» приложение. Она выгода для всех администраторов практически во всех средах.
Вам следует ознакомиться с этими новыми функциями, чтобы вы могли предоставить свои предложения группе разработки. Вам необходимо управления портами WinRM по умолчанию через групповую политику? Должны ли командлеты работать по-другому? Присутствуют ли проблемы производительности? Достаточно ли просто осуществляется настройка WinRM? Вы можете внести свой вклад, отправив предложения на веб-узле connect.microsoft.com, или поделиться мнением с обладателями звания MVP, включая меня (чтобы связаться со мной, оставьте отзыв на форумах ScriptingAnswers.com). Поэтому примите участие и помогите в создании «убойного» приложения для Windows PowerShell следующего поколения!
Командлет месяца: Select-Object
Попробуйте выполнить следующую команду: Get-Service | ConvertTo-HTML | Out-File Services.htm. Теперь просмотрите полученный файл HTML в веб-обозревателе. Довольно много информации, не так ли? Если бы только существовал способ немного ограничить ее, выбрав только нужную информацию. Именно это выполняет командлет Select-Object. Например, предположим, необходим список имен служб и их текущего состояния. Можно использовать следующее: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.
Однако необходимо помнить только одно: командлет Select-Object сбрасывает исходный объект, в этом случае службы, и создает пользовательский объект (тип объекта PSCustom), содержащий только указанные свойства. Все функции исходного объекта более недоступны, поэтому, наверное, вам потребуется разместить Select-Object в конце конвейера, обеспечивая максимально долгую работу с объектом.

Дон Джонс – соавтор книги Windows PowerShell v2.0: TFM и преподаватель очных курсов «Special Forces» ScriptingAnswers.com (scriptinganswers.com/training.asp). С ним можно связаться по электронной почте: jeepdon@mac.com.


Эй, сценарист! Выбираем быстрый путь
Сценаристы корпорации Майкрософт

В последние несколько месяцев одному из сотрудников группы сценаристов довелось здесь, в Сиетле, приобрести новый опыт. Речь идет о тестируемой в разных городах США программе, которая называется «электронные платежи». Правда, в штате Вашингтон она известна под именем «Good to Go!» («Счастливого пути!»).
Это происходит примерно следующим образом: вы платите за некоторое электронное устройство, которое прикрепляется к лобовому стеклу. Еще вы открываете счет, на который кладете небольшую сумму денег. Каждый раз, когда на автостраде вы проезжаете под одним из контролирующих устройств, с вашего счета автоматически снимаются деньги. По существу вы платите за проезд по автостраде (пора уже автострады называть высокоскоростными дорогами, хотя не так давно некоторые из них находились в нескольких метрах под водой, из-за чего они были совсем не на высоте), не останавливаясь больше у поста по сбору платежей.
В настоящее вермя во многих местах, где предусмотрена плата за проезд, те, кто едет по полосе для заполненных пассажирами автомобилей, освобождены от этой платы. Однако, интересно то, что программа «Счастливого пути!» работает только в такой полосе. В чем же смысл, спросите вы? Кому придет в голову возиться с пассажирами, чтобы затем еще и платить? Что ж, они и не платят. Эта система взимает плату только с тех, кто предпочитает пользоваться такой полосой, находясь в автомобиле в одиночестве. Очевидная причина желания ехать в такой полосе состоит в том, что обычно на ней меньше автомобилей; временами эта полоса является единственной, в которой автомобили действительно движутся.
Как уже было упомянуто, именно сейчас проводятся эксперименты с этой системой, хотя тысячи людей уже подписались на нее. Многие жители Сиэттла хотят заплатить деньги за возможность ехать по скоростной дороге, чтобы добраться до требуемого им места назначения.
В статье этого месяца сценаристы решили провести свой собственный небольшой эксперимент. Мы решили показать вам «быстрый» путь, известный под названием Microsoft® Visual Basic® Express Edition. Начнем с того, что одним из замечательных качеств этого пути является то, что он действительно бесплатен: не будет каких-либо поборов независимо от того, где вы используете эту информацию, сколько людей используют ее или от того, какое сейчас время дня. Звучит заманчиво, не так ли? Безусловно, необходимость изучить кое-что новое можно считать небольшой ценой, которую придется заплатить, но вы вполне можете решить, что приобретаемые преимущества стоят того.
Прежде чем продолжить, мы хотим упомянуть о том, что отдаем себе отчет в том, что несколько выходим за свойственные нам рамки. Обычно продукты Visual Studio®, такие как Visual Basic и Visual C#®, относятся к сфере влияния журнала MSDN® а не журнала TechNet Magazine. Но поскольку MSDN и TechNet, кажется, движутся в сторону создания одной расстро… — то есть счастливой, — семьи, мы надеемся, что в рамках данной статьи нам будет предоставлена некоторая свобода действий . Кроме этого, несмотря на то, что речь идет о работе с тем, что традиционно было средством разработчиков, мы все-таки обращаемся к системным администраторам Windows®. Не покидайте нас в течение еще нескольких минут, и вы поймете, что имеется в виду.
Чтобы следить за развитием повествования, первым делом необходимо установить Visual Basic. Нет, подождите. Не убегайте со словами «У меня его нет!» или «Мне это не по карману!» - Майкрософт предоставляет версию Visual Basic Express Edition, которую можно загрузить бесплатно с веб-узла microsoft.com/express/download.
Мы не собираемся подробно рассматривать методы работы с Visual Basic Express. В справочной системе есть учебные пособия, да и сама справка действительно хорошо написана. (Трудно поверить, не так ли?) Мы намерены продемонстировать использование Visual Basic Express для решения конкретной проблемы в Windows Vista® (хотя этот пример будет работать также и в более ранних версиях Windows), а затем вы сможете продолжить играть с ним самостоятельно. Проблема, которую мы собираемся решать, состоит в следующем: как в Windows Vista открыть диалоговое окно открытия файла?
Несколько лет назад мы объясняли, как открыть диалоговое окно открытия файла из сценария (вспомните статью «Как отобразить для пользователей диалоговое окно выбора файлов?» на веб-странице по адресу microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx). Эта статья была опубликована в январе 2005 года, задолго до появления на свет Windows Vista. В решении для открытия диалогового окна открытия файлов, в котором можно отыскать открываемый файл, используется элемент управления ActiveX® UserAccounts.CommonDialog. К сожалению, этот элемент управления удален из Windows, если речь идет о Windows Vista, и это означает, что данное решение не будет работать в новых системах. (Нет-нет, никто не посоветовался с нами относительно разумности этой идеи.) Насколько мы понимаем, это означает, что не существует способа открыть диалоговое окно открытия файлов с помощью VBScript. Поэтому, вместо того, чтобы писать сценарий, мы используем Visual Basic для написания приложения. Одной из функций этого приложения будет открытие диалогового окна открытия файлов.
Совершенно верно, в примере, который мы собираемся продемонстрировать, строится завершенное приложение на Visual Basic. Поначалу это может показаться несколько пугающим, но вы убедитесь в том, что написать полноценное приложение с помощью Visual Basic Express так же просто, как написать сценарий. В этом приложении будет окно или форма, содержащая кнопку, нажатие которой приводит к открытию диалогового окна открытия файлов. Затем в этом диалоговом окне можно выбрать текстовые файлы, а наше приложение прочитает их и отобразит в форме выбранное содержимое файлов.
Ну что же, приступим к делу. Начнем с открытия Visual Basic Express. Первое, что необходимо сделать, это создать новый проект, что делается выбором пункта New Project (Новый проект) в меню File (Файл). Открывается диалоговое окно New Project. (Обратите внимание на то, что, если используется версия Visual Basic Express более ранняя, чем версия 2008 года, вы обнаружите небольшие отличия от того, что представлено в статье.) Мы собираемся создавать приложение Windows Forms, поэтому выбраем шаблон Windows Forms Application и вводим имя, предусмотренное для проекта. Свой проект мы назвали ReadFiles, что видно из рис. 1.
Рис 1 Создание нового проекта в Basic (щелкните изображение для его увеличения)
При первоначальном создании проекта в нем автоматически предоставляется новая форма для работы. Приложение, которое мы будем создавать, предоставит пользователю форму, подобную показанной на рис. 2. Как было сказано, в форме присутствует кнопка, нажатие которой приводит к отображению диалогового окна открытия файлов, демонстрирующего содержимое папки C:\Scripts. Пользователь имеет возможность выбрать один или несколько файлов из любой папки файловой системы. Затем приложение читает первую строку каждого из выбранных текстовых файлов и отображает результаты в форме в виде списка. (Если вам это кажется знакомым, скорее всего вы входили в подразделение начинающих на чемпионате 2008 года по программированию «Scripting Games»: microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx.).
Рис. 2 Форма ReadFiles в том виде, как она будет представлена пользователям
Чтобы создать собственную форму, необходимо перетащить элементы управления из панели инструментов в форму проекта. По умолчанию панель инструментов открывается в левой стороне окна Visual Basic. (Если панель инструментов не открыта, нажмите кнопку панели инструментов в левой стороне рабочего пространства Visual Basic и разверните узел «Все формы Windows».) Щелкните элемент «Кнопка» на панели инструментов, затем растяните создаваемую в форме кнопку до нужного размера. Для добавления названия кнопки щелкните только что добавленную в форму кнопку и введите требуемое название. (В качестве альтернативы можно изменить свойство Text в диалоговом окне свойств; по умолчанию оно находится справа внизу в рабочей области Visual Basic.) Мы назвали кнопку «Поиск файлов». Далее щелкните элемент ListBox, снова щелкните форму и растяните создаваемый список до нужного размера. Этот список будет использоваться для отображения строк, считанных из текстовых файлов.
Это все, что нужно сделать для создания нашей формы. Теперь перейдем к увлекательной части: нам необходимо добиться выполнения некоторой операции по нажатию кнопки. Сначала дважды щелкнем в форме элемент управления Button. Это приведет к открытию редактора кода, содержащего новую, уже подготовленную для вас подпрограмму Button1_Click:
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
Эта подпрограмма будет работать при каждом нажатии кнопки в форме. Видно, что в настоящий момент подпрограмма пуста; необходимо добавить код, который сообщит приложению, что требуется выполнить при нажатии кнопки. И что же именно нам требуется? Во-первых, необходимо, чтобы выполнялось то, что в начале этой статьи мы пообещали продемонстировать: открытие диалогового окна открытия файлов. Для этого, как и почти всегда при работе с Visual Basic, будет использоваться Microsoft .NET Framework.
Начнем с добавления пары операторов импорта, предшествующих подпрограмме:
Imports System
Imports System.IO
Эти операторы указывают подпространства имен .NET Framework. Мы будем использовать классы из этих подпространств имен, поэтому импортируем их сюда, чтобы было проще ссылаться на требуемые классы. Обратите внимание на то, что мы собираемся вставить эти операторы до подпрограммы. Операторы импорта являются глобальными, и это означает, что они не могут находиться внутри подпрограммы или функции; необходимо, чтобы они находились снаружи, сами по себе.
В VBScript, если только вы не добавляете оператор Option Explicit в верхнюю часть сценария, не требуется явно объявлять переменные. В Visual Basic этот оператор добавляется автоматчески, поэтому необходимо объявлять все переменные. Нам потребуется переменная для ссылки на объект OpenFileDialog (которые как раз представляет диалоговое окно открытия файлов):
Dim dlg As Windows.Forms.OpenFileDialog
Теперь, после того, как мы объявили (с помощью оператора Dim) переменную типа OpenFileDialog, можно создать новый экземпляр этого объекта следующим образом.
dlg = New OpenFileDialog()
Однако мы еще не отобразили диалоговое окно. Во-первых, необходимо установить некоторые свойства:
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Свойство Multiselect указывает, будет ли разрешено пользователю выбирать более одного файла в диалоговом окне открытия файлов. Мы предполагаем разрешить это, поэтому устанавливаем для этого свойства значение True. Для свойства InitialDirectory устанавливаем значение C:\Scripts. Если не установить значение этого свойства, в диалоговом окне будет отображаться содержимое главной папки комьютера.
И последнее, но безусловно важное замечание: мы устанавливаем значение свойства Filter:
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Здесь выполняется фильтрация файлов, отображаемых пользователю в диалоговом окне. Мы намерены показывать только файлы TXT. С такими значениями этих свойств диалоговое окно открытия файлов имеет следующий вид рис. 3.
Рис 3. Диалоговое окно открытия, отображающее только текстовые файлы (щелкните изображение для его увеличения)
Теперь, наконец, наступил момент отображения диалогового окна. Мы сделаем это с помощью метода ShowDialog.
dlg.ShowDialog()
Метод ShowDialog возвращает значение, указывающее, какую кнопку нажал пользователь – кнопку «Открыть» для выбора файлов, или кнопку «Отмена» для закрытия диалогового окна. Если нажата кнопка «Отмена», мы не предполагаем ничего делать. Поэтому помещаем вызов метода ShowDialog в условный оператор If, чтобы перед продолжением убедиться в том, что была нажата кнопка «Открыть».
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
Да, мы знаем, что проверялось свойство OK вместо свойства Open. В действительности за кадром кнопка «Открыть» — это то же самое, что кнопка «OK», просто для пользователей в слове «Открыть» больше смысла.
Теперь нам требуется узнать, который файл или файлы выбрал пользователь в диалоговом окне. Имена файлов содержатся в свойстве FileNames объекта, поэтому мы организуем цикл For Each для чтения имен файлов, содержащихся в этом свойстве.
For Each strName In dlg.FileNames
Стоп! Мы забыли объявить strName.
Dim strName As String
Теперь нам требуется открыть каждый из этих файлов и выполнить операцию чтения из них. В Visual Basic мы делаем это с помощью блока Using.
Using sr As StreamReader = File.OpenText(strName)
Создатели сценариев VBScript не привыкли использовать блок Using, поскольку фактически в VBScript его нет. По части управления системными ресурсами Visual Basic немного лучше (ладно, во многих случаях существенно лучше), чем VBScript. Смысл оператора Using в том, чтобы гарантировать освобождение системных ресурсов после выхода из блока. В этом случае мы просто гарантируем, что не привязаны к содержимому файлов и большим блокам памяти.
Мы знаем, что это звучит несколько запутанно. Но действительно, просто смотрите на это, как на оператор Set. Мы просто создаем экземпляр нового объекта, в данном случае объекта StreamReader, и присваиваем ему поток текста, возвращенный методом File.OpenText. Заметьте, что мы передаем методу OpenText имя файла, который требуется открыть, — файла из нашей коллекции FileNames, которая в текущий момент обрабатывается в цикле.
Поэтому наша переменная StreamReader, sr, содержит содержимое файла. Теперь нам требуется еще одна переменная.
Dim strLine As String
Эта переменная будет использоваться для хранения первой строки только что открытого текстового файла.
strLine = sr.ReadLine()
Мы читаем из файла первую строку, вызывая метод ReadLine из нашего объекта StreamReader. (Помните, что в объекте StreamReader содержится содержимое нашего файла.) Сохраняем эту строку текста в переменной strLine.
Теперь для добавления этой строки в список просто вызываем метод Add из нашего объекта ListBox.
ListBox1.Items.Add(strLine)
В этом примере всё, что нам требуется, — это первая строка файла, так что можно закрыть StreamReader (мы не хотим больше быть привязанными ко всему тексту файла) и блок Using.
sr.Close()
End Using
После этого выполнение цикла с целью поиска следующего файла, выбранного в диалоговом окне открытия файла, продолжается до тех пор, пока не будут прочитаны все выбранные файлы и добавлены все строки в список. Завершенный код выглядит так, как на рис. 4.
Рис. 4 Завершенный код ReadFiles
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
End Sub
End Class
Видите, мы же говорили, что создать приложение ненамного сложнее, чем создать сценарий.
Вы можете проверить свое приложение, нажав клавишу F5 (или нажав кнопку Start Debugging на панели инструментов Debugging). При нажатии кнопки и последующем выборе одного или нескольких файлов в диалоговом окне открытия файлов результаты должны выглядеть приблизительно так, как на рис. 5.
Рис. 5 Первые строки выбранных файлов, отображенные в списке
Если ваше приложение работает именно так, как вам требуется, выберите в меню «Сборка» пункт «Собрать ReadFiles» (можно использовать любое другое имя проекта). Создается файл EXE с именем ReadFiles.exe, который можно выполнять, как любое другое приложение, и который можно передавать пользователям.
Мы понимаем, что, возможно, использование диалогового окна открытия файла не показалось вам быстрой дорогой. Но, если учесть тот факт, что это вообще невозможно сделать в Windows Vista посредством написания сценария, то написание простого приложения может показаться невысокой ценой. Точно так же, как плата за возможность действительно доехать куда-нибудь, если вы находитесь на автостраде: это может создавать некоторые неудобства, но в итоге вы попадаете туда, куда вам требуется.
Дополнительным преимуществом использования Visual Basic для чего-нибудь подобного является то, что вы приступили к работе со средствгом с более широкими возможностями, чем VBScript, которое позволяет без труда создавать приложения с привлекательным пользовательским интерфейсом; это является дополнительным достоинством. Системные администраторы найдут также множество других применений для Visual Basic.
И помните, что вам не требуется заново изучать способ использования новой платной полосы; вам нужно всего лишь привыкнуть к тому факту, что автомобили впереди вас действительно движутся. Точно так же, если вы знаете VBScript, для использования Visual Basic не требуется изучать с нуля совершенно новый язык, необходимо только привыкнуть к тому факту, что вы в состоянии сделать гораздо больше.
Головоломка-сценарий доктора Скрипто.
Задача на этот месяц, требующая не только умения решать головоломки, но и навыков создания сценариев.

Август 2008. Азбука сценариев
В головоломке этого месяца требуется вставить буквы A – Z в пустые клетки, чтобы получить слово, некоторым образом связанное с написанием сценария. Каждая буква (A – Z) используется только один раз, буквы располагаются не в алфавитном порядке. Вставленная буква может быть началом слова, концом слова или находиттся в любом месте в середине слова. Например, в первой строке мы вставили букву C, чтобы получить слово SCRIPT.

ОТВЕТ:
Головоломка-сценарий доктора Скрипто.
Ответ: Азбука сценариев, август 2008 г.

Сценаристы работают... ну хорошо, получают зарплату в корпорации Майкрософт. Когда они не играют в бейсбол, не тренируют бейсбольную команду, не смотрят бейсбол и не занимаются другими делами, они заведуют центром сценариев TechNet. Веб-узел проекта находится по адресу www.scriptingguys.com.


Материалы о рабочей среде Введение в работу служб развертывания Windows
Уэс Миллер (Wes Miller)

Содержание
Службы развертывания Windows в Windows Server 2003
Службы развертывания Windows в Windows Server 2008
Нужный выбор
О чем стоит подумать
Приступая к работе со службами развертывания Windows
Образы записи
Введение в запись
Перенос образов
Автоматическая установка
В прошлом месяце в этой рубрике мы рассмотрели историю средств развертывания от Майкрософт, основанных на среде предзагрузочного выполнения (Pre-Boot eXecution Environment – PXE). Этот выпуск я посвятил службам развертывания Windows (Windows Deployment Services – WDS), в частности рассказу о версиях, поставлявшихся для Windows Server 2003, и обновленной версии, поставляющейся в составе Windows Server
2008. После этого я дам читателям все необходимое для начала работы с WDS.
WDS лучше всего представить себе как переписанные службы удаленной установки (Remote Installation Services – RIS). Хотя некоторые из их ключевых компонентов являются общими и, более того, WDS на Windows Server® 2003 имеет режим поддержки прежних версий, функционально идентичный RIS, реальная инфраструктура служб WDS, работающих в стандартном режиме или в наполовину смешанном режиме, является совершенно новой.

WDS в Windows Server 2003
Одновременно с выпуском Windows Vista® были предложены службы WDS. Это действие было необходимо, поскольку установка Windows Vista была полностью переработана с использованием архитектуры формата образов Windows® Imaging Format (WIM), что сделало службы RIS неспособными развертывать Windows Vista (и впоследствии Windows Server 2008). Затем службы WDS были сделаны доступными как дополнительная загрузка для клиентов, использующих Windows Server 2003 с пакетом обновления 1 (SP1). С выходом пакета обновления 2 (SP2) службы RIS были полностью заменены на WDS.
Следует помнить, что поскольку WDS в Windows Server 2003 имеют полную обратную совместимость, при установке WDS на системах Windows Server 2003 с пакетом обновления 2 (SP2) не нужно переходить в стандартный режим. Можно продолжать работу в режиме поддержки предыдущих версий (по сути, работая, как сервер RIS) или в смешанном режиме, позволяющем инициировать и WDS, и RIS.
Помимо того, что WDS может развертывать Windows Vista и Windows Server 2008, при работе в стандартном режиме или в стандартной половине смешанного режима он имеет несколько дополнительных функций. Вместо использования программы установки Windows, работающей в режиме ядра (technet.microsoft.com/magazine/cc645015), службы WDS используют Windows PE в качестве своей загрузочной предустановочной среды и развертывают образы на основе WIM вместо установок на основе RISetup или RIPrep. Это делает развертывание быстрее, проще и надежнее.
Вдобавок, многие из ограничений, упомянутых мною в последнем месяце, таких как необходимость использовать символы, основанные на стандарте Американского национального института стандартов (American National Standards Institute – ANSI), отпадают, поскольку Windows PE может отображать тот же набор символов, что и полная установка Windows.
Вдобавок, WDS получила несколько средств, которых сильно не хватало RIS, – оснастку консоли управления Майкрософт (Microsoft® Management Console – MMC) для помощи в управлении и средство настройки для командной строки с очень широкими возможностями, намного превосходящими те, что дает RIS.
Поскольку как режим поддержки предыдущих версий, так и смешанный режим допускают развертывание образов Windows на основе RISetup и RIPrep, возможно стоит помнить одну вещь. Исторически службы RIS использовали компонент, именуемый технологией хранения единственного экземпляра (Single Instance Storage – SIS), чтобы оптимизировать хранение образа на диске. Компонент SIS, который впоследствии поставлялся как часть Windows Storage Server 2003, использовал службу, именуемую гровелером, работающую в фоновом режиме на серверах RIS (и WDS) и занимающуюся поиском идентичных файлов. Если размер и хэш каких-то файлов совпадают, SIS сохраняет копию в собственную папку общего хранилища SIS и затем создает жесткую связь с каждой из найденных первоначальных версий.
Компонент SIS разработан так, чтобы минимально влиять на загрузку процессора, в то же время делая возможной существенную экономию места в хранилище. Это была отличная концепция, использовавшаяся сперва в RIS, а затем весьма широко на платформе Windows Server. Но SIS более не используется для развивающихся служб WDS.
Так как службы WDS при работе на Windows Server 2003 в стандартном режиме и всегда при работе на Windows Server 2008 используют для установки образы WIM, у них имеется собственная модель сжатия и, что более важно, собственная модель хранения файлов в единственном экземпляре – они совершенно не используют SIS. Хранилище образа заменяет модель хранилища, использовавшуюся в RIS, на новую архитектуру для WDS, основанную на WIM. Дополнительная информация о SIS доступна по адресу go.microsoft.com/fwlink/?LinkId=120302.

Службы развертывания Windows в Windows Server 2008
В Windows Server 2008 службы WDS стали одновременно расширенным набором и частью функций, имевшихся в Windows Server 2003. Теперь они могут развертывать образы многоадресно в автономном режиме, используя транспортный сервер, сервер упрощенного протокола передачи файлов (Trivial File Transfer Protocol – TFTP) с повышенной производительностью, системы x64 на основе расширяемого интерфейса микропрограмм (Extensible Firmware Interface – EFI) и усовершенствованную отчетность о параметрах инсталляции. Я расскажу обо всем этом в следующем месяце.
Следует отметить, что одна из функций WDS в Windows Server 2003 отсутствует в Windows Server 2008 – поддержка прежних методов установки. Возможности развертывать образы RISetup/RIPrep или использовать старый мастер выбора ОС служб RIS теперь недоступны.

Нужный выбор
Один из вопросов, который мне сравнительно часто задают с момента появления в продаже Windows Server 2008, таков: «Какую версию WDS мне следует использовать?» Ответ зависит от того, использует ли спрашивающий предшествующие Windows Vista версии Windows, и если да, готов ли он перейти с образов, основанных на RISetup и/или RIPrep, к однозначному использованию установки на основе WIM.
Службы WDS даже в Windows Server 2008 могут развертывать все версии Windows до Windows 2000 включительно, если они находятся в образе WIM, – и могут использовать многоадресность при этом. Так что для тех, кто переходит с RIS на WDS, думает о Windows Server 2008 в своей инфраструктуре и готов перейти с образов на основе RIS к образам на основе WDS, может иметь смысл и переход на WDS в Windows Server 2008.
Также можно перейти с RIS на WDS в самой системе Windows Server 2003, что, по сути дела, и происходит при установке пакета обновления 2, и приступить к использованию образов на основе WDS. После этого можно просто обновиться до WDS от Windows Server 2008 и работать дальше.
Однако я не рекомендую такую модель. Как и в случае многих версий Windows Server до 2008, корпорация Майкрософт рекомендует перенос с одной версии Windows Server на другую (вместо обновления поверх существующей системы).
Как я упоминал ранее, версии x64 Windows Server 2008 могут куда больше подходить к инфраструктуре, чем версии x64 Windows Server 2003. Если проделать этот переход, перенос WDS с сервера под управлением Windows Server 2003 на сервер под управлением Windows Server 2008 будет относительно прост и гораздо более надежен по сравнению с обновлением поверх существующей системы.

О чем стоит подумать
Ниже приведены некоторые моменты, которые стоит помнить при работе над развертыванием WDS. Обратите внимание, что они не являются новыми требованиями WDS (многие из них относятся и к RIS), но их стоит учитывать независимо от того, создается ли один сервер WDS или целая инфраструктура:
Права При управлении сервером WDS следует помнить две основные вещи. Сервер служб WDS необходимо авторизовать в Active Directory®, точно так же, как это надо было сделать с RIS. Чтобы сделать это, необходимо быть либо администратором домена в корневом домене леса или корпоративным администратором, либо получить соответствующие права. Администратором домена также необходимо быть для администрирования своего сервера WDS и, само собой, необходимо быть администратором на самом сервере WDS.
Виртуализация При работе на Windows Server 2003 или экземпляре Windows Server 2008, виртуализованном в Microsoft Virtual PC или Virtual Server и сообщающимся с клиентским ПК на той же установке Virtual PC или Virtual Server, при загрузке PXE может возникнуть конфликт, ведущий к очень медленной работе клиента и, потенциально, к его зависанию. Виртуализовывать рекомендуется либо клиенты, либо серверы, но не те и другие – особенно при работе на одной размещающей системе. Лично я не рекомендовал бы виртуализацию сервера WDS для использования в рабочей среде – в основном это обусловлено следующим пунктом.
Другие службы WDS, подобно RIS, не всегда хорошо взаимодействуют с другими рабочими службами. В частности, я сталкивался с проблемами с RIS/WDS при использовании рабочей системы, где также были запущены Microsoft Exchange Server, Systems Management Server (SMS) и System Center Configuration Manager (SCCM).
В целом, я бы советовал сделать WDS единственной ролью на сервере, если они используются для обслуживания сколь-либо значительного числа клиентов. Эта проблема не уникальна для WDS – тщательное обдумывание вопроса о том, следует ли смешивать роли серверных продуктов Windows и тестирование их перед развертыванием, весьма желательно.
Медленная связь или связь с большими задержками Как и RIS, службы WDS не предназначены для использования через подключения с низкой пропускной способностью или большими задержками, такие как спутниковая связь; подтверждение PXE может быть проблематичным; а загрузка изображений – мучительно долгой, если она вообще заработает.

Начало работы со службами развертывания Windows
Дополнительные сведения о службах развертывания Windows (WDS)

  • Поэтапное руководство по WDS в Windows Server 2003
  • Поэтапное руководство по службам развертывания Windows (Windows Server 2008)
  • Развертывание обновления WDS на Windows Server 2003 и управление им
  • Документация по службам развертывания Windows в Windows Server 2008
  • Техническая справка: службы развертывания Windows (Windows Server 2008).
Для начала необходимо решить, будут ли WDS использоваться на Windows Server 2003 или на Windows Server 2008. В случае использования Windows Server 2003 я рекомендую начать с пакета обновления 2, в который собственные службы WDS включены как необязательный компонент (заменяя RIS), а не использовать пакет обновления 1 и ранее доступную необязательную загрузку WDS, входящую в пакет автоматической установки Windows (Windows Automated Installation Kit – WAIK).
В любой из версий Windows Server желательно расширить серверную систему. Следует использовать высококачественную сетевую плату со скоростью как минимум 100 Мбит/с. Не используйте совместную работу сетевых плат, поскольку взаимодействие с ней инфраструктуры PXE служб WDS может оказаться проблематичным. Обратите внимание, что при использовании Windows Server 2008 WDS можно установить как на Server Core, так и на полную установку Windows Server 2008.
WDS установлены на Windows Server 2003 как необязательный компонент (как и RIS до них). Их можно установить в ходе установки операционной системы, либо позже, через Установка и удаление программ | Установка и удаление компонентов Windows (либо запустив sysocmgr.exe из командной строки). WDS устанавливаются на Windows Server 2008 и могут быть установлены через мастер первоначальной настройки (Добавить роли | Далее | и выберите службы развертывания Windows), через диспетчер серверов (те же действия, что и в мастере первоначальной настройки) или из командной строки путем выполнения команды ServerManagerCmd –install WDS.
После установки WDS их необходимо настроить. В меню «Пуск» Windows перейдите к пункту «Администрирование» и выберите службы развертывания Windows. Когда MMC запустится, щелкните свой сервер правой кнопкой мыши и выберите в меню «Настроить сервер», чтобы запустить мастер настройки.
В случае установки на Windows Server 2003 и обновления существующего RIS Server желательно указать существующую категорию RemoteInstall, чтобы старую установку можно было бы обновить до смешанного режима. В этой ситуации следует убедиться, что каталог RemoteInstall не расположен в системном разделе, что может повлиять на производительность.
На рис. 1 показана консоль WDS на Windows Server 2008 перед завершением работы мастера настройки. На рис. 2 показана страница приветствия для мастера настройки WDS на Windows Server 2008. На рис. 3 показан этап настойки PXE в мастере настройки WDS. На этом этапе можно указать, следует ли серверу отвечать любым клиентам (полезно для первоначального расширения), отвечать только известным клиентским компьютерам (которые были предварительно размещены в Active Directory) или отвечать всем клиентам (и следует ли придерживать всех неизвестных клиентов, чтобы администратор мог выбрать дальнейшие действия).
Рис. 1 WDS установлены, но еще не настроены
Рис. 2 Мастер настройки WDS
Рис. 3. Выбор политики ответа для сервера PXE
На рис. 4 показан полностью настроенный сервер WDS на Windows Server 2008 (образов пока не установлено) с открытой страницей свойств. При использовании сервера, уже являющегося сервером DHCP, не забудьте установить параметр 60 DHCP на PXEClient и указать WDS не вести прослушивание порта 67. Это позволит серверу WDS пропустить этап в ходе процесса обнаружения PXE (как я рассказывал в выпуске рубрики за прошлый месяц).
Рис. 4. Полностью настроенный сервер WDS на Windows Server 2008
По завершении работы мастера, можно добавлять новые образы. К серверу WDS, работающему в стандартном или смешанном режиме, можно добавлять два типа образов:
  • Загрузочные образы: это образы, содержащие Windows PE 2.x, обычно скопированные с установочного диска DVD Windows Server 2008 или Windows Vista с пакетом обновления 1. Обратите внимание, что когда развертывание многоадресно, для загрузочных образов желательно использовать файл \Sources\Boot.wim с Windows Server 2008 (даже если развертывается Windows Vista или старая операционная система). Загрузочные образы обычно состоят из Windows PE, файла Windows Setup.exe и других зависимостей.
  • Установочные образы: эти образы состоят из образов ОС Windows, как правило, файлов \Sources\Install.wim из Windows Vista или Windows Server 2008.
Действия по добавлению загрузочного образа по умолчанию или установочного образа по умолчанию почти идентичны. Оба процесса начинаются со щелчка типа образа правой кнопкой мыши и выбора образа этого типа.
Для установочного образа необходимо указать имя группы образов (поскольку WIM по умолчанию на диске DVD Windows содержит более чем один тип ОС). Затем следует перейти к соответствующему boot.wim или install.wim, который следует добавить, и нажать кнопку «Открыть». Для установочных образов можно затем отменить выбор любых образов тома (образов ОС), которые не следует добавлять к серверу WDS. Наконец, можно установить с помощью PXE клиенты, использующие эти образы по умолчанию.

Образы записи
Для создания собственных образов ОС необходимо создать образ записи – образ Windows PE, разработанный для обеспечения записи системы Windows в форме образа WIM. Проще всего использовать для этого ранее установленный образ boot.wim.
Щелкните нужный образ правой кнопкой мыши и выберите «Создать образ загрузки записи». Укажите имя и описание для образа и место, где следует сохранить локальную копию файла WIM в случае возникновения проблем с подключением при развертывании образа записи. Затем доведите работу мастера до завершения и нажмите кнопку «Готово».
Далее, щелкните правой кнопкой мыши папку загрузочного образа в консоли управления Майкрософт WDS MMC и выберите «Добавить загрузочный образ». Как и ранее, выполните указания мастера. По завершении работы можно приступать к записи установочного образа Windows.

Введение в запись
Перед записью образа операционной системы, само собой, необходимо установить Windows и убедиться, что имеются все желаемые приложения, настройки и обновления. Далее следует запустить Sysprep на своей системе; записывать образы установки Windows можно только с систем, подготовленных с помощью Sysprep. Необходимо указать допустимое локальное местоположение для сохранения нового образа (чтобы избежать возможных повреждений) и расширение файла *.wim.
После настройки системы и копирования на нее правильной версии sysprep.exe необходимо предпринять следующие действия:
  1. Из командной строки, находящейся на эталонном компьютере, перейдите в каталог, где расположен sysprep.exe.
  2. Запустите Sysprep (также можно начать, дважды щелкнув sysprep.exe и указав параметры вручную). На компьютерах, использующих Windows Vista или Windows Server 2008, выполните команду sysprep /oobe /generalize /reboot. На компьютерах, где установлены предыдущие версии Windows, выполните sysprep -mini –reseal –reboot.
  3. При перезапуске компьютера PXE загрузит его (процесс может идти по-разному в зависимости от клиентской системы).
  4. Из загрузочного меню выберите образ записи WDS и нажмите кнопку «Далее».
  5. Выберите диск, а также имя и описание для образа.
  6. Как уже упоминалось, видимыми будут только системы, обработанные Sysprep. Так задумано, и это нельзя обойти.
  7. Нажмите кнопку «Обзор» и перейдите к локальной папке, где следует сохранить записанный установочный образ. Выбранное местонахождение может быть подключенным сетевым диском.
  8. Выберите загрузку образа на сервер WDS.
  9. Введите имя сервера WDS и нажмите кнопку «Подключить».
  10. 10.Из писка групп образов, выберите группу образов, в которой следует сохранить образ, и нажмите кнопку «Готово».
Теперь образ готов к развертыванию с сервера WDS. Знатоки RIS могут заметить здесь кое-что – я не записывал этот файл образа Windows. WDS требует, чтобы записываемая система работала автономно.
Программа RIPrep в RIS могла записывать и подключенную к сети систему (на деле, только такую и могла). Этот процесс был чрезвычайно неустойчив. Я думаю, что процесс записи для WDS покажется сравнительно простым и определенно более надежным.

Перенос образов
У тех, кто когда-либо использовал RIS, наверняка сохранились какие-то образы. Образы, основанные на RISetup (управляемая сценарием установка), теперь можно стирать. Однако образы RIPrep можно перенести в образы WDS на основе WIM. На самом деле, WDS даже позволяет переносить образы с помощью программы WDSUtil (я объясню это подробнее в следующем месяце).
В целом, я рекомендую делать это, только если нежелательно терять образ, в который были вложены большие усилия. Процесс работает достаточно хорошо, но я слышал о некоторых ошибках в ходе переноса, которые обычно означают необходимость все равно создавать образ с нуля.

Автоматическая установка
Создание образа так, как я проделал ранее, дает образ, который можно устанавливать вручную. Для более автоматизированной или полностью автоматизированной установки необходимо использовать два файла автоматической установки. Сам WDS требует файла ответа (unattend.xml, хранящегося в каталоге \RemoteInstall\WDSClientUnattend на сервере WDS Server), который автоматизирует процесс установки WDS. Второй файл – это файл автоматической установки собственно образа. Для Windows Vista и последующих версий это файл unattend.xml. Для более ранних образов Windows это файл sysprep.inf, хранящийся в структуре каталога $OEM$ или папке \Unattend каталога каждого образа. Этот файл используется для автоматизации собственно установки Windows по завершении работы WDS.
Для создания файла автоматической установки WDS создайте файл unattend.xml для WDS при помощи WAIK. Скопируйте этот файл в каталог RemoteInstall (или подкаталог). Щелкните правой кнопкой мыши установочный образ, для которого нужно использовать файл автоматической установки, а затем нажмите кнопку «Свойства». На вкладке клиента выберите «Включить автоматическую установку» и предоставьте указанный ранее файл unattend.xml.
Чтобы создать файл автоматической установки образа для образов более ранних систем, чем Windows Vista, скопируйте файл sysprep.inf в каталог $OEM$ образа – например, D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf. Для образов Windows Vista укажите образ, который следует соотнести, нажмите кнопку «Свойства» и затем на вкладке «Общие» установите флажок «Позволить образу установку в автоматическом режиме». Затем укажите файл unattend.xml, который будет использоваться для установки.
Теперь полдела сделано. Эта статья должна дать читателям всё необходимое для начала работы с WDS. В следующем месяце я углублюсь в подробности о WDSUtil, особенностях хранилища образов и многоадресности. Затем я завершу серию статей подробным рассмотрением того, зачем может быть нужно индивидуализированное решение развертывания поверх WDS и как его создать . Пока что ознакомьтесь с боковой панелью «Дополнительные сведения о службах развертывания Windows (WDS)», сопровождающую эту статью.

Уэс Миллер (Wes Miller) — старший технический руководитель продуктов в CoreTrace (www.CoreTrace.com) в Остине, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.


На страже безопасности Пароли и кредитные карты, часть 2
Йеспер М. Йоханссон (Jesper M. Johansson)

Содержание
Псевдо-многофакторный процесс входа
Проблема надстроек обозревателя
Проверка подлинности никогда не должна изменяться
Возврат к менее защищенным паролям
Обход псевдо-многофакторного входа
Проблемы скомпрометированных паролей
Некоторые преимущества
Введение пользователей в заблуждение при помощи внешней привлекательности
Открывать или не открывать
Предоставление безопасного подключения
Всё сводится к конфиденциальности
Представляем второй из трех выпусков о том, как отрасль ИТ вводит пользователей в замешательство, а не помогает им в плане безопасности. В выпуске журнала TechNet Magazine за июль 2008 г. я обсуждал невыполнимые и неверные рекомендации относительно безопасности и вводящие в заблуждение процессы входа в систему. (Если вы не читали первую часть, ее можно найти
по адресу technet.microsoft.com/magazine/cc626076.). Я показал, как распространенные, но неверные советы относительно безопасности и плохие потоки работ входа в систему вводят пользователей в замешательство и подрывают их усилия по защите личных данных.
В данном выпуске я продолжу обсуждение этой темы и приведу дополнительные реальные примеры из мира безопасности пользователей. Последний выпуск этой серии, в который будет включен «призыв к оружию» для специалистов в области безопасности всего мира, появится в следующем выпуске журнала TechNet Magazine.

Псевдо-многофакторный процесс входа
В октябре 2005 г. Федеральный совет по надзору за финансовыми учреждениями (FFIEC) опубликовал правила «Authentication in an Internet Banking Environment» (Проверка подлинности в банковском обслуживании через Интернет) (см. www.ffiec.gov/press/pr101205.htm). Эти правила должны были быть реализованы в течение 14 месяцев, и в скором времени финансовые учреждения США приступили к попыткам поиска путей соблюдения новых правил.
Большинству учреждений не удалось соблюсти эти временные рамки. Многие учреждения, которые, в конечном счете, привели свою деятельность в соответствие с правилами, сделали эти способами, цели которых отличались от целей правил. Другими словами, организации предприняли меры, никоим образом не улучшившие безопасность клиентов (они были просто « театром безопасности»). Одни из наиболее интересных примеров бесполезных решений заключались в попытке создания многофакторной проверки подлинности, в действительности не являющейся многофакторной.
Например, технология, осуществляющая анализ ритмичности ввода пароля пользователем. Это решение, используемое на веб-узле, отображает диалоговое окно входа в систему, полностью идентичное старому диалоговому окну входа. Однако теперь это диалоговое окно является объектом Adobe Flash.
Объект Flash записывает ритмичность ввода пользователем пароля с клавиатуры, включая длительность нажатия клавиш и время между нажатиями. Эти данные передаются веб-узлу вместе с паролем, где они сравниваются с сохраненными значениями. Если ритмичность ввода данных соответствует сохраненным данным с заданным уровнем отклонения, и если пароль является верным, подтверждается вход в систему. Основная идея заключается в том, что это позволяет использовать на узле псевдо-биометрический метод проверки подлинности без установки на клиенте оборудования стороннего производителя.
Я буду называть это псевдо-многофакторной проверкой подлинности. Это не подлинная многофакторная проверка подлинности, которая основана на измерении двух или нескольких следующих канонических факторов:
  • чего-либо, принадлежащего пользователю (например, смарт-карты);
  • чего-либо, что известно пользователю (например, пароля);
  • чего-либо, относящегося к самому пользователю (например, отпечатка пальца).
Вместо действительного включения нескольких факторов в процесс проверки подлинности псевдо-многофакторная проверка подлинности считывает несколько параметров одного фактора – пароля. Затем эти дополнительные параметры используются для получения определенных выводов о пользователе.
Используемая для псевдо-многофакторной проверки подлинности технология имеет множество недостатков. Вместе все эти недостатки делают технологию в значительной мере неэффективной для разрешения проблем безопасности, для решения которых она предназначена.

Проблема надстроек обозревателя
Системы псевдо-многофакторной проверки подлинности основаны на использовании надстроек обозревателя для выполнения необходимой сложной обработки на стороне клиента. Конечно, все программное обеспечение имеет ошибки, а некоторые из них вызывают появление уязвимостей. Эти уязвимости становятся действительной проблемой в случае трудности обновления программного обеспечения, и если пользователь не уверен в том, было ли установлено обновление.
Надстройки обозревателя соответствуют обеим этим характеристикам — они трудны в обновлении и не предоставляют пользователю достаточную информацию об актуальности установленной версии надстройки. В результате пользователю необходимо предоставить определенному программному обеспечению доступ к Интернету, который в иных случаях не требуется.
В некоторых случаях для поддержания актуальности надстройки необходимо регулярное посещение веб-узла надстройки для проверки наличия обновления. Нет нужды говорить, что так поступают немногие пользователи. Любое программное обеспечение, требующее от конечных пользователей предоставления доступа к Интернету для дополнительного несвязанного программного обеспечения только для обеспечения безопасности, должно быть тщательно обдумано.

Проверка подлинности никогда не должна изменяться
Фактор «что-либо, относящееся к вам» имеют особенность, возможно, даже недостаток, не влияющий на два другие фактора. Хотя можно изменить пароли (что-то, что вы знаете) и создать новые маркеры безопасности (что-то, что у вас есть), количество биометрических проверок подлинности, которые можно использовать, достаточно ограничено. Например, что касается отпечатков пальцев, обычно их всегда десять. Если вы случайно лишитесь одного из пальцев, обычно его невозможно заменить.
Теперь рассмотрим, как это применяется к примеру псевдо-многофакторного входа в систему. Показатели, собранные как часть другого фактора, не могут быть просто заменены или изменены. Конечно, при изменении пароля изменится способ ввода пользователем нового пароля, но общий способ нажатия клавиш на клавиатуре не изменится. Именно на этом и основывается метод. При компрометации этих показателей может быть возможным их объединение. По крайней мере, злоумышленник может записать показатели и воспроизвести их.

Возврат к менее защищенным паролям
Неплохо использовать длинные пароли и часто менять их. И, как говорилось в первой части этой серии, также рекомендуется (вопреки некоторым советам) записывать пароли, обеспечив, конечно же, их безопасность. Однако эти методы не способствуют вводу пароля вручную. Длинные пароли труднее вводить, а сохраненные пароли гораздо более полезны, поскольку их можно скопировать и вставить. Одним из наилучших способов отслеживания сотни или более паролей является использование специального программного обеспечения, например, Password Safe (страница sourceforge.net/projects/passwordsafe). С помощью подобного средства можно создавать абсолютно случайные пароли, хранить их в зашифрованной форме и вставлять непосредственно в диалоговые окна входа в систему. Фактически, при использовании подобного средства не требуется даже знать сам пароль.
Но существует одно препятствие: ритмичность ввода пароля можно проверить только при его вводе с клавиатуры. И если необходимо вводить пароль в объект для измерения ритмичности ввода, этот способ управления паролями начинает испытывать проблемы. Правильный ввод 15-символьного абсолютно случайного пароля – непростая задача. И поэтому пользователи, сталкивающиеся с подобной системой, обычно стремятся упростить пароли. Хотя сам по себе 15-символьный абсолютно случайный пароль гораздо безопаснее короткого пароля в сочетании с псевдо-многофакторной системой проверки подлинности.
В действительности, реализованная исключительным образом псевдо-многофакторная проверка подлинности вынуждает пользователей использовать менее безопасные пароли. К сожалению, как вы скоро увидите, приспособление пользователей, использующих верные способы управления паролями, устраняет практически все значение систем псевдо-многофакторной проверки подлинности.

Обход псевдо-многофакторного процесса входа
Даже если на узле реализована псевдо-многофакторная проверка подлинности, она все равно должна поддерживать обход псевдо-многофакторной системы. Во-первых, на немногих веб-узлах от пользователей может требоваться установка «сторонней от сторонней» технологии для доступа к этому узлу. Некоторые пользователи (например, определенно авторы журнала TechNet Magazine) будут всегда отказываться устанавливать подобное программное обеспечение.
Во-вторых, ритмичность ввода может меняться по множеству причин, и поэтому это должно учитываться на узле. Например, предположим, что пользователь растянул запястье, и поэтому его ритмичность ввода временно изменилась. Как он получит доступ к узлу, если ритмичность уже проанализирована, и предполагается, что другое лицо пытается выполнить ввод с учетными данными пользователя? Если травма является неизлечимой, пользователь может сбросить сохраненное значение ритмичности. Однако в случае временного нарушения здоровья пользователь, скорей всего, не захочет восстанавливать сохраненное значение, предполагая, что ритмичность ввода в скором времени станет примерно такой же, как и ранее.
Наконец, использовать системы псевдо-многофакторной проверки подлинности могут не все пользователи. Например, лица с ограниченными возможностями, взаимодействующие с компьютерами с помощью интерфейса распознавания речи, могут быть не в состоянии заполнить поля диалогового окна в зависимости от того, допускается ли программный ввод. В этом случае, вероятно, должна быть законодательно необходима другая система, учитывающая пользователей с ограниченными возможностями.
Наиболее простым и прямолинейным способом учета всех этих случаев также является поддержка стандартной проверки подлинности, основанной на пароле.

Проблемы скомпрометированных паролей
Подразумевается, что системы псевдо-многофакторной проверки подлинности должны решать различные проблемы, связанные с проверкой подлинности на основе паролей. Однако эти системы не обеспечивают устранение всех существенных способов компрометации паролей. Существует пять основных способов компрометации систем, основанных на проверке подлинности на основе паролей, где «компрометация» означает, что злоумышленнику известен пароль другого пользователя, и он использует его:
  • подбор пароля;
  • средства регистрации нажатия клавиш;
  • фишинг;
  • запрос пользователя;
  • взлом системы хранения пароля или его хэша.
Сейчас подбор паролей довольно редко используется злоумышленниками и значительно менее популярен, чем средства регистрации нажатия клавиш и фишинг. Кроме того, возможность подбора паролей устраняется псевдо-многофакторной проверкой подлинности только частично. Маловероятно, что обычный процесс подбора пароля будет работать в системах псевдо-многофакторной проверки подлинности, поскольку злоумышленник должен подобрать не только пароль, но и ритмичность печати. Хотя воспроизведение показателей печати теоретически возможно, это редко бывает необходимым, поскольку действительные данные могут быть собраны с помощью фишинга или средств регистрации нажатия клавиш. Кроме того, если система также предоставляет стандартный интерфейс входа в систему, использующий только пароль, злоумышленник может просто использовать эту систему для подбор пароля.
Помимо этого, атаки подбора паролей могут быть предотвращены путем использования надежных паролей. Если мы можем научить пользователей использовать надежные пароли, возможно, с помощью специальных средств, псевдо-многофакторная проверка подлинности не требуется. (В отличие от этого, более простые пароли, обычно используемые с системами псевдо-многофакторной проверки подлинности, в действительности делают подбор паролей более осуществимым подходом.) Таким образом, вся представленная ценность для устранения опасности подбора пароля значима только в случае, если реализация не поддерживает вход в систему только с паролем. И, как я указывал, это очень маловероятно, если вообще возможно. Другими словами, если в системах псевдо-многофакторной проверки подлинности пользователи используют менее надежные пароли, подбор пароля снова может стать возможным способом атаки; псевдо-многофакторная проверка подлинности ухудшает, а не улучшает безопасность. Этот вопрос нуждается в дополнительном исследовании.
Псевдо-многофакторная проверка подлинности также не разрешает проблему использования средств регистрации нажатия клавиш. Хотя мне неизвестны используемые в настоящее время средства регистрации нажатия клавиш, сохраняющие данные ритмичности ввода, нет никаких причин тому, чтобы кто-то разработал такие средства. Средство регистрации нажатия клавиш – это оборудование, располагающееся между клавиатурой и компьютером, или небольшая программа, регистрирующая нажатие клавиш. В любом случае средство регистрации получает полный доступ ко всем данным, используемым решением псевдо-многофакторной проверки подлинности.
Фактически, средству регистрации нажатия клавиш могут быть доступны не только данные, поскольку решение проверки подлинности работает в пользовательском режиме, а средство регистрации нажатия клавиш располагается далеко за его проделами. Без достоверного пути между клавиатурой и веб-объектом для регистрации пароля этот тип компрометации невозможно предотвратить. Если решения псевдо-многофакторной проверки подлинности станут достаточно распространены, вы, несомненно, может быть именно тем, кто создаст подобное средство регистрации нажатия клавиш.
Аналогично, псевдо-многофакторная проверка подлинности не защищает от фишинга. Вместо использования одного поддельного экрана входа в систему злоумышленник может использовать объект Flash для регистрации пароля и ритмичности ввода с клавиатуры.
Конечно, псевдо-многофакторная проверка подлинности может помочь в некоторых случаях, когда используемый злоумышленником способ предоставляет только пароль. Например, самый простой способ получить от пользователя пароль – спросить его. Невероятно, но этот метод доказал свою эффективность, запрашиваются ли пользователи лично, по телефону или путем фишинга.
Конечно, запрашивание у пользователя ритмичности ввода будет гораздо менее эффективным. Аналогично, при компрометации корпоративной базы данных злоумышленник скорей всего получит доступ только к паролям. Но опять же, эти атаки будут предотвращены, только если система не предоставляет стандартную проверку подлинности только с паролем.
Следует также отметить, что если сама база данных паролей на самом деле была скомпрометирована, скорей всего злоумышленник скомпрометировал систему гораздо больше, чем в случае одного или даже нескольких паролей обычных учетных записей пользователей. Поэтому в действительности бесполезно пытаться предотвратить действия злоумышленника, обладающего базой данных с паролями.

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

Введение пользователей в заблуждение при помощи внешней привлекательности
Один из самых лучших способов запутывания пользователей – предоставление неточных указаний относительно безопасности. Самым распространенным указанием, вероятно, является изображение замка на веб-странице, как показано на рис. 1. Эта страница идет еще дальше, рядом с замком отображается слово «Secure» (Безопасно).
Рис. 1. Пример злоупотребления значком с замком, тенденции, вызывающей беспокойство (щелкните изображение, чтобы увеличить его)
Как вы, конечно же, знаете, простое размещение на странице изображения замка и слова «Безопасно» не делает ее безопасной. Однако, что вызывает тревогу, такая практика является распространенной даже на самых зарекомендовавших себя и наиболее посещаемых веб-узлах. В результате множество пользователей привыкает к этим визуальных обозначениям безопасности на веб-странице вместо того, чтобы смотреть, что в действительности обозначают эти метки: в адресной строке. (На вики-странице W3C Web Security Context имеется статья, посвященная данной проблеме, доступная по адресу w3.org/2006/WSC/wiki/PadlockIconMisuse.)
К сожалению, по-прежнему существует множество примеров подобного неверного использования. Исследования показали, что пользователи не могут определить вредоносные веб-узлы даже при очевидности сертификатов (см. www.usablesecurity.org/papers/jackson.pdf). Все сводится к возможности просто отличать подделку, даже если ее не с чем сравнивать. Для этого необходимы навыки; визуальная привлекательность веб-страниц, вводящая в заблуждение относительно безопасности, препятствует выработке таких навыков, поскольку пользователям предоставляется неверная информация.
Особенно тревожный вариант этой проблемы показан на рис. 2. В этом случае страница, на которой отображаются сведения, в действительности не является безопасной. Если взглянуть на адресную строку, можно увидеть слово «http», обозначающее протокол. На этом узле используется очень распространенный метод оптимизации — вместо шифрования страницы с формой входа шифруется только отправка формы. Вход в систему является безопасным, что и указывается на странице, если словно «безопасно» означает «зашифровано». Однако, что очень важно, пользователь не может проверить отправку учетных данных до выполнения отправки! На узле не показан сертификат, подтверждающий подлинность веб-узла для пользователей до отправки формы. Это игра с доверием, также как упасть навзничь, предполагая, что сзади стоящий человек поймает вас. Ко времени отправки формы ущерб уже может быть нанесен.
Рис. 5. Безопасный внешний вид на небезопасной странице (щелкните изображение, чтобы увеличить его)
Протокол SSL, обеспечивающий безопасность протокола HTTPS, служит двум главным целям. Во-первых, он проверяет подлинность сервера для пользователя. Во-вторых, он предоставляет простой механизм согласования ключа шифрования сеанса, который может использоваться между клиентом и сервером.
При шифровании только самой отправки формы не достигается первая и самая главная цель. Узлы с применением подобной оптимизации используют SSL только для согласования ключей. По иронии это может осуществляться с помощью простого использования стандартного протокола согласования ключа, таким образом снижая затраты и перегрузку SSL.
Узел, показанный на рис. 2, не является чем-то редко встречающимся. Множество узлов обеспечивают защиту SSL только для отправки формы, но не для самой формы. Однако данный конкретный узел демонстрирует еще более тревожную черту. При вводе https://www.<site>.com (обратите внимание на указатель безопасности https) в адресную строку обозревателя узел перенаправит на версию узла без SSL! Даже при попытке просмотра сертификата перед отправкой узлу учетных данных сертификат не будет показан.
Не все узлы настолько плохие, но множество узлов подобны рассмотренному. И среди таких узлов узлы двух крупнейших учреждений США, выпускающих кредитные карты. Фактически, из трех крупных компаний, занимающихся обслуживанием кредитных карт, услугами которых я пользуюсь, только American Express предоставляет сертификат в форме входа в систему. American Express даже перенаправляет запросы HTTP на HTTPS. Отлично!
Последняя мысль о бессмысленной внешне привлекательной безопасности – это отсутствие сертификатов в форме входа в систему. Возможно, вам интересно узнать причины этого. Ответ заключается в простой экономии. Для представления сертификатов необходимо шифрование страницы, а это вызывает дополнительную обработку. Дополнительная обработка означает необходимость большего количества компьютеров для обслуживания нагрузки такого же объема. А большее количество компьютеров – это дополнительные затраты. К сожалению, при выборе между обеспечением конфиденциальности пользователей и увеличением прибыли множество организаций выберут последнее.

Открывать или не открывать
Недавно я получил по электронной почте удивительное сообщение от моей компании страхования здоровья. Все, кто пользуется компьютерами последние 10 лет, знают, что не нужно открывать незапрашиваемые вложения электронной почты. Поэтому представьте мое удивление, когда я получил сообщение, показанное на рис. 3.
Рис. 5. Сообщение электронной почты с «безопасным вложением» (щелкните изображение, чтобы увеличить его)
Вероятно, я задал вопрос на веб-узле компании страхования здоровья (и забыл это ко времени получения подозрительного сообщения). Так ответила компания. Сначала я подумал, что это ловкая схема фишинга. Но как выяснилось, это было подлинное сообщение, волосы на моем затылке начали вставать дыбом.
Первое указание заключается в необходимости двойного щелчка вложения для начала расшифровки сообщения. Сообщества безопасности и администраторы ИТ целых 10 лет пытались научить пользователей НЕ открывать вложения. И после этого компания (учреждение медицинского обслуживания, чьими услугами я пользуюсь, и, кстати, не единственная организация, использующая подобный подход) заявляет, что в целях моей безопасности я должен открыть вложение. Как должен действовать пользователь в такой ситуации? Какие действиям он знает или уже забыл?
Далее, я воспользовался функцией предварительного просмотра Microsoft® Office Outlook® 2007, чтобы просмотреть сообщение. Как показано на рис. 4, программа Outlook решила, что это сообщение может представлять опасность и рекомендовала мне не открывать его!
Рис. 4. Программа Outlook 2007 посчитала надежный документ небезопасным (щелкните изображение, чтобы увеличить его)
Одновременно смешно и грустно, что компания медицинского страхования может нарушить простейшие проверки безопасности, используемые в самой популярной почтовой программе в мире. Предполагая, что эта компания даже не проверила новое решение безопасности в программе Outlook, мне приходится догадываться, что еще компания осуществляет в интересах защиты моей частной информации. Или, говоря более откровенно, какие еще решения реализованы компанией исключительно для того, чтобы избежать обвинений в недостаточности защиты конфиденциальности клиентов? Это напоминает театр безопасности финансовых учреждений. Я думаю, что в этом случае основной причиной решения является избежание обвинения, а не защита клиентов.
Мне захотелось увидеть, что же собой представляет вложение. Оказалось, что это объект элемента управления ActiveX®. Чтобы просмотреть вложение, мне пришлось открыть его в обозревателе Internet Explorer® и установить объект. Я увидел успокаивающее окно, показанное на рис. 5. Как можно видеть, создатели пошли на все, чтобы это сообщение выглядело как обычный почтовый конверт, на нем даже есть штамп с уверением о надежности.
Рис. 5. Безопасный документ с изображением конверта со штампом «Trusted» (Надежно)(щелкните изображение, чтобы увеличить его)
Этот тип технологии вызывает тревогу по множеству причин. Во-первых, он поощряет выполнение пользователем недопустимых действий: открытие незапрашиваемых вложений. Во-вторых, само сообщение содержало в корне неверное указание на настройку системы на открытие вложений без выдачи запроса. В-третьих, несмотря на противоречащие сообщения компьютера (в сообщении электронной почты уверяется, что оно надежное, а программа Outlook заявляет обратное), сообщение выглядит очень подозрительным. Наконец, вложение содержит бесполезное визуально привлекательное обозначение безопасности, убеждающее пользователя в действительной надежности сообщения. Если пользователь привыкнет доверять подобным сообщениям, это быстро приведет к появлению доверия к сходным вредоносным сообщениям.

Предоставление безопасной связи
По общему признанию, проблема, для решения которой предназначена эта технология, является очень важной. Обеспечение доверенной связи с клиентами – очень трудная задача. Однако данное конкретное решение отличается излишней разработанностью. Скорее всего, оно вызовет путаницу у клиента и, возможно, приведет к противоположному результату, отличному от предполагавшегося: компрометации системы клиента.
Правильно созданные веб-узлы теперь используют «центр сообщений». В таком случае если компании необходимо связаться с клиентом, она отправляет сообщение электронной почты с текстом, подобным следующему: «В центре сообщений имеется непрочитанное сообщение. Посетите наш веб-узел, войдите в систему и щелкните ссылку центра сообщений, чтобы прочитать сообщение.» Компания получает премиальные баллы, если использует S/MIME для подписывания всех отправляемых клиентам сообщений электронной почты, чтобы пользователи могли проверить подлинности источника. Дополнительные премиальные баллы компания получает в случае, если в сообщении электронной почты отсутствуют фразы «щелкните данную ссылку». Пользователь должен ввести URL-адрес компании от руки, чтобы открыть именно нужный узел.
Центр сообщений и подписанные сообщения позволяют компании обеспечить надежный канал связи с клиентом. Проверена подлинность всего, что видит клиент во время рабочего процесса обмена сообщения, а компания не предоставляет неверных рекомендаций относительно безопасности.

Все сводится к конфиденциальности.
Пока я посвятил два из трех выпусков этой серии описанию того, как специалисты в области безопасности в действительности вредят пользователям. Обеспечение безопасности является нашей работой. Но множество принятых решений и реализованных систем вводят пользователей в заблуждение, рекомендуя им принимать неправильные решения и создавая у них неверное представление о безопасности. Нам не следует заваливать пользователей этими противоречивыми идеями.
Как указывалось ранее, для обычных пользователей безопасность означает простую защиту паролей и номеров кредитных карт. Им необходимо, чтобы технологии работали и были надежными. К сожалению, им приходится принимать решения, и наша работа состоит в том, чтобы их решения были компетентными.
В последнем выпуске этой серии я рассмотрю, как некоторые из наиболее важных доступных для пользователей технологий не оправдывают ожиданий. Я также представлю мою программу действий. Поэтому ознакомьтесь с рубрикой «На страже безопасности» в номере за сентябрь 2008 г.

Йеспер М. Йоханссон является архитектором программного обеспечения, который работает над программами безопасности, и пишущим редактором журнала TechNet Magazine. Он имеет докторскую степень по информационным системам управления, обладает более чем 20-летним опытом в области безопасности и званием наиболее ценного специалиста (MVP) Майкрософт по безопасности предприятий. Его последняя книга – Windows Server 2008 Security Resource Kit.

© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.


Экологически безопасная компьютеризация Отфильтровать «зеленый камуфляж»
Дейв Охара (Dave Ohara)

Содержание
Потребность в числах
Измерение энергопотребления
Коэффициент мощности
Измерения в ходе работы
Центр корпоративного проектирования Майкрософт
Заключение
Множество продуктов и решений рекламируются как экологически чистые, энергосберегающие и более экономные. Весь этот рекламный шум затрудняет обнаружение на рынке действительно соответствующих экологическим нормам продуктов. Даже после оценки характеристик различных продуктов специалисту по ИТ сложно, если вообще возможно
определить, какое оборудование следует использовать, когда воздействие на окружающую среду является ключевым вопросом. При просмотре всех демонстраций можно заметить постоянное выделение серьезного сбережения энергии, что заставляет думать, будто отдача от инвестиций упрощает обоснование необходимости обновления. В конце концов, энергосбережение должно понизить совокупную стоимость владения.
Стремление всех типов компаний ставить метку «природосберегающее» чуть ли не на все подряд и эксплуатировать нынешний интерес в экологически чистых решениях привело к появлению концепции «зеленого камуфляжа», под которым имеется в виду обещание несуществующих экологических преимуществ. Так какова же на деле ситуация с энергосбережением? Она не так проста, как, скажем, установка новых, экономичных лампочек у себя дома.
В силу растущего интереса в экологически безопасных информационных технологиях и расширяющегося рынка для информационного оборудования с минимальным воздействием на окружающую среду многие пользователи организации переходят прямо к развертыванию энергосберегающих переносных компьютеров, настольных систем и серверов, а также использованию виртуализации для снижения потребления энергии. Но немногие организации проводят аудиты энергопотребления, чтобы определить реальные выгоды от своих покупок.
Хотя лучшим способом его проведения являются активные измерения в рабочей среде, они также могут быть затратными. Те, кто не готов к началу замера показателей в рабочей среде, все же могут продвинуться вперед, выполняя свой аудит энергопотребления ранее в процессе – в лабораториях оценки производительности. (Большинство компаний имеют какую-либо лабораторию или группу, ответственную за тестирование и оценку оборудования, перед выполнением покупок.) В них можно сделать энергопотребление одним из критериев теста и затем учитывать полученные результаты при принятии решений о покупках вместо того, чтобы полагаться на цифры, предоставляемые производителями. Так что по мере проведения тестов создавайте собственную базу данных по энергопотреблению устройств. Это позволит увидеть то, что работает, самому, не обращая внимания на «зеленый камуфляж».
Само собой, стоит отметить, что если необходимы точные цифры для эксплуатации под реальной нагрузкой, необходимо вести наблюдения в рабочей среде. Чем быстрее начнется наблюдение за рабочей средой, тем лучше для организации и ее итоговых показателей. Этот процесс будет ключевым для ее долговременного успеха.

Потребность в числах
В идеальной ситуации, мы имели бы независимые тесты, оценивающие производительность оборудования на ватт энергопотребления в условиях реальных рабочих нагрузок. Но отрасль пока находится в ранних стадиях разработки и развертывания подобных тестов. А те из них, что доступны сейчас, такие как эталон SPEC Power, все еще остаются в зачаточном состоянии. Насколько хорошо они будут работать, когда станут готовы, еще предстоит увидеть. Но, как и в случае любого теста, производители, без сомнения, научаться модифицировать свое оборудования для получения оптимальных тестовых результатов.
Опытные специалисты по ИТ научились сомневаться в тестах, выполненных лабораториями тестирования. Подобно автомобилестроителям, посылающим свои лучшие автомобили для дорожных испытаний, поставщики в ИТ будут направлять свои наиболее экономные комплектации оборудования для тестов энергосбережения.
Представьте себе тесты виртуализации, используемые для сравнения с избыточной группой серверов, в которой не выполнялась консолидация, с целью демонстрации преимуществ виртуализации. Поставщики забывают упоминать возможный эффект рикошета от энергосберегающих проектов вроде виртуализации. По сути, под этим имеются в виду случаи, когда энергосбережение понижает затраты и требует повышения скости ответа, что повышает использование энергии и интенсивность эксплуатации. При виде решения вроде виртуализации, рекламируемого в качестве панацеи для энергосбережения, следует сохранять скептицизм. Крайне желательно увидеть, как все будет работать вместе и какими будут волновые эффекты с течением времени.
Так как можно найти правильный путь для своей организации? Существует немало консультантов, готовых выполнять платные оценки. Но у такого подхода есть свои крупные недостатки. Стоит ли передавать знание того, как быть эффективным, за пределы своей организации? Стоит ли полагаться на консультанта, желающего поддерживать долгосрочный контакт и создать зависимость от своих услуг?
Это можно превратить в огромный проект с десятками участников, занимающихся определением стратегии экологической безопасности. Избегайте соблазна просто выбрать место в рабочей среде и начать измерения. Порыв может быть направлен в верную сторону, но такой подход не имеет смысла, поскольку это просто случайное действие. Необходимо выяснить, где действительно происходит потребление энергии и где на него можно повлиять.

Измерение энергопотребления
Необходимо начать думать по другому о том, что работает, а что нет. Специалисты по ИТ знают, что элемент оборудования не работает, если, скажем, отключается служба. Но как насчет элемента оборудования, не работающего должным образом в плане энергопотребления? Подобные вещи, вероятно, не привлекают внимания, поскольку у большинства организаций нет данных для установки стандартов энергоэкономичности.
Как можно получить эти данные? Кое-кто считает, что для этого необходим «энергетический диктатор». Но им может быть только человек, способный провести организацию компании и разбирающийся в вопросах электроэнергии. Простым, более доступным методом является добавления средств измерения энергопотребления к существующим функциям в лабораториях оценки производительности.
Существует широкий спектр подобных устройств. Увы, ни одно из них не идеально для лаборатории оценки производительности ИТ. Из более дешевых можно выбрать Watts Up Pro. Это устройство USB, представляющее внутреннее измерение мощности для 120 вольт. Еще одно устройство – Smart-Watt, подключаемое к сети устройство измерение потребления мощности для диапазона в 100-240 вольт и 15-30 ампер. Доступны также устройства Smart-Watt с датчиками температуры и влажности для измерения факторов среды. Затем идут устройства анализа мощности промышленного уровня, такие как Extech Appliance Tester 380801 и Fluke 345 Power Clamp. Подбор подобных устройств для удовлетворения потребностей лабораторных тестов не должен составить проблем.

Коэффициент мощности
Тем, кто незнаком с измерением мощности, важно понять концепцию коэффициента мощности. Коэффициент мощности электрической системы переменного тока (в РФ – «косинус фи») определяется как соотношение реальной мощности к фиксируемой мощности и выражается числом от 0 до 1. Реальная мощность (Вт) – это возможность сети по выполнению работы. Фиксируемая мощность (ВА) является производной тока и напряжения в сети.
Может возникнуть вопрос, почему это важно. Взгляните на рис. 1. На фотографии показано использование измеряющего энергопотребление устройства компании Smart Works для сравнения экономичности переносного компьютера, лампочки и конденсатора. У лампочки на 50-ваттную нагрузку приходятся 50 ВА, давая коэффициент мощности 1,0. Конденсатор с чисто емкостной нагрузкой дает 2-ваттную нагрузку и 193 ВА – коэффициент мощности 0,01. Переносной компьютер использует 22 ватта мощности, но имеет показатель 48 ВА – коэффициент мощности 0,47. Низкий коэффициент мощности переносного компьютера вызван неэффективным блоком питания, и вероятно, является результатом направленности на снижение производственных издержек.
Рис. 1. Потребление мощности для настольного компьютера, лампочки и конденсатора (щелкните изображение, чтобы увеличить его)
При столь значительном интересе к экономии энергии поставщики теперь ищут способы улучшения производительности источников питания в ожидаемых условиях. Если сравнить коэффициент мощности существующего оборудования с таковым для нового оборудования, можно обнаружить, что определенные энергетические ресурсы можно высвободить, просто выбрав решения с более экономными источниками питания и более высокими коэффициентами мощности.

Измерения в ходе работы
Целью измерения результатов в лаборатории проверки производительности является предсказание производительности в рабочей среде. Проблема с измерением энергопотребления при работе состоит в затратах на измерение его для все устройств. Одна из стратегий уменьшения этих затрат состоит в измерении на распределительном щите и сведении воедино показателей различного оборудования. На Рис. 2 показан пример показателей энергопотребления, снятых с распределительного щита с несколькими одинаковыми приборами на одном модуле. Поскольку можно рассчитать среднее энергопотребление на сервер, этот способ измерения дает цифры энергопотребления для рабочей среды.
Рис. 2. Измерения у распределительного щита (щелкните изображение, чтобы увеличить его)
По мере проведения замеров на каждом устройстве информацию о мощности следует интегрировать в базу данных управления настройкой. Если это слишком сложно, можно создать собственную базу данных или, по крайней мере, электронную таблицу Excel®, показывающую устройства и их энергопотребление. По мере сбора новых устройств можно вносить в нее оценки для них, чтобы создать общий расчет требуемой мощности. Имейте в виду, что новый энергосберегающий сервер будет потреблять менее половины своей пиковой нагрузки на единицу мощности при простоях. А при наличии старых серверов, использующих устаревшие решения, они будут потреблять значительные объемы энергии даже при простоях. Это одна из самых явных целей для экономии электроэнергии.
Если работу по улучшению нужно продолжить, следующим этапом является расчет мощности на каждую стойку, используемую в центре данных. При изменении среды необходимо твердо знать имеющийся запас по мощности и охлаждению. Со временем это позволит начать учитывать энергопотребление оборудования, а не только занимаемое им пространство. Концепция пространства проста – оно статично и наглядно. Специалисты по ИТ всегда готовы обсуждать серверы 1U, 2U и 4U, но достаточно заговорить о 200-ваттных серверах в сравнении с 400-ваттными, чтобы тем же самые специалисты по ИТ начали испытывать сложности в беседе. Это новый подход к информационному оборудованию, и это очевидно при взгляде на современные центры данных. Многие из них имеют массу пространства для дополнительного оборудования, хотя и исчерпали свои возможности питания.

Центр корпоративного проектирования Майкрософт
Центр корпоративного проектирования (ЦКП) Майкрософт недавно добавил к своему центру возможности по измерению мощности. ЦКП, расположенный в корпоративном кампусе Майкрософт в Редмонде, штат Вашингтон (microsoft.com/windowsserver/evaluation/eec/default.mspx), является оснащенным по последнему слову техники полигоном для самых сложны вычислительных сред.
Благодаря более чем 40 миллионам долларов США, вложенным в оборудование, включая сетевое (см. рис. 3), ЦКП может осуществлять самые сложные воссоздания реальных корпоративных рабочих сред. Группа работает со многими ведущими поставщиками решений для сетей, хранилищ и серверов/клиентов, чтобы предложить смесь новейших технологий и старых платформ. Цель состоит в обеспечении аккуратного отражения текущей среды клиента каждым из тестов. Последней службой, разрабатываемой в этом центре, является служба отчетов об энергопотреблении для решений с целью предоставления эталона производительности на ватт.
Рис. 3. Один из многих рядов в лаборатории ЦКП (щелкните изображение, чтобы увеличить его)
За последние несколько лет ЦКП неоднократно сталкивался с исчерпанием операторами центров данных наличных ресурсов питания и охлаждения для их оборудования. К наиновейшему оборудованию часто прилагается повышенная плотность мощности, что повышает нагрузку на инфраструктуру. Персонал ЦКП вплотную познакомился с расходами и временем, уходящими на обновление инфраструктуры питания и охлаждения. Так что для повышения эффективности и экономичности в ЦКП добавлена возможность измерять мощность на устройство.
Некоторые из средств и приборов, используемых ЦКП, не поставлялись в момент написания этой статьи. Поскольку это решение только что создано, ЦКП продолжит разрабатывать улучшенные методики, работая с клиентами, поставщиками и группами разработки Майкрософт. ЦКП делится методами, разработанными им к настоящему моменту, с клиентами для получения ранних отзывов, позволяя клиентам создавать собственные эталоны.
И не надо предполагать, что результаты будут очевидны. ЦКП поделился некоторыми из интересных результатов, полученных группой при использовании функций наблюдения за энергопотреблением в лабораториях производительности ЦКП:
  1. Отключение устройства не обязательно понижает энергопотребление настолько, насколько можно ожидать (см. рис. 4). В одном из случаев с серверным оборудованием в ЦКП обнаружили устройство, потреблявшее 100 ватт, когда оно было выключено, но подключено к питанию физически. Такое удивило многих и EEC многократно воспроизводил эту ситуацию. В конце концов, они использовали инфракрасный термометр для измерения температуры штепселя и розетки устройства и убедились, что оно в самом деле потребляет 100 ватт, когда отключено.
  2. Программное обеспечение может существенно повлиять на энергопотребление. На идентичных сетевых коммутаторах с идентичным оборудованием и параметрами BIOS использование различного ПО для работы с сетью дало 21 процент разницы в энергопотреблении. Высокоуровневые решения, где включено больше процессов и функций, таких как средства безопасности и наблюдения, часто потребляют больше, чем их более скромные аналоги.
  3. В случаях виртуализации в ЦКП замеряли энергопотребление в сравнении с использованием ресурсов ввода/вывода и ЦП, чтобы определить, когда определенный прибор дает максимальную производительность на ватт. В ЦКП обнаружили, что фиксация на использовании ресурсов ЦП может привести к загрузке слишком многих виртуальных компьютеров на физический компьютер, что снижает общую производительность на ватт.
  4. Устройства с высокой плотностью размещения, как можно догадаться, сталкиваются с большим числом проблем питания и охлаждения. При развертывании систем с высокой плотностью размещения следует как можно раньше проконсультироваться со специалистами по питанию и охлаждению. Эти устройства могут быть хорошими кандидатами на размещение собственных устройств наблюдения за расходом энергии, если известно, что возможности питания в среде будут ограничены.
  5. Двойные блоки питания могут потреблять гораздо больше энергии, чем одинарный блок питания.
  6. Кажущиеся идентичными устройства с идентичными комплектациями могут существенно различаться по энергопотреблению. Наблюдавшиеся различия были достаточно существенными, чтобы заставить персонал ЦКП перепроверять, действительно ли комплектации идентичны.
  7. Число ватт на информационной табличке изделия является не действительным показателем потребления, а номинальной мощностью для блоков питания.
  8. Ведение базы данных тестов энергопотребления и результатов для различных устройств и подкомпонентов – ключевой элемент сохранения знаний и сравнения данных.
  9. Различные составы одинаковых объемов памяти потребляют различные объемы энергии. Меньшее число модулей DIMM обычно потребляет меньше энергии, например 4 DIMM по 2 ГБ тратят меньше, чем 8 DIMM по 1 ГБ. Но в некоторых случаях меньшее число модулей DIMM потребляло больше энергии.
Рис. 4. Сравнение энергопотребления во включенном и отключенном состоянии (щелкните изображение, чтобы увеличить его)

Заключение
Добавив возможность измерять энергопотребление к своей лаборатории проверки производительности, можно начать собирать собственную базу данных по энергопотреблению на устройство, с точными цифрами для своих реальных нагрузок. При развертывании этих решений, результаты следует проверить в системе обратной связи с замкнутым циклом, чтобы определить точность тестов своей лаборатории проверки производительности. Как персонал ЦКП выяснил, при выполнении собственных тестов измерения, существуют некоторые весьма интересные детали, позволяющие отфильтровать «зеленый камуфляж» и обнаружить правду.
Этот метод проведения замеров в лабораториях проверки производительности заставит рынок в целом начать определение того, что действительно является энергосберегающим. И со временем производители обнаружат, что необходимо предоставлять более точные данные в своих заявках об энергосбережении. Аналогично, специалисты по ИТ начнут говорить о ваттах на устройство как об обычном критерии покупок. Это должно стать обычной практикой, особенно для компаний, покупающих большое количество серверов. Однако процесс можно возглавить, начав думать о мощности питания как об одном из ценных информационно-технических ресурсов уже сейчас.
Поддержка охлаждения в центре данных
Охлаждение центров данных имеет громадный потенциал по снижению энергопотребления. Нагрев, который может быть создан в центре данных, и энергия, уходящая на охлаждение оборудования, просто поражают. Но тем, кто желает успешно управлять охлаждением, исправлять проблемы и разрабатывать более эффективные решения для охлаждения, необходимо решение для наблюдения за температурой. Подумайте о решении, используемом центрами данных Майкрософт.
Исследовательский центр Майкрософт создал сеть датчиков температуры для центров данных, делающую возможным улучшенный контроль температуры, а также оценку различных улучшений охлаждения. Например, один из центров данных Майкрософт рассматривал эффективность тепловых завес на концах проходов, чтобы улучшить разделение горячего и холодного воздуха. После их установки некоторые серверы начали посылать предупреждения о перегреве. Естественно, специалисты по эксплуатации увеличили поток воздуха от системы охлаждения, чтобы дать больше холодного воздуха. Но, к их удивлению, еще несколько серверов послали предупреждения. И все эти серверы находились на дне стойки – дно, само собой, обычно является самым холодным местом.
Используя сеть датчиков, специалисты убедились, что стойки были более прохладными выше и горячее всего внизу. И скоро они догадались, что горячий воздух вытягивается из горячего прохода между дном стойки и полом – следствие принципа Бернулли. Они легко справились с перегревом, сделав дно стойки сплошным и уменьшив скорость воздушного потока.
Данные такого рода и собирает, а затем анализирует Центр корпоративного проектирования Майкрософт при выполнении тестирования производительности. Так, ЦКП недавно уведомил исследовательский отдел Майкрософт, что они готовы к тесту развертывания. В течение дня система была развернута на 10 стойках, и установка заняла лишь один час. Сейчас ЦКП может исследовать и углублять свое понимание проблем охлаждения и их взаимоотношений с производительностью оборудования.
Само собой, одно лишь наблюдение не является решением. Реальная выгода заключается в возможности находить проблемные области, которые можно исправить, во внесении изменений и оценке различных решений, на предмет выдачи ожидаемых результатов. В конце концов, никому не охота быть застигнутым врасплох неожиданным перегревом стоек из-за нового решения охлаждения.

Дэйв Охара (Dave Ohara) обладает 26-летним опытом работы с технологиями. Сейчас он работает с несколькими компаниями, реализующими экологические инициативы.


Заметки разъездного инженера IMAP спасает мир
Рыкандар Коррати (R'ykandar Korra'ti)

Порой решения для новых, маленьких проблем могут решать и старые, большие проблемы. Это один из таких случаев.
Прошлой зимой наш веб-администратор купила MacBook. Ранее она работала исключительно на Windows®, но теперь у нее есть как OS X, так и Windows XP в виртуальной машине для синхронизации ее устройств Windows Mobile® и некоторых других мелких задач.
Ей был нужен доступ ко всем ее почтовым архивам из обеих операционных систем. Но она не хотела использовать Entourage на Макинтоше – это было бы слишком просто. Нет, ей хотелось использовать Mail.app, клиент электронной почты, входящей в OS X. Между прочим, она хранила все в локальном хранилище своего настольного компьютера, без зеркалирования. Моя задача: заставить это работать.
Возможность считывать архивы отовсюду была лишь упомянутой выше маленькой проблемой, поскольку (и это первая мораль нашей истории) все программы, включая Exchange Server, Microsoft® Office Outlook® и Mail, понимают IMAP4. IMAP4 – это протокол обмена сообщениями для обработки находящихся на сервере хранилищ сообщений от «тонких» клиентов. У него меньше функций, чем могло бы быть удобно для пользователей Exchange, но он работает (см. «Принцип работы: IMAP4» в мартовском и апрельском выпусках журнала TechNet Magazine за 2006 год, по адресу technet.microsoft.com/magazine/cc161016).
Так что достаточно изменить несколько параметров, чтобы включить IMAP4 через SSL, скопировать локальные папки на сервер – и связь установлена! Она могла получать доступ к почте на всех клиентах и обновлять свои устройства Windows Mobile. Проблема решена.
Но придумать простое решение для потенциально опасной проблемы – это все равно, что обзавестись новым отрезным станком. Неожиданно начинаешь искать фанеру, чтобы он не простаивал, и не успеешь оглянуться, как ты уже построил сцену и готов ставить «Ромео и Джульетту».
Наш крохотный поставщик услуг доступа к Интернету использует Windows, OS X, Mac OS, Linux и даже одну одинокую старую систему AmigaOS, стоящую в уголке, надеясь найти друга. Давным-давно мы размещали новости Usenet и почту UUCP на этой Amiga. Она создавала архивы, сохраняемые в формате RFC-733/AmigaUUCP. У нас также имеются архивы Microsoft Mail (формат MMF) и некоторые настолько же старинные архивы почты UNIX (формат MBOX). Все они просто сидели там и дразнили нас – проблема, о которой мы задумывались время от времени, после чего разбегались со стонами.
Эта ситуация ведет нас ко второй морали нашей истории, старинному девизу Danger Hacker («Хакера опасности»): не стирай того, что не можешь заменить.
Сперва мы взялись за архивы Microsoft Mail. Outlook в свое время не имел возможности импортировать файлы import.mmf. Но, по мере того, как мы обновляли клиенты с течением лет, мы сохраняли минимум одну лицензию на каждый продукт, поскольку неизвестно, когда что пригодится. В результате по нашей полке для лицензий можно проследить историю корпорации Майкрософт. Нужен MS-DOS®? OS/2 1.31? Microsoft Mail? Office 95? Никаких проблем! Вам на английском или на французском?
Outlook 2000 импортировал MMF, но его поддержка IMAP была странной и часто теряла данные заголовков. Кроме того, он не мог общаться с серверами IMAP4 и Exchange одновременно. Это было досадной, но вряд ли непреодолимой помехой. После импорта файлов MMF через Outlook 2000, обновления на оставшуюся у нас лицензию от Outlook 2003 и нескольких часов перетаскивания 15-летние архивы находятся в сети и их можно смотреть откуда угодно. Аналогично для MBOX – забросьте совместимый с mbox сервер IMAP на компьютер Linux и поместите архивы формата MBOX в в его рабочий каталог. Затем используйте поддержку IMAP в Outlook, чтобы подключиться и скопировать папки на рабочий сервер по выбору.
Архивы Amiga, с другой стороны, потребовали написания небольшого пакета кода на C для преобразования заголовков RFC-733 в формат RFC-822, сброса старых разделителей сообщений в стиле SysV и извлечения странных данных строк From: из специальной преисподней, где они обитали. Такова цена долгого игнорирования проблем. Но по окончании работы формат AmigaUUCP становится форматом MBOX. И после заброски в тот же рабочий каталог IMAP4 в Outlook тут же вернул почту, как новенькую. Он даже удобно упаковал для нас вложения.
Теперь наши архивы вплоть до 1990 года подключены к сети в едином формате, и мы ищем еще архивы… просто потому что можем подключить их. Интересно, мы нормальные?

Рыкандар Коррати (R'ykandar Korra'ti) работает администратором службы электронной почты небольшого кооперативного поставщика услуг Интернета и живет недалеко от г. Сиэтл со своей подругой Анной. Ранее она занималась поставками почтовых продуктов в Майкрософт, а сейчас пишет технические статьи, когда не работает над текстами к известным лишь немногим любителям песням для мандолины. Антрепренеры могут связаться с ней по адресу darako@murkworks.net.


О Windows из первых рук: Строительство на старом фундаменте
Рэймонд Чен (Ramond Chen)

Один из моих коллег выудил компьютер Alpha AXP из пыльного чулана. После загрузки системы он обнаружил, что на ней была установлена 64-разрядной версия Windows®, датированная началом 2000-х годов. Как такое возможно?»
Так получилось, что в моем офисе тогда стоял один их этих компьютеров. В свои лучшие времена этот компьютер был недюжинной силой. Он был размером с небольшой холодильник и шумел примерно как пылесос. Он содержал четыре (подумайте только, четыре!) процессора Alpha AXP, каждый с умопомрачительной частотой в 400 МГц. В нем имелись гигабайт оперативной памяти и тринадцать гигабайт места на диске – на более чем двенадцати дисках SCSI. В наши времена это может звучать убого, но тогда, в 1990-е, эти компьютеры Alpha AXP были предметом всеобщей зависти и привлекали к хозяину внимание.
В 1999 году, когда компания Compaq заявила, что больше не будет поддерживать Windows на Alpha AXP, масса систем Alpha AXP оказалась стоящей в Майкрософт безо всякого официального дела. Но некоторым из этих компьютеров скоро нашлись неофициальные дела. Я использовал мою систему Alpha AXP, чтобы проиндексировать весь исходный код Windows. Можете себе представить, насколько удобной для программиста может быть возможность определить все, что вызывает функцию, за считанные секунды или обнаружить исходный код для функции или диалогового окна, появляющегося в трассировке отладки.
Но даже в простой задаче индексирования Windows машины Alpha AXP скоро померкли в тени компьютеров архитектуры x86. Они были дешевле и быстрее, предлагали больше места на диске и имели больше памяти. По этой причине мой компьютер скоро присоединился ко своим забытым собратьям. Предполагалось, что конец поддержки Alpha AXP станет концом для этих компьютеров, но им была дана возможность погибнуть со славой, отдав последние капли крови на благо следующего поколения.
Проект 64-разрядной Windows уже был в разгаре, а из обдумывавшихся 64-разрядных процессоров под рукой и в физической форме имелись лишь Alpha AXP. Intel Itanium все еще был в разработке, существуя лишь в имитаторе, а архитектура AMD64 еще даже не была изобретена. В результате 64-разрядная версия Windows первоначально разрабатывалась на Alpha AXP.
Когда компания Compaq объявила, что больше не будет поддерживать Windows на Alpha AXP, все те компьютеры Alpha AXP, что раньше использовались для разработки и тестирования 32-разрядной Windows 2000, были перенацелены и начали вести тайную жизнь как тестовые компьютеры для 64-разрядной операционной системы, которая никогда не будет поставляться в этой форме. Компьютеры Alpha AXP были просто платформой для проверки концепции.
Компьютеры Alpha AXP хорошо послужили в этой роли, дав группе разработчиков 64-разрядной системы Windows реальное оборудование для работы, вместо необходимости запускать операционную систему на эмуляторе Itanium. (Можете себе представить, насколько это было медленно.) Конечно, Alpha AXP не были конечным целевым оборудованием, но они серьезно помогли в работе. Когда же ЦП Itanium начали появляться «в железе», ниша, которую занимали Alpha AXP, исчезла и они опять оказались в пыльных чуланах.
Мои друзья, работающие в архивах Майкрософт, вытащили мой старый, верный Alpha AXP из его пыльного чулана для этой фотосъемки, где он позирует с одним из продуктов, который воплотился в жизнь с его помощью: 64-разрядным выпуском Microsoft Windows Server® 2003. И, да, это подлинная пыль.

Рэймонд Чен (Raymond Chen) на своем веб-узле The Old New Thing (Хорошо забытое старое) и в книге с таким же названием (издательство Addison-Wesley, 2007 г.) рассказывает об истории развития Windows и касается вопросов программирования в среде Win32. Он предпочел бы не оказываться запертым в пыльном чулане.